aboutsummaryrefslogtreecommitdiffstats
path: root/roms/u-boot/doc
diff options
context:
space:
mode:
Diffstat (limited to 'roms/u-boot/doc')
-rw-r--r--roms/u-boot/doc/.gitignore1
-rw-r--r--roms/u-boot/doc/I2C_Edge_Conditions46
-rw-r--r--roms/u-boot/doc/Makefile124
-rw-r--r--roms/u-boot/doc/README.440-DDR-performance90
-rw-r--r--roms/u-boot/doc/README.AMCC-eval-boards-cleanup31
-rw-r--r--roms/u-boot/doc/README.Heterogeneous-SoCs105
-rw-r--r--roms/u-boot/doc/README.JFFS240
-rw-r--r--roms/u-boot/doc/README.JFFS2_NAND8
-rw-r--r--roms/u-boot/doc/README.LED77
-rw-r--r--roms/u-boot/doc/README.OFT28
-rw-r--r--roms/u-boot/doc/README.POST732
-rw-r--r--roms/u-boot/doc/README.SNTP17
-rw-r--r--roms/u-boot/doc/README.SPL113
-rw-r--r--roms/u-boot/doc/README.TPL49
-rw-r--r--roms/u-boot/doc/README.VLAN15
-rw-r--r--roms/u-boot/doc/README.VSC3316-330843
-rw-r--r--roms/u-boot/doc/README.arm-caches53
-rw-r--r--roms/u-boot/doc/README.arm-relocation193
-rw-r--r--roms/u-boot/doc/README.armada-secureboot373
-rw-r--r--roms/u-boot/doc/README.asn140
-rw-r--r--roms/u-boot/doc/README.atmel_mci74
-rw-r--r--roms/u-boot/doc/README.atmel_pmecc49
-rw-r--r--roms/u-boot/doc/README.autoboot162
-rw-r--r--roms/u-boot/doc/README.bcm7xxx150
-rw-r--r--roms/u-boot/doc/README.bcmns374
-rw-r--r--roms/u-boot/doc/README.bedbug78
-rw-r--r--roms/u-boot/doc/README.bitbangMII56
-rw-r--r--roms/u-boot/doc/README.bloblist82
-rw-r--r--roms/u-boot/doc/README.bootcount51
-rw-r--r--roms/u-boot/doc/README.boston58
-rw-r--r--roms/u-boot/doc/README.bus_vcxk67
-rw-r--r--roms/u-boot/doc/README.cfi63
-rw-r--r--roms/u-boot/doc/README.commands.itest16
-rw-r--r--roms/u-boot/doc/README.commands.spl31
-rw-r--r--roms/u-boot/doc/README.console100
-rw-r--r--roms/u-boot/doc/README.davinci82
-rw-r--r--roms/u-boot/doc/README.davinci.nand_spl141
-rw-r--r--roms/u-boot/doc/README.dfutftp118
-rw-r--r--roms/u-boot/doc/README.displaying-bmps27
-rw-r--r--roms/u-boot/doc/README.distro430
-rw-r--r--roms/u-boot/doc/README.dns62
-rw-r--r--roms/u-boot/doc/README.enetaddr118
-rw-r--r--roms/u-boot/doc/README.esbc_validate40
-rw-r--r--roms/u-boot/doc/README.ext483
-rw-r--r--roms/u-boot/doc/README.falcon232
-rw-r--r--roms/u-boot/doc/README.fdt-control230
-rw-r--r--roms/u-boot/doc/README.fec_mxc39
-rw-r--r--roms/u-boot/doc/README.fsl-clk5
-rw-r--r--roms/u-boot/doc/README.fsl-ddr439
-rw-r--r--roms/u-boot/doc/README.fsl-dpaa10
-rw-r--r--roms/u-boot/doc/README.fsl-esdhc8
-rw-r--r--roms/u-boot/doc/README.fsl-hwconfig46
-rw-r--r--roms/u-boot/doc/README.fsl-trustzone-components25
-rw-r--r--roms/u-boot/doc/README.fsl_iim48
-rw-r--r--roms/u-boot/doc/README.fuse67
-rw-r--r--roms/u-boot/doc/README.generic-board135
-rw-r--r--roms/u-boot/doc/README.generic_usb_ohci63
-rw-r--r--roms/u-boot/doc/README.gpio42
-rw-r--r--roms/u-boot/doc/README.gpt315
-rw-r--r--roms/u-boot/doc/README.hwconfig50
-rw-r--r--roms/u-boot/doc/README.i2c60
-rw-r--r--roms/u-boot/doc/README.iomux89
-rw-r--r--roms/u-boot/doc/README.kconfig158
-rw-r--r--roms/u-boot/doc/README.kwbimage104
-rw-r--r--roms/u-boot/doc/README.link-local75
-rw-r--r--roms/u-boot/doc/README.lynxkdi57
-rw-r--r--roms/u-boot/doc/README.m54418twr245
-rw-r--r--roms/u-boot/doc/README.malta16
-rw-r--r--roms/u-boot/doc/README.marvell98
-rw-r--r--roms/u-boot/doc/README.mediatek221
-rw-r--r--roms/u-boot/doc/README.memory-test98
-rw-r--r--roms/u-boot/doc/README.mpc74xx22
-rw-r--r--roms/u-boot/doc/README.mpc83xx.ddrecc154
-rw-r--r--roms/u-boot/doc/README.mpc83xxads97
-rw-r--r--roms/u-boot/doc/README.mpc85xx166
-rw-r--r--roms/u-boot/doc/README.mpc85xx-sd-spi-boot75
-rw-r--r--roms/u-boot/doc/README.mpc85xx-spin-table26
-rw-r--r--roms/u-boot/doc/README.mpc85xxcds225
-rw-r--r--roms/u-boot/doc/README.multi-dtb-fit65
-rw-r--r--roms/u-boot/doc/README.mxc_ocotp51
-rw-r--r--roms/u-boot/doc/README.nand345
-rw-r--r--roms/u-boot/doc/README.nand-boot-ppc44060
-rw-r--r--roms/u-boot/doc/README.nokia_rx5194
-rw-r--r--roms/u-boot/doc/README.odroid332
-rw-r--r--roms/u-boot/doc/README.omap-ulpi-viewport27
-rw-r--r--roms/u-boot/doc/README.omap3199
-rw-r--r--roms/u-boot/doc/README.pblimage111
-rw-r--r--roms/u-boot/doc/README.pcap62
-rw-r--r--roms/u-boot/doc/README.plan918
-rw-r--r--roms/u-boot/doc/README.power-framework166
-rw-r--r--roms/u-boot/doc/README.pxe258
-rw-r--r--roms/u-boot/doc/README.ramboot-ppc85xx102
-rw-r--r--roms/u-boot/doc/README.rmobile98
-rw-r--r--roms/u-boot/doc/README.rockchip703
-rw-r--r--roms/u-boot/doc/README.rockusb56
-rw-r--r--roms/u-boot/doc/README.s5p441863
-rw-r--r--roms/u-boot/doc/README.s5pc1xx72
-rw-r--r--roms/u-boot/doc/README.sata68
-rw-r--r--roms/u-boot/doc/README.sched53
-rw-r--r--roms/u-boot/doc/README.scrapyard11
-rw-r--r--roms/u-boot/doc/README.semihosting38
-rw-r--r--roms/u-boot/doc/README.serial_multi54
-rw-r--r--roms/u-boot/doc/README.sha158
-rw-r--r--roms/u-boot/doc/README.silent28
-rw-r--r--roms/u-boot/doc/README.socfpga178
-rw-r--r--roms/u-boot/doc/README.spear74
-rw-r--r--roms/u-boot/doc/README.splashprepare34
-rw-r--r--roms/u-boot/doc/README.srio-pcie-boot-corenet118
-rw-r--r--roms/u-boot/doc/README.standalone120
-rw-r--r--roms/u-boot/doc/README.t1040-l2switch63
-rw-r--r--roms/u-boot/doc/README.tee112
-rw-r--r--roms/u-boot/doc/README.ti-secure226
-rw-r--r--roms/u-boot/doc/README.ubi258
-rw-r--r--roms/u-boot/doc/README.ubispl141
-rw-r--r--roms/u-boot/doc/README.ublimage141
-rw-r--r--roms/u-boot/doc/README.udp35
-rw-r--r--roms/u-boot/doc/README.unaligned-memory-access.txt240
-rw-r--r--roms/u-boot/doc/README.uniphier462
-rw-r--r--roms/u-boot/doc/README.update97
-rw-r--r--roms/u-boot/doc/README.usb231
-rw-r--r--roms/u-boot/doc/README.vf61010
-rw-r--r--roms/u-boot/doc/README.video97
-rw-r--r--roms/u-boot/doc/README.vxworks115
-rw-r--r--roms/u-boot/doc/README.watchdog33
-rw-r--r--roms/u-boot/doc/README.zfs29
-rw-r--r--roms/u-boot/doc/SPI/README.altera_spi6
-rw-r--r--roms/u-boot/doc/SPI/README.ftssp010_spi_test41
-rw-r--r--roms/u-boot/doc/SPI/README.sandbox-spi42
-rw-r--r--roms/u-boot/doc/SPI/README.sh_qspi_test38
-rw-r--r--roms/u-boot/doc/SPI/README.ti_qspi_am43x_test76
-rw-r--r--roms/u-boot/doc/SPI/README.ti_qspi_dra_test47
-rw-r--r--roms/u-boot/doc/SPI/README.ti_qspi_flash47
-rw-r--r--roms/u-boot/doc/SPI/status.txt32
-rw-r--r--roms/u-boot/doc/SPL/README.am335x-network96
-rw-r--r--roms/u-boot/doc/SPL/README.omap352
-rw-r--r--roms/u-boot/doc/SPL/README.spl-secure-boot18
-rw-r--r--roms/u-boot/doc/android/ab.rst72
-rw-r--r--roms/u-boot/doc/android/avb2.rst133
-rw-r--r--roms/u-boot/doc/android/bcb.rst100
-rw-r--r--roms/u-boot/doc/android/boot-image.rst155
-rw-r--r--roms/u-boot/doc/android/fastboot-protocol.rst178
-rw-r--r--roms/u-boot/doc/android/fastboot.rst234
-rw-r--r--roms/u-boot/doc/android/index.rst14
-rw-r--r--roms/u-boot/doc/api/dfu.rst7
-rw-r--r--roms/u-boot/doc/api/efi.rst176
-rw-r--r--roms/u-boot/doc/api/getopt.rst8
-rw-r--r--roms/u-boot/doc/api/index.rst19
-rw-r--r--roms/u-boot/doc/api/linker_lists.rst159
-rw-r--r--roms/u-boot/doc/api/logging.rst6
-rw-r--r--roms/u-boot/doc/api/pinctrl.rst7
-rw-r--r--roms/u-boot/doc/api/rng.rst17
-rw-r--r--roms/u-boot/doc/api/sandbox.rst9
-rw-r--r--roms/u-boot/doc/api/serial.rst7
-rw-r--r--roms/u-boot/doc/api/timer.rst8
-rw-r--r--roms/u-boot/doc/api/unicode.rst7
-rw-r--r--roms/u-boot/doc/arch/arc.rst32
-rw-r--r--roms/u-boot/doc/arch/arm64.rst59
-rw-r--r--roms/u-boot/doc/arch/index.rst18
-rw-r--r--roms/u-boot/doc/arch/m68k.rst170
-rw-r--r--roms/u-boot/doc/arch/mips.rst46
-rw-r--r--roms/u-boot/doc/arch/nds32.rst101
-rw-r--r--roms/u-boot/doc/arch/nios2.rst111
-rw-r--r--roms/u-boot/doc/arch/sandbox.rst519
-rw-r--r--roms/u-boot/doc/arch/sh.rst88
-rw-r--r--roms/u-boot/doc/arch/x86.rst765
-rw-r--r--roms/u-boot/doc/arch/xtensa.rst99
-rw-r--r--roms/u-boot/doc/board/AndesTech/adp-ag101p.rst40
-rw-r--r--roms/u-boot/doc/board/AndesTech/ax25-ae350.rst524
-rw-r--r--roms/u-boot/doc/board/AndesTech/index.rst10
-rw-r--r--roms/u-boot/doc/board/actions/cubieboard7.rst114
-rw-r--r--roms/u-boot/doc/board/actions/index.rst10
-rw-r--r--roms/u-boot/doc/board/advantech/imx8qm-rom7720-a1.rst75
-rw-r--r--roms/u-boot/doc/board/advantech/index.rst9
-rw-r--r--roms/u-boot/doc/board/amlogic/beelink-gtking.rst115
-rw-r--r--roms/u-boot/doc/board/amlogic/beelink-gtkingpro.rst116
-rw-r--r--roms/u-boot/doc/board/amlogic/index.rst103
-rw-r--r--roms/u-boot/doc/board/amlogic/khadas-vim.rst101
-rw-r--r--roms/u-boot/doc/board/amlogic/khadas-vim2.rst102
-rw-r--r--roms/u-boot/doc/board/amlogic/khadas-vim3.rst160
-rw-r--r--roms/u-boot/doc/board/amlogic/khadas-vim3l.rst160
-rw-r--r--roms/u-boot/doc/board/amlogic/libretech-ac.rst110
-rw-r--r--roms/u-boot/doc/board/amlogic/libretech-cc.rst146
-rw-r--r--roms/u-boot/doc/board/amlogic/nanopi-k2.rst104
-rw-r--r--roms/u-boot/doc/board/amlogic/odroid-c2.rst63
-rw-r--r--roms/u-boot/doc/board/amlogic/odroid-c4.rst134
-rw-r--r--roms/u-boot/doc/board/amlogic/odroid-n2.rst130
-rw-r--r--roms/u-boot/doc/board/amlogic/p200.rst102
-rw-r--r--roms/u-boot/doc/board/amlogic/p201.rst102
-rw-r--r--roms/u-boot/doc/board/amlogic/p212.rst102
-rw-r--r--roms/u-boot/doc/board/amlogic/q200.rst101
-rw-r--r--roms/u-boot/doc/board/amlogic/s400.rst109
-rw-r--r--roms/u-boot/doc/board/amlogic/sei510.rst130
-rw-r--r--roms/u-boot/doc/board/amlogic/sei610.rst133
-rw-r--r--roms/u-boot/doc/board/amlogic/u200.rst135
-rw-r--r--roms/u-boot/doc/board/amlogic/w400.rst137
-rw-r--r--roms/u-boot/doc/board/amlogic/wetek-core2.rst96
-rw-r--r--roms/u-boot/doc/board/atmel/at91ek.rst192
-rw-r--r--roms/u-boot/doc/board/atmel/index.rst9
-rw-r--r--roms/u-boot/doc/board/congatec/cgtqmx8.rst70
-rw-r--r--roms/u-boot/doc/board/congatec/index.rst9
-rw-r--r--roms/u-boot/doc/board/coreboot/coreboot.rst52
-rw-r--r--roms/u-boot/doc/board/coreboot/index.rst9
-rw-r--r--roms/u-boot/doc/board/emulation/index.rst14
-rw-r--r--roms/u-boot/doc/board/emulation/qemu-arm.rst92
-rw-r--r--roms/u-boot/doc/board/emulation/qemu-mips.rst129
-rw-r--r--roms/u-boot/doc/board/emulation/qemu-ppce500.rst93
-rw-r--r--roms/u-boot/doc/board/emulation/qemu-riscv.rst115
-rw-r--r--roms/u-boot/doc/board/emulation/qemu-x86.rst118
-rw-r--r--roms/u-boot/doc/board/emulation/qemu_capsule_update.rst210
-rw-r--r--roms/u-boot/doc/board/freescale/b4860qds.rst453
-rw-r--r--roms/u-boot/doc/board/freescale/imx8mm_evk.rst57
-rw-r--r--roms/u-boot/doc/board/freescale/imx8mn_evk.rst58
-rw-r--r--roms/u-boot/doc/board/freescale/imx8mp_evk.rst61
-rw-r--r--roms/u-boot/doc/board/freescale/imx8mq_evk.rst56
-rw-r--r--roms/u-boot/doc/board/freescale/imx8qxp_mek.rst66
-rw-r--r--roms/u-boot/doc/board/freescale/imxrt1020-evk.rst41
-rw-r--r--roms/u-boot/doc/board/freescale/imxrt1050-evk.rst41
-rw-r--r--roms/u-boot/doc/board/freescale/index.rst20
-rw-r--r--roms/u-boot/doc/board/freescale/mx6sabreauto.rst100
-rw-r--r--roms/u-boot/doc/board/freescale/mx6sabresd.rst132
-rw-r--r--roms/u-boot/doc/board/freescale/mx6ul_14x14_evk.rst98
-rw-r--r--roms/u-boot/doc/board/freescale/mx6ullevk.rst47
-rw-r--r--roms/u-boot/doc/board/google/chromebook_coral.rst442
-rw-r--r--roms/u-boot/doc/board/google/chromebook_link.rst34
-rw-r--r--roms/u-boot/doc/board/google/chromebook_samus.rst101
-rw-r--r--roms/u-boot/doc/board/google/index.rst11
-rw-r--r--roms/u-boot/doc/board/index.rst29
-rw-r--r--roms/u-boot/doc/board/intel/bayleybay.rst29
-rw-r--r--roms/u-boot/doc/board/intel/cherryhill.rst30
-rw-r--r--roms/u-boot/doc/board/intel/cougarcanyon2.rst24
-rw-r--r--roms/u-boot/doc/board/intel/crownbay.rst43
-rw-r--r--roms/u-boot/doc/board/intel/edison.rst170
-rw-r--r--roms/u-boot/doc/board/intel/galileo.rst22
-rw-r--r--roms/u-boot/doc/board/intel/index.rst16
-rw-r--r--roms/u-boot/doc/board/intel/minnowmax.rst70
-rw-r--r--roms/u-boot/doc/board/intel/slimbootloader.rst177
-rw-r--r--roms/u-boot/doc/board/kontron/index.rst9
-rw-r--r--roms/u-boot/doc/board/kontron/sl28.rst160
-rw-r--r--roms/u-boot/doc/board/microchip/index.rst9
-rw-r--r--roms/u-boot/doc/board/microchip/mpfs_icicle.rst825
-rw-r--r--roms/u-boot/doc/board/rockchip/index.rst10
-rw-r--r--roms/u-boot/doc/board/rockchip/rockchip.rst238
-rw-r--r--roms/u-boot/doc/board/sifive/index.rst10
-rw-r--r--roms/u-boot/doc/board/sifive/unleashed.rst579
-rw-r--r--roms/u-boot/doc/board/sifive/unmatched.rst536
-rw-r--r--roms/u-boot/doc/board/sipeed/index.rst9
-rw-r--r--roms/u-boot/doc/board/sipeed/maix.rst697
-rw-r--r--roms/u-boot/doc/board/st/index.rst9
-rw-r--r--roms/u-boot/doc/board/st/stm32mp1.rst614
-rw-r--r--roms/u-boot/doc/board/tbs/index.rst9
-rw-r--r--roms/u-boot/doc/board/tbs/tbs2910.rst191
-rw-r--r--roms/u-boot/doc/board/toradex/apalix-imx8.rst82
-rw-r--r--roms/u-boot/doc/board/toradex/apalix-imx8x.rst77
-rw-r--r--roms/u-boot/doc/board/toradex/colibri-imx8x.rst82
-rw-r--r--roms/u-boot/doc/board/toradex/colibri_imx7.rst126
-rw-r--r--roms/u-boot/doc/board/toradex/index.rst13
-rw-r--r--roms/u-boot/doc/board/toradex/verdin-imx8mm.rst98
-rw-r--r--roms/u-boot/doc/board/xen/index.rst9
-rw-r--r--roms/u-boot/doc/board/xen/xenguest_arm64.rst81
-rw-r--r--roms/u-boot/doc/board/xilinx/index.rst12
-rw-r--r--roms/u-boot/doc/board/xilinx/xilinx.rst48
-rw-r--r--roms/u-boot/doc/board/xilinx/zynq.rst110
-rw-r--r--roms/u-boot/doc/board/xilinx/zynqmp-r5.rst137
-rw-r--r--roms/u-boot/doc/board/xilinx/zynqmp.rst115
-rw-r--r--roms/u-boot/doc/bounces3
-rw-r--r--roms/u-boot/doc/build/clang.rst76
-rw-r--r--roms/u-boot/doc/build/docker.rst14
-rw-r--r--roms/u-boot/doc/build/gcc.rst139
-rw-r--r--roms/u-boot/doc/build/index.rst13
-rw-r--r--roms/u-boot/doc/build/source.rst30
-rw-r--r--roms/u-boot/doc/build/tools.rst47
-rw-r--r--roms/u-boot/doc/chromium/chainload.rst257
-rw-r--r--roms/u-boot/doc/chromium/files/chromebook_jerry.its42
-rw-r--r--roms/u-boot/doc/chromium/files/devkeys/kernel.keyblockbin0 -> 1208 bytes
-rw-r--r--roms/u-boot/doc/chromium/files/devkeys/kernel_data_key.vbprivkbin0 -> 1199 bytes
-rw-r--r--roms/u-boot/doc/chromium/files/nyan-big.its42
-rw-r--r--roms/u-boot/doc/chromium/index.rst14
-rw-r--r--roms/u-boot/doc/chromium/overview.rst74
-rw-r--r--roms/u-boot/doc/chromium/run_vboot.rst204
-rw-r--r--roms/u-boot/doc/conf.py644
-rw-r--r--roms/u-boot/doc/develop/coccinelle.rst505
-rw-r--r--roms/u-boot/doc/develop/commands.rst226
-rw-r--r--roms/u-boot/doc/develop/crash_dumps.rst124
-rw-r--r--roms/u-boot/doc/develop/driver-model/bind.rst49
-rw-r--r--roms/u-boot/doc/develop/driver-model/debugging.rst62
-rw-r--r--roms/u-boot/doc/develop/driver-model/design.rst1149
-rw-r--r--roms/u-boot/doc/develop/driver-model/ethernet.rst321
-rw-r--r--roms/u-boot/doc/develop/driver-model/fdt-fixup.rst132
-rw-r--r--roms/u-boot/doc/develop/driver-model/fs_firmware_loader.rst154
-rw-r--r--roms/u-boot/doc/develop/driver-model/i2c-howto.rst56
-rw-r--r--roms/u-boot/doc/develop/driver-model/index.rst31
-rw-r--r--roms/u-boot/doc/develop/driver-model/livetree.rst286
-rw-r--r--roms/u-boot/doc/develop/driver-model/migration.rst109
-rw-r--r--roms/u-boot/doc/develop/driver-model/nvme.rst97
-rw-r--r--roms/u-boot/doc/develop/driver-model/of-plat.rst913
-rw-r--r--roms/u-boot/doc/develop/driver-model/pci-info.rst172
-rw-r--r--roms/u-boot/doc/develop/driver-model/pmic-framework.rst143
-rw-r--r--roms/u-boot/doc/develop/driver-model/remoteproc-framework.rst169
-rw-r--r--roms/u-boot/doc/develop/driver-model/serial-howto.rst46
-rw-r--r--roms/u-boot/doc/develop/driver-model/soc-framework.rst68
-rw-r--r--roms/u-boot/doc/develop/driver-model/spi-howto.rst692
-rw-r--r--roms/u-boot/doc/develop/driver-model/usb-info.rst423
-rw-r--r--roms/u-boot/doc/develop/driver-model/virtio.rst287
-rw-r--r--roms/u-boot/doc/develop/global_data.rst55
-rw-r--r--roms/u-boot/doc/develop/index.rst47
-rw-r--r--roms/u-boot/doc/develop/logging.rst319
-rw-r--r--roms/u-boot/doc/develop/menus.rst131
l---------roms/u-boot/doc/develop/package/binman.rst1
l---------roms/u-boot/doc/develop/package/entries.rst1
-rw-r--r--roms/u-boot/doc/develop/package/index.rst19
-rw-r--r--roms/u-boot/doc/develop/py_testing.rst427
-rw-r--r--roms/u-boot/doc/develop/testing.rst126
-rw-r--r--roms/u-boot/doc/develop/tests_sandbox.rst209
-rw-r--r--roms/u-boot/doc/develop/tests_writing.rst346
-rw-r--r--roms/u-boot/doc/develop/trace.rst355
-rw-r--r--roms/u-boot/doc/develop/uefi/index.rst15
-rw-r--r--roms/u-boot/doc/develop/uefi/iscsi.rst184
-rw-r--r--roms/u-boot/doc/develop/uefi/u-boot_on_efi.rst235
-rw-r--r--roms/u-boot/doc/develop/uefi/uefi.rst574
-rw-r--r--roms/u-boot/doc/develop/version.rst101
-rw-r--r--roms/u-boot/doc/device-tree-bindings/README17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/adc/adc.txt62
-rw-r--r--roms/u-boot/doc/device-tree-bindings/adc/st,stm32-adc.txt141
-rw-r--r--roms/u-boot/doc/device-tree-bindings/arm/arm,scmi.txt231
-rw-r--r--roms/u-boot/doc/device-tree-bindings/arm/l2c2x0.txt114
-rw-r--r--roms/u-boot/doc/device-tree-bindings/ata/intel-sata.txt26
-rw-r--r--roms/u-boot/doc/device-tree-bindings/axi/gdsys,ihs_axi.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/bus/simple-pm-bus.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/chosen.txt163
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/fixed-factor-clock.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/fsl,mpc83xx-clk.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/microchip,pic32-clock.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt207
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3188-cru.txt61
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-cru.txt61
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-dmc.txt155
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt67
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3399-dmc.txt42
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/rockchip.txt77
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/snps,hsdk-cgu.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/st,stm32-rcc.txt95
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/st,stm32h7-rcc.txt152
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/st,stm32mp1.txt405
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/ti,cdce9xx.txt49
-rw-r--r--roms/u-boot/doc/device-tree-bindings/clock/ti,sci-clk.txt53
-rw-r--r--roms/u-boot/doc/device-tree-bindings/config.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/cpu/fsl,mpc83xx.txt34
-rw-r--r--roms/u-boot/doc/device-tree-bindings/cpu/nios2.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/device.txt75
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/emmc-reset.txt15
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/soc.txt21
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/sound.txt27
-rw-r--r--roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/firmware/linaro,optee-tz.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/firmware/nvidia,tegra186-bpmp.txt104
-rw-r--r--roms/u-boot/doc/device-tree-bindings/firmware/ti,sci.txt76
-rw-r--r--roms/u-boot/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt43
-rw-r--r--roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt327
-rw-r--r--roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt490
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt28
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt5
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt71
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt41
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt324
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt55
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt208
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt45
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt161
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt40
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt48
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt43
-rw-r--r--roms/u-boot/doc/device-tree-bindings/gpu/nvidia,tegra20-host1x.txt372
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/generic-acpi.txt42
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-at91.txt26
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-cdns.txt20
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-cortina.txt18
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-designware.txt73
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-gpio.txt41
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-mux.txt60
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c-stm32.txt30
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/i2c.txt46
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/nvidia,tegra186-bpmp-i2c.txt42
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/nx_i2c.txt28
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/octeon-i2c.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/input/adc-keys.txt67
-rw-r--r--roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt72
-rw-r--r--roms/u-boot/doc/device-tree-bindings/input/hid-over-i2c.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/input/i8042.txt10
-rw-r--r--roms/u-boot/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt30
-rw-r--r--roms/u-boot/doc/device-tree-bindings/interrupt-controller/interrupts.txt131
-rw-r--r--roms/u-boot/doc/device-tree-bindings/leds/common.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6328.txt106
-rw-r--r--roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6358.txt141
-rw-r--r--roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6858.txt51
-rw-r--r--roms/u-boot/doc/device-tree-bindings/leds/leds-gpio.txt52
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt40
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mailbox/mailbox.txt32
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mailbox/nvidia,tegra186-hsp.txt52
-rw-r--r--roms/u-boot/doc/device-tree-bindings/memory-controller/k3-j721e-ddrss.txt2242
-rw-r--r--roms/u-boot/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt46
-rw-r--r--roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt58
-rw-r--r--roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt301
-rw-r--r--roms/u-boot/doc/device-tree-bindings/memory/memory.txt67
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mfd/kendryte,k210-sysctl.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/altera_sysid.txt4
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/bootcounter.txt21
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt38
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/esm-k3.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/esm-pmic.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/fs_loader.txt48
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt155
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/intel,irq-router.txt61
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/intel-lpc.txt64
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/misc/fsl,mpc83xx-serdes.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,io-endpoint.txt20
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocon_fpga.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocpu_fpga.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,soc.txt16
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mmc/msm_sdhci.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mmc/snps,dw-mmc.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mtd/altera_qspi.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mtd/mtd-physmap.txt88
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mtd/spi-nand.txt5
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mtd/spi/spi-flash.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt61
-rw-r--r--roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt53
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt27
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt27
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/altera_tse.txt112
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/aquantia-phy.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/ethernet.txt66
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/fixed-link.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-dma-fec.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-fec.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/fsl-tsec-phy.txt81
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/marvell-mdio.txt15
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/mdio-mux-reg.txt82
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/mdio-mux.txt138
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/mdio.txt36
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/micrel-ksz90x1.txt192
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/phy.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/phy/atheros.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt166
-rw-r--r--roms/u-boot/doc/device-tree-bindings/net/stmmac.txt63
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pci/armada8k-pcie.txt49
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pci/mediatek-pcie.txt122
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pci/x86-pci.txt47
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt18
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/mvebu_comphy.txt68
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/no-op.txt16
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/phy-mtk-tphy.txt144
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/phy-stih407-usb.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt75
-rw-r--r--roms/u-boot/doc/device-tree-bindings/phy/sun4i-usb-phy.txt65
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt69
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/bcm6838-pinctrl.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt39
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/kendryte,k210-fpioa.txt102
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt186
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt270
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt113
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt78
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt289
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/rockchip,pinctrl.txt157
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt208
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pmic/max77686.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pmic/pm8916.txt18
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pmic/rn5t567.txt17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pmic/s2mps11.txt17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pmic/sandbox.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/power/ti,sci-pm-domain.txt59
-rw-r--r--roms/u-boot/doc/device-tree-bindings/power/tps65090.txt17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pwm/cros-ec-pwm.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pwm/pwm-sifive.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pwm/pwm.txt69
-rw-r--r--roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt18
-rw-r--r--roms/u-boot/doc/device-tree-bindings/ram/fsl,mpc83xx-mem-controller.txt314
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/fan53555.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/fixed.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt45
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/max77686.txt70
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/regulator.txt92
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/sandbox.txt45
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/st,stm32-vrefbuf.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/regulator/tps65090.txt122
-rw-r--r--roms/u-boot/doc/device-tree-bindings/remoteproc/k3-rproc.txt50
-rw-r--r--roms/u-boot/doc/device-tree-bindings/remoteproc/k3-system-controller.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/remoteproc/remoteproc.txt14
-rw-r--r--roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt101
-rw-r--r--roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt167
-rw-r--r--roms/u-boot/doc/device-tree-bindings/reserved-memory/reserved-memory.txt136
-rw-r--r--roms/u-boot/doc/device-tree-bindings/reset/reset.txt75
-rw-r--r--roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt6
-rw-r--r--roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt36
-rw-r--r--roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/root.txt4
-rw-r--r--roms/u-boot/doc/device-tree-bindings/rtc/abracon,abx80x.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/rtc/ds3232.txt15
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/8250.txt66
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/altera_jtaguart.txt4
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/altera_uart.txt7
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/bcm2835-aux-uart.txt10
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/mcf-uart.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/microchip,pic32-uart.txt5
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/msm-serial.txt10
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/mxc-serial.txt8
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/omap_serial.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/pl01x.txt10
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/qca,ar9330-uart.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/sandbox-serial.txt13
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/sh.txt6
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt76
-rw-r--r--roms/u-boot/doc/device-tree-bindings/serial/xilinx_uartlite.txt13
-rw-r--r--roms/u-boot/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt53
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sound/da7219.txt113
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sound/intel-hda.txt26
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sound/max98357a.txt22
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt54
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sound/snow.txt32
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt56
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/soft-spi.txt38
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-atcspi200.txt37
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-ath79.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt94
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-cadence.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-mcf-dspi.txt34
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-qup.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-stm32-qspi.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-zynq-qspi.txt26
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi-zynq.txt32
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spi/spi_altera.txt4
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spmi/spmi-msm.txt26
-rw-r--r--roms/u-boot/doc/device-tree-bindings/spmi/spmi-sandbox.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysinfo/gdsys,sysinfo_gazerbeam.txt46
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysinfo/google,coral.txt37
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysinfo/gpio-sysinfo.txt37
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysinfo/smbios.txt77
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysinfo/sysinfo.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt29
-rw-r--r--roms/u-boot/doc/device-tree-bindings/thermal/rockchip-thermal.txt68
-rw-r--r--roms/u-boot/doc/device-tree-bindings/thermal/ti_soc_thermal.txt35
-rw-r--r--roms/u-boot/doc/device-tree-bindings/timer/altera_timer.txt19
-rw-r--r--roms/u-boot/doc/device-tree-bindings/timer/arc_timer.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/timer/atcpit100_timer.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/timer/fsl,mpc83xx-timer.txt21
-rw-r--r--roms/u-boot/doc/device-tree-bindings/timer/sandbox_timer.txt7
-rw-r--r--roms/u-boot/doc/device-tree-bindings/tpm2/sandbox.txt11
-rw-r--r--roms/u-boot/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt18
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/dwc2.txt58
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/dwc3-st.txt60
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/ehci-msm.txt10
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/generic.txt31
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/marvell.xhci-usb.txt28
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt44
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtu3.txt79
-rw-r--r--roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/atmel-hlcdc.txt42
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/bridge/ps8622.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/display-timing.txt110
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/displaymode.txt42
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt69
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt100
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt82
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/intel-gma.txt40
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt23
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/rockchip-lvds.txt77
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt17
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt25
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/syncoam,seps525.txt24
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt85
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/tilcdc/panel.txt66
-rw-r--r--roms/u-boot/doc/device-tree-bindings/video/tilcdc/tilcdc.txt82
-rw-r--r--roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds24xxx.txt37
-rw-r--r--roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds2502.txt33
-rw-r--r--roms/u-boot/doc/device-tree-bindings/w1-eeprom/eep_sandbox.txt34
-rw-r--r--roms/u-boot/doc/device-tree-bindings/w1/mxc-w1.txt37
-rw-r--r--roms/u-boot/doc/device-tree-bindings/w1/w1-gpio.txt40
-rw-r--r--roms/u-boot/doc/feature-removal-schedule.txt31
-rw-r--r--roms/u-boot/doc/git-mailrc134
-rw-r--r--roms/u-boot/doc/imx/ahab/csf_examples/csf_enc_boot_image.txt27
-rw-r--r--roms/u-boot/doc/imx/ahab/guides/mx8_mx8x_encrypted_boot.txt293
-rw-r--r--roms/u-boot/doc/imx/clk/ccf.txt102
-rw-r--r--roms/u-boot/doc/imx/common/imx25.txt10
-rw-r--r--roms/u-boot/doc/imx/common/imx27.txt10
-rw-r--r--roms/u-boot/doc/imx/common/imx5.txt40
-rw-r--r--roms/u-boot/doc/imx/common/imx6.txt164
-rw-r--r--roms/u-boot/doc/imx/common/mxs.txt290
-rw-r--r--roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt34
-rw-r--r--roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt32
-rw-r--r--roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt23
-rw-r--r--roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt43
-rw-r--r--roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt427
-rw-r--r--roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt181
-rw-r--r--roms/u-boot/doc/imx/habv4/introduction_habv4.txt262
-rw-r--r--roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl12
-rw-r--r--roms/u-boot/doc/imx/index.rst9
-rw-r--r--roms/u-boot/doc/imx/misc/index.rst9
-rw-r--r--roms/u-boot/doc/imx/misc/psb.rst174
-rw-r--r--roms/u-boot/doc/imx/misc/sdp.txt118
-rw-r--r--roms/u-boot/doc/imx/mkimage/imx8image.txt45
-rw-r--r--roms/u-boot/doc/imx/mkimage/imximage.txt239
-rw-r--r--roms/u-boot/doc/imx/mkimage/mxsimage.txt170
-rw-r--r--roms/u-boot/doc/index.rst112
-rw-r--r--roms/u-boot/doc/kwboot.184
-rw-r--r--roms/u-boot/doc/media/Makefile38
-rw-r--r--roms/u-boot/doc/media/linker_lists.h.rst.exceptions0
-rw-r--r--roms/u-boot/doc/mkimage.1242
-rw-r--r--roms/u-boot/doc/mvebu/armada-8k-memory.txt56
-rw-r--r--roms/u-boot/doc/mvebu/cmd/bubt.txt55
-rw-r--r--roms/u-boot/doc/sphinx-static/theme_overrides.css89
-rw-r--r--roms/u-boot/doc/sphinx/automarkup.py290
-rw-r--r--roms/u-boot/doc/sphinx/cdomain.py259
-rw-r--r--roms/u-boot/doc/sphinx/kernel_abi.py194
-rw-r--r--roms/u-boot/doc/sphinx/kernel_feat.py169
-rwxr-xr-xroms/u-boot/doc/sphinx/kernel_include.py190
-rw-r--r--roms/u-boot/doc/sphinx/kerneldoc.py190
-rw-r--r--roms/u-boot/doc/sphinx/kernellog.py32
-rw-r--r--roms/u-boot/doc/sphinx/kfigure.py557
-rw-r--r--roms/u-boot/doc/sphinx/load_config.py57
-rwxr-xr-xroms/u-boot/doc/sphinx/maintainers_include.py197
-rw-r--r--roms/u-boot/doc/sphinx/parallel-wrapper.sh33
-rwxr-xr-xroms/u-boot/doc/sphinx/parse-headers.pl401
-rw-r--r--roms/u-boot/doc/sphinx/requirements.txt4
-rwxr-xr-xroms/u-boot/doc/sphinx/rstFlatTable.py374
-rw-r--r--roms/u-boot/doc/uImage.FIT/beaglebone_vboot.txt607
-rw-r--r--roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt201
-rw-r--r--roms/u-boot/doc/uImage.FIT/howto.txt405
-rw-r--r--roms/u-boot/doc/uImage.FIT/kernel.its91
-rw-r--r--roms/u-boot/doc/uImage.FIT/kernel_fdt.its51
-rw-r--r--roms/u-boot/doc/uImage.FIT/kernel_fdts_compressed.its73
-rw-r--r--roms/u-boot/doc/uImage.FIT/multi-with-fpga.its68
-rw-r--r--roms/u-boot/doc/uImage.FIT/multi-with-loadables.its89
-rw-r--r--roms/u-boot/doc/uImage.FIT/multi.its133
-rw-r--r--roms/u-boot/doc/uImage.FIT/multi_spl.its96
-rw-r--r--roms/u-boot/doc/uImage.FIT/overlay-fdt-boot.txt225
-rw-r--r--roms/u-boot/doc/uImage.FIT/sec_firmware_ppa.its49
-rw-r--r--roms/u-boot/doc/uImage.FIT/sign-configs.its45
-rw-r--r--roms/u-boot/doc/uImage.FIT/sign-images.its42
-rw-r--r--roms/u-boot/doc/uImage.FIT/signature.txt682
-rw-r--r--roms/u-boot/doc/uImage.FIT/source_file_format.txt311
-rw-r--r--roms/u-boot/doc/uImage.FIT/uefi.its67
-rw-r--r--roms/u-boot/doc/uImage.FIT/update3.its44
-rw-r--r--roms/u-boot/doc/uImage.FIT/update_uboot.its24
-rw-r--r--roms/u-boot/doc/uImage.FIT/verified-boot.txt104
-rw-r--r--roms/u-boot/doc/uImage.FIT/x86-fit-boot.txt272
-rw-r--r--roms/u-boot/doc/usage/addrmap.rst41
-rw-r--r--roms/u-boot/doc/usage/askenv.rst87
-rw-r--r--roms/u-boot/doc/usage/base.rst23
-rw-r--r--roms/u-boot/doc/usage/bootefi.rst135
-rw-r--r--roms/u-boot/doc/usage/booti.rst114
-rw-r--r--roms/u-boot/doc/usage/bootmenu.rst95
-rw-r--r--roms/u-boot/doc/usage/button.rst64
-rw-r--r--roms/u-boot/doc/usage/conitrace.rst54
-rw-r--r--roms/u-boot/doc/usage/dfu.rst404
-rw-r--r--roms/u-boot/doc/usage/echo.rst65
-rw-r--r--roms/u-boot/doc/usage/exception.rst66
-rw-r--r--roms/u-boot/doc/usage/exit.rst40
-rw-r--r--roms/u-boot/doc/usage/extension.rst111
-rw-r--r--roms/u-boot/doc/usage/false.rst28
-rw-r--r--roms/u-boot/doc/usage/fatinfo.rst51
-rw-r--r--roms/u-boot/doc/usage/fdt_overlays.rst134
-rw-r--r--roms/u-boot/doc/usage/fit.rst8
-rw-r--r--roms/u-boot/doc/usage/for.rst65
-rw-r--r--roms/u-boot/doc/usage/index.rst48
-rw-r--r--roms/u-boot/doc/usage/load.rst74
-rw-r--r--roms/u-boot/doc/usage/loady.rst67
-rw-r--r--roms/u-boot/doc/usage/mbr.rst94
-rw-r--r--roms/u-boot/doc/usage/md.rst106
-rw-r--r--roms/u-boot/doc/usage/mmc.rst215
-rw-r--r--roms/u-boot/doc/usage/netconsole.rst109
-rw-r--r--roms/u-boot/doc/usage/partitions.rst80
-rw-r--r--roms/u-boot/doc/usage/pinmux.rst95
-rw-r--r--roms/u-boot/doc/usage/pstore.rst93
-rw-r--r--roms/u-boot/doc/usage/qfw.rst89
-rw-r--r--roms/u-boot/doc/usage/reset.rst26
-rw-r--r--roms/u-boot/doc/usage/sbi.rst49
-rw-r--r--roms/u-boot/doc/usage/scp03.rst33
-rw-r--r--roms/u-boot/doc/usage/size.rst40
-rw-r--r--roms/u-boot/doc/usage/true.rst28
-rw-r--r--roms/u-boot/doc/usage/ums.rst57
-rw-r--r--roms/u-boot/doc/usage/x86/cbsysinfo.rst25
691 files changed, 72501 insertions, 0 deletions
diff --git a/roms/u-boot/doc/.gitignore b/roms/u-boot/doc/.gitignore
new file mode 100644
index 000000000..53752db25
--- /dev/null
+++ b/roms/u-boot/doc/.gitignore
@@ -0,0 +1 @@
+output
diff --git a/roms/u-boot/doc/I2C_Edge_Conditions b/roms/u-boot/doc/I2C_Edge_Conditions
new file mode 100644
index 000000000..f4a996870
--- /dev/null
+++ b/roms/u-boot/doc/I2C_Edge_Conditions
@@ -0,0 +1,46 @@
+I2C Edge Conditions:
+====================
+
+ I2C devices may be left in a write state if a read was occuring
+ and the CPU was reset. This may result in EEPROM data corruption.
+
+ The edge condition is as follows:
+ 1) A read operation begins.
+ 2) I2C controller issues a start command.
+ 3) The I2C writes the device address.
+ 4) The CPU is reset at this point.
+
+ Once the CPU reinitializes and the read is tried again:
+ 1) The I2C controller issues a start command.
+ 2) The I2C controller writes the device address.
+ 3) The I2C controller writes the offset.
+
+ The EEPROM sees:
+ 1) START
+ 2) device address
+ 3) START "this start is ignored by most EEPROMs"
+ 4) device address "EEPROM interprets this as offset"
+ 5) Offset in device, "EEPROM interprets this as data to write"
+
+ The device will interpret this sequence as a WRITE command and
+ write rubbish into itself, i.e. the "offset" will be interpreted
+ as data to be written in location "device address".
+
+Notes
+-----
+!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A AMCC 4xx BUG!!!
+
+This reset edge condition could possibly be present in every I2C
+controller and device available. For boards where a I2C bus reset
+function can be implemented a i2c_init_board() function should be
+provided and enabled by #define'ing CONFIG_SYS_I2C_INIT_BOARD in your
+board's config file. Note that this is NOT necessary when using the
+bit-banging I2C driver (common/soft_i2c.c) as this already includes
+the I2C bus reset sequence.
+
+
+Many thanks to Bill Hunter for finding this serious BUG.
+email to: <williamhunter@attbi.com>
+
+Erik Theisen <etheisen@mindspring.com>
+Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET)
diff --git a/roms/u-boot/doc/Makefile b/roms/u-boot/doc/Makefile
new file mode 100644
index 000000000..683e4b560
--- /dev/null
+++ b/roms/u-boot/doc/Makefile
@@ -0,0 +1,124 @@
+# -*- makefile -*-
+# Makefile for Sphinx documentation
+#
+
+subdir-y :=
+
+# You can set these variables from the command line.
+SPHINXBUILD = sphinx-build
+SPHINXOPTS =
+SPHINXDIRS = .
+_SPHINXDIRS = $(patsubst $(srctree)/doc/%/conf.py,%,$(wildcard $(srctree)/doc/*/conf.py))
+SPHINX_CONF = conf.py
+PAPER =
+BUILDDIR = $(obj)/output
+PDFLATEX = xelatex
+LATEXOPTS = -interaction=batchmode
+
+# User-friendly check for sphinx-build
+HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi)
+
+ifeq ($(HAVE_SPHINX),0)
+
+.DEFAULT:
+ $(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
+ @echo
+ @./scripts/sphinx-pre-install
+ @echo " SKIP Sphinx $@ target."
+
+else # HAVE_SPHINX
+
+# User-friendly check for pdflatex
+HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; else echo 0; fi)
+
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+KERNELDOC = $(srctree)/scripts/kernel-doc
+KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC)
+ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS)
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+# commands; the 'cmd' from scripts/Kbuild.include is not *loopable*
+loop_cmd = $(echo-cmd) $(cmd_$(1)) || exit;
+
+# $2 sphinx builder e.g. "html"
+# $3 name of the build subfolder / e.g. "media", used as:
+# * dest folder relative to $(BUILDDIR) and
+# * cache folder relative to $(BUILDDIR)/.doctrees
+# $4 dest subfolder e.g. "man" for man pages at media/man
+# $5 reST source folder relative to $(srctree)/$(src),
+# e.g. "media" for the linux-tv book-set at ./doc/media
+
+quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
+ cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=doc/media $2 && \
+ PYTHONDONTWRITEBYTECODE=1 \
+ BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
+ $(SPHINXBUILD) \
+ -b $2 \
+ -c $(abspath $(srctree)/$(src)) \
+ -d $(abspath $(BUILDDIR)/.doctrees/$3) \
+ -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
+ $(ALLSPHINXOPTS) \
+ $(abspath $(srctree)/$(src)/$5) \
+ $(abspath $(BUILDDIR)/$3/$4)
+
+htmldocs:
+ @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
+
+linkcheckdocs:
+ @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,linkcheck,$(var),,$(var)))
+
+latexdocs:
+ @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,latex,$(var),latex,$(var)))
+
+ifeq ($(HAVE_PDFLATEX),0)
+
+pdfdocs:
+ $(warning The '$(PDFLATEX)' command was not found. Make sure you have it installed and in PATH to produce PDF output.)
+ @echo " SKIP Sphinx $@ target."
+
+else # HAVE_PDFLATEX
+
+pdfdocs: latexdocs
+ $(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX=$(PDFLATEX) LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
+
+endif # HAVE_PDFLATEX
+
+epubdocs:
+ @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var)))
+
+xmldocs:
+ @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,xml,$(var),xml,$(var)))
+
+endif # HAVE_SPHINX
+
+# The following targets are independent of HAVE_SPHINX, and the rules should
+# work or silently pass without Sphinx.
+
+refcheckdocs:
+ $(Q)cd $(srctree);scripts/documentation-file-ref-check
+
+cleandocs:
+ $(Q)rm -rf $(BUILDDIR)
+ $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=doc/media clean
+
+dochelp:
+ @echo ' U-Boot documentation in different formats from ReST:'
+ @echo ' htmldocs - HTML'
+ @echo ' latexdocs - LaTeX'
+ @echo ' pdfdocs - PDF'
+ @echo ' epubdocs - EPUB'
+ @echo ' xmldocs - XML'
+ @echo ' linkcheckdocs - check for broken external links (will connect to external hosts)'
+ @echo ' refcheckdocs - check for references to non-existing files under Documentation'
+ @echo ' cleandocs - clean all generated files'
+ @echo
+ @echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2'
+ @echo ' valid values for SPHINXDIRS are: $(_SPHINXDIRS)'
+ @echo
+ @echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build'
+ @echo ' configuration. This is e.g. useful to build with nit-picking config.'
+ @echo
+ @echo ' Default location for the generated documents is doc/output'
diff --git a/roms/u-boot/doc/README.440-DDR-performance b/roms/u-boot/doc/README.440-DDR-performance
new file mode 100644
index 000000000..66b97bc9b
--- /dev/null
+++ b/roms/u-boot/doc/README.440-DDR-performance
@@ -0,0 +1,90 @@
+AMCC suggested to set the PMU bit to 0 for best performace on the
+PPC440 DDR controller. The 440er common DDR setup files (sdram.c &
+spd_sdram.c) are changed accordingly. So all 440er boards using
+these setup routines will automatically receive this performance
+increase.
+
+Please see below some benchmarks done by AMCC to demonstrate this
+performance changes:
+
+
+----------------------------------------
+SDRAM0_CFG0[PMU] = 1 (U-Boot default for Bamboo, Yosemite and Yellowstone)
+----------------------------------------
+Stream benchmark results
+-------------------------------------------------------------
+This system uses 8 bytes per DOUBLE PRECISION word.
+-------------------------------------------------------------
+Array size = 2000000, Offset = 0
+Total memory required = 45.8 MB.
+Each test is run 10 times, but only
+the *best* time for each is used.
+-------------------------------------------------------------
+Your clock granularity/precision appears to be 1 microseconds.
+Each test below will take on the order of 112345 microseconds.
+ (= 112345 clock ticks)
+Increase the size of the arrays if this shows that you are not getting
+at least 20 clock ticks per test.
+-------------------------------------------------------------
+WARNING -- The above is only a rough guideline.
+For best results, please be sure you know the precision of your system
+timer.
+-------------------------------------------------------------
+Function Rate (MB/s) RMS time Min time Max time
+Copy: 256.7683 0.1248 0.1246 0.1250
+Scale: 246.0157 0.1302 0.1301 0.1302
+Add: 255.0316 0.1883 0.1882 0.1885
+Triad: 253.1245 0.1897 0.1896 0.1899
+
+
+TTCP Benchmark Results
+ttcp-t: socket
+ttcp-t: connect
+ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp ->
+localhost
+ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++
+ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57
+ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw
+
+----------------------------------------
+SDRAM0_CFG0[PMU] = 0 (Suggested modification)
+Setting PMU = 0 provides a noticeable performance improvement *2% to
+5% improvement in memory performance.
+*Improves the Mbit/sec for TTCP benchmark by almost 76%.
+----------------------------------------
+Stream benchmark results
+-------------------------------------------------------------
+This system uses 8 bytes per DOUBLE PRECISION word.
+-------------------------------------------------------------
+Array size = 2000000, Offset = 0
+Total memory required = 45.8 MB.
+Each test is run 10 times, but only
+the *best* time for each is used.
+-------------------------------------------------------------
+Your clock granularity/precision appears to be 1 microseconds.
+Each test below will take on the order of 120066 microseconds.
+ (= 120066 clock ticks)
+Increase the size of the arrays if this shows that you are not getting
+at least 20 clock ticks per test.
+-------------------------------------------------------------
+WARNING -- The above is only a rough guideline.
+For best results, please be sure you know the precision of your system
+timer.
+-------------------------------------------------------------
+Function Rate (MB/s) RMS time Min time Max time
+Copy: 262.5167 0.1221 0.1219 0.1223
+Scale: 258.4856 0.1238 0.1238 0.1240
+Add: 262.5404 0.1829 0.1828 0.1831
+Triad: 266.8594 0.1800 0.1799 0.1802
+
+TTCP Benchmark Results
+ttcp-t: socket
+ttcp-t: connect
+ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp ->
+localhost
+ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++
+ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89
+ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw
+
+
+2006-07-28, Stefan Roese <sr@denx.de>
diff --git a/roms/u-boot/doc/README.AMCC-eval-boards-cleanup b/roms/u-boot/doc/README.AMCC-eval-boards-cleanup
new file mode 100644
index 000000000..901bd875c
--- /dev/null
+++ b/roms/u-boot/doc/README.AMCC-eval-boards-cleanup
@@ -0,0 +1,31 @@
+---------------------------------------------------------------------
+Cleanup of AMCC eval boards (Walnut/Sycamore, Bubinga, Ebony, Ocotea)
+---------------------------------------------------------------------
+
+Changes to all AMCC eval boards:
+--------------------------------
+
+o Changed u-boot image size to 256 kBytes instead of 512 kBytes on most
+ boards.
+
+o Use 115200 baud as default console baudrate.
+
+o Added config option to use redundant environment in flash. This is also
+ the default setting. Option for environment in nvram is still available
+ for backward compatibility.
+
+o Merged board specific flash drivers to common flash driver:
+ board/amcc/common/flash.c
+
+
+Sycamore/Walnut (one port supporting both eval boards):
+-------------------------------------------------------
+
+o Cleanup to allow easier "cloning" for different (custom) boards:
+
+ o Moved EBC configuration from board specific asm-file "init.S"
+ using defines in board configuration file. No board specific
+ asm file needed anymore.
+
+
+August 01 2005, Stefan Roese <sr@denx.de>
diff --git a/roms/u-boot/doc/README.Heterogeneous-SoCs b/roms/u-boot/doc/README.Heterogeneous-SoCs
new file mode 100644
index 000000000..9da652e45
--- /dev/null
+++ b/roms/u-boot/doc/README.Heterogeneous-SoCs
@@ -0,0 +1,105 @@
+DSP side awareness for Freescale heterogeneous multicore chips based on
+StarCore and Power Architecture
+===============================================================
+powerpc/mpc85xx code ve APIs and function to get the number,
+configuration and frequencies of all PowerPC cores and devices
+connected to them, but it didnt have the similar code ofr HEterogeneous
+SC3900/DSP cores and such devices like CPRI, MAPLE, MAPLE-ULB etc.
+
+Code for DSP side awareness provides such functionality for Freescale
+Heterogeneous SoCs which are chasis-2 compliant like B4860 and B4420
+
+As part of this feature, following changes have been made:
+==========================================================
+
+1. Changed files:
+=================
+- arch/powerpc/cpu/mpc85xx/cpu.c
+
+Code added in this file to print the DSP cores and other device's(CPRI,
+MAPLE etc) frequencies
+
+- arch/powerpc/cpu/mpc85xx/speed.c
+
+Added Defines and code to extract the frequncy information for all
+required cores and devices from RCW and System frequency
+
+- arch/powerpc/cpu/mpc8xxx/cpu.c
+
+Added API to get the number of SC cores in running system and Their BIT
+MASK, similar to the code written for PowerPC
+
+- arch/powerpc/include/asm/config_mpc85xx.h
+
+Added top level CONFIG to identify presence of HETEROGENUOUS clusters
+in the system and CONFIGS for SC3900/DSP components
+
+- arch/powerpc/include/asm/processor.h
+- include/common.h
+
+Added newly added Functions Declaration
+
+- include/e500.h
+
+Global structure updated for dsp cores and other components
+
+2. CONFIGs ADDED
+================
+
+CONFIG_HETROGENOUS_CLUSTERS - Define for checking the presence of
+ DSP/SC3900 core clusters
+
+CONFIG_SYS_FSL_NUM_CC_PLLS - Define for number of PLLs
+
+Though there are only 4 PLLs in B4, but in sequence of PLLs from PLL1 -
+PLL5, PLL3 is Reserved(as mentioned in RM), so this define contains the
+value as 5 not 4, to iterate over all PLLs while coding
+
+CONFIG_SYS_MAPLE - Define for MAPLE Baseband Accelerator
+CONFIG_SYS_CPRI - Define for CPRI Interface
+CONFIG_PPC_CLUSTER_START - Start index of ppc clusters
+CONFIG_DSP_CLUSTER_START - Start index of dsp clusters
+
+Following are the defines for PLL's index that provide the Clocking to
+CPRI, ULB and ETVE components
+
+CONFIG_SYS_CPRI_CLK - Define PLL index for CPRI clock
+CONFIG_SYS_ULB_CLK - Define PLL index for ULB clock
+CONFIG_SYS_ETVPE_CLK - Define PLL index for ETVPE clock
+
+3. Changes in MPC85xx_SYS_INFO Global structure
+===============================================
+
+DSP cores and other device's components have been added in this structure.
+
+freq_processor_dsp[CONFIG_MAX_DSP_CPUS] - Array to contain the DSP core's frequencies
+freq_cpri - To store CPRI frequency
+freq_maple - To store MAPLE frequency
+freq_maple_ulb - To store MAPLE-ULB frequency
+freq_maple_etvpe - To store MAPLE-eTVPE frequency
+
+4. U-BOOT LOGS
+==============
+4.1 B4860QDS board
+ Boot from NOR flash
+
+U-Boot 2014.07-00222-g70587a8-dirty (Aug 07 2014 - 13:15:47)
+
+CPU0: B4860E, Version: 2.0, (0x86880020)
+Core: e6500, Version: 2.0, (0x80400020) Clock Configuration:
+ CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
+ DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200 MHz,
+ DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
+ CCB:666.667 MHz,
+ DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
+ CPRI:600 MHz
+ MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
+ FMAN1: 666.667 MHz
+ QMAN: 333.333 MHz
+
+CPUn - PowerPC core
+DSP CPUn - SC3900 core
+
+Shaveta Leekha(shaveta@freescale.com)
+Created August 7, 2014
+===========================================
diff --git a/roms/u-boot/doc/README.JFFS2 b/roms/u-boot/doc/README.JFFS2
new file mode 100644
index 000000000..0245da048
--- /dev/null
+++ b/roms/u-boot/doc/README.JFFS2
@@ -0,0 +1,40 @@
+JFFS2 options and usage.
+-----------------------
+
+JFFS2 in U-Boot is a read only implementation of the file system in
+Linux with the same name. To use JFFS2 define CONFIG_CMD_JFFS2.
+
+The module adds three new commands.
+fsload - load binary file from a file system image
+fsinfo - print information about file systems
+ls - list files in a directory
+chpart - change active partition
+
+If you do now need the commands, you can enable the filesystem separately
+with CONFIG_FS_JFFS2 and call the jffs2 functions yourself.
+
+If you boot from a partition which is mounted writable, and you
+update your boot environment by replacing single files on that
+partition, you should also define CONFIG_SYS_JFFS2_SORT_FRAGMENTS. Scanning
+the JFFS2 filesystem takes *much* longer with this feature, though.
+Sorting is done while inserting into the fragment list, which is
+more or less a bubble sort. That algorithm is known to be O(n^2),
+thus you should really consider if you can avoid it!
+
+
+There only one way for JFFS2 to find the disk. It uses the flash_info
+structure to find the start of a JFFS2 disk (called partition in the code)
+and you can change where the partition is with two defines.
+
+CONFIG_SYS_JFFS2_FIRST_BANK
+ defined the first flash bank to use
+
+CONFIG_SYS_JFFS2_FIRST_SECTOR
+ defines the first sector to use
+---
+
+TODO.
+
+ Remove the assumption that JFFS can dereference a pointer
+ into the disk. The current code do not work with memory holes
+ or hardware with a sliding window (PCMCIA).
diff --git a/roms/u-boot/doc/README.JFFS2_NAND b/roms/u-boot/doc/README.JFFS2_NAND
new file mode 100644
index 000000000..92fa0f6ea
--- /dev/null
+++ b/roms/u-boot/doc/README.JFFS2_NAND
@@ -0,0 +1,8 @@
+JFFS2 NAND support:
+
+To enable, use the following #define in the board configuration file:
+
+#define CONFIG_JFFS2_NAND
+
+Configuration of partitions is similar to how this is done in U-Boot
+for JFFS2 on top NOR flash.
diff --git a/roms/u-boot/doc/README.LED b/roms/u-boot/doc/README.LED
new file mode 100644
index 000000000..c21c9d53e
--- /dev/null
+++ b/roms/u-boot/doc/README.LED
@@ -0,0 +1,77 @@
+Status LED
+========================================
+
+This README describes the status LED API.
+
+The API is defined by the include file include/status_led.h
+
+The first step is to enable CONFIG_LED_STATUS in menuconfig:
+> Device Drivers > LED Support.
+
+If the LED support is only for specific board, enable
+CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig.
+
+Status LEDS 0 to 5 are enabled by the following configurations at menuconfig:
+CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5
+
+The following should be configured for each of the enabled LEDs:
+CONFIG_STATUS_LED_BIT<n>
+CONFIG_STATUS_LED_STATE<n>
+CONFIG_STATUS_LED_FREQ<n>
+Where <n> is an integer 1 through 5 (empty for 0).
+
+CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED
+is being acted on. As such, the value choose must be unique with with respect to
+the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the
+reponsiblity of the __led_* function.
+
+CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one
+of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON.
+
+CONFIG_STATUS_LED_FREQ determines the LED blink frequency.
+Values range from 2 to 10.
+
+Some other LED macros
+---------------------
+
+CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting.
+This must be a valid LED number (0-5).
+
+CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be
+a valid LED number (0-5). Other similar color LED's macros are
+CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE.
+
+General LED functions
+---------------------
+The following functions should be defined:
+
+__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE.
+One time start up code should be placed here.
+
+__led_set is called to change the state of the LED.
+
+__led_toggle is called to toggle the current state of the LED.
+
+Colour LED
+========================================
+
+Colour LED's are at present only used by ARM.
+
+The functions names explain their purpose.
+
+coloured_LED_init
+red_LED_on
+red_LED_off
+green_LED_on
+green_LED_off
+yellow_LED_on
+yellow_LED_off
+blue_LED_on
+blue_LED_off
+
+These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define
+these functions in the board specific source.
+
+TBD : Describe older board dependent macros similar to what is done for
+
+TBD : Describe general support via asm/status_led.h
diff --git a/roms/u-boot/doc/README.OFT b/roms/u-boot/doc/README.OFT
new file mode 100644
index 000000000..dd1c632bc
--- /dev/null
+++ b/roms/u-boot/doc/README.OFT
@@ -0,0 +1,28 @@
+Open Firmware Flat Tree and usage.
+----------------------------------
+
+As part of the ongoing cleanup of the Linux PPC trees, the preferred
+way to pass bootloader and board setup information is the open
+firmware flat tree.
+
+Please take a look at the following email discussion for some
+background.
+
+ http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html
+ http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html
+
+The generated tree is part static and part dynamic.
+
+There is a static part which is compiled in with DTC and a dynamic
+part which is programmatically appended.
+
+You'll need a fairly recent DTC tool, which is available by git at
+
+ rsync://ozlabs.org/dtc/dtc.git
+
+The xxd binary dumper is needed too which I got from
+
+ ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz
+
+
+Pantelis Antoniou, 13 Oct 2005
diff --git a/roms/u-boot/doc/README.POST b/roms/u-boot/doc/README.POST
new file mode 100644
index 000000000..1d1c25bdf
--- /dev/null
+++ b/roms/u-boot/doc/README.POST
@@ -0,0 +1,732 @@
+Power-On-Self-Test support in U-Boot
+------------------------------------
+
+This project is to support Power-On-Self-Test (POST) in U-Boot.
+
+1. High-level requirements
+
+The key requirements for this project are as follows:
+
+1) The project shall develop a flexible framework for implementing
+ and running Power-On-Self-Test in U-Boot. This framework shall
+ possess the following features:
+
+ o) Extensibility
+
+ The framework shall allow adding/removing/replacing POST tests.
+ Also, standalone POST tests shall be supported.
+
+ o) Configurability
+
+ The framework shall allow run-time configuration of the lists
+ of tests running on normal/power-fail booting.
+
+ o) Controllability
+
+ The framework shall support manual running of the POST tests.
+
+2) The results of tests shall be saved so that it will be possible to
+ retrieve them from Linux.
+
+3) The following POST tests shall be developed for MPC823E-based
+ boards:
+
+ o) CPU test
+ o) Cache test
+ o) Memory test
+ o) Ethernet test
+ o) Serial channels test
+ o) Watchdog timer test
+ o) RTC test
+ o) I2C test
+ o) SPI test
+ o) USB test
+
+4) The LWMON board shall be used for reference.
+
+2. Design
+
+This section details the key points of the design for the project.
+The whole project can be divided into two independent tasks:
+enhancing U-Boot/Linux to provide a common framework for running POST
+tests and developing such tests for particular hardware.
+
+2.1. Hardware-independent POST layer
+
+A new optional module will be added to U-Boot, which will run POST
+tests and collect their results at boot time. Also, U-Boot will
+support running POST tests manually at any time by executing a
+special command from the system console.
+
+The list of available POST tests will be configured at U-Boot build
+time. The POST layer will allow the developer to add any custom POST
+tests. All POST tests will be divided into the following groups:
+
+ 1) Tests running on power-on booting only
+
+ This group will contain those tests that run only once on
+ power-on reset (e.g. watchdog test)
+
+ 2) Tests running on normal booting only
+
+ This group will contain those tests that do not take much
+ time and can be run on the regular basis (e.g. CPU test)
+
+ 3) Tests running in special "slow test mode" only
+
+ This group will contain POST tests that consume much time
+ and cannot be run regularly (e.g. strong memory test, I2C test)
+
+ 4) Manually executed tests
+
+ This group will contain those tests that can be run manually.
+
+If necessary, some tests may belong to several groups simultaneously.
+For example, SDRAM test may run in both normal and "slow test" mode.
+In normal mode, SDRAM test may perform a fast superficial memory test
+only, while running in slow test mode it may perform a full memory
+check-up.
+
+Also, all tests will be discriminated by the moment they run at.
+Specifically, the following groups will be singled out:
+
+ 1) Tests running before relocating to RAM
+
+ These tests will run immediately after initializing RAM
+ as to enable modifying it without taking care of its
+ contents. Basically, this group will contain memory tests
+ only.
+
+ 2) Tests running after relocating to RAM
+
+ These tests will run immediately before entering the main
+ loop as to guarantee full hardware initialization.
+
+The POST layer will also distinguish a special group of tests that
+may cause system rebooting (e.g. watchdog test). For such tests, the
+layer will automatically detect rebooting and will notify the test
+about it.
+
+2.1.1. POST layer interfaces
+
+This section details the interfaces between the POST layer and the
+rest of U-Boot.
+
+The following flags will be defined:
+
+#define POST_POWERON 0x01 /* test runs on power-on booting */
+#define POST_NORMAL 0x02 /* test runs on normal booting */
+#define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */
+#define POST_POWERTEST 0x08 /* test runs after watchdog reset */
+#define POST_ROM 0x100 /* test runs in ROM */
+#define POST_RAM 0x200 /* test runs in RAM */
+#define POST_MANUAL 0x400 /* test can be executed manually */
+#define POST_REBOOT 0x800 /* test may cause rebooting */
+#define POST_PREREL 0x1000 /* test runs before relocation */
+
+The POST layer will export the following interface routines:
+
+ o) int post_run(struct bd_info *bd, char *name, int flags);
+
+ This routine will run the test (or the group of tests) specified
+ by the name and flag arguments. More specifically, if the name
+ argument is not NULL, the test with this name will be performed,
+ otherwise all tests running in ROM/RAM (depending on the flag
+ argument) will be executed. This routine will be called at least
+ twice with name set to NULL, once from board_init_f() and once
+ from board_init_r(). The flags argument will also specify the
+ mode the test is executed in (power-on, normal, power-fail,
+ manual).
+
+ o) void post_reloc(ulong offset);
+
+ This routine will be called from board_init_r() and will
+ relocate the POST test table.
+
+ o) int post_info(char *name);
+
+ This routine will print the list of all POST tests that can be
+ executed manually if name is NULL, and the description of a
+ particular test if name is not NULL.
+
+ o) int post_log(char *format, ...);
+
+ This routine will be called from POST tests to log their
+ results. Basically, this routine will print the results to
+ stderr. The format of the arguments and the return value
+ will be identical to the printf() routine.
+
+Also, the following board-specific routines will be called from the
+U-Boot common code:
+
+ o) int post_hotkeys_pressed(gd_t *gd)
+
+ This routine will scan the keyboard to detect if a magic key
+ combination has been pressed, or otherwise detect if the
+ power-on long-running tests shall be executed or not ("normal"
+ versus "slow" test mode).
+
+The list of available POST tests be kept in the post_tests array
+filled at U-Boot build time. The format of entry in this array will
+be as follows:
+
+struct post_test {
+ char *name;
+ char *cmd;
+ char *desc;
+ int flags;
+ int (*test)(struct bd_info *bd, int flags);
+};
+
+ o) name
+
+ This field will contain a short name of the test, which will be
+ used in logs and on listing POST tests (e.g. CPU test).
+
+ o) cmd
+
+ This field will keep a name for identifying the test on manual
+ testing (e.g. cpu). For more information, refer to section
+ "Command line interface".
+
+ o) desc
+
+ This field will contain a detailed description of the test,
+ which will be printed on user request. For more information, see
+ section "Command line interface".
+
+ o) flags
+
+ This field will contain a combination of the bit flags described
+ above, which will specify the mode the test is running in
+ (power-on, normal, power-fail or manual mode), the moment it
+ should be run at (before or after relocating to RAM), whether it
+ can cause system rebooting or not.
+
+ o) test
+
+ This field will contain a pointer to the routine that will
+ perform the test, which will take 2 arguments. The first
+ argument will be a pointer to the board info structure, while
+ the second will be a combination of bit flags specifying the
+ mode the test is running in (POST_POWERON, POST_NORMAL,
+ POST_SLOWTEST, POST_MANUAL) and whether the last execution of
+ the test caused system rebooting (POST_REBOOT). The routine will
+ return 0 on successful execution of the test, and 1 if the test
+ failed.
+
+The lists of the POST tests that should be run at power-on/normal/
+power-fail booting will be kept in the environment. Namely, the
+following environment variables will be used: post_poweron,
+powet_normal, post_slowtest.
+
+2.1.2. Test results
+
+The results of tests will be collected by the POST layer. The POST
+log will have the following format:
+
+...
+--------------------------------------------
+START <name>
+<test-specific output>
+[PASSED|FAILED]
+--------------------------------------------
+...
+
+Basically, the results of tests will be printed to stderr. This
+feature may be enhanced in future to spool the log to a serial line,
+save it in non-volatile RAM (NVRAM), transfer it to a dedicated
+storage server and etc.
+
+2.1.3. Integration issues
+
+All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
+This macro will be defined in the config_<board>.h file for those
+boards that need POST. The CONFIG_POST macro will contain the list of
+POST tests for the board. The macro will have the format of array
+composed of post_test structures:
+
+#define CONFIG_POST \
+ {
+ "On-board peripherals test", "board", \
+ " This test performs full check-up of the " \
+ "on-board hardware.", \
+ POST_RAM | POST_SLOWTEST, \
+ &board_post_test \
+ }
+
+A new file, post.h, will be created in the include/ directory. This
+file will contain common POST declarations and will define a set of
+macros that will be reused for defining CONFIG_POST. As an example,
+the following macro may be defined:
+
+#define POST_CACHE \
+ {
+ "Cache test", "cache", \
+ " This test verifies the CPU cache operation.", \
+ POST_RAM | POST_NORMAL, \
+ &cache_post_test \
+ }
+
+A new subdirectory will be created in the U-Boot root directory. It
+will contain the source code of the POST layer and most of POST
+tests. Each POST test in this directory will be placed into a
+separate file (it will be needed for building standalone tests). Some
+POST tests (mainly those for testing peripheral devices) will be
+located in the source files of the drivers for those devices. This
+way will be used only if the test subtantially uses the driver.
+
+2.1.4. Standalone tests
+
+The POST framework will allow to develop and run standalone tests. A
+user-space library will be developed to provide the POST interface
+functions to standalone tests.
+
+2.1.5. Command line interface
+
+A new command, diag, will be added to U-Boot. This command will be
+used for listing all available hardware tests, getting detailed
+descriptions of them and running these tests.
+
+More specifically, being run without any arguments, this command will
+print the list of all available hardware tests:
+
+=> diag
+Available hardware tests:
+ cache - cache test
+ cpu - CPU test
+ enet - SCC/FCC ethernet test
+Use 'diag [<test1> [<test2>]] ... ' to get more info.
+Use 'diag run [<test1> [<test2>]] ... ' to run tests.
+=>
+
+If the first argument to the diag command is not 'run', detailed
+descriptions of the specified tests will be printed:
+
+=> diag cpu cache
+cpu - CPU test
+ This test verifies the arithmetic logic unit of CPU.
+cache - cache test
+ This test verifies the CPU cache operation.
+=>
+
+If the first argument to diag is 'run', the specified tests will be
+executed. If no tests are specified, all available tests will be
+executed.
+
+It will be prohibited to execute tests running in ROM manually. The
+'diag' command will not display such tests and/or run them.
+
+2.1.6. Power failure handling
+
+The Linux kernel will be modified to detect power failures and
+automatically reboot the system in such cases. It will be assumed
+that the power failure causes a system interrupt.
+
+To perform correct system shutdown, the kernel will register a
+handler of the power-fail IRQ on booting. Being called, the handler
+will run /sbin/reboot using the call_usermodehelper() routine.
+/sbin/reboot will automatically bring the system down in a secure
+way. This feature will be configured in/out from the kernel
+configuration file.
+
+The POST layer of U-Boot will check whether the system runs in
+power-fail mode. If it does, the system will be powered off after
+executing all hardware tests.
+
+2.1.7. Hazardous tests
+
+Some tests may cause system rebooting during their execution. For
+some tests, this will indicate a failure, while for the Watchdog
+test, this means successful operation of the timer.
+
+In order to support such tests, the following scheme will be
+implemented. All the tests that may cause system rebooting will have
+the POST_REBOOT bit flag set in the flag field of the correspondent
+post_test structure. Before starting tests marked with this bit flag,
+the POST layer will store an identification number of the test in a
+location in IMMR. On booting, the POST layer will check the value of
+this variable and if it is set will skip over the tests preceding the
+failed one. On second execution of the failed test, the POST_REBOOT
+bit flag will be set in the flag argument to the test routine. This
+will allow to detect system rebooting on the previous iteration. For
+example, the watchdog timer test may have the following
+declaration/body:
+
+...
+#define POST_WATCHDOG \
+ {
+ "Watchdog timer test", "watchdog", \
+ " This test checks the watchdog timer.", \
+ POST_RAM | POST_POWERON | POST_REBOOT, \
+ &watchdog_post_test \
+ }
+...
+
+...
+int watchdog_post_test(struct bd_info *bd, int flags)
+{
+ unsigned long start_time;
+
+ if (flags & POST_REBOOT) {
+ /* Test passed */
+ return 0;
+ } else {
+ /* disable interrupts */
+ disable_interrupts();
+ /* 10-second delay */
+ ...
+ /* if we've reached this, the watchdog timer does not work */
+ enable_interrupts();
+ return 1;
+ }
+}
+...
+
+2.2. Hardware-specific details
+
+This project will also develop a set of POST tests for MPC8xx- based
+systems. This section provides technical details of how it will be
+done.
+
+2.2.1. Generic PPC tests
+
+The following generic POST tests will be developed:
+
+ o) CPU test
+
+ This test will check the arithmetic logic unit (ALU) of CPU. The
+ test will take several milliseconds and will run on normal
+ booting.
+
+ o) Cache test
+
+ This test will verify the CPU cache (L1 cache). The test will
+ run on normal booting.
+
+ o) Memory test
+
+ This test will examine RAM and check it for errors. The test
+ will always run on booting. On normal booting, only a limited
+ amount of RAM will be checked. On power-fail booting a fool
+ memory check-up will be performed.
+
+2.2.1.1. CPU test
+
+This test will verify the following ALU instructions:
+
+ o) Condition register istructions
+
+ This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
+ cror, crorc, crxor, crnand, crnor, creqv, mcrf.
+
+ The mtcrf/mfcr instructions will be tested by loading different
+ values into the condition register (mtcrf), moving its value to
+ a general-purpose register (mfcr) and comparing this value with
+ the expected one. The mcrxr instruction will be tested by
+ loading a fixed value into the XER register (mtspr), moving XER
+ value to the condition register (mcrxr), moving it to a
+ general-purpose register (mfcr) and comparing the value of this
+ register with the expected one. The rest of instructions will be
+ tested by loading a fixed value into the condition register
+ (mtcrf), executing each instruction several times to modify all
+ 4-bit condition fields, moving the value of the conditional
+ register to a general-purpose register (mfcr) and comparing it
+ with the expected one.
+
+ o) Integer compare instructions
+
+ This group will contain: cmp, cmpi, cmpl, cmpli.
+
+ To verify these instructions the test will run them with
+ different combinations of operands, read the condition register
+ value and compare it with the expected one. More specifically,
+ the test will contain a pre-built table containing the
+ description of each test case: the instruction, the values of
+ the operands, the condition field to save the result in and the
+ expected result.
+
+ o) Arithmetic instructions
+
+ This group will contain: add, addc, adde, addme, addze, subf,
+ subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu,
+ extsb, extsh.
+
+ The test will contain a pre-built table of instructions,
+ operands, expected results and expected states of the condition
+ register. For each table entry, the test will cyclically use
+ different sets of operand registers and result registers. For
+ example, for instructions that use 3 registers on the first
+ iteration r0/r1 will be used as operands and r2 for result. On
+ the second iteration, r1/r2 will be used as operands and r3 as
+ for result and so on. This will enable to verify all
+ general-purpose registers.
+
+ o) Logic instructions
+
+ This group will contain: and, andc, andi, andis, or, orc, ori,
+ oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw.
+
+ The test scheme will be identical to that from the previous
+ point.
+
+ o) Shift instructions
+
+ This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
+ rlwimi
+
+ The test scheme will be identical to that from the previous
+ point.
+
+ o) Branch instructions
+
+ This group will contain: b, bl, bc.
+
+ The first 2 instructions (b, bl) will be verified by jumping to
+ a fixed address and checking whether control was transferred to
+ that very point. For the bl instruction the value of the link
+ register will be checked as well (using mfspr). To verify the bc
+ instruction various combinations of the BI/BO fields, the CTR
+ and the condition register values will be checked. The list of
+ such combinations will be pre-built and linked in U-Boot at
+ build time.
+
+ o) Load/store instructions
+
+ This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
+ lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u).
+
+ All operations will be performed on a 16-byte array. The array
+ will be 4-byte aligned. The base register will point to offset
+ 8. The immediate offset (index register) will range in [-8 ...
+ +7]. The test cases will be composed so that they will not cause
+ alignment exceptions. The test will contain a pre-built table
+ describing all test cases. For store instructions, the table
+ entry will contain: the instruction opcode, the value of the
+ index register and the value of the source register. After
+ executing the instruction, the test will verify the contents of
+ the array and the value of the base register (it must change for
+ "store with update" instructions). For load instructions, the
+ table entry will contain: the instruction opcode, the array
+ contents, the value of the index register and the expected value
+ of the destination register. After executing the instruction,
+ the test will verify the value of the destination register and
+ the value of the base register (it must change for "load with
+ update" instructions).
+
+ o) Load/store multiple/string instructions
+
+
+The CPU test will run in RAM in order to allow run-time modification
+of the code to reduce the memory footprint.
+
+2.2.1.2 Special-Purpose Registers Tests
+
+TBD.
+
+2.2.1.3. Cache test
+
+To verify the data cache operation the following test scenarios will
+be used:
+
+ 1) Basic test #1
+
+ - turn on the data cache
+ - switch the data cache to write-back or write-through mode
+ - invalidate the data cache
+ - write the negative pattern to a cached area
+ - read the area
+
+ The negative pattern must be read at the last step
+
+ 2) Basic test #2
+
+ - turn on the data cache
+ - switch the data cache to write-back or write-through mode
+ - invalidate the data cache
+ - write the zero pattern to a cached area
+ - turn off the data cache
+ - write the negative pattern to the area
+ - turn on the data cache
+ - read the area
+
+ The negative pattern must be read at the last step
+
+ 3) Write-through mode test
+
+ - turn on the data cache
+ - switch the data cache to write-through mode
+ - invalidate the data cache
+ - write the zero pattern to a cached area
+ - flush the data cache
+ - write the negative pattern to the area
+ - turn off the data cache
+ - read the area
+
+ The negative pattern must be read at the last step
+
+ 4) Write-back mode test
+
+ - turn on the data cache
+ - switch the data cache to write-back mode
+ - invalidate the data cache
+ - write the negative pattern to a cached area
+ - flush the data cache
+ - write the zero pattern to the area
+ - invalidate the data cache
+ - read the area
+
+ The negative pattern must be read at the last step
+
+To verify the instruction cache operation the following test
+scenarios will be used:
+
+ 1) Basic test #1
+
+ - turn on the instruction cache
+ - unlock the entire instruction cache
+ - invalidate the instruction cache
+ - lock a branch instruction in the instruction cache
+ - replace the branch instruction with "nop"
+ - jump to the branch instruction
+ - check that the branch instruction was executed
+
+ 2) Basic test #2
+
+ - turn on the instruction cache
+ - unlock the entire instruction cache
+ - invalidate the instruction cache
+ - jump to a branch instruction
+ - check that the branch instruction was executed
+ - replace the branch instruction with "nop"
+ - invalidate the instruction cache
+ - jump to the branch instruction
+ - check that the "nop" instruction was executed
+
+The CPU test will run in RAM in order to allow run-time modification
+of the code.
+
+2.2.1.4. Memory test
+
+The memory test will verify RAM using sequential writes and reads
+to/from RAM. Specifically, there will be several test cases that will
+use different patterns to verify RAM. Each test case will first fill
+a region of RAM with one pattern and then read the region back and
+compare its contents with the pattern. The following patterns will be
+used:
+
+ 1) zero pattern (0x00000000)
+ 2) negative pattern (0xffffffff)
+ 3) checkerboard pattern (0x55555555, 0xaaaaaaaa)
+ 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
+ 5) address pattern (offset, ~offset)
+
+Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
+be used to detect adherent bits, i.e. bits whose state may randomly
+change if adjacent bits are modified. The last pattern will be used
+to detect far-located errors, i.e. situations when writing to one
+location modifies an area located far from it. Also, usage of the
+last pattern will help to detect memory controller misconfigurations
+when RAM represents a cyclically repeated portion of a smaller size.
+
+Being run in normal mode, the test will verify only small 4Kb regions
+of RAM around each 1Mb boundary. For example, for 64Mb RAM the
+following areas will be verified: 0x00000000-0x00000800,
+0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
+0x04000000. If the test is run in power-fail mode, it will verify the
+whole RAM.
+
+The memory test will run in ROM before relocating U-Boot to RAM in
+order to allow RAM modification without saving its contents.
+
+2.2.2. Common tests
+
+This section describes tests that are not based on any hardware
+peculiarities and use common U-Boot interfaces only. These tests do
+not need any modifications for porting them to another board/CPU.
+
+2.2.2.1. I2C test
+
+For verifying the I2C bus, a full I2C bus scanning will be performed
+using the i2c_probe() routine. If a board defines
+CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
+listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
+devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined
+the test will pass if any I2C device is found.
+
+The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C
+devices which may or may not be present when using
+CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
+if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not.
+This is useful in cases when I2C devices are optional (eg on a
+daughtercard that may or may not be present) or not critical
+to board operation.
+
+2.2.2.2. Watchdog timer test
+
+To test the watchdog timer the scheme mentioned above (refer to
+section "Hazardous tests") will be used. Namely, this test will be
+marked with the POST_REBOOT bit flag. On the first iteration, the
+test routine will make a 10-second delay. If the system does not
+reboot during this delay, the watchdog timer is not operational and
+the test fails. If the system reboots, on the second iteration the
+POST_REBOOT bit will be set in the flag argument to the test routine.
+The test routine will check this bit and report a success if it is
+set.
+
+2.2.2.3. RTC test
+
+The RTC test will use the rtc_get()/rtc_set() routines. The following
+features will be verified:
+
+ o) Time uniformity
+
+ This will be verified by reading RTC in polling within a short
+ period of time (5-10 seconds).
+
+ o) Passing month boundaries
+
+ This will be checked by setting RTC to a second before a month
+ boundary and reading it after its passing the boundary. The test
+ will be performed for both leap- and nonleap-years.
+
+2.2.3. MPC8xx peripherals tests
+
+This project will develop a set of tests verifying the peripheral
+units of MPC8xx processors. Namely, the following controllers of the
+MPC8xx communication processor module (CPM) will be tested:
+
+ o) Serial Management Controllers (SMC)
+
+ o) Serial Communication Controllers (SCC)
+
+2.2.3.1. Ethernet tests (SCC)
+
+The internal (local) loopback mode will be used to test SCC. To do
+that the controllers will be configured accordingly and several
+packets will be transmitted. These tests may be enhanced in future to
+use external loopback for testing. That will need appropriate
+reconfiguration of the physical interface chip.
+
+The test routines for the SCC ethernet tests will be located in
+arch/powerpc/cpu/mpc8xx/scc.c.
+
+2.2.3.2. UART tests (SMC/SCC)
+
+To perform these tests the internal (local) loopback mode will be
+used. The SMC/SCC controllers will be configured to connect the
+transmitter output to the receiver input. After that, several bytes
+will be transmitted. These tests may be enhanced to make to perform
+"external" loopback test using a loopback cable. In this case, the
+test will be executed manually.
+
+The test routine for the SMC/SCC UART tests will be located in
+arch/powerpc/cpu/mpc8xx/serial.c.
+
+2.2.3.3. USB test
+
+TBD
+
+2.2.3.4. SPI test
+
+TBD
diff --git a/roms/u-boot/doc/README.SNTP b/roms/u-boot/doc/README.SNTP
new file mode 100644
index 000000000..da9ec459a
--- /dev/null
+++ b/roms/u-boot/doc/README.SNTP
@@ -0,0 +1,17 @@
+To use SNTP support, add define CONFIG_CMD_SNTP to the
+configuration file of the board.
+
+The "sntp" command gets network time from NTP time server and
+syncronize RTC of the board. This command needs the command line
+parameter of server's IP address or environment variable
+"ntpserverip". The network time is sent as UTC. So if you want to
+set local time to RTC, set the offset in second from UTC to the
+environment variable "time offset".
+
+If the DHCP server provides time server's IP or time offset, you
+don't need to set the above environment variables yourself.
+
+Current limitations of SNTP support:
+1. The roundtrip time is ignored.
+2. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will
+ be used.
diff --git a/roms/u-boot/doc/README.SPL b/roms/u-boot/doc/README.SPL
new file mode 100644
index 000000000..2beb6d8f1
--- /dev/null
+++ b/roms/u-boot/doc/README.SPL
@@ -0,0 +1,113 @@
+Generic SPL framework
+=====================
+
+Overview
+--------
+
+To unify all existing implementations for a secondary program loader (SPL)
+and to allow simply adding of new implementations this generic SPL framework
+has been created. With this framework almost all source files for a board
+can be reused. No code duplication or symlinking is necessary anymore.
+
+
+How it works
+------------
+
+The object files for SPL are built separately and placed in the "spl" directory.
+The final binaries which are generated are u-boot-spl, u-boot-spl.bin and
+u-boot-spl.map.
+
+A config option named CONFIG_SPL_BUILD is enabled by Kconfig for SPL.
+Source files can therefore be compiled for SPL with different settings.
+
+For example:
+
+ifeq ($(CONFIG_SPL_BUILD),y)
+obj-y += board_spl.o
+else
+obj-y += board.o
+endif
+
+obj-$(CONFIG_SPL_BUILD) += foo.o
+
+#ifdef CONFIG_SPL_BUILD
+ foo();
+#endif
+
+
+The building of SPL images can be enabled by CONFIG_SPL option in Kconfig.
+
+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
+optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options
+are supported:
+
+CONFIG_SPL_LIBCOMMON_SUPPORT (common/libcommon.o)
+CONFIG_SPL_LIBDISK_SUPPORT (disk/libdisk.o)
+CONFIG_SPL_I2C_SUPPORT (drivers/i2c/libi2c.o)
+CONFIG_SPL_GPIO_SUPPORT (drivers/gpio/libgpio.o)
+CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o)
+CONFIG_SPL_SERIAL_SUPPORT (drivers/serial/libserial.o)
+CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o)
+CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o)
+CONFIG_SPL_FS_FAT (fs/fat/libfat.o)
+CONFIG_SPL_FS_EXT4
+CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o)
+CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o)
+CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/raw/libnand.o)
+CONFIG_SPL_DRIVERS_MISC_SUPPORT (drivers/misc)
+CONFIG_SPL_DMA (drivers/dma/libdma.o)
+CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
+CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/raw/nand_spl_load.o)
+CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
+CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
+CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
+
+Device tree
+-----------
+The U-Boot device tree is filtered by the fdtgrep tools during the build
+process to generate a much smaller device tree used in SPL (spl/u-boot-spl.dtb)
+with:
+- the mandatory nodes (/alias, /chosen, /config)
+- the nodes with one pre-relocation property:
+ 'u-boot,dm-pre-reloc' or 'u-boot,dm-spl'
+
+fdtgrep is also used to remove:
+- the properties defined in CONFIG_OF_SPL_REMOVE_PROPS
+- all the pre-relocation properties
+ ('u-boot,dm-pre-reloc', 'u-boot,dm-spl' and 'u-boot,dm-tpl')
+
+All the nodes remaining in the SPL devicetree are bound
+(see doc/driver-model/design.rst).
+
+Debugging
+---------
+
+When building SPL with DEBUG set you may also need to set CONFIG_PANIC_HANG
+as in most cases do_reset is not defined within SPL.
+
+
+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/roms/u-boot/doc/README.TPL b/roms/u-boot/doc/README.TPL
new file mode 100644
index 000000000..72027fd69
--- /dev/null
+++ b/roms/u-boot/doc/README.TPL
@@ -0,0 +1,49 @@
+Generic TPL framework
+=====================
+
+Overview
+--------
+
+TPL---Third Program Loader.
+
+Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot
+be compatible with all the external device(e.g. DDR). So add a tertiary
+program loader (TPL) to enable a loader stub loaded by the code from the
+SPL. It loads the final uboot image into DDR, then jump to it to begin
+execution. Now, only the powerpc mpc85xx has this requirement and will
+implemente it.
+
+Keep consistent with SPL, with this framework almost all source files for a
+board can be reused. No code duplication or symlinking is necessary anymore.
+
+How it works
+------------
+
+There has been a directory $(srctree)/spl which contains only a Makefile. The
+Makefile is shared by SPL and TPL.
+
+The object files are built separately for SPL/TPL and placed in the
+directory spl/tpl. The final binaries which are generated are
+u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map.
+
+During the TPL build a variable named CONFIG_TPL_BUILD is exported in the
+make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD.
+
+The SPL options are shared by SPL and TPL, the board config file should
+determine which SPL options to choose based on whether CONFIG_TPL_BUILD
+is set. Source files can be compiled for TPL with options chosen in the
+board config file.
+
+TPL use a small device tree (u-boot-tpl.dtb), containing only the nodes with
+the pre-relocation properties: 'u-boot,dm-pre-reloc' and 'u-boot,dm-tpl'
+(see README.SPL for details).
+
+For example:
+
+spl/Makefile:
+LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o
+
+CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file:
+#ifdef CONFIG_TPL_BUILD
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#endif
diff --git a/roms/u-boot/doc/README.VLAN b/roms/u-boot/doc/README.VLAN
new file mode 100644
index 000000000..4f86d55ea
--- /dev/null
+++ b/roms/u-boot/doc/README.VLAN
@@ -0,0 +1,15 @@
+U-Boot has networking support for VLANs (802.1q), and CDP (Cisco
+Discovery Protocol).
+
+You control the sending/receiving of VLAN tagged packets with the
+"vlan" environmental variable. When not present no tagging is
+performed.
+
+CDP is used mainly to discover your device VLAN(s) when connected to
+a Cisco switch.
+
+Note: In order to enable CDP support a small change is needed in the
+networking driver. You have to enable reception of the
+01:00:0c:cc:cc:cc MAC address which is a multicast address.
+
+Various defines control CDP; see the README section.
diff --git a/roms/u-boot/doc/README.VSC3316-3308 b/roms/u-boot/doc/README.VSC3316-3308
new file mode 100644
index 000000000..925663ba5
--- /dev/null
+++ b/roms/u-boot/doc/README.VSC3316-3308
@@ -0,0 +1,43 @@
+This file contains API information of the initialization code written for
+Vitesse cross-point devices, VSC3316 and VSC3308 for board B4860QDS
+
+Author: Shaveta Leekha <shaveta@freescale.com>
+
+About Device:
+=============
+VSC 3316/3308 is a low-power, low-cost asynchronous crosspoint switch capable of data rates upto 11.5Gbps.
+
+VSC3316 has 16 input and 16 output ports whereas VSC3308 has 8 input and 8 output ports. Programming of these devices are performed by two-wire or four-wire serial interface.
+
+Initialization:
+===============
+On reset, VSC devices are in low-power state with all inputs, outputs and connections in an off state.
+First thing required is to program it to interface with either two-wire or four-wire interface.
+In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. Also for crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register).
+
+API Overview:
+=============
+
+ vsc_if_enable(u8 vsc_addr):
+ --------------------------
+ This API programs VSC to interface with either two-wire or four-wire interface. In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface.
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
+
+
+ vsc3316_config(u8 vsc_addr, int con_arr[][2], u8 num_con):
+ ---------------------------------------------------------
+ This API configures the VSC3316 device for required connections. Connection through the VSC device requires the inputs and outputs to be properly configured.
+ Connection registers are on page 00. It Configures the selected input and output correctly and join them to make a connection. It also program Input state register, Global input ISE, Global input LOS, Global core control, Output mode register and core control registers etc.
+ vsc3308_config(u8 vsc_addr, int con_arr[][2], u8 num_con) does the essential configurations for VSC3308.
+
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
+ con_arr - connection array
+ num_con - number of connections to be configured
+
+ vsc_wp_config(u8 vsc_addr):
+ --------------------------
+ For crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register), which is done by this API.
+ Parameters:
+ vsc_addr - Address of the VSC device on board.
diff --git a/roms/u-boot/doc/README.arm-caches b/roms/u-boot/doc/README.arm-caches
new file mode 100644
index 000000000..dbb6190b9
--- /dev/null
+++ b/roms/u-boot/doc/README.arm-caches
@@ -0,0 +1,53 @@
+Disabling I-cache:
+- Set CONFIG_SYS_ICACHE_OFF
+
+Disabling D-cache:
+- Set CONFIG_SYS_DCACHE_OFF
+
+Enabling I-cache:
+- Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable().
+
+Enabling D-cache:
+- Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable().
+
+Enabling Caches at System Startup:
+- Implement enable_caches() for your platform and enable the I-cache and
+ D-cache from this function. This function is called immediately
+ after relocation.
+
+Guidelines for Working with D-cache:
+
+Memory to Peripheral DMA:
+- Flush the buffer after the MPU writes the data and before the DMA is
+ initiated.
+
+Peripheral to Memory DMA:
+- Invalidate the buffer before starting the DMA. In case there are any dirty
+ lines from the DMA buffer in the cache, subsequent cache-line replacements
+ may corrupt the buffer in memory while the DMA is still going on. Cache-line
+ replacement can happen if the CPU tries to bring some other memory locations
+ into the cache while the DMA is going on.
+- Invalidate the buffer after the DMA is complete and before the MPU reads
+ it. This may be needed in addition to the invalidation before the DMA
+ mentioned above, because in some processors memory contents can spontaneously
+ come to the cache due to speculative memory access by the CPU. If this
+ happens with the DMA buffer while DMA is going on we have a coherency problem.
+
+Buffer Requirements:
+- Any buffer that is invalidated(that is, typically the peripheral to
+ memory DMA buffer) should be aligned to cache-line boundary both at
+ at the beginning and at the end of the buffer.
+- If the buffer is not cache-line aligned invalidation will be restricted
+ to the aligned part. That is, one cache-line at the respective boundary
+ may be left out while doing invalidation.
+- A suitable buffer can be alloced on the stack using the
+ ALLOC_CACHE_ALIGN_BUFFER macro.
+
+Cleanup Before Linux:
+- cleanup_before_linux() should flush the D-cache, invalidate I-cache, and
+ disable MMU and caches.
+- The following sequence is advisable while disabling d-cache:
+ 1. dcache_disable() - flushes and disables d-cache
+ 2. invalidate_dcache_all() - invalid any entry that came to the cache
+ in the short period after the cache was flushed but before the
+ cache got disabled.
diff --git a/roms/u-boot/doc/README.arm-relocation b/roms/u-boot/doc/README.arm-relocation
new file mode 100644
index 000000000..bc6644911
--- /dev/null
+++ b/roms/u-boot/doc/README.arm-relocation
@@ -0,0 +1,193 @@
+To make relocation on arm working, the following changes are done:
+
+At arch level: add linker flag -pie
+
+ This causes the linker to generate fixup tables .rel.dyn and .dynsym,
+ which must be applied to the relocated image before transferring
+ control to it.
+
+ These fixups are described in the ARM ELF documentation as type 23
+ (program-base-relative) and 2 (symbol-relative)
+
+At cpu level: modify linker file and add a relocation and fixup loop
+
+ the linker file must be modified to include the .rel.dyn and .dynsym
+ tables in the binary image, and to provide symbols for the relocation
+ code to access these tables
+
+ The relocation and fixup loop must be executed after executing
+ board_init_f at initial location and before executing board_init_r
+ at final location.
+
+At board level:
+
+ dram_init(): bd pointer is now at this point not accessible, so only
+ detect the real dramsize, and store it in gd->ram_size. Bst detected
+ with get_ram_size().
+
+TODO: move also dram initialization there on boards where it is possible.
+
+ Setup of the bd_info dram bank info is done in the new function
+ dram_init_banksize() called after bd is accessible.
+
+At lib level:
+
+ Board.c code is adapted from ppc code
+
+* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING *
+
+Boards which are not fixed to support relocation will be REMOVED!
+
+-----------------------------------------------------------------------------
+
+For boards which boot from spl, it is possible to save one copy
+if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code
+is copied again in relocate_code().
+
+example for the tx25 board booting from NAND Flash:
+
+a) cpu starts
+b) it copies the first page in nand to internal ram
+ (spl code)
+c) end executes this code
+d) this initialize CPU, RAM, ... and copy itself to RAM
+ (this bin must fit in one page, so board_init_f()
+ don;t fit in it ... )
+e) there it copy u-boot to CONFIG_SYS_NAND_U_BOOT_DST and
+ starts this image @ CONFIG_SYS_NAND_U_BOOT_START
+f) u-boot code steps through board_init_f() and calculates
+ the relocation address and copy itself to it
+
+If CONFIG_SYS_TEXT_BASE == relocation address, the copying of u-boot
+in f) could be saved.
+
+-----------------------------------------------------------------------------
+
+TODO
+
+- fill in struct bd_info infos (check)
+- adapt all boards
+
+- maybe adapt CONFIG_SYS_TEXT_BASE (this must be checked from board maintainers)
+ This *must* be done for boards, which boot from NOR flash
+
+ on other boards if CONFIG_SYS_TEXT_BASE = relocation baseaddr, this saves
+ one copying from u-boot code.
+
+- new function dram_init_banksize() is actual board specific. Maybe
+ we make a weak default function in arch/arm/lib/board.c ?
+
+-----------------------------------------------------------------------------
+
+Relocation with SPL (example for the tx25 booting from NAND Flash):
+
+- cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE)
+ and start with code execution on this address.
+
+- The First page contains u-boot code from drivers/mtd/nand/raw/mxc_nand_spl.c
+ which inits the dram, cpu registers, reloacte itself to CONFIG_SPL_TEXT_BASE and loads
+ the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution
+ @CONFIG_SYS_NAND_U_BOOT_START
+
+- This u-boot does no RAM init, nor CPU register setup. Just look
+ where it has to copy and relocate itself to this address. If
+ relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the
+ CONFIG_SPL_TEXT_BASE from the spl code), then there is no need
+ to copy, just go on with bss clear and jump to board_init_r.
+
+-----------------------------------------------------------------------------
+
+How ELF relocations 23 and 2 work.
+
+TBC
+
+-------------------------------------------------------------------------------------
+
+Debugging u-boot in RAM:
+(example on the qong board)
+
+-----------------
+
+a) start debugger
+
+arm-linux-gdb u-boot
+
+[hs@pollux u-boot]$ arm-linux-gdb u-boot
+GNU gdb Red Hat Linux (6.7-2rh)
+Copyright (C) 2007 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
+The target architecture is set automatically (currently arm)
+..
+(gdb)
+
+-----------------
+
+b) connect to target
+
+target remote bdi10:2001
+
+(gdb) target remote bdi10:2001
+Remote debugging using bdi10:2001
+0x8ff17f10 in ?? ()
+(gdb)
+
+-----------------
+
+c) discard symbol-file
+
+(gdb) symbol-file
+Discard symbol table from `/home/hs/celf/u-boot/u-boot'? (y or n) y
+No symbol file now.
+(gdb)
+
+-----------------
+
+d) load new symbol table:
+
+(gdb) add-symbol-file u-boot 0x8ff08000
+add symbol table from file "u-boot" at
+ .text_addr = 0x8ff08000
+(y or n) y
+Reading symbols from /home/hs/celf/u-boot/u-boot...done.
+(gdb) c
+Continuing.
+^C
+Program received signal SIGSTOP, Stopped (signal).
+0x8ff17f18 in serial_getc () at serial_mxc.c:192
+192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY);
+(gdb)
+
+add-symbol-file u-boot 0x8ff08000
+ ^^^^^^^^^^
+ get this address from u-boot bdinfo command
+ or get it from gd->relocaddr in gdb
+
+ => bdinfo
+rch_number = XXXXXXXXXX
+boot_params = XXXXXXXXXX
+DRAM bank = XXXXXXXXXX
+-> start = XXXXXXXXXX
+-> size = XXXXXXXXXX
+ethaddr = XXXXXXXXXX
+ip_addr = XXXXXXXXXX
+baudrate = XXXXXXXXXX
+TLB addr = XXXXXXXXXX
+relocaddr = 0x8ff08000
+ ^^^^^^^^^^
+reloc off = XXXXXXXXXX
+irq_sp = XXXXXXXXXX
+sp start = XXXXXXXXXX
+FB base = XXXXXXXXXX
+
+or interrupt execution by any means and re-load the symbols at the location
+specified by gd->relocaddr -- this is only valid after board_init_f.
+
+(gdb) set $s = gd->relocaddr
+(gdb) symbol-file
+(gdb) add-symbol-file u-boot $s
+
+Now you can use gdb as usual :-)
diff --git a/roms/u-boot/doc/README.armada-secureboot b/roms/u-boot/doc/README.armada-secureboot
new file mode 100644
index 000000000..157cb5a23
--- /dev/null
+++ b/roms/u-boot/doc/README.armada-secureboot
@@ -0,0 +1,373 @@
+The trusted boot framework on Marvell Armada 38x
+================================================
+
+Contents:
+
+1. Overview of the trusted boot
+2. Terminology
+3. Boot image layout
+4. The secured header
+5. The secured boot flow
+6. Usage example
+7. Work to be done
+8. Bibliography
+
+1. Overview of the trusted boot
+-------------------------------
+
+The Armada's trusted boot framework enables the SoC to cryptographically verify
+a specially prepared boot image. This can be used to establish a chain of trust
+from the boot firmware all the way to the OS.
+
+To achieve this, the Armada SoC requires a specially prepared boot image, which
+contains the relevant cryptographic data, as well as other information
+pertaining to the boot process. Furthermore, a eFuse structure (a
+one-time-writeable memory) need to be configured in the correct way.
+
+Roughly, the secure boot process works as follows:
+
+* Load the header block of the boot image, extract a special "root" public RSA
+ key from it, and verify its SHA-256 hash against a SHA-256 stored in a eFuse
+ field.
+* Load an array of code signing public RSA keys from the header block, and
+ verify its RSA signature (contained in the header block as well) using the
+ "root" RSA key.
+* Choose a code signing key, and use it to verify the header block (excluding
+ the key array).
+* Verify the binary image's signature (contained in the header block) using the
+ code signing key.
+* If all checks pass successfully, boot the image.
+
+The chain of trust is thus as follows:
+
+* The SHA-256 value in the eFuse field verifies the "root" public key.
+* The "root" public key verifies the code signing key array.
+* The selected code signing key verifies the header block and the binary image.
+
+In the special case of building a boot image containing U-Boot as the binary
+image, which employs this trusted boot framework, the following tasks need to
+be addressed:
+
+1. Creation of the needed cryptographic key material.
+2. Creation of a conforming boot image containing the U-Boot image as binary
+ image.
+3. Burning the necessary eFuse values.
+
+(1) will be addressed later, (2) will be taken care of by U-Boot's build
+system (some user configuration is required, though), and for (3) the necessary
+data (essentially a series of U-Boot commands to be entered at the U-Boot
+command prompt) will be created by the build system as well.
+
+The documentation of the trusted boot mode is contained in part 1, chapter
+7.2.5 in the functional specification [1], and in application note [2].
+
+2. Terminology
+--------------
+
+ CSK - Code Signing Key(s): An array of RSA key pairs, which
+ are used to sign and verify the secured header and the
+ boot loader image.
+ KAK - Key Authentication Key: A RSA key pair, which is used
+ to sign and verify the array of CSKs.
+ Header block - The first part of the boot image, which contains the
+ image's headers (also known as "headers block", "boot
+ header", and "image header")
+ eFuse - A one-time-writeable memory.
+ BootROM - The Armada's built-in boot firmware, which is
+ responsible for verifying and starting secure images.
+ Boot image - The complete image the SoC's boot firmware loads
+ (contains the header block and the binary image)
+ Main header - The header in the header block containing information
+ and data pertaining to the boot process (used for both
+ the regular and secured boot processes)
+ Binary image - The binary code payload of the boot image; in this
+ case the U-Boot's code (also known as "source image",
+ or just "image")
+ Secured header - The specialized header in the header block that
+ contains information and data pertaining to the
+ trusted boot (also known as "security header")
+ Secured boot mode - A special boot mode of the Armada SoC in which secured
+ images are verified (non-secure images won't boot);
+ the mode is activated by setting a eFuse field.
+ Trusted debug mode - A special mode for the trusted boot that allows
+ debugging of devices employing the trusted boot
+ framework in a secure manner (untested in the current
+ implementation).
+Trusted boot framework - The ARMADA SoC's implementation of a secure verified
+ boot process.
+
+3. Boot image layout
+--------------------
+
++-- Boot image --------------------------------------------+
+| |
+| +-- Header block --------------------------------------+ |
+| | Main header | |
+| +------------------------------------------------------+ |
+| | Secured header | |
+| +------------------------------------------------------+ |
+| | BIN header(s) | |
+| +------------------------------------------------------+ |
+| | REG header(s) | |
+| +------------------------------------------------------+ |
+| | Padding | |
+| +------------------------------------------------------+ |
+| |
+| +------------------------------------------------------+ |
+| | Binary image + checksum | |
+| +------------------------------------------------------+ |
++----------------------------------------------------------+
+
+4. The secured header
+---------------------
+
+For the trusted boot framework, a additional header is added to the boot image.
+The following data are relevant for the secure boot:
+
+ KAK: The KAK is contained in the secured header in the form
+ of a RSA-2048 public key in DER format with a length of
+ 524 bytes.
+Header block signature: The RSA signature of the header block (excluding the
+ CSK array), created using the selected CSK.
+Binary image signature: The RSA signature of the binary image, created using
+ the selected CSK.
+ CSK array: The array of the 16 CSKs as RSA-2048 public keys in DER
+ format with a length of 8384 = 16 * 524 bytes.
+ CSK block signature: The RSA signature of the CSK array, created using the
+ KAK.
+
+NOTE: The JTAG delay, Box ID, and Flash ID header fields do play a role in the
+trusted boot process to enable and configure secure debugging, but they were
+not tested in the current implementation of the trusted boot in U-Boot.
+
+5. The secured boot flow
+------------------------
+
+The steps in the boot flow that are relevant for the trusted boot framework
+proceed as follows:
+
+1) Check if trusted boot is enabled, and perform regular boot if it is not.
+2) Load the secured header, and verify its checksum.
+3) Select the lowest valid CSK from CSK0 to CSK15.
+4) Verify the SHA-256 hash of the KAK embedded in the secured header.
+5) Verify the RSA signature of the CSK block from the secured header with the
+ KAK.
+6) Verify the header block signature (which excludes the CSK block) from the
+ secured header with the selected CSK.
+7) Load the binary image to the main memory and verify its checksum.
+8) Verify the binary image's RSA signature from the secured header with the
+ selected CSK.
+9) Continue the boot process as in the case of the regular boot.
+
+NOTE: All RSA signatures are verified according to the PKCS #1 v2.1 standard
+described in [3].
+
+NOTE: The Box ID and Flash ID are checked after step 6, and the trusted debug
+mode may be entered there, but since this mode is untested in the current
+implementation, it is not described further.
+
+6. Usage example
+----------------
+
+### Create key material
+
+To employ the trusted boot framework, cryptographic key material needs to be
+created. In the current implementation, two keys are needed to build a valid
+secured boot image: The KAK private key and a CSK private key (both have to be
+2048 bit RSA keys in PEM format). Note that the usage of more than one CSK is
+currently not supported.
+
+NOTE: Since the public key can be generated from the private key, it is
+sufficient to store the private key for each key pair.
+
+OpenSSL can be used to generate the needed files kwb_kak.key and kwb_csk.key
+(the names of these files have to be configured, see the next section on
+kwbimage.cfg settings):
+
+openssl genrsa -out kwb_kak.key 2048
+openssl genrsa -out kwb_csk.key 2048
+
+The generated files have to be placed in the U-Boot root directory.
+
+Alternatively, instead of copying the files, symlinks to the private keys can
+be placed in the U-Boot root directory.
+
+WARNING: Knowledge of the KAK or CSK private key would enable an attacker to
+generate secured boot images containing arbitrary code. Hence, the private keys
+should be carefully guarded.
+
+### Create/Modifiy kwbimage.cfg
+
+The Kirkwook architecture in U-Boot employs a special board-specific
+configuration file (kwbimage.cfg), which controls various boot image settings
+that are interpreted by the BootROM, such as the boot medium. The support the
+trusted boot framework, several new options were added to faciliate
+configuration of the secured boot.
+
+The configuration file's layout has been retained, only the following new
+options were added:
+
+ KAK - The name of the KAK RSA private key file in the U-Boot
+ root directory, without the trailing extension of ".key".
+ CSK - The name of the (active) CSK RSA private key file in the
+ U-Boot root directory, without the trailing extension of
+ ".key".
+ BOX_ID - The BoxID to be used for trusted debugging (a integer
+ value).
+ FLASH_ID - The FlashID to be used for trusted debugging (a integer
+ value).
+ JTAG_DELAY - The JTAG delay to be used for trusted debugging (a
+ integer value).
+ CSK_INDEX - The index of the active CSK (a integer value).
+SEC_SPECIALIZED_IMG - Flag to indicate whether to include the BoxID and FlashID
+ in the image (that is, whether to use the trusted debug
+ mode or not); no parameters.
+ SEC_BOOT_DEV - The boot device from which the trusted boot is allowed to
+ proceed, identified via a numeric ID. The tested values
+ are 0x34 = NOR flash, 0x31 = SDIO/MMC card; for
+ additional ID values, consult the documentation in [1].
+ SEC_FUSE_DUMP - Dump the "fuse prog" commands necessary for writing the
+ correct eFuse values to a text file in the U-Boot root
+ directory. The parameter is the architecture for which to
+ dump the commands (currently only "a38x" is supported).
+
+The parameter values may be hardcoded into the file, but it is also possible to
+employ a dynamic approach of creating a Autoconf-like kwbimage.cfg.in, then
+reading configuration values from Kconfig options or from the board config
+file, and generating the actual kwbimage.cfg from this template using Makefile
+mechanisms (see board/gdsys/a38x/Makefile as an example for this approach).
+
+### Set config options
+
+To enable the generation of trusted boot images, the corresponding support
+needs to be activated, and a index for the active CSK needs to be selected as
+well.
+
+Furthermore, eFuse writing support has to be activated in order to burn the
+eFuse structure's values (this option is just needed for programming the eFuse
+structure; production boot images may disable it).
+
+ARM architecture
+ -> [*] Build image for trusted boot
+ (0) Index of active CSK
+ -> [*] Enable eFuse support
+ [ ] Fake eFuse access (dry run)
+
+### Build and test boot image
+
+The creation of the boot image is done via the usual invocation of make (with a
+suitably set CROSS_COMPILE environment variable, of course). The resulting boot
+image u-boot-spl.kwb can then be tested, if so desired. The hdrparser from [5]
+can be used for this purpose. To build the tool, invoke make in the
+'tools/marvell/doimage_mv' directory of [5], which builds a stand-alone
+hdrparser executable. A test can be conducted by calling hdrparser with the
+produced boot image and the following (mandatory) parameters:
+
+./hdrparser -k 0 -t u-boot-spl.kwb
+
+Here we assume that the CSK index is 0 and the boot image file resides in the
+same directory (adapt accordingly if needed). The tool should report that all
+checksums are valid ("GOOD"), that all signature verifications succeed
+("PASSED"), and, finally, that the overall test was successful
+("T E S T S U C C E E D E D" in the last line of output).
+
+### Burn eFuse structure
+
++----------------------------------------------------------+
+| WARNING: Burning the eFuse structure is a irreversible |
+| operation! Should wrong or corrupted values be used, the |
+| board won't boot anymore, and recovery is likely |
+| impossible! |
++----------------------------------------------------------+
+
+After the build process has finished, and the SEC_FUSE_DUMP option was set in
+the kwbimage.cfg was set, a text file kwb_fuses_a38x.txt should be present in
+the U-Boot top-level directory. It contains all the necessary commands to set
+the eFuse structure to the values needed for the used KAK digest, as well as
+the CSK index, Flash ID and Box ID that were selected in kwbimage.cfg.
+
+Sequentially executing the commands in this file at the U-Boot command prompt
+will write these values to the eFuse structure.
+
+If the SEC_FUSE_DUMP option was not set, the commands needed to burn the fuses
+have to be crafted by hand. The needed fuse lines can be looked up in [1]; a
+rough overview of the process is:
+
+* Burn the KAK public key hash. The hash itself can be found in the file
+ pub_kak_hash.txt in the U-Boot top-level directory; be careful to account for
+ the endianness!
+* Burn the CSK selection, BoxID, and FlashID
+* Enable trusted boot by burning the corresponding fuse (WARNING: this must be
+ the last fuse line written!)
+* Lock the unused fuse lines
+
+The command to employ is the "fuse prog" command previously enabled by setting
+the corresponding configuration option.
+
+For the trusted boot, the fuse prog command has a special syntax, since the
+ARMADA SoC demands that whole fuse lines (64 bit values) have to be written as
+a whole. The fuse prog command itself allows lists of 32 bit words to be
+written at a time, but this is translated to a series of single 32 bit write
+operations to the fuse line, where the individual 32 bit words are identified
+by a "word" counter that is increased for each write.
+
+To work around this restriction, we interpret each line to have three "words"
+(0-2): The first and second words are the values to be written to the fuse
+line, and the third is a lock flag, which is supposed to lock the fuse line
+when set to 1. Writes to the first and second words are memoized between
+function calls, and the fuse line is only really written and locked (on writing
+the third word) if both words were previously set, so that "incomplete" writes
+are prevented. An exception to this is a single write to the third word (index
+2) without previously writing neither the first nor the second word, which
+locks the fuse line without setting any value; this is needed to lock the
+unused fuse lines.
+
+As an example, to write the value 0011223344556677 to fuse line 10, we would
+use the following command:
+
+fuse prog -y 10 0 00112233 44556677 1
+
+Here 10 is the fuse line number, 0 is the index of the first word to be
+written, 00112233 and 44556677 are the values to be written to the fuse line
+(first and second word) and the trailing 1 is the value for the third word
+responsible for locking the line.
+
+A "lock-only" command would look like this:
+
+fuse prog -y 11 2 1
+
+Here 11 is the fuse number, 2 is the index of the first word to be written
+(notice that we only write to word 2 here; the third word for fuse line
+locking), and the 1 is the value for the word we are writing to.
+
+WARNING: According to application note [4], the VHV pin of the SoC must be
+connected to a 1.8V source during eFuse programming, but *must* be disconnected
+for normal operation. The AN [4] describes a software-controlled circuit (based
+on a N-channel or P-channel FET and a free GPIO pin of the SoC) to achieve
+this, but a jumper-based circuit should suffice as well. Regardless of the
+chosen circuit, the issue needs to be addressed accordingly!
+
+7. Work to be done
+------------------
+
+* Add the ability to populate more than one CSK
+* Test secure debug
+* Test on Armada XP
+
+8. Bibliography
+---------------
+
+[1] ARMADA(R) 38x Family High-Performance Single/Dual CPU System on Chip
+ Functional Specification; MV-S109094-00, Rev. C; August 2, 2015,
+ Preliminary
+[2] AN-383: ARMADA(R) 38x Families Secure Boot Mode Support; MV-S302501-00
+ Rev. A; March 11, 2015, Preliminary
+[3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
+ Specifications Version 2.1; February 2003;
+ https://www.ietf.org/rfc/rfc3447.txt
+[4] AN-389: ARMADA(R) VHV Power; MV-S302545-00 Rev. B; January 28, 2016,
+ Released
+[5] Marvell Armada 38x U-Boot support; November 25, 2015;
+ https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
+
+2017-01-05, Mario Six <mario.six@gdsys.cc>
diff --git a/roms/u-boot/doc/README.asn1 b/roms/u-boot/doc/README.asn1
new file mode 100644
index 000000000..1359b93ae
--- /dev/null
+++ b/roms/u-boot/doc/README.asn1
@@ -0,0 +1,40 @@
+ASN1
+====
+
+Abstract Syntax Notation One (or ASN1) is a standard by ITU-T and ISO/IEC
+and used as a description language for defining data structure in
+an independent manner.
+Any data described in ASN1 notation can be serialized (or encoded) and
+de-serialized (or decoded) with well-defined encoding rules.
+
+A combination of ASN1 compiler and ASN1 decoder library function will
+provide a function interface for parsing encoded binary into specific
+data structure:
+1) define data structure in a text file (*.asn1)
+2) define "action" routines for specific "tags" defined in (1)
+3) generate bytecode as a C file (*.asn1.[ch]) from *.asn1 file
+ with ASN1 compiler (tools/asn1_compiler)
+4) call a ASN1 decoder (asn1_ber_decoder()) with bytecode and data
+
+Usage of ASN1 compiler
+----------------------
+ asn1_compiler [-v] [-d] <grammar-file> <c-file> <hdr-file>
+
+ <grammar-file>: ASN1 input file
+ <c-file>: generated C file
+ <hdr-file>: generated include file
+
+Usage of ASN1 decoder
+---------------------
+ int asn1_ber_decoder(const struct asn1_decoder *decoder, void *context,
+ const unsigned char *data, size_t datalen);
+
+ @decoder: bytecode binary
+ @context: context for decoder
+ @data: data to be parsed
+ @datalen: size of data
+
+
+As of writing this, ASN1 compiler and decoder are used to implement
+X509 certificate parser, pcks7 message parser and RSA public key parser
+for UEFI secure boot.
diff --git a/roms/u-boot/doc/README.atmel_mci b/roms/u-boot/doc/README.atmel_mci
new file mode 100644
index 000000000..00e64ba0c
--- /dev/null
+++ b/roms/u-boot/doc/README.atmel_mci
@@ -0,0 +1,74 @@
+How to use SD/MMC cards with Atmel SoCs having MCI hardware
+-----------------------------------------------------------
+2010-08-16 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+
+This is a new approach to use Atmel MCI hardware with the
+general MMC framework. Therefore it benefits from that
+framework's abilities to handle SDHC Cards and the ability
+to write blocks.
+
+- AT91SAM9XE512 (tested, will definitely work with XE128 and XE256)
+- AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
+- AT91SAM9G20 (not tested, should work)
+
+It should work with all other ATMEL devices that have MCI.
+
+The generic driver does NOT assign port pins to the MCI block
+nor does it start the MCI clock. This has to be handled in a
+board/SoC specific manner before the driver is initialized:
+
+example: this is added to at91sam9260_devices.c:
+
+#if defined(CONFIG_GENERIC_ATMEL_MCI)
+void at91_mci_hw_init(void)
+{
+ at91_set_a_periph(AT91_PIO_PORTA, 8, PUP); /* MCCK */
+#if defined(CONFIG_ATMEL_MCI_PORTB)
+ at91_set_b_periph(AT91_PIO_PORTA, 1, PUP); /* MCCDB */
+ at91_set_b_periph(AT91_PIO_PORTA, 0, PUP); /* MCDB0 */
+ at91_set_b_periph(AT91_PIO_PORTA, 5, PUP); /* MCDB1 */
+ at91_set_b_periph(AT91_PIO_PORTA, 4, PUP); /* MCDB2 */
+ at91_set_b_periph(AT91_PIO_PORTA, 3, PUP); /* MCDB3 */
+#else
+ at91_set_a_periph(AT91_PIO_PORTA, 7, PUP); /* MCCDA */
+ at91_set_a_periph(AT91_PIO_PORTA, 6, PUP); /* MCDA0 */
+ at91_set_a_periph(AT91_PIO_PORTA, 9, PUP); /* MCDA1 */
+ at91_set_a_periph(AT91_PIO_PORTA, 10, PUP); /* MCDA2 */
+ at91_set_a_periph(AT91_PIO_PORTA, 11, PUP); /* MCDA3 */
+#endif
+}
+#endif
+
+the board specific file need added:
+...
+#ifdef CONFIG_GENERIC_ATMEL_MCI
+# include <mmc.h>
+#endif
+...
+#ifdef CONFIG_GENERIC_ATMEL_MCI
+/* this is a weak define that we are overriding */
+int board_mmc_init(struct bd_info *bd)
+{
+ /* Enable clock */
+ at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI);
+ at91_mci_hw_init();
+
+ /* This calls the atmel_mci_init in gen_atmel_mci.c */
+ return atmel_mci_init((void *)AT91_BASE_MCI);
+}
+
+/* this is a weak define that we are overriding */
+int board_mmc_getcd(struct mmc *mmc)
+{
+ return !at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN);
+}
+
+#endif
+
+and the board definition files needs:
+
+/* SD/MMC card */
+#define CONFIG_GENERIC_ATMEL_MCI 1
+#define CONFIG_ATMEL_MCI_PORTB 1 /* Atmel XE-EK uses port B */
+#define CONFIG_SYS_MMC_CD_PIN AT91_PIN_PC9
+#define CONFIG_CMD_MMC 1
diff --git a/roms/u-boot/doc/README.atmel_pmecc b/roms/u-boot/doc/README.atmel_pmecc
new file mode 100644
index 000000000..c86d08577
--- /dev/null
+++ b/roms/u-boot/doc/README.atmel_pmecc
@@ -0,0 +1,49 @@
+How to enable PMECC(Programmable Multibit ECC) for nand on Atmel SoCs
+-----------------------------------------------------------
+2012-08-22 Josh Wu <josh.wu@atmel.com>
+
+The Programmable Multibit ECC (PMECC) controller is a programmable binary
+BCH(Bose, Chaudhuri and Hocquenghem) encoder and decoder. This controller
+can be used to support both SLC and MLC NAND Flash devices. It supports to
+generate ECC to correct 2, 4, 8, 12 or 24 bits of error per sector (512 or
+1024 bytes) of data.
+
+Following Atmel AT91 products support PMECC.
+- AT91SAM9X25, X35, G25, G15, G35 (tested)
+- AT91SAM9N12 (not tested, Should work)
+
+As soon as your nand flash software ECC works, you can enable PMECC.
+
+To use PMECC in this driver, the user needs to set:
+ 1. the PMECC correction error bits capability: CONFIG_PMECC_CAP.
+ It can be 2, 4, 8, 12 or 24.
+ 2. The PMECC sector size: CONFIG_PMECC_SECTOR_SIZE.
+ It only can be 512 or 1024.
+
+Take 'configs/at91sam9x5ek_nandflash_defconfig' as an example, the board
+configuration file has the following entries:
+
+ CONFIG_PMECC_CAP=2
+ CONFIG_PMECC_SECTOR_SIZE=512
+ CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER=y
+
+How to enable PMECC header for direct programmable boot.bin
+-----------------------------------------------------------
+2014-05-19 Andreas Bießmann <andreas@biessmann.org>
+
+The usual way to program SPL into NAND flash is to use the SAM-BA Atmel tool.
+This however is often not usable when doing field updates. To be able to
+program a SPL binary into NAND flash we need to add the PMECC header to the
+binary before. Chapter '12.4.4.1 NAND Flash Boot: NAND Flash Detection' in
+sama5d3 SoC spec (as of 03. April 2014) defines how this PMECC header has to
+look like. In order to do so we have a new image type added to mkimage to
+generate this PMECC header and integrated this into the build process of SPL.
+
+To enable the generation of atmel PMECC header for SPL one needs to define
+CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER. The required parameters are taken from
+board configuration and compiled into the host tools atmel_pmecc_params. This
+tool will be called in build process to parametrize mkimage for atmelimage
+type. The mkimage tool has intentionally _not_ compiled in those parameters.
+
+The mkimage image type atmelimage also set the 6'th interrupt vector to the
+correct value. This feature can also be used to setup a boot.bin for MMC boot.
diff --git a/roms/u-boot/doc/README.autoboot b/roms/u-boot/doc/README.autoboot
new file mode 100644
index 000000000..5e9a5e1cf
--- /dev/null
+++ b/roms/u-boot/doc/README.autoboot
@@ -0,0 +1,162 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2001
+ * Dave Ellis, SIXNET, dge@sixnetio.com
+ *
+ */
+
+Using autoboot configuration options
+====================================
+
+The basic autoboot configuration options are documented in the main
+U-Boot README. See it for details. They are:
+
+ bootdelay
+ bootcmd
+ CONFIG_BOOTDELAY
+ CONFIG_BOOTCOMMAND
+
+Some additional options that make autoboot safer in a production
+product are documented here.
+
+Why use them?
+-------------
+
+The basic autoboot feature allows a system to automatically boot to
+the real application (such as Linux) without a user having to enter
+any commands. If any key is pressed before the boot delay time
+expires, U-Boot stops the autoboot process, gives a U-Boot prompt
+and waits forever for a command. That's a good thing if you pressed a
+key because you wanted to get the prompt.
+
+It's not so good if the key press was a stray character on the
+console serial port, say because a user who knows nothing about
+U-Boot pressed a key before the system had time to boot. It's even
+worse on an embedded product that doesn't have a console during
+normal use. The modem plugged into that console port sends a
+character at the wrong time and the system hangs, with no clue as to
+why it isn't working.
+
+You might want the system to autoboot to recover after an external
+configuration program stops autoboot. If the configuration program
+dies or loses its connection (modems can disconnect at the worst
+time) U-Boot will patiently wait forever for it to finish.
+
+These additional configuration options can help provide a system that
+boots when it should, but still allows access to U-Boot.
+
+What they do
+------------
+
+ CONFIG_BOOT_RETRY_TIME
+ CONFIG_BOOT_RETRY_MIN
+
+ "bootretry" environment variable
+
+ These options determine what happens after autoboot is
+ stopped and U-Boot is waiting for commands.
+
+ CONFIG_BOOT_RETRY_TIME must be defined to enable the boot
+ retry feature. If the environment variable "bootretry" is
+ found then its value is used, otherwise the retry timeout is
+ CONFIG_BOOT_RETRY_TIME. CONFIG_BOOT_RETRY_MIN is optional and
+ defaults to CONFIG_BOOT_RETRY_TIME. All times are in seconds.
+
+ If the retry timeout is negative, the U-Boot command prompt
+ never times out. Otherwise it is forced to be at least
+ CONFIG_BOOT_RETRY_MIN seconds. If no valid U-Boot command is
+ entered before the specified time the boot delay sequence is
+ restarted. Each command that U-Boot executes restarts the
+ timeout.
+
+ If CONFIG_BOOT_RETRY_TIME < 0 the feature is there, but
+ doesn't do anything unless the environment variable
+ "bootretry" is >= 0.
+
+ CONFIG_AUTOBOOT_KEYED
+ CONFIG_AUTOBOOT_KEYED_CTRLC
+ CONFIG_AUTOBOOT_PROMPT
+ CONFIG_AUTOBOOT_DELAY_STR
+ CONFIG_AUTOBOOT_STOP_STR
+
+ "bootdelaykey" environment variable
+ "bootstopkey" environment variable
+
+ These options give more control over stopping autoboot. When
+ they are used a specific character or string is required to
+ stop or delay autoboot.
+
+ Define CONFIG_AUTOBOOT_KEYED (no value required) to enable
+ this group of options. CONFIG_AUTOBOOT_DELAY_STR,
+ CONFIG_AUTOBOOT_STOP_STR or both should be specified (or
+ specified by the corresponding environment variable),
+ otherwise there is no way to stop autoboot.
+
+ CONFIG_AUTOBOOT_PROMPT is displayed before the boot delay
+ selected by CONFIG_BOOTDELAY starts. If it is not defined
+ there is no output indicating that autoboot is in progress.
+
+ Note that CONFIG_AUTOBOOT_PROMPT is used as the (only)
+ argument to a printf() call, so it may contain '%' format
+ specifications, provided that it also includes, sepearated by
+ commas exactly like in a printf statement, the required
+ arguments. It is the responsibility of the user to select only
+ such arguments that are valid in the given context. A
+ reasonable prompt could be defined as
+
+ #define CONFIG_AUTOBOOT_PROMPT \
+ "autoboot in %d seconds\n",bootdelay
+
+ If CONFIG_AUTOBOOT_DELAY_STR or "bootdelaykey" is specified
+ and this string is received from console input before
+ autoboot starts booting, U-Boot gives a command prompt. The
+ U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is
+ used, otherwise it never times out.
+
+ If CONFIG_AUTOBOOT_STOP_STR or "bootstopkey" is specified and
+ this string is received from console input before autoboot
+ starts booting, U-Boot gives a command prompt. The U-Boot
+ prompt never times out, even if CONFIG_BOOT_RETRY_TIME is
+ used.
+
+ The string recognition is not very sophisticated. If a
+ partial match is detected, the first non-matching character
+ is checked to see if starts a new match. There is no check
+ for a shorter partial match, so it's best if the first
+ character of a key string does not appear in the rest of the
+ string.
+
+ The CONFIG_AUTOBOOT_KEYED_CTRLC #define allows for the boot
+ sequence to be interrupted by ctrl-c, in addition to the
+ "bootdelaykey" and "bootstopkey". Setting this variable
+ provides an escape sequence from the limited "password"
+ strings.
+
+ CONFIG_AUTOBOOT_ENCRYPTION
+
+ "bootstopkeysha256" environment variable
+
+ - Hash value of the input which unlocks the device and
+ stops autoboot.
+
+ This option allows a string to be entered into U-Boot to stop the
+ autoboot. The string itself is hashed and compared against the hash
+ in the environment variable 'bootstopkeysha256'. If it matches then
+ boot stops and a command-line prompt is presented.
+
+ This provides a way to ship a secure production device which can also
+ be accessed at the U-Boot command line.
+
+ CONFIG_RESET_TO_RETRY
+
+ (Only effective when CONFIG_BOOT_RETRY_TIME is also set)
+ After the countdown timed out, the board will be reset to restart
+ again.
+
+ CONFIG_AUTOBOOT_USE_MENUKEY
+ CONFIG_AUTOBOOT_MENUKEY
+
+ If this key is pressed to stop autoboot, then the commands in the
+ environment variable 'menucmd' will be executed before boot starts.
+ For example, 33 means "!" in ASCII, so pressing ! at boot would take
+ this action.
diff --git a/roms/u-boot/doc/README.bcm7xxx b/roms/u-boot/doc/README.bcm7xxx
new file mode 100644
index 000000000..9b5eae474
--- /dev/null
+++ b/roms/u-boot/doc/README.bcm7xxx
@@ -0,0 +1,150 @@
+Summary
+=======
+
+This document describes how to use U-Boot on the Broadcom 7445 SoC, as
+a third stage bootloader loaded by Broadcom's BOLT bootloader.
+
+BOLT loads U-Boot as a generic ELF binary. Some U-Boot features such
+as networking are not yet available but other important features are,
+including:
+
+ - ext4 file system traversal
+
+ - support for loading FIT images
+
+ - advanced scripting
+
+ - support for FIT-provided DTBs instead of relying on the
+ BOLT-provided DTB
+
+A customized version of this port has been used in production. The
+same approach may work on other BCM7xxx boards, with some
+configuration adjustments and memory layout experimentation.
+
+Build
+=====
+
+make bcm7445_defconfig
+make
+${CROSS_COMPILE}strip u-boot
+
+Run
+===
+
+Flash the u-boot binary into board storage, then invoke it from BOLT.
+For example:
+
+BOLT> boot -bsu -elf flash0.u-boot1
+
+This port assumes that I-cache and D-cache are already enabled when
+U-Boot is entered.
+
+Flattened Image Tree Support
+============================
+
+What follows is an example FIT image source file. Build it with:
+
+mkimage -f image.its image.itb
+
+Booting the resulting image.itb was tested on BOLT v1.20, with the
+following kernels:
+
+https://github.com/Broadcom/stblinux-3.14
+https://github.com/Broadcom/stblinux-4.1
+https://github.com/Broadcom/stblinux-4.9
+
+and with a generic ARMv7 root file system.
+
+image.its:
+/dts-v1/;
+/ {
+ description = "BCM7445 FIT";
+ images {
+ kernel@1 {
+ description = "Linux kernel";
+ /*
+ * This kernel image output format can be
+ * generated with:
+ *
+ * make vmlinux
+ * ${CROSS_COMPILE}objcopy -O binary -S vmlinux vmlinux.bin
+ * gzip -9 vmlinux.bin
+ *
+ * For stblinux-3.14, the specific Broadcom
+ * board type should be configured in the
+ * kernel, for example CONFIG_BCM7445D0=y.
+ */
+ data = /incbin/("<vmlinux.bin.gz>");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ compression = "gzip";
+ load = <0x8000>;
+ entry = <0x8000>;
+ hash@1 {
+ algo = "sha256";
+ };
+ };
+ ramdisk@1 {
+ description = "Initramfs root file system";
+ data = /incbin/("<initramfs.cpio.gz>");
+ type = "ramdisk";
+ arch = "arm";
+ os = "linux";
+ compression = "gzip";
+ /*
+ * Set the environment variable initrd_high to
+ * 0xffffffff, and set "load" and "entry" here
+ * to 0x0 to keep initramfs in-place and to
+ * accommodate stblinux bmem/CMA reservations.
+ */
+ load = <0x0>;
+ entry = <0x0>;
+ hash@1 {
+ algo = "sha256";
+ };
+ };
+ fdt@1 {
+ description = "Device tree dumped from BOLT";
+ /*
+ * This DTB should be similar to the
+ * BOLT-generated device tree, after BOLT has
+ * done its runtime modifications to it. For
+ * example, it can be dumped from within
+ * U-Boot (at ${fdtcontroladdr}), after BOLT
+ * has loaded U-Boot. The result can be added
+ * to the Linux source tree as a .dts file.
+ *
+ * To support modifications to the device tree
+ * in-place in U-Boot, add to Linux's
+ * arch/arm/boot/dts/Makefile:
+ *
+ * DTC_FLAGS ?= -p 4096
+ *
+ * This will leave some padding in the DTB and
+ * thus reserve room for node additions.
+ *
+ * Also, set the environment variable fdt_high
+ * to 0xffffffff to keep the DTB in-place and
+ * to accommodate stblinux bmem/CMA
+ * reservations.
+ */
+ data = /incbin/("<bolt-<version>.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash@1 {
+ algo = "sha256";
+ };
+ };
+ };
+ configurations {
+ default = "conf@bcm7445";
+ conf@bcm7445 {
+ description = "BCM7445 configuration";
+ kernel = "kernel@1";
+ ramdisk = "ramdisk@1";
+ fdt = "fdt@1";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/README.bcmns3 b/roms/u-boot/doc/README.bcmns3
new file mode 100644
index 000000000..c51f91471
--- /dev/null
+++ b/roms/u-boot/doc/README.bcmns3
@@ -0,0 +1,74 @@
+BCMNS3 QSPI memory layout
+=========================
+
+BCMNS3 has total 8MB non-volatile SPI flash memory. It is used to store
+different images like fip.bin, nitro firmware, DDR shmo value and other backup
+images.
+
+Following is the QSPI flash memory layout.
+
+/* QSPI layout
+ * |---------------------------|->0x000000
+ * | |
+ * | |
+ * | fip.bin |
+ * | 2MB |
+ * | |
+ * ~ ~
+ * ~ ~
+ * | |
+ * | |
+ * | |
+ * |---------------------------|->0x200000
+ * | |
+ * | |
+ * | |
+ * | fip.bin (Mirror) |
+ * | 2MB |
+ * ~ ~
+ * ~ ~
+ * | |
+ * | |
+ * | |
+ * |---------------------------|->0x400000
+ * | |
+ * | Nitro NS3 Config |
+ * | 1.5M |
+ * | |
+ * ~ ~
+ * ~ ~
+ * | |
+ * |---------------------------|->0x580000
+ * | Nitro NS3 Config |
+ * | 1.5M |
+ * | (Mirror) |
+ * ~ ~
+ * ~ ~
+ * | |
+ * |---------------------------|->0x700000
+ * | Nitro NS3 bspd Config |
+ * | 64KB |
+ * ~ ~
+ * ~ ~
+ * | |
+ * |---------------------------|->0x710000
+ * | Nitro NS3 bspd Config |
+ * | 64KB |
+ * ~ (Mirror) ~
+ * ~ ~
+ * | |
+ * |---------------------------|->0x720000
+ * | SHMOO |
+ * | 64KB |
+ * | |
+ * ~ ~
+ * ~ ~
+ * |---------------------------|->0x730000
+ * | Meta Data |
+ * | 832KB |
+ * | |
+ * ~ ~
+ * ~ ~
+ * | |
+ * |---------------------------|
+ */
diff --git a/roms/u-boot/doc/README.bedbug b/roms/u-boot/doc/README.bedbug
new file mode 100644
index 000000000..35e9d2706
--- /dev/null
+++ b/roms/u-boot/doc/README.bedbug
@@ -0,0 +1,78 @@
+BEDBUG Support for U-Boot
+--------------------------
+
+These changes implement the bedbug (emBEDded deBUGger) debugger in U-Boot.
+A specific implementation is made for the AMCC 405 processor but other flavors
+can be easily implemented.
+
+#####################
+### Modifications ###
+#####################
+
+./common/Makefile
+ Included cmd_bedbug.c and bedbug.c in the Makefile.
+
+./common/command.c
+ Added bedbug commands to command table.
+
+./common/board.c
+ Added call to initialize debugger on startup.
+
+./arch/powerpc/cpu/ppc4xx/Makefile
+ Added bedbug_405.c to the Makefile.
+
+./arch/powerpc/cpu/ppc4xx/start.S
+ Added code to handle the debug exception (0x2000) on the 405.
+ Also added code to handle critical exceptions since the debug
+ is treated as critical on the 405.
+
+./arch/powerpc/cpu/ppc4xx/traps.c
+ Added more detailed output for the program exception to tell
+ if it is an illegal instruction, privileged instruction or
+ a trap. Also added debug trap handler.
+
+./include/ppc_asm.tmpl
+ Added code to handle critical exceptions
+
+#################
+### New Stuff ###
+#################
+
+./include/bedbug/ppc.h
+./include/bedbug/regs.h
+./include/bedbug/bedbug.h
+./include/bedbug/elf.h [obsoleted by new include/elf.h]
+./include/bedbug/tables.h
+./include/cmd_bedbug.h
+./common/cmd_bedbug.c
+./common/bedbug.c
+ Bedbug library includes code for assembling and disassembling
+ PowerPC instructions to/from memory as well as handling
+ hardware breakpoints and stepping through code. These
+ routines are common to all PowerPC processors.
+
+./arch/powerpc/cpu/ppc4xx/bedbug_405.c
+ AMCC PPC405 specific debugger routines.
+
+
+Bedbug support for the MPC860
+-----------------------------
+
+Changes:
+
+ common/cmd_bedbug.c
+ Added call to initialize 860 debugger.
+
+ arch/powerpc/cpu/mpc8xx/Makefile
+ Added new file "bedbug_860.c" to the makefile
+
+ arch/powerpc/cpu/mpc8xx/start.S
+ Added handler for InstructionBreakpoint (0xfd00)
+
+ arch/powerpc/cpu/mpc8xx/traps.c
+ Added new routine DebugException()
+
+New Files:
+
+ arch/powerpc/cpu/mpc8xx/bedbug_860.c
+ CPU-specific routines for 860 debug registers.
diff --git a/roms/u-boot/doc/README.bitbangMII b/roms/u-boot/doc/README.bitbangMII
new file mode 100644
index 000000000..0a2fa48a5
--- /dev/null
+++ b/roms/u-boot/doc/README.bitbangMII
@@ -0,0 +1,56 @@
+This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
+support an arbitrary number of mii buses. This feature is useful when your
+board uses different mii buses for different phys and all (or a part) of these
+buses are implemented via bit-banging mode.
+
+The driver requires that the following macros should be defined into the board
+configuration file:
+
+CONFIG_BITBANGMII - Enable the miiphybb driver
+CONFIG_BITBANGMII_MULTI - Enable the multi bus support
+
+If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs
+to define at least the following macros:
+
+MII_INIT - Generic code to enable the MII bus (optional)
+MDIO_DECLARE - Declaration needed to access to the MDIO pin (optional)
+MDIO_ACTIVE - Activate the MDIO pin as out pin
+MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin
+MDIO_READ - Read the MDIO pin
+MDIO(v) - Write v on the MDIO pin
+MDC_DECLARE - Declaration needed to access to the MDC pin (optional)
+MDC(v) - Write v on the MDC pin
+
+The previous macros make the driver compatible with the previous version
+(that didn't support the multi-bus).
+
+When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill
+the bb_miiphy_buses[] array with a record for each required bus and declare
+the bb_miiphy_buses_num variable with the number of mii buses.
+The record (struct bb_miiphy_bus) has the following fields/callbacks (see
+miiphy.h for details):
+
+char name[] - The symbolic name that must be equal to the MII bus
+ registered name
+int (*init)() - Initialization function called at startup time (just
+ before the Ethernet initialization)
+int (*mdio_active)() - Activate the MDIO pin as output
+int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin
+int (*set_mdio)() - Write the MDIO pin
+int (*get_mdio)() - Read the MDIO pin
+int (*set_mdc)() - Write the MDC pin
+int (*delay)() - Delay function
+void *priv - Private data used by board specific code
+
+The board code will look like:
+
+struct bb_miiphy_bus bb_miiphy_buses[] = {
+ { .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... },
+ { .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... },
+ ...
+};
+int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) /
+ sizeof(bb_miiphy_buses[0]);
+
+2009 Industrie Dial Face S.p.A.
+ Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
diff --git a/roms/u-boot/doc/README.bloblist b/roms/u-boot/doc/README.bloblist
new file mode 100644
index 000000000..274c46055
--- /dev/null
+++ b/roms/u-boot/doc/README.bloblist
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+Blob Lists - bloblist
+=====================
+
+Introduction
+------------
+
+A bloblist provides a way to store collections of binary information (blobs) in
+a central structure. Each record of information is assigned a tag so that its
+owner can find it and update it. Each record is generally described by a C
+structure defined by the code that owns it.
+
+
+Passing state through the boot process
+--------------------------------------
+
+The bloblist is created when the first U-Boot component runs (often SPL,
+sometimes TPL). It is passed through to each successive part of the boot and
+can be accessed as needed. This provides a way to transfer state from one part
+to the next. For example, TPL may determine that a watchdog reset occurred by
+reading an SoC register. Reading the register may reset the value, so that it
+cannot be read a second time. So TPL can store that in a bloblist record which
+can be passed through to SPL and U-Boot proper, which can print a message
+indicating that something went wrong and the watchdog fired.
+
+
+Blobs
+-----
+
+While each blob in the bloblist can be of any length, bloblists are designed to
+hold small amounts of data, typically a few KB at most. It is not possible to
+change the length of a blob once it has been written. Each blob is normally
+created from a C structure which can beused to access its fields.
+
+
+Blob tags
+---------
+
+Each blob has a tag which is a 32-bit number. This uniquely identifies the
+owner of the blob. Blob tags are listed in enum blob_tag_t and are named
+with a BLOBT_ prefix.
+
+
+Single structure
+----------------
+
+There is normally only one bloblist in U-Boot. Since a bloblist can store
+multiple blobs it does not seem useful to allow multiple bloblists. Of course
+there could be reasons for this, such as needing to spread the blobs around in
+different memory areas due to fragmented memory, but it is simpler to just have
+a single bloblist.
+
+
+API
+---
+
+Bloblist provides a fairly simple API which allows blobs to be created and
+found. All access is via the blob's tag. Blob records are zeroed when added.
+
+
+Finishing the bloblist
+----------------------
+
+When a part of U-Boot is about to jump to the next part, it can 'finish' the
+bloblist in preparation for the next stage. This involves adding a checksum so
+that the next stage can make sure that the data arrived safely. While the
+bloblist is in use, changes can be made which will affect the checksum, so it
+is easier to calculate the checksum at the end after all changes are made.
+
+
+Future work
+-----------
+
+Bootstage has a mechanism to 'stash' its records for passing to the next part.
+This should move to using bloblist, to avoid having its own mechanism for
+passing information between U-Boot parts.
+
+
+Simon Glass
+sjg@chromium.org
+12-Aug-2018
diff --git a/roms/u-boot/doc/README.bootcount b/roms/u-boot/doc/README.bootcount
new file mode 100644
index 000000000..b1c22905c
--- /dev/null
+++ b/roms/u-boot/doc/README.bootcount
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Boot Count Limit
+================
+
+This allows to detect multiple failed attempts to boot Linux.
+
+After a power-on reset, "bootcount" variable will be initialized with 1, and
+each reboot will increment the value by 1.
+
+If, after a reboot, the new value of "bootcount" exceeds the value of
+"bootlimit", then instead of the standard boot action (executing the contents of
+"bootcmd") an alternate boot action will be performed, and the contents of
+"altbootcmd" will be executed.
+
+If the variable "bootlimit" is not defined in the environment, the Boot Count
+Limit feature is disabled. If it is enabled, but "altbootcmd" is not defined,
+then U-Boot will drop into interactive mode and remain there.
+
+It is the responsibility of some application code (typically a Linux
+application) to reset the variable "bootcount", thus allowing for more boot
+cycles.
+
+BOOTCOUNT_EXT
+-------------
+
+This adds support for maintaining boot count in a file on an EXT filesystem.
+The file to use is define by:
+
+SYS_BOOTCOUNT_EXT_INTERFACE
+SYS_BOOTCOUNT_EXT_DEVPART
+SYS_BOOTCOUNT_EXT_NAME
+
+The format of the file is:
+
+==== =================
+type entry
+==== =================
+u8 magic
+u8 version
+u8 bootcount
+u8 upgrade_available
+==== =================
+
+To prevent unattended usage of "altbootcmd" the "upgrade_available" variable is
+used.
+If "upgrade_available" is 0, "bootcount" is not saved, if "upgrade_available" is
+1 "bootcount" is save.
+So the Userspace Application must set the "upgrade_available" and "bootcount"
+variables to 0, if a boot was successfully.
+This also prevents writes on all reboots.
diff --git a/roms/u-boot/doc/README.boston b/roms/u-boot/doc/README.boston
new file mode 100644
index 000000000..38f6710e4
--- /dev/null
+++ b/roms/u-boot/doc/README.boston
@@ -0,0 +1,58 @@
+MIPS Boston Development Board
+
+---------
+ About
+---------
+
+The MIPS Boston development board is built around an FPGA & 3 PCIe controllers,
+one of which is connected to an Intel EG20T Platform Controller Hub which
+provides most connectivity to the board. It is used during the development &
+testing of both new CPUs and the software support for them. It is essentially
+the successor of the older MIPS Malta board.
+
+--------
+ QEMU
+--------
+
+U-Boot can be run on a currently out-of-tree branch of QEMU with support for
+the Boston board added. This QEMU code can currently be found in the "boston"
+branch of git://git.linux-mips.org/pub/scm/paul/qemu.git and used like so:
+
+ $ git clone git://git.linux-mips.org/pub/scm/paul/qemu.git -b boston
+ $ cd qemu
+ $ ./configure --target-list=mips64el-softmmu
+ $ make
+ $ ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
+ -bios u-boot.bin -serial stdio
+
+Please note that QEMU will default to emulating the I6400 CPU which implements
+the MIPS64r6 ISA, and at the time of writing doesn't implement any earlier CPUs
+with support for the CPS features the Boston board relies upon. You will
+therefore need to configure U-Boot to build for MIPSr6 in order to obtain a
+binary that will work in QEMU.
+
+-------------
+ Toolchain
+-------------
+
+If building for MIPSr6 then you will need a toolchain including GCC 5.x or
+newer, or the Codescape toolchain available for download from Imagination
+Technologies:
+
+ http://codescape-mips-sdk.imgtec.com/components/toolchain/2015.06-05/
+
+The "IMG GNU Linux Toolchain" is capable of building for all current MIPS ISAs,
+architecture revisions & both endiannesses.
+
+--------
+ TODO
+--------
+
+ - AHCI support
+ - CPU driver
+ - Exception handling (+UHI?)
+ - Flash support
+ - IOCU support
+ - L2 cache support
+ - More general LCD display driver
+ - Multi-arch-variant multi-endian fat binary
diff --git a/roms/u-boot/doc/README.bus_vcxk b/roms/u-boot/doc/README.bus_vcxk
new file mode 100644
index 000000000..aaa1565dd
--- /dev/null
+++ b/roms/u-boot/doc/README.bus_vcxk
@@ -0,0 +1,67 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2008-2009
+ * BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de>
+ * Jens Scharsig <esw@bus-elektronik.de>
+ */
+
+U-Boot vcxk video controller driver
+======================================
+
+By defining CONFIG_VIDEO_VCXK this driver can be used with VC2K, VC4K and
+VC8K devices on following boards:
+
+board | ARCH | Vendor
+-----------------------------------------------------------------------
+EB+CPU5282-T1 | MCF5282 | BuS Elektronik GmbH & Co. KG
+EB+MCF-EVB123 | MCF5282 | BuS Elektronik GmbH & Co. KG
+EB+CPUx9K2 | AT91RM9200 | BuS Elektronik GmbH & Co. KG
+ZLSA | AT91RM9200 | Ruf Telematik AG
+
+Driver configuration
+--------------------
+
+The driver needs some defines to describe the target hardware:
+
+CONFIG_SYS_VCXK_BASE
+
+ base address of VCxK hardware memory
+
+CONFIG_SYS_VCXK_DEFAULT_LINEALIGN
+
+ defines the physical alignment of a pixel row
+
+CONFIG_SYS_VCXK_DOUBLEBUFFERED
+
+ some boards that use vcxk prevent read from framebuffer memory.
+ define this option to enable double buffering (needs 16KiB RAM)
+
+CONFIG_SYS_VCXK_<xxxx>_PIN
+
+ defines the number of the I/O line PIN in the port
+ valid values for <xxxx> are:
+
+ ACKNOWLEDGE
+ describes the acknowledge line from vcxk hardware
+
+ ENABLE
+ describes the enable line to vcxk hardware
+
+ INVERT
+ describes the invert line to vcxk hardware
+
+ RESET
+ describes the reset line to vcxk hardware
+
+ REQUEST
+ describes the request line to vcxk hardware
+
+CONFIG_SYS_VCXK_<xxxx>_PORT
+
+ defines the I/O port which is connected with the line
+ for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN
+
+CONFIG_SYS_VCXK_<xxxx>_DDR
+
+ defines the register which configures the direction
+ for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN
diff --git a/roms/u-boot/doc/README.cfi b/roms/u-boot/doc/README.cfi
new file mode 100644
index 000000000..ad5285081
--- /dev/null
+++ b/roms/u-boot/doc/README.cfi
@@ -0,0 +1,63 @@
+The common CFI driver provides this weak default implementation for
+flash_cmd_reset():
+
+static void __flash_cmd_reset(flash_info_t *info)
+{
+ /*
+ * We do not yet know what kind of commandset to use, so we issue
+ * the reset command in both Intel and AMD variants, in the hope
+ * that AMD flash roms ignore the Intel command.
+ */
+ flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+ udelay(1);
+ flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
+}
+void flash_cmd_reset(flash_info_t *info)
+ __attribute__((weak,alias("__flash_cmd_reset")));
+
+Some flash chips seem to have trouble with this reset sequence.
+In this case, board-specific code can override this weak default
+version with a board-specific function.
+
+At the time of writing, there are two boards that define their own
+routine for this.
+
+First, the digsy_mtc board equipped with the M29W128GH from Numonyx
+needs this version to function properly:
+
+void flash_cmd_reset(flash_info_t *info)
+{
+ flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+}
+
+In addition, the t3corp board defines the routine thusly:
+
+void flash_cmd_reset(flash_info_t *info)
+{
+ /*
+ * FLASH at address CONFIG_SYS_FLASH_BASE is a Spansion chip and
+ * needs the Spansion type reset commands. The other flash chip
+ * is located behind a FPGA (Xilinx DS617) and needs the Intel type
+ * reset command.
+ */
+ if (info->start[0] == CONFIG_SYS_FLASH_BASE)
+ flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+ else
+ flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
+}
+
+see also:
+http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html
+
+
+Config Option
+
+ CONFIG_SYS_MAX_FLASH_SECT: Number of sectors available on Flash device
+
+ CONFIG_SYS_FLASH_CFI_WIDTH: Data-width of the flash device
+
+ CONFIG_CMD_FLASH: Enables Flash command library
+
+ CONFIG_FLASH_CFI_DRIVER: Enables CFI Flash driver
+
+ CONFIG_FLASH_CFI_MTD: Enables MTD frame work for NOR Flash devices
diff --git a/roms/u-boot/doc/README.commands.itest b/roms/u-boot/doc/README.commands.itest
new file mode 100644
index 000000000..5e0fe8624
--- /dev/null
+++ b/roms/u-boot/doc/README.commands.itest
@@ -0,0 +1,16 @@
+A slow day today so here is a revised itest command with provisional
+support for comparing strings as well :-))
+
+Now table driven to allow the operators
+-eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >=
+
+Uses the expected command modifier for integer compares of width 1, 2 or
+4 bytes of .b, .w, .l and the new modifer of .s for a string compare.
+String comparison is over the length of the shorter, this hopefully
+avoids missing terminators when using an indirect pointer.
+
+eg.
+if itest.l *40000 == 12345678 then; ....
+if itest.w *40000 != 1234 then; ....
+if itest.b *40000 >= 12 then; ....
+if itest.s *40000 -eq hello then; ....
diff --git a/roms/u-boot/doc/README.commands.spl b/roms/u-boot/doc/README.commands.spl
new file mode 100644
index 000000000..cb3e0c8e0
--- /dev/null
+++ b/roms/u-boot/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 <fdt|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/roms/u-boot/doc/README.console b/roms/u-boot/doc/README.console
new file mode 100644
index 000000000..9f5812c89
--- /dev/null
+++ b/roms/u-boot/doc/README.console
@@ -0,0 +1,100 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ */
+
+U-Boot console handling
+========================
+
+HOW THE CONSOLE WORKS?
+----------------------
+
+At system startup U-Boot initializes a serial console. When U-Boot
+relocates itself to RAM, all console drivers are initialized (they
+will register all detected console devices to the system for further
+use).
+
+If not defined in the environment, the first input device is assigned
+to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
+
+You can use the command "coninfo" to see all registered console
+devices and their flags. You can assign a standard file (stdin,
+stdout or stderr) to any device you see in that list simply by
+assigning its name to the corresponding environment variable. For
+example:
+
+ setenv stdin serial <- To use the serial input
+ setenv stdout video <- To use the video console
+
+Do a simple "saveenv" to save the console settings in the environment
+and get them working on the next startup, too.
+
+HOW CAN I USE STANDARD FILE INTO THE SOURCES?
+---------------------------------------------
+
+You can use the following functions to access the console:
+
+* STDOUT:
+ putc (to put a char to stdout)
+ puts (to put a string to stdout)
+ printf (to format and put a string to stdout)
+
+* STDIN:
+ tstc (to test for the presence of a char in stdin)
+ getc (to get a char from stdin)
+
+* STDERR:
+ eputc (to put a char to stderr)
+ eputs (to put a string to stderr)
+ eprintf (to format and put a string to stderr)
+
+* FILE (can be 'stdin', 'stdout', 'stderr'):
+ fputc (like putc but redirected to a file)
+ fputs (like puts but redirected to a file)
+ fprintf (like printf but redirected to a file)
+ ftstc (like tstc but redirected to a file)
+ fgetc (like getc but redirected to a file)
+
+Remember that all FILE-related functions CANNOT be used before
+U-Boot relocation (done in 'board_init_r' in arch/*/lib/board.c).
+
+HOW CAN I USE STANDARD FILE INTO APPLICATIONS?
+----------------------------------------------
+
+Use the 'bd_mon_fnc' field of the bd_info structure passed to the
+application to do everything you want with the console.
+
+But REMEMBER that that will work only if you have not overwritten any
+U-Boot code while loading (or uncompressing) the image of your
+application.
+
+For example, you won't get the console stuff running in the Linux
+kernel because the kernel overwrites U-Boot before running. Only
+some parameters like the framebuffer descriptors are passed to the
+kernel in the high memory area to let the applications (the kernel)
+use the framebuffers initialized by U-Boot.
+
+SUPPORTED DRIVERS
+-----------------
+
+Working drivers:
+
+ serial (architecture dependent serial stuff)
+ video (mpc8xx video controller)
+
+Work in progress:
+
+ wl_kbd (Wireless 4PPM keyboard)
+
+Waiting for volounteers:
+
+ lcd (mpc8xx lcd controller; to )
+
+TESTED CONFIGURATIONS
+---------------------
+
+The driver has been tested with the following configurations (see
+CREDITS for other contact informations):
+
+- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
diff --git a/roms/u-boot/doc/README.davinci b/roms/u-boot/doc/README.davinci
new file mode 100644
index 000000000..607531af2
--- /dev/null
+++ b/roms/u-boot/doc/README.davinci
@@ -0,0 +1,82 @@
+Summary
+=======
+
+Note: this document used to be about the entire family of DaVinci SOCs but the
+support for the DM* family and DA830 has since been dropped.
+
+This README is about U-Boot support for TI's DA850 SoC. This SOC has an OMAP
+part number but is very similar to the DaVinci series.
+
+Currently the following boards are supported:
+
+* TI DA850 EVM
+
+* TI OMAP-L138 LCDK
+
+* Lego EV3
+
+Build
+=====
+
+* TI DA850 EVM:
+
+make da850evm_config
+make
+
+* TI OMAP-L138 LCDK
+
+make omapl138_lcdk_defconfig
+make
+
+* Lego EV3
+
+make legoev3_defconfig
+make
+
+Bootloaders
+===============
+
+For DA850 an SPL (secondary program loader, see doc/README.SPL) is provided
+to load U-Boot from SPI flash, MMC or NAND. The SPL takes care of the low level
+initialization.
+
+The SPL is built as u-boot.ais for all DA850 defconfigs except those booting
+from NOR flash. The resulting image file can be programmed to the SPI flash
+of the DA850 EVM/LCDK.
+
+Devices that support booting from NOR utilize execute in place (XIP) and do
+not require SPL to perform low level initialization.
+
+Environment Variables
+=====================
+
+The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
+silicon, in Hz, via an environment variable "maxcpuclk".
+
+The maximum clock rate allowed depends on the silicon populated on the EVM.
+Please make sure you understand the restrictions placed on this clock in the
+device specific datasheet before setting up this variable. This information is
+passed to the Linux kernel using the ATAG_REVISION atag.
+
+If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
+is used to obtain this information.
+
+Links
+=====
+
+1) TI DA850 EVM
+http://focus.ti.com/docs/prod/folders/print/omap-l138.html
+http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit
+
+2) TI OMAP-L138 LCDK
+http://focus.ti.com/docs/prod/folders/print/omap-l138.html
+http://www.ti.com/tool/TMDXLCDK138
+
+Davinci special defines
+=======================
+
+CONFIG_SYS_DV_NOR_BOOT_CFG: AM18xx based boards, booting in NOR Boot mode
+ need a "NOR Boot Configuration Word" stored
+ in the NOR Flash. This define adds this.
+ More Info about this, see:
+ spraba5a.pdf chapter 3.1
diff --git a/roms/u-boot/doc/README.davinci.nand_spl b/roms/u-boot/doc/README.davinci.nand_spl
new file mode 100644
index 000000000..f46721a00
--- /dev/null
+++ b/roms/u-boot/doc/README.davinci.nand_spl
@@ -0,0 +1,141 @@
+With this approach, we don't need the UBL any more on DaVinci boards.
+A "make boardname" will compile a u-boot.ubl, with UBL Header, which is
+needed for the RBL to find the "UBL", which actually is a UBL-compatible
+header, nand spl code and u-boot code.
+
+
+As the RBL uses another read function as the "standard" u-boot,
+we need a command, which switches between this two read/write
+functions, so we can write the UBL header and the spl
+code in a format, which the RBL can read. This is realize
+(at the moment in board specific code) in the u-boot command
+nandrbl
+
+nandrbl without arguments returns actual mode (rbl or uboot).
+with nandrbl mode (mode = "rbl" or "uboot") you can switch
+between the two NAND read/write modes.
+
+
+To set up mkimage you need a config file for mkimage, example:
+board/ait/cam_enc_4xx/ublimage.cfg
+
+For information about the configuration please see:
+doc/README.ublimage
+
+Example for the cam_enc_4xx board:
+On the cam_enc_4xx board we have a NAND flash with blocksize = 0x20000 and
+pagesize = 0x800, so the u-boot.ubl image (which you get with:
+"make cam_enc_4xx") looks like this:
+
+00000000 00 ed ac a1 20 00 00 00 06 00 00 00 05 00 00 00 |.... ...........|
+00000010 00 00 00 00 20 00 00 00 ff ff ff ff ff ff ff ff |.... ...........|
+00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
+*
+00000800 14 00 00 ea 14 f0 9f e5 10 f0 9f e5 0c f0 9f e5 |................|
+00000810 08 f0 9f e5 04 f0 9f e5 00 f0 9f e5 04 f0 1f e5 |................|
+00000820 00 01 00 00 78 56 34 12 78 56 34 12 78 56 34 12 |....xV4.xV4.xV4.|
+[...]
+*
+00001fe0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
+00001ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
+*
+00003800 14 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
+00003810 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
+00003820 80 01 08 81 e0 01 08 81 40 02 08 81 a0 02 08 81 |........@.......|
+
+In the first "page" of the image, we have the UBL Header, needed for
+the RBL to find the spl code.
+
+The spl code starts in the second "page" of the image, with a size
+defined by:
+
+#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
+
+After the spl code, there comes the "real" u-boot code
+@ (6 + 1) * pagesize = 0x3800
+
+------------------------------------------------------------------------
+Setting up spl code:
+
+/*
+ * RBL searches from Block n (n = 1..24)
+ * so we can define, how many UBL Headers
+ * we write before the real spl code
+ */
+#define CONFIG_SYS_NROF_UBL_HEADER 5
+#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
+
+#define CONFIG_SYS_NAND_U_BOOT_OFFS ((CONFIG_SYS_NROF_UBL_HEADER * \
+ CONFIG_SYS_NAND_BLOCK_SIZE) + \
+ (CONFIG_SYS_NROF_PAGES_NAND_SPL) * \
+ CONFIG_SYS_NAND_PAGE_SIZE)
+------------------------------------------------------------------------
+
+Burning into NAND:
+
+step 1:
+The RBL searches from Block n ( n = 1..24) on page 0 for valid UBL
+Headers, so you have to burn the UBL header page from the u-boot.ubl
+image to the blocks, you want to have the UBL header.
+!! Don;t forget to switch to rbl nand read/write functions with
+ "nandrbl rbl"
+
+step 2:
+You need to setup in the ublimage.cfg, where the RBL can find the spl
+code, and how big it is.
+
+!! RBL always starts reading from page 0 !!
+
+For the AIT board, we have:
+PAGES 6
+START_BLOCK 5
+
+So we need to copy the spl code to block 5 page 0
+!! Don;t forget to switch to rbl nand read/write functions with
+ "nandrbl rbl"
+
+step 3:
+You need to copy the u-boot image to the block/page
+where the spl code reads it (CONFIG_SYS_NAND_U_BOOT_OFFS)
+!! Don;t forget to switch to rbl nand read/write functions with
+ "nandrbl uboot", which is default.
+
+On the cam_enc_4xx board it is:
+#define CONFIG_SYS_NAND_U_BOOT_OFFS (0xc0000)
+
+-> this results in following NAND usage on the cam_enc_4xx board:
+
+addr
+
+20000 possible UBL Header
+40000 possible UBL Header
+60000 possible UBL Header
+80000 possilbe UBL Header
+a0000 spl code
+c0000 u-boot code
+
+The above steps are executeed through the following environment vars:
+(using 80000 as address for the UBL header)
+
+pagesz=800
+uboot=/tftpboot/cam_enc_4xx/u-boot.ubl
+load=tftp 80000000 ${uboot}
+writeheader nandrbl rbl;nand erase 80000 ${pagesz};nand write 80000000 80000 ${pagesz};nandrbl uboot
+writenand_spl nandrbl rbl;nand erase a0000 3000;nand write 80000800 a0000 3000;nandrbl uboot
+writeuboot nandrbl uboot;nand erase c0000 5d000;nand write 80003800 c0000 5d000
+update=run load writeheader writenand_spl writeuboot
+
+If you do a "run load update" u-boot, spl + ubl header
+are magically updated ;-)
+
+Note:
+- There seem to be a bug in the RBL code (at least on my HW),
+ In the UBL block, I can set the page to values != 0, so it
+ is possible to burn step 1 and step 2 in one step into the
+ flash, but the RBL ignores the page settings, so I have to
+ burn the UBL Header to a page 0 and the spl code to
+ a page 0 ... :-(
+- If we make the nand read/write functions in the RBL equal to
+ the functions in u-boot (as I have no RBL code, it is only
+ possible in u-boot), we could burn the complete image in
+ one step ... that would be nice ...
diff --git a/roms/u-boot/doc/README.dfutftp b/roms/u-boot/doc/README.dfutftp
new file mode 100644
index 000000000..a3341bbb6
--- /dev/null
+++ b/roms/u-boot/doc/README.dfutftp
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2015
+#
+# Lukasz Majewski <l.majewski@majess.pl>
+
+Device Firmware Upgrade (DFU) - extension to use TFTP
+=====================================================
+
+Why?
+----
+
+* Update TFTP (CONFIG_UPDATE_TFTP) only supports writing
+code to NAND memory via TFTP.
+* DFU supports writing data to the variety of mediums (NAND,
+eMMC, SD, partitions, RAM, etc) via USB.
+
+Combination of both solves their shortcomings!
+
+
+Overview
+--------
+
+This document briefly describes how to use DFU for
+upgrading firmware (e.g. kernel, u-boot, rootfs, etc.)
+via TFTP protocol.
+
+By using Ethernet (TFTP protocol to be precise) it is
+possible to overcome the major problem of USB based DFU -
+the relatively low transfer speed for large files.
+This was caused by DFU standard, which imposed utilization
+of only EP0 for transfer. By using Ethernet we can circumvent
+this shortcoming.
+
+Beagle Bone Black rev. C (BBB) powered by TI's am335x CPU has
+been used as a demo board.
+
+To utilize this feature, one needs to first enable support
+for USB based DFU (CONFIG_DFU_*) and DFU TFTP update
+(CONFIG_DFU_TFTP) described in ./doc/README.update.
+
+The "dfu" command has been extended to support transfer via TFTP - one
+needs to type for example "dfu tftp 0 mmc 0"
+
+As of this writing (SHA1:8d77576371381ade83de475bb639949b44941e8c v2015.10-rc2)
+the update.c code is not enabled (CONFIG_UPDATE_TFTP) by any board in the
+contemporary u-boot tree.
+
+
+Environment variables
+---------------------
+
+The "dfu tftp" command can be used in the "preboot" environment variable
+(when it is enabled by defining CONFIG_PREBOOT).
+This is the preferable way of using this command in the early boot stage
+as opposed to legacy update_tftp() function invocation.
+
+
+Beagle Bone Black (BBB) setup
+-----------------------------
+
+1. Setup tftp env variables:
+ * select desired eth device - 'ethact' variable ["ethact=cpsw"]
+ (use "bdinfo" to check current setting)
+ * setup "serverip" and "ipaddr" variables
+ * set "loadaddr" as a fixed buffer where incoming data is placed
+ ["loadaddr=0x81000000"]
+
+#########
+# BONUS #
+#########
+It is possible to use USB interface to emulate ETH connection by setting
+"ethact=usb_ether". In this way one can have very fast DFU transfer via USB.
+
+For 33MiB test image the transfer rate was 1MiB/s for ETH over USB and 200KiB/s
+for pure DFU USB transfer.
+
+2. Setup update_tftp variables:
+ * set "updatefile" - the file name to be downloaded via TFTP (stored on
+ the HOST at e.g. /srv/tftp)
+
+3. If required, to update firmware on boot, put the "dfu tftp 0 mmc 0" in the
+ "preboot" env variable. Otherwise use this command from u-boot prompt.
+
+4. Inspect "dfu" specific variables:
+ * "dfu_alt_info" - information about available DFU entities
+ * "dfu_bufsiz" - variable to set buffer size [in bytes] - when it is not
+ possible to set large enough default buffer (8 MiB @ BBB)
+
+
+
+FIT image format for download
+-----------------------------
+
+To create FIT image for download one should follow the update tftp README file
+(./doc/README.update) with one notable difference:
+
+The original snippet of ./doc/uImage.FIT/update_uboot.its
+
+ images {
+ update@1 {
+ description = "U-Boot binary";
+
+should look like
+
+ images {
+ u-boot.bin@1 {
+ description = "U-Boot binary";
+
+where "u-boot.bin" is the DFU entity name to be stored.
+
+
+
+To do
+-----
+
+* Extend dfu-util command to support TFTP based transfers
+* Upload support (via TFTP)
diff --git a/roms/u-boot/doc/README.displaying-bmps b/roms/u-boot/doc/README.displaying-bmps
new file mode 100644
index 000000000..331154166
--- /dev/null
+++ b/roms/u-boot/doc/README.displaying-bmps
@@ -0,0 +1,27 @@
+If you are experiencing hangups/data-aborts when trying to display a BMP image,
+the following might be relevant to your situation...
+
+Some architectures cannot handle unaligned memory accesses, and an attempt to
+perform one will lead to a data abort. On such architectures it is necessary to
+make sure all data is properly aligned, and in many situations simply choosing
+a 32 bit aligned address is enough to ensure proper alignment. This is not
+always the case when dealing with data that has an internal layout such as a
+BMP image:
+
+BMP images have a header that starts with 2 byte-size fields followed by mostly
+32 bit fields. The packed struct that represents this header can be seen below:
+
+typedef struct bmp_header {
+ /* Header */
+ char signature[2];
+ __u32 file_size;
+ __u32 reserved;
+ __u32 data_offset;
+ ... etc
+} __attribute__ ((packed)) bmp_header_t;
+
+When placed in an aligned address such as 0x80a00000, char signature offsets
+the __u32 fields into unaligned addresses (in our example 0x80a00002,
+0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit
+access is generated at a non-32-bit-aligned address, causing a data abort.
+The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2.
diff --git a/roms/u-boot/doc/README.distro b/roms/u-boot/doc/README.distro
new file mode 100644
index 000000000..c4f041ca7
--- /dev/null
+++ b/roms/u-boot/doc/README.distro
@@ -0,0 +1,430 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 Red Hat Inc.
+ * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (C) 2015 K. Merker <merker@debian.org>
+ */
+
+Generic Distro Configuration Concept
+====================================
+
+Linux distributions are faced with supporting a variety of boot mechanisms,
+environments or bootloaders (PC BIOS, EFI, U-Boot, Barebox, ...). This makes
+life complicated. Worse, bootloaders such as U-Boot have a configurable set
+of features, and each board chooses to enable a different set of features.
+Hence, distros typically need to have board-specific knowledge in order to
+set up a bootable system.
+
+This document defines a common set of U-Boot features that are required for
+a distro to support the board in a generic fashion. Any board wishing to
+allow distros to install and boot in an out-of-the-box fashion should enable
+all these features. Linux distros can then create a single set of boot
+support/install logic that targets these features. This will allow distros
+to install on many boards without the need for board-specific logic.
+
+In fact, some of these features can be implemented by any bootloader, thus
+decoupling distro install/boot logic from any knowledge of the bootloader.
+
+This model assumes that boards will load boot configuration files from a
+regular storage mechanism (eMMC, SD card, USB Disk, SATA disk, etc.) with
+a standard partitioning scheme (MBR, GPT). Boards that cannot support this
+storage model are outside the scope of this document, and may still need
+board-specific installer/boot-configuration support in a distro.
+
+To some extent, this model assumes that a board has a separate boot flash
+that contains U-Boot, and that the user has somehow installed U-Boot to this
+flash before running the distro installer. Even on boards that do not conform
+to this aspect of the model, the extent of the board-specific support in the
+distro installer logic would be to install a board-specific U-Boot package to
+the boot partition during installation. This distro-supplied U-Boot can still
+implement the same features as on any other board, and hence the distro's boot
+configuration file generation logic can still be board-agnostic.
+
+Locating Bootable Disks
+-----------------------
+
+Typical desktop/server PCs search all (or a user-defined subset of) attached
+storage devices for a bootable partition, then load the bootloader or boot
+configuration files from there. A U-Boot board port that enables the features
+mentioned in this document will search for boot configuration files in the
+same way.
+
+Thus, distros do not need to manipulate any kind of bootloader-specific
+configuration data to indicate which storage device the system should boot
+from.
+
+Distros simply need to install the boot configuration files (see next
+section) in an ext2/3/4 or FAT partition, mark the partition bootable (via
+the MBR bootable flag, or GPT legacy_bios_bootable attribute), and U-Boot (or
+any other bootloader) will find those boot files and execute them. This is
+conceptually identical to creating a grub2 configuration file on a desktop
+PC.
+
+Note that in the absence of any partition that is explicitly marked bootable,
+U-Boot falls back to searching the first valid partition of a disk for boot
+configuration files. Other bootloaders are recommended to do the same, since
+I believe that partition table bootable flags aren't so commonly used outside
+the realm of x86 PCs.
+
+U-Boot can also search for boot configuration files from a TFTP server.
+
+Boot Configuration Files
+------------------------
+
+The standard format for boot configuration files is that of extlinux.conf, as
+handled by U-Boot's "syslinux" (disk) or "pxe boot" (network). This is roughly
+as specified at:
+
+http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
+
+... with the exceptions that the BootLoaderSpec document:
+
+* Prescribes a separate configuration per boot menu option, whereas U-Boot
+ lumps all options into a single extlinux.conf file. Hence, U-Boot searches
+ for /extlinux/extlinux.conf then /boot/extlinux/extlinux.conf on disk, or
+ pxelinux.cfg/default over the network.
+
+* Does not document the fdtdir option, which automatically selects the DTB to
+ pass to the kernel.
+
+One example extlinux.conf generated by the Fedora installer is:
+
+------------------------------------------------------------
+# extlinux.conf generated by anaconda
+
+ui menu.c32
+
+menu autoboot Welcome to Fedora. Automatic boot in # second{,s}. Press a key for options.
+menu title Fedora Boot Options.
+menu hidden
+
+timeout 50
+#totaltimeout 9000
+
+default Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae) 22 (Rawhide)
+
+label Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl) 22 (Rawhide)
+ kernel /boot/vmlinuz-3.17.0-0.rc4.git2.1.fc22.armv7hl
+ append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 LANG=en_US.UTF-8 drm.debug=0xf
+ fdtdir /boot/dtb-3.17.0-0.rc4.git2.1.fc22.armv7hl
+ initrd /boot/initramfs-3.17.0-0.rc4.git2.1.fc22.armv7hl.img
+
+label Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae) 22 (Rawhide)
+ kernel /boot/vmlinuz-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae
+ append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 LANG=en_US.UTF-8 drm.debug=0xf
+ fdtdir /boot/dtb-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae
+ initrd /boot/initramfs-3.17.0-0.rc4.git2.1.fc22.armv7hl+lpae.img
+
+label Fedora-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc (0-rescue-8f6ba7b039524e0eb957d2c9203f04bc)
+ kernel /boot/vmlinuz-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc
+ initrd /boot/initramfs-0-rescue-8f6ba7b039524e0eb957d2c9203f04bc.img
+ append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8
+ fdtdir /boot/dtb-3.16.0-0.rc6.git1.1.fc22.armv7hl+lpae
+------------------------------------------------------------
+
+Another hand-crafted network boot configuration file is:
+
+------------------------------------------------------------
+TIMEOUT 100
+
+MENU TITLE TFTP boot options
+
+LABEL jetson-tk1-emmc
+ MENU LABEL ../zImage root on Jetson TK1 eMMC
+ LINUX ../zImage
+ FDTDIR ../
+ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=80a5a8e9-c744-491a-93c1-4f4194fd690b
+
+LABEL venice2-emmc
+ MENU LABEL ../zImage root on Venice2 eMMC
+ LINUX ../zImage
+ FDTDIR ../
+ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f
+
+LABEL sdcard
+ MENU LABEL ../zImage, root on 2GB sdcard
+ LINUX ../zImage
+ FDTDIR ../
+ APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7
+
+LABEL fedora-installer-fk
+ MENU LABEL Fedora installer w/ Fedora kernel
+ LINUX fedora-installer/vmlinuz
+ INITRD fedora-installer/initrd.img.orig
+ FDTDIR fedora-installer/dtb
+ APPEND loglevel=8 ip=dhcp inst.repo=http://10.0.0.2/mirrors/fedora/linux/development/rawhide/armhfp/os/ rd.shell cma=64M
+------------------------------------------------------------
+
+U-Boot Implementation
+=====================
+
+Enabling the distro options
+---------------------------
+
+In your board's defconfig, enable the DISTRO_DEFAULTS option by adding
+a line with "CONFIG_DISTRO_DEFAULTS=y". If you want to enable this
+from Kconfig itself, for e.g. all boards using a specific SoC then
+add a "imply DISTRO_DEFAULTS" to your SoC CONFIG option.
+
+In your board configuration file, include the following:
+
+------------------------------------------------------------
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_bootcmd.h>
+#endif
+------------------------------------------------------------
+
+The first of those headers primarily enables a core set of U-Boot features,
+such as support for MBR and GPT partitions, ext* and FAT filesystems, booting
+raw zImage and initrd (rather than FIT- or uImage-wrapped files), etc. Network
+boot support is also enabled here, which is useful in order to boot distro
+installers given that distros do not commonly distribute bootable install
+media for non-PC targets at present.
+
+Finally, a few options that are mostly relevant only when using U-Boot-
+specific boot.scr scripts are enabled. This enables distros to generate a
+U-Boot-specific boot.scr script rather than extlinux.conf as the boot
+configuration file. While doing so is fully supported, and
+CONFIG_DISTRO_DEFAULTS exposes enough parameterization to boot.scr to
+allow for board-agnostic boot.scr content, this document recommends that
+distros generate extlinux.conf rather than boot.scr. extlinux.conf is intended
+to work across multiple bootloaders, whereas boot.scr will only work with
+U-Boot. TODO: document the contract between U-Boot and boot.scr re: which
+environment variables a generic boot.scr may rely upon.
+
+The second of those headers sets up the default environment so that $bootcmd
+is defined in a way that searches attached disks for boot configuration files,
+and executes them if found.
+
+Required Environment Variables
+------------------------------
+
+The U-Boot "syslinux" and "pxe boot" commands require a number of environment
+variables be set. Default values for these variables are often hard-coded into
+CONFIG_EXTRA_ENV_SETTINGS in the board's U-Boot configuration file, so that
+the user doesn't have to configure them.
+
+fdt_addr:
+
+ Mandatory for any system that provides the DTB in HW (e.g. ROM) and wishes
+ to pass that DTB to Linux, rather than loading a DTB from the boot
+ filesystem. Prohibited for any other system.
+
+ If specified a DTB to boot the system must be available at the given
+ address.
+
+fdt_addr_r:
+
+ Mandatory. The location in RAM where the DTB will be loaded or copied to when
+ processing the fdtdir/devicetreedir or fdt/devicetree options in
+ extlinux.conf.
+
+ This is mandatory even when fdt_addr is provided, since extlinux.conf must
+ always be able to provide a DTB which overrides any copy provided by the HW.
+
+ A size of 1MB for the FDT/DTB seems reasonable.
+
+fdtfile:
+
+ Mandatory. the name of the DTB file for the specific board for instance
+ the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+ while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+ a board providing its firmware based DTB this value can be used to override
+ the DTB with a different DTB. fdtfile will automatically be set for you if
+ it matches the format ${soc}-${board}.dtb which covers most 32 bit use cases.
+ AArch64 generally does not match as the Linux kernel put the dtb files under
+ SoC vendor directories.
+
+ramdisk_addr_r:
+
+ Mandatory. The location in RAM where the initial ramdisk will be loaded to
+ when processing the initrd option in extlinux.conf.
+
+ It is recommended that this location be highest in RAM out of fdt_addr_,
+ kernel_addr_r, and ramdisk_addr_r, so that the RAM disk can vary in size
+ and use any available RAM.
+
+kernel_addr_r:
+
+ Mandatory. The location in RAM where the kernel will be loaded to when
+ processing the kernel option in the extlinux.conf.
+
+ The kernel should be located within the first 128M of RAM in order for the
+ kernel CONFIG_AUTO_ZRELADDR option to work, which is likely enabled on any
+ distro kernel. Since the kernel will decompress itself to 0x8000 after the
+ start of RAM, kernel_addr_r should not overlap that area, or the kernel will
+ have to copy itself somewhere else first before decompression.
+
+ A size of 16MB for the kernel is likely adequate.
+
+kernel_comp_addr_r:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image(.gz, .bz2, .lzma, .lzo) using the booti command. It represents the
+ location in RAM where the compressed Image will be decompressed temporarily.
+ Once the decompression is complete, the decompressed data will be moved to
+ kernel_addr_r for booting.
+
+kernel_comp_size:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image using booti command. It represents the size of the compressed file. The
+ size has to at least the size of loaded image for decompression to succeed.
+
+pxefile_addr_r:
+
+ Mandatory. The location in RAM where extlinux.conf will be loaded to prior
+ to processing.
+
+ A size of 1MB for extlinux.conf is more than adequate.
+
+scriptaddr:
+
+ Mandatory, if the boot script is boot.scr rather than extlinux.conf. The
+ location in RAM where boot.scr will be loaded to prior to execution.
+
+ A size of 1MB for extlinux.conf is more than adequate.
+
+For suggestions on memory locations for ARM systems, you must follow the
+guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
+
+For a commented example of setting these values, please see the definition of
+MEM_LAYOUT_ENV_SETTINGS in include/configs/tegra124-common.h.
+
+Boot Target Configuration
+-------------------------
+
+<config_distro_bootcmd.h> defines $bootcmd and many helper command variables
+that automatically search attached disks for boot configuration files and
+execute them. Boards must provide configure <config_distro_bootcmd.h> so that
+it supports the correct set of possible boot device types. To provide this
+configuration, simply define macro BOOT_TARGET_DEVICES prior to including
+<config_distro_bootcmd.h>. For example:
+
+------------------------------------------------------------
+#ifndef CONFIG_SPL_BUILD
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 1) \
+ func(MMC, mmc, 0) \
+ func(USB, usb, 0) \
+ func(PXE, pxe, na) \
+ func(DHCP, dhcp, na)
+#include <config_distro_bootcmd.h>
+#endif
+------------------------------------------------------------
+
+Each entry in the macro defines a single boot device (e.g. a specific eMMC
+device or SD card) or type of boot device (e.g. USB disk). The parameters to
+the func macro (passed in by the internal implementation of the header) are:
+
+- Upper-case disk type (MMC, SATA, SCSI, IDE, USB, DHCP, PXE, VIRTIO).
+- Lower-case disk type (same options as above).
+- ID of the specific disk (MMC only) or ignored for other types.
+
+User Configuration
+==================
+
+Once the user has installed U-Boot, it is expected that the environment will
+be reset to the default values in order to enable $bootcmd and friends, as set
+up by <config_distro_bootcmd.h>. After this, various environment variables may
+be altered to influence the boot process:
+
+boot_targets:
+
+ The list of boot locations searched.
+
+ Example: mmc0, mmc1, usb, pxe
+
+ Entries may be removed or re-ordered in this list to affect the boot order.
+
+boot_prefixes:
+
+ For disk-based booting, the list of directories within a partition that are
+ searched for boot configuration files (extlinux.conf, boot.scr).
+
+ Example: / /boot/
+
+ Entries may be removed or re-ordered in this list to affect the set of
+ directories which are searched.
+
+boot_scripts:
+
+ The name of U-Boot style boot.scr files that $bootcmd searches for.
+
+ Example: boot.scr.uimg boot.scr
+
+ (Typically we expect extlinux.conf to be used, but execution of boot.scr is
+ maintained for backwards-compatibility.)
+
+ Entries may be removed or re-ordered in this list to affect the set of
+ filenames which are supported.
+
+scan_dev_for_extlinux:
+
+ If you want to disable extlinux.conf on all disks, set the value to something
+ innocuous, e.g. setenv scan_dev_for_extlinux true.
+
+scan_dev_for_scripts:
+
+ If you want to disable boot.scr on all disks, set the value to something
+ innocuous, e.g. setenv scan_dev_for_scripts true.
+
+boot_net_usb_start:
+
+ If you want to prevent USB enumeration by distro boot commands which execute
+ network operations, set the value to something innocuous, e.g. setenv
+ boot_net_usb_start true. This would be useful if you know your Ethernet
+ device is not attached to USB, and you wish to increase boot speed by
+ avoiding unnecessary actions.
+
+boot_net_pci_enum:
+
+ If you want to prevent PCI enumeration by distro boot commands which execute
+ network operations, set the value to something innocuous, e.g. setenv
+ boot_net_pci_enum true. This would be useful if you know your Ethernet
+ device is not attached to PCI, and you wish to increase boot speed by
+ avoiding unnecessary actions.
+
+Interactively booting from a specific device at the u-boot prompt
+=================================================================
+
+For interactively booting from a user-selected device at the u-boot command
+prompt, the environment provides predefined bootcmd_<target> variables for
+every target defined in boot_targets, which can be run be the user.
+
+If the target is a storage device, the format of the target is always
+<device type><device number>, e.g. mmc0. Specifying the device number is
+mandatory for storage devices, even if only support for a single instance
+of the storage device is actually implemented.
+
+For network targets (dhcp, pxe), only the device type gets specified;
+they do not have a device number.
+
+Examples:
+
+ - run bootcmd_usb0
+ boots from the first USB mass storage device
+
+ - run bootcmd_mmc1
+ boots from the second MMC device
+
+ - run bootcmd_pxe
+ boots by tftp using a pxelinux.cfg
+
+The list of possible targets consists of:
+
+- network targets
+ * dhcp
+ * pxe
+
+- storage targets (to which a device number must be appended)
+ * mmc
+ * sata
+ * scsi
+ * ide
+ * usb
+ * virtio
+
+Other *boot* variables than the ones defined above are only for internal use
+of the boot environment and are not guaranteed to exist or work in the same
+way in future u-boot versions. In particular the <device type>_boot
+variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation
+detail and must not be used as a public interface.
diff --git a/roms/u-boot/doc/README.dns b/roms/u-boot/doc/README.dns
new file mode 100644
index 000000000..8dff454b1
--- /dev/null
+++ b/roms/u-boot/doc/README.dns
@@ -0,0 +1,62 @@
+Domain Name System
+-------------------------------------------
+
+The Domain Name System (DNS) is a hierarchical naming system for computers,
+services, or any resource participating in the Internet. It associates various
+information with domain names assigned to each of the participants. Most
+importantly, it translates domain names meaningful to humans into the numerical
+(binary) identifiers associated with networking equipment for the purpose of
+locating and addressing these devices world-wide. An often used analogy to
+explain the Domain Name System is that it serves as the "phone book" for the
+Internet by translating human-friendly computer hostnames into IP addresses.
+For example, www.example.com translates to 208.77.188.166.
+
+For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
+
+U-Boot and DNS
+------------------------------------------
+
+CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
+ will send name lookups to the dns server (env var 'dnsip')
+ Turning this option on will about abou 1k to U-Boot's size.
+
+ Example:
+
+bfin> print dnsip
+dnsip=192.168.0.1
+
+bfin> dns www.google.com
+66.102.1.104
+
+ By default, dns does nothing except print the IP number on
+ the default console - which by itself, would be pretty
+ useless. Adding a third argument to the dns command will
+ use that as the environment variable to be set.
+
+ Example:
+
+bfin> print googleip
+## Error: "googleip" not defined
+bfin> dns www.google.com googleip
+64.233.161.104
+bfin> print googleip
+googleip=64.233.161.104
+bfin> ping ${googleip}
+Using Blackfin EMAC device
+host 64.233.161.104 is alive
+
+ In this way, you can lookup, and set many more meaningful
+ things.
+
+bfin> sntp
+ntpserverip not set
+bfin> dns pool.ntp.org ntpserverip
+72.18.205.156
+bfin> sntp
+Date: 2009-07-18 Time: 4:06:57
+
+ For some helpful things that can be related to DNS in U-Boot,
+ look at the top level README for these config options:
+ CONFIG_CMD_DHCP
+ CONFIG_BOOTP_DNS
+ CONFIG_BOOTP_DNS2
diff --git a/roms/u-boot/doc/README.enetaddr b/roms/u-boot/doc/README.enetaddr
new file mode 100644
index 000000000..5baa9f217
--- /dev/null
+++ b/roms/u-boot/doc/README.enetaddr
@@ -0,0 +1,118 @@
+---------------------------------
+ Ethernet Address (MAC) Handling
+---------------------------------
+
+There are a variety of places in U-Boot where the MAC address is used, parsed,
+and stored. This document covers proper usage of each location and the moving
+of data between them.
+
+-----------
+ Locations
+-----------
+
+Here are the places where MAC addresses might be stored:
+
+ - board-specific location (eeprom, dedicated flash, ...)
+ Note: only used when mandatory due to hardware design etc...
+
+ - environment ("ethaddr", "eth1addr", ...)
+ Note: this is the preferred way to permanently store MAC addresses
+
+ - ethernet data (struct eth_device -> enetaddr)
+ Note: these are temporary copies of the MAC address which exist only
+ after the respective init steps have run and only to make usage
+ in other places easier (to avoid constant env lookup/parsing)
+
+ - struct bd_info and/or device tree
+ Note: these are temporary copies of the MAC address only for the
+ purpose of passing this information to an OS kernel we are about
+ to boot
+
+Correct flow of setting up the MAC address (summarized):
+
+1. Read from hardware in initialize() function
+2. Read from environment in net/eth.c after initialize()
+3. The environment variable will be compared to the driver initialized
+ struct eth_device->enetaddr. If they differ, a warning is printed, and the
+ environment variable will be used unchanged.
+ If the environment variable is not set, it will be initialized from
+ eth_device->enetaddr, and a warning will be printed.
+ If both are invalid and CONFIG_NET_RANDOM_ETHADDR is defined, a random,
+ locally-assigned MAC is written to eth_device->enetaddr.
+4. Program the address into hardware if the following conditions are met:
+ a) The relevant driver has a 'write_addr' function
+ b) The user hasn't set an 'ethmacskip' environment variable
+ c) The address is valid (unicast, not all-zeros)
+
+Previous behavior had the MAC address always being programmed into hardware
+in the device's init() function.
+
+-------
+ Usage
+-------
+
+If the hardware design mandates that the MAC address is stored in some special
+place (like EEPROM etc...), then the board specific init code (such as the
+board-specific misc_init_r() function) is responsible for locating the MAC
+address(es) and initializing the respective environment variable(s) from it.
+Note that this shall be done if, and only if, the environment does not already
+contain these environment variables, i.e. existing variable definitions must
+not be overwritten.
+
+During runtime, the ethernet layer will use the environment variables to sync
+the MAC addresses to the ethernet structures. All ethernet driver code should
+then only use the enetaddr member of the eth_device structure. This is done
+on every network command, so the ethernet copies will stay in sync.
+
+Any other code that wishes to access the MAC address should query the
+environment directly. The helper functions documented below should make
+working with this storage much smoother.
+
+---------
+ Helpers
+---------
+
+To assist in the management of these layers, a few helper functions exist. You
+should use these rather than attempt to do any kind of parsing/manipulation
+yourself as many common errors have arisen in the past.
+
+ * void string_to_enetaddr(const char *addr, uchar *enetaddr);
+
+Convert a string representation of a MAC address to the binary version.
+char *addr = "00:11:22:33:44:55";
+uchar enetaddr[6];
+string_to_enetaddr(addr, enetaddr);
+/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */
+
+ * int eth_env_get_enetaddr(char *name, uchar *enetaddr);
+
+Look up an environment variable and convert the stored address. If the address
+is valid, then the function returns 1. Otherwise, the function returns 0. In
+all cases, the enetaddr memory is initialized. If the env var is not found,
+then it is set to all zeros. The common function is_valid_ethaddr() is used
+to determine address validity.
+uchar enetaddr[6];
+if (!eth_env_get_enetaddr("ethaddr", enetaddr)) {
+ /* "ethaddr" is not set in the environment */
+ ... try and setup "ethaddr" in the env ...
+}
+/* enetaddr is now set to the value stored in the ethaddr env var */
+
+ * int eth_env_set_enetaddr(char *name, const uchar *enetaddr);
+
+Store the MAC address into the named environment variable. The return value is
+the same as the env_set() function.
+uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
+eth_env_set_enetaddr("ethaddr", enetaddr);
+/* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */
+
+ * the %pM format modifier
+
+The %pM format modifier can be used with any standard printf function to format
+the binary 6 byte array representation of a MAC address.
+uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
+printf("The MAC is %pM\n", enetaddr);
+
+char buf[20];
+sprintf(buf, "%pM", enetaddr);
+/* the buf variable is now set to "00:11:22:33:44:55" */
diff --git a/roms/u-boot/doc/README.esbc_validate b/roms/u-boot/doc/README.esbc_validate
new file mode 100644
index 000000000..540923215
--- /dev/null
+++ b/roms/u-boot/doc/README.esbc_validate
@@ -0,0 +1,40 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2015
+ */
+
+esbc_validate command
+========================================
+
+1. esbc_validate command is meant for validating header and
+ signature of images (Boot Script and ESBC uboot client).
+ SHA-256 and RSA operations are performed using SEC block in HW.
+ This command works on both PBL based and Non PBL based Freescale
+ platforms.
+ Command usage:
+ esbc_validate img_hdr_addr [pub_key_hash]
+ esbc_validate hdr_addr <hash_val>
+ Validates signature using RSA verification.
+ $hdr_addr Address of header of the image to be validated.
+ $hash_val -Optional. It provides Hash of public/srk key to be
+ used to verify signature.
+
+2. ESBC uboot client can be linux. Additionally, rootfs and device
+ tree blob can also be signed.
+3. In the event of header or signature failure in validation,
+ ITS and ITF bits determine further course of action.
+4. In case of soft failure, appropriate error is dumped on console.
+5. In case of hard failure, SoC is issued RESET REQUEST after
+ dumping error on the console.
+6. KEY REVOCATION Feature:
+ QorIQ platforms like B4/T4 have support of srk key table and key
+ revocation in ISBC code in Silicon.
+ The srk key table allows the user to have a key table with multiple
+ keys and revoke any key in case of particular key gets compromised.
+ In case the ISBC code uses the key revocation and srk key table to
+ verify the u-boot code, the subsequent chain of trust should also
+ use the same.
+6. ISBC KEY EXTENSION Feature:
+ This feature allows large number of keys to be used for esbc validation
+ of images. A set of public keys is being signed and validated by ISBC
+ which can be further used for esbc validation of images.
diff --git a/roms/u-boot/doc/README.ext4 b/roms/u-boot/doc/README.ext4
new file mode 100644
index 000000000..8ecd21eee
--- /dev/null
+++ b/roms/u-boot/doc/README.ext4
@@ -0,0 +1,83 @@
+U-Boot supports access of both ext2 and ext4 filesystems, either in read-only
+mode or in read-write mode.
+
+First, to enable support for both ext4 (and, automatically, ext2 as well),
+but without selecting the corresponding commands, enable one of the following:
+
+ CONFIG_FS_EXT4 (for read-only)
+ CONFIG_EXT4_WRITE (for read-write)
+
+Next, to select the ext2-related commands:
+
+ * ext2ls
+ * ext2load
+
+or ext4-related commands:
+
+ * ext4size
+ * ext4ls
+ * ext4load
+
+use one or both of:
+
+ CONFIG_CMD_EXT2
+ CONFIG_CMD_EXT4
+
+Selecting either of the above automatically selects CONFIG_FS_EXT4 if it
+wasn't enabled already.
+
+In addition, to get the write access command "ext4write", enable:
+
+ CONFIG_CMD_EXT4_WRITE
+
+which automatically selects CONFIG_EXT4_WRITE if it wasn't defined
+already.
+
+Also relevant are the generic filesystem commands, selected by:
+
+ CONFIG_CMD_FS_GENERIC
+
+This does not automatically enable EXT4 support for you, you still need
+to do that yourself.
+
+Some sample commands to test ext4 support:
+
+1. Check that the commands can be seen in the output of U-Boot help:
+
+ UBOOT #help
+ ...
+ ext4load- load binary file from a Ext4 file system
+ ext4ls - list files in a directory (default /)
+ ext4size - determine a file's size
+ ext4write- create a file in ext4 formatted partition
+ ...
+
+2. To list the files in an ext4-formatted partition, run:
+
+ ext4ls <interface> <dev[:part]> [directory]
+
+ For example:
+ UBOOT #ext4ls mmc 0:5 /usr/lib
+
+3. To read and load a file from an ext4-formatted partition to RAM, run:
+
+ ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
+
+ For example:
+ UBOOT #ext4load mmc 2:2 0x30007fc0 uImage
+
+4. To write a file to an ext4-formatted partition.
+
+ a) First load a file to RAM at a particular address for example 0x30007fc0.
+ Now execute ext4write command:
+ ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes]
+
+ For example:
+ UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120
+ (here 6183120 is the size of the file to be written)
+ Note: Absolute path is required for the file to be written
+
+References :
+ -- ext4 implementation in Linux Kernel
+ -- Uboot existing ext2 load and ls implementation
+ -- Journaling block device JBD2 implementation in linux Kernel
diff --git a/roms/u-boot/doc/README.falcon b/roms/u-boot/doc/README.falcon
new file mode 100644
index 000000000..713d7063a
--- /dev/null
+++ b/roms/u-boot/doc/README.falcon
@@ -0,0 +1,232 @@
+U-Boot Falcon Mode
+====================
+
+Introduction
+------------
+
+This document provides an overview of how to add support for Falcon Mode
+to a board.
+
+Falcon Mode is introduced to speed up the booting process, allowing
+to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
+U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
+image. In most implementations, SPL is used to start U-Boot when booting from
+a mass storage, such as NAND or SD-Card. SPL has now support for other media,
+and can generally be seen as a way to start an image performing the minimum
+required initialization. SPL mainly initializes the RAM controller, and then
+copies U-Boot image into the memory.
+
+The Falcon Mode extends this way allowing to start the Linux kernel directly
+from SPL. A new command is added to U-Boot to prepare the parameters that SPL
+must pass to the kernel, using ATAGS or Device Tree.
+
+In normal mode, these parameters are generated each time before
+loading the kernel, passing to Linux the address in memory where
+the parameters can be read.
+With Falcon Mode, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
+
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+
+1. Boot the board into U-Boot.
+After loading the desired legacy-format kernel image into memory (and DT as
+well, if used), use the "spl export" command to generate the kernel parameters
+area or the DT. U-Boot runs as when it boots the kernel, but stops before
+passing the control to the kernel.
+
+2. Save the prepared snapshot into persistent media.
+The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy
+the parameters which are saved in the persistent area to the required address.
+If a valid uImage is not found at the defined location, U-Boot will be
+booted instead.
+
+It is required to implement a custom mechanism to select if SPL loads U-Boot
+or another image.
+
+The value of a GPIO is a simple way to operate the selection, as well as
+reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
+SPL that U-Boot is not the only available image that SPL is able to start.
+
+Configuration
+----------------------------
+CONFIG_CMD_SPL Enable the "spl export" command.
+ The command "spl export" is then available in U-Boot
+ mode
+CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
+ copied by SPL.
+ In most cases, it is <start_of_ram> + 0x100
+
+CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored
+
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved.
+
+CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved.
+
+CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied
+
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+
+Function that a board must implement
+------------------------------------
+
+void spl_board_prepare_for_linux(void) : optional
+ Called from SPL before starting the kernel
+
+spl_start_uboot() : required
+ Returns "0" if SPL should start the kernel, "1" if U-Boot
+ must be started.
+
+Environment variables
+---------------------
+
+A board may chose to look at the environment for decisions about falcon
+mode. In this case the following variables may be supported:
+
+boot_os : Set to yes/Yes/true/True/1 to enable booting to OS,
+ any other value to fall back to U-Boot (including
+ unset)
+falcon_args_file : Filename to load as the 'args' portion of falcon mode
+ rather than the hard-coded value.
+falcon_image_file : Filename to load as the OS image portion of falcon
+ mode rather than the hard-coded value.
+
+Using spl command
+-----------------
+
+spl - SPL configuration
+
+Usage:
+
+spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
+
+img : "atags" or "fdt"
+kernel_addr : kernel is loaded as part of the boot process, but it is not started.
+ This is the address where a kernel image is stored.
+initrd_addr : Address of initial ramdisk
+ can be set to "-" if fdt_addr without initrd_addr is used
+fdt_addr : in case of fdt, the address of the device tree.
+
+The spl export command does not write to a storage media. The user is
+responsible to transfer the gathered information (assembled ATAGS list
+or prepared FDT) from temporary storage in RAM into persistant storage
+after each run of 'spl export'. Unfortunately the position of temporary
+storage can not be predicted nor provided at commandline, it depends
+highly on your system setup and your provided data (ATAGS or FDT).
+However at the end of an succesful 'spl export' run it will print the
+RAM address of temporary storage. The RAM address of FDT will also be
+set in the environment variable 'fdtargsaddr', the new length of the
+prepared FDT will be set in the environment variable 'fdtargslen'.
+These environment variables can be used in scripts for writing updated
+FDT to persistent storage.
+
+Now the user have to save the generated BLOB from that printed address
+to the pre-defined address in persistent storage
+(CONFIG_CMD_SPL_NAND_OFS in case of NAND).
+The following example shows how to prepare the data for Falcon Mode on
+twister board with ATAGS BLOB.
+
+The "spl export" command is prepared to work with ATAGS and FDT. However,
+using FDT is at the moment untested. The ppc port (see a3m071 example
+later) prepares the fdt blob with the fdt command instead.
+
+
+Usage on the twister board:
+--------------------------------
+
+Using mtd names with the following (default) configuration
+for mtdparts:
+
+device nand0 <omap2-nand.0>, # parts = 9
+ #: name size offset mask_flags
+ 0: MLO 0x00080000 0x00000000 0
+ 1: u-boot 0x00100000 0x00080000 0
+ 2: env1 0x00040000 0x00180000 0
+ 3: env2 0x00040000 0x001c0000 0
+ 4: kernel 0x00600000 0x00200000 0
+ 5: bootparms 0x00040000 0x00800000 0
+ 6: splashimg 0x00200000 0x00840000 0
+ 7: mini 0x02800000 0x00a40000 0
+ 8: rootfs 0x1cdc0000 0x03240000 0
+
+
+twister => nand read 82000000 kernel
+
+NAND read: device 0 offset 0x200000, size 0x600000
+ 6291456 bytes read: OK
+
+Now the kernel is in RAM at address 0x82000000
+
+twister => spl export atags 0x82000000
+## Booting kernel from Legacy Image at 82000000 ...
+ Image Name: Linux-3.5.0-rc4-14089-gda0b7f4
+ Image Type: ARM Linux Kernel Image (uncompressed)
+ Data Size: 3654808 Bytes = 3.5 MiB
+ Load Address: 80008000
+ Entry Point: 80008000
+ Verifying Checksum ... OK
+ Loading Kernel Image ... OK
+OK
+cmdline subcommand not supported
+bdt subcommand not supported
+Argument image is now in RAM at: 0x80000100
+
+The result can be checked at address 0x80000100:
+
+twister => md 0x80000100
+80000100: 00000005 54410001 00000000 00000000 ......AT........
+80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot
+80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs
+
+The parameters generated with this step can be saved into NAND at the offset
+0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS)
+
+nand erase.part bootparms
+nand write 0x80000100 bootparms 0x4000
+
+Now the parameters are stored into the NAND flash at the address
+CONFIG_CMD_SPL_NAND_OFS (=0x800000).
+
+Next time, the board can be started into Falcon Mode moving the
+setting the gpio (on twister gpio 55 is used) to kernel mode.
+
+The kernel is loaded directly by the SPL without passing through U-Boot.
+
+Example with FDT: a3m071 board
+-------------------------------
+
+To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
+prepard/patched first. U-Boot usually inserts some dynamic values into
+the DT binary (blob), e.g. autodetected memory size, MAC addresses,
+clocks speeds etc. To generate this patched DT blob, you can use
+the following command:
+
+1. Load fdt blob to SDRAM:
+=> tftp 1800000 a3m071/a3m071.dtb
+
+2. Set bootargs as desired for Linux booting (e.g. flash_mtd):
+=> run mtdargs addip2 addtty
+
+3. Use "fdt" commands to patch the DT blob:
+=> fdt addr 1800000
+=> fdt boardsetup
+=> fdt chosen
+
+4. Display patched DT blob (optional):
+=> fdt print
+
+5. Save fdt to NOR flash:
+=> erase fc060000 fc07ffff
+=> cp.b 1800000 fc060000 10000
+...
+
+
+Falcon Mode was presented at the RMLL 2012. Slides are available at:
+
+http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
diff --git a/roms/u-boot/doc/README.fdt-control b/roms/u-boot/doc/README.fdt-control
new file mode 100644
index 000000000..424d13fc5
--- /dev/null
+++ b/roms/u-boot/doc/README.fdt-control
@@ -0,0 +1,230 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+
+Device Tree Control in U-Boot
+=============================
+
+This feature provides for run-time configuration of U-Boot via a flat
+device tree (fdt). U-Boot configuration has traditionally been done
+using CONFIG options in the board config file. This feature aims to
+make it possible for a single U-Boot binary to support multiple boards,
+with the exact configuration of each board controlled by a flat device
+tree (fdt). This is the approach recently taken by the ARM Linux kernel
+and has been used by PowerPC for some time.
+
+The fdt is a convenient vehicle for implementing run-time configuration
+for three reasons. Firstly it is easy to use, being a simple text file.
+It is extensible since it consists of nodes and properties in a nice
+hierarchical format.
+
+Finally, there is already excellent infrastructure for the fdt: a
+compiler checks the text file and converts it to a compact binary
+format, and a library is already available in U-Boot (libfdt) for
+handling this format.
+
+The dts directory contains a Makefile for building the device tree blob
+and embedding it in your U-Boot image. This is useful since it allows
+U-Boot to configure itself according to what it finds there. If you have
+a number of similar boards with different peripherals, you can describe
+the features of each board in the device tree file, and have a single
+generic source base.
+
+To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+
+
+What is a Flat Device Tree?
+---------------------------
+
+An fdt can be specified in source format as a text file. To read about
+the fdt syntax, take a look at the specification here:
+
+https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
+
+You also might find this section of the Linux kernel documentation
+useful: (access this in the Linux kernel source code)
+
+ Documentation/devicetree/booting-without-of.txt
+
+There is also a mailing list:
+
+ http://lists.ozlabs.org/listinfo/devicetree-discuss
+
+In case you are wondering, OF stands for Open Firmware.
+
+
+Tools
+-----
+
+To use this feature you will need to get the device tree compiler. This is
+provided by U-Boot automatically. If you have a system version of dtc
+(typically in the 'device-tree-compiler' package), it is currently not used.
+
+If you want to build your own dtc, it is kept here:
+
+ git://git.kernel.org/pub/scm/utils/dtc/dtc.git
+
+For example:
+
+ $ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git
+ $ cd dtc
+ $ make
+ $ sudo make install
+
+Then run the compiler (your version will vary):
+
+ $ dtc -v
+ Version: DTC 1.2.0-g2cb4b51f
+ $ make tests
+ $ cd tests
+ $ ./run_tests.sh
+ ********** TEST SUMMARY
+ * Total testcases: 1371
+ * PASS: 1371
+ * FAIL: 0
+ * Bad configuration: 0
+ * Strange test result: 0
+
+You will also find a useful fdtdump utility for decoding a binary file, as
+well as fdtget/fdtput for reading and writing properties in a binary file.
+
+
+Where do I get an fdt file for my board?
+----------------------------------------
+
+You may find that the Linux kernel has a suitable file. Look in the
+kernel source in arch/<arch>/boot/dts.
+
+If not you might find other boards with suitable files that you can
+modify to your needs. Look in the board directories for files with a
+.dts extension.
+
+Failing that, you could write one from scratch yourself!
+
+
+Configuration
+-------------
+
+Use:
+
+#define CONFIG_DEFAULT_DEVICE_TREE "<name>"
+
+to set the filename of the device tree source. Then put your device tree
+file into
+
+ board/<vendor>/dts/<name>.dts
+
+This should include your CPU or SOC's device tree file, placed in
+arch/<arch>/dts, and then make any adjustments required.
+
+If CONFIG_OF_EMBED is defined, then it will be picked up and built into
+the U-Boot image (including u-boot.bin). This is suitable for debugging
+and development only and is not recommended for production devices.
+
+If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
+a u-boot.dtb file alongside u-boot-nodtb.bin. A common approach is then to
+join the two:
+
+ cat u-boot-nodtb.bin u-boot.dtb >image.bin
+
+and then flash image.bin onto your board. Note that U-Boot creates
+u-boot-dtb.bin which does the above step for you also. Resulting
+u-boot.bin is a copy of u-boot-dtb.bin in this case. If you are using
+CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
+tree binary.
+
+If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
+device tree at runtime, for example if an earlier bootloader stage creates
+it and passes it to U-Boot.
+
+If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
+startup. This is only useful for sandbox. Use the -d flag to U-Boot to
+specify the file to read.
+
+You cannot use more than one of these options at the same time.
+
+To use a device tree file that you have compiled yourself, pass
+EXT_DTB=<filename> to 'make', as in:
+
+ make EXT_DTB=boot/am335x-boneblack-pubkey.dtb
+
+Then U-Boot will copy that file to u-boot.dtb, put it in the .img file
+if used, and u-boot-dtb.bin.
+
+If you wish to put the fdt at a different address in memory, you can
+define the "fdtcontroladdr" environment variable. This is the hex
+address of the fdt binary blob, and will override either of the options.
+Be aware that this environment variable is checked prior to relocation,
+when only the compiled-in environment is available. Therefore it is not
+possible to define this variable in the saved SPI/NAND flash
+environment, for example (it will be ignored). After relocation, this
+variable will be set to the address of the newly relocated fdt blob.
+It is read-only and cannot be changed. It can optionally be used to
+control the boot process of Linux with bootm/bootz commands.
+
+To use this, put something like this in your board header file:
+
+#define CONFIG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0"
+
+Build:
+
+After board configuration is done, fdt supported u-boot can be build in two ways:
+1) build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE
+ $ make
+2) build the user specified dts file
+ $ make DEVICE_TREE=<dts-file-name>
+
+
+Relocation, SPL and TPL
+-----------------------
+
+U-Boot can be divided into three phases: TPL, SPL and U-Boot proper.
+
+The full device tree is available to U-Boot proper, but normally only a subset
+(or none at all) is available to TPL and SPL. See 'Pre-Relocation Support' and
+'SPL Support' in doc/driver-model/design.rst for more details.
+
+
+Using several DTBs in the SPL (CONFIG_SPL_MULTI_DTB)
+----------------------------------------------------
+In some rare cases it is desirable to let SPL be able to select one DTB among
+many. This usually not very useful as the DTB for the SPL is small and usually
+fits several platforms. However the DTB sometimes include information that do
+work on several platforms (like IO tuning parameters).
+In this case it is possible to use CONFIG_SPL_MULTI_DTB. This option appends to
+the SPL a FIT image containing several DTBs listed in SPL_OF_LIST.
+board_fit_config_name_match() is called to select the right DTB.
+
+If board_fit_config_name_match() relies on DM (DM driver to access an EEPROM
+containing the board ID for example), it possible to start with a generic DTB
+and then switch over to the right DTB after the detection. For this purpose,
+the platform code must call fdtdec_resetup(). Based on the returned flag, the
+platform may have to re-initiliaze the DM subusystem using dm_uninit() and
+dm_init_and_scan().
+
+
+Limitations
+-----------
+
+U-Boot is designed to build with a single architecture type and CPU
+type. So for example it is not possible to build a single ARM binary
+which runs on your AT91 and OMAP boards, relying on an fdt to configure
+the various features. This is because you must select one of
+the CPU families within arch/arm/cpu/arm926ejs (omap or at91) at build
+time. Similarly you cannot build for multiple cpu types or
+architectures.
+
+That said the complexity reduction by using fdt to support variants of
+boards which use the same SOC / CPU can be substantial.
+
+It is important to understand that the fdt only selects options
+available in the platform / drivers. It cannot add new drivers (yet). So
+you must still have the CONFIG option to enable the driver. For example,
+you need to define CONFIG_SYS_NS16550 to bring in the NS16550 driver,
+but can use the fdt to specific the UART clock, peripheral address, etc.
+In very broad terms, the CONFIG options in general control *what* driver
+files are pulled in, and the fdt controls *how* those files work.
+
+--
+Simon Glass <sjg@chromium.org>
+1-Sep-11
diff --git a/roms/u-boot/doc/README.fec_mxc b/roms/u-boot/doc/README.fec_mxc
new file mode 100644
index 000000000..9ca6ac2fb
--- /dev/null
+++ b/roms/u-boot/doc/README.fec_mxc
@@ -0,0 +1,39 @@
+U-Boot config options used in fec_mxc.c
+
+CONFIG_FEC_MXC
+ Selects fec_mxc.c to be compiled into u-boot. Can read out the
+ ethaddr from the SoC eFuses (see below).
+
+CONFIG_MII
+ Must be defined if CONFIG_FEC_MXC is defined.
+
+CONFIG_FEC_XCV_TYPE
+ Defaults to MII100 for 100 Base-tx.
+ RGMII selects 1000 Base-tx reduced pin count interface.
+ RMII selects 100 Base-tx reduced pin count interface.
+
+CONFIG_FEC_MXC_SWAP_PACKET
+ Forced on iff MX28.
+ Swaps the bytes order of all words(4 byte units) in the packet.
+ This should not be specified by a board file. It is cpu specific.
+
+CONFIG_PHYLIB
+ fec_mxc supports PHYLIB and should be used for new boards.
+
+CONFIG_FEC_MXC_NO_ANEG
+ Relevant only if PHYLIB not used. Skips auto-negotiation restart.
+
+CONFIG_FEC_MXC_PHYADDR
+ Optional, selects the exact phy address that should be connected
+ and function fecmxc_initialize will try to initialize it.
+
+CONFIG_FEC_FIXED_SPEED
+ Optional, selects a fixed speed on the MAC interface without asking some
+ phy. This is usefull if there is a direct MAC <-> MAC connection, for
+ example if the CPU is connected directly via the RGMII interface to a
+ ethernet-switch.
+
+Reading the ethaddr from the SoC eFuses:
+if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
+ethaddr variable, then its value gets read from the corresponding eFuses in
+the SoC. See the README files of the specific SoC for details.
diff --git a/roms/u-boot/doc/README.fsl-clk b/roms/u-boot/doc/README.fsl-clk
new file mode 100644
index 000000000..3a9927f07
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-clk
@@ -0,0 +1,5 @@
+Freescale system clock options
+
+ - CONFIG_SYS_FSL_CLK
+ Enable to call get_clocks() in board_init_f() for
+ non-PPC platforms.
diff --git a/roms/u-boot/doc/README.fsl-ddr b/roms/u-boot/doc/README.fsl-ddr
new file mode 100644
index 000000000..cec5d94df
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-ddr
@@ -0,0 +1,439 @@
+Table of interleaving 2-4 controllers
+=====================================
+ +--------------+-----------------------------------------------------------+
+ |Configuration | Memory Controller |
+ | | 1 2 3 4 |
+ |--------------+--------------+--------------+-----------------------------+
+ | Two memory | Not Intlv'ed | Not Intlv'ed | |
+ | complexes +--------------+--------------+ |
+ | | 2-way Intlv'ed | |
+ |--------------+--------------+--------------+--------------+ |
+ | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | |
+ | Three memory +--------------+--------------+--------------+ |
+ | complexes | 2-way Intlv'ed | Not Intlv'ed | |
+ | +-----------------------------+--------------+ |
+ | | 3-way Intlv'ed | |
+ +--------------+--------------+--------------+--------------+--------------+
+ | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed |
+ | Four memory +--------------+--------------+--------------+--------------+
+ | complexes | 2-way Intlv'ed | 2-way Intlv'ed |
+ | +-----------------------------+-----------------------------+
+ | | 4-way Intlv'ed |
+ +--------------+-----------------------------------------------------------+
+
+
+Table of 2-way interleaving modes supported in cpu/8xxx/ddr/
+======================================================
+ +-------------+---------------------------------------------------------+
+ | | Rank Interleaving |
+ | +--------+-----------+-----------+------------+-----------+
+ |Memory | | | | 2x2 | 4x1 |
+ |Controller | None | 2x1 lower | 2x1 upper | {CS0+CS1}, | {CS0+CS1+ |
+ |Interleaving | | {CS0+CS1} | {CS2+CS3} | {CS2+CS3} | CS2+CS3} |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ |None | Yes | Yes | Yes | Yes | Yes |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ |Cacheline | Yes | Yes | No | No, Only(*)| Yes |
+ | |CS0 Only| | | {CS0+CS1} | |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ |Page | Yes | Yes | No | No, Only(*)| Yes |
+ | |CS0 Only| | | {CS0+CS1} | |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ |Bank | Yes | Yes | No | No, Only(*)| Yes |
+ | |CS0 Only| | | {CS0+CS1} | |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ |Superbank | No | Yes | No | No, Only(*)| Yes |
+ | | | | | {CS0+CS1} | |
+ +-------------+--------+-----------+-----------+------------+-----------+
+ (*) Although the hardware can be configured with memory controller
+ interleaving using "2x2" rank interleaving, it only interleaves {CS0+CS1}
+ from each controller. {CS2+CS3} on each controller are only rank
+ interleaved on that controller.
+
+ For memory controller interleaving, identical DIMMs are suggested. Software
+ doesn't check the size or organization of interleaved DIMMs.
+
+The ways to configure the ddr interleaving mode
+==============================================
+1. In board header file(e.g.MPC8572DS.h), add default interleaving setting
+ under "CONFIG_EXTRA_ENV_SETTINGS", like:
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+ "hwconfig=fsl_ddr:ctlr_intlv=bank" \
+ ......
+
+2. Run U-Boot "setenv" command to configure the memory interleaving mode.
+ Either numerical or string value is accepted.
+
+ # disable memory controller interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=null"
+
+ # cacheline interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=cacheline"
+
+ # page interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=page"
+
+ # bank interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=bank"
+
+ # superbank
+ setenv hwconfig "fsl_ddr:ctlr_intlv=superbank"
+
+ # 1KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_1KB"
+
+ # 4KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_4KB"
+
+ # 8KB 3-way interleaving
+ setenv hwconfig "fsl_ddr:ctlr_intlv=3way_8KB"
+
+ # disable bank (chip-select) interleaving
+ setenv hwconfig "fsl_ddr:bank_intlv=null"
+
+ # bank(chip-select) interleaving cs0+cs1
+ setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1"
+
+ # bank(chip-select) interleaving cs2+cs3
+ setenv hwconfig "fsl_ddr:bank_intlv=cs2_cs3"
+
+ # bank(chip-select) interleaving (cs0+cs1) and (cs2+cs3) (2x2)
+ setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_and_cs2_cs3"
+
+ # bank(chip-select) interleaving (cs0+cs1+cs2+cs3) (4x1)
+ setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_cs2_cs3"
+
+ # bank(chip-select) interleaving (auto)
+ setenv hwconfig "fsl_ddr:bank_intlv=auto"
+ This auto mode only select from cs0_cs1_cs2_cs3, cs0_cs1, null dependings
+ on DIMMs.
+
+Memory controller address hashing
+==================================
+If the DDR controller supports address hashing, it can be enabled by hwconfig.
+
+Syntax is:
+hwconfig=fsl_ddr:addr_hash=true
+
+Memory controller ECC on/off
+============================
+If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC,
+ECC can be turned on/off by hwconfig.
+
+Syntax is
+hwconfig=fsl_ddr:ecc=off
+
+
+Memory address parity on/off
+============================
+address parity can be turned on/off by hwconfig.
+Syntax is:
+hwconfig=fsl_ddr:parity=on
+
+
+Memory testing options for mpc85xx
+==================================
+1. Memory test can be done once U-Boot prompt comes up using mtest, or
+2. Memory test can be done with Power-On-Self-Test function, activated at
+ compile time.
+
+ In order to enable the POST memory test, CONFIG_POST needs to be
+ defined in board configuraiton header file. By default, POST memory test
+ performs a fast test. A slow test can be enabled by changing the flag at
+ compiling time. To test memory bigger than 2GB, 36BIT support is needed.
+ Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB
+ window to physical address so that all physical memory can be tested.
+
+Combination of hwconfig
+=======================
+Hwconfig can be combined with multiple parameters, for example, on a supported
+platform
+
+hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
+
+
+Table for dynamic ODT for DDR3
+==============================
+For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT may
+be needed, depending on the configuration. The numbers in the following tables are
+in Ohms.
+
+* denotes dynamic ODT
+
+Two slots system
++-----------------------+----------+---------------+-----------------------------+-----------------------------+
+| Configuration | |DRAM controller| Slot 1 | Slot 2 |
++-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
+| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
++ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
+| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 75 | 120 | off | off | off | off | off | 30 | 30 |
+| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 75 | off | off | 30 | 30 | 120 | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 75 | 120 | off | off | off | 20 | 20 | | |
+| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 75 | off | off | 20 | 20 | 120 *| off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 75 | 120 *| off | | | off | off | 20 | 20 |
+|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 75 | 20 | 20 | | | 120 | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 75 | 120 *| off | | | 30 | 30 | | |
+|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 75 | 30 | 30 | | | 120 *| off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Dual Rank | Empty | Slot 1 | off | 75 | 40 | off | off | off | | | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 40 | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|Single Rank| Empty | Slot 1 | off | 75 | 40 | off | | | | | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Empty |Single Rank| Slot 2 | off | 75 | | | | | 40 | off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+
+Single slot system
++-------------+------------+---------------+-----------------------------+-----------------------------+
+| | |DRAM controller| Rank 1 | Rank 2 | Rank 3 | Rank 4 |
+|Configuration| Write/Read |-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Write | Read | Write | Read | Write | Read | Write | Read | Write | Read |
++-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | R1 | off | 75 | 120 *| off | off | off | 20 | 20 | off | off |
+| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | R2 | off | 75 | off | 20 | 120 | off | 20 | 20 | off | off |
+| Quad Rank |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | R3 | off | 75 | 20 | 20 | off | off | 120 *| off | off | off |
+| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | R4 | off | 75 | 20 | 20 | off | off | off | 20 | 120 | off |
++-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | R1 | off | 75 | 40 | off | off | off |
+| Dual Rank |------------+-------+-------+-------+------+-------+------+
+| | R2 | off | 75 | 40 | off | off | off |
++-------------+------------+-------+-------+-------+------+-------+------+
+| Single Rank | R1 | off | 75 | 40 | off |
++-------------+------------+-------+-------+-------+------+
+
+Reference http://www.xrosstalkmag.com/mag_issues/xrosstalk_oct08_final.pdf
+ http://download.micron.com/pdf/technotes/ddr3/tn4108_ddr3_design_guide.pdf
+
+
+Table for ODT for DDR2
+======================
+Two slots system
++-----------------------+----------+---------------+-----------------------------+-----------------------------+
+| Configuration | |DRAM controller| Slot 1 | Slot 2 |
++-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
+| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
++ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
+| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | off | off |
+| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | | |
+| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | off | off |
+|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | | |
+|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Dual Rank | Empty | Slot 1 | off | 75 | 150 | off | off | off | | | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 150 | off | off | off |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|Single Rank| Empty | Slot 1 | off | 75 | 150 | off | | | | | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Empty |Single Rank| Slot 2 | off | 75 | | | | | 150 | off | | |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+
+Single slot system
++-------------+------------+---------------+-----------------------------+
+| | |DRAM controller| Rank 1 | Rank 2 |
+|Configuration| Write/Read |-------+-------+-------+------+-------+------+
+| | | Write | Read | Write | Read | Write | Read |
++-------------+------------+-------+-------+-------+------+-------+------+
+| | R1 | off | 75 | 150 | off | off | off |
+| Dual Rank |------------+-------+-------+-------+------+-------+------+
+| | R2 | off | 75 | 150 | off | off | off |
++-------------+------------+-------+-------+-------+------+-------+------+
+| Single Rank | R1 | off | 75 | 150 | off |
++-------------+------------+-------+-------+-------+------+
+
+Reference http://www.samsung.com/global/business/semiconductor/products/dram/downloads/applicationnote/ddr2_odt_control_200603.pdf
+
+
+Interactive DDR debugging
+===========================
+
+For DDR parameter tuning up and debugging, the interactive DDR debugger can
+be activated by setting the environment variable "ddr_interactive" to any
+value. (The value of ddr_interactive may have a meaning in the future, but,
+for now, the presence of the variable will cause the debugger to run.) Once
+activated, U-Boot will show the prompt "FSL DDR>" before enabling the DDR
+controller. The available commands are printed by typing "help".
+
+Another way to enter the interactive DDR debugger without setting the
+environment variable is to send the 'd' character early during the boot
+process. To save booting time, no additional delay is added, so the window
+to send the key press is very short -- basically, it is the time before the
+memory controller code starts to run. For example, when rebooting from
+within U-Boot, the user must press 'd' IMMEDIATELY after hitting enter to
+initiate a 'reset' command. In case of power on/reset, the user can hold
+down the 'd' key while applying power or hitting the board's reset button.
+
+The example flow of using interactive debugging is
+type command "compute" to calculate the parameters from the default
+type command "print" with arguments to show SPD, options, registers
+type command "edit" with arguments to change any if desired
+type command "copy" with arguments to copy controller/dimm settings
+type command "go" to continue calculation and enable DDR controller
+
+Additional commands to restart the debugging are:
+type command "reset" to reset the board
+type command "recompute" to reload SPD and start over
+
+Note, check "next_step" to show the flow. For example, after edit opts, the
+next_step is STEP_ASSIGN_ADDRESSES. After editing registers, the next_step is
+STEP_PROGRAM_REGS. Upon issuing command "go", the debugger will program the
+DDR controller with the current setting without further calculation and then
+exit to resume the booting of the machine.
+
+The detail syntax for each commands are
+
+print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
+ c<n> - the controller number, eg. c0, c1
+ d<n> - the DIMM number, eg. d0, d1
+ spd - print SPD data
+ dimmparms - DIMM parameters, calculated from SPD
+ commonparms - lowest common parameters for all DIMMs
+ opts - options
+ addresses - address assignment (not implemented yet)
+ regs - controller registers
+
+edit <c#> <d#> <spd|dimmparms|commonparms|opts|addresses|regs> <element> <value>
+ c<n> - the controller number, eg. c0, c1
+ d<n> - the DIMM number, eg. d0, d1
+ spd - print SPD data
+ dimmparms - DIMM parameters, calculated from SPD
+ commonparms - lowest common parameters for all DIMMs
+ opts - options
+ addresses - address assignment (not implemented yet)
+ regs - controller registers
+ <element> - name of the modified element
+ byte number if the object is SPD
+ <value> - decimal or heximal (prefixed with 0x) numbers
+
+copy <src c#> <src d#> <spd|dimmparms|commonparms|opts|addresses|regs> <dst c#> <dst d#>
+ same as for "edit" command
+ DIMM numbers ignored for commonparms, opts, and regs
+
+reset
+ no arguement - reset the board
+
+recompute
+ no argument - reload SPD and start over
+
+compute
+ no argument - recompute from current next_step
+
+next_step
+ no argument - show current next_step
+
+help
+ no argument - print a list of all commands
+
+go
+ no argument - program memory controller(s) and continue with U-Boot
+
+Examples of debugging flow
+
+ FSL DDR>compute
+ Detected UDIMM UG51U6400N8SU-ACF
+ FSL DDR>print
+ print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
+ FSL DDR>print dimmparms
+ DIMM parameters: Controller=0 DIMM=0
+ DIMM organization parameters:
+ module part name = UG51U6400N8SU-ACF
+ rank_density = 2147483648 bytes (2048 megabytes)
+ capacity = 4294967296 bytes (4096 megabytes)
+ burst_lengths_bitmask = 0C
+ base_addresss = 0 (00000000 00000000)
+ n_ranks = 2
+ data_width = 64
+ primary_sdram_width = 64
+ ec_sdram_width = 0
+ registered_dimm = 0
+ n_row_addr = 15
+ n_col_addr = 10
+ edc_config = 0
+ n_banks_per_sdram_device = 8
+ tCKmin_X_ps = 1500
+ tCKmin_X_minus_1_ps = 0
+ tCKmin_X_minus_2_ps = 0
+ tCKmax_ps = 0
+ caslat_X = 960
+ tAA_ps = 13125
+ caslat_X_minus_1 = 0
+ caslat_X_minus_2 = 0
+ caslat_lowest_derated = 0
+ tRCD_ps = 13125
+ tRP_ps = 13125
+ tRAS_ps = 36000
+ tWR_ps = 15000
+ tWTR_ps = 7500
+ tRFC_ps = 160000
+ tRRD_ps = 6000
+ tRC_ps = 49125
+ refresh_rate_ps = 7800000
+ tIS_ps = 0
+ tIH_ps = 0
+ tDS_ps = 0
+ tDH_ps = 0
+ tRTP_ps = 7500
+ tDQSQ_max_ps = 0
+ tQHS_ps = 0
+ FSL DDR>edit c0 opts ECC_mode 0
+ FSL DDR>edit c0 regs cs0_bnds 0x000000FF
+ FSL DDR>go
+ 2 GiB left unmapped
+ 4 GiB (DDR3, 64-bit, CL=9, ECC off)
+ DDR Chip-Select Interleaving Mode: CS0+CS1
+ Testing 0x00000000 - 0x7fffffff
+ Testing 0x80000000 - 0xffffffff
+ Remap DDR 2 GiB left unmapped
+
+ POST memory PASSED
+ Flash: 128 MiB
+ L2: 128 KB enabled
+ Corenet Platform Cache: 1024 KB enabled
+ SERDES: timeout resetting bank 3
+ SRIO1: disabled
+ SRIO2: disabled
+ MMC: FSL_ESDHC: 0
+ EEPROM: Invalid ID (ff ff ff ff)
+ PCIe1: disabled
+ PCIe2: Root Complex, x1, regs @ 0xfe201000
+ 01:00.0 - 8086:10d3 - Network controller
+ PCIe2: Bus 00 - 01
+ PCIe3: disabled
+ In: serial
+ Out: serial
+ Err: serial
+ Net: Initializing Fman
+ Fman1: Uploading microcode version 101.8.0
+ e1000: 00:1b:21:81:d2:e0
+ FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, e1000#0 [PRIME]
+ Warning: e1000#0 MAC addresses don't match:
+ Address in SROM is 00:1b:21:81:d2:e0
+ Address in environment is 00:e0:0c:00:ea:05
+
+ Hit any key to stop autoboot: 0
+ =>
diff --git a/roms/u-boot/doc/README.fsl-dpaa b/roms/u-boot/doc/README.fsl-dpaa
new file mode 100644
index 000000000..3ef5eeb32
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-dpaa
@@ -0,0 +1,10 @@
+This file documents Freescale DPAA-specific options.
+
+FMan (Frame Manager)
+ - CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
+ on SoCs T4240, T2080, LS1043A, etc, the notation between 10GEC and MAC as below:
+ 10GEC1->MAC9, 10GEC2->MAC10, 10GEC3->MAC1, 10GEC4->MAC2
+ on SoCs T1024, etc, the notation between 10GEC and MAC as below:
+ 10GEC1->MAC1, 10GEC2->MAC2
+ so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to identify the new SoCs on
+ which 10GEC enumeration is consistent with MAC enumeration.
diff --git a/roms/u-boot/doc/README.fsl-esdhc b/roms/u-boot/doc/README.fsl-esdhc
new file mode 100644
index 000000000..b620625df
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-esdhc
@@ -0,0 +1,8 @@
+Freescale esdhc-specific options
+
+ - CONFIG_SYS_FSL_ESDHC_LE
+ ESDHC IP is in little-endian mode. Accessing ESDHC registers can be
+ determined by ESDHC IP's endian mode or processor's endian mode.
+ - CONFIG_SYS_FSL_ESDHC_BE
+ ESDHC IP is in big-endian mode. Accessing ESDHC registers can be determined
+ by ESDHC IP's endian mode or processor's endian mode.
diff --git a/roms/u-boot/doc/README.fsl-hwconfig b/roms/u-boot/doc/README.fsl-hwconfig
new file mode 100644
index 000000000..e752505da
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-hwconfig
@@ -0,0 +1,46 @@
+Freescale-specific 'hwconfig' options.
+
+This file documents Freescale-specific key:value pairs for the 'hwconfig'
+option. See README.hwconfig for general information about 'hwconfig'.
+
+audclk
+ Specific to the P1022DS reference board.
+
+ This option specifies which of the two oscillator frequencies should be
+ routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to
+ route either a 11.2896MHz or a 12.288MHz clock. The default is
+ 12.288MHz. This option has two effects. First, the MUX on the board
+ will be programmed accordingly. Second, the clock-frequency property
+ in the codec node in the device tree will be updated to the correct
+ value.
+
+ 'audclk:11'
+ Select the 11.2896MHz clock
+
+ 'audclk:12'
+ Select the 12.288MHz clock
+
+usb
+ Specific to boards have USB controller
+
+ This option specifies the following for a USB controller:
+
+ - which controller mode to use
+ - which USB PHY to use
+
+ This is used by generic USB device-tree fixup function to update
+ modified values of phy type and controller mode.
+
+ Also used for configuring multiple USB controllers such that
+ 'usbN' (where N is 1, 2, etc. refers to controller no.)
+
+ 'phy_type'
+ Select USB phy type: 'utmi' OR 'ulpi'
+
+ 'dr_mode'
+ Select USB controller mode: 'host', 'peripheral' OR 'otg'
+
+ Examples:
+ usb1:dr_mode=host;usb2:dr_mode=peripheral'
+
+ usb1:dr_mode=host,phy_type=utmi;usb2:dr_mode=host'
diff --git a/roms/u-boot/doc/README.fsl-trustzone-components b/roms/u-boot/doc/README.fsl-trustzone-components
new file mode 100644
index 000000000..e1223469e
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl-trustzone-components
@@ -0,0 +1,25 @@
+Freescale ARM64 SoCs like LS2080A have ARM TrustZone components like
+TZPC-BP147 (TrustZone Protection Controller) and TZASC-400 (TrustZone
+Address Space Controller).
+
+While most of the configuration related programming of these peripherals
+is left to a root-of-trust security software layer (running in EL3
+privilege mode), but still some configurations of these peripherals
+might be required while the bootloader is executing in EL3 privilege
+mode. The following sections define how to turn on these features for
+LS2080A like SoCs.
+
+TZPC-BP147 (TrustZone Protection Controller)
+============================================
+- Depends on CONFIG_FSL_TZPC_BP147 configuration flag.
+- Separates Secure World and Normal World on-chip RAM (OCRAM) spaces.
+- Provides a programming model to set access control policy via the TZPC
+ TZDECPROT Registers.
+
+TZASC-400 (TrustZone Address Space Controller)
+==============================================
+- Depends on CONFIG_FSL_TZASC_400 configuration flag.
+- Separates Secure World and Normal World external memory spaces for bus masters
+ such as processors and DMA-equipped peripherals.
+- Supports 8 fully programmable address regions, initially inactive at reset,
+ and one base region, always active, that covers the remaining address space.
diff --git a/roms/u-boot/doc/README.fsl_iim b/roms/u-boot/doc/README.fsl_iim
new file mode 100644
index 000000000..e087f5e0e
--- /dev/null
+++ b/roms/u-boot/doc/README.fsl_iim
@@ -0,0 +1,48 @@
+Driver implementing the fuse API for Freescale's IC Identification Module (IIM)
+
+This IP can be found on the following SoCs:
+ - MPC512x,
+ - i.MX25,
+ - i.MX27,
+ - i.MX31,
+ - i.MX35,
+ - i.MX51,
+ - i.MX53.
+
+The section numbers in this file refer to the i.MX25 Reference Manual.
+
+A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1.
+
+A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1.
+
+Some fuse bit or word slots may not have the corresponding fuses actually
+implemented in the fusebox.
+
+See the README files of the SoCs using this driver in order to know the
+conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
+addresses.
+
+Fuse operations:
+
+ Read
+ Read operations are implemented as read accesses to the shadow registers,
+ using "Word y of Bank x" from the register summary in 30.3.2. This is
+ explained in detail in 30.4.5.1.
+
+ Sense
+ Sense operations are implemented as explained in 30.4.5.2.
+
+ Program
+ Program operations are implemented as explained in 30.4.5.3. Following
+ this operation, the shadow registers are reloaded by the hardware (not
+ immediately, but this does not make any difference for a user reading
+ these registers).
+
+ Override
+ Override operations are implemented as write accesses to the shadow
+ registers, as explained in 30.4.5.4.
+
+Configuration:
+
+ CONFIG_FSL_IIM
+ Define this to enable the fsl_iim driver.
diff --git a/roms/u-boot/doc/README.fuse b/roms/u-boot/doc/README.fuse
new file mode 100644
index 000000000..1bc91c44a
--- /dev/null
+++ b/roms/u-boot/doc/README.fuse
@@ -0,0 +1,67 @@
+Fuse API functions and commands
+
+The fuse API allows to control a fusebox and how it is used by the upper
+hardware layers.
+
+A fuse corresponds to a single non-volatile memory bit that can be programmed
+(i.e. blown, set to 1) only once. The programming operation is irreversible. A
+fuse that has not been programmed reads 0.
+
+Fuses can be used by SoCs to store various permanent configuration and data,
+e.g. boot configuration, security configuration, MAC addresses, etc.
+
+A fuse word is the smallest group of fuses that can be read at once from the
+fusebox control IP registers. This is limited to 32 bits with the current API.
+
+A fuse bank is the smallest group of fuse words having a common ID, as defined
+by each SoC.
+
+Upon startup, the fusebox control IP reads the fuse values and stores them to a
+volatile shadow cache.
+
+See the README files of the drivers implementing this API in order to know the
+SoC- and implementation-specific details.
+
+Functions / commands:
+
+ int fuse_read(u32 bank, u32 word, u32 *val);
+ fuse read <bank> <word> [<cnt>]
+ Read fuse words from the shadow cache.
+
+ int fuse_sense(u32 bank, u32 word, u32 *val);
+ fuse sense <bank> <word> [<cnt>]
+ Sense - i.e. read directly from the fusebox, skipping the shadow cache -
+ fuse words. This operation does not update the shadow cache.
+
+ This is useful to know the true value of fuses if an override has been
+ performed (see below).
+
+ int fuse_prog(u32 bank, u32 word, u32 val);
+ fuse prog [-y] <bank> <word> <hexval> [<hexval>...]
+ Program fuse words. This operation directly affects the fusebox and is
+ irreversible. The shadow cache is updated accordingly or not, depending on
+ each IP.
+
+ Only the bits to be programmed should be set in the input value (i.e. for
+ fuse bits that have already been programmed and hence should be left
+ unchanged by a further programming, it is preferable to clear the
+ corresponding bits in the input value in order not to perform a new
+ hardware programming operation on these fuse bits).
+
+ int fuse_override(u32 bank, u32 word, u32 val);
+ fuse override <bank> <word> <hexval> [<hexval>...]
+ Override fuse words in the shadow cache.
+
+ The fusebox is unaffected, so following this operation, the shadow cache
+ may differ from the fusebox values. Read or sense operations can then be
+ used to get the values from the shadow cache or from the fusebox.
+
+ This is useful to change the behaviors linked to some cached fuse values,
+ either because this is needed only temporarily, or because some of the
+ fuses have already been programmed or are locked (if the SoC allows to
+ override a locked fuse).
+
+Configuration:
+
+ CONFIG_CMD_FUSE
+ Define this to enable the fuse commands.
diff --git a/roms/u-boot/doc/README.generic-board b/roms/u-boot/doc/README.generic-board
new file mode 100644
index 000000000..bc35179fb
--- /dev/null
+++ b/roms/u-boot/doc/README.generic-board
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2014 Google, Inc
+# Simon Glass <sjg@chromium.org>
+
+Background
+----------
+
+U-Boot traditionally had a board.c file for each architecture. This introduced
+quite a lot of duplication, with each architecture tending to do
+initialisation slightly differently. To address this, a new 'generic board
+init' feature was introduced in March 2013 (further motivation is
+provided in the cover letter below).
+
+All boards and architectures have moved to this as of mid 2016.
+
+
+What has changed?
+-----------------
+
+The main change is that the arch/<arch>/lib/board.c file is removed in
+favour of common/board_f.c (for pre-relocation init) and common/board_r.c
+(for post-relocation init).
+
+Related to this, the global_data and bd_info structures now have a core set of
+fields which are common to all architectures. Architecture-specific fields
+have been moved to separate structures.
+
+
+Further Background
+------------------
+
+The full text of the original generic board series is reproduced below.
+
+--8<-------------
+
+This series creates a generic board.c implementation which contains
+the essential functions of the major arch/xxx/lib/board.c files.
+
+What is the motivation for this change?
+
+1. There is a lot of repeated code in the board.c files. Any change to
+things like setting up the baud rate requires a change in 10 separate
+places.
+
+2. Since there are 10 separate files, adding a new feature which requires
+initialisation is painful since it must be independently added in 10
+places.
+
+3. As time goes by the architectures naturally diverge since there is limited
+pressure to compare features or even CONFIG options against similar things
+in other board.c files.
+
+4. New architectures must implement all the features all over again, and
+sometimes in subtle different ways. This places an unfair burden on getting
+a new architecture fully functional and running with U-Boot.
+
+5. While it is a bit of a tricky change, I believe it is worthwhile and
+achievable. There is no requirement that all code be common, only that
+the code that is common should be located in common/board.c rather than
+arch/xxx/lib/board.c.
+
+All the functions of board_init_f() and board_init_r() are broken into
+separate function calls so that they can easily be included or excluded
+for a particular architecture. It also makes it easier to adopt Graeme's
+initcall proposal when it is ready.
+
+http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
+
+This series removes the dependency on generic relocation. So relocation
+happens as one big chunk and is still completely arch-specific. See the
+relocation series for a proposed solution to this for ARM:
+
+http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
+
+or Graeme's recent x86 series v2:
+
+http://lists.denx.de/pipermail/u-boot/2012-January/114467.html
+
+Instead of moving over a whole architecture, this series takes the approach
+of simply enabling generic board support for an architecture. It is then up
+to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
+config file. If this is not done, then the code will be generated as
+before. This allows both sets of code to co-exist until we are comfortable
+with the generic approach, and enough boards run.
+
+ARM is a relatively large board.c file and one which I can test, therefore
+I think it is a good target for this series. On the other hand, x86 is
+relatively small and simple, but different enough that it introduces a
+few issues to be solved. So I have chosen both ARM and x86 for this series.
+After a suggestion from Wolfgang I have added PPC also. This is the
+largest and most feature-full board, so hopefully we have all bases
+covered in this RFC.
+
+A generic global_data structure is also required. This might upset a few
+people. Here is my basic reasoning: most fields are the same, all
+architectures include and need it, most global_data.h files already have
+#ifdefs to select fields for a particular SOC, so it is hard to
+see why architecures are different in this area. We can perhaps add a
+way to put architecture-specific fields into a separate header file, but
+for now I have judged that to be counter-productive.
+
+Similarly we need a generic bd_info structure, since generic code will
+be accessing it. I have done this in the same way as global_data and the
+same comments apply.
+
+There was dicussion on the list about passing gd_t around as a parameter
+to pre-relocation init functions. I think this makes sense, but it can
+be done as a separate change, and this series does not require it.
+
+While this series needs to stand on its own (as with the link script
+cleanup series and the generic relocation series) the goal is the
+unification of the board init code. So I hope we can address issues with
+this in mind, rather than focusing too narrowly on particular ARM, x86 or
+PPC issues.
+
+I have run-tested ARM on Tegra Seaboard only. To try it out, define
+CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on
+x86 and PPC at least it will hang, but if you are lucky it will print
+something first :-)
+
+I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all
+ARM, PPC and x86 boards. There are a few failures due to errors in
+the board config, which I have sent patches for. The main issue is
+just the difference between __bss_end and __bss_end__.
+
+Note: the first group of commits are required for this series to build,
+but could be separated out if required. I have included them here for
+convenience.
+
+------------->8--
+
+Simon Glass, sjg@chromium.org
+March 2014
+Updated after final removal, May 2016
diff --git a/roms/u-boot/doc/README.generic_usb_ohci b/roms/u-boot/doc/README.generic_usb_ohci
new file mode 100644
index 000000000..65b0896c7
--- /dev/null
+++ b/roms/u-boot/doc/README.generic_usb_ohci
@@ -0,0 +1,63 @@
+Notes on the the generic USB-OHCI driver
+========================================
+
+This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of
+various existing OHCI drivers that were basically identical beside
+cpu/board dependant initalization. This initalization has been moved
+into cpu/board directories and are called via the hooks below.
+
+Configuration options
+----------------------
+
+ CONFIG_USB_OHCI_NEW: enable the new OHCI driver
+
+ CONFIG_SYS_USB_OHCI_BOARD_INIT: call the board dependant hooks:
+
+ - extern int board_usb_init(void);
+ - extern int usb_board_stop(void);
+ - extern int usb_cpu_init_fail(void);
+
+ CONFIG_SYS_USB_OHCI_CPU_INIT: call the cpu dependant hooks:
+
+ - extern int usb_cpu_init(void);
+ - extern int usb_cpu_stop(void);
+ - extern int usb_cpu_init_fail(void);
+
+ CONFIG_SYS_USB_OHCI_REGS_BASE: defines the base address of the OHCI
+ registers
+
+ CONFIG_SYS_USB_OHCI_SLOT_NAME: slot name
+
+ CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS: maximal number of ports of the
+ root hub.
+
+
+Endianness issues
+------------------
+
+The USB bus operates in little endian, but unfortunately there are
+OHCI controllers that operate in big endian such as ppc4xx. For these the
+config option
+
+ CONFIG_SYS_OHCI_BE_CONTROLLER
+
+needs to be defined.
+
+
+PCI Controllers
+----------------
+
+You'll need to define
+
+ CONFIG_PCI_OHCI
+
+If you have several USB PCI controllers, define
+
+ CONFIG_PCI_OHCI_DEVNO: number of the OHCI device in PCI list
+
+If undefined, the first instance found in PCI space will be used.
+
+PCI Controllers need to do byte swapping on register accesses, so they
+should to define:
+
+ CONFIG_SYS_OHCI_SWAP_REG_ACCESS
diff --git a/roms/u-boot/doc/README.gpio b/roms/u-boot/doc/README.gpio
new file mode 100644
index 000000000..548ff37b8
--- /dev/null
+++ b/roms/u-boot/doc/README.gpio
@@ -0,0 +1,42 @@
+
+GPIO hog (CONFIG_GPIO_HOG)
+--------
+
+All the GPIO hog are initialized in gpio_hog_probe_all() function called in
+board_r.c just before board_late_init() but you can also acces directly to
+the gpio with gpio_hog_lookup_name().
+
+
+Example, for the device tree:
+
+ tca6416@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ env_reset {
+ gpio-hog;
+ input;
+ gpios = <6 GPIO_ACTIVE_LOW>;
+ };
+ boot_rescue {
+ gpio-hog;
+ input;
+ line-name = "foo-bar-gpio";
+ gpios = <7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+You can than access the gpio in your board code with:
+
+ struct gpio_desc *desc;
+ int ret;
+
+ ret = gpio_hog_lookup_name("boot_rescue", &desc);
+ if (ret)
+ return;
+ if (dm_gpio_get_value(desc) == 1)
+ printf("\nBooting into Rescue System\n");
+ else if (dm_gpio_get_value(desc) == 0)
+ printf("\nBoot normal\n");
diff --git a/roms/u-boot/doc/README.gpt b/roms/u-boot/doc/README.gpt
new file mode 100644
index 000000000..91e397d06
--- /dev/null
+++ b/roms/u-boot/doc/README.gpt
@@ -0,0 +1,315 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2012 Samsung Electronics
+#
+# Lukasz Majewski <l.majewski@samsung.com>
+
+Glossary:
+========
+- UUID -(Universally Unique Identifier)
+- GUID - (Globally Unique ID)
+- EFI - (Extensible Firmware Interface)
+- UEFI - (Unified EFI) - EFI evolution
+- GPT (GUID Partition Table) - it is the EFI standard part
+- partitions - lists of available partitions (defined at u-boot):
+ ./include/configs/{target}.h
+
+Introduction:
+=============
+This document describes the GPT partition table format and usage of
+the gpt command in u-boot.
+
+UUID introduction:
+====================
+
+GPT for marking disks/partitions is using the UUID. It is supposed to be a
+globally unique value. A UUID is a 16-byte (128-bit) number. The number of
+theoretically possible UUIDs is therefore about 3 x 10^38.
+More often UUID is displayed as 32 hexadecimal digits, in 5 groups,
+separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters
+(32 digits and 4 hyphens)
+
+For instance, GUID of Basic data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
+and GUID of Linux filesystem data: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
+
+Historically there are 5 methods to generate this number. The oldest one is
+combining machine's MAC address and timer (epoch) value.
+
+Successive versions are using MD5 hash, random numbers and SHA-1 hash. All major
+OSes and programming languages are providing libraries to compute UUID (e.g.
+uuid command line tool).
+
+GPT brief explanation:
+======================
+
+ Layout:
+ -------
+
+ --------------------------------------------------
+ LBA 0 |Protective MBR |
+ ----------------------------------------------------------
+ LBA 1 |Primary GPT Header | Primary
+ -------------------------------------------------- GPT
+ LBA 2 |Entry 1|Entry 2| Entry 3| Entry 4|
+ --------------------------------------------------
+ LBA 3 |Entries 5 - 128 |
+ | |
+ | |
+ ----------------------------------------------------------
+ LBA 34 |Partition 1 |
+ | |
+ -----------------------------------
+ |Partition 2 |
+ | |
+ -----------------------------------
+ |Partition n |
+ | |
+ ----------------------------------------------------------
+ LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4| Backup
+ -------------------------------------------------- GPT
+ LBA -33 |Entries 5 - 128 |
+ | |
+ | |
+ LBA -2 | |
+ --------------------------------------------------
+ LBA -1 |Backup GPT Header |
+ ----------------------------------------------------------
+
+For a legacy reasons, GPT's LBA 0 sector has a MBR structure. It is called
+"protective MBR".
+Its first partition entry ID has 0xEE value, and disk software, which is not
+handling the GPT sees it as a storage device without free space.
+
+It is possible to define 128 linearly placed partition entries.
+
+"LBA -1" means the last addressable block (in the mmc subsystem:
+"dev_desc->lba - 1")
+
+Primary/Backup GPT header:
+----------------------------
+Offset Size Description
+
+0 8 B Signature ("EFI PART", 45 46 49 20 50 41 52 54)
+8 4 B Revision (For version 1.0, the value is 00 00 01 00)
+12 4 B Header size (in bytes, usually 5C 00 00 00 meaning 92 bytes)
+16 4 B CRC32 of header (0 to header size), with this field zeroed
+ during calculation
+20 4 B Reserved (ZERO);
+24 8 B Current LBA (location of this header copy)
+32 8 B Backup LBA (location of the other header copy)
+40 8 B First usable LBA for partitions (primary partition table last
+ LBA + 1)
+48 8 B Last usable LBA (secondary partition table first LBA - 1)
+56 16 B Disk GUID (also referred as UUID on UNIXes)
+72 8 B Partition entries starting LBA (always 2 in primary copy)
+80 4 B Number of partition entries
+84 4 B Size of a partition entry (usually 128)
+88 4 B CRC32 of partition array
+92 * Reserved; must be ZERO (420 bytes for a 512-byte LBA)
+
+TOTAL: 512 B
+
+
+IMPORTANT:
+
+GPT headers and partition entries are protected by CRC32 (the POSIX CRC32).
+
+Primary GPT header and Backup GPT header have swapped values of "Current LBA"
+and "Backup LBA" and therefore different CRC32 check-sum.
+
+CRC32 for GPT headers (field "CRC of header") are calculated up till
+"Header size" (92), NOT 512 bytes.
+
+CRC32 for partition entries (field "CRC32 of partition array") is calculated for
+the whole array entry ( Number_of_partition_entries *
+sizeof(partition_entry_size (usually 128)))
+
+Observe, how Backup GPT is placed in the memory. It is NOT a mirror reflect
+of the Primary.
+
+ Partition Entry Format:
+ ----------------------
+ Offset Size Description
+
+ 0 16 B Partition type GUID (Big Endian)
+ 16 16 B Unique partition GUID in (Big Endian)
+ 32 8 B First LBA (Little Endian)
+ 40 8 B Last LBA (inclusive)
+ 48 8 B Attribute flags [+]
+ 56 72 B Partition name (text)
+
+ Attribute flags:
+ Bit 0 - System partition
+ Bit 1 - Hide from EFI
+ Bit 2 - Legacy BIOS bootable
+ Bit 48-63 - Defined and used by the individual partition type
+ For Basic data partition :
+ Bit 60 - Read-only
+ Bit 62 - Hidden
+ Bit 63 - Not mount
+
+Creating GPT partitions in U-Boot:
+==============
+
+To restore GUID partition table one needs to:
+1. Define partition layout in the environment.
+ Format of partitions layout:
+ "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
+ name=kernel,size=60MiB,uuid=...;"
+ or
+ "uuid_disk=${uuid_gpt_disk};name=${uboot_name},
+ size=${uboot_size},uuid=${uboot_uuid};"
+
+ The fields 'name' and 'size' are mandatory for every partition.
+ The field 'start' is optional.
+
+ If field 'size' of the last partition is 0, the partition is extended
+ up to the end of the device.
+
+ The fields 'uuid' and 'uuid_disk' are optional if CONFIG_RANDOM_UUID is
+ enabled. A random uuid will be used if omitted or they point to an empty/
+ non-existent environment variable. The environment variable will be set to
+ the generated UUID. The 'gpt guid' command reads the current value of the
+ uuid_disk from the GPT.
+
+ The field 'bootable' is optional, it is used to mark the GPT partition
+ bootable (set attribute flags "Legacy BIOS bootable").
+ "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;name=rootfs,size=0"
+ It can be used to locate bootable disks with command
+ "part list <interface> <dev> -bootable <varname>",
+ please check out doc/README.distro for use.
+
+2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT'
+
+3. From u-boot prompt type:
+ gpt write mmc 0 $partitions
+
+Checking (validating) GPT partitions in U-Boot:
+===============================================
+
+Procedure is the same as above. The only change is at point 3.
+
+At u-boot prompt one needs to write:
+ gpt verify mmc 0 [$partitions]
+
+where [$partitions] is an optional parameter.
+
+When it is not provided, only basic checks based on CRC32 calculation for GPT
+header and PTEs are performed.
+When provided, additionally partition data - name, size and starting
+offset (last two in LBA) - are compared with data defined in '$partitions'
+environment variable.
+
+After running this command, return code is set to 0 if no errors found in
+on non-volatile medium stored GPT.
+
+Following line can be used to assess if GPT verification has succeed:
+
+U-BOOT> gpt verify mmc 0 $partitions
+U-BOOT> if test $? = 0; then echo "GPT OK"; else echo "GPT ERR"; fi
+
+Renaming GPT partitions from U-Boot:
+====================================
+
+GPT partition names are a mechanism via which userspace and U-Boot can
+communicate about software updates and boot failure. The 'gpt guid',
+'gpt read', 'gpt rename' and 'gpt swap' commands facilitate
+programmatic renaming of partitions from bootscripts by generating and
+modifying the partitions layout string. Here is an illustration of
+employing 'swap' to exchange 'primary' and 'backup' partition names:
+
+U-BOOT> gpt swap mmc 0 primary backup
+
+Afterwards, all partitions previously named 'primary' will be named
+'backup', and vice-versa. Alternatively, single partitions may be
+renamed. In this example, mmc0's first partition will be renamed
+'primary':
+
+U-BOOT> gpt rename mmc 0 1 primary
+
+The GPT functionality may be tested with the 'sandbox' board by
+creating a disk image as described under 'Block Device Emulation' in
+doc/arch/index.rst:
+
+=>host bind 0 ./disk.raw
+=> gpt read host 0
+[ . . . ]
+=> gpt swap host 0 name othername
+[ . . . ]
+
+Modifying GPT partition layout from U-Boot:
+===========================================
+
+The entire GPT partition layout can be exported to an environment
+variable and then modified enmasse. Users can change the partition
+numbers, offsets, names and sizes. The resulting variable can used to
+reformat the device. Here is an example of reading the GPT partitions
+into a variable and then modifying them:
+
+U-BOOT> gpt read mmc 0 current_partitions
+U-BOOT> env edit current_partitions
+edit: uuid_disk=[...];name=part1,start=0x4000,size=0x4000,uuid=[...];
+name=part2,start=0xc000,size=0xc000,uuid=[...];[ . . . ]
+
+U-BOOT> gpt write mmc 0 $current_partitions
+U-BOOT> gpt verify mmc 0 $current_partitions
+
+Partition type GUID:
+====================
+
+For created partition, the used partition type GUID is
+PARTITION_BASIC_DATA_GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7).
+
+If you define 'CONFIG_PARTITION_TYPE_GUID', a optionnal parameter 'type'
+can specify a other partition type guid:
+
+ "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
+ name=kernel,size=60MiB,uuid=...,
+ type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;"
+
+Some strings can be also used at the place of known GUID :
+ "system" = PARTITION_SYSTEM_GUID
+ (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)
+ "mbr" = LEGACY_MBR_PARTITION_GUID
+ (024DEE41-33E7-11D3-9D69-0008C781F39F)
+ "msft" = PARTITION_MSFT_RESERVED_GUID
+ (E3C9E316-0B5C-4DB8-817D-F92DF00215AE)
+ "data" = PARTITION_BASIC_DATA_GUID
+ (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)
+ "linux" = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID
+ (0FC63DAF-8483-4772-8E79-3D69D8477DE4)
+ "raid" = PARTITION_LINUX_RAID_GUID
+ (A19D880F-05FC-4D3B-A006-743F0F84911E)
+ "swap" = PARTITION_LINUX_SWAP_GUID
+ (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F)
+ "lvm" = PARTITION_LINUX_LVM_GUID
+ (E6D6D379-F507-44C2-A23C-238F2A3DF928)
+ "u-boot-env" = PARTITION_U_BOOT_ENVIRONMENT
+ (3DE21764-95BD-54BD-A5C3-4ABE786F38A8)
+
+ "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
+ name=kernel,size=60MiB,uuid=...,type=linux;"
+
+They are also used to display the type of partition in "part list" command.
+
+
+Useful info:
+============
+
+Two programs, namely: 'gdisk' and 'parted' are recommended to work with GPT
+recovery. Both are able to handle GUID partitions.
+Please, pay attention at -l switch for parted.
+
+"uuid" program is recommended to generate UUID string. Moreover it can decode
+(-d switch) passed in UUID string. It can be used to generate partitions UUID
+passed to u-boot environment variables.
+If optional CONFIG_RANDOM_UUID is defined then for any partition which environment
+uuid is unset, uuid is randomly generated and stored in correspond environment
+variable.
+
+note:
+Each string block of UUID generated by program "uuid" is in big endian and it is
+also stored in big endian in disk GPT.
+Partitions layout can be printed by typing "mmc part". Note that each partition
+GUID has different byte order than UUID generated before, this is because first
+three blocks of GUID string are in Little Endian.
diff --git a/roms/u-boot/doc/README.hwconfig b/roms/u-boot/doc/README.hwconfig
new file mode 100644
index 000000000..b6ddb438c
--- /dev/null
+++ b/roms/u-boot/doc/README.hwconfig
@@ -0,0 +1,50 @@
+To enable this feature just define CONFIG_HWCONFIG in your board
+config file.
+
+This implements a simple hwconfig infrastructure: an
+interface for software knobs to control hardware.
+
+This a is very simple implementation, i.e. it is implemented
+via the `hwconfig' environment variable. Later we could write
+some "hwconfig <enable|disable|list>" commands, ncurses
+interface for Award BIOS-like interface, and frame-buffer
+interface for AMI GUI[1] BIOS-like interface with mouse
+support[2].
+
+Current implementation details/limitations:
+
+1. Doesn't support options dependencies and mutual exclusion.
+ We can implement this by integrating apt-get[3] into Das
+ U-Boot. But I haven't bothered yet.
+
+2. Since we don't implement a hwconfig command, i.e. we're working
+ with the environment directly, there is no way to tell that
+ toggling a particular option will need a reboot to take
+ effect. So, for now it's advised to always reboot the
+ target after modifying the hwconfig variable.
+
+3. We support hwconfig options with arguments. For example,
+
+ set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi"
+
+ This selects three hwconfig options:
+ 1. dr_usb - enable Dual-Role USB controller;
+ 2. dr_usb_mode:peripheral - USB in Function mode;
+ 3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs.
+
+The purpose of this simple implementation is to refine the
+internal API and then we can continue improving the user
+experience by adding more mature interfaces, like a hwconfig
+command with bells and whistles. Or not adding, if we feel
+that the current interface fits people's needs.
+
+[1] http://en.wikipedia.org/wiki/American_Megatrends
+[2] Regarding ncurses and GUI with mouse support -- I'm just
+ kidding.
+[3] The comment regarding apt-get is also a joke, meaning that
+ dependency tracking could be non-trivial. For example, for
+ enabling HW feature X we may need to disable Y, and turn Z
+ into reduced mode (like RMII-only interface for ethernet,
+ no MII).
+
+ It's quite trivial to implement simple cases though.
diff --git a/roms/u-boot/doc/README.i2c b/roms/u-boot/doc/README.i2c
new file mode 100644
index 000000000..07cd8df85
--- /dev/null
+++ b/roms/u-boot/doc/README.i2c
@@ -0,0 +1,60 @@
+I2C Bus Arbitration
+===================
+
+While I2C supports multi-master buses this is difficult to get right.
+The implementation on the master side in software is quite complex.
+Clock-stretching and the arbitrary time that an I2C transaction can take
+make it difficult to share the bus fairly in the face of high traffic.
+When one or more masters can be reset independently part-way through a
+transaction it is hard to know the state of the bus.
+
+U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the
+AP (Application Processor, meaning the main CPU) and one driven by the EC
+(Embedded Controller, a small CPU aimed at handling system tasks). With
+these they can communicate and reliably share the bus. This scheme has
+minimal overhead and involves very little code. The scheme can survive
+reboots by either side without difficulty.
+
+Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
+meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
+is used by the device tree bindings in Linux also.
+
+The driver is implemented as an I2C mux, as it is in Linux. See
+i2c-arb-gpio-challenge for the implementation.
+
+GPIO lines are shared between the AP and EC to manage the bus. The AP and EC
+each have a 'bus claim' line, which is an output that the other can see.
+
+- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
+- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say the AP wants to claim the bus. It:
+
+1. Asserts AP_CLAIM
+2. Waits a little bit for the other side to notice (slew time)
+3. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we
+ are done
+4. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is
+ released
+5. If not, back off, release the claim and wait for a few more milliseconds
+ (retry time again)
+6. Go back to 1 if things don't look wedged (wait time has expired)
+7. Panic. The other side is hung with the CLAIM line set.
+
+The same algorithm applies on the EC.
+
+To release the bus, just de-assert the claim line.
+
+Typical delays are:
+- slew time 10 us
+- retry time 3 ms
+- wait time - 50ms
+
+In general the traffic is fairly light, and in particular the EC wants access
+to the bus quite rarely (maybe every 10s or 30s to check the battery). This
+scheme works very nicely with very low contention. There is only a 10 us
+wait for access to the bus assuming that the other side isn't using it.
diff --git a/roms/u-boot/doc/README.iomux b/roms/u-boot/doc/README.iomux
new file mode 100644
index 000000000..c428811ce
--- /dev/null
+++ b/roms/u-boot/doc/README.iomux
@@ -0,0 +1,89 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de>
+ */
+
+U-Boot console multiplexing
+===========================
+
+HOW CONSOLE MULTIPLEXING WORKS
+------------------------------
+
+This functionality is controlled with CONFIG_CONSOLE_MUX in the board
+configuration file.
+
+Two new files, common/iomux.c and include/iomux.h, contain the heart
+(iomux_doenv()) of the environment setting implementation.
+
+iomux_doenv() is called in common/cmd_nvedit.c to handle setenv and in
+common/console.c in console_init_r() during bootup to initialize
+stdio_devices[].
+
+A user can use a comma-separated list of devices to set stdin, stdout
+and stderr. For example: "setenv stdin serial,nc". NOTE: No spaces
+are allowed around the comma(s)!
+
+The length of the list is limited by malloc(), since the array used
+is allocated and freed dynamically.
+
+It should be possible to specify any device which console_assign()
+finds acceptable, but the code has only been tested with serial and
+nc.
+
+iomux_doenv() prevents multiple use of the same device, e.g. "setenv
+stdin nc,nc,serial" will discard the second nc. iomux_doenv() is
+not able to modify the environment, however, so that "pri stdin" still
+shows "nc,nc,serial".
+
+The major change in common/console.c was to modify fgetc() to call
+the iomux_tstc() routine in a for-loop. iomux_tstc() in turn calls
+the tstc() routine for every registered device, but exits immediately
+when one of them returns true. fgetc() then calls iomux_getc(),
+which calls the corresponding getc() routine. fgetc() hangs in
+the for-loop until iomux_tstc() returns true and the input can be
+retrieved.
+
+Thus, a user can type into any device registered for stdin. No effort
+has been made to demulitplex simultaneous input from multiple stdin
+devices.
+
+fputc() and fputs() have been modified to call iomux_putc() and
+iomux_puts() respectively, which call the corresponding output
+routines for every registered device.
+
+Thus, a user can see the ouput for any device registered for stdout
+or stderr on all devices registered for stdout or stderr. As an
+example, if stdin=serial,nc and stdout=serial,nc then all output
+for serial, e.g. echos of input on serial, will appear on serial and nc.
+
+Just as with the old console code, this statement is still true:
+If not defined in the environment, the first input device is assigned
+to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
+
+If CONFIG_SYS_CONSOLE_IS_IN_ENV is defined then multiple input/output
+devices can be set at boot time if defined in the environment.
+
+CAVEATS
+-------
+
+Note that common/iomux.c calls console_assign() for every registered
+device as it is discovered. This means that the environment settings
+for application consoles will be set to the last device in the list.
+
+On a slow machine, such as MPC852T clocked at 66MHz, the overhead associated
+with calling tstc() and then getc() means that copy&paste will normally not
+work, even when stdin=stdout=stderr=serial.
+On a faster machine, such as a sequoia, cut&paste of longer (about 80
+characters) lines works fine when serial is the only device used.
+
+Using nc as a stdin device results in even more overhead because nc_tstc()
+is quite slow. Even on a sequoia cut&paste does not work on the serial
+interface when nc is added to stdin, although there is no character loss using
+the ethernet interface for input. In this test case stdin=serial,nc and
+stdout=serial.
+
+In addition, the overhead associated with sending to two devices, when one of
+them is nc, also causes problems. Even on a sequoia cut&paste does not work
+on the serial interface (stdin=serial) when nc is added to stdout (stdout=
+serial,nc).
diff --git a/roms/u-boot/doc/README.kconfig b/roms/u-boot/doc/README.kconfig
new file mode 100644
index 000000000..0689f66c2
--- /dev/null
+++ b/roms/u-boot/doc/README.kconfig
@@ -0,0 +1,158 @@
+Kconfig in U-Boot
+=================
+
+This document describes the configuration infrastructure of U-Boot.
+
+The conventional configuration was replaced by Kconfig at v2014.10-rc1 release.
+
+
+Language Specification
+----------------------
+
+Kconfig originates in Linux Kernel.
+See the file "Documentation/kbuild/kconfig*.txt" in your Linux Kernel
+source directory for a basic specification of Kconfig.
+
+
+Difference from Linux's Kconfig
+-------------------------------
+
+Here are some worth-mentioning configuration targets.
+
+- silentoldconfig
+
+ This target updates .config, include/generated/autoconf.h and
+ include/configs/* as in Linux. In U-Boot, it also does the following
+ for the compatibility with the old configuration system:
+
+ * create a symbolic link "arch/${ARCH}/include/asm/arch" pointing to
+ the SoC/CPU specific header directory
+ * create include/config.h
+ * create include/autoconf.mk
+ * create spl/include/autoconf.mk (SPL and TPL only)
+ * create tpl/include/autoconf.mk (TPL only)
+
+ If we could completely switch to Kconfig in a long run
+ (i.e. remove all the include/configs/*.h), those additional processings
+ above would be removed.
+
+- defconfig
+
+ In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig"
+
+- <board>_defconfig
+
+ Now it works as in Linux.
+ The prefixes such as "+S:" in *_defconfig are deprecated.
+ You can simply remove the prefixes. Do not add them for new boards.
+
+- <board>_config
+
+ This does not exist in Linux's Kconfig.
+ "make <board>_config" works the same as "make <board>_defconfig".
+ Prior to Kconfig, in U-Boot, "make <board>_config" was used for the
+ configuration. It is still supported for backward compatibility, so
+ we do not need to update the distro recipes.
+
+
+The other configuration targets work as in Linux Kernel.
+
+
+Migration steps to Kconfig
+--------------------------
+
+Prior to Kconfig, the C preprocessor based board configuration had been used
+in U-Boot.
+
+Although Kconfig was introduced and some configs have been moved to Kconfig,
+many of configs are still defined in C header files. It will take a very
+long term to move all of them to Kconfig. In the interim, the two different
+configuration infrastructures should coexist.
+The configuration files are generated by both Kconfig and the old preprocessor
+based configuration as follows:
+
+Configuration files for use in C sources
+ - include/generated/autoconf.h (generated by Kconfig for Normal)
+ - include/configs/<board>.h (exists for all boards)
+
+Configuration file for use in makefiles
+ - include/config/auto.conf (generated by Kconfig)
+ - include/autoconf.mk (generated by the old config for Normal)
+ - spl/include/autoconfig.mk (generated by the old config for SPL)
+ - tpl/include/autoconfig.mk (generated by the old config for TPL)
+
+When adding a new CONFIG macro, it is highly recommended to add it to Kconfig
+rather than to a header file.
+
+
+Conversion from boards.cfg to Kconfig
+-------------------------------------
+
+Prior to Kconfig, boards.cfg was a primary database that contained Arch, CPU,
+SoC, etc. of all the supported boards. It was deleted when switching to
+Kconfig. Each field of boards.cfg was converted as follows:
+
+ Status -> "S:" entry of MAINTAINERS
+ Arch -> CONFIG_SYS_ARCH defined by Kconfig
+ CPU -> CONFIG_SYS_CPU defined by Kconfig
+ SoC -> CONFIG_SYS_SOC defined by Kconfig
+ Vendor -> CONFIG_SYS_VENDOR defined by Kconfig
+ Board -> CONFIG_SYS_BOARD defined by Kconfig
+ Target -> File name of defconfig (configs/<target>_defconfig)
+ Options -> CONFIG_SYS_EXTRA_OPTIONS defined by Kconfig
+ Maintainers -> "M:" entry of MAINTAINERS
+
+
+Tips to add/remove boards
+-------------------------
+
+When adding a new board, the following steps are generally needed:
+
+ [1] Add a header file include/configs/<target>.h
+ [2] Make sure to define necessary CONFIG_SYS_* in Kconfig:
+ Define CONFIG_SYS_CPU="cpu" to compile arch/<arch>/cpu/<cpu>
+ Define CONFIG_SYS_SOC="soc" to compile arch/<arch>/cpu/<cpu>/<soc>
+ Define CONFIG_SYS_VENDOR="vendor" to compile board/<vendor>/common/*
+ and board/<vendor>/<board>/*
+ Define CONFIG_SYS_BOARD="board" to compile board/<board>/*
+ (or board/<vendor>/<board>/* if CONFIG_SYS_VENDOR is defined)
+ Define CONFIG_SYS_CONFIG_NAME="target" to include
+ include/configs/<target>.h
+ [3] Add a new entry to the board select menu in Kconfig.
+ The board select menu is located in arch/<arch>/Kconfig or
+ arch/<arch>/*/Kconfig.
+ [4] Add a MAINTAINERS file
+ It is generally placed at board/<board>/MAINTAINERS or
+ board/<vendor>/<board>/MAINTAINERS
+ [5] Add configs/<target>_defconfig
+
+When removing an obsolete board, the following steps are generally needed:
+
+ [1] Remove configs/<target>_defconfig
+ [2] Remove include/configs/<target>.h if it is not used by any other boards
+ [3] Remove board/<vendor>/<board>/* or board/<board>/* if it is not used
+ by any other boards
+ [4] Update MAINTAINERS if necessary
+ [5] Remove the unused entry from the board select menu in Kconfig
+ [6] Add an entry to doc/README.scrapyard
+
+
+TODO
+----
+
+- The option field of boards.cfg, which was used for the pre-Kconfig
+ configuration, moved to CONFIG_SYS_EXTRA_OPTIONS verbatim now.
+ Board maintainers are expected to implement proper Kconfig options
+ and switch over to them. Eventually CONFIG_SYS_EXTRA_OPTIONS will go away.
+ CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards.
+
+- In the pre-Kconfig, a single board had multiple entries in the boards.cfg
+ file with differences in the option fields. The corresponding defconfig
+ files were auto-generated when switching to Kconfig. Now we have too many
+ defconfig files compared with the number of the supported boards. It is
+ recommended to have only one defconfig per board and allow users to select
+ the config options.
+
+- Move the config macros in header files to Kconfig. When we move at least
+ macros used in makefiles, we can drop include/autoconfig.mk, which makes
+ the build scripts much simpler.
diff --git a/roms/u-boot/doc/README.kwbimage b/roms/u-boot/doc/README.kwbimage
new file mode 100644
index 000000000..762b2e3ac
--- /dev/null
+++ b/roms/u-boot/doc/README.kwbimage
@@ -0,0 +1,104 @@
+---------------------------------------------
+Kirkwood Boot Image generation using mkimage
+---------------------------------------------
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Command syntax:
+--------------
+./tools/mkimage -l <kwboot_file>
+ to list the kwb image file details
+
+./tools/mkimage -n <board specific configuration file> \
+ -T kwbimage -a <start address> -e <execution address> \
+ -d <input_raw_binary> <output_kwboot_file>
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+ -T kwbimage -a 0x00600000 -e 0x00600000 \
+ -d u-boot.bin u-boot.kwb
+
+
+kwbimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash. The make target
+which uses mkimage to produce such an image is "u-boot.kwb". For example:
+
+ export KBUILD_OUTPUT=/tmp/build
+ make distclean
+ make yourboard_config
+ make u-boot.kwb
+
+
+Board specific configuration file specifications:
+------------------------------------------------
+1. This file must present in the $(BOARDDIR). The default name is
+ kwbimage.cfg. The name can be set as part of the full path
+ to the file using CONFIG_SYS_KWD_CONFIG (probably in
+ include/configs/<yourboard>.h). The path should look like:
+ $(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg
+2. This file can have empty lines and lines starting with "#" as first
+ character to put comments
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+---------------------------------
+1. Each command line is must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -------------- -----------
+ BOOT_FROM nand/spi/sata
+ NAND_ECC_MODE default/rs/hamming/disabled
+ NAND_PAGE_SIZE any uint16_t hex value
+ SATA_PIO_MODE any uint32_t hex value
+ DDR_INIT_DELAY any uint32_t hex value
+ DATA regaddr and regdara hex value
+ you can have maximum 55 such register programming commands
+
+3. All commands are optional to program
+
+Typical example of kwimage.cfg file:
+-----------------------------------
+
+# Boot Media configurations
+BOOT_FROM nand
+NAND_ECC_MODE default
+NAND_PAGE_SIZE 0x0800
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+# DRAM Configuration
+DATA 0xFFD01400 0x43000c30
+DATA 0xFFD01404 0x37543000
+DATA 0xFFD01408 0x22125451
+DATA 0xFFD0140C 0x00000a33
+DATA 0xFFD01410 0x000000cc
+DATA 0xFFD01414 0x00000000
+DATA 0xFFD01418 0x00000000
+DATA 0xFFD0141C 0x00000C52
+DATA 0xFFD01420 0x00000040
+DATA 0xFFD01424 0x0000F17F
+DATA 0xFFD01428 0x00085520
+DATA 0xFFD0147C 0x00008552
+DATA 0xFFD01504 0x0FFFFFF1
+DATA 0xFFD01508 0x10000000
+DATA 0xFFD0150C 0x0FFFFFF5
+DATA 0xFFD01514 0x00000000
+DATA 0xFFD0151C 0x00000000
+DATA 0xFFD01494 0x00030000
+DATA 0xFFD01498 0x00000000
+DATA 0xFFD0149C 0x0000E803
+DATA 0xFFD01480 0x00000001
+# End of Header extension
+DATA 0x0 0x0
+
+------------------------------------------------
+Author: Prafulla Wadaskar <prafulla@marvell.com>
diff --git a/roms/u-boot/doc/README.link-local b/roms/u-boot/doc/README.link-local
new file mode 100644
index 000000000..148b4987f
--- /dev/null
+++ b/roms/u-boot/doc/README.link-local
@@ -0,0 +1,75 @@
+------------------------------------------
+ Link-local IP address auto-configuration
+------------------------------------------
+
+Negotiate with other link-local clients on the local network
+for an address that doesn't require explicit configuration.
+This is especially useful if a DHCP server cannot be guaranteed
+to exist in all environments that the device must operate.
+
+This is an implementation of RFC3927.
+
+----------
+ Commands
+----------
+
+When CONFIG_CMD_LINK_LOCAL is defined in the board config file,
+the "linklocal" command is available. This running this will
+take approximately 5 seconds while the address is negotiated.
+
+------------------------
+ Environment interation
+------------------------
+
+The "llipaddr" variable is set with the most recently
+negotiated address and is preferred in future negotiations.
+
+The "ipaddr", "netmask", and "gatewayip" variables are set
+after successful negotiation to enable network access.
+
+-------------
+ Limitations
+-------------
+
+RFC3927 requires that addresses are continuously checked to
+avoid conflicts, however this can only happen when the net_loop
+is getting called. It is possible for a conflict to go undetected
+until a command that accesses the network is executed.
+
+Using NetConsole is one way to ensure that net_loop is always
+processing packets and monitoring for conflicts.
+
+This is also not a concern if the feature is use to connect
+directly to another machine that may not be running a DHCP server.
+
+----------------
+ Example script
+----------------
+
+This script allows use of DHCP and/or Link-local controlled
+by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP,
+and CONFIG_BOOTP_MAY_FAIL.
+If both fail or are disabled, static settings are used.
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "ipconfigcmd=if test \\\"$dhcpenabled\\\" -ne 0;" \
+ "then " \
+ "dhcpfail=0;dhcp || dhcpfail=1;" \
+ "else " \
+ "dhcpfail=-1;" \
+ "fi;" \
+ "if test \\\"$linklocalenabled\\\" -ne 0 -a " \
+ "\\\"$dhcpfail\\\" -ne 0;" \
+ "then " \
+ "linklocal;" \
+ "llfail=0;" \
+ "else " \
+ "llfail=-1;" \
+ "fi;" \
+ "if test \\\"$llfail\\\" -ne 0 -a " \
+ "\\\"$dhcpfail\\\" -ne 0; " \
+ "then " \
+ "setenv ipaddr $sipaddr; " \
+ "setenv netmask $snetmask; " \
+ "setenv gatewayip $sgatewayip; " \
+ "fi;\0" \
diff --git a/roms/u-boot/doc/README.lynxkdi b/roms/u-boot/doc/README.lynxkdi
new file mode 100644
index 000000000..076f01862
--- /dev/null
+++ b/roms/u-boot/doc/README.lynxkdi
@@ -0,0 +1,57 @@
+ LYNX KDI SUPPORT
+
+ Last Update: July 20, 2003
+=======================================================================
+
+This file describes support for LynuxWorks KDI within U-Boot. Support
+is enabled by defining CONFIG_LYNXKDI.
+
+
+LYNXOS AND BLUECAT SUPPORTED
+============================
+Both LynxOS and BlueCat linux KDIs are supported. The implementation
+automatically detects which is being booted. When you use mkimage
+you should specify "lynxos" for both (see target-specific notes).
+
+
+SUPPORTED ARCHITECTURE/TARGETS
+==============================
+The following targets have been tested:
+
+-PowerPC MPC8260ADS
+
+
+FILES TO LOOK AT
+================
+include/lynxkdi.h -defines a simple struct passed to a kdi.
+common/lynxkdi.c -implements the call to the kdi.
+common/cmd_bootm.c -top-level command implementation ("bootm").
+
+
+====================================================================
+TARGET SPECIFIC NOTES
+====================================================================
+
+MPC8260ADS
+===========
+The default LynxOS and BlueCat implementations require some
+modifications to the config file.
+
+Edit include/configs/MPC8260ADS.h to use the following:
+
+#define CONFIG_SYS_IMMR 0xFA200000
+#define CONFIG_SYS_BCSR 0xFA100000
+#define CONFIG_SYS_BR1_PRELIM 0xFA101801
+
+When creating a LynxOS or BlueCat u-boot image using mkimage,
+you must specify the following:
+
+Both: -A ppc -O lynxos -T kernel -C none
+LynxOS: -a 0x00004000 -e 0x00004020
+BlueCat: -a 0x00500000 -e 0x00507000
+
+To pass the MAC address to BlueCat you should define the
+"fcc2_ether_addr" parameter in the "bootargs" environment
+variable. E.g.:
+
+==> setenv bootargs fcc2_ether_addr=00:11:22:33:44:55:66
diff --git a/roms/u-boot/doc/README.m54418twr b/roms/u-boot/doc/README.m54418twr
new file mode 100644
index 000000000..0ca74aa11
--- /dev/null
+++ b/roms/u-boot/doc/README.m54418twr
@@ -0,0 +1,245 @@
+Freescale MCF54418TWR ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created Mar 22, 2012
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m54418twr/m54418twr.c Dram setup
+- board/freescale/m54418twr/Makefile Makefile
+- board/freescale/m54418twr/config.mk config make
+- board/freescale/m54418twr/u-boot.lds Linker description
+- board/freescale/m54418twr/sbf_dram_init.S
+ DDR/SDRAM initialization
+
+- arch/m68k/cpu/mcf5445x/cpu.c cpu specific code
+- arch/m68k/cpu/mcf5445x/cpu_init.c Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs
+- arch/m68k/cpu/mcf5445x/interrupts.c cpu specific interrupt support
+- arch/m68k/cpu/mcf5445x/speed.c system, pci, flexbus, and cpu clock
+- arch/m68k/cpu/mcf5445x/Makefile Makefile
+- arch/m68k/cpu/mcf5445x/config.mk config make
+- arch/m68k/cpu/mcf5445x/start.S start up assembly code
+
+- doc/README.m54418twr This readme file
+
+- drivers/net/mcffec.c ColdFire common FEC driver
+- drivers/net/mcfmii.c ColdFire common MII driver
+- drivers/serial/mcfuart.c ColdFire common UART driver
+
+- arch/m68k/include/asm/bitops.h Bit operation function export
+- arch/m68k/include/asm/byteorder.h Byte order functions
+- arch/m68k/include/asm/fec.h FEC structure and definition
+- arch/m68k/include/asm/global_data.h Global data structure
+- arch/m68k/include/asm/immap.h ColdFire specific header file and driver macros
+- arch/m68k/include/asm/immap_5441x.h mcf5441x specific header file
+- arch/m68k/include/asm/io.h io functions
+- arch/m68k/include/asm/m5441x.h mcf5441x specific header file
+- arch/m68k/include/asm/posix_types.h Posix
+- arch/m68k/include/asm/processor.h header file
+- arch/m68k/include/asm/ptrace.h Exception structure
+- arch/m68k/include/asm/rtc.h Realtime clock header file
+- arch/m68k/include/asm/string.h String function export
+- arch/m68k/include/asm/timer.h Timer structure and definition
+- arch/m68k/include/asm/types.h Data types definition
+- arch/m68k/include/asm/uart.h Uart structure and definition
+- arch/m68k/include/asm/u-boot.h u-boot structure
+
+- include/configs/M54418TWR.h Board specific configuration file
+
+- arch/m68k/lib/board.c board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts.c Coldfire common interrupt functions
+- arch/m68k/lib/time.c Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c Exception init code
+
+1 MCF5441x specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M54418TWR Development Board
+CONFIG_MCF5441x -- define for all MCF5441x CPUs
+CONFIG_M54418 -- define for all Freescale MCF54418 CPUs
+
+CONFIG_MCFUART -- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT -- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE -- define UART baudrate
+
+CONFIG_MCFFEC -- define to use common CF FEC driver
+CONFIG_MII -- enable to use MII driver
+CONFIG_SYS_DISCOVER_PHY -- enable PHY discovery
+CONFIG_SYS_RX_ETH_BUFFER -- Set FEC Receive buffer
+CONFIG_SYS_FAULT_ECHO_LINK_DOWN --
+CONFIG_SYS_FEC0_PINMUX -- Set FEC0 Pin configuration
+CONFIG_SYS_FEC1_PINMUX -- Set FEC1 Pin configuration
+CONFIG_SYS_FEC0_MIIBASE -- Set FEC0 MII base register
+CONFIG_SYS_FEC1_MIIBASE -- Set FEC0 MII base register
+MCFFEC_TOUT_LOOP -- set FEC timeout loop
+CONFIG_HAS_ETH1 -- define to enable second FEC in u-boot
+
+CONFIG_MCFTMR -- define to use DMA timer
+
+CONFIG_SYS_IMMR -- define for MBAR offset
+
+CONFIG_EXTRA_CLOCK -- Enable extra clock such as vco, flexbus, pci, etc
+
+CONFIG_SYS_MBAR -- define MBAR offset
+
+CONFIG_MONITOR_IS_IN_RAM -- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR -- defines the base address of the MCF54455 internal SRAM
+
+CONFIG_SYS_CSn_BASE -- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK -- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL -- defines the Chip Select Control register
+
+CONFIG_SYS_SDRAM_BASE -- defines the DRAM Base
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+ MRAM: 0x00000000-0x0003FFFF (256KB)
+ DDR: 0x40000000-0x47FFFFFF (128MB)
+ SRAM: 0x80000000-0x8000FFFF (64KB)
+ IP: 0xE0000000-0xFFFFFFFF (512MB)
+
+3. COMPILATION
+==============
+3.1 To create U-Boot the gcc-4.x compiler set (ColdFire ELF version)
+from codesourcery.com was used. Download it from:
+http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+3.2 Compilation
+ export CROSS_COMPILE=cross-compile-prefix
+ cd u-boot
+ make distclean
+ make M54418TWR_config, or - default to spi serial flash boot, 50Mhz input clock
+ make M54418TWR_nand_mii_config, or - default to nand flash boot, mii mode, 25Mhz input clock
+ make M54418TWR_nand_rmii_config, or - default to nand flash boot, rmii mode, 50Mhz input clock
+ make M54418TWR_nand_rmii_lowfreq_config, or - default to nand flash boot, rmii mode, 50Mhz input clock
+ make M54418TWR_serial_mii_config, or - default to spi serial flash boot, 25Mhz input clock
+ make M54418TWR_serial_rmii_config, or - default to spi serial flash boot, 50Mhz input clock
+ make
+
+4. SCREEN DUMP
+==============
+4.1 M54418TWR Development board
+ Boot from NAND flash (NOTE: May not show exactly the same)
+
+U-Boot 2012.10-00209-g12ae1d8-dirty (Oct 18 2012 - 15:54:54)
+
+CPU: Freescale MCF54418 (Mask:a3 Version:1)
+ CPU CLK 250 MHz BUS CLK 125 MHz FLB CLK 125 MHz
+ INP CLK 50 MHz VCO CLK 500 MHz
+Board: Freescale MCF54418 Tower System
+SPI: ready
+DRAM: 128 MiB
+NAND: 256 MiB
+In: serial
+Out: serial
+Err: serial
+Net: FEC0, FEC1
+-> pri
+baudrate=115200
+bootargs=root=/dev/mtdblock2 rw rootfstype=jffs2 mtdparts=NAND:1M(u-boot)ro,7M(k
+ernel)ro,-(jffs2) console=ttyS0,115200
+bootdelay=2
+eth1addr=00:e0:0c:bc:e5:61
+ethact=FEC0
+ethaddr=00:e0:0c:bc:e5:60
+fileaddr=40010000
+filesize=27354
+gatewayip=192.168.1.1
+hostname=M54418TWR
+inpclk=50000000
+ipaddr=192.168.1.2
+load=tftp ${loadaddr} ${u-boot};
+loadaddr=0x40010000
+mem=129024k
+netdev=eth0
+netmask=255.255.255.0
+prog=nand device 0;nand erase 0 40000;nb_update ${loadaddr} ${filesize};save
+serverip=192.168.1.1
+stderr=serial
+stdin=serial
+stdout=serial
+u-boot=u-boot.bin
+upd=run load; run prog
+
+Environment size: 653/131068 bytes
+-> bdinfo
+memstart = 0x40000000
+memsize = 0x08000000
+flashstart = 0x00000000
+flashsize = 0x00000000
+flashoffset = 0x00000000
+sramstart = 0x80000000
+sramsize = 0x00010000
+mbar = 0xFC000000
+cpufreq = 250 MHz
+busfreq = 125 MHz
+flbfreq = 125 MHz
+inpfreq = 50 MHz
+vcofreq = 500 MHz
+ethaddr = 00:e0:0c:bc:e5:60
+eth1addr = 00:e0:0c:bc:e5:61
+ip_addr = 192.168.1.2
+baudrate = 115200 bps
+-> help
+? - alias for 'help'
+base - print or set address offset
+bdinfo - print Board Info structure
+boot - boot default, i.e., run 'bootcmd'
+bootd - boot default, i.e., run 'bootcmd'
+bootelf - Boot from an ELF image in memory
+bootm - boot application image from memory
+bootp - boot image via network using BOOTP/TFTP protocol
+bootvx - Boot vxWorks from an ELF image
+cmp - memory compare
+coninfo - print console devices and information
+cp - memory copy
+crc32 - checksum calculation
+dcache - enable or disable data cache
+dhcp - boot image via network using DHCP/TFTP protocol
+echo - echo args to console
+editenv - edit environment variable
+env - environment handling commands
+exit - exit script
+false - do nothing, unsuccessfully
+go - start application at address 'addr'
+help - print command description/usage
+icache - enable or disable instruction cache
+iminfo - print header information for application image
+imxtract- extract a part of a multi-image
+itest - return true/false on integer compare
+loop - infinite loop on address range
+md - memory display
+mdio - MDIO utility commands
+mii - MII utility commands
+mm - memory modify (auto-incrementing address)
+mtest - simple RAM read/write test
+mw - memory write (fill)
+nand - NAND sub-system
+nb_update- Nand boot update program
+nboot - boot from NAND device
+nfs - boot image via network using NFS protocol
+nm - memory modify (constant address)
+ping - send ICMP ECHO_REQUEST to network host
+printenv- print environment variables
+reginfo - print register information
+reset - Perform RESET of the CPU
+run - run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv - set environment variables
+sf - SPI flash sub-system
+showvar - print local hushshell variables
+sleep - delay execution for some time
+source - run script from memory
+sspi - SPI utility command
+test - minimal test like /bin/sh
+tftpboot- boot image via network using TFTP protocol
+true - do nothing, successfully
+version - print monitor, compiler and linker version
diff --git a/roms/u-boot/doc/README.malta b/roms/u-boot/doc/README.malta
new file mode 100644
index 000000000..8614696a5
--- /dev/null
+++ b/roms/u-boot/doc/README.malta
@@ -0,0 +1,16 @@
+MIPS Malta board
+
+How to flash using a MIPS Navigator Probe:
+
+ - Ensure that your Malta has jumper JP1 fitted. Without this jumper you will
+ be unable to flash your Malta using a Navigator Probe.
+
+ - Connect Navigator Console to your probe and Malta as usual.
+
+ - Within Navigator Console run the following commands:
+
+ source /path/to/u-boot/board/imgtec/malta/flash-malta-boot.tcl
+ reset
+ flash-boot /path/to/u-boot/u-boot.bin
+
+ - You should now be able to reboot your Malta to a U-Boot shell.
diff --git a/roms/u-boot/doc/README.marvell b/roms/u-boot/doc/README.marvell
new file mode 100644
index 000000000..6fc5ac8a4
--- /dev/null
+++ b/roms/u-boot/doc/README.marvell
@@ -0,0 +1,98 @@
+Marvell U-Boot Build Instructions
+=================================
+
+This document describes how to compile the U-Boot and how to change U-Boot configuration
+
+Build Procedure
+----------------
+1. Install required packages:
+
+ # sudo apt-get install libssl-dev
+ # sudo apt-get install device-tree-compiler
+ # sudo apt-get install swig libpython-dev
+
+2. Set the cross compiler:
+
+ # sudo apt-get install gcc-aarch64-linux-gnu
+ # export CROSS_COMPILE=aarch64-linux-gnu-
+
+3. Clean-up old residuals:
+
+ # make mrproper
+
+4. Configure the U-Boot:
+
+ # make <defconfig_file>
+
+ - For the Armada-70x0/80x0 DB board use "mvebu_db_armada8k_defconfig"
+ - For the Armada-80x0 MacchiatoBin use "make mvebu_mcbin-88f8040_defconfig"
+ - For the Armada-3700 DB board use "make mvebu_db-88f3720_defconfig"
+ - For the Armada-3700 EspressoBin use "make mvebu_espressobin-88f3720_defconfig"
+
+5. Configure the device-tree and build the U-Boot image:
+
+ For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
+
+ # make DEVICE_TREE=<name>
+
+ NOTE:
+ Compilation with "mvebu_db_armada8k_defconfig" requires explicitly exporting DEVICE_TREE
+ for the requested board.
+ By default, u-boot is compiled with armada-8040-db device-tree.
+ Using A80x0 device-tree on A70x0 might break the device.
+ In order to prevent this, the required device-tree MUST be set during compilation.
+ All device-tree files are located in ./arch/arm/dts/ folder.
+
+ For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
+ just default device-tree from defconfig using:
+
+ # make
+
+ NOTE:
+ The u-boot.bin should not be used as a stand-alone image.
+ The ARM Trusted Firmware (ATF) build process uses this image to generate the
+ flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
+ https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
+
+Configuration update
+---------------------
+ To update the U-Boot configuration, please refer to doc/README.kconfig
+
+
+Permanent ethernet MAC address
+-------------------------------
+ Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
+ permanent ethernet MAC addresses as they are stored only in U-Boot env storage (SPI or eMMC).
+ Some boards like EspressoBin have MAC addresses printed on sticker. Some boards got assigned
+ only one address other may also more than one. To print current MAC addresses run:
+
+ # echo $ethaddr
+ # echo $eth1addr
+ # echo $eth2addr
+ # echo $eth3addr
+ # ...
+
+ MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
+ and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
+ forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
+ When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
+ suggested to generate new random one.
+
+ After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
+ and then set correct permanent ethernet MAC addresses.
+
+ # env default -a
+ # setenv ethaddr XX:XX:XX:XX:XX:XX
+ # setenv eth1addr XX:XX:XX:XX:XX:XX
+ # setenv eth2addr YY:YY:YY:YY:YY:YY
+ # setenv eth3addr ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
+ # ...
+ # saveenv
+
+ Where value for ethaddr is required permanent ethernet MAC address and values for ethNaddr
+ are optional per-port MAC addresses. When optional ethNaddr variables are not defined then
+ they are inherited from required ethaddr variable. eth1addr contains MAC address for the
+ wan port, other for particular lan ports.
+
+ Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
+ U-Boot will inject it into kernel's device-tree.
diff --git a/roms/u-boot/doc/README.mediatek b/roms/u-boot/doc/README.mediatek
new file mode 100644
index 000000000..246579d4b
--- /dev/null
+++ b/roms/u-boot/doc/README.mediatek
@@ -0,0 +1,221 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018 MediaTek Inc.
+# Ryder Lee <ryder.lee@kernel.org>
+
+
+This document describes how to compile the U-Boot and how to change U-Boot
+configuration about the MediaTek SoCs.
+
+
+Build Procedure
+===============
+ -Set the cross compiler:
+
+ # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
+
+ -Clean-up old residuals:
+
+ # make mrproper
+
+ -Configure the U-Boot:
+
+ # make <defconfig_file>
+ # make
+
+ - For the MT7623n bananapi R2 board use "mt7623n_bpir2_defconfig"
+ - For the MT7629 reference board use "mt7629_rfb_defconfig"
+
+
+Boot sequence
+=============
+ -Bootrom -> MTK preloader -> U-Boot
+
+ - MT7623n
+
+ This version of U-Boot doesn't implement SPL. So, MTK preloader binary
+ is needed to boot up:
+
+ https://github.com/BPI-SINOVOIP/BPI-R2-bsp/tree/master/mt-pack/mtk/bpi-r2/bin
+
+
+ -Bootrom -> SPL -> U-Boot
+
+ - MT7629
+
+
+Configuration update
+====================
+ To update the U-Boot configuration, please refer to doc/README.kconfig
+
+
+MediaTek image header
+=====================
+Currently there are two image headers used for MediaTek chips:
+
+ - BootROM image header. This header is used by the first stage bootloader. It records
+ the desired compatible boot device, integrity information and its load address.
+
+ The on-chip BootROM will firstly verify integrity and compatibility of the bootloader.
+
+ If verification passed, the BootROM will then load the bootloader into on-chip SRAM,
+ and pass control to it.
+
+ Note that this header is actually a combination of three independent headers:
+ Device header, BRLYT header and GFH header.
+
+ Used by U-Boot SPL of MT7629 and preloader of MT7623.
+
+
+ - MediaTek legacy image header. This header was originally used by the legacy image. It
+ basically records the load address, image size and image name.
+
+ After all low level initializations passed, the preloader will locate the LK image and
+ load it into DRAM, and pass control to it.
+
+ Now this header is used by U-Boot of MT7623.
+
+
+To generate these two headers with mkimage:
+
+ # mkimage -T mtk_image -a <load_addr> -n <option_string> -d <input_file> <image_file>
+
+ - mtk_image means using MediaTek's header generation method.
+
+
+ - load_addr is the load address of this image.
+ For first stage bootloader like U-Boot SPL or preloader, it usually points to the
+ on-chip SRAM.
+
+ For second stage bootloader like U-Boot, it usually points to the DRAM.
+
+
+ - option_string contains options to generate the header.
+
+ The option string is using the follow format:
+ key1=value1;key2=value2;...
+
+ The following key names are valid:
+ lk: If lk=1, LK image header is used. Otherwise BootROM image header is used.
+
+ lkname: The name of the LK image header. The maximum length is 32.
+ The default value is "U-Boot".
+
+ media: Desired boot device. The valid values are:
+ nand : Parallel NAND
+ snand: Serial NAND
+ nor : Serial NOR
+ emmc : eMMC
+ sdmmc: SD
+
+ nandinfo: Desired NAND device type, a combination of page size, oob size and
+ optional device capacity. Valid types are:
+ 2k+64 : for Serial NAND, 2KiB page size + 64B oob size
+ 2k+120 : for Serial NAND, 2KiB page size + 120B oob size
+ 2k+128 : for Serial NAND, 2KiB page size + 128B oob size
+ 4k+256 : for Serial NAND, 4KiB page size + 256B oob size
+ 1g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 1Gbit size
+ 2g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 2Gbit size
+ 4g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 4Gbit size
+ 2g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 2Gbit size
+ 4g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 4Gbit size
+
+
+MT7629 partitions on Serial NOR
+===============================
+
+ Start End Size Description
+ 00000000 - 0000ffff: 64KiB U-Boot SPL
+ 00010000 - 0005ffff: 320KiB U-Boot
+ 00060000 - 0006ffff: 64KiB U-Boot env / MediaTek NVRAM
+ 00070000 - 000affff: 256KiB RF calibration data
+ 000b0000 - xxxxxxxx: all left Firmware image
+
+
+BPi-R2 (MT7623N) partitions on SD
+=================================
+ Please note that the last two partitions can vary from different Linux distributions
+ depending on the MBR partition table.
+
+ Start End Size Description
+ 00000000 - 000001ff: 512B Device header (with MBR partition table)
+ 00000200 - 000007ff: 1536B BRLYT header
+ 00000800 - 0004ffff: 318KiB Preloader (with GFH header)
+ 00050000 - 000fffff: 704KiB U-Boot
+ 00100000 - 063fffff: 99MiB Reserved
+ 06400000 - 163fffff: 256MiB Partition 1 (FAT32)
+ 16400000 - xxxxxxxx: all left Partition 2 (ext4)
+
+
+Upgrading notice on Serial NOR
+==============================
+Example: MT7629
+
+ The command sf is used to operate the Serial NOR device:
+
+ - To probe current NOR flash:
+
+ # sf probe
+
+ - To erase a region:
+
+ # sf erase <offset> <len>
+
+ - To write data to an offset:
+
+ # sf write <data_addr> <offset> <len>
+
+ - To boot kernel:
+
+ # bootm 0x300b0000
+
+ The memory address range 0x30000000 - 0x3fffffff is mapped to the NOR flash.
+ The DRAM starts at 0x40000000.
+
+ Please note that the output binary u-boot-mtk.bin is a combination of SPL and U-Boot,
+ and it should be write to beginning of the flash.
+
+ Otherwise you should use standalone files:
+
+ spl/u-boot-spl-mtk.bin for SPL,
+ u-boot.img for U-Boot.
+
+
+Upgrading notice on SD / eMMC
+=============================
+Example: MT7623
+
+ Normally only Preloader and U-Boot can be upgraded within U-Boot, and other partitions
+ should be written in PC.
+
+ - To probe current SD card / eMMC:
+
+ # mmc dev 0 for eMMC
+ # mmc dev 1 for SD
+
+ - To erase a region:
+
+ # mmc erase <blk_offset> <blk_num>
+
+ - To write data to a block offset:
+
+ # mmc write <data_addr> <blk_offset> <blk_num>
+
+ - To load kernel image from partition 1:
+
+ # fatload mmc 0:1 <load_address> <path_to_kernel_uImage> for eMMC
+ # fatload mmc 1:1 <load_address> <path_to_kernel_uImage> for SD
+
+ - To boot kernel:
+
+ # bootm <load_address>
+
+ The DRAM starts at 0x80000000.
+
+ Please note that we use block offset and block count for SD card, not the byte offset.
+ The block size is always 512 bytes for SD card.
+
+
+Documentation
+=============
+ http://wiki.banana-pi.org/Banana_Pi_BPI-R2
diff --git a/roms/u-boot/doc/README.memory-test b/roms/u-boot/doc/README.memory-test
new file mode 100644
index 000000000..eb60e8d83
--- /dev/null
+++ b/roms/u-boot/doc/README.memory-test
@@ -0,0 +1,98 @@
+The most frequent cause of problems when porting U-Boot to new
+hardware, or when using a sloppy port on some board, is memory errors.
+In most cases these are not caused by failing hardware, but by
+incorrect initialization of the memory controller. So it appears to
+be a good idea to always test if the memory is working correctly,
+before looking for any other potential causes of any problems.
+
+U-Boot implements 3 different approaches to perform memory tests:
+
+1. The get_ram_size() function (see "common/memsize.c").
+
+ This function is supposed to be used in each and every U-Boot port
+ determine the presence and actual size of each of the potential
+ memory banks on this piece of hardware. The code is supposed to be
+ very fast, so running it for each reboot does not hurt. It is a
+ little known and generally underrated fact that this code will also
+ catch 99% of hardware related (i. e. reliably reproducible) memory
+ errors. It is strongly recommended to always use this function, in
+ each and every port of U-Boot.
+
+2. The "mtest" command.
+
+ This is probably the best known memory test utility in U-Boot.
+ Unfortunately, it is also the most problematic, and the most
+ useless one.
+
+ There are a number of serious problems with this command:
+
+ - It is terribly slow. Running "mtest" on the whole system RAM
+ takes a _long_ time before there is any significance in the fact
+ that no errors have been found so far.
+
+ - It is difficult to configure, and to use. And any errors here
+ will reliably crash or hang your system. "mtest" is dumb and has
+ no knowledge about memory ranges that may be in use for other
+ purposes, like exception code, U-Boot code and data, stack,
+ malloc arena, video buffer, log buffer, etc. If you let it, it
+ will happily "test" all such areas, which of course will cause
+ some problems.
+
+ - It is not easy to configure and use, and a large number of
+ systems are seriously misconfigured. The original idea was to
+ test basically the whole system RAM, with only exempting the
+ areas used by U-Boot itself - on most systems these are the areas
+ used for the exception vectors (usually at the very lower end of
+ system memory) and for U-Boot (code, data, etc. - see above;
+ these are usually at the very upper end of system memory). But
+ experience has shown that a very large number of ports use
+ pretty much bogus settings of CONFIG_SYS_MEMTEST_START and
+ CONFIG_SYS_MEMTEST_END; this results in useless tests (because
+ the ranges is too small and/or badly located) or in critical
+ failures (system crashes).
+
+ Because of these issues, the "mtest" command is considered depre-
+ cated. It should not be enabled in most normal ports of U-Boot,
+ especially not in production. If you really need a memory test,
+ then see 1. and 3. above resp. below.
+
+3. The most thorough memory test facility is available as part of the
+ POST (Power-On Self Test) sub-system, see "post/drivers/memory.c".
+
+ If you really need to perform memory tests (for example, because
+ it is mandatory part of your requirement specification), then
+ enable this test which is generic and should work on all archi-
+ tectures.
+
+WARNING:
+
+It should pointed out that _all_ these memory tests have one
+fundamental, unfixable design flaw: they are based on the assumption
+that memory errors can be found by writing to and reading from memory.
+Unfortunately, this is only true for the relatively harmless, usually
+static errors like shorts between data or address lines, unconnected
+pins, etc. All the really nasty errors which will first turn your
+hair gray, only to make you tear it out later, are dynamical errors,
+which usually happen not with simple read or write cycles on the bus,
+but when performing back-to-back data transfers in burst mode. Such
+accesses usually happen only for certain DMA operations, or for heavy
+cache use (instruction fetching, cache flushing). So far I am not
+aware of any freely available code that implements a generic, and
+efficient, memory test like that. The best known test case to stress
+a system like that is to boot Linux with root file system mounted over
+NFS, and then build some larger software package natively (say,
+compile a Linux kernel on the system) - this will cause enough context
+switches, network traffic (and thus DMA transfers from the network
+controller), varying RAM use, etc. to trigger any weak spots in this
+area.
+
+Note: An attempt was made once to implement such a test to catch
+memory problems on a specific board. The code is pretty much board
+specific (for example, it includes setting specific GPIO signals to
+provide triggers for an attached logic analyzer), but you can get an
+idea how it works: see "examples/standalone/test_burst*".
+
+Note 2: Ironically enough, the "test_burst" did not catch any RAM
+errors, not a single one ever. The problems this code was supposed
+to catch did not happen when accessing the RAM, but when reading from
+NOR flash.
diff --git a/roms/u-boot/doc/README.mpc74xx b/roms/u-boot/doc/README.mpc74xx
new file mode 100644
index 000000000..f81f1c2e8
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc74xx
@@ -0,0 +1,22 @@
+This file contains status information for the port of U-Boot to the
+Motorola mpc74xx series of CPUs.
+
+Author: Josh Huber <huber@mclx.com>
+ Mission Critical Linux, Inc.
+
+Currently the support for these CPUs is pretty minimal, but enough to
+get things going. (much like the support for the Galileo Eval Board)
+
+There is a framework in place to enable the L2 cache, and to program
+the BATs. Currently, there are still problems with the code which
+sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be
+anyway). Additionally, there is support for enabling the MMU, which
+we also don't do. The BATs are programmed just for the benefit of
+jumping into Linux in a sane configuration.
+
+Most of the code was based on other cpus supported by U-Boot.
+
+If you find any errors in the CPU setup code, please send us a note.
+
+Thanks,
+Josh
diff --git a/roms/u-boot/doc/README.mpc83xx.ddrecc b/roms/u-boot/doc/README.mpc83xx.ddrecc
new file mode 100644
index 000000000..0029f0875
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc83xx.ddrecc
@@ -0,0 +1,154 @@
+Overview
+========
+
+The overall usage pattern for ECC diagnostic commands is the following:
+
+ * (injecting errors is initially disabled)
+
+ * define inject mask (which tells the DDR controller what type of errors
+ we'll be injecting: single/multiple bit etc.)
+
+ * enable injecting errors - from now on the controller injects errors as
+ indicated in the inject mask
+
+IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially
+dangerous as such errors are NOT corrected by the controller. Therefore caution
+should be taken when enabling the injection of multiple-bit errors: it is only
+safe when used on a carefully selected memory area and used under control of
+the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit
+Errors' below). In particular, when you simply set the multiple-bit errors in
+inject mask and enable injection, U-Boot is very likely to hang quickly as the
+errors will be injected when it accesses its code, data etc.
+
+
+Use cases for DDR 'ecc' command:
+================================
+
+Before executing particular tests reset target board or clear status registers:
+
+=> ecc captureclear
+=> ecc errdetectclr all
+=> ecc sbecnt 0
+
+
+Injecting Single-Bit Errors
+---------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Run test over some memory region
+
+=> ecc testdw 200000 10
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000000
+...
+Memory Single-Bit Error Management (0..255):
+ Single-Bit Error Threshold: 255
+ Single Bit Error Counter: 16
+...
+Memory Error Detect:
+ Multiple Memory Errors: 0
+ Multiple-Bit Error: 0
+ Single-Bit Error: 0
+...
+
+16 errors were generated, Single-Bit Error flag was not set as Single Bit Error
+Counter did not reach Single-Bit Error Threshold.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef ................
+00200090: deadbeef deadbeef deadbeef deadbeef ................
+
+Injecting Multiple-Bit Errors
+-----------------------------
+
+1. Set more than 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+=> ecc injectdatalo 1
+
+2. Run test over some memory region
+
+=> ecc testword 200000 1
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000001
+...
+Memory Error Detect:
+ Multiple Memory Errors: 0
+ Multiple-Bit Error: 1
+ Single-Bit Error: 0
+...
+
+The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef ................
+00200090: deadbeef deadbeef deadbeef deadbeef ................
+
+
+Test Single-Bit Error Counter and Threshold
+-------------------------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Enable error injection
+
+=> ecc inject en
+
+3. Let u-boot run for a with Single-Bit error injection enabled
+
+4. Disable error injection
+
+=> ecc inject dis
+
+4. Check status
+
+=> ecc status
+
+...
+Memory Single-Bit Error Management (0..255):
+ Single-Bit Error Threshold: 255
+ Single Bit Error Counter: 199
+
+Memory Error Detect:
+ Multiple Memory Errors: 1
+ Multiple-Bit Error: 0
+ Single-Bit Error: 1
+...
+
+Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter
+reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that
+is Counter reached Threshold more than one time (it wraps back after reaching
+Threshold).
diff --git a/roms/u-boot/doc/README.mpc83xxads b/roms/u-boot/doc/README.mpc83xxads
new file mode 100644
index 000000000..372fdd9ce
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc83xxads
@@ -0,0 +1,97 @@
+Freescale MPC83xx ADS Boards
+-----------------------------------------
+
+0. Toolchain / Building
+
+ $ PATH=$PATH:/usr/powerpc/bin
+ $ CROSS_COMPILE=powerpc-linux-
+ $ export PATH CROSS_COMPILE
+
+ $ powerpc-linux-gcc -v
+ Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs
+ Configured with: ../configure --prefix=/usr/powerpc
+ --exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared
+ --disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc
+ Thread model: posix
+ gcc version 3.4.3 (Debian)
+
+ $ powerpc-linux-as -v
+ GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15
+
+
+ $ make MPC8349ADS_config
+ Configuring for MPC8349ADS board...
+
+ $ make
+
+
+1. Board Switches and Jumpers
+
+
+2. Memory Map
+
+2.1. The memory map should look pretty much like this:
+
+ 0x0000_0000 0x7fff_ffff DDR 2G
+ 0x8000_0000 0x9fff_ffff PCI MEM 512M
+ 0xc000_0000 0xdfff_ffff Rapid IO 512M
+ 0xe000_0000 0xe00f_ffff CCSR 1M
+ 0xe200_0000 0xe2ff_ffff PCI IO 16M
+ 0xf000_0000 0xf7ff_ffff SDRAM 128M
+ 0xf800_0000 0xf80f_ffff BCSR 1M
+ 0xfe00_0000 0xffff_ffff FLASH (boot bank) 16M
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+ include/configs/MPC8349ADS.h
+
+ CONFIG_MPC83xx MPC83xx family
+ CONFIG_MPC8349 MPC8349 specific
+ CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet
+
+
+4. Compilation
+
+ Assuming you're using BASH shell:
+
+ export CROSS_COMPILE=your-cross-compile-prefix
+ cd u-boot
+ make distclean
+ make MPC8349ADS_config
+ make
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+ loadb
+ [Drop to kermit:
+ ^\c
+ send <u-boot-bin-image>
+ c
+ ]
+
+
+ Or via tftp:
+
+ tftp 10000 u-boot.bin
+
+5.1 Reflash U-Boot Image using U-Boot
+
+ tftp 10000 u-boot.bin
+ protect off fe000000 fe09ffff
+ erase fe000000 fe09ffff
+
+ cp.b 10000 fe000000 xxxx
+or
+ cp.b 10000 fe000000 a0000
+
+You might have to supply the correct byte count for 'xxxx' from
+the TFTP. Maybe a0000 will work too, that corresponds to the
+erased sectors.
+
+
+6. Notes
diff --git a/roms/u-boot/doc/README.mpc85xx b/roms/u-boot/doc/README.mpc85xx
new file mode 100644
index 000000000..8464e7f4d
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc85xx
@@ -0,0 +1,166 @@
+External Debug Support
+----------------------
+
+Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some
+restrictions on external debugging (JTAG). In particular, for the debugger to
+be able to receive control after a single step or breakpoint:
+ - MSR[DE] must be set
+ - A valid opcode must be fetchable, through the MMU, from the debug
+ exception vector (IVPR + IVOR15).
+
+To maximize the time during which this requirement is met, U-Boot sets MSR[DE]
+immediately on entry and keeps it set. It also uses a temporary TLB to keep a
+mapping to a valid opcode at the debug exception vector, even if we normally
+don't support exception vectors being used that early, and that's not the area
+where U-Boot currently executes from.
+
+Note that there may still be some small windows where debugging will not work,
+such as in between updating IVPR and IVOR15.
+
+Config Switches:
+----------------
+
+Please refer README section "MPC85xx External Debug Support"
+
+Major Config Switches during various boot Modes
+----------------------------------------------
+
+NOR boot
+ !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SPL)
+NOR boot Secure
+ !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NXP_ESBC)
+RAMBOOT(SD, SPI & NAND boot)
+ defined(CONFIG_SYS_RAMBOOT)
+RAMBOOT Secure (SD, SPI & NAND)
+ defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NXP_ESBC)
+NAND SPL BOOT
+ defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NAND_SPL)
+
+
+TLB Entries during u-boot execution
+-----------------------------------
+
+Note: Sequence number is in order of execution
+
+A) defined(CONFIG_SYS_RAMBOOT) i.e. SD, SPI, NAND RAMBOOT & NAND_SPL boot
+
+ 1) TLB entry to overcome e500 v1/v2 debug restriction
+ Location : Label "_start_e500"
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
+ Properties : 256K, AS0, I, IPROT
+
+ 2) TLB entry for working in AS1
+ Location : Label "create_init_ram_area"
+ TLB Entry : 15
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
+ Properties : 1M, AS1, I, G, IPROT
+
+ 3) TLB entry for the stack during AS1
+ Location : Lable "create_init_ram_area"
+ TLB Entry : 14
+ EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR
+ Properties : 16K, AS1, IPROT
+
+ 4) TLB entry for CCSRBAR during AS1 execution
+ Location : cpu_init_early_f
+ TLB Entry : 13
+ EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR
+ Properties : 1M, AS1, I, G
+
+ 5) Invalidate unproctected TLB Entries
+ Location : cpu_init_early_f
+ Invalidated: 13
+
+ 6) Create TLB entries as per boards/freescale/<board>/tlb.c
+ Location : cpu_init_early_f --> init_tlbs()
+ Properties : ..., AS0, ...
+ Please note It can overwrites previous TLB Entries.
+
+ 7) Disable TLB Entries of AS1
+ Location : cpu_init_f --> disable_tlb()
+ Disable : 15, 14
+
+ 8) Update Flash's TLB entry
+ Location : Board_init_r
+ TLB entry : Search from TLB entries
+ EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS
+ Properties : Board specific size, AS0, I, G, IPROT
+
+
+B) !defined(CONFIG_SYS_RAMBOOT) i.e. NOR boot
+
+ 1) TLB entry to overcome e500 v1/v2 debug restriction
+ Location : Label "_start_e500"
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+#if defined(CONFIG_NXP_ESBC)
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW
+ Properties : 1M, AS1, I, G, IPROT
+#else
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
+ Properties : 4M, AS0, I, G, IPROT
+#endif
+
+ 2) TLB entry for working in AS1
+ Location : Label "create_init_ram_area"
+ TLB Entry : 15
+#if defined(CONFIG_NXP_ESBC)
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_PBI_FLASH_WINDOW
+ Properties : 1M, AS1, I, G, IPROT
+#else
+ EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
+ Properties : 4M, AS1, I, G, IPROT
+#endif
+
+ 3) TLB entry for the stack during AS1
+ Location : Lable "create_init_ram_area"
+ TLB Entry : 14
+ EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR
+ Properties : 16K, AS1, IPROT
+
+ 4) TLB entry for CCSRBAR during AS1 execution
+ Location : cpu_init_early_f
+ TLB Entry : 13
+ EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR
+ Properties : 1M, AS1, I, G
+
+ 5) TLB entry for Errata workaround CONFIG_SYS_FSL_ERRATUM_IFC_A003399
+ Location : cpu_init_early_f
+ TLB Entry : 9
+ EPN -->RPN : SRAM_BASE_ADDR --> SRAM_BASE_ADDR
+ Properties : 1M, AS1, I
+
+ 6) CONFIG_SYS_FSL_ERRATUM_IFC_A003399 Adjust flash's phys addr
+ Location : cpu_init_early_f --> setup_ifc
+ TLB Entry : Get Flash TLB
+ EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
+ Properties : 4M, AS1, I, G, IPROT
+
+ 7) CONFIG_SYS_FSL_ERRATUM_IFC_A003399: E500 v1,v2 debug restriction
+ Location : cpu_init_early_f --> setup_ifc
+ TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
+ EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
+ Properties : 4M, AS0, I, G, IPROT
+
+ 8) Invalidate unproctected TLB Entries
+ Location : cpu_init_early_f
+ Invalidated: 13, 9
+
+ 9) Create TLB entries as per boards/freescale/<board>/tlb.c
+ Location : cpu_init_early_f --> init_tlbs()
+ Properties : ..., AS0, ...
+ Note: It can overwrites previous TLB Entries
+
+ 10) Disable TLB Entries of AS1
+ Location : cpu_init_f --> disable_tlb()
+ Disable : 15, 14
+
+ 11) Create DDR's TLB entriy
+ Location : Board_init_f -> dram_init
+ TLB entry : Search free TLB entry
+
+ 12) Update Flash's TLB entry
+ Location : Board_init_r
+ TLB entry : Search from TLB entries
+ EPN -->RPN : CONFIG_SYS_FLASH_BASE --> CONFIG_SYS_FLASH_BASE_PHYS
+ Properties : Board specific size, AS0, I, G, IPROT
diff --git a/roms/u-boot/doc/README.mpc85xx-sd-spi-boot b/roms/u-boot/doc/README.mpc85xx-sd-spi-boot
new file mode 100644
index 000000000..e3f580446
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc85xx-sd-spi-boot
@@ -0,0 +1,75 @@
+----------------------------------------
+Booting from On-Chip ROM (eSDHC or eSPI)
+----------------------------------------
+
+boot_format is a tool to write SD bootable images to a filesystem and build
+SD/SPI images to a binary file for writing later.
+
+When booting from an SD card/MMC, boot_format puts the configuration file and
+the RAM-based U-Boot image on the card.
+When booting from an EEPROM, boot_format generates a binary image that is used
+to boot from this EEPROM.
+
+Where to get boot_format:
+========================
+
+you can browse it online at:
+http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/
+
+Building
+========
+
+Run the following to build this project
+
+ $ make
+
+Execution
+=========
+
+boot_format runs under a regular Linux machine and requires a super user mode
+to run. Execute boot_format as follows.
+
+For building SD images by writing directly to a file system on SD media:
+
+ $ boot_format $config u-boot.bin -sd $device
+
+Where $config is the included config.dat file for your platform and $device
+is the target block device for the SD media on your computer.
+
+For build binary images directly a local file:
+
+ $ boot_format $config u-boot.bin -spi $file
+
+Where $file is the target file. Also keep in mind the u-boot.bin file needs
+to be the u-boot built for your particular platform and target media.
+
+Example: To generate a u-boot.bin for a P1022DS booting from SD, run the
+following in the u-boot repository:
+
+ $ make P1022DS_SDCARD
+
+Configuration Files
+===================
+
+Below are the configuration files to be used with a particular platform. Keep
+in mind that some of these config files are tied to the platforms DDR speed.
+Please see the SoC reference manual for more documentation.
+
+P1022DS config_sram_p1022ds.dat
+P2020DS config_sram_p2020ds.dat
+P1020RDB config_ddr2_1g_p1020rdb_533M.dat
+P1020RDB config_ddr2_1g_p1020rdb_667M.dat
+P2020RDB config_ddr2_1g_p2020rdb_800M.dat
+P2020RDB config_ddr2_1g_p2020rdb_667M.dat
+P2020RDB config_ddr3_1gb_64bit_p2020rdb_pc.dat
+P1020RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1011RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1010RDB config_ddr3_1gb_p1010rdb_800M.dat
+P1021RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1022DS config_ddr3_2gb_p1022ds.dat
+P1024RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1025RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1016RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat
+P1020UTM config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+P1020MBG config_ddr3_1gb_p1_p2_rdb_pc_800M.dat
+MPC8536DS config_ddr2_512m_mpc8536ds_667M.dat
diff --git a/roms/u-boot/doc/README.mpc85xx-spin-table b/roms/u-boot/doc/README.mpc85xx-spin-table
new file mode 100644
index 000000000..72c7bd7b5
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc85xx-spin-table
@@ -0,0 +1,26 @@
+Spin table in cache
+=====================================
+As specified by ePAPR v1.1, the spin table needs to be in cached memory. After
+DDR is initialized and U-Boot relocates itself into DDR, the spin table is
+accessible for core 0. It is part of release.S, within 4KB range after
+__secondary_start_page. For other cores to use the spin table, the booting
+process is described below:
+
+Core 0 sets up the reset page on the top 4K of memory (or 4GB if total memory
+is more than 4GB), and creates a TLB to map it to 0xffff_f000, regardless of
+the physical address of this page, with WIMGE=0b01010. Core 0 also enables boot
+page translation for secondary cores to use this page of memory. Then 4KB
+memory is copied from __secondary_start_page to the boot page, after flusing
+cache because this page is mapped as normal DDR. Before copying the reset page,
+core 0 puts the physical address of the spin table (which is in release.S and
+relocated to the top of mapped memory) into a variable __spin_table_addr so
+that secondary cores can see it.
+
+When secondary cores boot up from 0xffff_f000 page, they only have one default
+TLB. While booting, they set up another TLB in AS=1 space and jump into
+the new space. The new TLB covers the physical address of the spin table page,
+with WIMGE =0b00100. Now secondary cores can keep polling the spin table
+without stress DDR bus because both the code and the spin table is in cache.
+
+For the above to work, DDR has to set the 'M' bit of WIMGE, in order to keep
+cache coherence.
diff --git a/roms/u-boot/doc/README.mpc85xxcds b/roms/u-boot/doc/README.mpc85xxcds
new file mode 100644
index 000000000..79d71cb37
--- /dev/null
+++ b/roms/u-boot/doc/README.mpc85xxcds
@@ -0,0 +1,225 @@
+Motorola MPC85xxCDS boards
+--------------------------
+
+The CDS family of boards consists of a PCI backplane called the
+"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot,
+and a CPU daughter card that bolts onto the daughter card.
+
+Much of the content of the README.mpc85xxads for the 85xx ADS boards
+applies to the 85xx CDS boards as well. In particular the toolchain,
+the switch nomenclature, and the basis for the memory map. There are
+some differences, though.
+
+
+Building U-Boot
+---------------
+
+The Binutils in current ELDK toolchain will not support MPC85xx
+chip. You need to use binutils-2.14.tar.bz2 (or newer) from
+ http://ftp.gnu.org/gnu/binutils.
+
+The 85xx CDS code base is known to compile using:
+ gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
+
+
+Memory Map
+----------
+
+The memory map for U-Boot and linux has been extended w.r.t. the ADS
+platform to allow for utilization of all 85xx CDS devices. The memory
+map is setup for linux to operate properly. The linux source when
+configured for MPC85xx CDS has been updated to reflect the new memory
+map.
+
+The mapping is:
+
+ 0x0000_0000 0x7fff_ffff DDR 2G
+ 0x8000_0000 0x9fff_ffff PCI1 MEM 512M
+ 0xa000_0000 0xbfff_ffff PCI2 MEM 512M
+ 0xe000_0000 0xe00f_ffff CCSR 1M
+ 0xe200_0000 0xe2ff_ffff PCI1 IO 16M
+ 0xe300_0000 0xe3ff_ffff PCI2 IO 16M
+ 0xf000_0000 0xf7ff_ffff SDRAM 128M
+ 0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M
+ 0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M
+ 0xff80_0000 0xffff_ffff FLASH (boot bank) 8M
+
+ (*) The system control registers (CADMUS) start at offset 0xfdb0_4000
+ within the NVRAM/CADMUS region of memory.
+
+
+Using Flash
+-----------
+
+The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000).
+There is a switch which allows the boot-bank to be selected. The switch
+settings for updating flash are given below.
+
+The U-Boot commands for copying the boot-bank into the secondary bank are
+as follows:
+
+ erase ff780000 ff7fffff
+ cp.b fff80000 ff780000 80000
+
+
+U-Boot/kermit commands for downloading an image, then copying
+it into the secondary bank:
+
+ loadb
+ [Drop to kermit:
+ ^\c
+ send <u-boot-bin-image>
+ c
+ ]
+
+ erase ff780000 ff7fffff
+ cp.b $loadaddr ff780000 80000
+
+
+U-Boot commands for downloading an image via tftp and flashing
+it into the second bank:
+
+ tftp 10000 <u-boot.bin.image>
+ erase ff780000 ff7fffff
+ cp.b 10000 ff780000 80000
+
+
+After copying the image into the second bank of flash, be sure to toggle
+SW2[2] on the carrier card before resetting the board in order to set the
+secondary bank as the boot-bank.
+
+
+Carrier Board Switches
+----------------------
+
+As a reminder, you should read the README.mpc85xxads too.
+
+Most switches on the carrier board should not be changed. The only
+user-settable switches on the carrier board are used to configure
+the flash banks and determining the PCI slot.
+
+The first two bits of SW2 control how flash is used on the board:
+
+ 12345678
+ --------
+ SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available.
+ 01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped).
+ 10XXXXXX FLASH: Boot promjet, bank 1 available
+ 11XXXXXX FLASH: Boot promjet, bank 2 available
+
+The boot bank is always mapped to FF80_0000 and listed first by
+the "flinfo" command. The secondary bank is always FF00_0000.
+
+When using PCI, linux needs to know to which slot the CDS carrier is
+connected.. By convention, the user-specific bits of SW2 are used to
+convey this information:
+
+ 12345678
+ --------
+ SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia
+ xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia
+ xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia
+ xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia
+
+These are cleverly, er, clearly silkscreened as Slot 1 through 4,
+respectively, on the Arcadia near the support posts.
+
+
+The default setting of all switches on the carrier board is:
+
+ 12345678
+ --------
+ SW1=01101100
+ SW2=0x1111yy x=Flash bank, yy=PCI slot
+ SW3=11101111
+ SW4=10001000
+
+
+8555/41 CPU Card Switches
+-------------------------
+
+Most switches on the CPU Card should not be changed. However, the
+frequency can be changed by setting SW3:
+
+ 12345678
+ --------
+ SW3=XX00XXXX == CORE:CCB 2:1
+ XX01XXXX == CORE:CCB 5:2
+ XX10XXXX == CORE:CCB 3:1
+ XX11XXXX == CORE:CCB 7:2
+ XXXX1000 == CCB:SYSCLK 8:1
+ XXXX1010 == CCB:SYSCLK 10:1
+
+A safe default setting for all switches on the CPU board is:
+
+ 12345678
+ --------
+ SW1=10001111
+ SW2=01000111
+ SW3=00001000
+ SW4=11111110
+
+
+8548 CPU Card Switches
+----------------------
+And, just to be confusing, in this set of switches:
+
+ ON = 1
+ OFF = 0
+
+Default
+ SW1=11111101
+ SW2=10011111
+ SW3=11001000 (8X) (2:1)
+ SW4=11110011
+
+ SW3=X000XXXX == CORE:CCB 4:1
+ X001XXXX == CORE:CCB 9:2
+ X010XXXX == CORE:CCB 1:1
+ X011XXXX == CORE:CCB 3:2
+ X100XXXX == CORE:CCB 2:1
+ X101XXXX == CORE:CCB 5:2
+ X110XXXX == CORE:CCB 3:1
+ X111XXXX == CORE:CCB 7:2
+ XXXX0000 == CCB:SYSCLK 16:1
+ XXXX0001 == RESERVED
+ XXXX0010 == CCB:SYSCLK 2:1
+ XXXX0011 == CCB:SYSCLK 3:1
+ XXXX0100 == CCB:SYSCLK 4:1
+ XXXX0101 == CCB:SYSCLK 5:1
+ XXXX0110 == CCB:SYSCLK 6:1
+ XXXX0111 == RESERVED
+ XXXX1000 == CCB:SYSCLK 8:1
+ XXXX1001 == CCB:SYSCLK 9:1
+ XXXX1010 == CCB:SYSCLK 10:1
+ XXXX1011 == RESERVED
+ XXXX1100 == CCB:SYSCLK 12:1
+ XXXX1101 == CCB:SYSCLK 20:1
+ XXXX1110 == RESERVED
+ XXXX1111 == RESERVED
+
+
+eDINK Info
+----------
+
+One bank of flash may contain an eDINK image.
+
+Memory Map:
+
+ CCSRBAR @ 0xe0000000
+ Flash Bank 1 @ 0xfe000000
+ Flash Bank 2 @ 0xff000000
+ Ram @ 0
+
+Commands for downloading a U-Boot image to memory from edink:
+
+ env -c
+ time -s 4/8/2004 4:30p
+ dl -k -b -o 100000
+ [Drop to kermit:
+ ^\c
+ transmit /binary <u-boot-bin-image>
+ c
+ ]
+
+ fu -l 100000 fe780000 80000
diff --git a/roms/u-boot/doc/README.multi-dtb-fit b/roms/u-boot/doc/README.multi-dtb-fit
new file mode 100644
index 000000000..f48450efc
--- /dev/null
+++ b/roms/u-boot/doc/README.multi-dtb-fit
@@ -0,0 +1,65 @@
+MULTI DTB FIT and SPL_MULTI_DTB_FIT
+
+The purpose of this feature is to enable U-Boot or the SPL to select its DTB
+from a FIT appended at the end of the binary.
+It comes in two flavors: U-Boot (CONFIG_MULTI_DTB_FIT) and SPL
+(CONFIG_SPL_MULTI_DTB_FIT).
+
+U-Boot flavor:
+Usually the DTB is selected by the SPL and passed down to U-Boot. But some
+platforms don't use the SPL. In this case MULTI_DTB_FIT can used to provide
+U-Boot with a choice of DTBs.
+The relevant DTBs are packed into a FIT (list provided by CONFIG_OF_LIST). The
+FIT is automatically generated at the end of the compilation and appended to
+u-boot.bin so that U-Boot can locate it and select the correct DTB from inside
+the FIT.
+The selection is done using board_fit_config_name_match() (same as what the SPL
+uses to select the DTB for U-Boot). The selection happens during fdtdec_setup()
+which is called during before relocation by board_init_f().
+
+SPL flavor:
+the SPL uses only a small subset of the DTB and it usually depends more
+on the SOC than on the board. So it's usually fine to include a DTB in the
+SPL that doesn't exactly match the board. There are howerver some cases
+where it's not possible. In the later case, in order to support multiple
+boards (or board revisions) with the same SPL binary, SPL_MULTI_DTB_FIT
+can be used.
+The relevant DTBs are packed into a FIT. This FIT is automatically generated
+at the end of the compilation, compressed and appended to u-boot-spl.bin, so
+that SPL can locate it and select the correct DTB from inside the FIT.
+CONFIG_SPL_OF_LIST is used to list the relevant DTBs.
+The compression stage is optional but reduces the impact on the size of the
+SPL. LZO and GZIP compressions are supported. By default, the area where the
+FIT is uncompressed is dynamicaly allocated but this behaviour can be changed
+for platforms that don't provide a HEAP big enough to contain the uncompressed
+FIT.
+The SPL uses board_fit_config_name_match() to find the correct DTB within the
+FIT (same as what the SPL uses to select the DTB for U-Boot).
+Uncompression and selection stages happen in fdtdec_setup() which is called
+during the early initialization stage of the SPL (spl_early_init() or
+spl_init())
+
+Impacts and performances (SPL flavor):
+The impact of this option is relatively small. Here are some numbers measured
+for a TI DRA72 platform:
+
+ +----------+------------+-----------+------------+
+ | size | size delta | SPL boot | boot time |
+ | (bytes) | (bytes) | time (s) | delta (s) |
++---------------------------+----------+------------+-----------+------------+
+| 1 DTB | | | | |
++---------------------------+----------+------------+-----------+------------+
+| reference | 125305 | 0 | 1.389 | 0 |
+| LZO (dynamic allocation) | 125391 | 86 | 1.381 | -0.008 |
++---------------------------+----------+------------+-----------+------------+
+| 4 DTBs (DRA7, DRA71, | | | | |
+| DRA72, DRA72 revC) | | | | |
++---------------------------+----------+------------+-----------+------------+
+| LZO (dynamic allocation) | 125991 | 686 | 1.39 | 0.001 |
+| LZO (user defined area) | 125927 | 622 | 1.403 | 0.014 |
+| GZIP (user defined area) | 133880 | 8575 | 1.421 | 0.032 |
+| No compression (in place) | 137472 | 12167 | 1.412 | 0.023 |
++---------------------------+----------+------------+-----------+------------+
+
+Note: SPL boot time is the time elapsed between the 'reset' command is entered
+and the time when the first U-Boot (not SPL) version string is displayed.
diff --git a/roms/u-boot/doc/README.mxc_ocotp b/roms/u-boot/doc/README.mxc_ocotp
new file mode 100644
index 000000000..7a2863cfd
--- /dev/null
+++ b/roms/u-boot/doc/README.mxc_ocotp
@@ -0,0 +1,51 @@
+Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP)
+on MXC
+
+This IP can be found on the following SoCs:
+ - Vybrid VF610,
+ - i.MX6.
+
+Note that this IP is different from albeit similar to the IPs of the same name
+that can be found on the following SoCs:
+ - i.MX23,
+ - i.MX28,
+ - i.MX50.
+
+The section numbers in this file refer to the i.MX6 Reference Manual.
+
+A fuse word contains 32 fuse bit slots, as explained in 46.2.1.
+
+A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the
+memory map in 46.4.
+
+Some fuse bit or word slots may not have the corresponding fuses actually
+implemented in the fusebox.
+
+See the README files of the SoCs using this driver in order to know the
+conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
+addresses.
+
+Fuse operations:
+
+ Read
+ Read operations are implemented as read accesses to the shadow registers,
+ using "Bankx Wordy" from the memory map in 46.4. This is explained in
+ detail by the first two paragraphs in 46.2.1.2.
+
+ Sense
+ Sense operations are implemented as the direct fusebox read explained by
+ the steps in 46.2.1.2.
+
+ Program
+ Program operations are implemented as explained by the steps in 46.2.1.3.
+ Following this operation, the shadow registers are not reloaded by the
+ hardware.
+
+ Override
+ Override operations are implemented as write accesses to the shadow
+ registers, as explained by the first paragraph in 46.2.1.3.
+
+Configuration:
+
+ CONFIG_MXC_OCOTP
+ Define this to enable the mxc_ocotp driver.
diff --git a/roms/u-boot/doc/README.nand b/roms/u-boot/doc/README.nand
new file mode 100644
index 000000000..ec461b2dc
--- /dev/null
+++ b/roms/u-boot/doc/README.nand
@@ -0,0 +1,345 @@
+# SPDX-License-Identifier: GPL-2.0+
+NAND FLASH commands and notes
+
+See NOTE below!!!
+
+# (C) Copyright 2003
+# Dave Ellis, SIXNET, dge@sixnetio.com
+#
+
+Commands:
+
+ nand bad
+ Print a list of all of the bad blocks in the current device.
+
+ nand device
+ Print information about the current NAND device.
+
+ nand device num
+ Make device `num' the current device and print information about it.
+
+ nand erase off|partition size
+ nand erase clean [off|partition size]
+ Erase `size' bytes starting at offset `off'. Alternatively partition
+ name can be specified, in this case size will be eventually limited
+ to not exceed partition size (this behaviour applies also to read
+ and write commands). Only complete erase blocks can be erased.
+
+ If `erase' is specified without an offset or size, the entire flash
+ is erased. If `erase' is specified with partition but without an
+ size, the entire partition is erased.
+
+ If `clean' is specified, a JFFS2-style clean marker is written to
+ each block after it is erased.
+
+ This command will not erase blocks that are marked bad. There is
+ a debug option in cmd_nand.c to allow bad blocks to be erased.
+ Please read the warning there before using it, as blocks marked
+ bad by the manufacturer must _NEVER_ be erased.
+
+ nand info
+ Print information about all of the NAND devices found.
+
+ nand read addr ofs|partition size
+ Read `size' bytes from `ofs' in NAND flash to `addr'. Blocks that
+ are marked bad are skipped. If a page cannot be read because an
+ uncorrectable data error is found, the command stops with an error.
+
+ nand read.oob addr ofs|partition size
+ Read `size' bytes from the out-of-band data area corresponding to
+ `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of
+ data for one 512-byte page or 2 256-byte pages. There is no check
+ for bad blocks or ECC errors.
+
+ nand write addr ofs|partition size
+ Write `size' bytes from `addr' to `ofs' in NAND flash. Blocks that
+ are marked bad are skipped. If a page cannot be read because an
+ uncorrectable data error is found, the command stops with an error.
+
+ As JFFS2 skips blocks similarly, this allows writing a JFFS2 image,
+ as long as the image is short enough to fit even after skipping the
+ bad blocks. Compact images, such as those produced by mkfs.jffs2
+ should work well, but loading an image copied from another flash is
+ going to be trouble if there are any bad blocks.
+
+ nand write.trimffs addr ofs|partition size
+ Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to
+ the NAND flash in a manner identical to the 'nand write' command
+ described above -- with the additional check that all pages at the end
+ of eraseblocks which contain only 0xff data will not be written to the
+ NAND flash. This behaviour is required when flashing UBI images
+ containing UBIFS volumes as per the UBI FAQ[1].
+
+ [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
+
+ nand write.oob addr ofs|partition size
+ Write `size' bytes from `addr' to the out-of-band data area
+ corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
+ of data for one 512-byte page or 2 256-byte pages. There is no check
+ for bad blocks.
+
+ nand read.raw addr ofs|partition [count]
+ nand write.raw addr ofs|partition [count]
+ Read or write one or more pages at "ofs" in NAND flash, from or to
+ "addr" in memory. This is a raw access, so ECC is avoided and the
+ OOB area is transferred as well. If count is absent, it is assumed
+ to be one page. As with .yaffs2 accesses, the data is formatted as
+ a packed sequence of "data, oob, data, oob, ..." -- no alignment of
+ individual pages is maintained.
+
+Configuration Options:
+
+ CONFIG_SYS_NAND_U_BOOT_OFFS
+ NAND Offset from where SPL will read u-boot image. This is the starting
+ address of u-boot MTD partition in NAND.
+
+ CONFIG_CMD_NAND
+ Enables NAND support and commands.
+
+ CONFIG_CMD_NAND_TORTURE
+ Enables the torture command (see description of this command below).
+
+ CONFIG_SYS_MAX_NAND_DEVICE
+ The maximum number of NAND devices you want to support.
+
+ CONFIG_SYS_NAND_MAX_ECCPOS
+ If specified, overrides the maximum number of ECC bytes
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 48 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_OOBFREE
+ If specified, overrides the maximum number of free OOB regions
+ supported. Useful for reducing image size, especially with SPL.
+ This must be at least 2 if nand_base.c is used.
+
+ CONFIG_SYS_NAND_MAX_CHIPS
+ The maximum number of NAND chips per device to be supported.
+
+ CONFIG_SYS_NAND_SELF_INIT
+ Traditionally, glue code in drivers/mtd/nand/raw/nand.c has driven
+ the initialization process -- it provides the mtd and nand
+ structs, calls a board init function for a specific device,
+ calls nand_scan(), and registers with mtd.
+
+ This arrangement does not provide drivers with the flexibility to
+ run code between nand_scan_ident() and nand_scan_tail(), or other
+ deviations from the "normal" flow.
+
+ If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/raw/nand.c
+ will make one call to board_nand_init(), with no arguments. That
+ function is responsible for calling a driver init function for
+ each NAND device on the board, that performs all initialization
+ tasks except setting mtd->name, and registering with the rest of
+ U-Boot. Those last tasks are accomplished by calling nand_register()
+ on the new mtd device.
+
+ Example of new init to be added to the end of an existing driver
+ init:
+
+ /* chip is struct nand_chip, and is now provided by the driver. */
+ mtd = nand_to_mtd(&chip);
+
+ /*
+ * Fill in appropriate values if this driver uses these fields,
+ * or uses the standard read_byte/write_buf/etc. functions from
+ * nand_base.c that use these fields.
+ */
+ chip.IO_ADDR_R = ...;
+ chip.IO_ADDR_W = ...;
+
+ if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_CHIPS, NULL))
+ error out
+
+ /*
+ * Insert here any code you wish to run after the chip has been
+ * identified, but before any other I/O is done.
+ */
+
+ if (nand_scan_tail(mtd))
+ error out
+
+ /*
+ * devnum is the device number to be used in nand commands
+ * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE.
+ */
+ if (nand_register(devnum, mtd))
+ error out
+
+ In addition to providing more flexibility to the driver, it reduces
+ the difference between a U-Boot driver and its Linux counterpart.
+ nand_init() is now reduced to calling board_nand_init() once, and
+ printing a size summary. This should also make it easier to
+ transition to delayed NAND initialization.
+
+ Please convert your driver even if you don't need the extra
+ flexibility, so that one day we can eliminate the old mechanism.
+
+
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
+
+Platform specific options
+=========================
+ CONFIG_NAND_OMAP_GPMC
+ Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms.
+ GPMC controller is used for parallel NAND flash devices, and can
+ do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8
+ and BCH16 ECC algorithms.
+
+ CONFIG_NAND_OMAP_ELM
+ Enables omap_elm.c driver for OMAPx and AMxxxx platforms.
+ ELM controller is used for ECC error detection (not ECC calculation)
+ of BCH4, BCH8 and BCH16 ECC algorithms.
+ Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
+ thus such SoC platforms need to depend on software library for ECC error
+ detection. However ECC calculation on such plaforms would still be
+ done by GPMC controller.
+
+ CONFIG_SPL_NAND_AM33XX_BCH
+ Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based
+ hardware ECC correction. This is useful for platforms which have ELM
+ hardware engine and use NAND boot mode.
+ Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
+ so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling
+ SPL-NAND driver with software ECC correction support.
+
+ CONFIG_NAND_OMAP_ECCSCHEME
+ On OMAP platforms, this CONFIG specifies NAND ECC scheme.
+ It can take following values:
+ OMAP_ECC_HAM1_CODE_SW
+ 1-bit Hamming code using software lib.
+ (for legacy devices only)
+ OMAP_ECC_HAM1_CODE_HW
+ 1-bit Hamming code using GPMC hardware.
+ (for legacy devices only)
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH4_CODE_HW
+ 4-bit BCH code (unsupported)
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using software library.
+ - requires CONFIG_BCH to enable software BCH library
+ (For legacy device which do not have ELM h/w engine)
+ OMAP_ECC_BCH8_CODE_HW
+ 8-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using ELM hardware engine.
+ OMAP_ECC_BCH16_CODE_HW
+ 16-bit BCH code with
+ - ecc calculation using GPMC hardware engine,
+ - error detection using ELM hardware engine.
+
+ How to select ECC scheme on OMAP and AMxx platforms ?
+ -----------------------------------------------------
+ Though higher ECC schemes have more capability to detect and correct
+ bit-flips, but still selection of ECC scheme is dependent on following
+ - hardware engines present in SoC.
+ Some legacy OMAP SoC do not have ELM h/w engine thus such
+ SoC cannot support BCHx_HW ECC schemes.
+ - size of OOB/Spare region
+ With higher ECC schemes, more OOB/Spare area is required to
+ store ECC. So choice of ECC scheme is limited by NAND oobsize.
+
+ In general following expression can help:
+ NAND_OOBSIZE >= 2 + (NAND_PAGESIZE / 512) * ECC_BYTES
+ where
+ NAND_OOBSIZE = number of bytes available in
+ OOB/spare area per NAND page.
+ NAND_PAGESIZE = bytes in main-area of NAND page.
+ ECC_BYTES = number of ECC bytes generated to
+ protect 512 bytes of data, which is:
+ 3 for HAM1_xx ecc schemes
+ 7 for BCH4_xx ecc schemes
+ 14 for BCH8_xx ecc schemes
+ 26 for BCH16_xx ecc schemes
+
+ example to check for BCH16 on 2K page NAND
+ NAND_PAGESIZE = 2048
+ NAND_OOBSIZE = 64
+ 2 + (2048 / 512) * 26 = 106 > NAND_OOBSIZE
+ Thus BCH16 cannot be supported on 2K page NAND.
+
+ However, for 4K pagesize NAND
+ NAND_PAGESIZE = 4096
+ NAND_OOBSIZE = 224
+ ECC_BYTES = 26
+ 2 + (4096 / 512) * 26 = 210 < NAND_OOBSIZE
+ Thus BCH16 can be supported on 4K page NAND.
+
+
+ CONFIG_NAND_OMAP_GPMC_PREFETCH
+ On OMAP platforms that use the GPMC controller
+ (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that
+ uses the prefetch mode to speed up read operations.
+
+NOTE:
+=====
+
+The Disk On Chip driver is currently broken and has been for some time.
+There is a driver in drivers/mtd/nand/raw, taken from Linux, that works with
+the current NAND system but has not yet been adapted to the u-boot
+environment.
+
+Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
+
+JFFS2 related commands:
+
+ implement "nand erase clean" and old "nand erase"
+ using both the new code which is able to skip bad blocks
+ "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob.
+
+Miscellaneous and testing commands:
+ "markbad [offset]"
+ create an artificial bad block (for testing bad block handling)
+
+ "scrub [offset length]"
+ like "erase" but don't skip bad block. Instead erase them.
+ DANGEROUS!!! Factory set bad blocks will be lost. Use only
+ to remove artificial bad blocks created with the "markbad" command.
+
+ "torture offset [size]"
+ Torture block to determine if it is still reliable.
+ Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
+ This command returns 0 if the block is still reliable, else 1.
+ If the block is detected as unreliable, it is up to the user to decide to
+ mark this block as bad.
+ The analyzed block is put through 3 erase / write cycles (or less if the block
+ is detected as unreliable earlier).
+ This command can be used in scripts, e.g. together with the markbad command to
+ automate retries and handling of possibly newly detected bad blocks if the
+ nand write command fails.
+ It can also be used manually by users having seen some NAND errors in logs to
+ search the root cause of these errors.
+ The underlying nand_torture() function is also useful for code willing to
+ automate actions following a nand->write() error. This would e.g. be required
+ in order to program or update safely firmware to NAND, especially for the UBI
+ part of such firmware.
+ Optionally, a second parameter size can be given to test multiple blocks with
+ one call. If size is not a multiple of the NAND's erase size, then the block
+ that contains offset + size will be tested in full. If used with size, this
+ command returns 0 if all tested blocks have been found reliable, else 1.
+
+
+NAND locking command (for chips with active LOCKPRE pin)
+
+ "nand lock"
+ set NAND chip to lock state (all pages locked)
+
+ "nand lock tight"
+ set NAND chip to lock tight state (software can't change locking anymore)
+
+ "nand lock status"
+ displays current locking status of all pages
+
+ "nand unlock [offset] [size]"
+ unlock consecutive area (can be called multiple times for different areas)
+
+ "nand unlock.allexcept [offset] [size]"
+ unlock all except specified consecutive area
+
+I have tested the code with board containing 128MiB NAND large page chips
+and 32MiB small page chips.
diff --git a/roms/u-boot/doc/README.nand-boot-ppc440 b/roms/u-boot/doc/README.nand-boot-ppc440
new file mode 100644
index 000000000..1e9c10264
--- /dev/null
+++ b/roms/u-boot/doc/README.nand-boot-ppc440
@@ -0,0 +1,60 @@
+-----------------------------
+NAND boot on PPC440 platforms
+-----------------------------
+
+This document describes the U-Boot NAND boot feature as it
+is implemented for the AMCC Sequoia (PPC440EPx) board.
+
+The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH,
+completely without NOR FLASH. This can be done by using the NAND
+boot feature of the 440 NAND flash controller (NDFC).
+
+Here a short description of the different boot stages:
+
+a) IPL (Initial Program Loader, integrated inside CPU)
+------------------------------------------------------
+Will load first 4k from NAND (SPL) into cache and execute it from there.
+
+b) SPL (Secondary Program Loader)
+---------------------------------
+Will load special U-Boot version (NUB) from NAND and execute it. This SPL
+has to fit into 4kByte. It sets up the CPU and configures the SDRAM
+controller and the NAND controller so that the special U-Boot image can be
+loaded from NAND to SDRAM.
+This special image is build in the directory "nand_spl".
+
+c) NUB (NAND U-Boot)
+--------------------
+This NAND U-Boot (NUB) is a special U-Boot version which can be started
+from RAM. Therefore it mustn't (re-)configure the SDRAM controller.
+
+On 440EPx the SPL is copied to internal SRAM before the NAND controller
+is set up. While still running from cache, I experienced problems accessing
+the NAND controller.
+
+
+Example: Build and install NAND boot image for Sequoia (440EPx):
+
+a) Configure for sequoia with NAND boot support:
+# make sequoia_nand_config
+
+b) Build image(s)
+# make
+
+This will generate the SPL image in the "nand_spl" directory:
+nand_spl/u-boot-spl.bin
+Also another image is created spanning a whole NAND block (16kBytes):
+nand_spl/u-boot-spl-16k.bin
+The main NAND U-Boot image is generated in the toplevel directory:
+u-boot.bin
+A combined image of u-boot-spl-16k.bin and u-boot.bin is also created:
+u-boot-nand.bin
+
+This image should be programmed at offset 0 in the NAND flash:
+
+# tftp 100000 /tftpboot/sequoia/u-boot-nand.bin
+# nand erase 0 60000
+# nand write 100000 0 60000
+
+
+September 07 2006, Stefan Roese <sr@denx.de>
diff --git a/roms/u-boot/doc/README.nokia_rx51 b/roms/u-boot/doc/README.nokia_rx51
new file mode 100644
index 000000000..84d1912dd
--- /dev/null
+++ b/roms/u-boot/doc/README.nokia_rx51
@@ -0,0 +1,94 @@
+Board: Nokia RX-51 aka N900
+
+This board definition results in a u-boot.bin which can be chainloaded
+from NOLO in qemu or on a real N900. It does very little hardware config
+because NOLO has already configured the board. Only needed is enabling
+internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
+
+NOLO is expecting a kernel image and will treat any image it finds in
+onenand as such. This u-boot is intended to be flashed to the N900 like
+a kernel. In order to transparently boot the original kernel, it will be
+appended to u-boot.bin at 0x40000. NOLO will load the entire image into
+(random) memory and execute u-boot, which saves hw revision, boot reason
+and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
+uImage or boot.scr from a fat, ext2/ext3 or ext4 filesystem in external
+SD card or internal eMMC memory. If this fails or keyboard is closed then
+the appended kernel image will be booted using some generated and some
+stored ATAGs (see boot order).
+
+For generating combined image of u-boot and kernel there is a simple script
+called u-boot-gen-combined. It is available in following repository:
+
+ https://github.com/pali/u-boot-maemo
+
+There is support for hardware watchdog. Hardware watchdog is started by
+NOLO so u-boot must kick watchdog to prevent reboot device (but not very
+often, max every 2 seconds). There is also support for framebuffer display
+output with ANSI escape codes and the N900 HW keyboard input.
+
+When U-Boot is starting it enable IBE bit in Auxiliary Control Register,
+which is needed for Thumb-2 ISA support. It is workaround for errata 430973.
+
+Default boot order:
+
+ * 0. if keyboard is closed boot automatically attached kernel image
+ * 1. try boot from external SD card
+ * 2. try boot from internal eMMC memory
+ * 3. try boot from attached kernel image
+
+Boot from SD or eMMC in this order:
+
+ * 1.
+ * 1.1 find boot.scr on first fat partition
+ * 1.2 find uImage on first fat partition
+ * 1.3 same order for 2. - 4. fat partition
+ * 2. same as 1. but for ext2/3 partition
+ * 3. same as 1. but for ext4 partition
+
+
+Available additional commands/variables:
+
+ * run sdboot - Boot from external SD card (see boot order)
+ * run emmcboot - Boot from internal eMMC memory (see boot order)
+ * run attachboot - Boot attached kernel image (attached to U-Boot binary)
+
+ * run scriptload - Load boot script ${mmcscriptfile}
+ * run scriptboot - Run loaded boot script
+ * run kernload - Load kernel image ${mmckernfile}
+ * run initrdload - Load initrd image ${mmcinitrdfile}
+ * run kernboot - Boot loaded kernel image
+ * run kerninitrdboot - Boot loaded kernel image with loaded initrd image
+
+ * run trymmcscriptboot - Try to load and boot script ${mmcscriptfile}
+ * run trymmckernboot - Try to load and boot kernel image ${mmckernfile}
+ * run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile}
+ with initrd image ${mmcinitrdfile}
+
+Additional variables for loading files from mmc:
+
+ * mmc ${mmcnum} (0 - external, 1 - internal)
+ * partition number ${mmcpart} (1 - 4)
+ * parition type ${mmctype} (fat, ext2, ext4)
+
+Additional variables for booting kernel:
+
+ * setup_omap_atag - Add OMAP table into atags structure (needs maemo kernel)
+ * setup_console_atag - Enable serial console in OMAP table
+ * setup_boot_reason_atag - Change boot reason in OMAP table
+ * setup_boot_mode_atag - Change boot mode in OMAP table
+
+ Variable setup_omap_atag is automatically set when booting attached kernel.
+ When variable setup_omap_atag is set, variable setup_console_atag is unset
+ and u-boot standard output is set to serial then setup_console_atag is
+ automatically set to 1. So output from Maemo kernel would go to serial port.
+
+UBIFS support:
+
+ UBIFS support is disabled, because U-Boot image is too big and cannot be
+ flashed with attached zImage to RX-51 kernel nand area. For enabling UBIFS
+ support add following lines into file configs/nokia_rx51_defconfig
+
+ CONFIG_CMD_UBI=y
+ CONFIG_CMD_UBIFS=y
+ CONFIG_MTD_UBI_FASTMAP=y
+ CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
diff --git a/roms/u-boot/doc/README.odroid b/roms/u-boot/doc/README.odroid
new file mode 100644
index 000000000..bc77ae317
--- /dev/null
+++ b/roms/u-boot/doc/README.odroid
@@ -0,0 +1,332 @@
+ U-Boot for Odroid X2/U3/XU3/XU4/HC1
+========================
+
+1. Summary
+==========
+This is a quick instruction for setup Odroid boards.
+Board config: odroid_config for X2/U3
+Board config: odroid-xu3_config for XU3/XU4/HC1
+
+2. Supported devices
+====================
+This U-BOOT config can be used on three boards:
+- Odroid U3
+- Odroid X2
+with CPU Exynos 4412 rev 2.0 and 2GB of RAM
+- Odroid XU3
+- Odroid XU4
+- Odroid HC1
+with CPU Exynos5422 and 2GB of RAM
+
+3. Boot sequence
+================
+iROM->BL1->(BL2 + TrustZone)->U-BOOT
+
+This version of U-BOOT doesn't implement SPL. So, BL1, BL2, and TrustZone
+binaries are needed to boot up.
+
+<< X2/U3 >>
+It can be found in "boot.tar.gz" from here:
+http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz
+or here:
+http://odroid.in/guides/ubuntu-lfs/boot.tar.gz
+
+<< XU3/XU4 >>
+It can be downloaded from:
+https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot
+
+
+4. Boot media layout
+====================
+The table below shows SD/eMMC cards layout for U-Boot.
+The block offset is starting from 0 and the block size is 512B.
+ -------------------------------------
+| Binary | Block offset| part type |
+| name | SD | eMMC |(eMMC only)|
+ -------------------------------------
+| Bl1 | 1 | 0 | 1 (boot) |
+| Bl2 | 31 | 30 | 1 (boot) |
+| U-Boot | 63 | 62 | 1 (boot) |
+| Tzsw | 2111 | 2110 | 1 (boot) |
+| Uboot Env | 2560 | 2560 | 0 (user) |
+ -------------------------------------
+
+5. Prepare the SD boot card - with SD card reader
+=================================================
+To prepare bootable media you need boot binaries provided by hardkernel.
+From the downloaded files, You can find:
+- bl1.bin
+- tzsw.bin
+- bl2.bin
+- sd_fusing.sh
+- u-boot.bin
+(The file names can be slightly different, but you can distinguish what they are
+without problem)
+
+This is all you need to boot this board. But if you want to use your custom
+U-Boot then you need to change u-boot.bin with your own U-Boot binary*
+and run the script "sd_fusing.sh" - this script is valid only for SD card.
+
+*note:
+The proper binary file of current U-Boot is u-boot-dtb.bin.
+
+quick steps for Linux:
+- Download all files from the link at point 3 and extract it if needed.
+- put any SD card into the SD reader
+- check the device with "dmesg"
+- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
+Check if Hardkernel U-Boot is booting, and next do the same with your U-Boot.
+
+6. Prepare the eMMC boot card
+ with a eMMC card reader (boot from eMMC card slot)
+=====================================================
+To boot the device from the eMMC slot you should use a special card reader
+which supports eMMC partition switch. All of the boot binaries are stored
+on the eMMC boot partition which is normally hidden.
+
+The "sd_fusing.sh" script can be used after updating offsets of binaries
+according to the table from point 4. Be sure that you are working on the right
+eMMC partition - its size is usually very small, about 1-4 MiB.
+
+7. Prepare the eMMC boot card
+ with a SD card reader (boot from SD card slot)
+=================================================
+If you have an eMMC->microSD adapter you can prepare the card as in point 5.
+But then the device can boot only from the SD card slot.
+
+8. Prepare the boot media using Hardkernel U-Boot
+=================================================
+You can update the U-Boot to the custom one if you have a working bootloader
+delivered with the board on the eMMC/SD card. Then follow the steps:
+- install the android fastboot tool
+- connect a micro usb cable to the board
+- on the U-Boot prompt, run command: fastboot (as a root)
+- on the host, run command: "fastboot flash bootloader u-boot-dtb.bin"
+- the custom U-Boot should start after the board resets.
+
+9. Partition layout
+====================
+Default U-Boot environment is setup for fixed partition layout.
+
+Partition table: MSDOS. Disk layout and files as listed in the table below.
+ ----- ------ ------ ------ -------- ---------------------------------
+| Num | Name | FS | Size | Offset | Reguired files |
+| | | Type | MiB | MiB | |
+ ----- ------ ------ ------ -------- ---------------------------------
+| 1 | BOOT | fat | 100 | 2 | kernel, fdt** |
+| 2 | ROOT | ext4 | - | | any Linux system |
+ ----- ------ ------ ------ -------- ---------------------------------
+
+**note:
+Supported fdt files are:
+- exynos4412-odroidx2.dtb
+- exynos4412-odroidu3.dtb
+- exynos5422-odroidxu3.dtb
+- exynos5422-odroidxu3-lite.dtb
+- exynos5422-odroidxu4.dtb
+- exynos5422-odroidhc1.dtb
+
+Supported kernel files are:
+- Image.itb
+- zImage
+- uImage
+
+The default environmental variable "dfu_alt_info" is set* for above layout.
+Each partition size is just an example, dfu_alt_info tries init two partitions.
+The size of each is not important.
+
+*note:
+$dfu_alt_info is set on a boot time and it is concatenated using two variables:
+- $dfu_alt_boot(set dynamically)
+- $dfu_alt_system(from current env).
+
+To add any changes to dfu_alt_info - please modify $dfu_alt_system only.
+Changes are visible after board reset.
+
+10. The environment and booting the kernel
+==========================================
+There are three macros defined in config for various boot options:
+Two for both, kernel with device tree support and also without it:
+- boot_uimg - load uImage
+- boot_zimg - load zImage
+If proper fdt file exists then it will be automatically loaded,
+so for old kernel types, please remove fdt file from boot partition.
+
+The third boot option for multi image support (more info: doc/uImage.FIT/)
+- boot_fit - for binary file: "Image.itb"
+
+Default boot command: "autoboot"
+And the boot sequence is:
+- boot_fit - if "Image.itb" exists
+- boot_zimg - if "zImage" exists
+- boot_uimg - if "uImage" exists
+
+11. USB host support
+====================
+NOTE: This section is only for Odroid X2/U3.
+
+The ethernet can be accessed after starting the USB subsystem in U-Boot.
+The adapter does not come with a preconfigured MAC address, and hence it needs
+to be set before starting USB.
+setenv usbethaddr 02:DE:AD:BE:EF:FF
+
+Note that in this example a locally managed MAC address is chosen. Care should
+be taken to make these MAC addresses unique within the same subnet.
+
+Start the USB subsystem:
+Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF
+Odroid # usb start
+(Re)start USB...
+USB0: USB EHCI 1.00
+scanning bus 0 for devices... 4 USB Device(s) found
+ scanning usb for storage devices... 1 Storage Device(s) found
+ scanning usb for ethernet devices... 1 Ethernet Device(s) found
+Odroid #
+
+Automatic IP assignment:
+------------------------
+If the ethernet is connected to a DHCP server (router maybe with DHCP enabled),
+then the below will automatically assign an ip address through DHCP.
+setenv autoload no
+dhcp
+
+Odroid # setenv autoload no
+Odroid # dhcp
+Waiting for Ethernet connection... done.
+BOOTP broadcast 1
+DHCP client bound to address 192.168.1.10 (524 ms)
+Odroid #
+
+Note that this automatically sets the many IP address related variables in
+U-Boot that is obtained from the DHCP server.
+
+Odroid # printenv ipaddr netmask gatewayip dnsip
+ipaddr=192.168.1.10
+netmask=255.255.255.0
+gatewayip=192.168.1.1
+dnsip=192.168.1.1
+
+Ping example:
+The ping command can be used a test to check connectivity. In this example,
+192.168.1.27 is a pingable server in the network.
+Odroid # ping 192.168.1.27
+Waiting for Ethernet connection... done.
+Using sms0 device
+host 192.168.1.27 is alive
+Odroid #
+
+Static IP assignment:
+---------------------
+In the case where there are no DHCP servers in the network, or you want to
+set the IP address statically, it can be done by:
+Odroid # setenv ipaddr 192.168.1.10
+Odroid # ping 192.168.1.27
+Waiting for Ethernet connection... done.
+Using sms0 device
+host 192.168.1.27 is alive
+
+TFTP booting:
+-------------
+Say there exists a tftp server in the network with address 192.168.1.27 and
+it serves a kernel image (zImage.3.17) and a DTB blob (exynos4412-odroidu3.dtb)
+that needs to be loaded and booted. It can be accomplished as below:
+(Assumes that you have setenv usbethaddr, and have not set autoload to no)
+
+Odroid # setenv serverip 192.168.1.27
+Odroid # tftpboot 0x40080000 zImage.3.17
+Waiting for Ethernet connection... done.
+Using sms0 device
+TFTP from server 192.168.1.27; our IP address is 192.168.1.10
+Filename 'zImage.3.17'.
+Load address: 0x40080000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ #######################
+ 52.7 KiB/s
+done
+Bytes transferred = 3194200 (30bd58 hex)
+Odroid # tftpboot 0x42000000 exynos4412-odroidu3.dtb
+Waiting for Ethernet connection... done.
+Using sms0 device
+TFTP from server 192.168.1.27; our IP address is 192.168.1.10
+Filename 'exynos4412-odroidu3.dtb'.
+Load address: 0x42000000
+Loading: ####
+ 40 KiB/s
+done
+Bytes transferred = 46935 (b757 hex)
+Odroid # printenv bootargs
+bootargs=Please use defined boot
+Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootwait
+Odroid # bootz 40080000 - 42000000
+Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
+## Flattened Device Tree blob at 42000000
+ Booting using the fdt blob at 0x42000000
+ Loading Device Tree to 4fff1000, end 4ffff756 ... OK
+
+Starting kernel ...
+
+[ 0.000000] Booting Linux on physical CPU 0xa00
+... etc ...
+
+In the above example you can substitute 'dhcp' for 'tftpboot' as well.
+
+USB Storage booting:
+--------------------
+Similarly we can use the USB storage to load the kernel image/initrd/fdt etc
+and boot. For this example, there is a USB drive plugged in. It has a FAT
+1st partition and an EXT 2nd partition. Using the generic FS (ls/load) makes
+it even easier to work with FAT/EXT file systems.
+For this example the second EXT partition is used for booting and as rootfs.
+The boot files - kernel and the dtb are present in the /boot directory of the
+second partition.
+
+Odroid # usb start
+(Re)start USB...
+USB0: USB EHCI 1.00
+scanning bus 0 for devices... 4 USB Device(s) found
+ scanning usb for storage devices... 1 Storage Device(s) found
+ scanning usb for ethernet devices...
+Error: sms0 address not set. <----- Note the error as usbethaddr
+Warning: failed to set MAC address <----- is not set.
+1 Ethernet Device(s) found
+Odroid # usb part 0
+
+Partition Map for USB device 0 -- Partition Type: DOS
+
+Part Start Sector Num Sectors UUID Type
+ 1 3072 263168 000c4046-01 06
+ 2 266240 13457408 000c4046-02 83
+
+Odroid # ls usb 0:2 /boot
+<DIR> 4096 .
+<DIR> 4096 ..
+ 353 boot.scr
+ 281 boot.txt
+ 101420 config-3.8.13.23
+ 2127254 initrd.img-3.8.13.23
+ 2194825 uInitrd
+ 2194825 uInitrd-3.8.13.23
+ 2453112 zImage
+ 101448 config-3.8.13.26
+ 2127670 uInitrd-3.8.13.26
+ 2127606 initrd.img-3.8.13.26
+ 3194200 zImage.3.17 <--- Kernel
+ 46935 exynos4412-odroidu3.dtb <--- DTB
+Odroid # load usb 0:2 40080000 /boot/zImage.3.17
+3194200 bytes read in 471 ms (6.5 MiB/s)
+Odroid # load usb 0:2 42000000 /boot/exynos4412-odroidu3.dtb
+46935 bytes read in 233 ms (196.3 KiB/s)
+Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/sda2 rootwait
+Odroid # bootz 40080000 - 42000000
+Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
+## Flattened Device Tree blob at 42000000
+ Booting using the fdt blob at 0x42000000
+ Loading Device Tree to 4fff1000, end 4ffff756 ... OK
+
+Starting kernel ...
+
+[ 0.000000] Booting Linux on physical CPU 0xa00
+
+Please refer to README.usb for additional information.
diff --git a/roms/u-boot/doc/README.omap-ulpi-viewport b/roms/u-boot/doc/README.omap-ulpi-viewport
new file mode 100644
index 000000000..a5240b9e2
--- /dev/null
+++ b/roms/u-boot/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.
diff --git a/roms/u-boot/doc/README.omap3 b/roms/u-boot/doc/README.omap3
new file mode 100644
index 000000000..208714ad6
--- /dev/null
+++ b/roms/u-boot/doc/README.omap3
@@ -0,0 +1,199 @@
+
+Summary
+=======
+
+This README is about U-Boot support for TI's ARM Cortex-A8 based OMAP3 [1]
+family of SoCs. TI's OMAP3 SoC family contains an ARM Cortex-A8. Additionally,
+some family members contain a TMS320C64x+ DSP and/or an Imagination SGX 2D/3D
+graphics processor and various other standard peripherals.
+
+Currently the following boards are supported:
+
+* OMAP3530 BeagleBoard [2]
+
+* Gumstix Overo [3]
+
+* TI EVM [4]
+
+* OpenPandora Ltd. Pandora [5]
+
+* TI/Logic PD Zoom MDK [6]
+
+* TI/Logic PD Zoom 2 [7]
+
+* CompuLab Ltd. CM-T35 [8]
+
+Build
+=====
+
+* BeagleBoard:
+
+make omap3_beagle_config
+make
+
+* Gumstix Overo:
+
+make omap3_overo_config
+make
+
+* TI EVM:
+
+make omap3_evm_config
+make
+
+* Zoom 2:
+
+make omap3_zoom2_config
+make
+
+* CM-T35:
+
+make cm_t35_config
+make
+
+
+Custom commands
+===============
+
+To make U-Boot for OMAP3 support NAND device SW or HW ECC calculation, U-Boot
+for OMAP3 supports custom user command
+
+nandecc hw/sw
+
+To be compatible with NAND drivers using SW ECC (e.g. kernel code)
+
+nandecc sw
+
+enables SW ECC calculation. HW ECC enabled with
+
+nandecc hw
+
+is typically used to write 2nd stage bootloader (known as 'x-loader') which is
+executed by OMAP3's boot rom and therefore has to be written with HW ECC.
+
+For all other commands see
+
+help
+
+Interfaces
+==========
+
+gpio
+----
+
+To set a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_output(N, 0);
+ gpio_set_value(N, 1);
+ }
+
+To clear a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_output(N, 0);
+ gpio_set_value(N, 0);
+ }
+
+To read a bit :
+
+ if (!gpio_request(N, "")) {
+ gpio_direction_input(N);
+ val = gpio_get_value(N);
+ gpio_free(N);
+ }
+ if (val)
+ printf("GPIO N is set\n");
+ else
+ printf("GPIO N is clear\n");
+
+dma
+---
+void omap3_dma_init(void)
+ Init the DMA module
+int omap3_dma_get_conf_chan(uint32_t chan, struct dma4_chan *config);
+ Read config of the channel
+int omap3_dma_conf_chan(uint32_t chan, struct dma4_chan *config);
+ Write config to the channel
+int omap3_dma_conf_transfer(uint32_t chan, uint32_t *src, uint32_t *dst,
+ uint32_t sze)
+ Config source, destination and size of a transfer
+int omap3_dma_wait_for_transfer(uint32_t chan)
+ Wait for a transfer to end - this hast to be called before a channel
+ or the data the channel transferd are used.
+int omap3_dma_get_revision(uint32_t *minor, uint32_t *major)
+ Read silicon Revision of the DMA module
+
+NAND
+====
+
+There are some OMAP3 devices out there with NAND attached. Due to the fact that
+OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page
+(place where SPL lives) we require this setup for u-boot at least when reading
+the second progam within SPL. A lot of newer NAND chips however require more
+than 1-bit ECC for the pages, some can live with 1-bit for the first page. To
+handle this we can switch to another ECC algorithm after reading the payload
+within SPL.
+
+BCH8
+----
+
+To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on
+OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH
+and set CONFIG_NAND_OMAP_ECCSCHEME=5 (refer README.nand) for selecting BCH8_SW.
+The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8
+implementation for OMAP3 works for you so the u-boot version should also.
+When you require the SPL to read with BCH8 there are two more configs to
+change:
+
+ * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in
+ GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in
+ arch/arm/include/asm/arch-omap3/omap_gpmc.h)
+ * CONFIG_SYS_NAND_ECCSIZE must be 512
+ * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup
+
+Acknowledgements
+================
+
+OMAP3 U-Boot is based on U-Boot tar ball [9] for BeagleBoard and EVM done by
+several TI employees.
+
+Links
+=====
+
+[1] OMAP3:
+
+http://www.ti.com/omap3 (high volume) and
+http://www.ti.com/omap35x (broad market)
+
+[2] OMAP3530 BeagleBoard:
+
+http://beagleboard.org/
+
+[3] Gumstix Overo:
+
+http://www.gumstix.net/Overo/
+
+[4] TI EVM:
+
+http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html
+
+[5] OpenPandora Ltd. Pandora:
+
+http://openpandora.org/
+
+[6] TI/Logic PD Zoom MDK:
+
+http://www.logicpd.com/products/devkit/ti/zoom_mobile_development_kit
+
+[7] TI/Logic PD Zoom 2
+
+http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
+
+[8] CompuLab Ltd. CM-T35:
+
+http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm
+
+[9] TI OMAP3 U-Boot:
+
+http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
diff --git a/roms/u-boot/doc/README.pblimage b/roms/u-boot/doc/README.pblimage
new file mode 100644
index 000000000..7fdd26b71
--- /dev/null
+++ b/roms/u-boot/doc/README.pblimage
@@ -0,0 +1,111 @@
+------------------------------------------------------------------
+Freescale PBL(pre-boot loader) Boot Image generation using mkimage
+------------------------------------------------------------------
+
+The CoreNet SoC's can boot directly from eSPI FLASH, SD/MMC and
+NAND, etc. These SoCs use PBL to load RCW and/or pre-initialization
+instructions. For more details refer section 5 Pre-boot loader
+specifications of reference manual P3041RM/P4080RM/P5020RM at link:
+http://www.freescale.com/webapp/search/Serp.jsp?Reference+Manuals
+
+Building PBL Boot Image and boot steps
+--------------------------------------
+
+1. Building PBL Boot Image.
+ The default Image is u-boot.pbl.
+
+ For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
+ To build the eSPI boot image:
+ make <board_name>_SPIFLASH
+
+ For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
+ To build the SD boot image:
+ make <board_name>_SDCARD
+
+ For Nand boot(available on P2041/P3041/P5020/P5040):
+ To build the NAND boot image:
+ make <board_name>_NAND
+
+
+2. pblimage support available with mkimage utility will generate Freescale PBL
+boot image that can be flashed on the board eSPI flash, SD/MMC and NAND.
+Following steps describe it in detail.
+
+ 1). Boot from eSPI flash
+ Write u-boot.pbl to eSPI flash from offset 0x0.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>sf probe 0
+ =>sf erase 0 100000
+ =>sf write 100000 0 $filesize
+ Change SW1[1:5] = off off on off on.
+
+ 2). Boot from SD/MMC
+ Write u-boot.pbl to SD/MMC from offset 0x1000.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>mmcinfo
+ =>mmc write 100000 8 441
+ Change SW1[1:5] = off off on on off.
+
+ 3). Boot from Nand
+ Write u-boot.pbl to Nand from offset 0x0.
+ for ex in u-boot:
+ =>tftp 100000 u-boot.pbl
+ =>nand info
+ =>nand erase 0 100000
+ =>nand write 100000 0 $filesize
+ Change SW1[1:5] = off on off off on
+ Change SW7[1:4] = on off off on
+
+Board specific configuration file specifications:
+------------------------------------------------
+1. Configuration files rcw.cfg and pbi.cfg must present in the
+board/freescale/corenet_ds/, rcw.cfg is for RCW, pbi.cfg is for
+PBI instructions. File name must not be changed since they are used
+in Makefile.
+2. These files can have empty lines and lines starting with "#" as first
+character to put comments
+
+Typical example of rcw.cfg file:
+-----------------------------------
+
+#PBL preamble and RCW header
+aa55aa55 010e0100
+#64 bytes RCW data
+4c580000 00000000 18185218 0000cccc
+40464000 3c3c2000 58000000 61000000
+00000000 00000000 00000000 008b6000
+00000000 00000000 00000000 00000000
+
+Typical example of pbi.cfg file:
+-----------------------------------
+
+#PBI commands
+#Initialize CPC1
+09010000 00200400
+09138000 00000000
+091380c0 00000100
+09010100 00000000
+09010104 fff0000b
+09010f00 08000000
+09010000 80000000
+#Configure LAW for CPC1
+09000d00 00000000
+09000d04 fff00000
+09000d08 81000013
+09000010 00000000
+09000014 ff000000
+09000018 81000000
+#Initialize eSPI controller
+09110000 80000403
+09110020 2d170008
+09110024 00100008
+09110028 00100008
+0911002c 00100008
+#Flush PBL data
+09138000 00000000
+091380c0 00000000
+
+------------------------------------------------
+Author: Shaohui Xie<Shaohui.Xie@freescale.com>
diff --git a/roms/u-boot/doc/README.pcap b/roms/u-boot/doc/README.pcap
new file mode 100644
index 000000000..97b3e55fd
--- /dev/null
+++ b/roms/u-boot/doc/README.pcap
@@ -0,0 +1,62 @@
+PCAP:
+
+U-boot supports live Ethernet packet capture in PCAP(2.4) format.
+This is enabled by CONFIG_CMD_PCAP.
+
+The capture is stored on physical memory, and should be copied to
+a machine capable of parsing and displaying PCAP files (IE. wireshark)
+If networking works properly one can copy the capture file from physical memory
+using tftpput, or save it to local storage with (sf write, mmc write, fatwrite, etc)
+
+the pcap capturing requires maximum buffer size.
+when the buffer is full an error message will be displayed and then packets
+will silently drop.
+the actual capture file size is populate in the environment variable "pcapsize".
+
+Usage example:
+
+# Initialize pcap capture to physical address (0x100000) with maximum size of
+# 100000 bytes.
+
+# Start capture
+pcap start
+
+# Initialize network activity
+env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64
+
+# Stop capture
+pcap stop
+
+# pcap init 0x100000 100000
+PCAP capture initialized: addr: 0xffffffff80100000 max length: 100000
+
+# pcap start
+# env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64
+eth0@10000000: PHY present at 0
+eth0@10000000: link up, 1000Mbps full-duplex (lpa: 0x7c00)
+Using eth0@10000000 device
+TFTP from server 10.0.2.2; our IP address is 10.0.2.15
+Filename 'uImage64'.
+Load address: 0xffffffff88000000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+!!! Buffer is full, consider increasing buffer size !!!
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #
+ 18.2 MiB/s
+done
+Bytes transferred = 8359376 (7f8dd0 hex)
+PCAP status:
+ Initialized addr: 0xffffffff80100000 max length: 100000
+ Status: Active. file size: 99991
+ Incoming packets: 66 Outgoing packets: 67
+
+# pcap stop
+# tftpput 0xffffffff80100000 $pcapsize 10.0.2.2:capture.pcap
+
diff --git a/roms/u-boot/doc/README.plan9 b/roms/u-boot/doc/README.plan9
new file mode 100644
index 000000000..2d3d0e0cf
--- /dev/null
+++ b/roms/u-boot/doc/README.plan9
@@ -0,0 +1,18 @@
+Plan 9 from Bell Labs kernel images require additional setup to pass
+configuration information to the kernel. An environment variable named
+confaddr must be defined with the same value as CONFADDR (see mem.h).
+Use of this facility is optional, but should be preferable to manual
+configuration.
+
+When booting an image, arguments supplied to the bootm command will be
+copied to CONFADDR. If no arguments are specified, the contents of the
+bootargs environment variable will be copied.
+
+If no command line arguments or bootargs are defined, CONFADDR is left
+uninitialized to permit manual configuration. For example, PC-style
+configuration could be simulated by issuing a fatload in bootcmd:
+
+ # setenv bootcmd fatload mmc 0 $confaddr plan9.ini; ...; bootm
+
+Steven Stallion
+June 2013
diff --git a/roms/u-boot/doc/README.power-framework b/roms/u-boot/doc/README.power-framework
new file mode 100644
index 000000000..1f6fd4320
--- /dev/null
+++ b/roms/u-boot/doc/README.power-framework
@@ -0,0 +1,166 @@
+#
+# (C) Copyright 2014 Samsung Electronics
+# Lukasz Majewski <l.majewski@samsung.com>
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+Introduction
+------------
+
+This document describes the second version of the u-boot's PMIC (Power
+Management IC) framework. As a reference boards please consider Samsungs' Trats
+and Trats2.
+
+Background
+----------
+
+Boards supported by u-boot are getting increasingly complex. Developers and
+designers strive to cut down power consumption. Hence several different types of
+devices are now available on the board - namely power managers (PMIC), fuel
+gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function
+devices (MFD).
+
+Explanation of key design decisions
+-----------------------------------
+
+One package can integrate PMIC and MUIC with different addresses on the I2C bus.
+The same device - e.g. MAX8997 uses two different I2C busses and addresses.
+
+Power devices use not only I2C for communication, but SPI as well. Additionally
+different ICs use different endianess. For this reason struct pmic holds
+information about I2C/SPI transmission, which is used with generic
+pmic_req_write() function.
+
+The "flat" hierarchy for power devices works well when each device performs only
+one operation - e.g. PMIC enables LDO.
+
+The problem emerges when we have a device (battery) which conceptually shall be
+the master and uses methods exported by other devices. We need to control MUIC
+to start charging the battery, use PMIC to reduce board's overall power
+consumption (by disabling not needed LDOs, BUCKs) and get current state of
+energy on the battery from FG.
+Up till now u-boot doesn't support device model, so a simple one had to be
+added.
+
+The directory hierarchy has following structure:
+./include/power/<device_name>_<device_function>.h
+e.g. ./include/power/max8997_pmic.h
+
+./drivers/power/pmic/power_{core files}.c
+e.g. ./drivers/power/pmic/power_core.c
+
+./drivers/power/pmic/<device_function>/<device_function>_<device_name>.c
+e.g. ./drivers/power/pmic/pmic_max8997.c
+e.g. ./drivers/power/battery/trats/bat_trats.c
+e.g. ./drivers/power/fuel_gauge/fg_max17042.c
+
+The framework classifies devices by their function - separate directories should
+be maintained for different classes of devices.
+
+Current design
+--------------
+
+Everything is a power device described by struct pmic. Even battery is
+considered as a valid power device. This helps for better management of those
+devices.
+
+- Block diagram of the hierarchy:
+ -----------------
+ --------| BAT |------------
+ | | | |
+ | ----------------- |
+ | | |
+ \|/ \|/ \|/
+ ----------- ----------------- ---------
+ |FG | |MUIC | |CHRG |
+ | | | | | |
+ ----------- ----------------- ---------
+
+
+1. When hierarchy is not needed (no complex battery charge):
+
+Definition of the struct pmic is only required with proper name and parameters
+for communication. This is enough to use the "pmic" command in the u-boot
+prompt to change values of device's register (enable/disable LDO, BUCK).
+
+The PG, MUIC and CHRG above are regarded to be in the same level in the
+hierarchy.
+
+2. Complex battery charging.
+
+To charge a battery, information from several "abstract" power devices is
+needed (defined at ./include/power/pmic.h):
+- FG device (struct power_fg):
+ -- *fg_battery_check - check if battery is not above its limits
+ -- *fg_battery_update - update the pmic framework with current
+ battery state(voltage and current capacity)
+
+- Charger device (struct power_chrq):
+ -- *chrg_type - type/capacity of the charger (including information
+ about USB cable disconnection)
+ -- *chrg_bat_present - detection if battery to be charged is
+ present
+ -- *chrg_state - status of the charger - if it is enabled or
+ disabled
+
+- Battery device (struct power_battery):
+ -- *battery_init - assign proper callbacks to be used by top
+ hierarchy battery device
+ -- *battery_charge - called from "pmic" command, responsible
+ for performing the charging
+
+Now two batteries are supported; trats and trats2 [*]. Those differ in the way
+how they handle the exact charging. Trats uses polling (MAX8997) and trats2
+relies on the PMIC/MUIC HW completely (MAX77693).
+
+__Example for trats (this can be very different for other board):__
+ -- *fg_battery_check -> FG device (fg_max17042.c)
+ -- *fg_battery_update -> FG device (fg_max17042.c)
+ -- *chrg_type -> MUIC device (muic_max8997.c)
+ -- *chrg_bat_present -> PMIC device (pmic_max8997.c)
+ -- *chrg_state -> PMIC device (pmic_max8997.c)
+ -- *battery_init -> BAT device (bat_trats.c)
+ -- *battery_charge -> BAT device (bat_trats.c)
+
+Also the struct pmic holds method (*low_power_mode) for reducing board's
+power consumption when one calls "pmic BAT_TRATS bat charge" command.
+
+How to add a new power device
+-----------------------------
+
+1. Simple device should be added with creation of file
+<pmic_function>_<pmic_name>.c, <pmic_name>_<pmic_function>.h according to the
+proposed and described above scheme.
+
+Then "pmic" command supports reading/writing/dump of device's internal
+registers.
+
+2. Charging battery with hierarchy
+Define devices as listed at 1.
+
+Define battery file (bat_<board>.c). Please also note that one might need a
+corresponding battery model description for FG.
+
+For points 1 and 2 use a generic function power_init_board() to initialise the
+power framework on your board.
+
+For reference, please look into the trats/trats2 boards.
+
+TO DO list (for PMICv3) - up till v2014.04
+------------------------------------------
+
+1. Description of the devices related to power via device tree is not available.
+This is the main problem when a developer tries to build a multi-boot u-boot
+binary. The best would be to parse the DTS from Linux kernel.
+
+2. To support many instances of the same IC, like two MAX8997, one needs to
+copy the corresponding pmic_max8997.c file with changed name to "MAX8997_PMICX",
+where X is the device number. This problem will be addressed when extended
+pmic_core.c will support storing available devices in a list.
+
+3. Definition of batteries [*] (for trats/trats2) should be excluded from the
+code responsible for charging them and since it in fact describes the charging
+profile it should be put to a separate file.
+
+4. Adjust the framework to work with the device model.
diff --git a/roms/u-boot/doc/README.pxe b/roms/u-boot/doc/README.pxe
new file mode 100644
index 000000000..b67151ca5
--- /dev/null
+++ b/roms/u-boot/doc/README.pxe
@@ -0,0 +1,258 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2010-2011 Calxeda, Inc.
+ */
+
+The 'pxe' commands provide a near subset of the functionality provided by
+the PXELINUX boot loader. This allows U-Boot based systems to be controlled
+remotely using the same PXE based techniques that many non U-Boot based servers
+use.
+
+Commands
+========
+
+pxe get
+-------
+ syntax: pxe get
+
+ follows PXELINUX's rules for retrieving configuration files from a tftp
+ server, and supports a subset of PXELINUX's config file syntax.
+
+ Environment
+ -----------
+ 'pxe get' requires two environment variables to be set:
+
+ pxefile_addr_r - should be set to a location in RAM large enough to hold
+ pxe files while they're being processed. Up to 16 config files may be
+ held in memory at once. The exact number and size of the files varies with
+ how the system is being used. A typical config file is a few hundred bytes
+ long.
+
+ bootfile,serverip - these two are typically set in the DHCP response
+ handler, and correspond to fields in the DHCP response.
+
+ 'pxe get' optionally supports these two environment variables being set:
+
+ ethaddr - this is the standard MAC address for the ethernet adapter in use.
+ 'pxe get' uses it to look for a configuration file specific to a system's
+ MAC address.
+
+ pxeuuid - this is a UUID in standard form using lower case hexadecimal
+ digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses
+ it to look for a configuration file based on the system's UUID.
+
+ File Paths
+ ----------
+ 'pxe get' repeatedly tries to download config files until it either
+ successfully downloads one or runs out of paths to try. The order and
+ contents of paths it tries mirrors exactly that of PXELINUX - you can
+ read in more detail about it at:
+
+ http://syslinux.zytor.com/wiki/index.php/Doc/pxelinux
+
+pxe boot
+--------
+ syntax: pxe boot [pxefile_addr_r]
+
+ Interprets a pxe file stored in memory.
+
+ pxefile_addr_r is an optional argument giving the location of the pxe file.
+ The file must be terminated with a NUL byte.
+
+ Environment
+ -----------
+ There are some environment variables that may need to be set, depending
+ on conditions.
+
+ pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied,
+ an environment variable named pxefile_addr_r must be supplied. This is
+ typically the same value as is used for the 'pxe get' command.
+
+ bootfile - typically set in the DHCP response handler based on the
+ same field in the DHCP respone, this path is used to generate the base
+ directory that all other paths to files retrieved by 'pxe boot' will use.
+ If no bootfile is specified, paths used in pxe files will be used as is.
+
+ serverip - typically set in the DHCP response handler, this is the IP
+ address of the tftp server from which other files will be retrieved.
+
+ kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will
+ store the kernel(or FIT image) and initrd it retrieves from tftp. These
+ locations will be passed to the bootm command to boot the kernel. These
+ environment variables are required to be set.
+
+ fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it
+ retrieves from tftp. The retrieval is possible if 'fdt' label is defined in
+ pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
+ will be passed to bootm command to boot the kernel.
+
+ fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm
+ command if it is set and 'fdt_addr_r' is not passed to bootm command.
+
+ fdtoverlay_addr_r - location in RAM at which 'pxe boot' will temporarily store
+ fdt overlay(s) before applying them to the fdt blob stored at 'fdt_addr_r'.
+
+pxe file format
+===============
+The pxe file format is nearly a subset of the PXELINUX file format; see
+http://syslinux.zytor.com/wiki/index.php/PXELINUX. It's composed of one line
+commands - global commands, and commands specific to labels. Lines begining
+with # are treated as comments. White space between and at the beginning of
+lines is ignored.
+
+The size of pxe files and the number of labels is only limited by the amount
+of RAM available to U-Boot. Memory for labels is dynamically allocated as
+they're parsed, and memory for pxe files is statically allocated, and its
+location is given by the pxefile_addr_r environment variable. The pxe code is
+not aware of the size of the pxefile memory and will outgrow it if pxe files
+are too large.
+
+Supported global commands
+-------------------------
+Unrecognized commands are ignored.
+
+default <label> - the label named here is treated as the default and is
+ the first label 'pxe boot' attempts to boot.
+
+menu title <string> - sets a title for the menu of labels being displayed.
+
+menu include <path> - use tftp to retrieve the pxe file at <path>, which
+ is then immediately parsed as if the start of its
+ contents were the next line in the current file. nesting
+ of include up to 16 files deep is supported.
+
+prompt <flag> - if 1, always prompt the user to enter a label to boot
+ from. if 0, only prompt the user if timeout expires.
+
+timeout <num> - wait for user input for <num>/10 seconds before
+ auto-booting a node.
+
+label <name> - begin a label definition. labels continue until
+ a command not recognized as a label command is seen,
+ or EOF is reached.
+
+Supported label commands
+------------------------
+labels end when a command not recognized as a label command is reached, or EOF.
+
+menu default - set this label as the default label to boot; this is
+ the same behavior as the global default command but
+ specified in a different way
+
+kernel <path> - if this label is chosen, use tftp to retrieve the kernel
+ (or FIT image) at <path>. it will be stored at the address
+ indicated in the kernel_addr_r environment variable, and
+ that address will be passed to bootm to boot this kernel.
+ For FIT image, The configuration specification can be
+ appended to the file name, with the format:
+ <path>#<conf>[#<extra-conf[#...]]
+ It will passed to bootm with that address.
+ (see: doc/uImage.FIT/command_syntax_extensions.txt)
+ It useful for overlay selection in pxe file
+ (see: doc/uImage.FIT/overlay-fdt-boot.txt)
+
+fdtoverlays <path> [...] - if this label is chosen, use tftp to retrieve the DT
+ overlay(s) at <path>. it will be temporarily stored at the
+ address indicated in the fdtoverlay_addr_r environment variable,
+ and then applied in the load order to the fdt blob stored at the
+ address indicated in the fdt_addr_r environment variable.
+
+append <string> - use <string> as the kernel command line when booting this
+ label.
+
+initrd <path> - if this label is chosen, use tftp to retrieve the initrd
+ at <path>. it will be stored at the address indicated in
+ the initrd_addr_r environment variable, and that address
+ will be passed to bootm.
+
+fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob
+ at <path>. it will be stored at the address indicated in
+ the fdt_addr_r environment variable, and that address will
+ be passed to bootm.
+
+fdtdir <path> - if this label is chosen, use tftp to retrieve a fdt blob
+ relative to <path>. If the fdtfile environment variable
+ is set, <path>/<fdtfile> is retrieved. Otherwise, the
+ filename is generated from the soc and board environment
+ variables, i.e. <path>/<soc>-<board>.dtb is retrieved.
+ If the fdt command is specified, fdtdir is ignored.
+
+localboot <flag> - Run the command defined by "localcmd" in the environment.
+ <flag> is ignored and is only here to match the syntax of
+ PXELINUX config files.
+
+Example
+-------
+Here's a couple of example files to show how this works.
+
+------------/tftpboot/pxelinux.cfg/menus/base.menu-----------
+menu title Linux selections
+
+# This is the default label
+label install
+ menu label Default Install Image
+ kernel kernels/install.bin
+ append console=ttyAMA0,38400 debug earlyprintk
+ initrd initrds/uzInitrdDebInstall
+
+# Just another label
+label linux-2.6.38
+ kernel kernels/linux-2.6.38.bin
+ append root=/dev/sdb1
+
+# The locally installed kernel
+label local
+ menu label Locally installed kernel
+ append root=/dev/sdb1
+ localboot 1
+-------------------------------------------------------------
+
+------------/tftpboot/pxelinux.cfg/default-------------------
+menu include pxelinux.cfg/menus/base.menu
+timeout 500
+
+default linux-2.6.38
+-------------------------------------------------------------
+
+When a pxe client retrieves and boots the default pxe file,
+'pxe boot' will wait for user input for 5 seconds before booting
+the linux-2.6.38 label, which will cause /tftpboot/kernels/linux-2.6.38.bin
+to be downloaded, and boot with the command line "root=/dev/sdb1"
+
+Differences with PXELINUX
+=========================
+The biggest difference between U-Boot's pxe and PXELINUX is that since
+U-Boot's pxe support is written entirely in C, it can run on any platform
+with network support in U-Boot. Here are some other differences between
+PXELINUX and U-Boot's pxe support.
+
+- U-Boot's pxe does not support the PXELINUX DHCP option codes specified
+ in RFC 5071, but could be extended to do so.
+
+- when U-Boot's pxe fails to boot, it will return control to U-Boot,
+ allowing another command to run, other U-Boot command, instead of resetting
+ the machine like PXELINUX.
+
+- U-Boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
+ only uses U-Boot.
+
+- U-Boot's pxe doesn't provide the full menu implementation that PXELINUX
+ does, only a simple text based menu using the commands described in
+ this README. With PXELINUX, it's possible to have a graphical boot
+ menu, submenus, passwords, etc. U-Boot's pxe could be extended to support
+ a more robust menuing system like that of PXELINUX's.
+
+- U-Boot's pxe expects U-Boot uimg's as kernels. Anything that would work
+ with the 'bootm' command in U-Boot could work with the 'pxe boot' command.
+
+- U-Boot's pxe only recognizes a single file on the initrd command line. It
+ could be extended to support multiple.
+
+- in U-Boot's pxe, the localboot command doesn't necessarily cause a local
+ disk boot - it will do whatever is defined in the 'localcmd' env
+ variable. And since it doesn't support a full UNDI/PXE stack, the
+ type field is ignored.
+
+- the interactive prompt in U-Boot's pxe only allows you to choose a label
+ from the menu. If you want to boot something not listed, you can ctrl+c
+ out of 'pxe boot' and use existing U-Boot commands to accomplish it.
diff --git a/roms/u-boot/doc/README.ramboot-ppc85xx b/roms/u-boot/doc/README.ramboot-ppc85xx
new file mode 100644
index 000000000..c9fef533a
--- /dev/null
+++ b/roms/u-boot/doc/README.ramboot-ppc85xx
@@ -0,0 +1,102 @@
+ RAMBOOT for MPC85xx Platforms
+ ==============================
+
+RAMBOOT literally means boot from DDR. But since DDR is volatile memory some
+pre-mechanism is required to load the DDR with the bootloader binary.
+- In case of SD and SPI boot this is done by BootROM code inside the chip
+ itself.
+- In case of NAND boot FCM supports loading initial 4K code from NAND flash
+ which can initialize the DDR and get the complete bootloader copied to DDR.
+
+In addition to the above there could be some more methods to initialize the DDR
+and load it manually.
+Two of them are described below.There is also an explanation as to where these
+methods could be handy.
+1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then
+ execute the bootloader from DDR.
+ This may be handy in the following cases:
+ - In very early stage of platform bringup where other boot options are not
+ functional because of various reasons.
+ - In case the support to program the flashes on the board is not available.
+
+2. Load the RAM based bootloader onto DDR using already existing bootloader on
+ the board.And then execute the bootloader from DDR.
+ Some usecases where this may be used:
+ - While developing some new feature of u-boot, for example USB driver or
+ SPI driver.
+ Suppose the board already has a working bootloader on it. And you would
+ prefer to keep it intact, at the same time want to test your bootloader.
+ In this case you can get your test bootloader binary into DDR via tftp
+ for example. Then execute the test bootloader.
+ - Suppose a platform already has a propreitery bootloader which does not
+ support for example AMP boot. In this case also RAM boot loader can be
+ utilized.
+
+ So basically when the original bootloader is required to be kept intact
+ RAM based bootloader can offer an updated bootloader on the system.
+
+Both the above Bootloaders are slight variants of SDcard or SPI Flash
+bootloader or for that matter even NAND bootloader.
+All of them define CONFIG_SYS_RAMBOOT.
+The main difference among all of them is the way the pre-environment is getting
+configured and who is doing that.
+- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself.
+- In case of NAND boot SPL/TPL code does it with some support from Si itself.
+- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader.
+
+How to use them:
+1. Using JTAG
+ Boot up in core hold off mode or stop the core after reset using JTAG
+ interface.
+ Preconfigure DDR/L2SRAM through JTAG interface.
+ - setup DDR controller registers.
+ - setup DDR LAWs
+ - setup DDR TLB
+ Load the RAM based boot loader to the proper location in DDR/L2SRAM.
+ set up IAR (Instruction counter properly)
+ Enable the core to execute.
+
+2. Using already existing bootloader.
+ get the rambased boot loader binary into DDR/L2SRAM via tftp.
+ execute the RAM based bootloader.
+ => tftp 11000000 u-boot-ram.bin
+ => go 1107f000
+
+Please note that L2SRAM can also be used instead of DDR if the SOC has
+sufficient size of L2SRAM.
+
+Necessary Code changes Required:
+=====================================
+Please note that below mentioned changes are for 85xx platforms.
+They have been tested on P1020/P2020/P1010 RDB.
+
+The main difference between the above two methods from technical perspective is
+that in 1st case SOC is just out of reset so it is in default configuration.
+(CCSRBAR is at 0xff700000).
+In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000
+
+1. File name-> boards.cfg
+ There can be added specific Make options for RAMBoot. We can keep different
+ options for the two cases mentioned above.
+ for example
+ P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT.
+
+2. platform config file
+ for example include/configs/P1_P2_RDB.h
+
+ #ifdef CONFIG_RAMBOOT
+ #define CONFIG_SDCARD
+ #endif
+
+ This will finally use the CONFIG_SYS_RAMBOOT.
+
+3. Change CONFIG_SYS_CCSRBAR_DEFAULT in menuconfig accordingly.
+ In the section of the particular SOC, for example P1020, pseudo code
+
+ #if defined(CONFIG_GO)
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000
+ #else
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000
+ #endif
+
+For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000.
diff --git a/roms/u-boot/doc/README.rmobile b/roms/u-boot/doc/README.rmobile
new file mode 100644
index 000000000..ea170a25a
--- /dev/null
+++ b/roms/u-boot/doc/README.rmobile
@@ -0,0 +1,98 @@
+Summary
+=======
+
+This README is about U-Boot support for Renesas's ARM Cortex-A9 based RMOBILE[1]
+and Cortex-A9/A53/A57 based R-Car[2] family of SoCs. Renesas's RMOBILE/R-Car SoC
+family contains an ARM Cortex-A9/A53/A57.
+
+Currently the following boards are supported:
+
+| SoC | Board | defconfig
+|===============+========================================+===================
+| R8A73A0 | KMC KZM-A9-GT [3] | kzm9g_config
+| R8A7734 | Atmark-Techno Armadillo-800-EVA [4] | armadillo-800eva_config
+|===============+========================================+===================
+| R8A7790 H2 | Renesas Electronics Lager | lager_defconfig
+| | Renesas Electronics Stout | stout_defconfig
+|---------------+----------------------------------------+-------------------
+| R8A7791 M2-W | Renesas Electronics Koelsch | koelsch_defconfig
+| | Renesas Electronics Porter | porter_defconfig
+|---------------+----------------------------------------+-------------------
+| R8A7792 V2H | Renesas Electronics Blanche | blanche_defconfig
+|---------------+----------------------------------------+-------------------
+| R8A7793 M2-N | Renesas Electronics Gose | gose_defconfig
+|---------------+----------------------------------------+-------------------
+| R8A7794 E2 | Renesas Electronics Alt | alt_defconfig
+| | Renesas Electronics Silk | silk_defconfig
+|===============+========================================+===================
+| R8A7795 H3 | Renesas Electronics Salvator-XS ES2.0+ | r8a7795_salvator-x_defconfig
+| R8A7795 H3 | Renesas Electronics ULCB ES2.0+ | r8a7795_ulcb
+|---------------+----------------------------------------+-------------------
+| R8A7796 M3-W | Renesas Electronics Salvator-X | r8a7796_salvator-x_defconfig
+| R8A7796 M3-W | Renesas Electronics ULCB | r8a7796_ulcb
+|---------------+----------------------------------------+-------------------
+| R8A77965 M3-N | Renesas Electronics Salvator-XS | r8a77965_salvator-x_defconfig
+| R8A77965 M3-N | Renesas Electronics ULCB | r8a77965_ulcb
+|---------------+----------------------------------------+-------------------
+| R8A77970 V3M | Renesas Electronics Eagle | r8a77970_eagle_defconfig
+|---------------+----------------------------------------+-------------------
+| R8A77995 D3 | Renesas Electronics Draak | r8a77995_draak_defconfig
+'===============+========================================+===================
+
+Toolchain
+=========
+
+Either ARMv7 toolchain for 32bit Cortex-A9 systems or ARMv8 (aarch64)
+toolchain for 64bit Cortex-A53/A57 systems. Currently we compile the
+32bit systems with -march=armv5 to allow more compilers to work. (For
+U-Boot code this has no performance impact.)
+
+Currently, ELDK[5], Linaro[6], CodeSourcery[7] and Emdebian[8] supports
+ARMv7. Modern distributions also contain ARMv7 and ARMv8 crosstoolchains
+in their package feeds.
+
+Build
+=====
+
+Locate defconfig in the table above. Then apply standard build procedure:
+
+ make <board>_defconfig
+ make
+
+ Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only.
+ Please see "B.2 Appendix B Boot Specifications" in hardware manual.
+
+Links
+=====
+
+[1] Renesas RMOBILE:
+
+http://am.renesas.com/products/soc/assp/mobile/r_mobile/index.jsp
+
+[2] Renesas R-Car:
+
+http://am.renesas.com/products/soc/assp/automotive/index.jsp
+
+[3] KZM-A9-GT
+
+http://www.kmckk.co.jp/kzma9-gt/index.html
+
+[4] Armadillo-800-EVA
+
+http://armadillo.atmark-techno.com/armadillo-800-EVA
+
+[5] ELDK
+
+http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6.
+
+[6] Linaro
+
+http://www.linaro.org/downloads/
+
+[7] CodeSourcey
+
+http://www.mentor.com/embedded-software/codesourcery
+
+[8] Emdebian
+
+http://www.emdebian.org/crosstools.html
diff --git a/roms/u-boot/doc/README.rockchip b/roms/u-boot/doc/README.rockchip
new file mode 100644
index 000000000..154166ec7
--- /dev/null
+++ b/roms/u-boot/doc/README.rockchip
@@ -0,0 +1,703 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2015 Google. Inc
+# Written by Simon Glass <sjg@chromium.org>
+
+U-Boot on Rockchip
+==================
+
+A wide range of Rockchip SoCs are supported in mainline U-Boot
+
+Warning
+=======
+This document is being moved to doc/board/rockchip, so information on it
+might be incomplete or outdated.
+
+Prerequisites
+=============
+
+You will need:
+
+ - Firefly RK3288 board or something else with a supported RockChip SoC
+ - Power connection to 5V using the supplied micro-USB power cable
+ - Separate USB serial cable attached to your computer and the Firefly
+ (connect to the micro-USB connector below the logo)
+ - rkflashtool [3]
+ - openssl (sudo apt-get install openssl)
+ - Serial UART connection [4]
+ - Suitable ARM cross compiler, e.g.:
+ sudo apt-get install gcc-4.7-arm-linux-gnueabi
+
+Building
+========
+
+1. To build RK3288 board:
+
+ CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
+
+ (or you can use another cross compiler if you prefer)
+
+2. To build RK3308 board:
+ - Get the rkbin
+ => git clone https://github.com/rockchip-linux/rkbin.git
+
+ - Compile U-Boot
+ => cd /path/to/u-boot
+ => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf
+ => make roc-cc-rk3308_defconfig
+ => make CROSS_COMPILE=aarch64-linux-gnu- all
+ => ./tools/mkimage -n rk3308 -T rksd -d /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img
+ => cat spl/u-boot-spl.bin >> idbloader.img
+
+3. To build RK3399 board:
+
+ Option 1: Package the image with Rockchip miniloader:
+
+ - Compile U-Boot
+
+ => cd /path/to/u-boot
+ => make nanopi-neo4-rk3399_defconfig
+ => make
+
+ - Get the rkbin
+
+ => git clone https://github.com/rockchip-linux/rkbin.git
+
+ - Create trust.img
+
+ => cd /path/to/rkbin
+ => ./tools/trust_merger RKTRUST/RK3399TRUST.ini
+
+ - Create uboot.img
+
+ => cd /path/to/rkbin
+ => ./tools/loaderimage --pack --uboot /path/to/u-boot/u-boot-dtb.bin uboot.img
+
+ (Get trust.img and uboot.img)
+
+ Option 2: Package the image with SPL:
+
+ - Export cross compiler path for aarch64
+
+ - Compile ATF
+
+ For Puma board.
+
+ => git clone git://git.theobroma-systems.com/arm-trusted-firmware.git
+ => cd arm-trusted-firmware
+ => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
+
+ (export bl31.bin)
+ => export BL31=/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.bin
+
+ For rest of rk3399 boards.
+
+ => git clone https://github.com/ARM-software/arm-trusted-firmware.git
+ => cd arm-trusted-firmware
+
+ (export cross compiler path for Cortex-M0 MCU likely arm-none-eabi-)
+ => make realclean
+ => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+ (export bl31.elf)
+ => export BL31=/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf
+
+ - Compile PMU M0 firmware
+
+ This is optional for most of the rk3399 boards and required only for Puma board.
+
+ => git clone git://git.theobroma-systems.com/rk3399-cortex-m0.git
+ => cd rk3399-cortex-m0
+
+ (export cross compiler path for Cortex-M0 PMU)
+ => make CROSS_COMPILE=arm-cortex_m0-eabi-
+
+ (export rk3399m0.bin)
+ => export PMUM0=/path/to/rk3399-cortex-m0/rk3399m0.bin
+
+ - Compile U-Boot
+
+ => cd /path/to/u-boot
+ => make orangepi-rk3399_defconfig
+ => make
+
+ (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get
+ spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL
+
+ If TPL enabled on the target, get tpl/u-boot-tpl-dtb.bin or tpl/u-boot-tpl.bin
+ if CONFIG_TPL_OF_CONTROL not enabled)
+
+Writing to the board with USB
+=============================
+
+For USB to work you must get your board into ROM boot mode, either by erasing
+your MMC or (perhaps) holding the recovery button when you boot the board.
+To erase your MMC, you can boot into Linux and type (as root)
+
+ dd if=/dev/zero of=/dev/mmcblk0 bs=1M
+
+Connect your board's OTG port to your computer.
+
+To create a suitable image and write it to the board:
+
+ ./firefly-rk3288/tools/mkimage -n rk3288 -T rkimage -d \
+ ./firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
+ cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | rkflashtool l
+
+If all goes well you should something like:
+
+ U-Boot SPL 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 10:06:49)
+ Card did not respond to voltage select!
+ spl: mmc init failed with error: -17
+ ### ERROR ### Please RESET the board ###
+
+You will need to reset the board before each time you try. Yes, that's all
+it does so far. If support for the Rockchip USB protocol or DFU were added
+in SPL then we could in principle load U-Boot and boot to a prompt from USB
+as several other platforms do. However it does not seem to be possible to
+use the existing boot ROM code from SPL.
+
+
+Writing to the eMMC with USB on ROC-RK3308-CC
+=============================================
+For USB to work you must get your board into Bootrom mode,
+either by erasing the eMMC or short circuit the GND and D0
+on core board.
+
+Connect the board to your computer via tyepc.
+=> rkdeveloptool db rk3308_loader_v1.26.117.bin
+=> rkdeveloptool wl 0x40 idbloader.img
+=> rkdeveloptool wl 0x4000 u-boot.itb
+=> rkdeveloptool rd
+
+Then you will see the boot log from Debug UART at baud rate 1500000:
+DDR Version V1.26
+REGFB: 0x00000032, 0x00000032
+In
+589MHz
+DDR3
+ Col=10 Bank=8 Row=14 Size=256MB
+msch:1
+Returning to boot ROM...
+
+U-Boot SPL 2020.01-rc1-00225-g34b681327f (Nov 14 2019 - 10:58:04 +0800)
+Trying to boot from MMC1
+INFO: Preloader serial: 2
+NOTICE: BL31: v1.3(release):30f1405
+NOTICE: BL31: Built : 17:08:28, Sep 23 2019
+INFO: Lastlog: last=0x100000, realtime=0x102000, size=0x2000
+INFO: ARM GICv2 driver initialized
+INFO: Using opteed sec cpu_context!
+INFO: boot cpu mask: 1
+INFO: plat_rockchip_pmu_init: pd status 0xe b
+INFO: BL31: Initializing runtime services
+WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will rK
+ERROR: Error initializing runtime service opteed_fast
+INFO: BL31: Preparing for EL3 exit to normal world
+INFO: Entry point address = 0x600000
+INFO: SPSR = 0x3c9
+
+
+U-Boot 2020.01-rc1-00225-g34b681327f (Nov 14 2019 - 10:58:47 +0800)
+
+Model: Firefly ROC-RK3308-CC board
+DRAM: 254 MiB
+MMC: dwmmc@ff480000: 0, dwmmc@ff490000: 1
+rockchip_dnl_key_pressed read adc key val failed
+Net: No ethernet found.
+Hit any key to stop autoboot: 0
+Card did not respond to voltage select!
+switch to partitions #0, OK
+mmc1(part 0) is current device
+Scanning mmc 1:4...
+Found /extlinux/extlinux.conf
+Retrieving file: /extlinux/extlinux.conf
+151 bytes read in 3 ms (48.8 KiB/s)
+1: kernel-mainline
+Retrieving file: /Image
+14737920 bytes read in 377 ms (37.3 MiB/s)
+append: earlycon=uart8250,mmio32,0xff0c0000 console=ttyS2,1500000n8
+Retrieving file: /rk3308-roc-cc.dtb
+28954 bytes read in 4 ms (6.9 MiB/s)
+Flattened Device Tree blob at 01f00000
+Booting using the fdt blob at 0x1f00000
+## Loading Device Tree to 000000000df3a000, end 000000000df44119 ... OK
+
+Starting kernel ...
+[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd042]
+[ 0.000000] Linux version 5.4.0-rc1-00040-g4dc2d508fa47-dirty (andy@B150) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-209
+[ 0.000000] Machine model: Firefly ROC-RK3308-CC board
+[ 0.000000] earlycon: uart8250 at MMIO32 0x00000000ff0c0000 (options '')
+[ 0.000000] printk: bootconsole [uart8250] enabled
+
+Booting from an SD card
+=======================
+
+To write an image that boots from an SD card (assumed to be /dev/sdc):
+
+ ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
+ firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
+ sudo dd if=out of=/dev/sdc seek=64 && \
+ sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=16384
+
+This puts the Rockchip header and SPL image first and then places the U-Boot
+image at block 16384 (i.e. 8MB from the start of the SD card). This
+corresponds with this setting in U-Boot:
+
+ #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x4000
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+ U-Boot 2016.01-rc2-00309-ge5bad3b-dirty (Jan 02 2016 - 23:41:59 -0700)
+
+ Model: Radxa Rock 2 Square
+ DRAM: 2 GiB
+ MMC: dwmmc@ff0f0000: 0, dwmmc@ff0c0000: 1
+ *** Warning - bad CRC, using default environment
+
+ In: serial
+ Out: vop@ff940000.vidconsole
+ Err: serial
+ Net: Net Initialization Skipped
+ No ethernet found.
+ Hit any key to stop autoboot: 0
+ =>
+
+The rockchip bootrom can load and boot an initial spl, then continue to
+load a second-stage bootloader (ie. U-Boot) as soon as the control is returned
+to the bootrom. Both the RK3288 and the RK3036 use this special boot sequence.
+The configuration option enabling this is:
+
+ CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
+
+You can create the image via the following operations:
+
+ ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
+ firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
+ cat firefly-rk3288/u-boot-dtb.bin >> out && \
+ sudo dd if=out of=/dev/sdc seek=64
+
+Or:
+ ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
+ firefly-rk3288/spl/u-boot-spl-dtb.bin:firefly-rk3288/u-boot-dtb.bin \
+ out && \
+ sudo dd if=out of=/dev/sdc seek=64
+
+If you have an HDMI cable attached you should see a video console.
+
+For evb_rk3036 board:
+ ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d evb-rk3036/spl/u-boot-spl.bin out && \
+ cat evb-rk3036/u-boot-dtb.bin >> out && \
+ sudo dd if=out of=/dev/sdc seek=64
+
+Or:
+ ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d \
+ evb-rk3036/spl/u-boot-spl.bin:evb-rk3036/u-boot-dtb.bin out && \
+ sudo dd if=out of=/dev/sdc seek=64
+
+Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the
+ debug uart must be disabled
+
+
+Booting from an SD card on RK3288 with TPL
+==========================================
+
+Since the size of SPL can't be exceeded 0x8000 bytes in RK3288, it is not possible add
+new SPL features like Falcon mode or etc.
+
+So introduce TPL so-that adding new features to SPL is possible because now TPL should
+run minimal with code like DDR, clock etc and rest of new features in SPL.
+
+As of now TPL is added on Vyasa-RK3288 board.
+
+To write an image that boots from an SD card (assumed to be /dev/mmcblk0):
+
+ sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 &&
+ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 seek=16384
+
+Booting from an SD card on RK3188
+=================================
+
+For rk3188 boards the general storage onto the card stays the same as
+described above, but the image creation needs a bit more care.
+
+The bootrom of rk3188 expects to find a small 1kb loader which returns
+control to the bootrom, after which it will load the real loader, which
+can then be up to 29kb in size and does the regular ddr init. This is
+handled by a single image (built as the SPL stage) that tests whether
+it is handled for the first or second time via code executed from the
+boot0-hook.
+
+Additionally the rk3188 requires everything the bootrom loads to be
+rc4-encrypted. Except for the very first stage the bootrom always reads
+and decodes 2kb pages, so files should be sized accordingly.
+
+# copy tpl, pad to 1020 bytes and append spl
+tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
+
+# truncate, encode and append u-boot.bin
+truncate -s %2048 u-boot.bin
+cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out
+
+Booting from an SD card on Pine64 Rock64 (RK3328)
+=================================================
+
+For Rock64 rk3328 board the following three parts are required:
+TPL, SPL, and the u-boot image tree blob.
+
+ - Write TPL/SPL image at 64 sector
+
+ => sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
+
+ - Write u-boot image tree blob at 16384 sector
+
+ => sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
+
+Booting from an SD card on RK3399
+=================================
+
+To write an image that boots from an SD card (assumed to be /dev/sdc):
+
+Option 1: Package the image with Rockchip miniloader:
+
+ - Create idbloader.img
+
+ => cd /path/to/u-boot
+ => ./tools/mkimage -n rk3399 -T rksd -d /path/to/rkbin/bin/rk33/rk3399_ddr_800MHz_v1.20.bin idbloader.img
+ => cat /path/to/rkbin/bin/rk33/rk3399_miniloader_v1.19.bin >> idbloader.img
+
+ - Write idbloader.img at 64 sector
+
+ => sudo dd if=idbloader.img of=/dev/sdc seek=64
+
+ - Write trust.img at 24576
+
+ => sudo dd if=trust.img of=/dev/sdc seek=24576
+
+ - Write uboot.img at 16384 sector
+
+ => sudo dd if=uboot.img of=/dev/sdc seek=16384
+ => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+DDR Version 1.20 20190314
+In
+Channel 0: DDR3, 933MHz
+Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
+no stride
+ch 0 ddrconfig = 0x101, ddrsize = 0x20
+pmugrf_os_reg[2] = 0x10006281, stride = 0x17
+OUT
+Boot1: 2019-03-14, version: 1.19
+CPUId = 0x0
+ChipType = 0x10, 239
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+SdmmcInit=2 1
+mmc0:cmd5,20
+SdmmcInit=0 0
+BootCapSize=0
+UserCapSize=60543MB
+FwPartOffset=2000 , 0
+StorageInit ok = 45266
+SecureMode = 0
+SecureInit read PBA: 0x4
+SecureInit read PBA: 0x404
+SecureInit read PBA: 0x804
+SecureInit read PBA: 0xc04
+SecureInit read PBA: 0x1004
+SecureInit read PBA: 0x1404
+SecureInit read PBA: 0x1804
+SecureInit read PBA: 0x1c04
+SecureInit ret = 0, SecureMode = 0
+atags_set_bootdev: ret:(0)
+GPT 0x3380ec0 signature is wrong
+recovery gpt...
+GPT 0x3380ec0 signature is wrong
+recovery gpt fail!
+LoadTrust Addr:0x4000
+No find bl30.bin
+Load uboot, ReadLba = 2000
+hdr 0000000003380880 + 0x0:0x88,0x41,0x3e,0x97,0xe6,0x61,0x54,0x23,0xe9,0x5a,0xd1,0x2b,0xdc,0x2f,0xf9,0x35,
+
+Load OK, addr=0x200000, size=0x9c9c0
+RunBL31 0x10000
+NOTICE: BL31: v1.3(debug):370ab80
+NOTICE: BL31: Built : 09:23:41, Mar 4 2019
+NOTICE: BL31: Rockchip release version: v1.1
+INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
+INFO: Using opteed sec cpu_context!
+INFO: boot cpu mask: 0
+INFO: plat_rockchip_pmu_init(1181): pd status 3e
+INFO: BL31: Initializing runtime services
+INFO: BL31: Initializing BL32
+INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-195-g8f090d20 #6 Fri Dec 7 06:11:20 UTC 2018 aarch64)
+
+INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2
+
+INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
+INFO: BL31: Preparing for EL3 exit to normal world
+INFO: Entry point address = 0x200000
+INFO: SPSR = 0x3c9
+
+
+U-Boot 2019.04-rc4-00136-gfd121f9641-dirty (Apr 16 2019 - 14:02:47 +0530)
+
+Model: FriendlyARM NanoPi NEO4
+DRAM: 1022 MiB
+MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
+Loading Environment from MMC... *** Warning - bad CRC, using default environment
+
+In: serial@ff1a0000
+Out: serial@ff1a0000
+Err: serial@ff1a0000
+Model: FriendlyARM NanoPi NEO4
+Net: eth0: ethernet@fe300000
+Hit any key to stop autoboot: 0
+=>
+
+Option 2: Package the image with SPL:
+
+ - Prefix rk3399 header to SPL image
+
+ => cd /path/to/u-boot
+ => ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl-dtb.bin out
+
+ - Write prefixed SPL at 64th sector
+
+ => sudo dd if=out of=/dev/sdc seek=64
+
+ - Write U-Boot proper at 16384 sector
+
+ => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
+ => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+U-Boot SPL board init
+Trying to boot from MMC1
+
+
+U-Boot 2019.01-00004-g14db5ee998 (Mar 11 2019 - 13:18:41 +0530)
+
+Model: Orange Pi RK3399 Board
+DRAM: 2 GiB
+MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
+Loading Environment from MMC... OK
+In: serial@ff1a0000
+Out: serial@ff1a0000
+Err: serial@ff1a0000
+Model: Orange Pi RK3399 Board
+Net: eth0: ethernet@fe300000
+Hit any key to stop autoboot: 0
+=>
+
+Option 3: Package the image with TPL:
+
+ - Write tpl+spl at 64th sector
+
+ => sudo dd if=idbloader.img of=/dev/sdc seek=64
+
+ - Write U-Boot proper at 16384 sector
+
+ => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
+ => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+U-Boot TPL board init
+Trying to boot from BOOTROM
+Returning to boot ROM...
+
+U-Boot SPL board init
+Trying to boot from MMC1
+
+
+U-Boot 2019.07-rc1-00241-g5b3244767a (May 08 2019 - 10:51:06 +0530)
+
+Model: Orange Pi RK3399 Board
+DRAM: 2 GiB
+MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
+Loading Environment from MMC... OK
+In: serial@ff1a0000
+Out: serial@ff1a0000
+Err: serial@ff1a0000
+Model: Orange Pi RK3399 Board
+Net: eth0: ethernet@fe300000
+Hit any key to stop autoboot: 0
+=>
+
+Using fastboot on rk3288
+========================
+- Write GPT partition layout to mmc device which fastboot want to use it to
+store the image
+
+ => gpt write mmc 1 $partitions
+
+- Invoke fastboot command to prepare
+
+ => fastboot 1
+
+- Start fastboot request on PC
+
+ fastboot -i 0x2207 flash loader evb-rk3288/spl/u-boot-spl-dtb.bin
+
+You should see something like:
+
+ => fastboot 1
+ WARNING: unknown variable: partition-type:loader
+ Starting download of 357796 bytes
+ ..
+ downloading of 357796 bytes finished
+ Flashing Raw Image
+ ........ wrote 357888 bytes to 'loader'
+
+Booting from SPI
+================
+
+To write an image that boots from SPI flash (e.g. for the Haier Chromebook or
+Bob):
+
+ ./chromebook_jerry/tools/mkimage -n rk3288 -T rkspi \
+ -d chromebook_jerry/spl/u-boot-spl-dtb.bin spl.bin && \
+ dd if=spl.bin of=spl-out.bin bs=128K conv=sync && \
+ cat spl-out.bin chromebook_jerry/u-boot-dtb.img >out.bin && \
+ dd if=out.bin of=out.bin.pad bs=4M conv=sync
+
+This converts the SPL image to the required SPI format by adding the Rockchip
+header and skipping every second 2KB block. Then the U-Boot image is written at
+offset 128KB and the whole image is padded to 4MB which is the SPI flash size.
+The position of U-Boot is controlled with this setting in U-Boot:
+
+ #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x20000
+
+If you have a Dediprog em100pro connected then you can write the image with:
+
+ sudo em100 -s -c GD25LQ32 -d out.bin.pad -r
+
+When booting you should see something like:
+
+ U-Boot SPL 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32)
+
+
+ U-Boot 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32 -0600)
+
+ Model: Google Jerry
+ DRAM: 2 GiB
+ MMC:
+ Using default environment
+
+ In: serial@ff690000
+ Out: serial@ff690000
+ Err: serial@ff690000
+ =>
+
+Future work
+===========
+
+Immediate priorities are:
+
+- USB host
+- USB device
+- Run CPU at full speed (code exists but we only see ~60 DMIPS maximum)
+- NAND flash
+- Boot U-Boot proper over USB OTG (at present only SPL works)
+
+
+Development Notes
+=================
+
+There are plenty of patches in the links below to help with this work.
+
+[1] https://github.com/rkchrome/uboot.git
+[2] https://github.com/linux-rockchip/u-boot-rockchip.git branch u-boot-rk3288
+[3] https://github.com/linux-rockchip/rkflashtool.git
+[4] http://wiki.t-firefly.com/index.php/Firefly-RK3288/Serial_debug/en
+
+rkimage
+-------
+
+rkimage.c produces an SPL image suitable for sending directly to the boot ROM
+over USB OTG. This is a very simple format - just the string RK32 (as 4 bytes)
+followed by u-boot-spl-dtb.bin.
+
+The boot ROM loads image to 0xff704000 which is in the internal SRAM. The SRAM
+starts at 0xff700000 and extends to 0xff718000 where we put the stack.
+
+rksd
+----
+
+rksd.c produces an image consisting of 32KB of empty space, a header and
+u-boot-spl-dtb.bin. The header is defined by 'struct header0_info' although
+most of the fields are unused by U-Boot. We just need to specify the
+signature, a flag and the block offset and size of the SPL image.
+
+The header occupies a single block but we pad it out to 4 blocks. The header
+is encoding using RC4 with the key 7c4e0304550509072d2c7b38170d1711. The SPL
+image can be encoded too but we don't do that.
+
+The maximum size of u-boot-spl-dtb.bin which the boot ROM will read is 32KB,
+or 0x40 blocks. This is a severe and annoying limitation. There may be a way
+around this limitation, since there is plenty of SRAM, but at present the
+board refuses to boot if this limit is exceeded.
+
+The image produced is padded up to a block boundary (512 bytes). It should be
+written to the start of an SD card using dd.
+
+Since this image is set to load U-Boot from the SD card at block offset,
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, dd should be used to write
+u-boot-dtb.img to the SD card at that offset. See above for instructions.
+
+rkspi
+-----
+
+rkspi.c produces an image consisting of a header and u-boot-spl-dtb.bin. The
+resulting image is then spread out so that only the first 2KB of each 4KB
+sector is used. The header is the same as with rksd and the maximum size is
+also 32KB (before spreading). The image should be written to the start of
+SPI flash.
+
+See above for instructions on how to write a SPI image.
+
+rkmux.py
+--------
+
+You can use this script to create #defines for SoC register access. See the
+script for usage.
+
+
+Device tree and driver model
+----------------------------
+
+Where possible driver model is used to provide a structure to the
+functionality. Device tree is used for configuration. However these have an
+overhead and in SPL with a 32KB size limit some shortcuts have been taken.
+In general all Rockchip drivers should use these features, with SPL-specific
+modifications where required.
+
+GPT partition layout
+----------------------------
+
+Rockchip use a unified GPT partition layout in open source support.
+With this GPT partition layout, uboot can be compatilbe with other components,
+like miniloader, trusted-os, arm-trust-firmware.
+
+There are some documents about partitions in the links below.
+http://rockchip.wikidot.com/partitions
+
+--
+Jagan Teki <jagan@amarulasolutions.com>
+27 Mar 2019
+Simon Glass <sjg@chromium.org>
+24 June 2015
diff --git a/roms/u-boot/doc/README.rockusb b/roms/u-boot/doc/README.rockusb
new file mode 100644
index 000000000..66437e17e
--- /dev/null
+++ b/roms/u-boot/doc/README.rockusb
@@ -0,0 +1,56 @@
+Rockusb (Rockchip USB protocol)
+=====================================================
+
+Overview
+--------
+
+Rockusb protocol is widely used by Rockchip SoC based devices. It can
+read/write info, image to/from devices. This document briefly describes how to
+use Rockusb for upgrading firmware (e.g. kernel, u-boot, rootfs, etc.).
+
+Tools
+--------
+There are many tools can support Rockusb protocol. rkdeveloptool
+(https://github.com/rockchip-linux/rkdeveloptool) is open source,
+It is maintained by Rockchip. People don't want to build from source
+can download from here
+(https://github.com/rockchip-linux/rkbin/blob/master/tools/rkdeveloptool)
+
+Usage
+--------
+The Usage of Rockusb command is:
+
+rockusb <USB_controller> <devtype> <dev[:part]>
+
+e.g. rockusb 0 mmc 0
+
+On your U-Boot console, type this command to enter rockusb mode.
+On your host PC. use lsusb command. you should see a usb device
+using 0x2207 as its USB verdor id.
+
+for more detail about the rkdeveloptool. please read the usage.
+
+rkdeveloptool -h
+
+use rkdeveloptool wl command to write lba. BeginSec is the lba on device
+you want to write.
+
+sudo rkdeveloptool wl <BeginSec> <File>
+
+to flash U-Boot image use below command. U-Boot binary is made by mkimage.
+see doc/README.rockchip for more detail about how to get U-Boot binary.
+
+sudo rkdeveloptool wl 64 <U-Boot binary>
+
+Current set of rkdeveloptool commands supported:
+- rci: Read Chip Info
+- rfi: Read Flash Id
+- rd : Reset Device
+- td : Test Device Ready
+- rl : Read blocks using LBA
+- wl : Write blocks using LBA
+- wlx: Write partition
+
+To do
+-----
+* Fully support Rockusb protocol
diff --git a/roms/u-boot/doc/README.s5p4418 b/roms/u-boot/doc/README.s5p4418
new file mode 100644
index 000000000..ac724d08a
--- /dev/null
+++ b/roms/u-boot/doc/README.s5p4418
@@ -0,0 +1,63 @@
+
+Summary
+=======
+
+This README is about U-Boot support for SAMSUNG's/NEXELL's ARM Cortex-A9 based
+S5P4418 SoC. It is based on FriendlyARM's U-Boot v2016.01 for the NanoPi2
+(and other) boards [1].
+
+Currently the following boards are supported:
+
+* FriendlyArm NanoPi2 [2]
+* FriendlyArm NanoPC-T2 [3]
+
+
+Build
+=====
+
+* NanoPi2 and NanoPC-T2
+
+make s5p4418_nanopi2_defconfig
+make
+
+
+Installation
+============
+
+- Download Official-ROMs-SDCard-20190718.7z from [4] (images files for android,
+ friendlyCore and LUbuntu)
+- Use s5p4418-sd-lubuntu-desktop-xenial-4.4-armhf-20190718.img to make a SD-card
+- Use dd in the directory where U-Boot has been built to update U-Boot:
+ (replace <SD-card> with the device used for the SD-card, e.g. sdc)
+ sudo dd seek=3841 if=u-boot.bin of=/dev/<SD-card>
+- Boot the board from this SD-card
+
+The source code for (the used?) LUbuntu 16.04 can be found at [5].
+
+
+Links
+=====
+
+[1] FriendlyArm U-boot v2016.01:
+
+https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01
+
+
+[2] NanoPi2:
+
+http://wiki.friendlyarm.com/wiki/index.php/NanoPi_2
+
+
+[3] NanoPC-T2:
+
+http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T2
+
+
+[4] FriendlyArm image files for NanoPi2:
+
+http://download.friendlyarm.com//NanoPi2
+
+
+[5] FriendlyArm LUbuntu 16.04 Source Code for NanoPi2:
+
+https://github.com/friendlyarm/linux/tree/nanopi2-v4.4.y
diff --git a/roms/u-boot/doc/README.s5pc1xx b/roms/u-boot/doc/README.s5pc1xx
new file mode 100644
index 000000000..ab1f02469
--- /dev/null
+++ b/roms/u-boot/doc/README.s5pc1xx
@@ -0,0 +1,72 @@
+
+Summary
+=======
+
+This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx
+family of SoCs (S5PC100 [1] and S5PC110).
+
+Currently the following board is supported:
+
+* SMDKC100 [2]
+
+Toolchain
+=========
+
+While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
+with -march=armv5 to allow more compilers to work. For U-Boot code this has
+no performance impact.
+
+Build
+=====
+
+* SMDKC100
+
+make smdkc100_config
+make
+
+
+Interfaces
+==========
+
+cpu
+
+To check SoC:
+
+ if (cpu_is_s5pc100())
+ printf("cpu is s5pc100\n");
+
+ or
+
+ if (cpu_is_s5pc110())
+ printf("cpu is s5pc110\n");
+
+gpio
+
+ struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE;
+
+ /* GPA[0] pin set to irq */
+ gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ);
+
+ /* GPA[0] pin set to input */
+ gpio_direction_input(&gpio->gpio_a, 0);
+
+ /* GPA[0] pin set to output/high */
+ gpio_direction_output(&gpio->gpio_a, 0, 1);
+
+ /* GPA[0] value set to low */
+ gpio_set_value(&gpio->gpio_a, 0, 0);
+
+ /* get GPA[0] value */
+ value = gpio_get_value(&gpio->gpio_a, 0);
+
+Links
+=====
+
+[1] S5PC100:
+
+http://www.samsung.com/global/business/semiconductor/productInfo.do?
+fmly_id=229&partnum=S5PC100
+
+[2] SMDKC100:
+
+http://meritech.co.kr/eng/products/product_view.php?num=28
diff --git a/roms/u-boot/doc/README.sata b/roms/u-boot/doc/README.sata
new file mode 100644
index 000000000..b1104bbd3
--- /dev/null
+++ b/roms/u-boot/doc/README.sata
@@ -0,0 +1,68 @@
+1. SATA usage in U-Boot
+
+ There are two ways to operate the hard disk
+
+ * Read/write raw blocks from/to SATA hard disk
+ * ext2load to read a file from ext2 file system
+
+1.0 How to read the SATA hard disk's information?
+
+ => sata info
+
+SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN
+ Type: Hard Disk
+ Supports 48-bit addressing
+ Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
+
+1.1 How to raw write the kernel, file system, dtb to a SATA hard disk?
+
+ Notes: Hard disk sectors are normally 512 bytes, so
+ 0x1000 sectors = 2 MBytes
+
+ write kernel
+ => tftp 40000 /tftpboot/uImage.837x
+ => sata write 40000 0 2000
+
+ write ramdisk
+ => tftp 40000 /tftpboot/ramdisk.837x
+ => sata write 40000 2000 8000
+
+ write dtb
+ => tftp 40000 /tftpboot/mpc837xemds.dtb
+ => sata write 40000 a000 1000
+
+1.2 How to raw read the kernel, file system, dtb from a SATA hard disk?
+
+ load kernel
+ => sata read 200000 0 2000
+
+ load ramdisk
+ => sata read 1000000 2000 8000
+
+ load dtb
+ => sata read 2000000 a000 1000
+
+ boot
+ => bootm 200000 1000000 2000000
+
+1.3 How to load an image from an ext2 file system in U-Boot?
+
+ U-Boot doesn't support writing to an ext2 file system, so the
+ files must be written by other means (e.g. linux).
+
+ => ext2ls sata 0:1 /
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 16384 lost+found
+ 1352023 uImage.837x
+ 3646377 ramdisk.837x
+ 12288 mpc837xemds.dtb
+ 12 hello.txt
+
+ => ext2load sata 0:1 200000 /uImage.837x
+
+ => ext2load sata 0:1 1000000 /ramdisk.837x
+
+ => ext2load sata 0:1 2000000 /mpc837xemds.dtb
+
+ => bootm 200000 1000000 2000000
diff --git a/roms/u-boot/doc/README.sched b/roms/u-boot/doc/README.sched
new file mode 100644
index 000000000..3aa89e6d3
--- /dev/null
+++ b/roms/u-boot/doc/README.sched
@@ -0,0 +1,53 @@
+Notes on the scheduler in sched.c:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ 'sched.c' provides an very simplistic multi-threading scheduler.
+ See the example, function 'sched(...)', in the same file for its
+ API usage.
+
+ Until an exhaustive testing can be done, the implementation cannot
+ qualify as that of production quality. It works with the example
+ in 'sched.c', it may or may not work in other cases.
+
+
+Limitations:
+~~~~~~~~~~~~
+
+ - There are NO primitives for thread synchronization (locking,
+ notify etc).
+
+ - Only the GPRs and FPRs context is saved during a thread context
+ switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
+ etc) are NOT saved.
+
+ - The scheduler is NOT transparent to the user. The user
+ applications must invoke thread_yield() to allow other threads to
+ scheduler.
+
+ - There are NO priorities, and the scheduling policy is round-robin
+ based.
+
+ - There are NO capabilities to collect thread CPU usage, scheduler
+ stats, thread status etc.
+
+ - The semantics are somewhat based on those of pthreads, but NOT
+ the same.
+
+ - Only seven threads are allowed. These can be easily increased by
+ changing "#define MAX_THREADS" depending on the available memory.
+
+ - The stack size of each thread is 8KBytes. This can be easily
+ increased depending on the requirement and the available memory,
+ by increasing "#define STK_SIZE".
+
+ - Only one master/parent thread is allowed, and it cannot be
+ stopped or deleted. Any given thread is NOT allowed to stop or
+ delete itself.
+
+ - There NOT enough safety checks as are probably in the other
+ threads implementations.
+
+ - There is no parent-child relationship between threads. Only one
+ thread may thread_join, preferably the master/parent thread.
+
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
diff --git a/roms/u-boot/doc/README.scrapyard b/roms/u-boot/doc/README.scrapyard
new file mode 100644
index 000000000..24a6c1be1
--- /dev/null
+++ b/roms/u-boot/doc/README.scrapyard
@@ -0,0 +1,11 @@
+Over time, support for more and more boards gets added to U-Boot -
+while other board support code dies a silent death caused by
+negligence in combination with ordinary bitrot. Sometimes this goes
+by unnoticed, but often build errors will result. If nobody cares any
+more to resolve such problems, then the code is really dead and will
+be removed from the U-Boot source tree. The remainders rest in peace
+in the imperishable depths of the git history. Please use the tools
+git provides to read through this history. A common example would be:
+$ git log -p --follow -- board/technexion/twister
+to see the history and changes made to the Technexion "twister" board
+from introduction to removal.
diff --git a/roms/u-boot/doc/README.semihosting b/roms/u-boot/doc/README.semihosting
new file mode 100644
index 000000000..c019999be
--- /dev/null
+++ b/roms/u-boot/doc/README.semihosting
@@ -0,0 +1,38 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2014 Broadcom Corporation.
+ */
+
+Semihosting is ARM's way of having a real or virtual target communicate
+with a host or host debugger for basic operations such as file I/O,
+console I/O, etc. Please see
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Bgbjjgij.html for more information.
+
+For developing on armv8 virtual fastmodel platforms, semihosting is a
+valuable tool since it allows access to image/configuration files before
+eMMC or other NV media are available.
+
+There are two main ARM virtual Fixed Virtual Platform (FVP) models,
+Versatile Express (VE) FVP and BASE FVP (See
+http://www.arm.com/products/tools/models/fast-models/foundation-model.php)
+The initial vexpress64 u-boot board created here runs on the VE virtual
+platform using the license-free Foundation_v8 simulator. Fortunately,
+the Foundation_v8 simulator also supports the BASE_FVP model which
+companies can purchase licenses for and contain much more functionality.
+So we can, in u-boot, run either model by either using the VE FVP (default),
+or turning on CONFIG_BASE_FVP for the more full featured model.
+
+Rather than create a new armv8 board similar to armltd/vexpress64, add
+semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING
+and CONFIG_BASE_FVP both set. Also reuse the existing board config file
+vexpress_aemv8a.h but differentiate the two models by the presence or
+absence of CONFIG_BASE_FVP. This change is tested and works on both the
+Foundation and Base fastmodel simulators.
+
+The semihosting code adds a command:
+
+ smhload <image> <address> [env var]
+
+That will load an image from the host filesystem into RAM at the specified
+address and optionally store the load end address in the specified
+environment variable.
diff --git a/roms/u-boot/doc/README.serial_multi b/roms/u-boot/doc/README.serial_multi
new file mode 100644
index 000000000..c9049fd01
--- /dev/null
+++ b/roms/u-boot/doc/README.serial_multi
@@ -0,0 +1,54 @@
+The support for multiple serial interfaces as implemented is mainly
+intended to allow for modem dial-in / dial-out while still being able
+to use a serial console on a (different) serial port.
+
+MPC8XX Specific
+===============
+At the moment, the ports must be split on a SMC and a SCC port on a
+8xx processor; other configurations are not (yet) supported.
+
+Support for hardware handshake has not been implemented yet (but is
+in the works).
+
+*) The default console depends on the keys pressed:
+ - SMC if keys not pressed (modem not enabled)
+ - SCC if keys pressed (modem enabled)
+
+*) The console can be switched to SCC by any of the following commands:
+
+ setenv stdout serial_scc
+ setenv stdin serial_scc
+ setenv stderr serial_scc
+
+*) The console can be switched to SMC by any of the following commands:
+
+ setenv stdout serial_smc
+ setenv stdin serial_smc
+ setenv stderr serial_smc
+
+*) If a file descriptor is set to "serial" then the current serial device
+will be used which, in turn, can be switched by above commands.
+
+*) The baudrate is the same for all serial devices. But it can be switched
+just after switching the console:
+
+ setenv sout serial_scc; setenv baudrate 38400
+
+After that press 'enter' at the SCC console. Note that baudrates <38400
+are not allowed on LWMON with watchdog enabled (see CONFIG_SYS_BAUDRATE_TABLE in
+include/configs/lwmon.h).
+
+
+PPC4XX Specific
+===============
+*) The default console is UART0
+
+*) The console can be switched to UART1 by any of the following commands:
+ setenv stdout serial1
+ setenv stderr serial1
+ setenv stdin serial1
+
+*) The console can be switched to UART0 by any of the following commands:
+ setenv stdout serial0
+ setenv stderr serial0
+ setenv stdin serial0
diff --git a/roms/u-boot/doc/README.sha1 b/roms/u-boot/doc/README.sha1
new file mode 100644
index 000000000..f178f3726
--- /dev/null
+++ b/roms/u-boot/doc/README.sha1
@@ -0,0 +1,58 @@
+SHA1 usage:
+-----------
+
+In the U-Boot Image for the pcs440ep board is a SHA1 checksum integrated.
+This SHA1 sum is used, to check, if the U-Boot Image in Flash is not
+corrupted.
+
+The following command is available:
+
+=> help sha1
+sha1 address len [addr] calculate the SHA1 sum [save at addr]
+ -p calculate the SHA1 sum from the U-Boot image in flash and print
+ -c check the U-Boot image in flash
+
+"sha1 -p"
+ calculates and prints the SHA1 sum, from the Image stored in Flash
+
+"sha1 -c"
+ check, if the SHA1 sum from the Image stored in Flash is correct
+
+
+It is possible to calculate a SHA1 checksum from a memoryrange with:
+
+"sha1 address len"
+
+If you want to store a new Image in Flash for the pcs440ep board,
+which has no SHA1 sum, you can do the following:
+
+a) cp the new Image on a position in RAM (here 0x300000)
+ (for this example we use the Image from Flash, stored at 0xfffa0000 and
+ 0x60000 Bytes long)
+
+"cp.b fffa0000 300000 60000"
+
+b) Initialize the SHA1 sum in the Image with 0x00
+ The SHA1 sum is stored in Flash at:
+ CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN + SHA1_SUM_POS
+ for the pcs440ep Flash: 0xfffa0000 + 0x60000 + -0x20
+ = 0xffffffe0
+ for the example in RAM: 0x300000 + 0x60000 + -0x20
+ = 0x35ffe0
+
+ note: a SHA1 checksum is 20 bytes long.
+
+"mw.b 35ffe0 0 14"
+
+c) now calculate the SHA1 sum from the memoryrange and write
+ the calculated checksum at the right place:
+
+"sha1 300000 60000 35ffe0"
+
+Now you have a U-Boot-Image for the pcs440ep board with the correct SHA1 sum.
+
+If you do a "buildman -k pcs440ep" or a "make all" to get the U-Boot image,
+which will be found in ../current/ipam390/ - the correct SHA1 sum will be
+automagically included in the U-Boot image.
+
+Heiko Schocher, 11 Jul 2007
diff --git a/roms/u-boot/doc/README.silent b/roms/u-boot/doc/README.silent
new file mode 100644
index 000000000..00288e03b
--- /dev/null
+++ b/roms/u-boot/doc/README.silent
@@ -0,0 +1,28 @@
+The config option CONFIG_SILENT_CONSOLE can be used to quiet messages
+on the console. If the option has been enabled, the output can be
+silenced by setting the environment variable "silent".
+
+- CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
+ When the "silent" variable is changed with env set, the change
+ will take effect immediately.
+
+- CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC
+ Some environments are not available until relocation (e.g. NAND)
+ so this will make the value in the flash env take effect at
+ relocation.
+
+The following actions are taken if "silent" is set at boot time:
+
+ - Until the console devices have been initialized, output has to be
+ suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags".
+
+ - When the console devices have been initialized, "stdout" and
+ "stderr" are set to "nulldev", so subsequent messages are
+ suppressed automatically. Make sure to enable "nulldev" by
+ enabling CONFIG_SYS_DEVICE_NULLDEV in your board defconfig file.
+
+ - When booting a linux kernel, the "bootargs" are fixed up so that
+ the argument "console=" will be in the command line, no matter how
+ it was set in "bootargs" before. If you don't want the linux command
+ line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board
+ config file as well, and this part of the feature will be disabled.
diff --git a/roms/u-boot/doc/README.socfpga b/roms/u-boot/doc/README.socfpga
new file mode 100644
index 000000000..4d73398eb
--- /dev/null
+++ b/roms/u-boot/doc/README.socfpga
@@ -0,0 +1,178 @@
+----------------------------------------
+SOCFPGA Documentation for U-Boot and SPL
+----------------------------------------
+
+This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore
+based SOCFPGA. To know more about the hardware itself, please refer to
+www.altera.com.
+
+
+socfpga_dw_mmc
+--------------
+
+Here are macro and detailed configuration required to enable DesignWare SDMMC
+controller support within SOCFPGA
+
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT 256
+-> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM
+
+---------------------------------------------------------------------
+Cyclone 5 / Arria 5 generating the handoff header files for U-Boot SPL
+---------------------------------------------------------------------
+
+This text is assuming quartus 16.1, but newer versions will probably work just fine too;
+verified with DE1_SOC_Linux_FB demo project (https://github.com/VCTLabs/DE1_SOC_Linux_FB).
+Updated/working projects should build using either process below.
+
+Note: it *should* work from Quartus 14.0.200 onwards, however, the current vendor demo
+projects must have the IP cores updated as shown below.
+
+Rebuilding your Quartus project
+-------------------------------
+
+Choose one of the follwing methods, either command line or GUI.
+
+Using the command line
+~~~~~~~~~~~~~~~~~~~~~~
+
+First run the embedded command shell, using your path to the Quartus install:
+
+ $ /path/to/intelFPGA/16.1/embedded/embedded_command_shell.sh
+
+Then (if necessary) update the IP cores in the project, generate HDL code, and
+build the project:
+
+ $ cd path/to/project/dir
+ $ qsys-generate soc_system.qsys --upgrade-ip-cores
+ $ qsys-generate soc_system.qsys --synthesis=[VERILOG|VHDL]
+ $ quartus_sh --flow compile <project name>
+
+Convert the resulting .sof file (SRAM object file) to .rbf file (Raw bit file):
+
+ $ quartus_cpf -c <project_name>.sof soc_system.rbf
+
+
+Generate BSP handoff files
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can run the bsp editor GUI below, or run the following command from the
+project directory:
+
+ $ /path/to/bsb/tools/bsp-create-settings --type spl --bsp-dir build \
+ --preloader-settings-dir hps_isw_handoff/soc_system_hps_0/ \
+ --settings build/settings.bsp
+
+You should use the bsp "build" directory above (ie, where the settings.bsp file is)
+in the following u-boot command to update the board headers. Once these headers
+are updated for a given project build, u-boot should be configured for the
+project board (eg, de0-nano-sockit) and then build the normal spl build.
+
+Now you can skip the GUI section.
+
+
+Using the Qsys GUI
+~~~~~~~~~~~~~~~~~~
+
+1. Navigate to your project directory
+2. Run Quartus II
+3. Open Project (Ctrl+J), select <project_name>.qpf
+4. Run QSys [Tools->QSys]
+ 4.1 In the Open dialog, select '<project_name>.qsys'
+ 4.2 In the Open System dialog, wait until completion and press 'Close'
+ 4.3 In the Qsys window, click on 'Generate HDL...' in bottom right corner
+ 4.3.1 In the 'Generation' window, click 'Generate'
+ 4.3.2 In the 'Generate' dialog, wait until completion and click 'Close'
+ 4.4 In the QSys window, click 'Finish'
+ 4.4.1 In the 'Quartus II' pop up window, click 'OK'
+5. Back in Quartus II main window, do the following
+ 5.1 Use Processing -> Start -> Start Analysis & Synthesis (Ctrl+K)
+ 5.2 Use Processing -> Start Compilation (Ctrl+L)
+
+ ... this may take some time, have patience ...
+
+6. Start the embedded command shell as shown in the previous section
+ 6.1 Change directory to 'software/spl_bsp'
+ 6.2 Prepare BSP by launching the BSP editor from ECS
+ => bsp-editor
+ 6.3 In BSP editor
+ 6.3.1 Use File -> Open
+ 6.3.2 Select 'settings.bsp' file
+ 6.3.3 Click Generate
+ 6.3.4 Click Exit
+
+
+Post handoff generation
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that the handoff files are generated, U-Boot can be used to process
+the handoff files generated by the bsp-editor. For this, please use the
+following script from the u-boot source tree:
+
+ $ ./arch/arm/mach-socfpga/qts-filter.sh \
+ <soc_type> \
+ <input_qts_dir> \
+ <input_bsp_dir> \
+ <output_dir>
+
+Process QTS-generated files into U-Boot compatible ones.
+
+ soc_type - Type of SoC, either 'cyclone5' or 'arria5'.
+ input_qts_dir - Directory with compiled Quartus project
+ and containing the Quartus project file (QPF).
+ input_bsp_dir - Directory with generated bsp containing
+ the settings.bsp file.
+ output_dir - Directory to store the U-Boot compatible
+ headers.
+
+This will generate (or update) the following 4 files:
+
+ iocsr_config.h
+ pinmux_config.h
+ pll_config.h
+ sdram_config.h
+
+These files should be copied into "qts" directory in the board directory
+(see output argument of qts-filter.sh command above).
+
+Here is an example for the DE-0 Nano SoC after the above rebuild process:
+
+ $ ll board/terasic/de0-nano-soc/qts/
+ total 36
+ -rw-r--r-- 1 sarnold sarnold 8826 Mar 21 18:11 iocsr_config.h
+ -rw-r--r-- 1 sarnold sarnold 4398 Mar 21 18:11 pinmux_config.h
+ -rw-r--r-- 1 sarnold sarnold 3190 Mar 21 18:11 pll_config.h
+ -rw-r--r-- 1 sarnold sarnold 9022 Mar 21 18:11 sdram_config.h
+
+Note: file sizes will differ slightly depending on the selected board.
+
+Now your board is ready for full mainline support including U-Boot SPL.
+The Preloader will not be needed any more.
+
+----------------------------------------------------------
+Arria 10 generating the handoff header files for U-Boot SPL
+----------------------------------------------------------
+
+A header file for inclusion in a devicetree for Arria10 can be generated
+by the qts-filter-a10.sh script directly from the hps_isw_handoff/hps.xml
+file generated during the FPGA project compilation. The header contains
+all PLL, clock, pinmux, and bridge configurations required.
+
+Please look at the socfpga_arria10_socdk_sdmmc-u-boot.dtsi for an example
+that includes use of the generated handoff header.
+
+Devicetree header generation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The qts-filter-a10.sh script can process the compile time genetated hps.xml
+to create the appropriate devicetree header.
+
+
+ $ ./arch/arm/mach-socfpga/qts-filter-a10.sh \
+ <hps_xml> \
+ <output_file>
+
+ hps_xml - hps_isw_handoff/hps.xml from Quartus project
+ output_file - Output filename and location for header file
+
+The script generates a single header file names <output_file> that should
+be placed in arch/arm/dts.
diff --git a/roms/u-boot/doc/README.spear b/roms/u-boot/doc/README.spear
new file mode 100644
index 000000000..0789b3fd2
--- /dev/null
+++ b/roms/u-boot/doc/README.spear
@@ -0,0 +1,74 @@
+
+SPEAr (Structured Processor Enhanced Architecture).
+
+SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic
+
+The SPEAr SoC family embeds a customizable logic that can be programmed
+one-time by a customer at silicon mask level (i.e. not at runtime!).
+
+U-Boot supports four SoCs: SPEAr600, SPEAr3xx
+
+All 4 SoCs (SPEAr3xx and SPEAr600) share common peripherals. SPEAr300 and
+SPEAr600 do not have EMI.
+
+1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux)
+2. FastEthernet (sp600 has Gbit version, but same controller - GMAC)
+3. USB Host
+4. USB Device
+5. NAND controller (FSMC)
+6. Serial NOR ctrl
+7. I2C
+8. SPI
+9. CLCD
+10. others ..
+
+Everything is supported in Linux.
+u-boot is currently not supporting all peripeharls (just a few as listed below).
+1. USB Device
+2. NAND controller (FSMC)
+3. Serial Memory Interface
+4. EMI (Parallel NOR interface)
+4. I2C
+5. UART
+
+Build options
+ make spear320_config
+ spear320 build with environment variables placed at default
+ location i.e. Serial NOR device
+ make spear320_pnor_config
+ This option generates a uboot image that supports emi controller
+ for CFI compliant parallel NOR flash. Environment variables are
+ placed in Parallel NOR device
+ make spear320_nand_config
+ spear320 build with environment variables placed in NAND device
+ make spear320_usbtty_config
+ spear320 build with usbtty terminal as default and environment
+ placed at default location
+ make spear320_usbtty_pnor_config
+ spear320 build with usbtty terminal as default and environment
+ placed in pnor device
+ make spear320_usbtty_nand_config
+ Build with usbtty terminal as default and environment placed in
+ NAND device
+ make spear300_config
+ make spear300_nand_config
+ make spear300_usbtty_config
+ make spear300_usbtty_nand_config
+ make spear310_config
+ make spear310_pnor_config
+ make spear310_nand_config
+ make spear310_usbtty_config
+ make spear310_usbtty_pnor_config
+ make spear310_usbtty_nand_config
+ make spear600_config
+ make spear600_nand_config
+ make spear600_usbtty_config
+ make spear600_usbtty_nand_config
+
+Mac id storage and retrieval in spear platforms
+
+Please read doc/README.enetaddr for the implementation guidelines for mac id
+usage. Basically, environment has precedence over board specific storage. The
+ethaddr beeing used for the network interface is always taken only from
+environment variables. Although, we can check the mac id programmed in i2c
+memory by using chip_config command
diff --git a/roms/u-boot/doc/README.splashprepare b/roms/u-boot/doc/README.splashprepare
new file mode 100644
index 000000000..3cb5b5aeb
--- /dev/null
+++ b/roms/u-boot/doc/README.splashprepare
@@ -0,0 +1,34 @@
+---------------------------------------------------------------------
+Splash Screen
+---------------------------------------------------------------------
+The splash_screen_prepare() function is a weak function defined in
+common/splash.c. It is called as part of the splash screen display
+sequence. It gives the board an opportunity to prepare the splash
+image data before it is processed and sent to the frame buffer by
+U-Boot. Define your own version to use this feature.
+
+CONFIG_SPLASH_SOURCE
+
+Use the splash_source.c library. This library provides facilities to declare
+board specific splash image locations, routines for loading splash image from
+supported locations, and a way of controlling the selected splash location
+using the "splashsource" environment variable.
+
+splashsource works as follows:
+- If splashsource is set to a supported location name as defined by board code,
+ use that splash location.
+- If splashsource is undefined, use the first splash location as default.
+- If splashsource is set to an unsupported value, do not load a splash screen.
+
+A splash source location can describe either storage with raw data, a storage
+formatted with a file system or a FIT image. In case of a filesystem, the splash
+screen data is loaded as a file. The name of the splash screen file can be
+controlled with the environment variable "splashfile".
+
+To enable loading the splash image from a FIT image, CONFIG_FIT must be
+enabled. The FIT image has to start at the 'offset' field address in the
+selected splash location. The name of splash image within the FIT shall be
+specified by the environment variable "splashfile".
+
+In case the environment variable "splashfile" is not defined the default name
+'splash.bmp' will be used.
diff --git a/roms/u-boot/doc/README.srio-pcie-boot-corenet b/roms/u-boot/doc/README.srio-pcie-boot-corenet
new file mode 100644
index 000000000..2b1f76b8d
--- /dev/null
+++ b/roms/u-boot/doc/README.srio-pcie-boot-corenet
@@ -0,0 +1,118 @@
+---------------------------------------
+SRIO and PCIE Boot on Corenet Platforms
+---------------------------------------
+
+For some PowerPC processors with SRIO or PCIE interface, boot location can be
+configured to SRIO or PCIE by RCW. The processor booting from SRIO or PCIE can
+do without flash for u-boot image, ucode and ENV. All the images can be fetched
+from another processor's memory space by SRIO or PCIE link connected between
+them.
+
+This document describes the processes based on an example implemented on P4080DS
+platforms and a RCW example with boot from SRIO or PCIE configuration.
+
+Environment of the SRIO or PCIE boot:
+ a) Master and slave can be SOCs in one board or SOCs in separate boards.
+ b) They are connected with SRIO or PCIE links, whether 1x, 2x or 4x, and
+ directly or through switch system.
+ c) Only Master has NorFlash for booting, and all the Master's and Slave's
+ U-Boot images, UCodes will be stored in this flash.
+ d) Slave has its own EEPROM for RCW and PBI.
+ e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set
+ the boot location to SRIO or PCIE, and holdoff all the cores.
+
+ ----------- ----------- -----------
+ | | | | | |
+ | | | | | |
+ | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM]
+ | | | |<===========>| |
+ | | | | | |
+ ----------- ----------- -----------
+
+The example based on P4080DS platform:
+ Two P4080DS platforms can be used to implement the boot from SRIO or PCIE.
+ Their SRIO or PCIE ports 1 will be connected directly and will be used for
+ the boot from SRIO or PCIE.
+
+ 1. Slave's RCW example for boot from SRIO port 1 and all cores in holdoff.
+ 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
+ 00000010: 1818 1818 0000 8888 7440 4000 0000 2000
+ 00000020: f440 0000 0100 0000 0000 0000 0000 0000
+ 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
+ 00000040: 0000 0000 0000 0000 0813 8040 063c 778f
+
+ 2. Slave's RCW example for boot from PCIE port 1 and all cores in holdoff.
+ 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
+ 00000010: 1818 1818 0000 8888 1440 4000 0000 2000
+ 00000020: f040 0000 0100 0000 0020 0000 0000 0000
+ 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
+ 00000040: 0000 0000 0000 0000 0813 8040 547e ffc9
+
+ 3. Sequence in Step by Step.
+ a) Update RCW for slave with boot from SRIO or PCIE port 1 configuration.
+ b) Program slave's U-Boot image, UCode, and ENV parameters into master's
+ NorFlash.
+ c) Set environment variable "bootmaster" to "SRIO1" or "PCIE1" and save
+ environment for master.
+ setenv bootmaster SRIO1
+ or
+ setenv bootmaster PCIE1
+ saveenv
+ d) Restart up master and it will boot up normally from its NorFlash.
+ Then, it will finish necessary configurations for slave's boot from
+ SRIO or PCIE port 1.
+ e) Master will set inbound SRIO or PCIE windows covered slave's U-Boot
+ image stored in master's NorFlash.
+ f) Master will set an inbound SRIO or PCIE window covered slave's UCode
+ and ENV stored in master's NorFlash.
+ g) Master will set outbound SRIO or PCIE windows in order to configure
+ slave's registers for the core's releasing.
+ h) Since all cores of slave in holdoff, slave should be powered on before
+ all the above master's steps, and wait to be released by master. In the
+ startup phase of the slave from SRIO or PCIE, it will finish some
+ necessary configurations.
+ i) Slave will set a specific TLB entry for the boot process.
+ j) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
+ the boot.
+ k) Slave will set a specific TLB entry in order to fetch UCode and ENV
+ from master.
+ l) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
+ UCode and ENV.
+
+How to use this feature:
+ To use this feature, you need to focus those points.
+
+ 1. Slave's RCW with SRIO or PCIE boot configurations, and all cores in holdoff
+ configurations.
+ Please refer to the examples given above.
+
+ 2. U-Boot image's compilation.
+ For master, U-Boot image should be generated normally.
+
+ For example, master U-Boot image used on P4080DS should be compiled with
+
+ make P4080DS_config.
+
+ For slave, U-Boot image should be generated specifically by
+
+ make xxxx_SRIO_PCIE_BOOT_config.
+
+ For example, slave U-Boot image used on P4080DS should be compiled with
+
+ make P4080DS_SRIO_PCIE_BOOT_config.
+
+ 3. Necessary modifications based on a specific environment.
+ For a specific environment, the addresses of the slave's U-Boot image,
+ UCode, ENV stored in master's NorFlash, and any other configurations
+ can be modified in the file:
+ include/configs/corenet_ds.h.
+
+ 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2"
+ or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to
+ perform the role as a master for boot from SRIO or PCIE.
+
+NOTE: When the Slave's ENV parameters are stored in Master's NorFlash,
+ it can fetch them through PCIE or SRIO interface. But the ENV
+ parameters can not be modified by "saveenv" or other commands under
+ the Slave's u-boot environment, because the Slave can not erase,
+ write Master's NorFlash by PCIE or SRIO link.
diff --git a/roms/u-boot/doc/README.standalone b/roms/u-boot/doc/README.standalone
new file mode 100644
index 000000000..874ca2f7c
--- /dev/null
+++ b/roms/u-boot/doc/README.standalone
@@ -0,0 +1,120 @@
+Design Notes on Exporting U-Boot Functions to Standalone Applications:
+======================================================================
+
+1. The functions are exported by U-Boot via a jump table. The jump
+ table is allocated and initialized in the jumptable_init() routine
+ (common/exports.c). Other routines may also modify the jump table,
+ however. The jump table can be accessed as the 'jt' field of the
+ 'global_data' structure. The struct members for the jump table are
+ defined in the <include/exports.h> header. E.g., to substitute the
+ malloc() and free() functions that will be available to standalone
+ applications, one should do the following:
+
+ DECLARE_GLOBAL_DATA_PTR;
+
+ gd->jt->malloc = my_malloc;
+ gd->jt->free = my_free;
+
+ Note that the pointers to the functions are real function pointers
+ so the compiler can perform type checks on these assignments.
+
+2. The pointer to the jump table is passed to the application in a
+ machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II
+ architectures use a dedicated register to hold the pointer to the
+ 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS,
+ P3 on Blackfin and gp on Nios II. The x86 architecture does not
+ use such a register; instead, the pointer to the 'global_data'
+ structure is passed as 'argv[-1]' pointer.
+
+ The application can access the 'global_data' structure in the same
+ way as U-Boot does:
+
+ DECLARE_GLOBAL_DATA_PTR;
+
+ printf("U-Boot relocation offset: %x\n", gd->reloc_off);
+
+3. The application should call the app_startup() function before any
+ call to the exported functions. Also, implementor of the
+ application may want to check the version of the ABI provided by
+ U-Boot. To facilitate this, a get_version() function is exported
+ that returns the ABI version of the running U-Boot. I.e., a
+ typical application startup may look like this:
+
+ int my_app (int argc, char *const argv[])
+ {
+ app_startup (argv);
+ if (get_version () != XF_VERSION)
+ return 1;
+ }
+
+4. The default load and start addresses of the applications are as
+ follows:
+
+ Load address Start address
+ x86 0x00040000 0x00040000
+ PowerPC 0x00040000 0x00040004
+ ARM 0x0c100000 0x0c100000
+ MIPS 0x80200000 0x80200000
+ Blackfin 0x00001000 0x00001000
+ NDS32 0x00300000 0x00300000
+ Nios II 0x02000000 0x02000000
+ RISC-V 0x00600000 0x00600000
+
+ For example, the "hello world" application may be loaded and
+ executed on a PowerPC board with the following commands:
+
+ => tftp 0x40000 hello_world.bin
+ => go 0x40004
+
+5. To export some additional function long foobar(int i,char c), the following steps
+ should be undertaken:
+
+ - Append the following line at the end of the include/_exports.h
+ file:
+
+ EXPORT_FUNC(foobar, long, foobar, int, char)
+
+ Parameters to EXPORT_FUNC:
+ - the first parameter is the function that is exported (default implementation)
+ - the second parameter is the return value type
+ - the third parameter is the name of the member in struct jt_funcs
+ this is also the name that the standalone application will used.
+ the rest of the parameters are the function arguments
+
+ - Add the prototype for this function to the include/exports.h
+ file:
+
+ long foobar(int i, char c);
+
+ Initialization with the default implementation is done in jumptable_init()
+
+ You can override the default implementation using:
+
+ gd->jt->foobar = another_foobar;
+
+ The signature of another_foobar must then match the declaration of foobar.
+
+ - Increase the XF_VERSION value by one in the include/exports.h
+ file
+
+ - If you want to export a function which depends on a CONFIG_XXX
+ use 2 lines like this:
+ #ifdef CONFIG_FOOBAR
+ EXPORT_FUNC(foobar, long, foobar, int, char)
+ #else
+ EXPORT_FUNC(dummy, void, foobar, void)
+ #endif
+
+
+6. The code for exporting the U-Boot functions to applications is
+ mostly machine-independent. The only places written in assembly
+ language are stub functions that perform the jump through the jump
+ table. That said, to port this code to a new architecture, the
+ only thing to be provided is the code in the examples/stubs.c
+ file. If this architecture, however, uses some uncommon method of
+ passing the 'global_data' pointer (like x86 does), one should add
+ the respective code to the app_startup() function in that file.
+
+ Note that these functions may only use call-clobbered registers;
+ those registers that are used to pass the function's arguments,
+ the stack contents and the return address should be left intact.
diff --git a/roms/u-boot/doc/README.t1040-l2switch b/roms/u-boot/doc/README.t1040-l2switch
new file mode 100644
index 000000000..6f03de239
--- /dev/null
+++ b/roms/u-boot/doc/README.t1040-l2switch
@@ -0,0 +1,63 @@
+This file contains information for VSC9953, a Vitesse L2 Switch IP
+which is integrated in the T1040/T1020 Freescale SoCs.
+
+About Device:
+=============
+VSC9953 is an 8-port Gigabit Ethernet switch supports the following features:
+ - 8192 MAC addresses
+ - Static Address provisioning
+ - Dynamic learning of MAC addresses and aging
+ - 4096 VLANs
+ - Independent and shared VLAN learning (IVL, SVL)
+ - Policing with storm control and MC/BC protection
+ - IPv4 and IPv6 multicast
+ - Jumbo frames (9.6 KB)
+ - Access Control List
+ - VLAN editing, translation and remarking
+ - RMON counters per port
+
+Switch interfaces:
+ - 8 Gigabit switch ports (ports 0 to 7) are external and are connected to external PHYs
+ - 2 switch ports (ports 8 and 9) of 2.5 G are connected (fixed links)
+ to FMan ports (FM1@DTSEC1 and FM1@DTSEC2)
+
+Commands Overview:
+=============
+Commands supported
+ - enable/disable a port or show its configuration (speed, duplexity, status, etc.)
+ - port statistics
+ - MAC learning
+ - add/remove FDB entries
+ - Port-based VLAN
+ - Private/Shared VLAN learning
+ - VLAN ingress filtering
+ - Port LAG
+
+Commands syntax
+ethsw [port <port_no>] { enable | disable | show } - enable/disable a port; show a port's configuration
+ethsw [port <port_no>] statistics { [help] | [clear] } - show an l2 switch port's statistics
+ethsw [port <port_no>] learning { [help] | show | auto | disable } - enable/disable/show learning configuration on a port
+ethsw [port <port_no>] [vlan <vid>] fdb { [help] | show | flush | { add | del } <mac> } - add/delete a mac entry in FDB; use show to see FDB entries;
+ if [vlan <vid>] is missing, VID 1 will be used
+ethsw [port <port_no>] pvid { [help] | show | <pvid> } - set/show PVID (ingress and egress VLAN tagging) for a port
+ethsw [port <port_no>] vlan { [help] | show | add <vid> | del <vid> } - add a VLAN to a port (VLAN members)
+ethsw [port <port_no>] untagged { [help] | show | all | none | pvid } - set egress tagging mode for a port
+ethsw [port <port_no>] egress tag { [help] | show | pvid | classified } - configure VID source for egress tag.
+ Tag's VID could be the frame's classified VID or the PVID of the port
+ethsw vlan fdb { [help] | show | shared | private } - make VLAN learning shared or private
+ethsw [port <port_no>] ingress filtering { [help] | show | enable | disable } - enable/disable VLAN ingress filtering on port
+ethsw [port <port_no>] aggr { [help] | show | <lag_group_no> } - get/set LAG group for a port
+
+=> ethsw show
+ Port Status Link Speed Duplex
+ 0 enabled down 10 half
+ 1 enabled down 10 half
+ 2 enabled down 10 half
+ 3 enabled up 1000 full
+ 4 disabled down - half
+ 5 disabled down - half
+ 6 disabled down - half
+ 7 disabled down - half
+ 8 enabled up 2500 full
+ 9 enabled up 2500 full
+=>
diff --git a/roms/u-boot/doc/README.tee b/roms/u-boot/doc/README.tee
new file mode 100644
index 000000000..79e7996a6
--- /dev/null
+++ b/roms/u-boot/doc/README.tee
@@ -0,0 +1,112 @@
+=============
+TEE uclass
+=============
+
+This document describes the TEE uclass in U-Boot
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This uclass deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between U-Boot and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=================
+
+include/tee.h defines the generic interface to a TEE.
+
+A client finds the TEE device via tee_find_device(). Other important functions
+when interfacing with a TEE are:
+
+- tee_shm_alloc(), tee_shm_register() and tee_shm_free() to manage shared
+ memory objects often needed when communicating with the TEE.
+
+- tee_get_version() lets the client know which the capabilities of the TEE
+ device.
+
+- tee_open_session() opens a session to a Trusted Application
+
+- tee_invoke_func() invokes a function in a Trusted Application
+
+- tee_close_session() closes a session to a Trusted Application
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results.
+
+OP-TEE driver
+=============
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+ which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+ to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+ separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+ range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture:
+
+ U-Boot Secure world
+ ~~~~~~ ~~~~~~~~~~~~
+ +------------+ +-------------+
+ | Client | | Trusted |
+ | | | Application |
+ +------------+ +-------------+
+ /\ /\
+ || ||
+ \/ \/
+ +------------+ +-------------+
+ | TEE | | TEE Internal|
+ | uclass | | API |
+ +------------+ +-------------+
+ | OP-TEE | | OP-TEE |
+ | driver | | Trusted OS |
+ +------------+-----------+-------------+
+ | OP-TEE MSG |
+ | SMCCC (OPTEE_SMC_CALL_*) |
+ +--------------------------------------+
+
+RPC (Remote Procedure Call) are requests from secure world to the driver.
+An RPC is identified by a special range of SMCCC return values from
+OPTEE_SMC_CALL_WITH_ARG.
+
+References
+==========
+
+[1] https://github.com/OP-TEE/optee_os
+
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+
+[3] drivers/tee/optee/optee_smc.h
+
+[4] drivers/tee/optee/optee_msg.h
+
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+ "TEE Client API Specification v1.0" and click download.
diff --git a/roms/u-boot/doc/README.ti-secure b/roms/u-boot/doc/README.ti-secure
new file mode 100644
index 000000000..27c0eaa77
--- /dev/null
+++ b/roms/u-boot/doc/README.ti-secure
@@ -0,0 +1,226 @@
+README on how boot images are created for secure TI devices
+
+CONFIG_TI_SECURE_DEVICE:
+Secure TI devices require a boot image that is authenticated by ROM
+code to function. Without this, even JTAG remains locked and the
+device is essentially useless. In order to create a valid boot image for
+a secure device from TI, the initial public software image must be signed
+and combined with various headers, certificates, and other binary images.
+
+Information on the details on the complete boot image format can be obtained
+from Texas Instruments. The tools used to generate boot images for secure
+devices are part of a secure development package (SECDEV) that can be
+downloaded from:
+
+ http://www.ti.com/mysecuresoftware (login required)
+
+The secure development package is access controlled due to NDA and export
+control restrictions. Access must be requested and granted by TI before the
+package is viewable and downloadable. Contact TI, either online or by way
+of a local TI representative, to request access.
+
+Booting of U-Boot SPL
+=====================
+
+ When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process
+ requires the presence and use of these tools in order to create a
+ viable boot image. The build process will look for the environment
+ variable TI_SECURE_DEV_PKG, which should be the path of the installed
+ SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or
+ if it is defined but doesn't point to a valid SECDEV package, a
+ warning is issued during the build to indicate that a final secure
+ bootable image was not created.
+
+ Within the SECDEV package exists an image creation script:
+
+ ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+ This is called as part of the SPL/u-boot build process. As the secure
+ boot image formats and requirements differ between secure SOC from TI,
+ the purpose of this script is to abstract these details as much as
+ possible.
+
+ The script is basically the only required interface to the TI SECDEV
+ package for creating a bootable SPL image for secure TI devices.
+
+ Invoking the script for AM33xx Secure Devices
+ =============================================
+
+ create-boot-image.sh \
+ <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+ <IMAGE_FLAG> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
+ X-LOADER - Generates an image for non-XIP flash
+ MLO - Generates an image for SD/MMC/eMMC media
+ 2ND - Generates an image for USB, UART and Ethernet
+ XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loaderbinary file (depending on the boot media, this is usually
+ either u-boot-spl.bin or u-boot.bin).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure
+ image. The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides and
+ releases notes for how the non-secure images are typically used)
+ u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+ u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode
+ u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media
+ u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet
+ u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash
+
+ <SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+ <INPUT_FILE>
+
+ Invoking the script for AM43xx Secure Devices
+ =============================================
+
+ create-boot-image.sh \
+ <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+ <IMAGE_FLAG> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ SPI_X-LOADER - Generates an image for SPI flash (byte
+ swapped)
+ XIP_X-LOADER - Generates a single stage u-boot for
+ NOR/QSPI XiP
+ ISSW - Generates an image for all other boot modes
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loaderbinary file (depending on the boot media, this is usually
+ either u-boot-spl.bin or u-boot.bin).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure
+ image. The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides and
+ releases notes for how the non-secure images are typically used)
+ u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+ u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
+ u-boot-spl_HS_ISSW - boot image for all other boot media
+
+ <SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+ <INPUT_FILE>
+
+ Invoking the script for DRA7xx/AM57xx Secure Devices
+ ====================================================
+
+ create-boot-image.sh \
+ <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+ <IMAGE_TYPE> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ X-LOADER - Generates an image for NOR or QSPI boot modes
+ MLO - Generates an image for SD/MMC/eMMC boot modes
+ ULO - Generates an image for USB/UART peripheral boot modes
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loader binary file (for this platform, this is always u-boot-spl.bin).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure image.
+ The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides
+ and releases notes for how the non-secure images are typically used)
+ u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is
+ copied to a file named MLO, which is the name that
+ the device ROM bootloader requires for loading from
+ the FAT partition of an SD card (same as on
+ non-secure devices)
+ u-boot-spl_HS_ULO - boot image for USB/UART peripheral boot modes
+ u-boot-spl_HS_X-LOADER - boot image for all other flash memories
+ including QSPI and NOR flash
+
+ <SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+ <INPUT_FILE>
+
+ Invoking the script for Keystone2 Secure Devices
+ ================================================
+
+ create-boot-image.sh \
+ <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED>
+
+ <UNUSED> is currently ignored and reserved for future use.
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loader binary file (only u-boot.bin is currently supported on
+ Keystone2 devices, u-boot-spl.bin is not currently supported).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure image.
+ The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides
+ and releases notes for how the non-secure images are typically used)
+ u-boot_HS_MLO - signed and encrypted boot image that can be used to
+ boot from all media. Secure boot from SPI NOR flash is not
+ currently supported.
+
+ Invoking the script for K3 Secure Devices
+ =========================================
+
+ The signing steps required to produce a bootable SPL image on secure
+ K3 TI devices are the same as those performed on non-secure devices.
+ The only difference is the key is not checked on non-secure devices so
+ a dummy key is used when building U-Boot for those devices. For secure
+ K3 TI devices simply use the real hardware key for your device. This
+ real key can be set with the Kconfig option "K3_KEY". The environment
+ variable TI_SECURE_DEV_PKG is also searched for real keys when the
+ build targets secure devices.
+
+Booting of Primary U-Boot (u-boot.img)
+======================================
+
+ The SPL image is responsible for loading the next stage boot loader,
+ which is the main u-boot image. For secure TI devices, the SPL will
+ be authenticated, as described above, as part of the particular
+ device's ROM boot process. In order to continue the secure boot
+ process, the authenticated SPL must authenticate the main u-boot
+ image that it loads.
+
+ The configurations for secure TI platforms are written to make the boot
+ process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK
+ and CONFIG_SPL_LOAD_FIT). With these configurations the binary
+ components that the SPL loads include a specific DTB image and u-boot
+ image. These DTB image may be one of many available to the boot
+ process. In order to secure these components so that they can be
+ authenticated by the SPL as they are loaded from the FIT image, the
+ build procedure for secure TI devices will secure these images before
+ they are integrated into the FIT image. When those images are extracted
+ from the FIT image at boot time, they are post-processed to verify that
+ they are still secure. The outlined security-related SPL post-processing
+ is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which
+ must be enabled for the secure boot scheme to work. In order to allow
+ verifying proper operation of the secure boot chain in case of successful
+ authentication messages like "Authentication passed" are output by the
+ SPL to the console for each blob that got extracted from the FIT image.
+
+ The exact details of the how the images are secured is handled by the
+ SECDEV package. Within the SECDEV package exists a script to process
+ an input binary image:
+
+ ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
+
+ This is called as part of the u-boot build process. As the secure
+ image formats and requirements can differ between the various secure
+ SOCs from TI, this script in the SECDEV package abstracts these
+ details. This script is essentially the only required interface to the
+ TI SECDEV package for creating a u-boot.img image for secure TI
+ devices.
+
+ The SPL/u-boot code contains calls to dedicated secure ROM functions
+ to perform the validation on the secured images. The details of the
+ interface to those functions is shown in the code. The summary
+ is that they are accessed by invoking an ARM secure monitor call to
+ the device's secure ROM (fixed read-only-memory that is secure and
+ only accessible when the ARM core is operating in the secure mode).
+
+ Invoking the secure-binary-image script for Secure Devices
+ ==========================================================
+
+ secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
+
+ <INPUT_FILE> is the full path and filename of the input binary image
+
+ <OUTPUT_FILE> is the full path and filename of the output secure image.
diff --git a/roms/u-boot/doc/README.ubi b/roms/u-boot/doc/README.ubi
new file mode 100644
index 000000000..c78a81795
--- /dev/null
+++ b/roms/u-boot/doc/README.ubi
@@ -0,0 +1,258 @@
+-------------------
+UBI usage in U-Boot
+-------------------
+
+UBI support in U-Boot is broken down into five separate commands.
+The first is the ubi command, which has six subcommands:
+
+=> help ubi
+ubi - ubi commands
+
+Usage:
+ubi part [part] [offset]
+ - Show or set current partition (with optional VID header offset)
+ubi info [l[ayout]] - Display volume and ubi layout information
+ubi create[vol] volume [size] [type] - create volume name with size
+ubi write[vol] address volume size - Write volume from address with size
+ubi write.part address volume size [fullsize]
+ - Write part of a volume from address
+ubi read[vol] address volume [size] - Read volume to address with size
+ubi remove[vol] volume - Remove volume
+[Legends]
+ volume: character name
+ size: specified in bytes
+ type: s[tatic] or d[ynamic] (default=dynamic)
+
+
+The first command that is needed to be issues is "ubi part" to connect
+one mtd partition to the UBI subsystem. This command will either create
+a new UBI device on the requested MTD partition. Or it will attach a
+previously created UBI device. The other UBI commands will only work
+when such a UBI device is attached (via "ubi part"). Here an example:
+
+=> mtdparts
+
+device nor0 <1fc000000.nor_flash>, # parts = 6
+ #: name size offset mask_flags
+ 0: kernel 0x00200000 0x00000000 0
+ 1: dtb 0x00040000 0x00200000 0
+ 2: root 0x00200000 0x00240000 0
+ 3: user 0x01ac0000 0x00440000 0
+ 4: env 0x00080000 0x01f00000 0
+ 5: u-boot 0x00080000 0x01f80000 0
+
+active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000
+
+defaults:
+mtdids : nor0=1fc000000.nor_flash
+mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot)
+
+=> ubi part root
+Creating 1 MTD partitions on "nor0":
+0x000000240000-0x000000440000 : "mtd=2"
+UBI: attaching mtd1 to ubi0
+UBI: physical eraseblock size: 262144 bytes (256 KiB)
+UBI: logical eraseblock size: 262016 bytes
+UBI: smallest flash I/O unit: 1
+UBI: VID header offset: 64 (aligned 64)
+UBI: data offset: 128
+UBI: attached mtd1 to ubi0
+UBI: MTD device name: "mtd=2"
+UBI: MTD device size: 2 MiB
+UBI: number of good PEBs: 8
+UBI: number of bad PEBs: 0
+UBI: max. allowed volumes: 128
+UBI: wear-leveling threshold: 4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes: 1
+UBI: available PEBs: 0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 2/1
+
+
+Now that the UBI device is attached, this device can be modified
+using the following commands:
+
+ubi info Display volume and ubi layout information
+ubi createvol Create UBI volume on UBI device
+ubi removevol Remove UBI volume from UBI device
+ubi read Read data from UBI volume to memory
+ubi write Write data from memory to UBI volume
+ubi write.part Write data from memory to UBI volume, in parts
+
+
+Here a few examples on the usage:
+
+=> ubi create testvol
+Creating dynamic volume testvol of size 1048064
+
+=> ubi info l
+UBI: volume information dump:
+UBI: vol_id 0
+UBI: reserved_pebs 4
+UBI: alignment 1
+UBI: data_pad 0
+UBI: vol_type 3
+UBI: name_len 7
+UBI: usable_leb_size 262016
+UBI: used_ebs 4
+UBI: used_bytes 1048064
+UBI: last_eb_bytes 262016
+UBI: corrupted 0
+UBI: upd_marker 0
+UBI: name testvol
+
+UBI: volume information dump:
+UBI: vol_id 2147479551
+UBI: reserved_pebs 2
+UBI: alignment 1
+UBI: data_pad 0
+UBI: vol_type 3
+UBI: name_len 13
+UBI: usable_leb_size 262016
+UBI: used_ebs 2
+UBI: used_bytes 524032
+UBI: last_eb_bytes 2
+UBI: corrupted 0
+UBI: upd_marker 0
+UBI: name layout volume
+
+=> ubi info
+UBI: MTD device name: "mtd=2"
+UBI: MTD device size: 2 MiB
+UBI: physical eraseblock size: 262144 bytes (256 KiB)
+UBI: logical eraseblock size: 262016 bytes
+UBI: number of good PEBs: 8
+UBI: number of bad PEBs: 0
+UBI: smallest flash I/O unit: 1
+UBI: VID header offset: 64 (aligned 64)
+UBI: data offset: 128
+UBI: max. allowed volumes: 128
+UBI: wear-leveling threshold: 4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes: 1
+UBI: available PEBs: 0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 4/1
+
+=> ubi write 800000 testvol 80000
+Volume "testvol" found at volume id 0
+
+=> ubi read 900000 testvol 80000
+Volume testvol found at volume id 0
+read 524288 bytes from volume 0 to 900000(buf address)
+
+=> cmp.b 800000 900000 80000
+Total of 524288 bytes were the same
+
+
+Next, the ubifsmount command allows you to access filesystems on the
+UBI partition which has been attached with the ubi part command:
+
+=> help ubifsmount
+ubifsmount - mount UBIFS volume
+
+Usage:
+ubifsmount <volume-name>
+ - mount 'volume-name' volume
+
+For example:
+
+=> ubifsmount ubi0:recovery
+UBIFS: mounted UBI device 0, volume 0, name "recovery"
+UBIFS: mounted read-only
+UBIFS: file system size: 46473216 bytes (45384 KiB, 44 MiB, 366 LEBs)
+UBIFS: journal size: 6348800 bytes (6200 KiB, 6 MiB, 50 LEBs)
+UBIFS: media format: w4/r0 (latest is w4/r0)
+UBIFS: default compressor: LZO
+UBIFS: reserved for root: 0 bytes (0 KiB)
+
+Note that unlike Linux, U-Boot can only have one active UBI partition
+at a time, which can be referred to as ubi0, and must be supplied along
+with the name of the filesystem you are mounting.
+
+
+Once a UBI filesystem has been mounted, the ubifsls command allows you
+to list the contents of a directory in the filesystem:
+
+
+=> help ubifsls
+ubifsls - list files in a directory
+
+Usage:
+ubifsls [directory]
+ - list files in a 'directory' (default '/')
+
+For example:
+
+=> ubifsls
+ 17442 Thu Jan 01 02:57:38 1970 imx28-evk.dtb
+ 2998146 Thu Jan 01 02:57:43 1970 zImage
+
+
+And the ubifsload command allows you to load a file from a UBI
+filesystem:
+
+
+=> help ubifsload
+ubifsload - load file from an UBIFS filesystem
+
+Usage:
+ubifsload <addr> <filename> [bytes]
+ - load file 'filename' to address 'addr'
+
+For example:
+
+=> ubifsload ${loadaddr} zImage
+Loading file 'zImage' to addr 0x42000000 with size 2998146 (0x002dbf82)...
+Done
+
+
+Finally, you can unmount the UBI filesystem with the ubifsumount
+command:
+
+=> help ubifsumount
+ubifsumount - unmount UBIFS volume
+
+Usage:
+ubifsumount - unmount current volume
+
+For example:
+
+=> ubifsumount
+Unmounting UBIFS volume recovery!
+
+
+Usage of the UBI CRC skip-check flag of static volumes:
+-------------------------------------------------------
+Some users of static UBI volumes implement their own integrity check,
+thus making the volume CRC check done at open time useless. For
+instance, this is the case when one use the ubiblock + dm-verity +
+squashfs combination, where dm-verity already checks integrity of the
+block device but this time at the block granularity instead of verifying
+the whole volume.
+
+Skipping this test drastically improves the boot-time.
+
+U-Boot now supports the "skip_check" flag to optionally skip the CRC
+check at open time.
+
+Usage: Case A - Upon UBI volume creation:
+You can optionally add "--skipcheck" to the "ubi create" command:
+
+ubi create[vol] volume [size] [type] [id] [--skipcheck]
+ - create volume name with size ('-' for maximum available size)
+
+Usage: Case B - With an already existing UBI volume:
+Use the "ubi skipcheck" command:
+
+ubi skipcheck volume on/off - Set or clear skip_check flag in volume header
+
+Example:
+=> ubi skipcheck rootfs0 on
+Setting skip_check on volume rootfs0
+
+BTW: This saves approx. 10 seconds Linux bootup time on a MT7688 based
+target with 128MiB of SPI NAND.
diff --git a/roms/u-boot/doc/README.ubispl b/roms/u-boot/doc/README.ubispl
new file mode 100644
index 000000000..ff008bc31
--- /dev/null
+++ b/roms/u-boot/doc/README.ubispl
@@ -0,0 +1,141 @@
+Lightweight UBI and UBI fastmap support
+
+# Copyright (C) Thomas Gleixner <tglx@linutronix.de>
+#
+# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause
+
+Scans the UBI information and loads the requested static volumes into
+memory.
+
+Configuration Options:
+
+ CONFIG_SPL_UBI
+ Enables the SPL UBI support
+
+ CONFIG_SPL_UBI_MAX_VOL_LEBS
+ The maximum number of logical eraseblocks which a static volume
+ to load can contain. Used for sizing the scan data structure
+
+ CONFIG_SPL_UBI_MAX_PEB_SIZE
+ The maximum physical erase block size. Either a compile time
+ constant or runtime detection. Used for sizing the scan data
+ structure
+
+ CONFIG_SPL_UBI_MAX_PEBS
+ The maximum physical erase block count. Either a compile time
+ constant or runtime detection. Used for sizing the scan data
+ structure
+
+ CONFIG_SPL_UBI_VOL_IDS
+ The maximum volume ids which can be loaded. Used for sizing the
+ scan data structure.
+
+Usage notes:
+
+In the board config file define for example:
+
+#define CONFIG_SPL_UBI
+#define CONFIG_SPL_UBI_MAX_VOL_LEBS 256
+#define CONFIG_SPL_UBI_MAX_PEB_SIZE (256*1024)
+#define CONFIG_SPL_UBI_MAX_PEBS 4096
+#define CONFIG_SPL_UBI_VOL_IDS 8
+
+The size requirement is roughly as follows:
+
+ 2k for the basic data structure
+ + CONFIG_SPL_UBI_VOL_IDS * CONFIG_SPL_UBI_MAX_VOL_LEBS * 8
+ + CONFIG_SPL_UBI_MAX_PEBS * 64
+ + CONFIG_SPL_UBI_MAX_PEB_SIZE * UBI_FM_MAX_BLOCKS
+
+The last one is big, but I really don't care in that stage. Real world
+implementations only use the first couple of blocks, but the code
+handles up to UBI_FM_MAX_BLOCKS.
+
+Given the above configuration example the requirement is about 5M
+which is usually not a problem to reserve in the RAM along with the
+other areas like the kernel/dts load address.
+
+So something like this will do the trick:
+
+#define SPL_FINFO_ADDR 0x80800000
+#define SPL_DTB_LOAD_ADDR 0x81800000
+#define SPL_KERNEL_LOAD_ADDR 0x82000000
+
+In the board file, implement the following:
+
+static struct ubispl_load myvolumes[] = {
+ {
+ .vol_id = 0, /* kernel volume */
+ .load_addr = (void *)SPL_KERNEL_LOAD_ADDR,
+ },
+ {
+ .vol_id = 1, /* DT blob */
+ .load_addr = (void *)SPL_DTB_LOAD_ADDR,
+ }
+};
+
+int spl_start_uboot(void)
+{
+ struct ubispl_info info;
+
+ info.ubi = (struct ubi_scan_info *) SPL_FINFO_ADDR;
+ info.fastmap = 1;
+ info.read = nand_spl_read_flash;
+
+#if COMPILE_TIME_DEFINED
+ /*
+ * MY_NAND_NR_SPL_PEBS is the number of physical erase blocks
+ * in the FLASH which are reserved for the SPL. Think about
+ * mtd partitions:
+ *
+ * part_spl { .start = 0, .end = 4 }
+ * part_ubi { .start = 4, .end = NR_PEBS }
+ */
+ info.peb_offset = MY_NAND_NR_SPL_PEBS;
+ info.peb_size = CONFIG_SYS_NAND_BLOCK_SIZE;
+ info.vid_offset = MY_NAND_UBI_VID_OFFS;
+ info.leb_start = MY_NAND_UBI_DATA_OFFS;
+ info.peb_count = MY_NAND_UBI_NUM_PEBS;
+#else
+ get_flash_info(&flash_info);
+ info.peb_offset = MY_NAND_NR_SPL_PEBS;
+ info.peb_size = flash_info.peb_size;
+
+ /*
+ * The VID and Data offset depend on the capability of the
+ * FLASH chip to do subpage writes.
+ *
+ * If the flash chip supports subpage writes, then the VID
+ * header starts at the second subpage. So for 2k pages size
+ * with 4 subpages the VID offset is 512. The DATA offset is 2k.
+ *
+ * If the flash chip does not support subpage writes then the
+ * VID offset is FLASH_PAGE_SIZE and the DATA offset
+ * 2 * FLASH_PAGE_SIZE
+ */
+ info.vid_offset = flash_info.vid_offset;
+ info.leb_start = flash_info.data_offset;
+
+ /*
+ * The flash reports the total number of erase blocks, so
+ * we need to subtract the number of blocks which are reserved
+ * for the SPL itself and not managed by UBI.
+ */
+ info.peb_count = flash_info.peb_count - MY_NAND_NR_SPL_PEBS;
+#endif
+
+ ret = ubispl_load_volumes(&info, myvolumes, ARRAY_SIZE(myvolumes);
+
+ ....
+
+}
+
+Note: you can load any payload that way. You can even load u-boot from
+UBI, so the only non UBI managed FLASH area is the one which is
+reserved for the SPL itself and read from the SoC ROM.
+
+And you can do fallback scenarios:
+
+ if (ubispl_load_volumes(&info, volumes0, ARRAY_SIZE(volumes0)))
+ if (ubispl_load_volumes(&info, volumes1, ARRAY_SIZE(volumes1)))
+ ubispl_load_volumes(&info, vol_uboot, ARRAY_SIZE(vol_uboot));
diff --git a/roms/u-boot/doc/README.ublimage b/roms/u-boot/doc/README.ublimage
new file mode 100644
index 000000000..ab25b2615
--- /dev/null
+++ b/roms/u-boot/doc/README.ublimage
@@ -0,0 +1,141 @@
+---------------------------------------------
+UBL image Boot Image generation using mkimage
+---------------------------------------------
+
+This document describes how to set up an U-Boot image that can be directly
+booted by a DaVinci processor via NAND boot mode, using an UBL header,
+but without need for UBL.
+
+For more details see section 11.2 "ARM ROM Boot Modes" of
+http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf
+
+Command syntax:
+--------------
+./tools/mkimage -l <u-boot_file>
+ to list the UBL image file details
+
+./tools/mkimage -T ublimage \
+ -n <board specific configuration file> \
+ -d <u-boot binary> <output image file>
+
+For example, for the davinci dm365evm board:
+./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg \
+ -T ublimage \
+ -d u-boot-nand.bin u-boot.ubl
+
+You can generate the image directly when you compile u-boot with:
+
+$ make u-boot.ubl
+
+The output image can be flashed into the NAND.
+
+Please check the DaVinci documentation for further details.
+
+Board specific configuration file specifications:
+-------------------------------------------------
+1. This file must present in the $(BOARDDIR) and the name should be
+ ublimage.cfg (since this is used in Makefile).
+2. This file can have empty lines and lines starting with "#" as first
+ character to put comments.
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+---------------------------------
+1. Each command line must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -------------- -----------
+ MODE UBL special mode, on of:
+ safe
+ Example:
+ MODE safe
+
+ ENTRY Entry point address for the user
+ bootloader (absolute address) = TEXT_BASE
+ nand_spl loader.
+ Example:
+ ENTRY 0x00000020
+
+ PAGES Number of pages (size of user bootloader
+ in number of pages)
+ Example:
+ PAGES 27
+
+ START_BLOCK Block number where user bootloader is present
+ Example:
+ START_BLOCK 5
+
+ START_PAGE Page number where user bootloader is present
+ (for RBL always 0)
+ Example:
+ START_PAGE 0
+
+------------------------------------------------
+
+Structure of the u-boot.ubl binary:
+
+compile steps:
+
+1) nand_spl code compile, with pad_to = (TEXT_BASE +
+ (CONFIG_SYS_NROF_PAGES_NAND_SPL * pagesize))
+ Example: cam_enc_4xx pad_to = 0x20 + (6 * 0x800) = 0x3020 = 12320
+ -> u-boot-spl-16k.bin
+
+ !! TEXT_BASE = 0x20, as the RBL starts at 0x20
+
+2) compile u-boot.bin ("normal" u-boot)
+ -> u-boot.bin
+
+3) create u-boot-nand.bin = u-boot-spl-16k.bin + u-boot.bin
+
+4) create u-boot.ubl, size = 1 page size NAND
+ create UBL header and paste it before u-boot.bin
+
+This steps are done automagically if you do a "make all"
+
+-> You get an u-boot.ubl binary, which you can flash
+ into your NAND.
+
+Structure of this binary (Example for the cam_enc_4xx board with a NAND
+page size = 0x800):
+
+offset : 0x00000 | 0x800 | 0x3800
+content: UBL | nand_spl | u-boot code
+ Header | code |
+
+The NAND layout looks for example like this:
+
+(Example for the cam_enc_4xx board with a NAND page size = 0x800, block
+size = 0x20000 and CONFIG_SYS_NROF_UBL_HEADER 5):
+
+offset : 0x80000 | 0xa0000 | 0xa3000
+content: UBL | nand_spl | u-boot code
+ Header | code |
+ ^ ^
+ ^ 0xa0000 = CONFIG_SYS_NROF_UBL_HEADER * 0x20000
+ ^
+ 0x80000 = Block 4 * 0x20000
+
+If the cpu starts in NAND boot mode, it checks the UBL descriptor
+starting with block 1 (page 0). When a valid UBL signature is found,
+the corresponding block number (from 1 to 24) is written to the last 32
+bits of ARM internal memory (0x7ffc-0x8000). This feature is provided
+as a basic debug mechanism. If not found, it continues with block 2
+... last possible block is 24
+
+If a valid UBL descriptor is found, the UBL descriptor is read and
+processed. The descriptor gives the information required for loading
+and control transfer to the nand_spl code. The nand_spl code is then
+read and processed.
+
+Once the user-specified start-up conditions are set, the RBL copies the
+nand_spl into ARM internal RAM, starting at address 0x0000: 0020.
+ ^^^^
+
+The nand_spl code itself now does necessary intializations, and at least,
+copies the u-boot code from NAND into RAM, and jumps to it ...
+
+------------------------------------------------
+Author: Heiko Schocher <hs@denx.de>
diff --git a/roms/u-boot/doc/README.udp b/roms/u-boot/doc/README.udp
new file mode 100644
index 000000000..da0725719
--- /dev/null
+++ b/roms/u-boot/doc/README.udp
@@ -0,0 +1,35 @@
+Udp framework
+
+The udp framework is build on top of network framework and is designed
+to define new protocol or new command based on udp without modifying
+the network framework.
+
+The udp framework define a function udp_loop that take as argument
+a structure udp_ops (defined in include/net/udp.h) :
+
+struct udp_ops {
+ int (*prereq)(void *data);
+ int (*start)(void *data);
+ void *data;
+};
+
+The callback prereq define if all the requirements are
+valid before running the network/udp loop.
+
+The callback start define the first step in the network/udp loop,
+and it may also be used to configure a timemout and udp handler.
+
+The pointer data is used to store private data that
+could be used by both callback.
+
+A simple example to use this framework:
+
+static struct udp_ops udp_ops = {
+ .prereq = wmp_prereq,
+ .start = wmp_start,
+ .data = NULL,
+};
+
+...
+
+err = udp_loop(&udp_ops);
diff --git a/roms/u-boot/doc/README.unaligned-memory-access.txt b/roms/u-boot/doc/README.unaligned-memory-access.txt
new file mode 100644
index 000000000..70a85f9cf
--- /dev/null
+++ b/roms/u-boot/doc/README.unaligned-memory-access.txt
@@ -0,0 +1,240 @@
+Editors note: This document is _heavily_ cribbed from the Linux Kernel, with
+really only the section about "Alignment vs. Networking" removed.
+
+UNALIGNED MEMORY ACCESSES
+=========================
+
+Linux runs on a wide variety of architectures which have varying behaviour
+when it comes to memory access. This document presents some details about
+unaligned accesses, why you need to write code that doesn't cause them,
+and how to write such code!
+
+
+The definition of an unaligned access
+=====================================
+
+Unaligned memory accesses occur when you try to read N bytes of data starting
+from an address that is not evenly divisible by N (i.e. addr % N != 0).
+For example, reading 4 bytes of data from address 0x10004 is fine, but
+reading 4 bytes of data from address 0x10005 would be an unaligned memory
+access.
+
+The above may seem a little vague, as memory access can happen in different
+ways. The context here is at the machine code level: certain instructions read
+or write a number of bytes to or from memory (e.g. movb, movw, movl in x86
+assembly). As will become clear, it is relatively easy to spot C statements
+which will compile to multiple-byte memory access instructions, namely when
+dealing with types such as u16, u32 and u64.
+
+
+Natural alignment
+=================
+
+The rule mentioned above forms what we refer to as natural alignment:
+When accessing N bytes of memory, the base memory address must be evenly
+divisible by N, i.e. addr % N == 0.
+
+When writing code, assume the target architecture has natural alignment
+requirements.
+
+In reality, only a few architectures require natural alignment on all sizes
+of memory access. However, we must consider ALL supported architectures;
+writing code that satisfies natural alignment requirements is the easiest way
+to achieve full portability.
+
+
+Why unaligned access is bad
+===========================
+
+The effects of performing an unaligned memory access vary from architecture
+to architecture. It would be easy to write a whole document on the differences
+here; a summary of the common scenarios is presented below:
+
+ - Some architectures are able to perform unaligned memory accesses
+ transparently, but there is usually a significant performance cost.
+ - Some architectures raise processor exceptions when unaligned accesses
+ happen. The exception handler is able to correct the unaligned access,
+ at significant cost to performance.
+ - Some architectures raise processor exceptions when unaligned accesses
+ happen, but the exceptions do not contain enough information for the
+ unaligned access to be corrected.
+ - Some architectures are not capable of unaligned memory access, but will
+ silently perform a different memory access to the one that was requested,
+ resulting in a subtle code bug that is hard to detect!
+
+It should be obvious from the above that if your code causes unaligned
+memory accesses to happen, your code will not work correctly on certain
+platforms and will cause performance problems on others.
+
+
+Code that does not cause unaligned access
+=========================================
+
+At first, the concepts above may seem a little hard to relate to actual
+coding practice. After all, you don't have a great deal of control over
+memory addresses of certain variables, etc.
+
+Fortunately things are not too complex, as in most cases, the compiler
+ensures that things will work for you. For example, take the following
+structure:
+
+ struct foo {
+ u16 field1;
+ u32 field2;
+ u8 field3;
+ };
+
+Let us assume that an instance of the above structure resides in memory
+starting at address 0x10000. With a basic level of understanding, it would
+not be unreasonable to expect that accessing field2 would cause an unaligned
+access. You'd be expecting field2 to be located at offset 2 bytes into the
+structure, i.e. address 0x10002, but that address is not evenly divisible
+by 4 (remember, we're reading a 4 byte value here).
+
+Fortunately, the compiler understands the alignment constraints, so in the
+above case it would insert 2 bytes of padding in between field1 and field2.
+Therefore, for standard structure types you can always rely on the compiler
+to pad structures so that accesses to fields are suitably aligned (assuming
+you do not cast the field to a type of different length).
+
+Similarly, you can also rely on the compiler to align variables and function
+parameters to a naturally aligned scheme, based on the size of the type of
+the variable.
+
+At this point, it should be clear that accessing a single byte (u8 or char)
+will never cause an unaligned access, because all memory addresses are evenly
+divisible by one.
+
+On a related topic, with the above considerations in mind you may observe
+that you could reorder the fields in the structure in order to place fields
+where padding would otherwise be inserted, and hence reduce the overall
+resident memory size of structure instances. The optimal layout of the
+above example is:
+
+ struct foo {
+ u32 field2;
+ u16 field1;
+ u8 field3;
+ };
+
+For a natural alignment scheme, the compiler would only have to add a single
+byte of padding at the end of the structure. This padding is added in order
+to satisfy alignment constraints for arrays of these structures.
+
+Another point worth mentioning is the use of __attribute__((packed)) on a
+structure type. This GCC-specific attribute tells the compiler never to
+insert any padding within structures, useful when you want to use a C struct
+to represent some data that comes in a fixed arrangement 'off the wire'.
+
+You might be inclined to believe that usage of this attribute can easily
+lead to unaligned accesses when accessing fields that do not satisfy
+architectural alignment requirements. However, again, the compiler is aware
+of the alignment constraints and will generate extra instructions to perform
+the memory access in a way that does not cause unaligned access. Of course,
+the extra instructions obviously cause a loss in performance compared to the
+non-packed case, so the packed attribute should only be used when avoiding
+structure padding is of importance.
+
+
+Code that causes unaligned access
+=================================
+
+With the above in mind, let's move onto a real life example of a function
+that can cause an unaligned memory access. The following function taken
+from the Linux Kernel's include/linux/etherdevice.h is an optimized routine
+to compare two ethernet MAC addresses for equality.
+
+bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
+{
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+ u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
+ ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
+
+ return fold == 0;
+#else
+ const u16 *a = (const u16 *)addr1;
+ const u16 *b = (const u16 *)addr2;
+ return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0;
+#endif
+}
+
+In the above function, when the hardware has efficient unaligned access
+capability, there is no issue with this code. But when the hardware isn't
+able to access memory on arbitrary boundaries, the reference to a[0] causes
+2 bytes (16 bits) to be read from memory starting at address addr1.
+
+Think about what would happen if addr1 was an odd address such as 0x10003.
+(Hint: it'd be an unaligned access.)
+
+Despite the potential unaligned access problems with the above function, it
+is included in the kernel anyway but is understood to only work normally on
+16-bit-aligned addresses. It is up to the caller to ensure this alignment or
+not use this function at all. This alignment-unsafe function is still useful
+as it is a decent optimization for the cases when you can ensure alignment,
+which is true almost all of the time in ethernet networking context.
+
+
+Here is another example of some code that could cause unaligned accesses:
+ void myfunc(u8 *data, u32 value)
+ {
+ [...]
+ *((u32 *) data) = cpu_to_le32(value);
+ [...]
+ }
+
+This code will cause unaligned accesses every time the data parameter points
+to an address that is not evenly divisible by 4.
+
+In summary, the 2 main scenarios where you may run into unaligned access
+problems involve:
+ 1. Casting variables to types of different lengths
+ 2. Pointer arithmetic followed by access to at least 2 bytes of data
+
+
+Avoiding unaligned accesses
+===========================
+
+The easiest way to avoid unaligned access is to use the get_unaligned() and
+put_unaligned() macros provided by the <asm/unaligned.h> header file.
+
+Going back to an earlier example of code that potentially causes unaligned
+access:
+
+ void myfunc(u8 *data, u32 value)
+ {
+ [...]
+ *((u32 *) data) = cpu_to_le32(value);
+ [...]
+ }
+
+To avoid the unaligned memory access, you would rewrite it as follows:
+
+ void myfunc(u8 *data, u32 value)
+ {
+ [...]
+ value = cpu_to_le32(value);
+ put_unaligned(value, (u32 *) data);
+ [...]
+ }
+
+The get_unaligned() macro works similarly. Assuming 'data' is a pointer to
+memory and you wish to avoid unaligned access, its usage is as follows:
+
+ u32 value = get_unaligned((u32 *) data);
+
+These macros work for memory accesses of any length (not just 32 bits as
+in the examples above). Be aware that when compared to standard access of
+aligned memory, using these macros to access unaligned memory can be costly in
+terms of performance.
+
+If use of such macros is not convenient, another option is to use memcpy(),
+where the source or destination (or both) are of type u8* or unsigned char*.
+Due to the byte-wise nature of this operation, unaligned accesses are avoided.
+
+--
+In the Linux Kernel,
+Authors: Daniel Drake <dsd@gentoo.org>,
+ Johannes Berg <johannes@sipsolutions.net>
+With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
+Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
+Vadim Lobanov
diff --git a/roms/u-boot/doc/README.uniphier b/roms/u-boot/doc/README.uniphier
new file mode 100644
index 000000000..badfacd66
--- /dev/null
+++ b/roms/u-boot/doc/README.uniphier
@@ -0,0 +1,462 @@
+U-Boot for UniPhier SoC family
+==============================
+
+
+Recommended toolchains
+----------------------
+
+The UniPhier platform is well tested with Linaro toolchains.
+You can download pre-built toolchains from:
+
+ http://www.linaro.org/downloads/
+
+
+Compile the source
+------------------
+
+The source can be configured and built with the following commands:
+
+ $ make <defconfig>
+ $ make CROSS_COMPILE=<toolchain-prefix> DEVICE_TREE=<device-tree>
+
+The recommended <toolchain-prefix> is `arm-linux-gnueabihf-` for 32bit SoCs,
+`aarch64-linux-gnu-` for 64bit SoCs, but you may wish to change it to use your
+favorite compiler.
+
+The following tables show <defconfig> and <device-tree> for each board.
+
+32bit SoC boards:
+
+ Board | <defconfig> | <device-tree>
+---------------|-----------------------------|------------------------------
+LD4 reference | uniphier_ld4_sld8_defconfig | uniphier-ld4-ref (default)
+sld8 reference | uniphier_ld4_sld8_defconfig | uniphier-sld8-def
+Pro4 reference | uniphier_v7_defconfig | uniphier-pro4-ref
+Pro4 Ace | uniphier_v7_defconfig | uniphier-pro4-ace
+Pro4 Sanji | uniphier_v7_defconfig | uniphier-pro4-sanji
+Pro5 4KBOX | uniphier_v7_defconfig | uniphier-pro5-4kbox
+PXs2 Gentil | uniphier_v7_defconfig | uniphier-pxs2-gentil
+PXs2 Vodka | uniphier_v7_defconfig | uniphier-pxs2-vodka (default)
+LD6b reference | uniphier_v7_defconfig | uniphier-ld6b-ref
+
+64bit SoC boards:
+
+ Board | <defconfig> | <device-tree>
+---------------|-----------------------|----------------------------
+LD11 reference | uniphier_v8_defconfig | uniphier-ld11-ref
+LD11 Global | uniphier_v8_defconfig | uniphier-ld11-global
+LD20 reference | uniphier_v8_defconfig | uniphier-ld20-ref (default)
+LD20 Global | uniphier_v8_defconfig | uniphier-ld20-global
+PXs3 reference | uniphier_v8_defconfig | uniphier-pxs3-ref
+
+For example, to compile the source for PXs2 Vodka board, run the following:
+
+ $ make uniphier_v7_defconfig
+ $ make CROSS_COMPILE=arm-linux-gnueabihf- DEVICE_TREE=uniphier-pxs2-vodka
+
+The device tree marked as (default) can be omitted. `uniphier-pxs2-vodka` is
+the default device tree for the configuration `uniphier_v7_defconfig`, so the
+following gives the same result.
+
+ $ make uniphier_v7_defconfig
+ $ make CROSS_COMPILE=arm-linux-gnueabihf-
+
+
+Booting 32bit SoC boards
+------------------------
+
+The build command will generate the following:
+- u-boot.bin
+- spl/u-boot.bin
+
+U-Boot can boot UniPhier 32bit SoC boards by itself. Flash the generated images
+to the storage device (NAND or eMMC) on your board.
+
+ - spl/u-boot-spl.bin at the offset address 0x00000000
+ - u-boot.bin at the offset address 0x00020000
+
+The `u-boot-with-spl.bin` is the concatenation of the two (with appropriate
+padding), so you can also do:
+
+ - u-boot-with-spl.bin at the offset address 0x00000000
+
+If a TFTP server is available, the images can be easily updated.
+Just copy the u-boot-spl.bin and u-boot.bin to the TFTP public directory,
+and run the following command at the U-Boot command line:
+
+To update the images in NAND:
+
+ => run nandupdate
+
+To update the images in eMMC:
+
+ => run emmcupdate
+
+
+Booting 64bit SoC boards
+------------------------
+
+The build command will generate the following:
+- u-boot.bin
+
+However, U-Boot is not the first stage loader for UniPhier 64bit SoC boards.
+U-Boot serves as a non-secure boot loader loaded by [ARM Trusted Firmware],
+so you need to provide the `u-boot.bin` to the build command of ARM Trusted
+Firmware.
+
+[ARM Trusted Firmware]: https://github.com/ARM-software/arm-trusted-firmware
+
+
+Verified Boot
+-------------
+
+U-Boot supports an image verification method called "Verified Boot".
+This is a brief tutorial to utilize this feature for the UniPhier platform.
+You will find details documents in the doc/uImage.FIT directory.
+
+Here, we take LD20 reference board for example, but it should work for any
+other boards including 32 bit SoCs.
+
+1. Generate key to sign with
+
+ $ mkdir keys
+ $ openssl genpkey -algorithm RSA -out keys/dev.key \
+ -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
+ $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
+but need to match to the "key-name-hint" property described below.
+
+2. Describe FIT source
+
+You need to write an FIT (Flattened Image Tree) source file to describe the
+structure of the image container.
+
+The following is an example for a simple usecase:
+
+---------------------------------------->8----------------------------------------
+/dts-v1/;
+
+/ {
+ description = "Kernel, DTB and Ramdisk for UniPhier LD20 Reference Board";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "linux";
+ data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/Image.gz");
+ type = "kernel";
+ arch = "arm64";
+ os = "linux";
+ compression = "gzip";
+ load = <0x82080000>;
+ entry = <0x82080000>;
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+
+ fdt-1 {
+ description = "fdt";
+ data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dtb");
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+
+ ramdisk {
+ description = "ramdisk";
+ data = /incbin/("PATH/TO/YOUR/ROOTFS/DIR/rootfs.cpio");
+ type = "ramdisk";
+ arch = "arm64";
+ os = "linux";
+ compression = "none";
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-1";
+
+ config-1 {
+ description = "Configuration0";
+ kernel = "kernel";
+ fdt = "fdt-1";
+ ramdisk = "ramdisk";
+ signature-1 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel", "fdt", "ramdisk";
+ };
+ };
+ };
+};
+---------------------------------------->8----------------------------------------
+
+You need to change the three '/incbin/' lines, depending on the location of
+your kernel image, device tree blob, and init ramdisk. The "load" and "entry"
+properties also need to be adjusted if you want to change the physical placement
+of the kernel.
+
+The "key-name-hint" must specify the key name you have created in the step 1.
+
+The FIT file name is arbitrary. Let's say you saved it into "fit.its".
+
+3. Compile U-Boot with FIT and signature enabled
+
+To use the Verified Boot, you need to enable the following two options:
+ CONFIG_FIT
+ CONFIG_FIT_SIGNATURE
+
+They are disabled by default for UniPhier defconfig files. So, you need to
+tweak the configuration from "make menuconfig" or friends.
+
+ $ make uniphier_v8_defconfig
+ $ make menuconfig
+ [ enable CONFIG_FIT and CONFIG_FIT_SIGNATURE ]
+ $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+4. Build the image tree blob
+
+After building U-Boot, you will see tools/mkimage. With this tool, you can
+create an image tree blob as follows:
+
+ $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
+
+The -k option must specify the key directory you have created in step 1.
+
+A file "fitImage" will be created. This includes kernel, DTB, Init-ramdisk,
+hash data for each of the three, and signature data.
+
+The public key needed for the run-time verification is stored in "dts/dt.dtb".
+
+5. Compile U-Boot again
+
+Since the "dt.dtb" has been updated in step 4, you need to re-compile the
+U-Boot.
+
+ $ make CROSS_COMPILE=aarch64-linux-gnu-
+
+The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
+
+6. Flash the image
+
+Flash the "fitImage" to a storage device (NAND, eMMC, or whatever) on your
+board.
+
+Please note the "u-boot.bin" must be signed, and verified by someone when it is
+loaded. For ARMv8 SoCs, the "someone" is generally ARM Trusted Firmware BL2.
+ARM Trusted Firmware supports an image authentication mechanism called Trusted
+Board Boot (TBB). The verification process must be chained from the moment of
+the system reset. If the Chain of Trust has a breakage somewhere, the verified
+boot process is entirely pointless.
+
+7. Boot verified kernel
+
+Load the fitImage to memory and run the following from the U-Boot command line.
+
+ > bootm <addr>
+
+Here, <addr> is the base address of the fitImage.
+
+If it is successful, you will see messages like follows:
+
+---------------------------------------->8----------------------------------------
+## Loading kernel from FIT Image at 84100000 ...
+ Using 'config-1' configuration
+ Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
+ Trying 'kernel' kernel subimage
+ Description: linux
+ Created: 2017-10-20 14:32:29 UTC
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x841000c8
+ Data Size: 6957818 Bytes = 6.6 MiB
+ Architecture: AArch64
+ OS: Linux
+ Load Address: 0x82080000
+ Entry Point: 0x82080000
+ Hash algo: sha256
+ Hash value: 82a37b7f11ae55f4e07aa25bf77e4067cb9dc1014d52d6cd4d588f92eee3aaad
+ Verifying Hash Integrity ... sha256+ OK
+## Loading ramdisk from FIT Image at 84100000 ...
+ Using 'config-1' configuration
+ Trying 'ramdisk' ramdisk subimage
+ Description: ramdisk
+ Created: 2017-10-20 14:32:29 UTC
+ Type: RAMDisk Image
+ Compression: uncompressed
+ Data Start: 0x847a5cc0
+ Data Size: 5264365 Bytes = 5 MiB
+ Architecture: AArch64
+ OS: Linux
+ Load Address: unavailable
+ Entry Point: unavailable
+ Hash algo: sha256
+ Hash value: 44980a2874154a2e31ed59222c9f8ea968867637f35c81e4107a984de7014deb
+ Verifying Hash Integrity ... sha256+ OK
+## Loading fdt from FIT Image at 84100000 ...
+ Using 'config-1' configuration
+ Trying 'fdt-1' fdt subimage
+ Description: fdt
+ Created: 2017-10-20 14:32:29 UTC
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x847a2cb0
+ Data Size: 12111 Bytes = 11.8 KiB
+ Architecture: AArch64
+ Hash algo: sha256
+ Hash value: c517099db537f6d325e6be46b25c871a41331ad5af0283883fd29d40bfc14e1d
+ Verifying Hash Integrity ... sha256+ OK
+ Booting using the fdt blob at 0x847a2cb0
+ Uncompressing Kernel Image ... OK
+ reserving fdt memory region: addr=80000000 size=2000000
+ Loading Device Tree to 000000009fffa000, end 000000009fffff4e ... OK
+
+Starting kernel ...
+---------------------------------------->8----------------------------------------
+
+Please pay attention to the lines that start with "Verifying Hash Integrity".
+
+"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
+passed.
+
+"Verifying Hash Integrity ... sha256+ OK" (3 times) means the hash check passed
+for kernel, DTB, and Init ramdisk.
+
+If they are not displayed, the Verified Boot is not working.
+
+
+Deployment for Distro Boot
+--------------------------
+
+UniPhier SoC family boot the kernel in a generic manner as described in
+doc/README.distro .
+
+To boot the kernel, you need to deploy necesssary components to a file
+system on one of your block devices (eMMC, NAND, USB drive, etc.).
+
+The components depend on the kernel image format.
+
+[1] Bare images
+
+ - kernel
+ - init ramdisk
+ - device tree blob
+ - boot configuration file (extlinux.conf)
+
+Here is an exmple of the configuration file.
+
+-------------------->8--------------------
+menu title UniPhier Boot Options.
+
+timeout 50
+default UniPhier
+
+label UniPhier
+ kernel ../Image
+ initrd ../rootfs.cpio.gz
+ fdtdir ..
+-------------------->8--------------------
+
+Then, write 'Image', 'rootfs.cpio.gz', 'uniphier-ld20-ref.dtb' (DTB depends on
+your board), and 'extlinux/extlinux.conf' to the file system.
+
+[2] FIT
+
+ - FIT blob
+ - boot configuration file (extlinux.conf)
+
+-------------------->8--------------------
+menu title UniPhier Boot Options.
+
+timeout 50
+default UniPhier
+
+label UniPhier
+ kernel ../fitImage
+-------------------->8--------------------
+
+Since the init ramdisk and DTB are contained in the FIT blob,
+you do not need to describe them in the configuration file.
+Write 'fitImage' and 'extlinux/extlinux.conf' to the file system.
+
+
+UniPhier specific commands
+--------------------------
+
+ - pinmon (enabled by CONFIG_CMD_PINMON)
+ shows the boot mode pins that has been latched at the power-on reset
+
+ - ddrphy (enabled by CONFIG_CMD_DDRPHY_DUMP)
+ shows the DDR PHY parameters set by the PHY training
+
+ - ddrmphy (enabled by CONFIG_CMD_DDRMPHY_DUMP)
+ shows the DDR Multi PHY parameters set by the PHY training
+
+
+Supported devices
+-----------------
+
+ - UART (on-chip)
+ - NAND
+ - SD/eMMC
+ - USB 2.0 (EHCI)
+ - USB 3.0 (xHCI)
+ - GPIO
+ - LAN (on-board SMSC9118)
+ - I2C
+ - EEPROM (connected to the on-board I2C bus)
+ - Support card (SRAM, NOR flash, some peripherals)
+
+
+Micro Support Card
+------------------
+
+The recommended bit switch settings are as follows:
+
+ SW2 OFF(1)/ON(0) Description
+ ------------------------------------------
+ bit 1 <---- BKSZ[0]
+ bit 2 ----> BKSZ[1]
+ bit 3 <---- SoC Bus Width 16/32
+ bit 4 <---- SERIAL_SEL[0]
+ bit 5 ----> SERIAL_SEL[1]
+ bit 6 ----> BOOTSWAP_EN
+ bit 7 <---- CS1/CS5
+ bit 8 <---- SOC_SERIAL_DISABLE
+
+ SW8 OFF(1)/ON(0) Description
+ ------------------------------------------
+ bit 1 <---- CS1_SPLIT
+ bit 2 <---- CASE9_ON
+ bit 3 <---- CASE10_ON
+ bit 4 Don't Care Reserve
+ bit 5 Don't Care Reserve
+ bit 6 Don't Care Reserve
+ bit 7 ----> BURST_EN
+ bit 8 ----> FLASHBUS32_16
+
+The BKSZ[1:0] specifies the address range of memory slot and peripherals
+as follows:
+
+ BKSZ Description RAM slot Peripherals
+ --------------------------------------------------------------------
+ 0b00 15MB RAM / 1MB Peri 00000000-00efffff 00f00000-00ffffff
+ 0b01 31MB RAM / 1MB Peri 00000000-01efffff 01f00000-01ffffff
+ 0b10 64MB RAM / 1MB Peri 00000000-03efffff 03f00000-03ffffff
+ 0b11 127MB RAM / 1MB Peri 00000000-07efffff 07f00000-07ffffff
+
+Set BSKZ[1:0] to 0b01 for U-Boot.
+This mode is the most handy because EA[24] is always supported by the save pin
+mode of the system bus. On the other hand, EA[25] is not supported for some
+newer SoCs. Even if it is, EA[25] is not connected on most of the boards.
+
+--
+Masahiro Yamada <yamada.masahiro@socionext.com>
+Oct. 2017
diff --git a/roms/u-boot/doc/README.update b/roms/u-boot/doc/README.update
new file mode 100644
index 000000000..bf4379279
--- /dev/null
+++ b/roms/u-boot/doc/README.update
@@ -0,0 +1,97 @@
+Automatic software update from a TFTP server
+============================================
+
+Overview
+--------
+
+This feature allows to automatically store software updates present on a TFTP
+server in NOR Flash. In more detail: a TFTP transfer of a file given in
+environment variable 'updatefile' from server 'serverip' is attempted during
+boot. The update file should be a FIT file, and can contain one or more
+updates. Each update in the update file has an address in NOR Flash where it
+should be placed, updates are also protected with a SHA-1 checksum. If the
+TFTP transfer is successful, the hash of each update is verified, and if the
+verification is positive, the update is stored in Flash.
+
+The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
+
+#define CONFIG_UPDATE_TFTP 1
+
+
+Note that when enabling auto-update, Flash support must be turned on. Also,
+one must enable FIT and LIBFDT support:
+
+#define CONFIG_FIT 1
+#define CONFIG_OF_LIBFDT 1
+
+The auto-update feature uses the following configuration knobs:
+
+- CONFIG_UPDATE_LOAD_ADDR
+
+ Normally, TFTP transfer of the update file is done to the address specified
+ in environment variable 'loadaddr'. If this variable is not present, the
+ transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
+ by default).
+
+- CONFIG_UPDATE_TFTP_CNT_MAX
+ CONFIG_UPDATE_TFTP_MSEC_MAX
+
+ These knobs control the timeouts during initial connection to the TFTP
+ server. Since a transfer is attempted during each boot, it is undesirable to
+ have a long delay when a TFTP server is not present.
+ CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
+ the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
+ gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
+ be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
+ positive and is 100 by default.
+
+Since the update file is in FIT format, it is created from an *.its file using
+the mkimage tool. dtc tool with support for binary includes, e.g. in version
+1.2.0 or later, must also be available on the system where the update file is
+to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
+images.
+
+
+Example .its files
+------------------
+
+- doc/uImage.FIT/update_uboot.its
+
+ A simple example that can be used to create an update file for automatically
+ replacing U-Boot image on a system.
+
+ Assuming that an U-Boot image u-boot.bin is present in the current working
+ directory, and that the address given in the 'load' property in the
+ 'update_uboot.its' file is where the U-Boot is stored in Flash, the
+ following command will create the actual update file 'update_uboot.itb':
+
+ mkimage -f update_uboot.its update_uboot.itb
+
+ Place 'update_uboot.itb' on a TFTP server, for example as
+ '/tftpboot/update_uboot.itb', and set the 'updatefile' variable
+ appropriately, for example in the U-Boot prompt:
+
+ setenv updatefile /tftpboot/update_uboot.itb
+ saveenv
+
+ Now, when the system boots up and the update TFTP server specified in the
+ 'serverip' environment variable is accessible, the new U-Boot image will be
+ automatically stored in Flash.
+
+ NOTE: do make sure that the 'u-boot.bin' image used to create the update
+ file is a good, working image. Also make sure that the address in Flash
+ where the update will be placed is correct. Making mistake here and
+ attempting the auto-update can render the system unusable.
+
+- doc/uImage.FIT/update3.its
+
+ An example containing three updates. It can be used to update Linux kernel,
+ ramdisk and FDT blob stored in Flash. The procedure for preparing the update
+ file is similar to the example above.
+
+TFTP update via DFU
+-------------------
+
+- It is now possible to update firmware (bootloader, kernel, rootfs, etc.) via
+ TFTP by using DFU (Device Firmware Upgrade). More information can be found in
+ ./doc/README.dfutftp documentation entry.
diff --git a/roms/u-boot/doc/README.usb b/roms/u-boot/doc/README.usb
new file mode 100644
index 000000000..05c62c341
--- /dev/null
+++ b/roms/u-boot/doc/README.usb
@@ -0,0 +1,231 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2001
+ * Denis Peter, MPL AG Switzerland
+ */
+
+USB Support
+===========
+
+The USB support is implemented on the base of the UHCI Host
+controller.
+
+Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
+flash sticks and USB network adaptors.
+Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
+
+How it works:
+-------------
+
+The USB (at least the USB UHCI) needs a frame list (4k), transfer
+descripor and queue headers which are all located in the main memory.
+The UHCI allocates every milisecond the PCI bus and reads the current
+frame pointer. This may cause to crash the OS during boot. So the USB
+_MUST_ be stopped during OS boot. This is the reason, why the USB is
+NOT automatically started during start-up. If someone needs the USB
+he has to start it and should therefore be aware that he had to stop
+it before booting the OS.
+
+For USB keyboards this can be done by a script which is automatically
+started after the U-Boot is up and running. To boot an OS with a an
+USB keyboard another script is necessary, which first disables the
+USB and then executes the boot command. If the boot command fails,
+the script can reenable the USB kbd.
+
+Common USB Commands:
+- usb start:
+- usb reset: (re)starts the USB. All USB devices will be
+ initialized and a device tree is build for them.
+- usb tree: shows all USB devices in a tree like display
+- usb info [dev]: shows all USB infos of the device dev, or of all
+ the devices
+- usb stop [f]: stops the USB. If f==1 the USB will also stop if
+ an USB keyboard is assigned as stdin. The stdin
+ is then switched to serial input.
+Storage USB Commands:
+- usb scan: scans the USB for storage devices.The USB must be
+ running for this command (usb start)
+- usb device [dev]: show or set current USB storage device
+- usb part [dev]: print partition table of one or all USB storage
+ devices
+- usb read addr blk# cnt:
+ read `cnt' blocks starting at block `blk#'to
+ memory address `addr'
+- usbboot addr dev:part:
+ boot from USB device
+
+Config Switches:
+----------------
+CONFIG_CMD_USB enables basic USB support and the usb command
+CONFIG_USB_UHCI defines the lowlevel part.A lowlevel part must be defined
+ if using CONFIG_CMD_USB
+CONFIG_USB_KEYBOARD enables the USB Keyboard
+CONFIG_USB_STORAGE enables the USB storage devices
+CONFIG_USB_HOST_ETHER enables USB ethernet adapter support
+
+
+USB Host Networking
+===================
+
+If you have a supported USB Ethernet adapter you can use it in U-Boot
+to obtain an IP address and load a kernel from a network server.
+
+Note: USB Host Networking is not the same as making your board act as a USB
+client. In that case your board is pretending to be an Ethernet adapter
+and will appear as a network interface to an attached computer. In that
+case the connection is via a USB cable with the computer acting as the host.
+
+With USB Host Networking, your board is the USB host. It controls the
+Ethernet adapter to which it is directly connected and the connection to
+the outside world is your adapter's Ethernet cable. Your board becomes an
+independent network device, able to connect and perform network operations
+independently of your computer.
+
+
+Device support
+--------------
+
+Currently supported devices are listed in the drivers according to
+their vendor and product IDs. You can check your device by connecting it
+to a Linux machine and typing 'lsusb'. The drivers are in
+drivers/usb/eth.
+
+For example this lsusb output line shows a device with Vendor ID 0x0x95
+and product ID 0x7720:
+
+Bus 002 Device 010: ID 0b95:7720 ASIX Electronics Corp. AX88772
+
+If you look at drivers/usb/eth/asix.c you will see this line within the
+supported device list, so we know this adapter is supported.
+
+ { 0x0b95, 0x7720 }, /* Trendnet TU2-ET100 V3.0R */
+
+If your adapter is not listed there is a still a chance that it will
+work. Try looking up the manufacturer of the chip inside your adapter.
+or take the adapter apart and look for chip markings. Then add a line
+for your vendor/product ID into the table of the appropriate driver,
+build U-Boot and see if it works. If not then there might be differences
+between the chip in your adapter and the driver. You could try to get a
+datasheet for your device and add support for it to U-Boot. This is not
+particularly difficult - you only need to provide support for four basic
+functions: init, halt, send and recv.
+
+
+Enabling USB Host Networking
+----------------------------
+
+The normal U-Boot commands are used with USB networking, but you must
+start USB first. For example:
+
+usb start
+setenv bootfile /tftpboot/uImage
+bootp
+
+
+To enable USB Host Ethernet in U-Boot, your platform must of course
+support USB with CONFIG_CMD_USB enabled and working. You will need to
+add some config settings to your board config:
+
+CONFIG_CMD_USB=y /* the 'usb' interactive command */
+CONFIG_USB_HOST_ETHER=y /* Enable USB Ethernet adapters */
+
+and one or more of the following for individual adapter hardware:
+
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_LAN75XX=y
+CONFIG_USB_ETHER_LAN78XX=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+
+As with built-in networking, you will also want to enable some network
+commands, for example:
+
+CONFIG_CMD_NET=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_DHCP=y
+
+and some bootp options, which tell your board to obtain its subnet,
+gateway IP, host name and boot path from the bootp/dhcp server. These
+settings should start you off:
+
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_BOOTPATH
+
+You can also set the default IP address of your board and the server
+as well as the default file to load when a 'bootp' command is issued.
+However note that encoding these individual network settings into a
+common exectuable is discouraged, as it leads to potential conflicts,
+and all the parameters can either get stored in the board's external
+environment, or get obtained from the bootp server if not set.
+
+#define CONFIG_IPADDR 10.0.0.2 (replace with your value)
+#define CONFIG_SERVERIP 10.0.0.1 (replace with your value)
+#define CONFIG_BOOTFILE "uImage"
+
+
+The 'usb start' command should identify the adapter something like this:
+
+CrOS> usb start
+(Re)start USB...
+USB EHCI 1.00
+scanning bus for devices... 3 USB Device(s) found
+ scanning bus for storage devices... 0 Storage Device(s) found
+ scanning bus for ethernet devices... 1 Ethernet Device(s) found
+CrOS> print ethact
+ethact=asx0
+
+You can see that it found an ethernet device and we can print out the
+device name (asx0 in this case).
+
+Then 'bootp' or 'dhcp' should use it to obtain an IP address from DHCP,
+perhaps something like this:
+
+CrOS> bootp
+Waiting for Ethernet connection... done.
+BOOTP broadcast 1
+BOOTP broadcast 2
+DHCP client bound to address 172.22.73.81
+Using asx0 device
+TFTP from server 172.22.72.144; our IP address is 172.22.73.81
+Filename '/tftpboot/uImage-sjg-seaboard-261347'.
+Load address: 0x40c000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ ################################################
+done
+Bytes transferred = 3557464 (364858 hex)
+CrOS>
+
+
+Another way of doing this is to issue a tftp command, which will cause the
+bootp to happen automatically.
+
+
+MAC Addresses
+-------------
+
+Most Ethernet dongles have a built-in MAC address which is unique in the
+world. This is important so that devices on the network can be
+distinguised from each other. MAC address conflicts are evil and
+generally result in strange and eratic behaviour.
+
+Some boards have USB Ethernet chips on-board, and these sometimes do not
+have an assigned MAC address. In this case it is up to you to assign
+one which is unique. You should obtain a valid MAC address from a range
+assigned to you before you ship the product.
+
+Built-in Ethernet adapters support setting the MAC address by means of
+an ethaddr environment variable for each interface (ethaddr, eth1addr,
+eth2addr). There is similar support on the USB network side, using the
+names usbethaddr, usbeth1addr, etc. They are kept separate since we
+don't want a USB device taking the MAC address of a built-in device or
+vice versa.
+
+So if your USB Ethernet chip doesn't have a MAC address available then
+you must set usbethaddr to a suitable MAC address. At the time of
+writing this functionality is only supported by the SMSC driver.
diff --git a/roms/u-boot/doc/README.vf610 b/roms/u-boot/doc/README.vf610
new file mode 100644
index 000000000..38cf5cfd2
--- /dev/null
+++ b/roms/u-boot/doc/README.vf610
@@ -0,0 +1,10 @@
+U-Boot for Freescale Vybrid VF610
+
+This file contains information for the port of U-Boot to the Freescale Vybrid
+VF610 SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the
+ 32 lsbs in word 3.
diff --git a/roms/u-boot/doc/README.video b/roms/u-boot/doc/README.video
new file mode 100644
index 000000000..ced35bd2d
--- /dev/null
+++ b/roms/u-boot/doc/README.video
@@ -0,0 +1,97 @@
+SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ */
+
+"video-mode" environment variable
+=================================
+
+The 'video-mode' environment variable can be used to enable and configure
+some video drivers. The format matches the video= command-line option used
+for Linux:
+
+ video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string>
+
+ <driver> The video driver name, ignored by U-Boot
+ <xres> The X resolution (in pixels) to use.
+ <yres> The Y resolution (in pixels) to use.
+ <depth> The color depth (in bits) to use.
+ <freq> The frequency (in Hz) to use.
+ <options> A comma-separated list of device-specific options
+
+
+U-Boot MPC8xx video controller driver
+=====================================
+
+The driver has been tested with the following configurations:
+
+- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
+
+Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi
+
+
+U-Boot sunxi video controller driver
+====================================
+
+U-Boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output
+requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set.
+
+The sunxi U-Boot driver supports the following video-mode options:
+
+- monitor=[none|dvi|hdmi|lcd|vga|composite-*] - Select the video output to use
+ none: Disable video output.
+ dvi/hdmi: Selects output over the hdmi connector with dvi resp. hdmi output
+ format, if edid is used the format is automatically selected.
+ lcd: Selects video output to a LCD screen.
+ vga: Selects video output over the VGA connector.
+ composite-pal/composite-ntsc/composite-pal-m/composite-pal-nc:
+ Selects composite video output, note the specified resolution is
+ ignored with composite video output.
+ Defaults to monitor=dvi.
+
+- hpd=[0|1] - Enable use of the hdmi HotPlug Detect feature
+ 0: Disabled. Configure dvi/hdmi output even if no cable is detected
+ 1: Enabled. Fallback to the lcd / vga / none in that order (if available)
+ Defaults to hpd=1.
+
+- hpd_delay=<int> - How long to wait for the hdmi HPD signal in milliseconds
+ When the monitor and the board power up at the same time, it may take some
+ time for the monitor to assert the HPD signal. This configures how long to
+ wait for the HPD signal before assuming no cable is connected.
+ Defaults to hpd_delay=500.
+
+- edid=[0|1] - Enable use of DDC + EDID to get monitor info
+ 0: Disabled.
+ 1: Enabled. If valid EDID info was read from the monitor the EDID info will
+ overrides the xres, yres and refresh from the video-mode env. variable.
+ Defaults to edid=1.
+
+- overscan_x/overscan_y=<int> - Set x/y overscan value
+ This configures a black border on the left and right resp. top and bottom
+ to deal with overscanning displays. Defaults to overscan_x=32 and
+ overscan_y=20 for composite monitors, 0 for other monitors.
+
+For example to always use the hdmi connector, even if no cable is inserted,
+using edid info when available and otherwise initalizing it at 1024x768@60Hz,
+use: "setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=1".
+
+
+TrueType fonts
+--------------
+
+U-Boot supports the use of antialiased TrueType fonts on some platforms. This
+has been tested in x86, ARMv7 and sandbox.
+
+To enable this, select CONFIG_CONSOLE_TRUETYPE. You can choose between several
+fonts, with CONSOLE_TRUETYPE_NIMBUS being the default.
+
+TrueType support requires floating point at present. On ARMv7 platforms you
+need to disable use of the private libgcc. You can do this by disabling
+CONFIG_USE_PRIVATE_LIBGCC. See chromebook_jerry for an example. Note that this
+increases U-Boot's size by about 70KB at present.
+
+On ARM you should also make sure your toolchain supports hardfp. This is
+normally given in the name of your toolchain, e.g. arm-linux-gnueabihf (hf
+means hardware floating point). You can also run gcc with -v to see if it has
+this option.
diff --git a/roms/u-boot/doc/README.vxworks b/roms/u-boot/doc/README.vxworks
new file mode 100644
index 000000000..12a0d744d
--- /dev/null
+++ b/roms/u-boot/doc/README.vxworks
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2013, Miao Yan <miao.yan@windriver.com>
+# Copyright (C) 2015-2018, Bin Meng <bmeng.cn@gmail.com>
+# Copyright (C) 2019, Lihua Zhao <lihua.zhao@windriver.com>
+
+VxWorks Support
+===============
+
+This document describes the information about U-Boot loading VxWorks kernel.
+
+Status
+------
+U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands.
+For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions
+on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels
+on PowerPC and ARM, 'bootm' shall be used.
+
+With CONFIG_EFI_LOADER option, it's possible to chain load a VxWorks x86 kernel
+via the UEFI boot loader application for VxWorks loaded by 'bootefi' command.
+
+VxWorks 7 on PowerPC and ARM
+---------------------------
+From VxWorks 7, VxWorks starts adopting device tree as its hardware description
+mechanism (for PowerPC and ARM), thus requiring boot interface changes.
+This section will describe the new interface.
+
+Since VxWorks 7 SR0640 release, VxWorks starts using Linux compatible standard
+DTB for some boards. With that, the exact same bootm flow as used by Linux is
+used, which includes board-specific DTB fix up. To keep backward compatibility,
+only when the least significant bit of flags in bootargs is set, the standard
+DTB will be used. Otherwise it falls back to the legacy bootm flow.
+
+For legacy bootm flow, make sure the least significant bit of flags in bootargs
+is cleared. The calling convention is described below:
+
+For PowerPC, the calling convention of the new VxWorks entry point conforms to
+the ePAPR standard, which is shown below (see ePAPR for more details):
+
+ void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
+
+For ARM, the calling convention is shown below:
+
+ void (*kernel_entry)(void *fdt_addr)
+
+When using the Linux compatible standard DTB, the calling convention of VxWorks
+entry point is exactly the same as the Linux kernel.
+
+When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
+is like below:
+
+ bootm <kernel image address> - <device tree address>
+
+VxWorks bootline
+----------------
+When using 'bootvx', the kernel bootline must be prepared by U-Boot at a
+board-specific address before loading VxWorks. U-Boot supplies its address
+via "bootaddr" environment variable. To check where the bootline should be
+for a specific board, go to the VxWorks BSP for that board, and look for a
+parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
+value for "bootaddr" on an x86 board is 0x101200.
+
+If a "bootargs" variable is defined, its content will be copied to the memory
+location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
+there, command 'bootvx' can construct a valid bootline using the following
+environments variables: bootdev, bootfile, ipaddr, netmask, serverip,
+gatewayip, hostname, othbootargs.
+
+When using 'bootm', just define "bootargs" in the environment and U-Boot will
+handle bootline fix up for the kernel dtb automatically.
+
+When using 'bootefi' to chain load an x86 kernel, the UEFI boot loader
+application for VxWorks takes care of the kernel bootline preparation.
+
+Serial console
+--------------
+It's very common that VxWorks BSPs configure a different baud rate for the
+serial console from what is being used by U-Boot. For example, VxWorks tends
+to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200.
+Please configure both U-Boot and VxWorks to use the same baud rate, or it may
+look like VxWorks hangs somewhere as nothing outputs on the serial console.
+
+x86-specific information
+------------------------
+Before direct loading an x86 kernel via 'bootvx', one additional environment
+variable need to be provided. This is "vx_phys_mem_base", which represent the
+physical memory base address of VxWorks.
+
+Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For
+VxWorks 7, this is normally a virtual address and you need find out its
+corresponding physical address and assign its value to "vx_phys_mem_base".
+
+For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
+be configured to use MP table and virtual wire interrupt mode. This requires
+INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
+VxWorks kernel configuration.
+
+Both 32-bit x86 and 64-bit x64 kernels can be loaded.
+
+There are two types of graphics console drivers in VxWorks. One is the 80x25
+VGA text mode driver. The other one is the EFI console bitmapped graphics mode
+driver. To make these drivers function, U-Boot needs to load and run the VGA
+BIOS of the graphics card first.
+
+ - If the kernel is configured with 80x25 VGA text mode driver,
+ CONFIG_FRAMEBUFFER_SET_VESA_MODE must be unset in U-Boot.
+ - If the kernel is configured with bitmapped graphics mode driver,
+ CONFIG_FRAMEBUFFER_SET_VESA_MODE need remain set but care must be taken
+ at which VESA mode is to be set. The supported pixel format is 32-bit
+ RGBA, hence the available VESA mode can only be one of the following:
+ * FRAMEBUFFER_VESA_MODE_10F
+ * FRAMEBUFFER_VESA_MODE_112
+ * FRAMEBUFFER_VESA_MODE_115
+ * FRAMEBUFFER_VESA_MODE_118
+ * FRAMEBUFFER_VESA_MODE_11B
diff --git a/roms/u-boot/doc/README.watchdog b/roms/u-boot/doc/README.watchdog
new file mode 100644
index 000000000..f23c92391
--- /dev/null
+++ b/roms/u-boot/doc/README.watchdog
@@ -0,0 +1,33 @@
+Watchdog driver general info
+
+CONFIG_HW_WATCHDOG
+ This enables hw_watchdog_reset to be called during various loops,
+ including waiting for a character on a serial port. But it
+ does not also call hw_watchdog_init. Boards which want this
+ enabled must call this function in their board file. This split
+ is useful because some rom's enable the watchdog when downloading
+ new code, so it must be serviced, but the board would rather it
+ was off. And, it cannot always be turned off once on.
+
+CONFIG_WATCHDOG_TIMEOUT_MSECS
+ Can be used to change the timeout for i.mx31/35/5x/6x.
+ If not given, will default to maximum timeout. This would
+ be 128000 msec for i.mx31/35/5x/6x.
+
+CONFIG_WDT_AT91
+ Available for AT91SAM9 to service the watchdog.
+
+CONFIG_FTWDT010_WATCHDOG
+ Available for FTWDT010 to service the watchdog.
+
+CONFIG_FTWDT010_HW_TIMEOUT
+ Can be used to change the timeout for FTWDT010.
+
+CONFIG_IMX_WATCHDOG
+ Available for i.mx31/35/5x/6x to service the watchdog. This is not
+ automatically set because some boards (vision2) still need to define
+ their own hw_watchdog_reset routine.
+ TODO: vision2 is removed now, so perhaps this can be changed.
+
+CONFIG_XILINX_TB_WATCHDOG
+ Available for Xilinx Axi platforms to service timebase watchdog timer.
diff --git a/roms/u-boot/doc/README.zfs b/roms/u-boot/doc/README.zfs
new file mode 100644
index 000000000..7f237c407
--- /dev/null
+++ b/roms/u-boot/doc/README.zfs
@@ -0,0 +1,29 @@
+This patch series adds support for ZFS listing and load to u-boot.
+
+To Enable zfs ls and load commands, modify the board specific config file with
+#define CONFIG_CMD_ZFS
+
+Steps to test:
+
+1. After applying the patch, zfs specific commands can be seen
+ in the boot loader prompt using
+ UBOOT #help
+
+ zfsload- load binary file from a ZFS file system
+ zfsls - list files in a directory (default /)
+
+2. To list the files in zfs pool, device or partition, execute
+ zfsls <interface> <dev[:part]> [POOL/@/dir/file]
+ For example:
+ UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/
+
+3. To read and load a file from an ZFS formatted partition to RAM, execute
+ zfsload <interface> <dev[:part]> [addr] [filename] [bytes]
+ For example:
+ UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage
+
+References :
+ -- ZFS GRUB sources from Solaris GRUB-0.97
+ -- GRUB Bazaar repository
+
+Jorgen Lundman <lundman at lundman.net> 2012.
diff --git a/roms/u-boot/doc/SPI/README.altera_spi b/roms/u-boot/doc/SPI/README.altera_spi
new file mode 100644
index 000000000..b07449f80
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.altera_spi
@@ -0,0 +1,6 @@
+SoCFPGA EPCS/EPCQx1 mini howto:
+- Instantiate EPCS/EPCQx1 Serial flash controller in QSys and rebuild
+- The controller base address is the "Base" in QSys + 0x400
+- Set MSEL[4:0]=10010 (AS Standard)
+- Load the bitstream into FPGA, enable bridges
+- Only then will the driver work
diff --git a/roms/u-boot/doc/SPI/README.ftssp010_spi_test b/roms/u-boot/doc/SPI/README.ftssp010_spi_test
new file mode 100644
index 000000000..1d86f3623
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.ftssp010_spi_test
@@ -0,0 +1,41 @@
+SPI Flash test on Faraday A369 EVB:
+==================================
+
+U-Boot 2014.01-rc2-g3444b6f (Dec 20 2013 - 10:58:40)
+
+CPU: FA626TE 528 MHz
+AHB: 132 MHz
+APB: 66 MHz
+I2C: ready
+DRAM: 256 MiB
+MMU: on
+NAND: 512 MiB
+MMC: ftsdc010: 0
+*** Warning - bad CRC, using default environment
+
+In: serial
+Out: serial
+Err: serial
+Net: FTGMAC100#0
+Hit any key to stop autoboot: 0
+=> sf probe 0:0
+SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB, total 2 MiB
+=> sf read 0x10800000 0 0x400
+SF: 1024 bytes @ 0x0 Read: OK
+=> md 0x10800000
+10800000: ea000013 e59ff014 e59ff014 e59ff014 ................
+10800010: e59ff014 e59ff014 e59ff014 e59ff014 ................
+10800020: 1ff7b0c0 1ff7b120 1ff7b180 1ff7b1e0 .... ...........
+10800030: 1ff7b240 1ff7b2a0 1ff7b300 deadbeef @...............
+10800040: 10800000 0002c1f0 0007409c 00032048 .........@..H ..
+10800050: 1fd6af40 e10f0000 e3c0001f e38000d3 @...............
+10800060: e129f000 eb000001 eb000223 e12fff1e ..).....#...../.
+10800070: e3a00000 ee070f1e ee080f17 ee070f15 ................
+10800080: ee070f9a ee110f10 e3c00c03 e3c00087 ................
+10800090: e3c00a02 e3800002 e3800a01 ee010f10 ................
+108000a0: e1a0c00e eb007a68 e1a0e00c e1a0f00e ....hz..........
+108000b0: e1a00000 e1a00000 e1a00000 e1a00000 ................
+108000c0: e51fd078 e58de000 e14fe000 e58de004 x.........O.....
+108000d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
+108000e0: e24dd048 e88d1fff e51f20a0 e892000c H.M...... ......
+108000f0: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
diff --git a/roms/u-boot/doc/SPI/README.sandbox-spi b/roms/u-boot/doc/SPI/README.sandbox-spi
new file mode 100644
index 000000000..f6a55fe78
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.sandbox-spi
@@ -0,0 +1,42 @@
+Sandbox SPI/SPI Flash Implementation
+====================================
+
+U-Boot supports SPI and SPI flash emulation in sandbox. This must be enabled
+via a device tree.
+
+For example:
+
+ spi@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 1>;
+ compatible = "sandbox,spi";
+ cs-gpios = <0>, <&gpio_a 0>;
+ spi.bin@0 {
+ reg = <0>;
+ compatible = "spansion,m25p16", "jedec,spi-nor";
+ spi-max-frequency = <40000000>;
+ sandbox,filename = "spi.bin";
+ };
+ };
+
+Supported chips are W25Q16 (2MB), W25Q32 (4MB) and W25Q128 (16MB). Once
+U-Boot it started you can use 'sf' commands as normal. For example:
+
+$ dd if=/dev/zero of=spi.bin bs=1M count=2
+$ u-boot -T
+
+Since the SPI bus is fully implemented as well as the SPI flash connected to
+it, you can also use low-level SPI commands to access the flash. For example
+this reads the device ID from the emulated chip:
+
+=> sspi 0 32 9f
+SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
+FF202015
+
+
+Simon Glass
+sjg@chromium.org
+7/11/2013
+Note that the sandbox SPI implementation was written by Mike Frysinger
+<vapier@gentoo.org>.
diff --git a/roms/u-boot/doc/SPI/README.sh_qspi_test b/roms/u-boot/doc/SPI/README.sh_qspi_test
new file mode 100644
index 000000000..8a33fec32
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.sh_qspi_test
@@ -0,0 +1,38 @@
+-------------------------------------------------
+ Simple steps used to test the SH-QSPI at U-Boot
+-------------------------------------------------
+
+#0, Currently, SH-QSPI is used by lager board (Renesas ARM SoC R8A7790)
+ and koelsch board (Renesas ARM SoC R8A7791). These boot from SPI ROM
+ basically. Thus, U-Boot start, SH-QSPI will is operating normally.
+
+#1, build U-Boot and load u-boot.bin
+
+ => tftpboot 40000000 u-boot.bin
+ sh_eth Waiting for PHY auto negotiation to complete.. done
+ sh_eth: 100Base/Half
+ Using sh_eth device
+ TFTP from server 192.168.169.1; our IP address is 192.168.169.79
+ Filename 'u-boot.bin'.
+ Load address: 0x40000000
+ Loading: ############
+ 2.5 MiB/s
+ done
+ Bytes transferred = 175364 (2ad04 hex)
+
+#2, Commands to erase/write u-boot to flash device
+
+ Note: This method is description of the lager board. If you want to use the
+ other boards, please change the value according to each environment.
+
+ => sf probe 0
+ SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 64 KiB, total 64 MiB
+ => sf erase 80000 40000
+ SF: 262144 bytes @ 0x80000 Erased: OK
+ => sf write 40000000 80000 175364
+ SF: 1528676 bytes @ 0x80000 Written: OK
+ =>
+
+#3, Push reset button.
+
+ If you're written correctly and driver works properly, U-Boot starts.
diff --git a/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test b/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test
new file mode 100644
index 000000000..8fbf10b57
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test
@@ -0,0 +1,76 @@
+Testing details-
+----------------
+
+This doc simply illustrated the testing details of qspi flash
+driver with Macronix M25L51235 flash device.
+
+The test includes
+- probing the flash device
+- erasing the flash device
+- Writing to flash
+- Reading the contents of the flash.
+
+Test Log
+--------
+
+Hit any key to stop autoboot: 0
+U-Boot# sf probe 0
+SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
+U-Boot# sf erase 0 0x80000
+SF: 524288 bytes @ 0x0 Erased: OK
+U-Boot# mw 81000000 0xdededede 0x40000
+U-Boot# sf write 81000000 0 0x40000
+SF: 262144 bytes @ 0x0 Written: OK
+U-Boot# sf read 82000000 0 0x40000
+SF: 262144 bytes @ 0x0 Read: OK
+U-Boot# md 0x82000000
+82000000: dededede dededede dededede dededede ................
+82000010: dededede dededede dededede dededede ................
+82000020: dededede dededede dededede dededede ................
+82000030: dededede dededede dededede dededede ................
+82000040: dededede dededede dededede dededede ................
+82000050: dededede dededede dededede dededede ................
+82000060: dededede dededede dededede dededede ................
+82000070: dededede dededede dededede dededede ................
+82000080: dededede dededede dededede dededede ................
+82000090: dededede dededede dededede dededede ................
+820000a0: dededede dededede dededede dededede ................
+820000b0: dededede dededede dededede dededede ................
+820000c0: dededede dededede dededede dededede ................
+820000d0: dededede dededede dededede dededede ................
+820000e0: dededede dededede dededede dededede ................
+820000f0: dededede dededede dededede dededede ................
+U-Boot# md 0x82010000
+82010000: dededede dededede dededede dededede ................
+82010010: dededede dededede dededede dededede ................
+82010020: dededede dededede dededede dededede ................
+82010030: dededede dededede dededede dededede ................
+82010040: dededede dededede dededede dededede ................
+82010050: dededede dededede dededede dededede ................
+82010060: dededede dededede dededede dededede ................
+82010070: dededede dededede dededede dededede ................
+82010080: dededede dededede dededede dededede ................
+82010090: dededede dededede dededede dededede ................
+820100a0: dededede dededede dededede dededede ................
+820100b0: dededede dededede dededede dededede ................
+820100c0: dededede dededede dededede dededede ................
+820100d0: dededede dededede dededede dededede ................
+820100e0: dededede dededede dededede dededede ................
+820100f0: dededede dededede dededede dededede ................
+U-Boot# md 0x82030000
+82030000: dededede dededede dededede dededede ................
+82030010: dededede dededede dededede dededede ................
+82030020: dededede dededede dededede dededede ................
+82030030: dededede dededede dededede dededede ................
+82030040: dededede dededede dededede dededede ................
+82030050: dededede dededede dededede dededede ................
+82030060: dededede dededede dededede dededede ................
+82030070: dededede dededede dededede dededede ................
+82030080: dededede dededede dededede dededede ................
+82030090: dededede dededede dededede dededede ................
+820300a0: dededede dededede dededede dededede ................
+820300b0: dededede dededede dededede dededede ................
+820300c0: dededede dededede dededede dededede ................
+820300d0: dededede dededede dededede dededede ................
+820300e0: dededede dededede dededede dededede ................
+820300f0: dededede dededede dededede dededede ................
diff --git a/roms/u-boot/doc/SPI/README.ti_qspi_dra_test b/roms/u-boot/doc/SPI/README.ti_qspi_dra_test
new file mode 100644
index 000000000..e89f53587
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.ti_qspi_dra_test
@@ -0,0 +1,47 @@
+-------------------------------------------------
+ Simple steps used to test the QSPI at U-Boot
+-------------------------------------------------
+
+For #1, build the patched U-Boot and load MLO/u-boot.img
+
+----------------------------------
+Boot from another medium like MMC
+----------------------------------
+
+U-Boot# mmc dev 0
+mmc0 is current device
+U-Boot# fatload mmc 0 0x82000000 MLO
+reading MLO
+55872 bytes read in 8 ms (6.7 MiB/s)
+U-Boot# fatload mmc 0 0x83000000 u-boot.img
+reading u-boot.img
+248600 bytes read in 19 ms (12.5 MiB/s)
+
+--------------------------------------------------
+Commands to erase/write u-boot/mlo to flash device
+--------------------------------------------------
+U-Boot# sf probe 0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
+U-Boot# sf erase 0 0x10000
+SF: 65536 bytes @ 0x0 Erased: OK
+U-Boot# sf erase 0x20000 0x10000
+SF: 65536 bytes @ 0x20000 Erased: OK
+U-Boot# sf erase 0x30000 0x10000
+SF: 65536 bytes @ 0x30000 Erased: OK
+U-Boot# sf erase 0x40000 0x10000
+SF: 65536 bytes @ 0x40000 Erased: OK
+U-Boot# sf erase 0x50000 0x10000
+SF: 65536 bytes @ 0x50000 Erased: OK
+U-Boot# sf erase 0x60000 0x10000
+SF: 65536 bytes @ 0x60000 Erased: OK
+U-Boot# sf write 82000000 0 0x10000
+SF: 65536 bytes @ 0x0 Written: OK
+U-Boot# sf write 83000000 0x20000 0x60000
+SF: 393216 bytes @ 0x20000 Written: OK
+
+For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
+on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
+then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
+find a U-Boot image header at offset 0x20000 (set in the config file)
+and proceeds to load that image using the U-Boot image payload offset/size
+from the header. It will then start U-Boot.
diff --git a/roms/u-boot/doc/SPI/README.ti_qspi_flash b/roms/u-boot/doc/SPI/README.ti_qspi_flash
new file mode 100644
index 000000000..5cc1fd03b
--- /dev/null
+++ b/roms/u-boot/doc/SPI/README.ti_qspi_flash
@@ -0,0 +1,47 @@
+QSPI U-Boot support
+------------------
+
+Host processor is connected to serial flash device via qpsi
+interface. QSPI is a kind of spi module that allows single,
+dual and quad read access to external spi devices. The module
+has a memory mapped interface which provide direct interface
+for accessing data form external spi devices.
+
+The one QSPI in the device is primarily intended for fast booting
+from Quad SPI flash devices.
+
+Usecase
+-------
+
+MLO/u-boot.img will be flashed from SD/MMC to the flash device
+using serial flash erase and write commands. Then, switch settings
+will be changed to qspi boot. Then, the ROM code will read MLO
+from the predefined location in the flash, where it was flashed and
+execute it after storing it in SDRAM. Then, the MLO will read
+u-boot.img from flash and execute it from SDRAM.
+
+SPI mode
+-------
+SPI mode uses mtd spi framework for transfer and reception of data.
+Can be used in:
+1. Normal mode: use single pin for transfers
+2. Dual Mode: use two pins for transfers.
+3. Quad mode: use four pin for transfer
+
+Memory mapped read mode
+-----------------------
+In this, SPI controller is configured using configuration port and then
+controller is switched to memory mapped port for data read.
+
+Driver
+------
+drivers/qspi/ti_qspi.c
+ - Newly created file which is responsible for configuring the
+ qspi controller and also for providing the low level api which
+ is responsible for transferring the datas from host controller
+ to flash device and vice versa.
+
+Testing
+-------
+A seperated file named README.dra_qspi_test has been created which gives all the
+details about the commands required to test qspi at U-Boot level.
diff --git a/roms/u-boot/doc/SPI/status.txt b/roms/u-boot/doc/SPI/status.txt
new file mode 100644
index 000000000..13889f545
--- /dev/null
+++ b/roms/u-boot/doc/SPI/status.txt
@@ -0,0 +1,32 @@
+Status on SPI subsystem:
+=======================
+
+SPI COMMAND (common/cmd_sf, cmd_spi):
+-
+
+SPI FLASH (drivers/mtd/spi):
+- sf_probe.c: SPI flash probing code.
+- sf_ops.c: SPI flash operations code.
+- sf.c: SPI flash interface, which interacts controller driver.
+- Bank Address Register (Accessing flashes > 16Mbytes in 3-byte addressing)
+- Added memory_mapped support for read operations.
+- Common probe support for all supported flash vendors except, ramtron.
+- Extended read commands support(dual read, dual IO read)
+- Quad Page Program support.
+- Quad Read support(quad fast read, quad IO read)
+- Dual flash connection topology support(accessing two spi flash memories with single cs)
+- Banking support on dual flash connection topology.
+
+SPI DRIVERS (drivers/spi):
+-
+
+TODO:
+- Runtime detection of spi_flash params, SFDP(if possible)
+- Add support for multibus build/accessing.
+- Need proper cleanups on spi_flash and drivers.
+
+--
+Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+18-09-2013.
+07-10-2013.
+08-01-2014.
diff --git a/roms/u-boot/doc/SPL/README.am335x-network b/roms/u-boot/doc/SPL/README.am335x-network
new file mode 100644
index 000000000..e3cf93f8d
--- /dev/null
+++ b/roms/u-boot/doc/SPL/README.am335x-network
@@ -0,0 +1,96 @@
+USING AM335x NETBOOT FEATURE
+
+ Some boards (like TI AM335x based ones) have quite big on-chip RAM and
+have support for booting via network in ROM. The following describes
+how to setup network booting and then optionally use this support to flash
+NAND and bricked (empty) board with only a network cable.
+
+ I. Building the required images
+ 1. You have to enable generic SPL configuration options (see
+doc/README.SPL) as well as CONFIG_SPL_NET_SUPPORT,
+CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and
+CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build
+SPL with support for booting over the network. Also you have to enable
+the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your
+board needs some board-specific initialization (TI AM335x EVM does).
+If you want SPL to use some Vendor Class Identifier (VCI) you can set
+one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration
+comes with support for network booting preconfigured.
+ 2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick
+script after boot:
+#define CONFIG_BOOTCOMMAND \
+ "setenv autoload no; " \
+ "bootp; " \
+ "if tftp 80000000 debrick.scr; then " \
+ "source 80000000; " \
+ "fi"
+(Or create additional board configuration with such option).
+ 3. Build U-Boot as usual
+ $ make <your_board_name>
+ You will need u-boot.img and spl/u-boot.bin images to perform
+network boot. Copy them to u-boot-restore.img and
+u-boot-spl-restore.bin respectively to distinguish this version
+(with automatic restore running) from the main one.
+
+ II. Host configuration.
+ 1. Setup DHCP server (recommended server is ISC DHCPd).
+ - Install DHCP server and setup it to listen on the interface you
+chose to connect to the board (usually configured in
+/etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there
+are no other active DHCP servers in the same network segment.
+ - Edit your dhcpd.conf and subnet declaration matching the address
+on the interface. Specify the range of assigned addresses and bootfile
+to use. IMPORTANT! Both RBL and SPL use the image filename provided
+in the BOOTP reply but obviously they need different images (RBL needs
+raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot
+image -- u-boot-restore.img). So you have to configure DHCP server to
+provide different image filenames to RBL and SPL (and possibly another
+one to main U-Boot). This can be done by checking Vendor Class
+Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0"
+and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option,
+see above).
+ - If you plan to use TFTP server on another machine you have to set
+server-name option to point to it.
+ - Here is sample configuration for ISC DHCPd, assuming the interface
+used to connect to the board is eth0, and it has address 192.168.8.1:
+
+subnet 192.168.8.0 netmask 255.255.255.0 {
+ range dynamic-bootp 192.168.8.100 192.168.8.199;
+
+ if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
+ filename "u-boot-spl-restore.bin";
+ } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
+ filename "u-boot-restore.img";
+ } else {
+ filename "uImage";
+ }
+}
+
+ May the ROM bootloader sends another "vendor-class-identifier"
+ on the shc board with an AM335X it is:
+ "AM335x ROM"
+
+ 2. Setup TFTP server.
+ Install TFTP server and put image files to it's root directory
+(likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need
+u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory.
+
+ III. Reflashing (debricking) the board.
+ 1. Write debrick script. You will need to write a script that will
+be executed after network boot to perform actual rescue actions. You
+can use usual U-Boot commands from this script: tftp to load additional
+files, nand erase/nand write to erase/write the NAND flash.
+
+ 2. Create script image from your script. From U-Boot build directory:
+
+$ ./tools/mkimage -A arm -O U-Boot -C none -T script -d <your script> debrick.scr
+
+This will create debrick.scr file with your script inside.
+
+ 3. Copy debrick.scr to TFTP root directory. You also need to copy
+there all the files your script tries to load via TFTP. Example script
+loads u-boot.img and MLO. You have to create these files doing regular
+(not restore_flash) build and copy them to tftpboot directory.
+
+ 4. Boot the board from the network, U-Boot will load debrick script
+and run it after boot.
diff --git a/roms/u-boot/doc/SPL/README.omap3 b/roms/u-boot/doc/SPL/README.omap3
new file mode 100644
index 000000000..c77ca4300
--- /dev/null
+++ b/roms/u-boot/doc/SPL/README.omap3
@@ -0,0 +1,52 @@
+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
+0x4020E000 - 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
+0x4020E000 - 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.
diff --git a/roms/u-boot/doc/SPL/README.spl-secure-boot b/roms/u-boot/doc/SPL/README.spl-secure-boot
new file mode 100644
index 000000000..f2f8d7888
--- /dev/null
+++ b/roms/u-boot/doc/SPL/README.spl-secure-boot
@@ -0,0 +1,18 @@
+Overview of SPL verified boot on powerpc/mpc85xx & arm/layerscape platforms
+===========================================================================
+
+Introduction
+------------
+
+This document provides an overview of how SPL verified boot works on powerpc/
+mpc85xx & arm/layerscape platforms.
+
+Methodology
+-----------
+
+The SPL image is responsible for loading the next stage boot loader, which is
+the main u-boot image. For secure boot process on these platforms ROM verifies
+SPL image, so to continue chain of trust SPL image verifies U-boot image using
+spl_validate_uboot(). This function uses QorIQ Trust Architecture header
+(appended to U-boot image) to validate the U-boot binary just before passing
+control to it.
diff --git a/roms/u-boot/doc/android/ab.rst b/roms/u-boot/doc/android/ab.rst
new file mode 100644
index 000000000..961895c32
--- /dev/null
+++ b/roms/u-boot/doc/android/ab.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Android A/B updates
+===================
+
+Overview
+--------
+
+A/B system updates ensures modern approach for system update. This feature
+allows one to use two sets (or more) of partitions referred to as slots
+(normally slot A and slot B). The system runs from the current slot while the
+partitions in the unused slot can be updated [1]_.
+
+A/B enablement
+--------------
+
+The A/B updates support can be activated by specifying next options in
+your board configuration file::
+
+ CONFIG_ANDROID_AB=y
+ CONFIG_CMD_AB_SELECT=y
+
+The disk space on target device must be partitioned in a way so that each
+partition which needs to be updated has two or more instances. The name of
+each instance must be formed by adding suffixes: ``_a``, ``_b``, ``_c``, etc.
+For example: ``boot_a``, ``boot_b``, ``system_a``, ``system_b``, ``vendor_a``,
+``vendor_b``.
+
+As a result you can use ``ab_select`` command to ensure A/B boot process in your
+boot script. This command analyzes and processes A/B metadata stored on a
+special partition (e.g. ``misc``) and determines which slot should be used for
+booting up.
+
+Command usage
+-------------
+
+.. code-block:: none
+
+ ab_select <slot_var_name> <interface> <dev[:part_number|#part_name]>
+
+for example::
+
+ => ab_select slot_name mmc 1:4
+
+or::
+
+ => ab_select slot_name mmc 1#misc
+
+Result::
+
+ => printenv slot_name
+ slot_name=a
+
+Based on this slot information, the current boot partition should be defined,
+and next kernel command line parameters should be generated:
+
+* ``androidboot.slot_suffix=``
+* ``root=``
+
+For example::
+
+ androidboot.slot_suffix=_a root=/dev/mmcblk1p12
+
+A/B metadata is organized according to AOSP reference [2]_. On the first system
+start with A/B enabled, when ``misc`` partition doesn't contain required data,
+the default A/B metadata will be created and written to ``misc`` partition.
+
+References
+----------
+
+.. [1] https://source.android.com/devices/tech/ota/ab
+.. [2] https://android.googlesource.com/platform/bootable/recovery/+/refs/tags/android-10.0.0_r25/bootloader_message/include/bootloader_message/bootloader_message.h
diff --git a/roms/u-boot/doc/android/avb2.rst b/roms/u-boot/doc/android/avb2.rst
new file mode 100644
index 000000000..a07211957
--- /dev/null
+++ b/roms/u-boot/doc/android/avb2.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Android Verified Boot 2.0
+=========================
+
+This file contains information about the current support of Android Verified
+Boot 2.0 in U-Boot.
+
+Overview
+--------
+
+Verified Boot establishes a chain of trust from the bootloader to system images:
+
+* Provides integrity checking for:
+
+ * Android Boot image: Linux kernel + ramdisk. RAW hashing of the whole
+ partition is done and the hash is compared with the one stored in
+ the VBMeta image
+ * ``system``/``vendor`` partitions: verifying root hash of dm-verity hashtrees
+
+* Provides capabilities for rollback protection
+
+Integrity of the bootloader (U-Boot BLOB and environment) is out of scope.
+
+For additional details check [1]_.
+
+AVB using OP-TEE (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If AVB is configured to use OP-TEE (see `Enable on your board`_) rollback
+indexes and device lock state are stored in RPMB. The RPMB partition is managed
+by OP-TEE (see [2]_ for details) which is a secure OS leveraging ARM
+TrustZone.
+
+AVB 2.0 U-Boot shell commands
+-----------------------------
+
+Provides CLI interface to invoke AVB 2.0 verification + misc. commands for
+different testing purposes::
+
+ avb init <dev> - initialize avb 2.0 for <dev>
+ avb verify - run verification process using hash data from vbmeta structure
+ avb read_rb <num> - read rollback index at location <num>
+ avb write_rb <num> <rb> - write rollback index <rb> to <num>
+ avb is_unlocked - returns unlock status of the device
+ avb get_uuid <partname> - read and print uuid of partition <partname>
+ avb read_part <partname> <offset> <num> <addr> - read <num> bytes from
+ partition <partname> to buffer <addr>
+ avb write_part <partname> <offset> <num> <addr> - write <num> bytes to
+ <partname> by <offset> using data from <addr>
+
+Partitions tampering (example)
+------------------------------
+
+Boot or system/vendor (dm-verity metadata section) is tampered::
+
+ => avb init 1
+ => avb verify
+ avb_slot_verify.c:175: ERROR: boot: Hash of data does not match digest in
+ descriptor.
+ Slot verification result: ERROR_IO
+
+Vbmeta partition is tampered::
+
+ => avb init 1
+ => avb verify
+ avb_vbmeta_image.c:206: ERROR: Hash does not match!
+ avb_slot_verify.c:388: ERROR: vbmeta: Error verifying vbmeta image:
+ HASH_MISMATCH
+ Slot verification result: ERROR_IO
+
+Enable on your board
+--------------------
+
+The following options must be enabled::
+
+ CONFIG_LIBAVB=y
+ CONFIG_AVB_VERIFY=y
+ CONFIG_CMD_AVB=y
+
+In addtion optionally if storing rollback indexes in RPMB with help of
+OP-TEE::
+
+ CONFIG_TEE=y
+ CONFIG_OPTEE=y
+ CONFIG_OPTEE_TA_AVB=y
+ CONFIG_SUPPORT_EMMC_RPMB=y
+
+Then add ``avb verify`` invocation to your android boot sequence of commands,
+e.g.::
+
+ => avb_verify=avb init $mmcdev; avb verify;
+ => if run avb_verify; then \
+ echo AVB verification OK. Continue boot; \
+ set bootargs $bootargs $avb_bootargs; \
+ else \
+ echo AVB verification failed; \
+ exit; \
+ fi; \
+
+ => emmc_android_boot= \
+ echo Trying to boot Android from eMMC ...; \
+ ... \
+ run avb_verify; \
+ mmc read ${fdtaddr} ${fdt_start} ${fdt_size}; \
+ mmc read ${loadaddr} ${boot_start} ${boot_size}; \
+ bootm $loadaddr $loadaddr $fdtaddr; \
+
+If partitions you want to verify are slotted (have A/B suffixes), then current
+slot suffix should be passed to ``avb verify`` sub-command, e.g.::
+
+ => avb verify _a
+
+To switch on automatic generation of vbmeta partition in AOSP build, add these
+lines to device configuration mk file::
+
+ BOARD_AVB_ENABLE := true
+ BOARD_AVB_ALGORITHM := SHA512_RSA4096
+ BOARD_BOOTIMAGE_PARTITION_SIZE := <boot partition size>
+
+After flashing U-Boot don't forget to update environment and write new
+partition table::
+
+ => env default -f -a
+ => setenv partitions $partitions_android
+ => env save
+ => gpt write mmc 1 $partitions_android
+
+References
+----------
+
+.. [1] https://android.googlesource.com/platform/external/avb/+/master/README.md
+.. [2] https://www.op-tee.org/
diff --git a/roms/u-boot/doc/android/bcb.rst b/roms/u-boot/doc/android/bcb.rst
new file mode 100644
index 000000000..886160830
--- /dev/null
+++ b/roms/u-boot/doc/android/bcb.rst
@@ -0,0 +1,100 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Android Bootloader Control Block (BCB)
+======================================
+
+The purpose behind this file is to:
+
+* give an overview of BCB w/o duplicating public documentation
+* describe the main BCB use-cases which concern U-Boot
+* reflect current support status in U-Boot
+* mention any relevant U-Boot build-time tunables
+* precisely exemplify one or more use-cases
+
+Additions and fixes are welcome!
+
+Overview
+--------
+
+Bootloader Control Block (BCB) is a well established term/acronym in
+the Android namespace which refers to a location in a dedicated raw
+(i.e. FS-unaware) flash (e.g. eMMC) partition, usually called ``misc``,
+which is used as media for exchanging messages between Android userspace
+(particularly recovery [1]_) and an Android-capable bootloader.
+
+On higher level, BCB provides a way to implement a subset of Android
+Bootloader Requirements [2]_, amongst which are:
+
+* Android-specific bootloader flow [3]_
+* Get the "reboot reason" (and act accordingly) [4]_
+* Get/pass a list of commands from/to recovery [1]_
+* TODO
+
+
+'bcb'. Shell command overview
+-----------------------------
+
+The ``bcb`` command provides a CLI to facilitate the development of the
+requirements enumerated above. Below is the command's help message::
+
+ => bcb
+ bcb - Load/set/clear/test/dump/store Android BCB fields
+
+ Usage:
+ bcb load <dev> <part> - load BCB from mmc <dev>:<part>
+ bcb set <field> <val> - set BCB <field> to <val>
+ bcb clear [<field>] - clear BCB <field> or all fields
+ bcb test <field> <op> <val> - test BCB <field> against <val>
+ bcb dump <field> - dump BCB <field>
+ bcb store - store BCB back to mmc
+
+ Legend:
+ <dev> - MMC device index containing the BCB partition
+ <part> - MMC partition index or name containing the BCB
+ <field> - one of {command,status,recovery,stage,reserved}
+ <op> - the binary operator used in 'bcb test':
+ '=' returns true if <val> matches the string stored in <field>
+ '~' returns true if <val> matches a subset of <field>'s string
+ <val> - string/text provided as input to bcb {set,test}
+ NOTE: any ':' character in <val> will be replaced by line feed
+ during 'bcb set' and used as separator by upper layers
+
+
+'bcb'. Example of getting reboot reason
+---------------------------------------
+
+.. code-block:: bash
+
+ if bcb load 1 misc; then
+ # valid BCB found
+ if bcb test command = bootonce-bootloader; then
+ bcb clear command; bcb store;
+ # do the equivalent of AOSP ${fastbootcmd}
+ # i.e. call fastboot
+ else if bcb test command = boot-recovery; then
+ bcb clear command; bcb store;
+ # do the equivalent of AOSP ${recoverycmd}
+ # i.e. do anything required for booting into recovery
+ else
+ # boot Android OS normally
+ fi
+ else
+ # corrupted/non-existent BCB
+ # report error or boot non-Android OS (platform-specific)
+ fi
+
+
+Enable on your board
+--------------------
+
+The following Kconfig options must be enabled::
+
+ CONFIG_PARTITIONS=y
+ CONFIG_MMC=y
+ CONFIG_BCB=y
+
+.. [1] https://android.googlesource.com/platform/bootable/recovery
+.. [2] https://source.android.com/devices/bootloader
+.. [3] https://patchwork.ozlabs.org/patch/746835/
+ ("[U-Boot,5/6] Initial support for the Android Bootloader flow")
+.. [4] https://source.android.com/devices/bootloader/boot-reason
diff --git a/roms/u-boot/doc/android/boot-image.rst b/roms/u-boot/doc/android/boot-image.rst
new file mode 100644
index 000000000..fa8f2a47e
--- /dev/null
+++ b/roms/u-boot/doc/android/boot-image.rst
@@ -0,0 +1,155 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Sam Protsenko <joe.skb7@gmail.com>
+
+Android Boot Image
+==================
+
+Overview
+--------
+
+Android Boot Image is used to boot Android OS. It usually contains kernel image
+(like ``zImage`` file) and ramdisk. Sometimes it can contain additional
+binaries. This image is built as a part of AOSP (called ``boot.img``), and being
+flashed into ``boot`` partition on eMMC. Bootloader then reads that image from
+``boot`` partition to RAM and boots the kernel from it. Kernel than starts
+``init`` process from the ramdisk. It should be mentioned that recovery image
+(``recovery.img``) also has Android Boot Image format.
+
+Android Boot Image format is described at [1]_. At the moment it can have one of
+next image headers:
+
+* v0: it's called *legacy* boot image header; used in devices launched before
+ Android 9; contains kernel image, ramdisk and second stage bootloader
+ (usually unused)
+* v1: used in devices launched with Android 9; adds ``recovery_dtbo`` field,
+ which should be used for non-A/B devices in ``recovery.img`` (see [2]_ for
+ details)
+* v2: used in devices launched with Android 10; adds ``dtb`` field, which
+ references payload containing DTB blobs (either concatenated one after the
+ other, or in Android DTBO image format)
+
+v2, v1 and v0 formats are backward compatible.
+
+The Android Boot Image format is represented by
+:c:type:`struct andr_img_hdr <andr_img_hdr>` in U-Boot, and can be seen in
+``include/android_image.h``. U-Boot supports booting Android Boot Image and also
+has associated command
+
+Booting
+-------
+
+U-Boot is able to boot the Android OS from Android Boot Image using ``bootm``
+command. In order to use Android Boot Image format support, next option should
+be enabled::
+
+ CONFIG_ANDROID_BOOT_IMAGE=y
+
+Then one can use next ``bootm`` command call to run Android:
+
+.. code-block:: bash
+
+ => bootm $loadaddr $loadaddr $fdtaddr
+
+where ``$loadaddr`` - address in RAM where boot image was loaded; ``$fdtaddr`` -
+address in RAM where DTB blob was loaded.
+
+And parameters are, correspondingly:
+
+ 1. Where kernel image is located in RAM
+ 2. Where ramdisk is located in RAM (can be ``"-"`` if not applicable)
+ 3. Where DTB blob is located in RAM
+
+``bootm`` command will figure out that image located in ``$loadaddr`` has
+Android Boot Image format, will parse that and boot the kernel from it,
+providing DTB blob to kernel (from 3rd parameter), passing info about ramdisk to
+kernel via DTB.
+
+DTB and DTBO blobs
+------------------
+
+``bootm`` command can't just use DTB blob from Android Boot Image (``dtb``
+field), because:
+
+* there is no DTB area in Android Boot Image before v2
+* there may be several DTB blobs in DTB area (e.g. for different SoCs)
+* some DTBO blobs may have to be merged in DTB blobs before booting
+ (e.g. for different boards)
+
+So user has to prepare DTB blob manually and provide it in a 3rd parameter
+of ``bootm`` command. Next commands can be used to do so:
+
+1. ``abootimg``: manipulates Anroid Boot Image, allows one to extract
+ meta-information and payloads from it
+2. ``adtimg``: manipulates Android DTB/DTBO image [3]_, allows one to extract
+ DTB/DTBO blobs from it
+
+In order to use those, please enable next config options::
+
+ CONFIG_CMD_ABOOTIMG=y
+ CONFIG_CMD_ADTIMG=y
+
+For example, let's assume we have next Android partitions on eMMC:
+
+* ``boot``: contains Android Boot Image v2 (including DTB blobs)
+* ``dtbo``: contains DTBO blobs
+
+Then next command sequence can be used to boot Android:
+
+.. code-block:: bash
+
+ => mmc dev 1
+
+ # Read boot image to RAM (into $loadaddr)
+ => part start mmc 1 boot boot_start
+ => part size mmc 1 boot boot_size
+ => mmc read $loadaddr $boot_start $boot_size
+
+ # Read DTBO image to RAM (into $dtboaddr)
+ => part start mmc 1 dtbo dtbo_start
+ => part size mmc 1 dtbo dtbo_size
+ => mmc read $dtboaddr $dtbo_start $dtbo_size
+
+ # Copy required DTB blob (into $fdtaddr)
+ => abootimg get dtb --index=0 dtb0_start dtb0_size
+ => cp.b $dtb0_start $fdtaddr $dtb0_size
+
+ # Merge required DTBO blobs into DTB blob
+ => fdt addr $fdtaddr 0x100000
+ => adtimg addr $dtboaddr
+ => adtimg get dt --index=0 $dtbo0_addr
+ => fdt apply $dtbo0_addr
+
+ # Boot Android
+ => bootm $loadaddr $loadaddr $fdtaddr
+
+This sequence should be used for Android 10 boot. Of course, the whole Android
+boot procedure includes much more actions, like:
+
+* obtaining reboot reason from BCB (see [4]_)
+* implementing recovery boot
+* implementing fastboot boot
+* implementing A/B slotting (see [5]_)
+* implementing AVB2.0 (see [6]_)
+
+But Android Boot Image booting is the most crucial part in Android boot scheme.
+
+All Android bootloader requirements documentation is available at [7]_. Some
+overview on the whole Android 10 boot process can be found at [8]_.
+
+C API for working with Android Boot Image format
+------------------------------------------------
+
+.. kernel-doc:: common/image-android.c
+ :internal:
+
+References
+----------
+
+.. [1] https://source.android.com/devices/bootloader/boot-image-header
+.. [2] https://source.android.com/devices/bootloader/recovery-image
+.. [3] https://source.android.com/devices/architecture/dto/partitions
+.. [4] :doc:`bcb`
+.. [5] :doc:`ab`
+.. [6] :doc:`avb2`
+.. [7] https://source.android.com/devices/bootloader
+.. [8] https://connect.linaro.org/resources/san19/san19-217/
diff --git a/roms/u-boot/doc/android/fastboot-protocol.rst b/roms/u-boot/doc/android/fastboot-protocol.rst
new file mode 100644
index 000000000..e8cbd7f24
--- /dev/null
+++ b/roms/u-boot/doc/android/fastboot-protocol.rst
@@ -0,0 +1,178 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+FastBoot Version 0.4
+====================
+
+The fastboot protocol is a mechanism for communicating with bootloaders
+over USB. It is designed to be very straightforward to implement, to
+allow it to be used across a wide range of devices and from hosts running
+Linux, Windows, or OSX.
+
+Basic Requirements
+------------------
+
+* Two bulk endpoints (in, out) are required
+* Max packet size must be 64 bytes for full-speed and 512 bytes for
+ high-speed USB
+* The protocol is entirely host-driven and synchronous (unlike the
+ multi-channel, bi-directional, asynchronous ADB protocol)
+
+
+Transport and Framing
+---------------------
+
+1. Host sends a command, which is an ascii string in a single
+ packet no greater than 64 bytes.
+
+2. Client response with a single packet no greater than 64 bytes.
+ The first four bytes of the response are "OKAY", "FAIL", "DATA",
+ or "INFO". Additional bytes may contain an (ascii) informative
+ message.
+
+ a. INFO -> the remaining 60 bytes are an informative message
+ (providing progress or diagnostic messages). They should
+ be displayed and then step #2 repeats
+
+ b. FAIL -> the requested command failed. The remaining 60 bytes
+ of the response (if present) provide a textual failure message
+ to present to the user. Stop.
+
+ c. OKAY -> the requested command completed successfully. Go to #5
+
+ d. DATA -> the requested command is ready for the data phase.
+ A DATA response packet will be 12 bytes long, in the form of
+ DATA00000000 where the 8 digit hexidecimal number represents
+ the total data size to transfer.
+
+3. Data phase. Depending on the command, the host or client will
+ send the indicated amount of data. Short packets are always
+ acceptable and zero-length packets are ignored. This phase continues
+ until the client has sent or received the number of bytes indicated
+ in the "DATA" response above.
+
+4. Client responds with a single packet no greater than 64 bytes.
+ The first four bytes of the response are "OKAY", "FAIL", or "INFO".
+ Similar to #2:
+
+ a. INFO -> display the remaining 60 bytes and return to #4
+
+ b. FAIL -> display the remaining 60 bytes (if present) as a failure
+ reason and consider the command failed. Stop.
+
+ c. OKAY -> success. Go to #5
+
+5. Success. Stop.
+
+
+Example Session
+---------------
+
+.. code-block:: none
+
+ Host: "getvar:version" request version variable
+
+ Client: "OKAY0.4" return version "0.4"
+
+ Host: "getvar:nonexistant" request some undefined variable
+
+ Client: "OKAY" return value ""
+
+ Host: "download:00001234" request to send 0x1234 bytes of data
+
+ Client: "DATA00001234" ready to accept data
+
+ Host: < 0x1234 bytes > send data
+
+ Client: "OKAY" success
+
+ Host: "flash:bootloader" request to flash the data to the bootloader
+
+ Client: "INFOerasing flash" indicate status / progress
+ "INFOwriting flash"
+ "OKAY" indicate success
+
+ Host: "powerdown" send a command
+
+ Client: "FAILunknown command" indicate failure
+
+
+Command Reference
+-----------------
+
+* Command parameters are indicated by printf-style escape sequences.
+
+* Commands are ascii strings and sent without the quotes (which are
+ for illustration only here) and without a trailing 0 byte.
+
+* Commands that begin with a lowercase letter are reserved for this
+ specification. OEM-specific commands should not begin with a
+ lowercase letter, to prevent incompatibilities with future specs.
+
+.. code-block:: none
+
+ "getvar:%s" Read a config/version variable from the bootloader.
+ The variable contents will be returned after the
+ OKAY response.
+
+ "download:%08x" Write data to memory which will be later used
+ by "boot", "ramdisk", "flash", etc. The client
+ will reply with "DATA%08x" if it has enough
+ space in RAM or "FAIL" if not. The size of
+ the download is remembered.
+
+ "verify:%08x" Send a digital signature to verify the downloaded
+ data. Required if the bootloader is "secure"
+ otherwise "flash" and "boot" will be ignored.
+
+ "flash:%s" Write the previously downloaded image to the
+ named partition (if possible).
+
+ "erase:%s" Erase the indicated partition (clear to 0xFFs)
+
+ "boot" The previously downloaded data is a boot.img
+ and should be booted according to the normal
+ procedure for a boot.img
+
+ "continue" Continue booting as normal (if possible)
+
+ "reboot" Reboot the device.
+
+ "reboot-bootloader" Reboot back into the bootloader.
+ Useful for upgrade processes that require upgrading
+ the bootloader and then upgrading other partitions
+ using the new bootloader.
+
+ "powerdown" Power off the device.
+
+ "ucmd" execute any bootloader command and wait until it
+ finishs.
+
+ "acmd" execute any bootloader command, do not wait.
+
+Client Variables
+----------------
+
+The ``getvar:%s`` command is used to read client variables which
+represent various information about the device and the software
+on it.
+
+The various currently defined names are::
+
+ version Version of FastBoot protocol supported.
+ It should be "0.3" for this document.
+
+ version-bootloader Version string for the Bootloader.
+
+ version-baseband Version string of the Baseband Software
+
+ product Name of the product
+
+ serialno Product serial number
+
+ secure If the value is "yes", this is a secure
+ bootloader requiring a signature before
+ it will install or boot images.
+
+Names starting with a lowercase character are reserved by this
+specification. OEM-specific names should not start with lowercase
+characters.
diff --git a/roms/u-boot/doc/android/fastboot.rst b/roms/u-boot/doc/android/fastboot.rst
new file mode 100644
index 000000000..7611f0703
--- /dev/null
+++ b/roms/u-boot/doc/android/fastboot.rst
@@ -0,0 +1,234 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Android Fastboot
+================
+
+Overview
+--------
+
+The protocol that is used over USB and UDP is described in [1]_.
+
+The current implementation supports the following standard commands:
+
+- ``boot``
+- ``continue``
+- ``download``
+- ``erase`` (if enabled)
+- ``flash`` (if enabled)
+- ``getvar``
+- ``reboot``
+- ``reboot-bootloader``
+- ``set_active`` (only a stub implementation which always succeeds)
+- ``ucmd`` (if enabled)
+- ``acmd`` (if enabled)
+
+The following OEM commands are supported (if enabled):
+
+- ``oem format`` - this executes ``gpt write mmc %x $partitions``
+- ``oem partconf`` - this executes ``mmc partconf %x <arg> 0`` to configure eMMC
+ with <arg> = boot_ack boot_partition
+- ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
+
+Support for both eMMC and NAND devices is included.
+
+Client installation
+-------------------
+
+The counterpart to this is the fastboot client which can be found in
+Android's ``platform/system/core`` repository in the fastboot
+folder. It runs on Windows, Linux and OSX. The fastboot client is
+part of the Android SDK Platform-Tools and can be downloaded from [2]_.
+
+Board specific
+--------------
+
+USB configuration
+^^^^^^^^^^^^^^^^^
+
+The fastboot gadget relies on the USB download gadget, so the following
+options must be configured:
+
+::
+
+ CONFIG_USB_GADGET_DOWNLOAD
+ CONFIG_USB_GADGET_VENDOR_NUM
+ CONFIG_USB_GADGET_PRODUCT_NUM
+ CONFIG_USB_GADGET_MANUFACTURER
+
+NOTE: The ``CONFIG_USB_GADGET_VENDOR_NUM`` must be one of the numbers
+supported by the fastboot client. The list of vendor IDs supported can
+be found in the fastboot client source code.
+
+General configuration
+^^^^^^^^^^^^^^^^^^^^^
+
+The fastboot protocol requires a large memory buffer for
+downloads. This buffer should be as large as possible for a
+platform. The location of the buffer and size are set with
+``CONFIG_FASTBOOT_BUF_ADDR`` and ``CONFIG_FASTBOOT_BUF_SIZE``. These
+may be overridden on the fastboot command line using ``-l`` and
+``-s``.
+
+Fastboot environment variables
+------------------------------
+
+Partition aliases
+^^^^^^^^^^^^^^^^^
+
+Fastboot partition aliases can also be defined for devices where GPT
+limitations prevent user-friendly partition names such as ``boot``, ``system``
+and ``cache``. Or, where the actual partition name doesn't match a standard
+partition name used commonly with fastboot.
+
+The current implementation checks aliases when accessing partitions by
+name (flash_write and erase functions). To define a partition alias
+add an environment variable similar to::
+
+ fastboot_partition_alias_<alias partition name>=<actual partition name>
+
+for example::
+
+ fastboot_partition_alias_boot=LNX
+
+Raw partition descriptors
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In cases where no partition table is present, a raw partition descriptor can be
+defined, specifying the offset, size, and optionally the MMC hardware partition
+number for a given partition name.
+
+This is useful when using fastboot to flash files (e.g. SPL or U-Boot) to a
+specific offset in the eMMC boot partition, without having to update the entire
+boot partition.
+
+To define a raw partition descriptor, add an environment variable similar to::
+
+ fastboot_raw_partition_<raw partition name>=<offset> <size> [mmcpart <num>]
+
+for example::
+
+ fastboot_raw_partition_boot=0x100 0x1f00 mmcpart 1
+
+Variable overrides
+^^^^^^^^^^^^^^^^^^
+
+Variables retrived through ``getvar`` can be overridden by defining
+environment variables of the form ``fastboot.<variable>``. These are
+looked up first so can be used to override values which would
+otherwise be returned. Using this mechanism you can also return types
+for NAND filesystems, as the fully parameterised variable is looked
+up, e.g.::
+
+ fastboot.partition-type:boot=jffs2
+
+Boot command
+^^^^^^^^^^^^
+
+When executing the fastboot ``boot`` command, if ``fastboot_bootcmd`` is set
+then that will be executed in place of ``bootm <CONFIG_FASTBOOT_BUF_ADDR>``.
+
+Partition Names
+---------------
+
+The Fastboot implementation in U-Boot allows to write images into disk
+partitions. Target partitions are referred on the host computer by
+their names.
+
+For GPT/EFI the respective partition name is used.
+
+For MBR the partitions are referred by generic names according to the
+following schema::
+
+ <device type><device index letter><partition index>
+
+Example: ``hda3``, ``sdb1``, ``usbda1``.
+
+The device type is as follows:
+
+ * IDE, ATAPI and SATA disks: ``hd``
+ * SCSI disks: ``sd``
+ * USB media: ``usbd``
+ * MMC and SD cards: ``mmcsd``
+ * Disk on chip: ``docd``
+ * other: ``xx``
+
+The device index starts from ``a`` and refers to the interface (e.g. USB
+controller, SD/MMC controller) or disk index. The partition index starts
+from ``1`` and describes the partition number on the particular device.
+
+Alternatively, partition types may be specified using :ref:`U-Boot's partition
+syntax <partitions>`. This allows specifying partitions like ``0.1``,
+``0#boot``, or ``:3``. The interface is always ``mmc``.
+
+Writing Partition Table
+-----------------------
+
+Fastboot also allows to write the partition table to the media. This can be
+done by writing the respective partition table image to a special target
+"gpt" or "mbr". These names can be customized by defining the following
+configuration options:
+
+::
+
+ CONFIG_FASTBOOT_GPT_NAME
+ CONFIG_FASTBOOT_MBR_NAME
+
+In Action
+---------
+
+Enter into fastboot by executing the fastboot command in U-Boot for either USB::
+
+ => fastboot usb 0
+
+or UDP::
+
+ => fastboot udp
+ link up on port 0, speed 100, full duplex
+ Using ethernet@4a100000 device
+ Listening for fastboot command on 192.168.0.102
+
+On the client side you can fetch the bootloader version for instance::
+
+ $ fastboot getvar version-bootloader
+ version-bootloader: U-Boot 2019.07-rc4-00240-g00c9f2a2ec
+ Finished. Total time: 0.005s
+
+or initiate a reboot::
+
+ $ fastboot reboot
+
+and once the client comes back, the board should reset.
+
+You can also specify a kernel image to boot. You have to either specify
+the an image in Android format *or* pass a binary kernel and let the
+fastboot client wrap the Android suite around it. On OMAP for instance you
+take zImage kernel and pass it to the fastboot client::
+
+ $ fastboot -b 0x80000000 -c "console=ttyO2 earlyprintk root=/dev/ram0 mem=128M" boot zImage
+ creating boot image...
+ creating boot image - 1847296 bytes
+ downloading 'boot.img'...
+ OKAY [ 2.766s]
+ booting...
+ OKAY [ -0.000s]
+ finished. total time: 2.766s
+
+and on the U-Boot side you should see::
+
+ Starting download of 1847296 bytes
+ ........................................................
+ downloading of 1847296 bytes finished
+ Booting kernel..
+ ## Booting Android Image at 0x81000000 ...
+ Kernel load addr 0x80008000 size 1801 KiB
+ Kernel command line: console=ttyO2 earlyprintk root=/dev/ram0 mem=128M
+ Loading Kernel Image ... OK
+ OK
+
+ Starting kernel ...
+
+References
+----------
+
+.. [1] :doc:`fastboot-protocol`
+.. [2] https://developer.android.com/studio/releases/platform-tools
diff --git a/roms/u-boot/doc/android/index.rst b/roms/u-boot/doc/android/index.rst
new file mode 100644
index 000000000..225d6f125
--- /dev/null
+++ b/roms/u-boot/doc/android/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Android-specific doc
+====================
+
+.. toctree::
+ :maxdepth: 2
+
+ ab
+ avb2
+ bcb
+ boot-image
+ fastboot-protocol
+ fastboot
diff --git a/roms/u-boot/doc/api/dfu.rst b/roms/u-boot/doc/api/dfu.rst
new file mode 100644
index 000000000..5bd9e292a
--- /dev/null
+++ b/roms/u-boot/doc/api/dfu.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Device firmware update
+======================
+
+.. kernel-doc:: include/dfu.h
+ :internal:
diff --git a/roms/u-boot/doc/api/efi.rst b/roms/u-boot/doc/api/efi.rst
new file mode 100644
index 000000000..cb2a1c897
--- /dev/null
+++ b/roms/u-boot/doc/api/efi.rst
@@ -0,0 +1,176 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+UEFI subsystem
+==============
+
+Lauching UEFI images
+--------------------
+
+Bootefi command
+~~~~~~~~~~~~~~~
+
+The bootefi command is used to start UEFI applications or to install UEFI
+drivers. It takes two parameters
+
+ bootefi <image address> [fdt address]
+
+* image address - the memory address of the UEFI binary
+* fdt address - the memory address of the flattened device tree
+
+The environment variable 'bootargs' is passed as load options in the UEFI system
+table. The Linux kernel EFI stub uses the load options as command line
+arguments.
+
+.. kernel-doc:: cmd/bootefi.c
+ :internal:
+
+Boot manager
+~~~~~~~~~~~~
+
+The UEFI specification foresees to define boot entries and boot sequence via UEFI
+variables. Booting according to these variables is possible via
+
+ bootefi bootmgr [fdt address]
+
+* fdt address - the memory address of the flattened device tree
+
+The relevant variables are:
+
+* Boot0000-BootFFFF define boot entries
+* BootNext specifies next boot option to be booted
+* BootOrder specifies in which sequence the boot options shall be tried if
+ BootNext is not defined or booting via BootNext fails
+
+.. kernel-doc:: lib/efi_loader/efi_bootmgr.c
+ :internal:
+
+Efidebug command
+~~~~~~~~~~~~~~~~
+
+The efidebug command is used to set and display boot options as well as to
+display information about internal data of the UEFI subsystem (devices,
+drivers, handles, loaded images, and the memory map).
+
+.. kernel-doc:: cmd/efidebug.c
+ :internal:
+
+Initialization of the UEFI sub-system
+-------------------------------------
+
+.. kernel-doc:: lib/efi_loader/efi_setup.c
+ :internal:
+
+Boot services
+-------------
+
+.. kernel-doc:: lib/efi_loader/efi_boottime.c
+ :internal:
+
+Image relocation
+~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_image_loader.c
+ :internal:
+
+Memory services
+~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_memory.c
+ :internal:
+
+SetWatchdogTimer service
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_watchdog.c
+ :internal:
+
+Runtime services
+----------------
+
+.. kernel-doc:: lib/efi_loader/efi_runtime.c
+ :internal:
+
+Variable services
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/efi_variable.h
+ :internal:
+.. kernel-doc:: lib/efi_loader/efi_variable.c
+ :internal:
+
+UEFI drivers
+------------
+
+UEFI driver uclass
+~~~~~~~~~~~~~~~~~~
+.. kernel-doc:: lib/efi_driver/efi_uclass.c
+ :internal:
+
+Block device driver
+~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_driver/efi_block_device.c
+ :internal:
+
+Protocols
+---------
+
+Block IO protocol
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_disk.c
+ :internal:
+
+File protocol
+~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_file.c
+ :internal:
+
+Graphical output protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_gop.c
+ :internal:
+
+Load file 2 protocol
+~~~~~~~~~~~~~~~~~~~~
+
+The load file 2 protocol can be used by the Linux kernel to load the initial
+RAM disk. U-Boot can be configured to provide an implementation.
+
+.. kernel-doc:: lib/efi_loader/efi_load_initrd.c
+ :internal:
+
+Network protocols
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_net.c
+ :internal:
+
+Random number generator protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_rng.c
+ :internal:
+
+Text IO protocols
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_console.c
+ :internal:
+
+Unicode Collation protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: lib/efi_loader/efi_unicode_collation.c
+ :internal:
+
+Unit testing
+------------
+
+The following library functions are provided to support writing UEFI unit tests.
+The should not be used elsewhere.
+
+.. kernel-doc:: include/efi_selftest.h
+ :internal:
diff --git a/roms/u-boot/doc/api/getopt.rst b/roms/u-boot/doc/api/getopt.rst
new file mode 100644
index 000000000..773f79aeb
--- /dev/null
+++ b/roms/u-boot/doc/api/getopt.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020 Sean Anderson <seanga2@gmail.com>
+
+Option Parsing
+==============
+
+.. kernel-doc:: include/getopt.h
+ :internal:
diff --git a/roms/u-boot/doc/api/index.rst b/roms/u-boot/doc/api/index.rst
new file mode 100644
index 000000000..ea02aa571
--- /dev/null
+++ b/roms/u-boot/doc/api/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot API documentation
+========================
+
+.. toctree::
+ :maxdepth: 2
+
+ dfu
+ efi
+ getopt
+ linker_lists
+ logging
+ pinctrl
+ rng
+ sandbox
+ serial
+ timer
+ unicode
diff --git a/roms/u-boot/doc/api/linker_lists.rst b/roms/u-boot/doc/api/linker_lists.rst
new file mode 100644
index 000000000..7063fdc83
--- /dev/null
+++ b/roms/u-boot/doc/api/linker_lists.rst
@@ -0,0 +1,159 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Linker-Generated Arrays
+=======================
+
+A linker list is constructed by grouping together linker input
+sections, each containing one entry of the list. Each input section
+contains a constant initialized variable which holds the entry's
+content. Linker list input sections are constructed from the list
+and entry names, plus a prefix which allows grouping all lists
+together. Assuming _list and _entry are the list and entry names,
+then the corresponding input section name is
+
+::
+
+ .u_boot_list_ + 2_ + @_list + _2_ + @_entry
+
+and the C variable name is
+
+::
+
+ _u_boot_list + _2_ + @_list + _2_ + @_entry
+
+This ensures uniqueness for both input section and C variable name.
+
+Note that the names differ only in the first character, "." for the
+section and "_" for the variable, so that the linker cannot confuse
+section and symbol names. From now on, both names will be referred
+to as
+
+::
+
+ %u_boot_list_ + 2_ + @_list + _2_ + @_entry
+
+Entry variables need never be referred to directly.
+
+The naming scheme for input sections allows grouping all linker lists
+into a single linker output section and grouping all entries for a
+single list.
+
+Note the two '_2_' constant components in the names: their presence
+allows putting a start and end symbols around a list, by mapping
+these symbols to sections names with components "1" (before) and
+"3" (after) instead of "2" (within).
+Start and end symbols for a list can generally be defined as
+
+::
+
+ %u_boot_list_2_ + @_list + _1_...
+ %u_boot_list_2_ + @_list + _3_...
+
+Start and end symbols for the whole of the linker lists area can be
+defined as
+
+::
+
+ %u_boot_list_1_...
+ %u_boot_list_3_...
+
+Here is an example of the sorted sections which result from a list
+"array" made up of three entries : "first", "second" and "third",
+iterated at least once.
+
+::
+
+ .u_boot_list_2_array_1
+ .u_boot_list_2_array_2_first
+ .u_boot_list_2_array_2_second
+ .u_boot_list_2_array_2_third
+ .u_boot_list_2_array_3
+
+If lists must be divided into sublists (e.g. for iterating only on
+part of a list), one can simply give the list a name of the form
+'outer_2_inner', where 'outer' is the global list name and 'inner'
+is the sub-list name. Iterators for the whole list should use the
+global list name ("outer"); iterators for only a sub-list should use
+the full sub-list name ("outer_2_inner").
+
+Here is an example of the sections generated from a global list
+named "drivers", two sub-lists named "i2c" and "pci", and iterators
+defined for the whole list and each sub-list:
+
+::
+
+ %u_boot_list_2_drivers_1
+ %u_boot_list_2_drivers_2_i2c_1
+ %u_boot_list_2_drivers_2_i2c_2_first
+ %u_boot_list_2_drivers_2_i2c_2_first
+ %u_boot_list_2_drivers_2_i2c_2_second
+ %u_boot_list_2_drivers_2_i2c_2_third
+ %u_boot_list_2_drivers_2_i2c_3
+ %u_boot_list_2_drivers_2_pci_1
+ %u_boot_list_2_drivers_2_pci_2_first
+ %u_boot_list_2_drivers_2_pci_2_second
+ %u_boot_list_2_drivers_2_pci_2_third
+ %u_boot_list_2_drivers_2_pci_3
+ %u_boot_list_2_drivers_3
+
+Alignment issues
+----------------
+
+The linker script uses alphabetic sorting to group the different linker
+lists together. Each group has its own struct and potentially its own
+alignment. But when the linker packs the structs together it cannot ensure
+that a linker list starts on the expected alignment boundary.
+
+For example, if the first list has a struct size of 8 and we place 3 of
+them in the image, that means that the next struct will start at offset
+0x18 from the start of the linker_list section. If the next struct has
+a size of 16 then it will start at an 8-byte aligned offset, but not a
+16-byte aligned offset.
+
+With sandbox on x86_64, a reference to a linker list item using
+ll_entry_get() can force alignment of that particular linker_list item,
+if it is in the same file as the linker_list item is declared.
+
+Consider this example, where struct driver is 0x80 bytes::
+
+ ll_entry_declare(struct driver, fred, driver)
+
+ ...
+
+ void *p = ll_entry_get(struct driver, fred, driver)
+
+If these two lines of code are in the same file, then the entry is forced
+to be aligned at the 'struct driver' alignment, which is 16 bytes. If the
+second line of code is in a different file, then no action is taken, since
+the compiler cannot update the alignment of the linker_list item.
+
+In the first case, an 8-byte 'fill' region is added::
+
+ .u_boot_list_2_driver_2_testbus_drv
+ 0x0000000000270018 0x80 test/built-in.o
+ 0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv
+ .u_boot_list_2_driver_2_testfdt1_drv
+ 0x0000000000270098 0x80 test/built-in.o
+ 0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv
+ *fill* 0x0000000000270118 0x8
+ .u_boot_list_2_driver_2_testfdt_drv
+ 0x0000000000270120 0x80 test/built-in.o
+ 0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv
+ .u_boot_list_2_driver_2_testprobe_drv
+ 0x00000000002701a0 0x80 test/built-in.o
+ 0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv
+
+With this, the linker_list no-longer works since items after testfdt1_drv
+are not at the expected address.
+
+Ideally we would have a way to tell gcc not to align structs in this way.
+It is not clear how we could do this, and in any case it would require us
+to adjust every struct used by the linker_list feature.
+
+The simplest fix seems to be to force each separate linker_list to start
+on the largest possible boundary that can be required by the compiler. This
+is the purpose of CONFIG_LINKER_LIST_ALIGN
+
+
+.. kernel-doc:: include/linker_lists.h
+ :internal:
diff --git a/roms/u-boot/doc/api/logging.rst b/roms/u-boot/doc/api/logging.rst
new file mode 100644
index 000000000..1e6cbc493
--- /dev/null
+++ b/roms/u-boot/doc/api/logging.rst
@@ -0,0 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Logging API
+===========
+
+.. kernel-doc:: include/log.h
diff --git a/roms/u-boot/doc/api/pinctrl.rst b/roms/u-boot/doc/api/pinctrl.rst
new file mode 100644
index 000000000..043bd57ef
--- /dev/null
+++ b/roms/u-boot/doc/api/pinctrl.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Pinctrl and Pinmux
+==================
+
+.. kernel-doc:: include/dm/pinctrl.h
+ :internal:
diff --git a/roms/u-boot/doc/api/rng.rst b/roms/u-boot/doc/api/rng.rst
new file mode 100644
index 000000000..b826d4fd4
--- /dev/null
+++ b/roms/u-boot/doc/api/rng.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2018 Heinrich Schuchardt
+
+Random number generation
+========================
+
+Hardware random number generation
+---------------------------------
+
+.. kernel-doc:: include/rng.h
+ :internal:
+
+Pseudo random number generation
+-------------------------------
+
+.. kernel-doc:: include/rand.h
+ :internal:
diff --git a/roms/u-boot/doc/api/sandbox.rst b/roms/u-boot/doc/api/sandbox.rst
new file mode 100644
index 000000000..724776399
--- /dev/null
+++ b/roms/u-boot/doc/api/sandbox.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sandbox
+=======
+
+The following API routines are used to implement the U-Boot sandbox.
+
+.. kernel-doc:: include/os.h
+ :internal:
diff --git a/roms/u-boot/doc/api/serial.rst b/roms/u-boot/doc/api/serial.rst
new file mode 100644
index 000000000..ed34e592a
--- /dev/null
+++ b/roms/u-boot/doc/api/serial.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Serial system
+=============
+
+.. kernel-doc:: drivers/serial/serial.c
+ :internal:
diff --git a/roms/u-boot/doc/api/timer.rst b/roms/u-boot/doc/api/timer.rst
new file mode 100644
index 000000000..b0695174d
--- /dev/null
+++ b/roms/u-boot/doc/api/timer.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020 Sean Anderson <seanga2@gmail.com>
+
+Timer Subsystem
+===============
+
+.. kernel-doc:: include/timer.h
+ :internal:
diff --git a/roms/u-boot/doc/api/unicode.rst b/roms/u-boot/doc/api/unicode.rst
new file mode 100644
index 000000000..3fb6745f8
--- /dev/null
+++ b/roms/u-boot/doc/api/unicode.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Unicode support
+===============
+
+.. kernel-doc:: include/charset.h
+ :internal:
diff --git a/roms/u-boot/doc/arch/arc.rst b/roms/u-boot/doc/arch/arc.rst
new file mode 100644
index 000000000..f8e04a34f
--- /dev/null
+++ b/roms/u-boot/doc/arch/arc.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+ARC
+===
+
+Synopsys' DesignWare(r) ARC(r) Processors are a family of 32-bit CPUs
+that SoC designers can optimize for a wide range of uses, from deeply embedded
+to high-performance host applications.
+
+More information on ARC cores avaialble here:
+http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx
+
+Designers can differentiate their products by using patented configuration
+technology to tailor each ARC processor instance to meet specific performance,
+power and area requirements.
+
+The DesignWare ARC processors are also extendable, allowing designers to add
+their own custom instructions that dramatically increase performance.
+
+Synopsys' ARC processors have been used by over 170 customers worldwide who
+collectively ship more than 1 billion ARC-based chips annually.
+
+All DesignWare ARC processors utilize a 16-/32-bit ISA that provides excellent
+performance and code density for embedded and host SoC applications.
+
+The RISC microprocessors are synthesizable and can be implemented in any foundry
+or process, and are supported by a complete suite of development tools.
+
+The ARC GNU toolchain with support for all ARC Processors can be downloaded
+from here (available pre-built toolchains as well):
+
+https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases
diff --git a/roms/u-boot/doc/arch/arm64.rst b/roms/u-boot/doc/arch/arm64.rst
new file mode 100644
index 000000000..80498f6f6
--- /dev/null
+++ b/roms/u-boot/doc/arch/arm64.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+ARM64
+=====
+
+Summary
+-------
+The initial arm64 U-Boot port was developed before hardware was available,
+so the first supported platforms were the Foundation and Fast Model for ARMv8.
+These days U-Boot runs on a variety of 64-bit capable ARM hardware, from
+embedded development boards to servers.
+
+Notes
+-----
+
+1. U-Boot can run at any exception level it is entered in, it is
+ recommened to enter it in EL3 if U-Boot takes some responsibilities of a
+ classical firmware (like initial hardware setup, CPU errata workarounds
+ or SMP bringup). U-Boot can be entered in EL2 when its main purpose is
+ that of a boot loader. It can drop to lower exception levels before
+ entering the OS.
+
+2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
+ use rela relocation format, a tool(tools/relocate-rela) by Scott Wood
+ is used to encode the initial addend of rela to u-boot.bin. After running,
+ the U-Boot will be relocated to destination again.
+
+3. Earlier Linux kernel versions required the FDT to be placed at a
+ 2 MB boundary and within the same 512 MB section as the kernel image,
+ resulting in fdt_high to be defined specially.
+ Since kernel version 4.2 Linux is more relaxed about the DT location, so it
+ can be placed anywhere in memory.
+ Please reference linux/Documentation/arm64/booting.txt for detail.
+
+4. Spin-table is used to wake up secondary processors. One location
+ (or per processor location) is defined to hold the kernel entry point
+ for secondary processors. It must be ensured that the location is
+ accessible and zero immediately after secondary processor
+ enter slave_cpu branch execution in start.S. The location address
+ is encoded in cpu node of DTS. Linux kernel store the entry point
+ of secondary processors to it and send event to wakeup secondary
+ processors.
+ Please reference linux/Documentation/arm64/booting.txt for detail.
+
+5. Generic board is supported.
+
+6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and
+ aarch32 specific codes.
+
+
+Contributors
+------------
+ * Tom Rini <trini@ti.com>
+ * Scott Wood <scottwood@freescale.com>
+ * York Sun <yorksun@freescale.com>
+ * Simon Glass <sjg@chromium.org>
+ * Sharma Bhupesh <bhupesh.sharma@freescale.com>
+ * Rob Herring <robherring2@gmail.com>
+ * Sergey Temerkhanov <s.temerkhanov@gmail.com>
diff --git a/roms/u-boot/doc/arch/index.rst b/roms/u-boot/doc/arch/index.rst
new file mode 100644
index 000000000..369d8eeb6
--- /dev/null
+++ b/roms/u-boot/doc/arch/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Architecture-specific doc
+=========================
+
+.. toctree::
+ :maxdepth: 2
+
+ arc
+ arm64
+ m68k
+ mips
+ nds32
+ nios2
+ sandbox
+ sh
+ x86
+ xtensa
diff --git a/roms/u-boot/doc/arch/m68k.rst b/roms/u-boot/doc/arch/m68k.rst
new file mode 100644
index 000000000..44e1a5dfa
--- /dev/null
+++ b/roms/u-boot/doc/arch/m68k.rst
@@ -0,0 +1,170 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+M68K / ColdFire
+===============
+
+History
+-------
+* November 02, 2017 Angelo Dureghello <angelo@sysam.it>
+* August 08, 2005 Jens Scharsig <esw@bus-elektronik.de>
+ MCF5282 implementation without preloader
+* January 12, 2004 <josef.baumgartner@telex.de>
+
+This file contains status information for the port of U-Boot to the
+Motorola ColdFire series of CPUs.
+
+Overview
+--------
+
+The ColdFire instruction set is "assembly source" compatible but an evolution
+of the original 68000 instruction set. Some not much used instructions has
+been removed. The instructions are only 16, 32, or 48 bits long, a
+simplification compared to the 68000 series.
+
+Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola ColdFire architecture.
+The patches of Bernhard support the MCF5272 and MCF5282. A great disadvantage
+of these patches was that they needed a pre-bootloader to start U-Boot.
+Because of this, a new port was created which no longer needs a first stage
+booter.
+
+Thanks mainly to Freescale but also to several other contributors, U-Boot now
+supports nearly the entire range of ColdFire processors and their related
+development boards.
+
+
+Supported CPU families
+----------------------
+
+Please "make menuconfig" and select "m68k" or check arch/m68k/cpu to see the
+currently supported processor and families.
+
+
+Supported boards
+----------------
+
+U-Boot supports actually more than 40 ColdFire based boards.
+Board configuration can be done trough include/configs/<boardname>.h but the
+current recommended method is to use the new and more friendly approach as
+the "make menuconfig" way, very similar to the Linux way.
+
+To know details as memory map, build targets, default setup, etc, of a
+specific board please check:
+
+* include/configs/<boardname>.h
+
+and/or
+
+* configs/<boardname>_defconfig
+
+It is possible to build all ColdFire boards in a single command-line command,
+from u-boot root directory, as::
+
+ ./tools/buildman/buildman m68k
+
+Build U-Boot for a specific board
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A bash script similar to the one below may be used:
+
+.. code-block:: shell
+
+ #!/bin/bash
+
+ export CROSS_COMPILE=/opt/toolchains/m68k/gcc-4.9.0-nolibc/bin/m68k-linux-
+
+ board=M5475DFE
+
+ make distclean
+ make ${board}_defconfig
+ make KBUILD_VERBOSE=1
+
+
+Adopted toolchains
+------------------
+
+Please check:
+https://www.denx.de/wiki/U-Boot/ColdFireNotes
+
+
+ColdFire specific configuration options/settings
+------------------------------------------------
+
+Configuration to use a pre-loader
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If U-Boot should be loaded to RAM and started by a pre-loader
+CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the
+initial vector table and basic processor initialization will not
+be compiled in. The start address of U-Boot must be adjusted in
+the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile
+(CONFIG_SYS_TEXT_BASE) to the load address.
+
+ColdFire CPU specific options/settings
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To specify a CPU model, some defines shoudl be used, i.e.:
+
+CONFIG_MCF52x2:
+ defined for all MCF52x2 CPUs
+CONFIG_M5272:
+ defined for all Motorola MCF5272 CPUs
+
+Other options, generally set inside include/configs/<boardname>.h, they may
+apply to one or more cpu for the ColdFire family:
+
+CONFIG_SYS_MBAR:
+ defines the base address of the MCF5272 configuration registers
+CONFIG_SYS_ENET_BD_BASE:
+ defines the base address of the FEC buffer descriptors
+CONFIG_SYS_SCR:
+ defines the contents of the System Configuration Register
+CONFIG_SYS_SPR:
+ defines the contents of the System Protection Register
+CONFIG_SYS_MFD:
+ defines the PLL Multiplication Factor Divider
+ (see table 9-4 of MCF user manual)
+CONFIG_SYS_RFD:
+ defines the PLL Reduce Frequency Devider
+ (see table 9-4 of MCF user manual)
+CONFIG_SYS_CSx_BASE:
+ defines the base address of chip select x
+CONFIG_SYS_CSx_SIZE:
+ defines the memory size (address range) of chip select x
+CONFIG_SYS_CSx_WIDTH:
+ defines the bus with of chip select x
+CONFIG_SYS_CSx_MASK:
+ defines the mask for the related chip select x
+CONFIG_SYS_CSx_RO:
+ if set to 0 chip select x is read/write else chip select is read only
+CONFIG_SYS_CSx_WS:
+ defines the number of wait states of chip select x
+CONFIG_SYS_CACHE_ICACR:
+ cache-related registers config
+CONFIG_SYS_CACHE_DCACR:
+ cache-related registers config
+CONFIG_SYS_CACHE_ACRX:
+ cache-related registers config
+CONFIG_SYS_SDRAM_BASE:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_SIZE:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_BASEX:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_CFG1:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_CFG2:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_CTRL:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_MODE:
+ SDRAM config for SDRAM controller-specific registers
+CONFIG_SYS_SDRAM_EMOD:
+ SDRAM config for SDRAM controller-specific registers, please
+ see arch/m68k/cpu/<specific_cpu>/start.S files to see how
+ these options are used.
+CONFIG_MCFUART:
+ defines enabling of ColdFire UART driver
+CONFIG_SYS_UART_PORT:
+ defines the UART port to be used (only a single UART can be actually enabled)
+CONFIG_SYS_SBFHDR_SIZE:
+ size of the prepended SBF header, if any
diff --git a/roms/u-boot/doc/arch/mips.rst b/roms/u-boot/doc/arch/mips.rst
new file mode 100644
index 000000000..b8166087d
--- /dev/null
+++ b/roms/u-boot/doc/arch/mips.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+MIPS
+====
+
+Notes for the MIPS architecture port of U-Boot
+
+Toolchains
+----------
+
+ * `ELDK < DULG < DENX <http://www.denx.de/wiki/DULG/ELDK>`_
+ * `Embedded Debian -- Cross-development toolchains <http://www.emdebian.org/crosstools.html>`_
+ * `Buildroot <http://buildroot.uclibc.org/>`_
+
+Known Issues
+------------
+
+ * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c
+
+ Cache will be disabled before entering the loaded ELF image without
+ writing back and invalidating cache lines. This leads to cache
+ incoherency in most cases, unless the code gets loaded after U-Boot
+ re-initializes the cache. The more common uImage 'bootm' command does
+ not suffer this problem.
+
+ [workaround] To avoid this cache incoherency:
+ - insert flush_cache(all) before calling dcache_disable(), or
+ - fix dcache_disable() to do both flushing and disabling cache.
+
+ * Note that Linux users need to kill dcache_disable() in do_bootelf_exec()
+ or override do_bootelf_exec() not to disable I-/D-caches, because most
+ Linux/MIPS ports don't re-enable caches after entering kernel_entry.
+
+TODOs
+-----
+
+ * Probe CPU types, I-/D-cache and TLB size etc. automatically
+ * Secondary cache support missing
+ * Initialize TLB entries redardless of their use
+ * R2000/R3000 class parts are not supported
+ * Limited testing across different MIPS variants
+ * Due to cache initialization issues, the DRAM on board must be
+ initialized in board specific assembler language before the cache init
+ code is run -- that is, initialize the DRAM in lowlevel_init().
+ * centralize/share more CPU code of MIPS32, MIPS64 and XBurst
+ * support Qemu Malta
diff --git a/roms/u-boot/doc/arch/nds32.rst b/roms/u-boot/doc/arch/nds32.rst
new file mode 100644
index 000000000..502397cf7
--- /dev/null
+++ b/roms/u-boot/doc/arch/nds32.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+NDS32
+=====
+
+NDS32 is a new high-performance 32-bit RISC microprocessor core.
+
+http://www.andestech.com/
+
+AndeStar ISA
+------------
+AndeStar is a patent-pending 16-bit/32-bit mixed-length instruction set to
+achieve optimal system performance, code density, and power efficiency.
+
+It contains the following features:
+ - Intermixable 32-bit and 16-bit instruction sets without the need for
+ mode switch.
+ - 16-bit instructions as a frequently used subset of 32-bit instructions.
+ - RISC-style register-based instruction set.
+ - 32 32-bit General Purpose Registers (GPR).
+ - Upto 1024 User Special Registers (USR) for existing and extension
+ instructions.
+ - Rich load/store instructions for...
+ - Single memory access with base address update.
+ - Multiple aligned and unaligned memory accesses for memory copy and stack
+ operations.
+ - Data prefetch to improve data cache performance.
+ - Non-bus locking synchronization instructions.
+ - PC relative jump and PC read instructions for efficient position independent
+ code.
+ - Multiply-add and multiple-sub with 64-bit accumulator.
+ - Instruction for efficient power management.
+ - Bi-endian support.
+ - Three instruction extension space for application acceleration:
+ - Performance extension.
+ - Andes future extensions (for floating-point, multimedia, etc.)
+ - Customer extensions.
+
+AndesCore CPU
+-------------
+Andes Technology has 4 families of CPU cores: N12, N10, N9, N8.
+
+For details about N12 CPU family, please check below N1213 features.
+N1213 is a configurable hard/soft core of NDS32's N12 CPU family.
+
+N1213 Features
+^^^^^^^^^^^^^^
+
+CPU Core
+ - 16-/32-bit mixable instruction format.
+ - 32 general-purpose 32-bit registers.
+ - 8-stage pipeline.
+ - Dynamic branch prediction.
+ - 32/64/128/256 BTB.
+ - Return address stack (RAS).
+ - Vector interrupts for internal/external.
+ interrupt controller with 6 hardware interrupt signals.
+ - 3 HW-level nested interruptions.
+ - User and super-user mode support.
+ - Memory-mapped I/O.
+ - Address space up to 4GB.
+
+Memory Management Unit
+ - TLB
+ - 4/8-entry fully associative iTLB/dTLB.
+ - 32/64/128-entry 4-way set-associati.ve main TLB.
+ - TLB locking support
+ - Optional hardware page table walker.
+ - Two groups of page size support.
+ - 4KB & 1MB.
+ - 8KB & 1MB.
+
+Memory Subsystem
+ - I & D cache.
+ - Virtually indexed and physically tagged.
+ - Cache size: 8KB/16KB/32KB/64KB.
+ - Cache line size: 16B/32B.
+ - Set associativity: 2-way, 4-way or direct-mapped.
+ - Cache locking support.
+ - I & D local memory (LM).
+ - Size: 4KB to 1MB.
+ - Bank numbers: 1 or 2.
+ - Optional 1D/2D DMA engine.
+ - Internal or external to CPU core.
+
+Bus Interface
+ - Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports.
+ - Synchronous High speed memory port.
+ (HSMP): 0, 1 or 2 ports.
+
+Debug
+ - JTAG debug interface.
+ - Embedded debug module (EDM).
+ - Optional embedded program tracer interface.
+
+Miscellaneous
+ - Programmable data endian control.
+ - Performance monitoring mechanism.
+
+The NDS32 ports of u-boot, the Linux kernel, the GNU toolchain and other
+associated software are actively supported by Andes Technology Corporation.
diff --git a/roms/u-boot/doc/arch/nios2.rst b/roms/u-boot/doc/arch/nios2.rst
new file mode 100644
index 000000000..35defb0af
--- /dev/null
+++ b/roms/u-boot/doc/arch/nios2.rst
@@ -0,0 +1,111 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Nios II
+=======
+
+Nios II is a 32-bit embedded-processor architecture designed
+specifically for the Altera family of FPGAs.
+
+Please refer to the link for more information on Nios II:
+https://www.altera.com/products/processors/overview.html
+
+Please refer to the link for Linux port and toolchains:
+http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual
+
+The Nios II port of u-boot is controlled by device tree. Please check
+out doc/README.fdt-control.
+
+To add a new board/configuration (eg, mysystem) to u-boot, you will need
+three files.
+
+1. The device tree source which describes the hardware, dts file:
+ arch/nios2/dts/mysystem.dts
+
+2. Default configuration of Kconfig, defconfig file:
+ configs/mysystem_defconfig
+
+3. The legacy board header file:
+ include/configs/mysystem.h
+
+The device tree source must be generated from your qsys/sopc design
+using the sopc2dts tool. Then modified to fit your configuration.
+
+Please find the sopc2dts download and usage at the wiki:
+http://www.alterawiki.com/wiki/Sopc2dts
+
+.. code-block:: none
+
+ $ java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts
+
+You will need to add additional properties to the dts. Please find an
+example at, arch/nios2/dts/10m50_devboard.dts.
+
+1. Add "stdout-path=..." property with your serial path to the chosen
+ node, like this::
+
+ chosen {
+ stdout-path = &uart_0;
+ };
+
+2. If you use SPI/EPCS or I2C, you will need to add aliases to number
+ the sequence of these devices, like this::
+
+ aliases {
+ spi0 = &epcs_controller;
+ };
+
+Next, you will need a default config file. You may start with
+10m50_defconfig, modify the options and save it.
+
+.. code-block:: none
+
+ $ make 10m50_defconfig
+ $ make menuconfig
+ $ make savedefconfig
+ $ cp defconfig configs/mysystem_defconfig
+
+You will need to change the names of board header file and device tree,
+and select the drivers with menuconfig.
+
+.. code-block:: none
+
+ Nios II architecture --->
+ (mysystem) Board header file
+ Device Tree Control --->
+ (mysystem) Default Device Tree for DT control
+
+There is a selection of "Provider of DTB for DT control" in the Device
+Tree Control menu.
+
+ * Separate DTB for DT control, will cat the dtb to end of u-boot
+ binary, output u-boot-dtb.bin. This should be used for production.
+ If you use boot copier, like EPCS boot copier, make sure the copier
+ copies all the u-boot-dtb.bin, not just u-boot.bin.
+
+ * Embedded DTB for DT control, will include the dtb inside the u-boot
+ binary. This is handy for development, eg, using gdb or nios2-download.
+
+The last thing, legacy board header file describes those config options
+not covered in Kconfig yet. You may copy it from 10m50_devboard.h::
+
+ $ cp include/configs/10m50_devboard.h include/configs/mysystem.h
+
+Please change the SDRAM base and size to match your board. The base
+should be cached virtual address, for Nios II with MMU it is 0xCxxx_xxxx
+to 0xDxxx_xxxx.
+
+.. code-block:: c
+
+ #define CONFIG_SYS_SDRAM_BASE 0xc8000000
+ #define CONFIG_SYS_SDRAM_SIZE 0x08000000
+
+You will need to change the environment variables location and setting,
+too. You may change other configs to fit your board.
+
+After all these changes, you may build and test::
+
+ $ export CROSS_COMPILE=nios2-elf- (or nios2-linux-gnu-)
+ $ make mysystem_defconfig
+ $ make
+
+Enjoy!
diff --git a/roms/u-boot/doc/arch/sandbox.rst b/roms/u-boot/doc/arch/sandbox.rst
new file mode 100644
index 000000000..e052b6bdb
--- /dev/null
+++ b/roms/u-boot/doc/arch/sandbox.rst
@@ -0,0 +1,519 @@
+.. SPDX-License-Identifier: GPL-2.0+ */
+.. Copyright (c) 2014 The Chromium OS Authors.
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Sandbox
+=======
+
+Native Execution of U-Boot
+--------------------------
+
+The 'sandbox' architecture is designed to allow U-Boot to run under Linux on
+almost any hardware. To achieve this it builds U-Boot (so far as possible)
+as a normal C application with a main() and normal C libraries.
+
+All of U-Boot's architecture-specific code therefore cannot be built as part
+of the sandbox U-Boot. The purpose of running U-Boot under Linux is to test
+all the generic code, not specific to any one architecture. The idea is to
+create unit tests which we can run to test this upper level code.
+
+Sandbox allows development of many types of new features in a traditional way,
+rather than needing to test each iteration on real hardware. Many U-Boot
+features were developed on sandbox, including the core driver model, most
+uclasses, verified boot, bloblist, logging and dozens of others. Sandbox has
+enabled many large-scale code refactors as well.
+
+CONFIG_SANDBOX is defined when building a native board.
+
+The board name is 'sandbox' but the vendor name is unset, so there is a
+single board in board/sandbox.
+
+CONFIG_SANDBOX_BIG_ENDIAN should be defined when running on big-endian
+machines.
+
+There are two versions of the sandbox: One using 32-bit-wide integers, and one
+using 64-bit-wide integers. The 32-bit version can be build and run on either
+32 or 64-bit hosts by either selecting or deselecting CONFIG_SANDBOX_32BIT; by
+default, the sandbox it built for a 32-bit host. The sandbox using 64-bit-wide
+integers can only be built on 64-bit hosts.
+
+Note that standalone/API support is not available at present.
+
+
+Prerequisites
+-------------
+
+Here are some packages that are worth installing if you are doing sandbox or
+tools development in U-Boot:
+
+ python3-pytest lzma lzma-alone lz4 python3 python3-virtualenv
+ libssl1.0-dev
+
+
+Basic Operation
+---------------
+
+To run sandbox U-Boot use something like::
+
+ make sandbox_defconfig all
+ ./u-boot
+
+Note: If you get errors about 'sdl-config: Command not found' you may need to
+install libsdl2.0-dev or similar to get SDL support. Alternatively you can
+build sandbox without SDL (i.e. no display/keyboard support) by removing
+the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using::
+
+ make sandbox_defconfig all NO_SDL=1
+ ./u-boot
+
+U-Boot will start on your computer, showing a sandbox emulation of the serial
+console::
+
+ U-Boot 2014.04 (Mar 20 2014 - 19:06:00)
+
+ DRAM: 128 MiB
+ Using default environment
+
+ In: serial
+ Out: lcd
+ Err: lcd
+ =>
+
+You can issue commands as your would normally. If the command you want is
+not supported you can add it to include/configs/sandbox.h.
+
+To exit, type 'poweroff' or press Ctrl-C.
+
+
+Console / LCD support
+---------------------
+
+Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the
+sandbox with LCD and keyboard emulation, using something like::
+
+ ./u-boot -d u-boot.dtb -l
+
+This will start U-Boot with a window showing the contents of the LCD. If
+that window has the focus then you will be able to type commands as you
+would on the console. You can adjust the display settings in the device
+tree file - see arch/sandbox/dts/sandbox.dts.
+
+
+Command-line Options
+--------------------
+
+Various options are available, mostly for test purposes. Use -h to see
+available options. Some of these are described below:
+
+-t, --terminal <arg>
+ The terminal is normally in what is called 'raw-with-sigs' mode. This means
+ that you can use arrow keys for command editing and history, but if you
+ press Ctrl-C, U-Boot will exit instead of handling this as a keypress.
+ Other options are 'raw' (so Ctrl-C is handled within U-Boot) and 'cooked'
+ (where the terminal is in cooked mode and cursor keys will not work, Ctrl-C
+ will exit).
+
+-l
+ Show the LCD emulation window.
+
+-d <device_tree>
+ A device tree binary file can be provided with -d. If you edit the source
+ (it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to
+ recreate the binary file.
+
+-D
+ To use the default device tree, use -D.
+
+-T
+ To use the test device tree, use -T.
+
+-c [<cmd>;]<cmd>
+ To execute commands directly, use the -c option. You can specify a single
+ command, or multiple commands separated by a semicolon, as is normal in
+ U-Boot. Be careful with quoting as the shell will normally process and
+ swallow quotes. When -c is used, U-Boot exits after the command is complete,
+ but you can force it to go to interactive mode instead with -i.
+
+-i
+ Go to interactive mode after executing the commands specified by -c.
+
+Environment Variables
+---------------------
+
+UBOOT_SB_TIME_OFFSET
+ This environment variable stores the offset of the emulated real time clock
+ to the host's real time clock in seconds. The offset defaults to zero.
+
+Memory Emulation
+----------------
+
+Memory emulation is supported, with the size set by CONFIG_SYS_SDRAM_SIZE.
+The -m option can be used to read memory from a file on start-up and write
+it when shutting down. This allows preserving of memory contents across
+test runs. You can tell U-Boot to remove the memory file after it is read
+(on start-up) with the --rm_memory option.
+
+To access U-Boot's emulated memory within the code, use map_sysmem(). This
+function is used throughout U-Boot to ensure that emulated memory is used
+rather than the U-Boot application memory. This provides memory starting
+at 0 and extending to the size of the emulation.
+
+
+Storing State
+-------------
+
+With sandbox you can write drivers which emulate the operation of drivers on
+real devices. Some of these drivers may want to record state which is
+preserved across U-Boot runs. This is particularly useful for testing. For
+example, the contents of a SPI flash chip should not disappear just because
+U-Boot exits.
+
+State is stored in a device tree file in a simple format which is driver-
+specific. You then use the -s option to specify the state file. Use -r to
+make U-Boot read the state on start-up (otherwise it starts empty) and -w
+to write it on exit (otherwise the stored state is left unchanged and any
+changes U-Boot made will be lost). You can also use -n to tell U-Boot to
+ignore any problems with missing state. This is useful when first running
+since the state file will be empty.
+
+The device tree file has one node for each driver - the driver can store
+whatever properties it likes in there. See 'Writing Sandbox Drivers' below
+for more details on how to get drivers to read and write their state.
+
+
+Running and Booting
+-------------------
+
+Since there is no machine architecture, sandbox U-Boot cannot actually boot
+a kernel, but it does support the bootm command. Filesystems, memory
+commands, hashing, FIT images, verified boot and many other features are
+supported.
+
+When 'bootm' runs a kernel, sandbox will exit, as U-Boot does on a real
+machine. Of course in this case, no kernel is run.
+
+It is also possible to tell U-Boot that it has jumped from a temporary
+previous U-Boot binary, with the -j option. That binary is automatically
+removed by the U-Boot that gets the -j option. This allows you to write
+tests which emulate the action of chain-loading U-Boot, typically used in
+a situation where a second 'updatable' U-Boot is stored on your board. It
+is very risky to overwrite or upgrade the only U-Boot on a board, since a
+power or other failure will brick the board and require return to the
+manufacturer in the case of a consumer device.
+
+
+Supported Drivers
+-----------------
+
+U-Boot sandbox supports these emulations:
+
+- Block devices
+- Chrome OS EC
+- GPIO
+- Host filesystem (access files on the host from within U-Boot)
+- I2C
+- Keyboard (Chrome OS)
+- LCD
+- Network
+- Serial (for console only)
+- Sound (incomplete - see sandbox_sdl_sound_init() for details)
+- SPI
+- SPI flash
+- TPM (Trusted Platform Module)
+
+A wide range of commands are implemented. Filesystems which use a block
+device are supported.
+
+Also sandbox supports driver model (CONFIG_DM) and associated commands.
+
+
+Sandbox Variants
+----------------
+
+There are unfortunately quite a few variants at present:
+
+sandbox:
+ should be used for most tests
+sandbox64:
+ special build that forces a 64-bit host
+sandbox_flattree:
+ builds with dev_read\_...() functions defined as inline.
+ We need this build so that we can test those inline functions, and we
+ cannot build with both the inline functions and the non-inline functions
+ since they are named the same.
+sandbox_spl:
+ builds sandbox with SPL support, so you can run spl/u-boot-spl
+ and it will start up and then load ./u-boot. It is also possible to
+ run ./u-boot directly.
+
+Of these sandbox_spl can probably be removed since it is a superset of sandbox.
+
+Most of the config options should be identical between these variants.
+
+
+Linux RAW Networking Bridge
+---------------------------
+
+The sandbox_eth_raw driver bridges traffic between the bottom of the network
+stack and the RAW sockets API in Linux. This allows much of the U-Boot network
+functionality to be tested in sandbox against real network traffic.
+
+For Ethernet network adapters, the bridge utilizes the RAW AF_PACKET API. This
+is needed to get access to the lowest level of the network stack in Linux. This
+means that all of the Ethernet frame is included. This allows the U-Boot network
+stack to be fully used. In other words, nothing about the Linux network stack is
+involved in forming the packets that end up on the wire. To receive the
+responses to packets sent from U-Boot the network interface has to be set to
+promiscuous mode so that the network card won't filter out packets not destined
+for its configured (on Linux) MAC address.
+
+The RAW sockets Ethernet API requires elevated privileges in Linux. You can
+either run as root, or you can add the capability needed like so::
+
+ sudo /sbin/setcap "CAP_NET_RAW+ep" /path/to/u-boot
+
+The default device tree for sandbox includes an entry for eth0 on the sandbox
+host machine whose alias is "eth1". The following are a few examples of network
+operations being tested on the eth0 interface.
+
+.. code-block:: none
+
+ sudo /path/to/u-boot -D
+
+ DHCP
+ ....
+
+ setenv autoload no
+ setenv ethrotate no
+ setenv ethact eth1
+ dhcp
+
+ PING
+ ....
+
+ setenv autoload no
+ setenv ethrotate no
+ setenv ethact eth1
+ dhcp
+ ping $gatewayip
+
+ TFTP
+ ....
+
+ setenv autoload no
+ setenv ethrotate no
+ setenv ethact eth1
+ dhcp
+ setenv serverip WWW.XXX.YYY.ZZZ
+ tftpboot u-boot.bin
+
+The bridge also supports (to a lesser extent) the localhost interface, 'lo'.
+
+The 'lo' interface cannot use the RAW AF_PACKET API because the lo interface
+doesn't support Ethernet-level traffic. It is a higher-level interface that is
+expected only to be used at the AF_INET level of the API. As such, the most raw
+we can get on that interface is the RAW AF_INET API on UDP. This allows us to
+set the IP_HDRINCL option to include everything except the Ethernet header in
+the packets we send and receive.
+
+Because only UDP is supported, ICMP traffic will not work, so expect that ping
+commands will time out.
+
+The default device tree for sandbox includes an entry for lo on the sandbox
+host machine whose alias is "eth5". The following is an example of a network
+operation being tested on the lo interface.
+
+.. code-block:: none
+
+ TFTP
+ ....
+
+ setenv ethrotate no
+ setenv ethact eth5
+ tftpboot u-boot.bin
+
+
+SPI Emulation
+-------------
+
+Sandbox supports SPI and SPI flash emulation.
+
+The device can be enabled via a device tree, for example::
+
+ spi@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 1>;
+ compatible = "sandbox,spi";
+ cs-gpios = <0>, <&gpio_a 0>;
+ spi.bin@0 {
+ reg = <0>;
+ compatible = "spansion,m25p16", "jedec,spi-nor";
+ spi-max-frequency = <40000000>;
+ sandbox,filename = "spi.bin";
+ };
+ };
+
+The file must be created in advance::
+
+ $ dd if=/dev/zero of=spi.bin bs=1M count=2
+ $ u-boot -T
+
+Here, you can use "-T" or "-D" option to specify test.dtb or u-boot.dtb,
+respectively, or "-d <file>" for your own dtb.
+
+With this setup you can issue SPI flash commands as normal::
+
+ =>sf probe
+ SF: Detected M25P16 with page size 64 KiB, total 2 MiB
+ =>sf read 0 0 10000
+ SF: 65536 bytes @ 0x0 Read: OK
+
+Since this is a full SPI emulation (rather than just flash), you can
+also use low-level SPI commands::
+
+ =>sspi 0:0 32 9f
+ FF202015
+
+This is issuing a READ_ID command and getting back 20 (ST Micro) part
+0x2015 (the M25P16).
+
+
+Block Device Emulation
+----------------------
+
+U-Boot can use raw disk images for block device emulation. To e.g. list
+the contents of the root directory on the second partion of the image
+"disk.raw", you can use the following commands::
+
+ =>host bind 0 ./disk.raw
+ =>ls host 0:2
+
+The device can be marked removeable with 'host bind -r'.
+
+A disk image can be created using the following commands::
+
+ $> truncate -s 1200M ./disk.raw
+ $> echo -e "label: gpt\n,64M,U\n,,L" | /usr/sbin/sgdisk ./disk.raw
+ $> lodev=`sudo losetup -P -f --show ./disk.raw`
+ $> sudo mkfs.vfat -n EFI -v ${lodev}p1
+ $> sudo mkfs.ext4 -L ROOT -v ${lodev}p2
+
+or utilize the device described in test/py/make_test_disk.py::
+
+ #!/usr/bin/python
+ import make_test_disk
+ make_test_disk.makeDisk()
+
+Writing Sandbox Drivers
+-----------------------
+
+Generally you should put your driver in a file containing the word 'sandbox'
+and put it in the same directory as other drivers of its type. You can then
+implement the same hooks as the other drivers.
+
+To access U-Boot's emulated memory, use map_sysmem() as mentioned above.
+
+If your driver needs to store configuration or state (such as SPI flash
+contents or emulated chip registers), you can use the device tree as
+described above. Define handlers for this with the SANDBOX_STATE_IO macro.
+See arch/sandbox/include/asm/state.h for documentation. In short you provide
+a node name, compatible string and functions to read and write the state.
+Since writing the state can expand the device tree, you may need to use
+state_setprop() which does this automatically and avoids running out of
+space. See existing code for examples.
+
+
+Debugging the init sequence
+---------------------------
+
+If you get a failure in the initcall sequence, like this::
+
+ initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)
+
+Then you use can use grep to see which init call failed, e.g.::
+
+ $ grep 0000000000048134 u-boot.map
+ stdio_add_devices
+
+Of course another option is to run it with a debugger such as gdb::
+
+ $ gdb u-boot
+ ...
+ (gdb) br initcall.h:41
+ Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)
+
+Note that two locations are reported, since this function is used in both
+board_init_f() and board_init_r().
+
+.. code-block:: none
+
+ (gdb) r
+ Starting program: /tmp/b/sandbox/u-boot
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+
+ U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)
+
+ DRAM: 128 MiB
+ MMC:
+
+ Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
+ at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
+ 41 printf("initcall sequence %p failed at call %p (err=%d)\n",
+ (gdb) print *init_fnc_ptr
+ $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
+ (gdb)
+
+
+This approach can be used on normal boards as well as sandbox.
+
+
+SDL_CONFIG
+----------
+
+If sdl-config is on a different path from the default, set the SDL_CONFIG
+environment variable to the correct pathname before building U-Boot.
+
+
+Using valgrind / memcheck
+-------------------------
+
+It is possible to run U-Boot under valgrind to check memory allocations::
+
+ valgrind u-boot
+
+If you are running sandbox SPL or TPL, then valgrind will not by default
+notice when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. To
+fix this, use::
+
+ valgrind --trace-children=yes u-boot
+
+
+Testing
+-------
+
+U-Boot sandbox can be used to run various tests, mostly in the test/
+directory.
+
+See :doc:`../develop/tests_sandbox` for more information and
+:doc:`../develop/testing` for information about testing generally.
+
+
+Memory Map
+----------
+
+Sandbox has its own emulated memory starting at 0. Here are some of the things
+that are mapped into that memory:
+
+======= ======================== ===============================
+Addr Config Usage
+======= ======================== ===============================
+ 0 CONFIG_SYS_FDT_LOAD_ADDR Device tree
+ e000 CONFIG_BLOBLIST_ADDR Blob list
+ 10000 CONFIG_MALLOC_F_ADDR Early memory allocation
+ f0000 CONFIG_PRE_CON_BUF_ADDR Pre-console buffer
+ 100000 CONFIG_TRACE_EARLY_ADDR Early trace buffer (if enabled). Also used
+ as the SPL load buffer in spl_test_load().
+ 200000 CONFIG_SYS_TEXT_BASE Load buffer for U-Boot (sandbox_spl only)
+======= ======================== ===============================
diff --git a/roms/u-boot/doc/arch/sh.rst b/roms/u-boot/doc/arch/sh.rst
new file mode 100644
index 000000000..3e3759d68
--- /dev/null
+++ b/roms/u-boot/doc/arch/sh.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2007,2008 Nobuhiro Iwamatsu <iwamatsu@nigaur.org>
+
+SuperH
+======
+
+What's this?
+------------
+This file contains status information for the port of U-Boot to the
+Renesas SuperH series of CPUs.
+
+Overview
+--------
+SuperH has an original boot loader. However, source code is dirty, and
+maintenance is not done. To improve sharing and the maintenance of the code,
+Nobuhiro Iwamatsu started the porting to U-Boot in 2007.
+
+Supported CPUs
+--------------
+
+Renesas SH7750/SH7750R
+^^^^^^^^^^^^^^^^^^^^^^
+This CPU has the SH4 core.
+
+Renesas SH7722
+^^^^^^^^^^^^^^
+This CPU has the SH4AL-DSP core.
+
+Supported Boards
+----------------
+
+Hitachi UL MS7750SE01/MS7750RSE01
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Board specific code is in board/ms7750se
+To use this board, type "make ms7750se_config".
+Support devices are:
+
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+
+Hitachi UL MS7722SE01
+^^^^^^^^^^^^^^^^^^^^^
+Board specific code is in board/ms7722se
+To use this board, type "make ms7722se_config".
+Support devices are:
+
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+ - SMC91x ethernet
+
+Hitachi UL MS7720ERP01
+^^^^^^^^^^^^^^^^^^^^^^
+Board specific code is in board/ms7720se
+To use this board, type "make ms7720se_config".
+Support devices are:
+
+ - SCIF
+ - SDRAM
+ - NOR Flash
+ - Marubun PCMCIA
+
+In SuperH, S-record and binary of made u-boot work on the memory.
+When u-boot is written in the flash, it is necessary to change the
+address by using 'objcopy'::
+
+ ex) shX-linux-objcopy -Ibinary -Osrec u-boot.bin u-boot.flash.srec
+
+Compiler
+--------
+You can use the following of u-boot to compile.
+ - `SuperH Linux Open site <http://www.superh-linux.org/>`_
+ - `KPIT GNU tools <http://www.kpitgnutools.com/>`_
+
+Future
+------
+I plan to support the following CPUs and boards.
+
+CPUs
+^^^^
+- SH7751R(SH4)
+
+Boards
+^^^^^^
+Many boards ;-)
diff --git a/roms/u-boot/doc/arch/x86.rst b/roms/u-boot/doc/arch/x86.rst
new file mode 100644
index 000000000..2ebfed871
--- /dev/null
+++ b/roms/u-boot/doc/arch/x86.rst
@@ -0,0 +1,765 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2014, Simon Glass <sjg@chromium.org>
+.. Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
+
+x86
+===
+
+This document describes the information about U-Boot running on x86 targets,
+including supported boards, build instructions, todo list, etc.
+
+Status
+------
+U-Boot supports running as a `coreboot`_ payload on x86. So far only Link
+(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should
+work with minimal adjustments on other x86 boards since coreboot deals with
+most of the low-level details.
+
+U-Boot is a main bootloader on Intel Edison board.
+
+U-Boot also supports booting directly from x86 reset vector, without coreboot.
+In this case, known as bare mode, from the fact that it runs on the
+'bare metal', U-Boot acts like a BIOS replacement. The following platforms
+are supported:
+
+ - Bayley Bay CRB
+ - Cherry Hill CRB
+ - Congatec QEVAL 2.0 & conga-QA3/E3845
+ - Cougar Canyon 2 CRB
+ - Crown Bay CRB
+ - Galileo
+ - Link (Chromebook Pixel)
+ - Minnowboard MAX
+ - Samus (Chromebook Pixel 2015)
+ - QEMU x86 (32-bit & 64-bit)
+
+As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
+Linux kernel as part of a FIT image. It also supports a compressed zImage.
+U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks
+for more details.
+
+Build Instructions for U-Boot as BIOS replacement (bare mode)
+-------------------------------------------------------------
+Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a
+little bit tricky, as generally it requires several binary blobs which are not
+shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is
+not turned on by default in the U-Boot source tree. Firstly, you need turn it
+on by enabling the ROM build either via an environment variable::
+
+ $ export BUILD_ROM=y
+
+or via configuration::
+
+ CONFIG_BUILD_ROM=y
+
+Both tell the Makefile to build u-boot.rom as a target.
+
+CPU Microcode
+-------------
+Modern CPUs usually require a special bit stream called `microcode`_ to be
+loaded on the processor after power up in order to function properly. U-Boot
+has already integrated these as hex dumps in the source tree.
+
+SMP Support
+-----------
+On a multicore system, U-Boot is executed on the bootstrap processor (BSP).
+Additional application processors (AP) can be brought up by U-Boot. In order to
+have an SMP kernel to discover all of the available processors, U-Boot needs to
+prepare configuration tables which contain the multi-CPUs information before
+loading the OS kernel. Currently U-Boot supports generating two types of tables
+for SMP, called Simple Firmware Interface (`SFI`_) and Multi-Processor (`MP`_)
+tables. The writing of these two tables are controlled by two Kconfig
+options GENERATE_SFI_TABLE and GENERATE_MP_TABLE.
+
+Driver Model
+------------
+x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash,
+keyboard, real-time clock, USB. Video is in progress.
+
+Device Tree
+-----------
+x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to
+be turned on. Not every device on the board is configured via device tree, but
+more and more devices will be added as time goes by. Check out the directory
+arch/x86/dts/ for these device tree source files.
+
+Useful Commands
+---------------
+In keeping with the U-Boot philosophy of providing functions to check and
+adjust internal settings, there are several x86-specific commands that may be
+useful:
+
+fsp
+ Display information about Intel Firmware Support Package (FSP).
+ This is only available on platforms which use FSP, mostly Atom.
+iod
+ Display I/O memory
+iow
+ Write I/O memory
+mtrr
+ List and set the Memory Type Range Registers (MTRR). These are used to
+ tell the CPU whether memory is cacheable and if so the cache write
+ mode to use. U-Boot sets up some reasonable values but you can
+ adjust then with this command.
+
+Booting Ubuntu
+--------------
+As an example of how to set up your boot flow with U-Boot, here are
+instructions for starting Ubuntu from U-Boot. These instructions have been
+tested on Minnowboard MAX with a SATA drive but are equally applicable on
+other platforms and other media. There are really only four steps and it's a
+very simple script, but a more detailed explanation is provided here for
+completeness.
+
+Note: It is possible to set up U-Boot to boot automatically using syslinux.
+It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the
+GUID. If you figure these out, please post patches to this README.
+
+Firstly, you will need Ubuntu installed on an available disk. It should be
+possible to make U-Boot start a USB start-up disk but for now let's assume
+that you used another boot loader to install Ubuntu.
+
+Use the U-Boot command line to find the UUID of the partition you want to
+boot. For example our disk is SCSI device 0::
+
+ => part list scsi 0
+
+ Partition Map for SCSI device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00000800 0x001007ff ""
+ attrs: 0x0000000000000000
+ type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
+ guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c
+ 2 0x00100800 0x037d8fff ""
+ attrs: 0x0000000000000000
+ type: 0fc63daf-8483-4772-8e79-3d69d8477de4
+ guid: 965c59ee-1822-4326-90d2-b02446050059
+ 3 0x037d9000 0x03ba27ff ""
+ attrs: 0x0000000000000000
+ type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
+ guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17
+ =>
+
+This shows that your SCSI disk has three partitions. The really long hex
+strings are called Globally Unique Identifiers (GUIDs). You can look up the
+'type' ones `here`_. On this disk the first partition is for EFI and is in
+VFAT format (DOS/Windows)::
+
+ => fatls scsi 0:1
+ efi/
+
+ 0 file(s), 1 dir(s)
+
+
+Partition 2 is 'Linux filesystem data' so that will be our root disk. It is
+in ext2 format::
+
+ => ext2ls scsi 0:2
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 16384 lost+found
+ <DIR> 4096 boot
+ <DIR> 12288 etc
+ <DIR> 4096 media
+ <DIR> 4096 bin
+ <DIR> 4096 dev
+ <DIR> 4096 home
+ <DIR> 4096 lib
+ <DIR> 4096 lib64
+ <DIR> 4096 mnt
+ <DIR> 4096 opt
+ <DIR> 4096 proc
+ <DIR> 4096 root
+ <DIR> 4096 run
+ <DIR> 12288 sbin
+ <DIR> 4096 srv
+ <DIR> 4096 sys
+ <DIR> 4096 tmp
+ <DIR> 4096 usr
+ <DIR> 4096 var
+ <SYM> 33 initrd.img
+ <SYM> 30 vmlinuz
+ <DIR> 4096 cdrom
+ <SYM> 33 initrd.img.old
+ =>
+
+and if you look in the /boot directory you will see the kernel::
+
+ => ext2ls scsi 0:2 /boot
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 4096 efi
+ <DIR> 4096 grub
+ 3381262 System.map-3.13.0-32-generic
+ 1162712 abi-3.13.0-32-generic
+ 165611 config-3.13.0-32-generic
+ 176500 memtest86+.bin
+ 178176 memtest86+.elf
+ 178680 memtest86+_multiboot.bin
+ 5798112 vmlinuz-3.13.0-32-generic
+ 165762 config-3.13.0-58-generic
+ 1165129 abi-3.13.0-58-generic
+ 5823136 vmlinuz-3.13.0-58-generic
+ 19215259 initrd.img-3.13.0-58-generic
+ 3391763 System.map-3.13.0-58-generic
+ 5825048 vmlinuz-3.13.0-58-generic.efi.signed
+ 28304443 initrd.img-3.13.0-32-generic
+ =>
+
+The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of
+self-extracting compressed file mixed with some 'setup' configuration data.
+Despite its size (uncompressed it is >10MB) this only includes a basic set of
+device drivers, enough to boot on most hardware types.
+
+The 'initrd' files contain a RAM disk. This is something that can be loaded
+into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots
+of drivers for whatever hardware you might have. It is loaded before the
+real root disk is accessed.
+
+The numbers after the end of each file are the version. Here it is Linux
+version 3.13. You can find the source code for this in the Linux tree with
+the tag v3.13. The '.0' allows for additional Linux releases to fix problems,
+but normally this is not needed. The '-58' is used by Ubuntu. Each time they
+release a new kernel they increment this number. New Ubuntu versions might
+include kernel patches to fix reported bugs. Stable kernels can exist for
+some years so this number can get quite high.
+
+The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own
+secure boot mechanism - see `this`_ & `that`_. It cannot read .efi files
+at present.
+
+To boot Ubuntu from U-Boot the steps are as follows:
+
+1. Set up the boot arguments. Use the GUID for the partition you want to boot::
+
+ => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro
+
+Here root= tells Linux the location of its root disk. The disk is specified
+by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory'
+containing all the GUIDs Linux has found. When it starts up, there will be a
+file in that directory with this name in it. It is also possible to use a
+device name here, see later.
+
+2. Load the kernel. Since it is an ext2/4 filesystem we can do::
+
+ => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic
+
+The address 30000000 is arbitrary, but there seem to be problems with using
+small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into
+the start of RAM (which is at 0 on x86).
+
+3. Load the ramdisk (to 64MB)::
+
+ => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic
+
+4. Start up the kernel. We need to know the size of the ramdisk, but can use
+ a variable for that. U-Boot sets 'filesize' to the size of the last file it
+ loaded::
+
+ => zboot 03000000 0 04000000 ${filesize}
+
+Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is
+quite verbose when it boots a kernel. You should see these messages from
+U-Boot::
+
+ Valid Boot Flag
+ Setup Size = 0x00004400
+ Magic signature found
+ Using boot protocol version 2.0c
+ Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015
+ Building boot_params at 0x00090000
+ Loading bzImage at address 100000 (5805728 bytes)
+ Magic signature found
+ Initial RAM disk at linear address 0x04000000, size 19215259 bytes
+ Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro"
+
+ Starting kernel ...
+
+U-Boot prints out some bootstage timing. This is more useful if you put the
+above commands into a script since then it will be faster::
+
+ Timer summary in microseconds:
+ Mark Elapsed Stage
+ 0 0 reset
+ 241,535 241,535 board_init_r
+ 2,421,611 2,180,076 id=64
+ 2,421,790 179 id=65
+ 2,428,215 6,425 main_loop
+ 48,860,584 46,432,369 start_kernel
+
+ Accumulated time:
+ 240,329 ahci
+ 1,422,704 vesa display
+
+Now the kernel actually starts (if you want to examine kernel boot up message on
+the serial console, append "console=ttyS0,115200" to the kernel command line)::
+
+ [ 0.000000] Initializing cgroup subsys cpuset
+ [ 0.000000] Initializing cgroup subsys cpu
+ [ 0.000000] Initializing cgroup subsys cpuacct
+ [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22)
+ [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200
+
+It continues for a long time. Along the way you will see it pick up your
+ramdisk::
+
+ [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff]
+ ...
+ [ 0.788540] Trying to unpack rootfs image as initramfs...
+ [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000)
+ ...
+
+Later it actually starts using it::
+
+ Begin: Running /scripts/local-premount ... done.
+
+You should also see your boot disk turn up::
+
+ [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5
+ [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
+ [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0
+ [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off
+ [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+ [ 4.399535] sda: sda1 sda2 sda3
+
+Linux has found the three partitions (sda1-3). Mercifully it doesn't print out
+the GUIDs. In step 1 above we could have used::
+
+ setenv bootargs root=/dev/sda2 ro
+
+instead of the GUID. However if you add another drive to your board the
+numbering may change whereas the GUIDs will not. So if your boot partition
+becomes sdb2, it will still boot. For embedded systems where you just want to
+boot the first disk, you have that option.
+
+The last thing you will see on the console is mention of plymouth (which
+displays the Ubuntu start-up screen) and a lot of 'Starting' messages::
+
+ * Starting Mount filesystems on boot [ OK ]
+
+After a pause you should see a login screen on your display and you are done.
+
+If you want to put this in a script you can use something like this::
+
+ setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro
+ setenv boot zboot 03000000 0 04000000 \${filesize}
+ setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot"
+ saveenv
+
+The \ is to tell the shell not to evaluate ${filesize} as part of the setenv
+command.
+
+You can also bake this behaviour into your build by hard-coding the
+environment variables if you add this to minnowmax.h:
+
+.. code-block:: c
+
+ #undef CONFIG_BOOTCOMMAND
+ #define CONFIG_BOOTCOMMAND \
+ "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \
+ "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \
+ "run boot"
+
+ #undef CONFIG_EXTRA_ENV_SETTINGS
+ #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}"
+
+and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to::
+
+ CONFIG_BOOTARGS="root=/dev/sda2 ro"
+
+Test with SeaBIOS
+-----------------
+`SeaBIOS`_ is an open source implementation of a 16-bit x86 BIOS. It can run
+in an emulator or natively on x86 hardware with the use of U-Boot. With its
+help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS.
+
+As U-Boot, we have to manually create a table where SeaBIOS gets various system
+information (eg: E820) from. The table unfortunately has to follow the coreboot
+table format as SeaBIOS currently supports booting as a coreboot payload.
+
+To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on.
+Booting SeaBIOS is done via U-Boot's bootelf command, like below::
+
+ => tftp bios.bin.elf;bootelf
+ Using e1000#0 device
+ TFTP from server 10.10.0.100; our IP address is 10.10.0.108
+ ...
+ Bytes transferred = 122124 (1dd0c hex)
+ ## Starting application at 0x000ff06e ...
+ SeaBIOS (version rel-1.9.0)
+ ...
+
+bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree.
+Make sure it is built as follows::
+
+ $ make menuconfig
+
+Inside the "General Features" menu, select "Build for coreboot" as the
+"Build Target". Inside the "Debugging" menu, turn on "Serial port debugging"
+so that we can see something as soon as SeaBIOS boots. Leave other options
+as in their default state. Then::
+
+ $ make
+ ...
+ Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom)
+ Creating out/bios.bin.elf
+
+Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS
+to install/boot a Windows XP OS (below for example command to install Windows).
+
+.. code-block:: none
+
+ # Create a 10G disk.img as the virtual hard disk
+ $ qemu-img create -f qcow2 disk.img 10G
+
+ # Install a Windows XP OS from an ISO image 'winxp.iso'
+ $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512
+
+ # Boot a Windows XP OS installed on the virutal hard disk
+ $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512
+
+This is also tested on Intel Crown Bay board with a PCIe graphics card, booting
+SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally.
+
+If you are using Intel Integrated Graphics Device (IGD) as the primary display
+device on your board, SeaBIOS needs to be patched manually to get its VGA ROM
+loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM
+register, but IGD device does not have its VGA ROM mapped by this register.
+Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address
+which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below:
+
+.. code-block:: none
+
+ diff --git a/src/optionroms.c b/src/optionroms.c
+ index 65f7fe0..c7b6f5e 100644
+ --- a/src/optionroms.c
+ +++ b/src/optionroms.c
+ @@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources)
+ rom = deploy_romfile(file);
+ else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga))
+ rom = map_pcirom(pci);
+ + if (pci->bdf == pci_to_bdf(0, 2, 0))
+ + rom = (struct rom_header *)0xfff90000;
+ if (! rom)
+ // No ROM present.
+ return;
+
+Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM
+is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX.
+Change these two accordingly if this is not the case on your board.
+
+Development Flow
+----------------
+These notes are for those who want to port U-Boot to a new x86 platform.
+
+Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment.
+The Dediprog em100 can be used on Linux.
+
+The em100 tool is available here: http://review.coreboot.org/p/em100.git
+
+On Minnowboard Max the following command line can be used::
+
+ sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r
+
+A suitable clip for connecting over the SPI flash chip is here:
+http://www.dediprog.com/pd/programmer-accessories/EM-TC-8.
+
+This allows you to override the SPI flash contents for development purposes.
+Typically you can write to the em100 in around 1200ms, considerably faster
+than programming the real flash device each time. The only important
+limitation of the em100 is that it only supports SPI bus speeds up to 20MHz.
+This means that images must be set to boot with that speed. This is an
+Intel-specific feature - e.g. tools/ifttool has an option to set the SPI
+speed in the SPI descriptor region.
+
+If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly
+easy to fit it in. You can follow the Minnowboard Max implementation, for
+example. Hopefully you will just need to create new files similar to those
+in arch/x86/cpu/baytrail which provide Bay Trail support.
+
+If you are not using an FSP you have more freedom and more responsibility.
+The ivybridge support works this way, although it still uses a ROM for
+graphics and still has binary blobs containing Intel code. You should aim to
+support all important peripherals on your platform including video and storage.
+Use the device tree for configuration where possible.
+
+For the microcode you can create a suitable device tree file using the
+microcode tool::
+
+ ./tools/microcode-tool -d microcode.dat -m <model> create
+
+or if you only have header files and not the full Intel microcode.dat database::
+
+ ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \
+ -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h -m all create
+
+These are written to arch/x86/dts/microcode/ by default.
+
+Note that it is possible to just add the micrcode for your CPU if you know its
+model. U-Boot prints this information when it starts::
+
+ CPU: x86_64, vendor Intel, device 30673h
+
+so here we can use the M0130673322 file.
+
+If you platform can display POST codes on two little 7-segment displays on
+the board, then you can use post_code() calls from C or assembler to monitor
+boot progress. This can be good for debugging.
+
+If not, you can try to get serial working as early as possible. The early
+debug serial port may be useful here. See setup_internal_uart() for an example.
+
+During the U-Boot porting, one of the important steps is to write correct PIRQ
+routing information in the board device tree. Without it, device drivers in the
+Linux kernel won't function correctly due to interrupt is not working. Please
+refer to U-Boot `doc <doc/device-tree-bindings/misc/intel,irq-router.txt>`_ for
+the device tree bindings of Intel interrupt router. Here we have more details
+on the intel,pirq-routing property below.
+
+.. code-block:: none
+
+ intel,pirq-routing = <
+ PCI_BDF(0, 2, 0) INTA PIRQA
+ ...
+ >;
+
+As you see each entry has 3 cells. For the first one, we need describe all pci
+devices mounted on the board. For SoC devices, normally there is a chapter on
+the chipset datasheet which lists all the available PCI devices. For example on
+Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we
+can get the interrupt pin either from datasheet or hardware via U-Boot shell.
+The reliable source is the hardware as sometimes chipset datasheet is not 100%
+up-to-date. Type 'pci header' plus the device's pci bus/device/function number
+from U-Boot shell below::
+
+ => pci header 0.1e.1
+ vendor ID = 0x8086
+ device ID = 0x0f08
+ ...
+ interrupt line = 0x09
+ interrupt pin = 0x04
+ ...
+
+It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin
+register. Repeat this until you get interrupt pins for all the devices. The last
+cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel
+chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This
+can be changed by registers in LPC bridge. So far Intel FSP does not touch those
+registers so we can write down the PIRQ according to the default mapping rule.
+
+Once we get the PIRQ routing information in the device tree, the interrupt
+allocation and assignment will be done by U-Boot automatically. Now you can
+enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and
+CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC.
+
+This script might be useful. If you feed it the output of 'pci long' from
+U-Boot then it will generate a device tree fragment with the interrupt
+configuration for each device (note it needs gawk 4.0.0)::
+
+ $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \
+ /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \
+ {patsplit(device, bdf, "[0-9a-f]+"); \
+ printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \
+ strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}'
+
+Example output::
+
+ PCI_BDF(0, 2, 0) INTA PIRQA
+ PCI_BDF(0, 3, 0) INTA PIRQA
+ ...
+
+Porting Hints
+-------------
+
+Quark-specific considerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To port U-Boot to other boards based on the Intel Quark SoC, a few things need
+to be taken care of. The first important part is the Memory Reference Code (MRC)
+parameters. Quark MRC supports memory-down configuration only. All these MRC
+parameters are supplied via the board device tree. To get started, first copy
+the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then
+change these values by consulting board manuals or your hardware vendor.
+Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h.
+The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports,
+but by default they are held in reset after power on. In U-Boot, PCIe
+initialization is properly handled as per Quark's firmware writer guide.
+In your board support codes, you need provide two routines to aid PCIe
+initialization, which are board_assert_perst() and board_deassert_perst().
+The two routines need implement a board-specific mechanism to assert/deassert
+PCIe PERST# pin. Care must be taken that in those routines that any APIs that
+may trigger PCI enumeration process are strictly forbidden, as any access to
+PCIe root port's configuration registers will cause system hang while it is
+held in reset. For more details, check how they are implemented by the Intel
+Galileo board support codes in board/intel/galileo/galileo.c.
+
+coreboot
+^^^^^^^^
+
+See scripts/coreboot.sed which can assist with porting coreboot code into
+U-Boot drivers. It will not resolve all build errors, but will perform common
+transformations. Remember to add attribution to coreboot for new files added
+to U-Boot. This should go at the top of each file and list the coreboot
+filename where the code originated.
+
+Debugging ACPI issues with Windows
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Windows might cache system information and only detect ACPI changes if you
+modify the ACPI table versions. So tweak them liberally when debugging ACPI
+issues with Windows.
+
+ACPI Support Status
+-------------------
+Advanced Configuration and Power Interface (`ACPI`_) aims to establish
+industry-standard interfaces enabling OS-directed configuration, power
+management, and thermal management of mobile, desktop, and server platforms.
+
+Linux can boot without ACPI with "acpi=off" command line parameter, but
+with ACPI the kernel gains the capabilities to handle power management.
+For Windows, ACPI is a must-have firmware feature since Windows Vista.
+CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in
+U-Boot. This requires Intel ACPI compiler to be installed on your host to
+compile ACPI DSDT table written in ASL format to AML format. You can get
+the compiler via "apt-get install iasl" if you are on Ubuntu or download
+the source from https://www.acpica.org/downloads to compile one by yourself.
+
+Current ACPI support in U-Boot is basically complete. More optional features
+can be added in the future. The status as of today is:
+
+ * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables.
+ * Support one static DSDT table only, compiled by Intel ACPI compiler.
+ * Support S0/S3/S4/S5, reboot and shutdown from OS.
+ * Support booting a pre-installed Ubuntu distribution via 'zboot' command.
+ * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with
+ the help of SeaBIOS using legacy interface (non-UEFI mode).
+ * Support installing and booting Windows 8.1/10 from U-Boot with the help
+ of SeaBIOS using legacy interface (non-UEFI mode).
+ * Support ACPI interrupts with SCI only.
+
+Features that are optional:
+
+ * Dynamic AML bytecodes insertion at run-time. We may need this to support
+ SSDT table generation and DSDT fix up.
+ * SMI support. Since U-Boot is a modern bootloader, we don't want to bring
+ those legacy stuff into U-Boot. ACPI spec allows a system that does not
+ support SMI (a legacy-free system).
+
+ACPI was initially enabled on BayTrail based boards. Testing was done by booting
+a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and
+Windows 8.1/10 to a SATA drive and booting from there is also tested. Most
+devices seem to work correctly and the board can respond a reboot/shutdown
+command from the OS.
+
+For other platform boards, ACPI support status can be checked by examining their
+board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y.
+
+The S3 sleeping state is a low wake latency sleeping state defined by ACPI
+spec where all system context is lost except system memory. To test S3 resume
+with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will
+put the board to S3 state where the power is off. So when the power button is
+pressed again, U-Boot runs as it does in cold boot and detects the sleeping
+state via ACPI register to see if it is S3, if yes it means we are waking up.
+U-Boot is responsible for restoring the machine state as it is before sleep.
+When everything is done, U-Boot finds out the wakeup vector provided by OSes
+and jump there. To determine whether ACPI S3 resume is supported, check to
+see if CONFIG_HAVE_ACPI_RESUME is set for that specific board.
+
+Note for testing S3 resume with Windows, correct graphics driver must be
+installed for your platform, otherwise you won't find "Sleep" option in
+the "Power" submenu from the Windows start menu.
+
+EFI Support
+-----------
+U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
+This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
+UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
+The CONFIG_EFI_LOADER option, where U-Boot provides an EFI environment to
+the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
+services) is supported too. For example, we can even use 'bootefi' command
+to load a 'u-boot-payload.efi', see below test logs on QEMU.
+
+.. code-block:: none
+
+ => load ide 0 3000000 u-boot-payload.efi
+ 489787 bytes read in 138 ms (3.4 MiB/s)
+ => bootefi 3000000
+ Scanning disk ide.blk#0...
+ Found 2 disks
+ WARNING: booting without device tree
+ ## Starting EFI application at 03000000 ...
+ U-Boot EFI Payload
+
+
+ U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800)
+
+ CPU: x86_64, vendor AMD, device 663h
+ DRAM: 2 GiB
+ MMC:
+ Video: 1024x768x32
+ Model: EFI x86 Payload
+ Net: e1000: 52:54:00:12:34:56
+
+ Warning: e1000#0 using MAC address from ROM
+ eth0: e1000#0
+ No controllers found
+ Hit any key to stop autoboot: 0
+
+See :doc:`../develop/uefi/u-boot_on_efi` and :doc:`../develop/uefi/uefi` for
+details of EFI support in U-Boot.
+
+Chain-loading
+-------------
+U-Boot can be chain-loaded from another bootloader, such as coreboot or
+Slim Bootloader. Typically this is done by building for targets 'coreboot' or
+'slimbootloader'.
+
+For example, at present we have a 'coreboot' target but this runs very
+different code from the bare-metal targets, such as coral. There is very little
+in common between them.
+
+It is useful to be able to boot the same U-Boot on a device, with or without a
+first-stage bootloader. For example, with chromebook_coral, it is helpful for
+testing to be able to boot the same U-Boot (complete with FSP) on bare metal
+and from coreboot. It allows checking of things like CPU speed, comparing
+registers, ACPI tables and the like.
+
+To do this you can use ll_boot_init() in appropriate places to skip init that
+has already been done by the previous stage. This works by setting a
+GD_FLG_NO_LL_INIT flag when U-Boot detects that it is running from another
+bootloader.
+
+With this feature, you can build a bare-metal target and boot it from
+coreboot, for example.
+
+Note that this is a development feature only. It is not intended for use in
+production environments. Also it is not currently part of the automated tests
+so may break in the future.
+
+SMBIOS tables
+-------------
+
+To generate SMBIOS tables in U-Boot, for use by the OS, enable the
+CONFIG_GENERATE_SMBIOS_TABLE option. The easiest way to provide the values to
+use is via the device tree. For details see
+device-tree-bindings/sysinfo/smbios.txt
+
+TODO List
+---------
+- Audio
+- Chrome OS verified boot
+
+.. _coreboot: http://www.coreboot.org
+.. _QEMU: http://www.qemu.org
+.. _microcode: http://en.wikipedia.org/wiki/Microcode
+.. _SFI: http://simplefirmware.org
+.. _MP: http://www.intel.com/design/archives/processors/pro/docs/242016.htm
+.. _here: https://en.wikipedia.org/wiki/GUID_Partition_Table
+.. _this: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
+.. _that: http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf
+.. _SeaBIOS: http://www.seabios.org/SeaBIOS
+.. _ACPI: http://www.acpi.info
diff --git a/roms/u-boot/doc/arch/xtensa.rst b/roms/u-boot/doc/arch/xtensa.rst
new file mode 100644
index 000000000..176410d96
--- /dev/null
+++ b/roms/u-boot/doc/arch/xtensa.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xtensa
+======
+
+Xtensa Architecture and Diamond Cores
+-------------------------------------
+
+Xtensa is a configurable processor architecture from Tensilica, Inc.
+Diamond Cores are pre-configured instances available for license and
+SoC cores in the same manner as ARM, MIPS, etc.
+
+Xtensa licensees create their own Xtensa cores with selected features
+and custom instructions, registers and co-processors. The custom core
+is configured with Tensilica tools and built with Tensilica's Xtensa
+Processor Generator.
+
+There are an effectively infinite number of CPUs in the Xtensa
+architecture family. It is, however, not feasible to support individual
+Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU
+in the cpu tree of U-Boot.
+
+In the same manner as the Linux port to Xtensa, U-Boot adapts to an
+individual Xtensa core configuration using a set of macros provided with
+the particular core. This is part of what is known as the hardware
+abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only
+of a few header files. These provide CPP macros that customize sources,
+Makefiles, and the linker script.
+
+
+Adding support for an additional processor configuration
+--------------------------------------------------------
+
+The header files for one particular processor configuration are inside
+a variant-specific directory located in the arch/xtensa/include/asm
+directory. The name of that directory starts with 'arch-' followed by
+the name for the processor configuration, for example, arch-dc233c for
+the Diamond DC233 processor.
+
+core.h:
+ Definitions for the core itself.
+
+The following files are part of the overlay but not used by U-Boot.
+
+tie.h:
+ Co-processors and custom extensions defined in the Tensilica Instruction
+ Extension (TIE) language.
+tie-asm.h:
+ Assembly macros to access custom-defined registers and states.
+
+
+Global Data Pointer, Exported Function Stubs, and the ABI
+---------------------------------------------------------
+
+To support standalone applications launched with the "go" command,
+U-Boot provides a jump table of entrypoints to exported functions
+(grep for EXPORT_FUNC). The implementation for Xtensa depends on
+which ABI (or function calling convention) is used.
+
+Windowed ABI presents unique difficulties with the approach based on
+keeping global data pointer in dedicated register. Because the register
+window rotates during a call, there is no register that is constantly
+available for the gd pointer. Therefore, on xtensa gd is a simple
+global variable. Another difficulty arises from the requirement to have
+an 'entry' at the beginning of a function, which rotates the register
+file and reserves a stack frame. This is an integral part of the
+windowed ABI implemented in hardware. It makes using a jump table to an
+arbitrary (separately compiled) function a bit tricky. Use of a simple
+wrapper is also very tedious due to the need to move all possible
+register arguments and adjust the stack to handle arguments that cannot
+be passed in registers. The most efficient approach is to have the jump
+table perform the 'entry' so as to pretend it's the start of the real
+function. This requires decoding the target function's 'entry'
+instruction to determine the stack frame size, and adjusting the stack
+pointer accordingly, then jumping into the target function just after
+the 'entry'. Decoding depends on the processor's endianness so uses the
+HAL. The implementation (12 instructions) is in examples/stubs.c.
+
+
+Access to Invalid Memory Addresses
+----------------------------------
+
+U-Boot does not check if memory addresses given as arguments to commands
+such as "md" are valid. There are two possible types of invalid
+addresses: an area of physical address space may not be mapped to RAM
+or peripherals, or in the presence of MMU an area of virtual address
+space may not be mapped to physical addresses.
+
+Accessing first type of invalid addresses may result in hardware lockup,
+reading of meaningless data, written data being ignored or an exception,
+depending on the CPU wiring to the system. Accessing second type of
+invalid addresses always ends with an exception.
+
+U-Boot for Xtensa provides a special memory exception handler that
+reports such access attempts and resets the board.
+
+
+.. Chris Zankel
+.. Ross Morley
diff --git a/roms/u-boot/doc/board/AndesTech/adp-ag101p.rst b/roms/u-boot/doc/board/AndesTech/adp-ag101p.rst
new file mode 100644
index 000000000..879eba029
--- /dev/null
+++ b/roms/u-boot/doc/board/AndesTech/adp-ag101p.rst
@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+ADP-AG101P
+==========
+
+ADP-AG101P is the SoC with AG101 hardcore CPU.
+
+AG101P SoC
+----------
+
+AG101P is the mainline SoC produced by Andes Technology using N1213 CPU core
+with FPU and DDR contoller support.
+AG101P has integrated both AHB and APB bus and many periphals for application
+and product development.
+
+
+Configurations
+--------------
+
+CONFIG_MEM_REMAP:
+ Doing memory remap is essential for preparing some non-OS or RTOS
+ applications.
+
+CONFIG_SKIP_LOWLEVEL_INIT:
+ If you want to boot this system from SPI ROM and bypass e-bios (the
+ other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT
+ in "include/configs/adp-ag101p.h".
+
+Build and boot steps
+--------------------
+
+Build:
+
+1. Prepare the toolchains and make sure the $PATH to toolchains is correct.
+2. Use `make adp-ag101p_defconfig` in u-boot root to build the image.
+
+Burn U-Boot to SPI ROM
+----------------------
+
+This section will be added later.
diff --git a/roms/u-boot/doc/board/AndesTech/ax25-ae350.rst b/roms/u-boot/doc/board/AndesTech/ax25-ae350.rst
new file mode 100644
index 000000000..b46f427f4
--- /dev/null
+++ b/roms/u-boot/doc/board/AndesTech/ax25-ae350.rst
@@ -0,0 +1,524 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+AX25-AE350
+==========
+
+AE350 is the mainline SoC produced by Andes Technology using AX25 CPU core
+base on RISC-V architecture.
+
+AE350 has integrated both AHB and APB bus and many periphals for application
+and product development.
+
+AX25-AE350 is the SoC with AE350 hardcore CPU.
+
+AX25 is Andes CPU IP to adopt RISC-V architecture.
+
+AX25 Features
+-------------
+
+CPU Core
+ - 5-stage in-order execution pipeline
+ - Hardware Multiplier
+ - radix-2/radix-4/radix-16/radix-256/fast
+ - Hardware Divider
+ - Optional branch prediction
+ - Machine mode and optional user mode
+ - Optional performance monitoring
+
+ISA
+ - RV64I base integer instructions
+ - RVC for 16-bit compressed instructions
+ - RVM for multiplication and division instructions
+
+Memory subsystem
+ - I & D local memory
+ - Size: 4KB to 16MB
+ - Memory subsyetem soft-error protection
+ - Protection scheme: parity-checking or error-checking-and-correction (ECC)
+ - Automatic hardware error correction
+
+Bus
+ - Interface Protocol
+ - Synchronous AHB (32-bit/64-bit data-width), or
+ - Synchronous AXI4 (64-bit data-width)
+
+Power management
+ - Wait for interrupt (WFI) mode
+
+Debug
+ - Configurable number of breakpoints: 2/4/8
+ - External Debug Module
+ - AHB slave port
+ - External JTAG debug transport module
+
+Platform Level Interrupt Controller (PLIC)
+ - AHB slave port
+ - Configurable number of interrupts: 1-1023
+ - Configurable number of interrupt priorities: 3/7/15/63/127/255
+ - Configurable number of targets: 1-16
+ - Preempted interrupt priority stack
+
+Build and boot steps
+--------------------
+
+Build:
+
+1. Prepare the toolchains and make sure the $PATH to toolchains is correct.
+2. Use `make ae350_rv[32|64]_defconfig` in u-boot root to build the image for
+ 32 or 64 bit.
+
+Verification:
+
+1. startup
+2. relocation
+3. timer driver
+4. uart driver
+5. mac driver
+6. mmc driver
+7. spi driver
+
+Steps
+-----
+
+1. Ping a server by mac driver
+2. Scan sd card and copy u-boot image which is booted from flash to ram by sd driver
+3. Burn this u-boot image to spi rom by spi driver
+4. Re-boot u-boot from spi flash with power off and power on
+
+Messages of U-Boot boot on AE350 board
+--------------------------------------
+
+.. code-block:: none
+
+ U-Boot 2018.01-rc2-00033-g824f89a (Dec 21 2017 - 16:51:26 +0800)
+
+ DRAM: 1 GiB
+ MMC: mmc@f0e00000: 0
+ SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB
+ In: serial@f0300000
+ Out: serial@f0300000
+ Err: serial@f0300000
+ Net:
+ Warning: mac@e0100000 (eth0) using random MAC address - be:dd:d7:e4:e8:10
+ eth0: mac@e0100000
+
+ RISC-V # version
+ U-Boot 2018.01-rc2-00033-gb265b91-dirty (Dec 22 2017 - 13:54:21 +0800)
+
+ riscv32-unknown-linux-gnu-gcc (GCC) 7.2.0
+ GNU ld (GNU Binutils) 2.29
+
+ RISC-V # setenv ipaddr 10.0.4.200 ;
+ RISC-V # setenv serverip 10.0.4.97 ;
+ RISC-V # ping 10.0.4.97 ;
+ Using mac@e0100000 device
+ host 10.0.4.97 is alive
+
+ RISC-V # mmc rescan
+ RISC-V # fatls mmc 0:1
+ 318907 u-boot-ae350-64.bin
+ 1252 hello_world_ae350_32.bin
+ 328787 u-boot-ae350-32.bin
+
+ 3 file(s), 0 dir(s)
+
+ RISC-V # sf probe 0:0 50000000 0
+ SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB
+
+ RISC-V # sf test 0x100000 0x1000
+ SPI flash test:
+ 0 erase: 36 ticks, 111 KiB/s 0.888 Mbps
+ 1 check: 29 ticks, 137 KiB/s 1.096 Mbps
+ 2 write: 40 ticks, 100 KiB/s 0.800 Mbps
+ 3 read: 20 ticks, 200 KiB/s 1.600 Mbps
+ Test passed
+ 0 erase: 36 ticks, 111 KiB/s 0.888 Mbps
+ 1 check: 29 ticks, 137 KiB/s 1.096 Mbps
+ 2 write: 40 ticks, 100 KiB/s 0.800 Mbps
+ 3 read: 20 ticks, 200 KiB/s 1.600 Mbps
+
+ RISC-V # fatload mmc 0:1 0x600000 u-boot-ae350-32.bin
+ reading u-boot-ae350-32.bin
+ 328787 bytes read in 324 ms (990.2 KiB/s)
+
+ RISC-V # sf erase 0x0 0x51000
+ SF: 331776 bytes @ 0x0 Erased: OK
+
+ RISC-V # sf write 0x600000 0x0 0x50453
+ device 0 offset 0x0, size 0x50453
+ SF: 328787 bytes @ 0x0 Written: OK
+
+ RISC-V # crc32 0x600000 0x50453
+ crc32 for 00600000 ... 00650452 ==> 692dc44a
+
+ RISC-V # crc32 0x80000000 0x50453
+ crc32 for 80000000 ... 80050452 ==> 692dc44a
+ RISC-V #
+
+ *** power-off and power-on, this U-Boot is booted from spi flash ***
+
+ U-Boot 2018.01-rc2-00032-gf67dd47-dirty (Dec 21 2017 - 13:56:03 +0800)
+
+ DRAM: 1 GiB
+ MMC: mmc@f0e00000: 0
+ SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB
+ In: serial@f0300000
+ Out: serial@f0300000
+ Err: serial@f0300000
+ Net:
+ Warning: mac@e0100000 (eth0) using random MAC address - ee:4c:58:29:32:f5
+ eth0: mac@e0100000
+ RISC-V #
+
+
+Boot bbl and riscv-linux via U-Boot on QEMU
+-------------------------------------------
+
+1. Build riscv-linux
+2. Build bbl and riscv-linux with --with-payload
+3. Prepare ae350.dtb
+4. Creating OS-kernel images
+
+.. code-block:: none
+
+ ./mkimage -A riscv -O linux -T kernel -C none -a 0x0000 -e 0x0000 -d bbl.bin bootmImage-bbl.bin
+ Image Name:
+ Created: Tue Mar 13 10:06:42 2018
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 17901204 Bytes = 17481.64 KiB = 17.07 MiB
+ Load Address: 00000000
+ Entry Point: 00000000
+
+5. Copy bootmImage-bbl.bin and ae350.dtb to qemu sd card image
+6. Message of booting riscv-linux from bbl via u-boot on qemu
+
+.. code-block:: none
+
+ U-Boot 2018.03-rc4-00031-g2631273 (Mar 13 2018 - 15:02:55 +0800)
+
+ DRAM: 1 GiB
+ main-loop: WARNING: I/O thread spun for 1000 iterations
+ MMC: mmc@f0e00000: 0
+ Loading Environment from SPI Flash... *** Warning - spi_flash_probe_bus_cs() failed, using default environment
+
+ Failed (-22)
+ In: serial@f0300000
+ Out: serial@f0300000
+ Err: serial@f0300000
+ Net:
+ Warning: mac@e0100000 (eth0) using random MAC address - 02:00:00:00:00:00
+ eth0: mac@e0100000
+ RISC-V # mmc rescan
+ RISC-V # mmc part
+
+ Partition Map for MMC device 0 -- Partition Type: DOS
+
+ Part Start Sector Num Sectors UUID Type
+ RISC-V # fatls mmc 0:0
+ 17901268 bootmImage-bbl.bin
+ 1954 ae2xx.dtb
+
+ 2 file(s), 0 dir(s)
+
+ RISC-V # fatload mmc 0:0 0x00600000 bootmImage-bbl.bin
+ 17901268 bytes read in 4642 ms (3.7 MiB/s)
+ RISC-V # fatload mmc 0:0 0x2000000 ae350.dtb
+ 1954 bytes read in 1 ms (1.9 MiB/s)
+ RISC-V # setenv bootm_size 0x2000000
+ RISC-V # setenv fdt_high 0x1f00000
+ RISC-V # bootm 0x00600000 - 0x2000000
+ ## Booting kernel from Legacy Image at 00600000 ...
+ Image Name:
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 17901204 Bytes = 17.1 MiB
+ Load Address: 00000000
+ Entry Point: 00000000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 02000000
+ Booting using the fdt blob at 0x2000000
+ Loading Kernel Image ... OK
+ Loading Device Tree to 0000000001efc000, end 0000000001eff7a1 ... OK
+ [ 0.000000] OF: fdt: Ignoring memory range 0x0 - 0x200000
+ [ 0.000000] Linux version 4.14.0-00046-gf3e439f-dirty (rick@atcsqa06) (gcc version 7.1.1 20170509 (GCC)) #1 Tue Jan 9 16:34:25 CST 2018
+ [ 0.000000] bootconsole [early0] enabled
+ [ 0.000000] Initial ramdisk at: 0xffffffe000016a98 (12267008 bytes)
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA [mem 0x0000000000200000-0x000000007fffffff]
+ [ 0.000000] Normal empty
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000000200000-0x000000007fffffff]
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x000000007fffffff]
+ [ 0.000000] elf_hwcap is 0x112d
+ [ 0.000000] random: fast init done
+ [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 516615
+ [ 0.000000] Kernel command line: console=ttyS0,38400n8 earlyprintk=uart8250-32bit,0xf0300000 debug loglevel=7
+ [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
+ [ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
+ [ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] Memory: 2047832K/2095104K available (1856K kernel code, 204K rwdata, 532K rodata, 12076K init, 756K bss, 47272K reserved, 0K cma-reserved)
+ [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
+ [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
+ [ 0.000000] riscv,cpu_intc,0: 64 local interrupts mapped
+ [ 0.000000] riscv,plic0,e4000000: mapped 31 interrupts to 1/2 handlers
+ [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
+ [ 0.000000] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=40000)
+ [ 0.000000] pid_max: default: 32768 minimum: 301
+ [ 0.004000] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
+ [ 0.004000] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
+ [ 0.056000] devtmpfs: initialized
+ [ 0.060000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+ [ 0.064000] futex hash table entries: 256 (order: 0, 6144 bytes)
+ [ 0.068000] NET: Registered protocol family 16
+ [ 0.080000] vgaarb: loaded
+ [ 0.084000] clocksource: Switched to clocksource riscv_clocksource
+ [ 0.088000] NET: Registered protocol family 2
+ [ 0.092000] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
+ [ 0.096000] TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
+ [ 0.096000] TCP: Hash tables configured (established 16384 bind 16384)
+ [ 0.100000] UDP hash table entries: 1024 (order: 3, 32768 bytes)
+ [ 0.100000] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
+ [ 0.104000] NET: Registered protocol family 1
+ [ 0.616000] Unpacking initramfs...
+ [ 1.220000] workingset: timestamp_bits=62 max_order=19 bucket_order=0
+ [ 1.244000] io scheduler noop registered
+ [ 1.244000] io scheduler cfq registered (default)
+ [ 1.244000] io scheduler mq-deadline registered
+ [ 1.248000] io scheduler kyber registered
+ [ 1.360000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ [ 1.368000] console [ttyS0] disabled
+ [ 1.372000] f0300000.serial: ttyS0 at MMIO 0xf0300020 (irq = 10, base_baud = 1228800) is a 16550A
+ [ 1.392000] console [ttyS0] enabled
+ [ 1.392000] ftmac100: Loading version 0.2 ...
+ [ 1.396000] ftmac100 e0100000.mac eth0: irq 8, mapped at ffffffd002005000
+ [ 1.400000] ftmac100 e0100000.mac eth0: generated random MAC address 6e:ac:c3:92:36:c0
+ [ 1.404000] IR NEC protocol handler initialized
+ [ 1.404000] IR RC5(x/sz) protocol handler initialized
+ [ 1.404000] IR RC6 protocol handler initialized
+ [ 1.404000] IR JVC protocol handler initialized
+ [ 1.408000] IR Sony protocol handler initialized
+ [ 1.408000] IR SANYO protocol handler initialized
+ [ 1.408000] IR Sharp protocol handler initialized
+ [ 1.408000] IR MCE Keyboard/mouse protocol handler initialized
+ [ 1.412000] IR XMP protocol handler initialized
+ [ 1.456000] ftsdc010 f0e00000.mmc: mmc0 - using hw SDIO IRQ
+ [ 1.464000] bootconsole [early0] uses init memory and must be disabled even before the real one is ready
+ [ 1.464000] bootconsole [early0] disabled
+ [ 1.508000] Freeing unused kernel memory: 12076K
+ [ 1.512000] This architecture does not have kernel memory protection.
+ [ 1.520000] mmc0: new SD card at address 4567
+ [ 1.524000] mmcblk0: mmc0:4567 QEMU! 20.0 MiB
+ [ 1.844000] mmcblk0:
+ Wed Dec 1 10:00:00 CST 2010
+ / #
+
+
+Running U-Boot SPL
+------------------
+The U-Boot SPL will boot in M mode and load the FIT image which include
+OpenSBI and U-Boot proper images. After loading progress, it will jump
+to OpenSBI first and then U-Boot proper which will run in S mode.
+
+
+How to build U-Boot SPL
+-----------------------
+Before building U-Boot SPL, OpenSBI must be build first. OpenSBI can be
+cloned and build for AE350 as below:
+
+.. code-block:: none
+
+ git clone https://github.com/riscv/opensbi.git
+ cd opensbi
+ make PLATFORM=andes/ae350
+
+Copy OpenSBI FW_DYNAMIC image (build/platform/andes/ae350/firmware/fw_dynamic.bin)
+into U-Boot root directory
+
+
+How to build U-Boot SPL booting from RAM
+----------------------------------------
+With ae350_rv[32|64]_spl_defconfigs:
+
+U-Boot SPL will be loaded by gdb or FSBL and runs in RAM in machine mode
+and then load FIT image from RAM device on AE350.
+
+
+How to build U-Boot SPL booting from ROM
+----------------------------------------
+With ae350_rv[32|64]_spl_xip_defconfigs:
+
+U-Boot SPL can be burned into SPI flash and run in flash in machine mode
+and then load FIT image from SPI flash or MMC device on AE350.
+
+
+Messages of U-Boot SPL boots Kernel on AE350 board
+--------------------------------------------------
+
+.. code-block:: none
+
+ U-Boot SPL 2020.01-rc1-00292-g67a3313-dirty (Nov 14 2019 - 11:26:21 +0800)
+ Trying to boot from RAM
+
+ OpenSBI v0.5-1-gdd8ef28 (Nov 14 2019 11:08:39)
+ ____ _____ ____ _____
+ / __ \ / ____| _ \_ _|
+ | | | |_ __ ___ _ __ | (___ | |_) || |
+ | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
+ | |__| | |_) | __/ | | |____) | |_) || |_
+ \____/| .__/ \___|_| |_|_____/|____/_____|
+ | |
+ |_|
+
+ Platform Name : Andes AE350
+ Platform HART Features : RV64ACIMSUX
+ Platform Max HARTs : 4
+ Current Hart : 0
+ Firmware Base : 0x0
+ Firmware Size : 84 KB
+ Runtime SBI Version : 0.2
+
+ PMP0: 0x0000000000000000-0x000000000001ffff (A)
+ PMP1: 0x0000000000000000-0x00000001ffffffff (A,R,W,X)
+
+
+ U-Boot 2020.01-rc1-00292-g67a3313-dirty (Nov 14 2019 - 11:26:21 +0800)
+
+ DRAM: 1 GiB
+ Flash: 64 MiB
+ MMC: mmc@f0e00000: 0
+ Loading Environment from SPI Flash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB
+ OK
+ In: serial@f0300000
+ Out: serial@f0300000
+ Err: serial@f0300000
+ Net: no alias for ethernet0
+
+ Warning: mac@e0100000 (eth0) using random MAC address - a2:ae:93:7b:cc:8f
+ eth0: mac@e0100000
+ Hit any key to stop autoboot: 0
+ 6455 bytes read in 31 ms (203.1 KiB/s)
+ 20421684 bytes read in 8647 ms (2.3 MiB/s)
+ ## Booting kernel from Legacy Image at 00600000 ...
+ Image Name:
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 20421620 Bytes = 19.5 MiB
+ Load Address: 00200000
+ Entry Point: 00200000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 20000000
+ Booting using the fdt blob at 0x20000000
+ Loading Kernel Image
+ Loading Device Tree to 000000001effb000, end 000000001efff936 ... OK
+
+ Starting kernel ...
+
+ OF: fdt: Ignoring memory range 0x0 - 0x200000
+ Linux version 4.17.0-00253-g49136e10bcb2 (sqa@atcsqa07) (gcc version 7.3.0 (2019-04-06_nds64le-linux-glibc-v5_experimental)) #1 SMP PREEMPT Sat Apr 6 23:41:49 CST 2019
+ bootconsole [early0] enabled
+ Initial ramdisk at: 0x (ptrval) (13665712 bytes)
+ Zone ranges:
+ DMA32 [mem 0x0000000000200000-0x000000003fffffff]
+ Normal empty
+ Movable zone start for each node
+ Early memory node ranges
+ node 0: [mem 0x0000000000200000-0x000000003fffffff]
+ Initmem setup node 0 [mem 0x0000000000200000-0x000000003fffffff]
+ software IO TLB [mem 0x3b1f8000-0x3f1f8000] (64MB) mapped at [ (ptrval)- (ptrval)]
+ elf_platform is rv64i2p0m2p0a2p0c2p0xv5-0p0
+ compatible privileged spec version 1.10
+ percpu: Embedded 16 pages/cpu @ (ptrval) s28184 r8192 d29160 u65536
+ Built 1 zonelists, mobility grouping on. Total pages: 258055
+ Kernel command line: console=ttyS0,38400n8 debug loglevel=7
+ log_buf_len individual max cpu contribution: 4096 bytes
+ log_buf_len total cpu_extra contributions: 12288 bytes
+ log_buf_len min size: 16384 bytes
+ log_buf_len: 32768 bytes
+ early log buf free: 14608(89%)
+ Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
+ Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
+ Sorting __ex_table...
+ Memory: 944428K/1046528K available (3979K kernel code, 246K rwdata, 1490K rodata, 13523K init, 688K bss, 102100K reserved, 0K cma-reserved)
+ SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+ Preemptible hierarchical RCU implementation.
+ Tasks RCU enabled.
+ NR_IRQS: 72, nr_irqs: 72, preallocated irqs: 0
+ riscv,cpu_intc,0: 64 local interrupts mapped
+ riscv,cpu_intc,1: 64 local interrupts mapped
+ riscv,cpu_intc,2: 64 local interrupts mapped
+ riscv,cpu_intc,3: 64 local interrupts mapped
+ riscv,plic0,e4000000: mapped 71 interrupts to 8/8 handlers
+ clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1bacf917bf, max_idle_ns: 881590412290 ns
+ sched_clock: 64 bits at 60MHz, resolution 16ns, wraps every 4398046511098ns
+ Console: colour dummy device 40x30
+ Calibrating delay loop (skipped), value calculated using timer frequency.. 120.00 BogoMIPS (lpj=600000)
+ pid_max: default: 32768 minimum: 301
+ Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
+ Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
+ Hierarchical SRCU implementation.
+ smp: Bringing up secondary CPUs ...
+ CPU0: online
+ CPU2: online
+ CPU3: online
+ smp: Brought up 1 node, 4 CPUs
+ devtmpfs: initialized
+ random: get_random_u32 called from bucket_table_alloc+0x198/0x1d8 with crng_init=0
+ clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+ futex hash table entries: 1024 (order: 4, 65536 bytes)
+ NET: Registered protocol family 16
+ Advanced Linux Sound Architecture Driver Initialized.
+ clocksource: Switched to clocksource riscv_clocksource
+ NET: Registered protocol family 2
+ tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes)
+ TCP established hash table entries: 8192 (order: 4, 65536 bytes)
+ TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
+ TCP: Hash tables configured (established 8192 bind 8192)
+ UDP hash table entries: 512 (order: 2, 16384 bytes)
+ UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
+ NET: Registered protocol family 1
+ RPC: Registered named UNIX socket transport module.
+ RPC: Registered udp transport module.
+ RPC: Registered tcp transport module.
+ RPC: Registered tcp NFSv4.1 backchannel transport module.
+ Unpacking initramfs...
+ workingset: timestamp_bits=62 max_order=18 bucket_order=0
+ NFS: Registering the id_resolver key type
+ Key type id_resolver registered
+ Key type id_legacy registered
+ nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+ io scheduler noop registered
+ io scheduler cfq registered (default)
+ io scheduler mq-deadline registered
+ io scheduler kyber registered
+ Console: switching to colour frame buffer device 40x30
+ Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ console [ttyS0] disabled
+ f0300000.serial: ttyS0 at MMIO 0xf0300020 (irq = 20, base_baud = 1228800) is a 16550A
+ console [ttyS0] enabled
+ console [ttyS0] enabled
+ bootconsole [early0] disabled
+ bootconsole [early0] disabled
+ loop: module loaded
+ tun: Universal TUN/TAP device driver, 1.6
+ ftmac100: Loading version 0.2 ...
+ ftmac100 e0100000.mac eth0: irq 21, mapped at (ptrval)
+ ftmac100 e0100000.mac eth0: generated random MAC address 4e:fd:bd:f3:04:fc
+ ftsdc010 f0e00000.mmc: mmc0 - using hw SDIO IRQ
+ mmc0: new SDHC card at address d555
+ ftssp010 card registered!
+ mmcblk0: mmc0:d555 SD04G 3.79 GiB
+ NET: Registered protocol family 10
+ mmcblk0: p1
+ Segment Routing with IPv6
+ sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+ NET: Registered protocol family 17
+ NET: Registered protocol family 15
+ ALSA device list:
+ #0: ftssp_ac97 controller
+ Freeing unused kernel memory: 13520K
+ This architecture does not have kernel memory protection.
+ Sysinit starting
+ Sat Apr 6 23:33:53 CST 2019
+ nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
+
+ ~ #
diff --git a/roms/u-boot/doc/board/AndesTech/index.rst b/roms/u-boot/doc/board/AndesTech/index.rst
new file mode 100644
index 000000000..d8f7d155f
--- /dev/null
+++ b/roms/u-boot/doc/board/AndesTech/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Andes Tech
+==========
+
+.. toctree::
+ :maxdepth: 2
+
+ adp-ag101p
+ ax25-ae350
diff --git a/roms/u-boot/doc/board/actions/cubieboard7.rst b/roms/u-boot/doc/board/actions/cubieboard7.rst
new file mode 100644
index 000000000..74f2b12e4
--- /dev/null
+++ b/roms/u-boot/doc/board/actions/cubieboard7.rst
@@ -0,0 +1,114 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020 Amit Singh Tomar <amittomer25@gmail.com>
+
+CUBIEBOARD7
+===========
+
+About this
+----------
+
+This document describes build and flash steps for Actions S700 SoC based Cubieboard7
+board.
+
+Cubieboard7 initial configuration
+---------------------------------
+
+Default Cubieboard7 comes with pre-installed Android where U-Boot is configured with
+a bootdelay of 0, entering a prompt by pressing keys does not seem to work.
+
+Though, one can enter ADFU mode and flash debian image(from host machine) where
+getting into u-boot prompt is easy.
+
+Enter ADFU Mode
+----------------
+
+Before write the firmware, let the development board entering the ADFU mode: insert
+one end of the USB cable to the PC, press and hold the ADFU button, and then connect
+the other end of the USB cable to the Mini USB port of the development board, release
+the ADFU button, after connecting it will enter the ADFU mode.
+
+Check whether entered ADFU Mode
+--------------------------------
+
+The user needs to run the following command on the PC side to check if the ADFU
+device is detected. ID realted to "Actions Semiconductor Co., Ltd" means that
+the PC side has been correctly detected ADFU device, the development board
+also enter into the ADFU mode.
+
+.. code-block:: none
+
+ $ lsusb
+ Bus 001 Device 005: ID 04f2:b2eb Chicony Electronics Co., Ltd
+ Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
+ Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
+ Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
+ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+ Bus 003 Device 013: ID 10d6:10d6 Actions Semiconductor Co., Ltd
+ Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+
+Flashing debian image
+---------------------
+
+.. code-block:: none
+
+ $ sudo ./ActionsFWU.py --fw=debian-stretch-desktop-cb7-emmc-v2.0.fw
+ ActionsFWU.py : 1.0.150828.0830
+ libScript.so : 2.3.150825.0951
+ libFileSystem.so: 2.3.150825.0952
+ libProduction.so: 2.3.150915.1527
+ =====burn all partition====
+ FW_VER: 3.10.37.180608
+ 3% DOWNLOAD ADFUDEC ...
+ 5% DOWNLOAD BOOT PARA ...
+ 7% SWITCH ADFUDEC ...
+ 12% DOWNLOAD BL31 ...
+ 13% DOWNLOAD BL32 ...
+ 15% DOWNLOAD VMLINUX ...
+ 20% DOWNLOAD INITRD ...
+ 24% DOWNLOAD FDT ...
+ 27% DOWNLOAD ADFUS ...
+ 30% SWITCH ADFUS ...
+ 32% DOWNLOAD MBR ...
+ 35% DOWNLOAD PARTITIONS ...
+ WRITE_MBRC_PARTITION
+ 35% write p0 size = 2048 : ok
+ WRITE_BOOT_PARTITION
+ 35% write p1 size = 2048 : ok
+ WRITE_MISC_PARTITION
+ 36% write p2 size = 98304 : ok
+ WRITE_SYSTEM_PARTITION
+ 94% write p3 size = 4608000 : ok
+ FORMAT_SWAP_PARTITION
+ 94% write p4 size = 20480 : ok
+ 95% TRANSFER OVER ...
+ Firmware upgrade successfully!
+
+Debian image can be downloaded from here[1].
+
+Once debian image is flashed, one can get into u-boot prompt by pressing any key and from
+there run ums command(make sure, usb cable is connected between host and target):
+
+.. code-block:: none
+
+ owl> ums 0 mmc 1
+
+Above command would mount debian image partition on host machine.
+
+Building U-BOOT proper image
+----------------------------
+
+.. code-block:: none
+
+ $ make clean
+ $ export CROSS_COMPILE=aarch64-linux-gnu-
+ $ make cubieboard7_defconfig
+ $ make u-boot-dtb.img -j16
+
+u-boot-dtb.img can now be flashed to debian image partition mounted on host machine.
+
+.. code-block:: none
+
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1024 seek=3072
+
+[1]: https://pan.baidu.com/s/1uawPr0Jao2HgWFLZCLzHAg#list/path=%2FCubieBoard_Download%2FBoard%2FCubieBoard7%2F%E6%96%B9%E7%B3%96%E6%96%B9%E6%A1%88%E5%BC%80%E5%8F%91%E8%B5%84%E6%96%99%2FImage%2FDebian%2FV2.1-test&parentPath=%2F
diff --git a/roms/u-boot/doc/board/actions/index.rst b/roms/u-boot/doc/board/actions/index.rst
new file mode 100644
index 000000000..c59687915
--- /dev/null
+++ b/roms/u-boot/doc/board/actions/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020 Amit Singh Tomar <amittomer25@gmail.com>
+
+Actions
+========
+
+.. toctree::
+ :maxdepth: 2
+
+ cubieboard7
diff --git a/roms/u-boot/doc/board/advantech/imx8qm-rom7720-a1.rst b/roms/u-boot/doc/board/advantech/imx8qm-rom7720-a1.rst
new file mode 100644
index 000000000..bd4be1dbe
--- /dev/null
+++ b/roms/u-boot/doc/board/advantech/imx8qm-rom7720-a1.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the NXP i.MX8QM ROM 7720a1 board
+===========================================
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Get imx-mkimage
+- Build U-Boot
+- Build imx-mkimage
+- Flash the binary into the SD card
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ git clone https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ git checkout origin/imx_4.14.78_1.0.0_ga -b imx_4.14.78_1.0.0_ga
+ $ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.1.bin
+ $ chmod +x imx-sc-firmware-1.1.bin
+ $ ./imx-sc-firmware-1.1.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+ $ chmod +x firmware-imx-8.0.bin
+ $ ./firmware-imx-8.0.bin
+
+Or use this to avoid running random scripts from the internet,
+but note that you must agree to the license the script displays:
+
+.. code-block:: bash
+
+ $ dd if=imx-sc-firmware-1.1.bin of=imx-sc-firmware-1.1.tar.bz2 bs=37185 skip=1
+ $ tar -xf imx-sc-firmware-1.1.tar.bz2
+ $ cp imx-sc-firmware-1.1/mx8qm-val-scfw-tcm.bin $(builddir)
+
+ $ dd if=firmware-imx-8.0.bin of=firmware-imx-8.0.tar.bz2 bs=37180 skip=1
+ $ tar -xf firmware-imx-8.0.tar.bz2
+ $ cp firmware-imx-8.0/firmware/seco/mx8qm-ahab-container.img $(builddir)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export ATF_LOAD_ADDR=0x80000000
+ $ export BL33_LOAD_ADDR=0x80020000
+ $ make imx8qm_rom7720_a1_4G_defconfig
+ $ make u-boot.bin
+ $ make flash.bin
+
+Flash the binary into the SD card
+---------------------------------
+
+Burn the flash.bin binary to SD card offset 32KB:
+
+.. code-block:: bash
+
+ $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
+
+Boot
+----
+
+Set Boot switch SW2: 1100.
diff --git a/roms/u-boot/doc/board/advantech/index.rst b/roms/u-boot/doc/board/advantech/index.rst
new file mode 100644
index 000000000..e9b198c5c
--- /dev/null
+++ b/roms/u-boot/doc/board/advantech/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Advantech
+=========
+
+.. toctree::
+ :maxdepth: 2
+
+ imx8qm-rom7720-a1.rst
diff --git a/roms/u-boot/doc/board/amlogic/beelink-gtking.rst b/roms/u-boot/doc/board/amlogic/beelink-gtking.rst
new file mode 100644
index 000000000..56ce2cb27
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/beelink-gtking.rst
@@ -0,0 +1,115 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Beelink GT-King
+==========================
+
+The Shenzen AZW (Beelink) GT-King is based on the Amlogic W400 reference
+board with an S922X-H chip.
+
+- 4GB LPDDR4 RAM
+- 64GB eMMC storage
+- 10/100/1000 Base-T Ethernet
+- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
+- HDMI 2.1 video
+- S/PDIF optical output
+- Analogue audio output
+- 1x USB 2.0 port
+- 2x USB 3.0 ports
+- IR receiver
+- 1x micro SD card slot
+
+Beelink do not provide public schematics, but have been willing
+to share them with known distro developers on request.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make beelink-gtking_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic does not provide sources for the firmware and for tools needed
+to create the bootloader image. Beelink have provided the Amlogic "SDK"
+in their forums, but the u-boot sources included result in 2GB RAM being
+detected. The following FIPs were generated with newer private sources
+and give correct (4GB) RAM detection:
+
+https://github.com/LibreELEC/amlogic-boot-fip/tree/master/beelink-s922x
+
+NB: Beelink use a common board config for GT-King, GT-King Pro and the
+GS-King-X model, hence the "beelink-s922x" name.
+
+.. code-block:: bash
+
+ $ wget https://github.com/LibreELEC/amlogic-boot-fip/archive/master.zip
+ $ unzip master.zip
+ $ export FIPDIR=$PWD/amlogic-boot-fip/beelink-s922x
+
+Go back to the mainline U-Boot source tree then:
+
+.. code-block:: bash
+
+ $ mkdir fip
+ $ cp $FIPDIR/* fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ fip/aml_encrypt_g12b --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ fip/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ fip/aml_encrypt_g12b --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/beelink-gtkingpro.rst b/roms/u-boot/doc/board/amlogic/beelink-gtkingpro.rst
new file mode 100644
index 000000000..d75035136
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/beelink-gtkingpro.rst
@@ -0,0 +1,116 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Beelink GT-King Pro
+==============================
+
+The Shenzen AZW (Beelink) GT-King Pro is based on the Amlogic W400 reference
+board with an S922X-H chip.
+
+- 4GB LPDDR4 RAM
+- 64GB eMMC storage
+- 10/100/1000 Base-T Ethernet
+- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
+- HDMI 2.1 video
+- Analogue audio output
+- 1x RS232 port
+- 2x USB 2.0 port
+- 2x USB 3.0 ports
+- IR receiver
+- 1x SD card slot
+- 1x Power on/off button
+
+Beelink do not provide public schematics, but have been willing
+to share them with known distro developers on request.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make beelink-gtkingpro_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic does not provide sources for the firmware and for tools needed
+to create the bootloader image. Beelink have provided the Amlogic "SDK"
+in their forums, but the u-boot sources included result in 2GB RAM being
+detected. The following FIPs were generated with newer private sources
+and give correct (4GB) RAM detection:
+
+https://github.com/LibreELEC/amlogic-boot-fip/tree/master/beelink-s922x
+
+NB: Beelink use a common board config for GT-King, GT-King Pro and the
+GS-King-X model, hence the "beelink-s922x" name.
+
+.. code-block:: bash
+
+ $ wget https://github.com/LibreELEC/amlogic-boot-fip/archive/master.zip
+ $ unzip master.zip
+ $ export FIPDIR=$PWD/amlogic-boot-fip/beelink-s922x
+
+Go back to the mainline U-Boot source tree then:
+
+.. code-block:: bash
+
+ $ mkdir fip
+ $ cp $FIPDIR/* fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ fip/aml_encrypt_g12b --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ fip/aml_encrypt_g12b --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ fip/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ fip/aml_encrypt_g12b --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/index.rst b/roms/u-boot/doc/board/amlogic/index.rst
new file mode 100644
index 000000000..8da7afddb
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/index.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Amlogic
+=======
+
+Hardware Support Matrix
+-----------------------
+
+An up-do-date matrix is also available on: http://linux-meson.com
+
+This matrix concerns the actual source code version.
+
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| | S905 | S905X | S912 | A113X | S905X2 | S922X | S905X3 |
+| | | S805X | S905D | | S905D2 | A311D | S905D3 |
+| | | | | | S905Y2 | | |
++===============================+===========+=================+==============+============+============+=============+==============+
+| Boards | Odroid-C2 | P212 | Khadas VIM2 | S400 | U200 | Odroid-N2 | SEI610 |
+| | Nanopi-K2 | Khadas-VIM | Libretech-PC | | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
+| | P200 | LibreTech-CC v1 | WeTek Core2 | | | GT-King/Pro | Odroid-C4 |
+| | P201 | LibreTech-AC v2 | | | | | |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| UART | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Pinctrl/GPIO | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Clock Control | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| PWM | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Reset Control | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Infrared Decoder | No | No | No | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Ethernet | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Multi-core | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Fuse access | **Yes** | **Yes** |**Yes** |**Yes** |**Yes** |**Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| SPI (FC) | **Yes** | **Yes** | **Yes** | **Yes** |**Yes** | **Yes** | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| SPI (CC) | No | No | No | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| I2C | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| USB | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| USB OTG | No | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| eMMC | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| SDCard | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| NAND | No | No | No | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| ADC | **Yes** | **Yes** | **Yes** | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| CVBS Output | **Yes** | **Yes** | **Yes** | *N/A* | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| HDMI Output | **Yes** | **Yes** | **Yes** | *N/A* | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| CEC | No | No | No | *N/A* | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| Thermal Sensor | No | No | No | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| LCD/LVDS Output | No | *N/A* | No | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| MIPI DSI Output | *N/A* | *N/A* | *N/A* | No | No | No | No |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| SoC (version) information | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+| PCIe (+NVMe) | *N/A* | *N/A* | *N/A* | **Yes** | **Yes** | **Yes** | **Yes** |
++-------------------------------+-----------+-----------------+--------------+------------+------------+-------------+--------------+
+
+Board Documentation
+-------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ beelink-gtking
+ beelink-gtkingpro
+ khadas-vim2
+ khadas-vim3l
+ khadas-vim3
+ khadas-vim
+ libretech-ac
+ libretech-cc
+ nanopi-k2
+ odroid-c2
+ odroid-c4
+ odroid-n2
+ p200
+ p201
+ p212
+ q200
+ s400
+ sei510
+ sei610
+ u200
+ wetek-core2
+ w400
diff --git a/roms/u-boot/doc/board/amlogic/khadas-vim.rst b/roms/u-boot/doc/board/amlogic/khadas-vim.rst
new file mode 100644
index 000000000..bbb61c29e
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/khadas-vim.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Khadas VIM
+======================
+
+Khadas VIM is an Open Source DIY Box manufactured by Shenzhen Wesion
+Technology Co., Ltd with the following specifications:
+
+ - Amlogic S905X ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 2 x USB 2.0 Host, 1 x USB 2.0 Type-C OTG
+ - 8GB/16GBeMMC
+ - microSD
+ - SDIO Wifi Module, Bluetooth
+ - Two channels IR receiver
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make khadas-vim_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
+ $ cd vim-u-boot
+ $ make kvim_defconfig
+ $ make CROSS_COMPILE=aarch64-none-elf-
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/khadas-vim2.rst b/roms/u-boot/doc/board/amlogic/khadas-vim2.rst
new file mode 100644
index 000000000..c57d96d8b
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/khadas-vim2.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Khadas VIM2
+=======================
+
+Khadas VIM2 is an Open Source DIY Box manufactured by Shenzhen Wesion
+Technology Co., Ltd with the following specifications:
+
+ - Amlogic S912 ARM Cortex-A53 octo-core SoC @ 1.5GHz
+ - ARM Mali T860 GPU
+ - 2/3GB DDR4 SDRAM
+ - 10/100/1000 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 2 x USB 2.0 Host, 1 x USB 2.0 Type-C OTG
+ - 16GB/32GB/64GB eMMC
+ - 2MB SPI Flash
+ - microSD
+ - SDIO Wifi Module, Bluetooth
+ - Two channels IR receiver
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make khadas-vim2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 vim-u-boot
+ $ cd vim-u-boot
+ $ make kvim2_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/khadas-vim3.rst b/roms/u-boot/doc/board/amlogic/khadas-vim3.rst
new file mode 100644
index 000000000..8b7196d98
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/khadas-vim3.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Khadas VIM3
+======================
+
+Khadas VIM3 is a single board computer manufactured by Shenzhen Wesion
+Technology Co., Ltd. with the following specifications:
+
+ - Amlogic A311D Arm Cortex-A53 dual-core + Cortex-A73 quad-core SoC
+ - 4GB LPDDR4 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.1 display
+ - 40-pin GPIO header
+ - 1 x USB 3.0 Host, 1 x USB 2.0 Host
+ - eMMC, microSD
+ - M.2
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+PCIe Setup
+----------
+The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
+lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
+an USB3.0 Type A connector and a M.2 Key M slot.
+The PHY driving these differential lines is shared between
+the USB3.0 controller and the PCIe Controller, thus only
+a single controller can use it.
+
+To setup for PCIe, run the following commands from U-Boot:
+
+.. code-block:: none
+
+ i2c dev i2c@5000
+ i2c mw 0x18 0x33 1
+
+Then power-cycle the board.
+
+To set back to USB3.0, run the following commands from U-Boot:
+
+.. code-block:: none
+
+ i2c dev i2c@5000
+ i2c mw 0x18 0x33 0
+
+Then power-cycle the board.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make khadas-vim3_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+
+ $ DIR=vim3-u-boot
+ $ git clone --depth 1 \
+ https://github.com/khadas/u-boot.git -b khadas-vims-v2015.01 \
+ $DIR
+
+ $ cd vim3-u-boot
+ $ make kvim3_defconfig
+ $ make CROSS_COMPILE=aarch64-none-elf-
+ $ export UBOOTDIR=$PWD
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/khadas/kvim3/firmware/acs.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl2.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl30.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl31.img fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/diag_lpddr4.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/lpddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/lpddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/lpddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/piei.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/aml_ddr.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ bash fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ bash fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33 --compress lz4
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --ddrfw9 fip/lpddr3_1d.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/khadas-vim3l.rst b/roms/u-boot/doc/board/amlogic/khadas-vim3l.rst
new file mode 100644
index 000000000..aed895539
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/khadas-vim3l.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Khadas VIM3L
+=======================
+
+Khadas VIM3L is a single board computer manufactured by Shenzhen Wesion
+Technology Co., Ltd. with the following specifications:
+
+ - Amlogic S905D3 Arm Cortex-A55 quad-core SoC
+ - 2GB LPDDR4 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.1 display
+ - 40-pin GPIO header
+ - 1 x USB 3.0 Host, 1 x USB 2.0 Host
+ - eMMC, microSD
+ - M.2
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+PCIe Setup
+----------
+The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
+lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
+an USB3.0 Type A connector and a M.2 Key M slot.
+The PHY driving these differential lines is shared between
+the USB3.0 controller and the PCIe Controller, thus only
+a single controller can use it.
+
+To setup for PCIe, run the following commands from U-Boot:
+
+.. code-block:: none
+
+ i2c dev i2c@5000
+ i2c mw 0x18 0x33 1
+
+Then power-cycle the board.
+
+To set back to USB3.0, run the following commands from U-Boot:
+
+.. code-block:: none
+
+ i2c dev i2c@5000
+ i2c mw 0x18 0x33 0
+
+Then power-cycle the board.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make khadas-vim3l_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+
+ $ DIR=vim3l-u-boot
+ $ git clone --depth 1 \
+ https://github.com/khadas/u-boot.git -b khadas-vims-v2015.01 \
+ $DIR
+
+ $ cd vim3l-u-boot
+ $ make kvim3l_defconfig
+ $ make CROSS_COMPILE=aarch64-none-elf-
+ $ export UBOOTDIR=$PWD
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/khadas/kvim3l/firmware/acs.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl2.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl30.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl31.img fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/diag_lpddr4.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/piei.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/aml_ddr.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ bash fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ bash fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33 --compress lz4
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --ddrfw9 fip/lpddr3_1d.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/libretech-ac.rst b/roms/u-boot/doc/board/amlogic/libretech-ac.rst
new file mode 100644
index 000000000..39bae86d3
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/libretech-ac.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for LibreTech AC
+=======================
+
+LibreTech AC is a single board computer manufactured by Libre Technology
+with the following specifications:
+
+ - Amlogic S805X ARM Cortex-A53 quad-core SoC @ 1.2GHz
+ - ARM Mali 450 GPU
+ - 512MiB DDR4 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 4 x USB 2.0 Host
+ - eMMC, SPI NOR Flash
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make libretech-ac_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b libretech-ac amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ wget https://raw.githubusercontent.com/BayLibre/u-boot/libretech-cc/fip/blx_fix.sh
+ $ make libretech_ac_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Download the latest Amlogic Buildroot package, and extract it :
+
+.. code-block:: bash
+
+ $ wget http://openlinux2.amlogic.com:8000/ARM/filesystem/Linux_BSP/buildroot_openlinux_kernel_4.9_fbdev_20180418.tar.gz
+ $ tar xfz buildroot_openlinux_kernel_4.9_fbdev_20180418.tar.gz buildroot_openlinux_kernel_4.9_fbdev_20180418/bootloader
+ $ export BRDIR=$PWD/buildroot_openlinux_kernel_4.9_fbdev_20180418
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/libretech_ac/firmware/bl21.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/libretech_ac/firmware/acs.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl2/bin/gxl/bl2.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl30/bin/gxl/bl30.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl31/bin/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh $UBOOTDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $BRDIR/bootloader/uboot-repo/fip/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ sh $UBOOTDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $BRDIR/bootloader/uboot-repo/fip/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $BRDIR/bootloader/uboot-repo/fip/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $BRDIR/bootloader/uboot-repo/fip/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $BRDIR/bootloader/uboot-repo/fip/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $BRDIR/bootloader/uboot-repo/fip/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/libretech-cc.rst b/roms/u-boot/doc/board/amlogic/libretech-cc.rst
new file mode 100644
index 000000000..94c74c5a8
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/libretech-cc.rst
@@ -0,0 +1,146 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for LibreTech CCs
+========================
+
+LibreTech CC is a single board computer manufactured by Libre Technology
+with the following specifications:
+
+V1:
+
+ - Amlogic S905X ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 4 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - Jack for CVBS and Audio
+
+V2:
+
+ - Added SPI NOR
+ - Removed Jack
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make libretech-cc_defconfig
+ $ make
+
+Use libretech-cc_v2_defconfig for v2.
+
+Image creation
+--------------
+
+To boot the system, u-boot must be combined with several earlier stage
+bootloaders:
+
+* bl2.bin: vendor-provided binary blob
+* bl21.bin: built from vendor u-boot source
+* bl30.bin: vendor-provided binary blob
+* bl301.bin: built from vendor u-boot source
+* bl31.bin: vendor-provided binary blob
+* acs.bin: built from vendor u-boot source
+
+These binaries and the tools required below have been collected and prebuilt
+for convenience at <https://github.com/BayLibre/u-boot/releases/>. These
+apply to both v1 and v2.
+
+Download and extract the libretech-cc release from there, and set FIPDIR to
+point to the `fip` subdirectory.
+
+.. code-block:: bash
+
+ $ export FIPDIR=/path/to/extracted/fip
+
+Alternatively, you can obtain the original vendor u-boot tree which
+contains the required blobs and sources, and build yourself.
+Note that old compilers are required for this to build. The compilers here
+are suggested by Amlogic, and they are 32-bit x86 binaries.
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b libretech-cc amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make libretech_cc_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Once you have the binaries available (either through the prebuilt download,
+or having built the vendor u-boot yourself), you can then proceed to glue
+everything together. Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
+
+Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no
+source code. Should you prefer to avoid that, there are open source reverse
+engineered versions available:
+
+1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy
+ Makefile that automates the whole process.
+2. meson-tools <https://github.com/afaerber/meson-tools>
+
+However, these community-developed alternatives are not endorsed by or
+supported by Amlogic.
diff --git a/roms/u-boot/doc/board/amlogic/nanopi-k2.rst b/roms/u-boot/doc/board/amlogic/nanopi-k2.rst
new file mode 100644
index 000000000..1222ee4e8
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/nanopi-k2.rst
@@ -0,0 +1,104 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for NanoPi-K2
+====================
+
+NanoPi-K2 is a single board computer manufactured by FriendlyElec
+with the following specifications:
+
+ - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 4 x USB 2.0 Host, 1 x USB OTG
+ - eMMC, microSD
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make nanopi-k2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b libretech-cc amlogic-u-boot
+ $ git clone https://github.com/friendlyarm/u-boot.git -b nanopi-k2-v2015.01 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ sed -i 's/aarch64-linux-gnu-/aarch64-none-elf-/' Makefile
+ $ sed -i 's/arm-linux-/arm-none-eabi-/' arch/arm/cpu/armv8/gxb/firmware/scp_task/Makefile
+ $ make nanopi-k2_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxb/bl2.bin fip/
+ $ cp $FIPDIR/gxb/acs.bin fip/
+ $ cp $FIPDIR/gxb/bl21.bin fip/
+ $ cp $FIPDIR/gxb/bl30.bin fip/
+ $ cp $FIPDIR/gxb/bl301.bin fip/
+ $ cp $FIPDIR/gxb/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/fip_create \
+ --bl30 fip/bl30_new.bin \
+ --bl31 fip/bl31.img \
+ --bl33 fip/bl33.bin \
+ fip/fip.bin
+
+ $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ cat fip/bl2_new.bin fip/fip.bin > fip/boot_new.bin
+
+ $ $FIPDIR/gxb/aml_encrypt_gxb --bootsig \
+ --input fip/boot_new.bin
+ --output fip/u-boot.bin
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin of=$DEV conv=fsync,notrunc bs=512 seek=1
diff --git a/roms/u-boot/doc/board/amlogic/odroid-c2.rst b/roms/u-boot/doc/board/amlogic/odroid-c2.rst
new file mode 100644
index 000000000..966c18b36
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/odroid-c2.rst
@@ -0,0 +1,63 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for ODROID-C2
+====================
+
+ODROID-C2 is a single board computer manufactured by Hardkernel
+Co. Ltd with the following specifications:
+
+ - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 2GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 40-pin GPIO header
+ - 4 x USB 2.0 Host, 1 x USB OTG
+ - eMMC, microSD
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make odroid-c2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ DIR=odroid-c2
+ $ git clone --depth 1 \
+ https://github.com/hardkernel/u-boot.git -b odroidc2-v2015.01 \
+ $DIR
+ $ $DIR/fip/fip_create --bl30 $DIR/fip/gxb/bl30.bin \
+ --bl301 $DIR/fip/gxb/bl301.bin \
+ --bl31 $DIR/fip/gxb/bl31.bin \
+ --bl33 u-boot.bin \
+ $DIR/fip.bin
+ $ $DIR/fip/fip_create --dump $DIR/fip.bin
+ $ cat $DIR/fip/gxb/bl2.package $DIR/fip.bin > $DIR/boot_new.bin
+ $ $DIR/fip/gxb/aml_encrypt_gxb --bootsig \
+ --input $DIR/boot_new.bin \
+ --output $DIR/u-boot.img
+ $ dd if=$DIR/u-boot.img of=$DIR/u-boot.gxbb bs=512 skip=96
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ BL1=$DIR/sd_fuse/bl1.bin.hardkernel
+ $ dd if=$BL1 of=$DEV conv=fsync bs=1 count=442
+ $ dd if=$BL1 of=$DEV conv=fsync bs=512 skip=1 seek=1
+ $ dd if=$DIR/u-boot.gxbb of=$DEV conv=fsync bs=512 seek=97
diff --git a/roms/u-boot/doc/board/amlogic/odroid-c4.rst b/roms/u-boot/doc/board/amlogic/odroid-c4.rst
new file mode 100644
index 000000000..5a5a8688b
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/odroid-c4.rst
@@ -0,0 +1,134 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for ODROID-C4
+====================
+
+ODROID-C4 is a single board computer manufactured by Hardkernel
+Co. Ltd with the following specifications:
+
+ - Amlogic S905X3 Arm Cortex-A55 quad-core SoC
+ - 4GB DDR4 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.1 display
+ - 40-pin GPIO header
+ - 4x USB 3.0 Host
+ - 1x USB 2.0 Host/OTG (micro)
+ - eMMC, microSD
+ - UART serial
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make odroid-c4_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+
+ $ DIR=odroid-c4
+ $ git clone --depth 1 \
+ https://github.com/hardkernel/u-boot.git -b odroidg12-v2015.01 \
+ $DIR
+
+ $ cd odroid-c4
+ $ make odroidc4_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/hardkernel/odroidc4/firmware/acs.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl2.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl30.bin fip/
+ $ cp $UBOOTDIR/fip/g12a/bl31.img fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/ddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/diag_lpddr4.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/lpddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/piei.fw fip/
+ $ cp $UBOOTDIR/fip/g12a/aml_ddr.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33 --compress lz4
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $UBOOTDIR/fip/g12a/aml_encrypt_g12a --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --ddrfw9 fip/lpddr3_1d.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/odroid-n2.rst b/roms/u-boot/doc/board/amlogic/odroid-n2.rst
new file mode 100644
index 000000000..fe6311323
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/odroid-n2.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for ODROID-N2
+====================
+
+ODROID-N2 is a single board computer manufactured by Hardkernel
+Co. Ltd with the following specifications:
+
+ - Amlogic S922X ARM Cortex-A53 dual-core + Cortex-A73 quad-core SoC
+ - 4GB DDR4 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.1 4K/60Hz display
+ - 40-pin GPIO header
+ - 4 x USB 3.0 Host, 1 x USB OTG
+ - eMMC, microSD
+ - Infrared receiver
+
+Schematics are available on the manufacturer website.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make odroid-n2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+
+ $ DIR=odroid-n2
+ $ git clone --depth 1 \
+ https://github.com/hardkernel/u-boot.git -b odroidn2-v2015.01 \
+ $DIR
+
+ $ cd odroid-n2
+ $ make odroidn2_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+ Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/hardkernel/odroidn2/firmware/acs.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl2.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl30.bin fip/
+ $ cp $UBOOTDIR/fip/g12b/bl31.img fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr3_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/ddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/diag_lpddr4.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/lpddr4_1d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/lpddr4_2d.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/piei.fw fip/
+ $ cp $UBOOTDIR/fip/g12b/aml_ddr.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33 --compress lz4
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $UBOOTDIR/fip/g12b/aml_encrypt_g12b --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/p200.rst b/roms/u-boot/doc/board/amlogic/p200.rst
new file mode 100644
index 000000000..c3d6441fd
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/p200.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic P200
+=======================
+
+P200 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - SDIO WiFi Module
+ - CVBS+Stereo Audio Jack
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make p200_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make gxb_p200_v1_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/p201.rst b/roms/u-boot/doc/board/amlogic/p201.rst
new file mode 100644
index 000000000..06da933a2
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/p201.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic P201
+=======================
+
+P201 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - SDIO WiFi Module
+ - CVBS+Stereo Audio Jack
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make p201_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make gxb_p201_v1_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/p212.rst b/roms/u-boot/doc/board/amlogic/p212.rst
new file mode 100644
index 000000000..e2f3fe313
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/p212.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic P212
+=======================
+
+P212 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905X ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - SDIO WiFi Module
+ - CVBS+Stereo Audio Jack
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make p212_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make gxl_p212_v1_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/q200.rst b/roms/u-boot/doc/board/amlogic/q200.rst
new file mode 100644
index 000000000..3ac4116be
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/q200.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic Q200
+=======================
+
+Q200 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S912 ARM Cortex-A53 octo-core SoC @ 1.5GHz
+ - ARM Mali T860 GPU
+ - 2/3GB DDR4 SDRAM
+ - 10/100/1000 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host, 1 x USB 2.0 Device
+ - 16GB/32GB/64GB eMMC
+ - 2MB SPI Flash
+ - microSD
+ - SDIO Wifi Module, Bluetooth
+ - IR receiver
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make khadas-vim2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make gxm_q200_v1_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/s400.rst b/roms/u-boot/doc/board/amlogic/s400.rst
new file mode 100644
index 000000000..52c7b2733
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/s400.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic S400
+=======================
+
+S400 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic A113DX ARM Cortex-A53 quad-core SoC @ 1.2GHz
+ - 1GB DDR4 SDRAM
+ - 10/100 Ethernet
+ - 2 x USB 2.0 Host
+ - eMMC
+ - Infrared receiver
+ - SDIO WiFi Module
+ - MIPI DSI Connector
+ - Audio HAT Connector
+ - PCI-E M.2 Connectors
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make s400_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make axg_s400_v1_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ cp $FIPDIR/axg/bl2.bin fip/
+ $ cp $FIPDIR/axg/acs.bin fip/
+ $ cp $FIPDIR/axg/bl21.bin fip/
+ $ cp $FIPDIR/axg/bl30.bin fip/
+ $ cp $FIPDIR/axg/bl301.bin fip/
+ $ cp $FIPDIR/axg/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/axg/aml_encrypt_axg --bl3sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $FIPDIR/axg/aml_encrypt_axg --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $FIPDIR/axg/aml_encrypt_axg --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ $FIPDIR/axg/aml_encrypt_axg --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $FIPDIR/axg/aml_encrypt_axg --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/sei510.rst b/roms/u-boot/doc/board/amlogic/sei510.rst
new file mode 100644
index 000000000..2d296b1c3
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/sei510.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic SEI510
+=========================
+
+SEI510 is a customer board manufactured by SEI Robotics with the following
+specifications:
+
+ - Amlogic S905X2 ARM Cortex-A53 quad-core SoC
+ - 2GB DDR4 SDRAM
+ - 10/100 Ethernet (Internal PHY)
+ - 1 x USB 3.0 Host
+ - eMMC
+ - SDcard
+ - Infrared receiver
+ - SDIO WiFi Module
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make sei510_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b buildroot-openlinux-20180418 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make g12a_u200_v1_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Download the latest Amlogic Buildroot package, and extract it :
+
+.. code-block:: bash
+
+ $ wget http://openlinux2.amlogic.com:8000/ARM/filesystem/Linux_BSP/buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz
+ $ tar xfz buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz buildroot_openlinux_kernel_4.9_fbdev_20180706/bootloader
+ $ export BRDIR=$PWD/buildroot_openlinux_kernel_4.9_fbdev_20180706
+ $ export FIPDIR=$BRDIR/bootloader/uboot-repo/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/g12a_u200_v1/firmware/acs.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl2/bin/g12a/bl2.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl30/bin/g12a/bl30.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl31_1.3/bin/g12a/bl31.img fip/
+ $ cp $FIPDIR/g12a/ddr3_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/diag_lpddr4.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/piei.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/sei610.rst b/roms/u-boot/doc/board/amlogic/sei610.rst
new file mode 100644
index 000000000..9434e6f02
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/sei610.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic SEI610
+=========================
+
+SEI610 is a customer board manufactured by SEI Robotics with the following
+specifications:
+
+ - Amlogic S905X3 ARM Cortex-A55 quad-core SoC
+ - 2GB DDR4 SDRAM
+ - 10/100 Ethernet (Internal PHY)
+ - 1 x USB 3.0 Host
+ - 1 x USB Type-C DRD
+ - 1 x FTDI USB Serial Debug Interface
+ - eMMC
+ - SDcard
+ - Infrared receiver
+ - SDIO WiFi Module
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make sei610_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b buildroot-openlinux-4.9-g12a-201904 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make sm1_ac200_v1_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Download the latest Amlogic Buildroot package, and extract it :
+
+.. code-block:: bash
+
+ $ wget http://openlinux2.amlogic.com:8000/ARM/filesystem/buildroot-openlinux-A113-201901.tgz
+ $ tar xfz buildroot-openlinux-A113-201901.tgz buildroot-openlinux-A113-201901/bootloader
+ $ export BRDIR=$PWD/buildroot-openlinux-A113-201901
+ $ export FIPDIR=$BRDIR/bootloader/uboot-repo/fip
+
+Go back to mainline U-Boot source tree then :
+
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/g12a_u200_v1/firmware/acs.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl2/bin/g12a/bl2.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl30/bin/g12a/bl30.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl31_1.3/bin/g12a/bl31.img fip/
+ $ cp $FIPDIR/g12a/ddr3_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/diag_lpddr4.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/piei.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/u200.rst b/roms/u-boot/doc/board/amlogic/u200.rst
new file mode 100644
index 000000000..5aa3936c2
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/u200.rst
@@ -0,0 +1,135 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic U200
+=======================
+
+U200 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905D2 ARM Cortex-A53 quad-core SoC
+ - 2GB DDR4 SDRAM
+ - 10/100 Ethernet (Internal PHY)
+ - 1 x USB 3.0 Host
+ - eMMC
+ - SDcard
+ - Infrared receiver
+ - SDIO WiFi Module
+ - MIPI DSI Connector
+ - Audio HAT Connector
+ - PCI-E M.2 Connector
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make u200_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b buildroot-openlinux-20180418 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make g12a_u200_v1_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Download the latest Amlogic Buildroot package, and extract it :
+
+.. code-block:: bash
+
+ $ wget http://openlinux2.amlogic.com:8000/ARM/filesystem/Linux_BSP/buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz
+ $ tar xfz buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz buildroot_openlinux_kernel_4.9_fbdev_20180706/bootloader
+ $ export BRDIR=$PWD/buildroot_openlinux_kernel_4.9_fbdev_20180706
+ $ export FIPDIR=$BRDIR/bootloader/uboot-repo/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/g12a_u200_v1/firmware/acs.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl2/bin/g12a/bl2.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl30/bin/g12a/bl30.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl31_1.3/bin/g12a/bl31.img fip/
+ $ cp $FIPDIR/g12a/ddr3_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/ddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/diag_lpddr4.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_1d.fw fip/
+ $ cp $FIPDIR/g12a/lpddr4_2d.fw fip/
+ $ cp $FIPDIR/g12a/piei.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $FIPDIR/g12a/aml_encrypt_g12a --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/w400.rst b/roms/u-boot/doc/board/amlogic/w400.rst
new file mode 100644
index 000000000..38dbf52fb
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/w400.rst
@@ -0,0 +1,137 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Amlogic W400
+=======================
+
+U200 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S922X ARM Cortex-A53 dual-core + Cortex-A73 quad-core SoC
+ - 2GB DDR4 SDRAM
+ - 10/100 Ethernet (Internal PHY)
+ - 1 x USB 3.0 Host
+ - eMMC
+ - SDcard
+ - Infrared receiver
+ - SDIO WiFi Module
+ - MIPI DSI Connector
+ - Audio HAT Connector
+ - PCI-E M.2 Connector
+
+Schematics are available from Amlogic on demand.
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make w400_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/BayLibre/u-boot.git -b buildroot-openlinux-20180418 amlogic-u-boot
+ $ cd amlogic-u-boot
+ $ make g12b_w400_v1_defconfig
+ $ make
+ $ export UBOOTDIR=$PWD
+
+Download the latest Amlogic Buildroot package, and extract it :
+
+.. code-block:: bash
+
+ $ wget http://openlinux2.amlogic.com:8000/ARM/filesystem/Linux_BSP/buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz
+ $ tar xfz buildroot_openlinux_kernel_4.9_fbdev_20180706.tar.gz buildroot_openlinux_kernel_4.9_fbdev_20180706/bootloader
+ $ export BRDIR=$PWD/buildroot_openlinux_kernel_4.9_fbdev_20180706
+ $ export FIPDIR=$BRDIR/bootloader/uboot-repo/fip
+
+Go back to mainline U-Boot source tree then :
+
+.. code-block:: bash
+
+ $ mkdir fip
+
+ $ wget https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh -O fip/blx_fix.sh
+ $ cp $UBOOTDIR/build/scp_task/bl301.bin fip/
+ $ cp $UBOOTDIR/build/board/amlogic/g12b_w400_v1/firmware/acs.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl2/bin/g12b/bl2.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl30/bin/g12b/bl30.bin fip/
+ $ cp $BRDIR/bootloader/uboot-repo/bl31_1.3/bin/g12b/bl31.img fip/
+ $ cp $FIPDIR/g12b/ddr3_1d.fw fip/
+ $ cp $FIPDIR/g12b/ddr4_1d.fw fip/
+ $ cp $FIPDIR/g12b/ddr4_2d.fw fip/
+ $ cp $FIPDIR/g12b/diag_lpddr4.fw fip/
+ $ cp $FIPDIR/g12b/lpddr4_1d.fw fip/
+ $ cp $FIPDIR/g12b/lpddr4_2d.fw fip/
+ $ cp $FIPDIR/g12b/piei.fw fip/
+ $ cp $FIPDIR/g12b/aml_ddr.fw fip/
+ $ cp u-boot.bin fip/bl33.bin
+
+ $ sh fip/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+
+ $ sh fip/blx_fix.sh \
+ fip/bl2.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/acs.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bl30sig --input fip/bl30_new.bin \
+ --output fip/bl30_new.bin.g12a.enc \
+ --level v3
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bl3sig --input fip/bl30_new.bin.g12a.enc \
+ --output fip/bl30_new.bin.enc \
+ --level v3 --type bl30
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bl3sig --input fip/bl31.img \
+ --output fip/bl31.img.enc \
+ --level v3 --type bl31
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bl3sig --input fip/bl33.bin --compress lz4 \
+ --output fip/bl33.bin.enc \
+ --level v3 --type bl33
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bl2sig --input fip/bl2_new.bin \
+ --output fip/bl2.n.bin.sig
+ $ $FIPDIR/g12b/aml_encrypt_g12b --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc \
+ --ddrfw1 fip/ddr4_1d.fw \
+ --ddrfw2 fip/ddr4_2d.fw \
+ --ddrfw3 fip/ddr3_1d.fw \
+ --ddrfw4 fip/piei.fw \
+ --ddrfw5 fip/lpddr4_1d.fw \
+ --ddrfw6 fip/lpddr4_2d.fw \
+ --ddrfw7 fip/diag_lpddr4.fw \
+ --ddrfw8 fip/aml_ddr.fw \
+ --level v3
+
+and then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/amlogic/wetek-core2.rst b/roms/u-boot/doc/board/amlogic/wetek-core2.rst
new file mode 100644
index 000000000..1012079de
--- /dev/null
+++ b/roms/u-boot/doc/board/amlogic/wetek-core2.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for WeTek Core2
+======================
+
+WeTek Core2 is an Android STB based on the Q200 reference design with
+the following specifications:
+
+ - Amlogic S912 ARM Cortex-A53 octo-core SoC @ 1.5GHz
+ - ARM Mali T820 GPU
+ - 3GB DDR4 SDRAM
+ - 10/100 Realtek RTL8152 Ethernet (internal USB)
+ - HDMI 2.0 4K/60Hz display
+ - 2x USB 2.0 Host, 1x USB 2.0 OTG (internal)
+ - 32GB eMMC
+ - microSD
+ - SDIO Wifi Module, Bluetooth
+ - Two channel IR receiver
+
+U-Boot compilation
+------------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-none-elf-
+ $ make wetek-core2_defconfig
+ $ make
+
+Image creation
+--------------
+
+Amlogic does not provide sources for the firmware or the tools needed
+to create the bootloader image, and WeTek has not publicly shared the
+precompiled FIP binaries. However the public Khadas VIM2 sources also
+work with the Core2 box so we can use the Khadas git tree:
+
+.. code-block:: bash
+
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ $ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ $ export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ $ git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 vim-u-boot
+ $ cd vim-u-boot
+ $ make kvim2_defconfig
+ $ make
+ $ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then:
+
+.. code-block:: bash
+
+ $ mkdir fip
+ $ cp $FIPDIR/gxl/bl2.bin fip/
+ $ cp $FIPDIR/gxl/acs.bin fip/
+ $ cp $FIPDIR/gxl/bl21.bin fip/
+ $ cp $FIPDIR/gxl/bl30.bin fip/
+ $ cp $FIPDIR/gxl/bl301.bin fip/
+ $ cp $FIPDIR/gxl/bl31.img fip/
+ $ cp u-boot.bin fip/bl33.bin
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl30.bin \
+ fip/zero_tmp \
+ fip/bl30_zero.bin \
+ fip/bl301.bin \
+ fip/bl301_zero.bin \
+ fip/bl30_new.bin \
+ bl30
+ $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+ $ $FIPDIR/blx_fix.sh \
+ fip/bl2_acs.bin \
+ fip/zero_tmp \
+ fip/bl2_zero.bin \
+ fip/bl21.bin \
+ fip/bl21_zero.bin \
+ fip/bl2_new.bin \
+ bl2
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig
+ $ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+ --output fip/u-boot.bin \
+ --bl2 fip/bl2.n.bin.sig \
+ --bl30 fip/bl30_new.bin.enc \
+ --bl31 fip/bl31.img.enc \
+ --bl33 fip/bl33.bin.enc
+
+then write the image to SD with:
+
+.. code-block:: bash
+
+ $ DEV=/dev/your_sd_device
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1
+ $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444
diff --git a/roms/u-boot/doc/board/atmel/at91ek.rst b/roms/u-boot/doc/board/atmel/at91ek.rst
new file mode 100644
index 000000000..6185b1dfb
--- /dev/null
+++ b/roms/u-boot/doc/board/atmel/at91ek.rst
@@ -0,0 +1,192 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+AT91 Evaluation kits
+====================
+
+Board mapping & boot media
+--------------------------
+
+AT91SAM9260EK, AT91SAM9G20EK & AT91SAM9XEEK
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - Cxxxxxxx Atmel Dataflash card (J13)
+ 0xD0000000 - D07FFFFF Soldered Atmel Dataflash (AT45DB642)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Dataflash on SPI chip select 1 (default)
+ - Dataflash on SPI chip select 0 (dataflash card)
+ - Nand flash
+
+You can choose your storage location at config step (here for at91sam9260ek)::
+
+ make at91sam9260ek_nandflash_config - use nand flash
+ make at91sam9260ek_dataflash_cs0_config - use data flash (spi cs0)
+ make at91sam9260ek_dataflash_cs1_config - use data flash (spi cs1)
+
+
+AT91SAM9261EK, AT91SAM9G10EK
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - C07FFFFF Soldered Atmel Dataflash (AT45DB642)
+ 0xD0000000 - Dxxxxxxx Atmel Dataflash card (J22)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Dataflash on SPI chip select 0 (default)
+ - Dataflash on SPI chip select 3 (dataflash card)
+ - Nand flash
+
+You can choose your storage location at config step (here for at91sam9260ek)::
+
+ make at91sam9261ek_nandflash_config - use nand flash
+ make at91sam9261ek_dataflash_cs0_config - use data flash (spi cs0)
+ make at91sam9261ek_dataflash_cs3_config - use data flash (spi cs3)
+
+
+AT91SAM9263EK
+^^^^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - Cxxxxxxx Atmel Dataflash card (J9)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Dataflash on SPI chip select 0 (dataflash card)
+ - Nand flash
+ - Nor flash (not populate by default)
+
+You can choose your storage location at config step (here for at91sam9260ek)::
+
+ make at91sam9263ek_nandflash_config - use nand flash
+ make at91sam9263ek_dataflash_cs0_config - use data flash (spi cs0)
+ make at91sam9263ek_norflash_config - use nor flash
+
+You can choose to boot directly from U-Boot at config step::
+
+ make at91sam9263ek_norflash_boot_config - boot from nor flash
+
+
+AT91SAM9M10G45EK
+^^^^^^^^^^^^^^^^
+
+Memory map::
+
+ 0x70000000 - 77FFFFFF SDRAM (128 MB)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Nand flash
+
+You can choose your storage location at config step (here for at91sam9m10g45ek)::
+
+ make at91sam9m10g45ek_nandflash_config - use nand flash
+
+
+AT91SAM9RLEK
+^^^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 23FFFFFF SDRAM (64 MB)
+ 0xC0000000 - C07FFFFF Soldered Atmel Dataflash (AT45DB642)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Dataflash on SPI chip select 0
+ - Nand flash.
+
+You can choose your storage location at config step (here for at91sam9rlek)::
+
+ make at91sam9rlek_nandflash_config - use nand flash
+
+
+AT91SAM9N12EK, AT91SAM9X5EK
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 27FFFFFF SDRAM (128 MB)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Nand flash
+ - SD/MMC card
+ - Serialflash/Dataflash on SPI chip select 0
+
+You can choose your storage location at config step (here for at91sam9x5ek)::
+
+ make at91sam9x5ek_dataflash_config - use data flash
+ make at91sam9x5ek_mmc_config - use sd/mmc card
+ make at91sam9x5ek_nandflash_config - use nand flash
+ make at91sam9x5ek_spiflash_config - use serial flash
+
+
+SAMA5D3XEK
+^^^^^^^^^^
+
+Memory map::
+
+ 0x20000000 - 3FFFFFFF SDRAM (512 MB)
+
+Environment variables
+
+U-Boot environment variables can be stored at different places:
+
+ - Nand flash
+ - SD/MMC card
+ - Serialflash on SPI chip select 0
+
+You can choose your storage location at config step (here for sama5d3xek)::
+
+ make sama5d3xek_mmc_config - use SD/MMC card
+ make sama5d3xek_nandflash_config - use nand flash
+ make sama5d3xek_serialflash_config - use serial flash
+
+
+NAND partition table
+--------------------
+
+All the board support boot from NAND flash will use the following NAND
+partition table::
+
+ 0x00000000 - 0x0003FFFF bootstrap (256 KiB)
+ 0x00040000 - 0x000BFFFF u-boot (512 KiB)
+ 0x000C0000 - 0x000FFFFF env (256 KiB)
+ 0x00100000 - 0x0013FFFF env_redundant (256 KiB)
+ 0x00140000 - 0x0017FFFF spare (256 KiB)
+ 0x00180000 - 0x001FFFFF dtb (512 KiB)
+ 0x00200000 - 0x007FFFFF kernel (6 MiB)
+ 0x00800000 - 0xxxxxxxxx rootfs (All left)
+
+
+Watchdog support
+----------------
+
+For security reasons, the at91 watchdog is running at boot time and,
+if deactivated, cannot be used anymore.
+If you want to use the watchdog, you will need to keep it running in
+your code (make sure not to disable it in AT91Bootstrap for instance).
+
+In the U-Boot configuration, the AT91 watchdog support is enabled using
+the CONFIG_WDT and CONFIG_WDT_AT91 options.
diff --git a/roms/u-boot/doc/board/atmel/index.rst b/roms/u-boot/doc/board/atmel/index.rst
new file mode 100644
index 000000000..8ba00fc22
--- /dev/null
+++ b/roms/u-boot/doc/board/atmel/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Atmel
+=====
+
+.. toctree::
+ :maxdepth: 2
+
+ at91ek
diff --git a/roms/u-boot/doc/board/congatec/cgtqmx8.rst b/roms/u-boot/doc/board/congatec/cgtqmx8.rst
new file mode 100644
index 000000000..bccdef2f1
--- /dev/null
+++ b/roms/u-boot/doc/board/congatec/cgtqmx8.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the Congatec conga-QMX8 board
+========================================
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Get imx-mkimage
+- Build U-Boot
+- Build imx-mkimage
+- Flash the binary into the SD card
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ git clone https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ git checkout origin/imx_4.14.78_1.0.0_ga -b imx_4.14.78_1.0.0_ga
+ $ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.1.bin
+ $ chmod +x imx-sc-firmware-1.1.bin
+ $ ./imx-sc-firmware-1.1.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+ $ chmod +x firmware-imx-8.0.bin
+ $ ./firmware-imx-8.0.bin
+
+Or use this to avoid running random scripts from the internet,
+but note that you must agree to the license the script displays:
+
+.. code-block:: bash
+
+ $ dd if=imx-sc-firmware-1.1.bin of=imx-sc-firmware-1.1.tar.bz2 bs=37185 skip=1
+ $ tar -xf imx-sc-firmware-1.1.tar.bz2
+ $ cp imx-sc-firmware-1.1/mx8qx-val-scfw-tcm.bin $(builddir)
+
+ $ dd if=firmware-imx-8.0.bin of=firmware-imx-8.0.tar.bz2 bs=37180 skip=1
+ $ tar -xf firmware-imx-8.0.tar.bz2
+ $ cp firmware-imx-8.0/firmware/seco/mx8qm-ahab-container.img $(builddir)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export ATF_LOAD_ADDR=0x80000000
+ $ export BL33_LOAD_ADDR=0x80020000
+ $ make cgtqmx8_defconfig
+ $ make u-boot.bin
+ $ make flash.bin
+
+Flash the binary into the SD card
+---------------------------------
+
+Burn the flash.bin binary to SD card offset 32KB:
+
+.. code-block:: bash
+
+ $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
diff --git a/roms/u-boot/doc/board/congatec/index.rst b/roms/u-boot/doc/board/congatec/index.rst
new file mode 100644
index 000000000..cc57b36b2
--- /dev/null
+++ b/roms/u-boot/doc/board/congatec/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Congatec
+========
+
+.. toctree::
+ :maxdepth: 2
+
+ cgtqmx8.rst
diff --git a/roms/u-boot/doc/board/coreboot/coreboot.rst b/roms/u-boot/doc/board/coreboot/coreboot.rst
new file mode 100644
index 000000000..9c44c025a
--- /dev/null
+++ b/roms/u-boot/doc/board/coreboot/coreboot.rst
@@ -0,0 +1,52 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Coreboot
+========
+
+Build Instructions for U-Boot as coreboot payload
+-------------------------------------------------
+Building U-Boot as a coreboot payload is just like building U-Boot for targets
+on other architectures, like below::
+
+ $ make coreboot_defconfig
+ $ make all
+
+Test with coreboot
+------------------
+For testing U-Boot as the coreboot payload, there are things that need be paid
+attention to. coreboot supports loading an ELF executable and a 32-bit plain
+binary, as well as other supported payloads. With the default configuration,
+U-Boot is set up to use a separate Device Tree Blob (dtb). As of today, the
+generated u-boot-dtb.bin needs to be packaged by the cbfstool utility (a tool
+provided by coreboot) manually as coreboot's 'make menuconfig' does not provide
+this capability yet. The command is as follows::
+
+ # in the coreboot root directory
+ $ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \
+ -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110000
+
+Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE, which is the symbol address
+of _x86boot_start (in arch/x86/cpu/start.S).
+
+If you want to use ELF as the coreboot payload, change U-Boot configuration to
+use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE.
+
+To enable video you must enable these options in coreboot:
+
+ - Set framebuffer graphics resolution (1280x1024 32k-color (1:5:5))
+ - Keep VESA framebuffer
+
+At present it seems that for Minnowboard Max, coreboot does not pass through
+the video information correctly (it always says the resolution is 0x0). This
+works correctly for link though.
+
+64-bit U-Boot
+-------------
+
+In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. This
+produces an image which can be booted from coreboot (32-bit). Internally it
+works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It
+can be useful for running UEFI applications, for example.
+
+This has only been lightly tested.
diff --git a/roms/u-boot/doc/board/coreboot/index.rst b/roms/u-boot/doc/board/coreboot/index.rst
new file mode 100644
index 000000000..d148db95f
--- /dev/null
+++ b/roms/u-boot/doc/board/coreboot/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Coreboot
+========
+
+.. toctree::
+ :maxdepth: 2
+
+ coreboot
diff --git a/roms/u-boot/doc/board/emulation/index.rst b/roms/u-boot/doc/board/emulation/index.rst
new file mode 100644
index 000000000..be66b6bb6
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Emulation
+=========
+
+.. toctree::
+ :maxdepth: 2
+
+ qemu-arm
+ qemu-mips
+ qemu-ppce500
+ qemu-riscv
+ qemu-x86
+ qemu_capsule_update
diff --git a/roms/u-boot/doc/board/emulation/qemu-arm.rst b/roms/u-boot/doc/board/emulation/qemu-arm.rst
new file mode 100644
index 000000000..8d7fda10f
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu-arm.rst
@@ -0,0 +1,92 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2017, Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
+
+QEMU ARM
+========
+
+QEMU for ARM supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+Both 32-bit ARM and AArch64 are supported.
+
+The 'virt' platform provides the following as the basic functionality:
+
+ - A freely configurable amount of CPU cores
+ - U-Boot loaded and executing in the emulated flash at address 0x0
+ - A generated device tree blob placed at the start of RAM
+ - A freely configurable amount of RAM, described by the DTB
+ - A PL011 serial port, discoverable via the DTB
+ - An ARMv7/ARMv8 architected timer
+ - PSCI for rebooting the system
+ - A generic ECAM-based PCI host controller, discoverable via the DTB
+
+Additionally, a number of optional peripherals can be added to the PCI bus.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable as usual, and run:
+
+- For ARM::
+
+ make qemu_arm_defconfig
+ make
+
+- For AArch64::
+
+ make qemu_arm64_defconfig
+ make
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is:
+
+- For ARM::
+
+ qemu-system-arm -machine virt -bios u-boot.bin
+
+- For AArch64::
+
+ qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
+
+Note that for some odd reason qemu-system-aarch64 needs to be explicitly
+told to use a 64-bit CPU or it will boot in 32-bit mode.
+
+Additional persistent U-boot environment support can be added as follows:
+
+- Create envstore.img using qemu-img::
+
+ qemu-img create -f raw envstore.img 64M
+
+- Add a pflash drive parameter to the command line::
+
+ -drive if=pflash,format=raw,index=1,file=envstore.img
+
+Additional peripherals that have been tested to work in both U-Boot and Linux
+can be enabled with the following command line parameters:
+
+- To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.::
+
+ -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0
+
+- To add an Intel E1000 network adapter, pass e.g.::
+
+ -netdev user,id=net0 -device e1000,netdev=net0
+
+- To add an EHCI-compliant USB host controller, pass e.g.::
+
+ -device usb-ehci,id=ehci
+
+- To add a NVMe disk, pass e.g.::
+
+ -drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
+
+These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.
+
+Debug UART
+----------
+
+The debug UART on the ARM virt board uses these settings::
+
+ CONFIG_DEBUG_UART=y
+ CONFIG_DEBUG_UART_PL010=y
+ CONFIG_DEBUG_UART_BASE=0x9000000
+ CONFIG_DEBUG_UART_CLOCK=0
diff --git a/roms/u-boot/doc/board/emulation/qemu-mips.rst b/roms/u-boot/doc/board/emulation/qemu-mips.rst
new file mode 100644
index 000000000..5fd8a0a23
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu-mips.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
+
+QEMU MIPS
+=========
+
+Qemu for MIPS is based on the MIPS Malta board. The built Malta U-Boot
+images can be used for Qemu and on physical hardware. The Malta board
+supports all combinations of Little and Big Endian as well as 32 bit
+and 64 bit.
+
+Limitations & comments
+----------------------
+The memory size for Qemu is hard-coded to 256 MiB. For Malta Little Endian
+targets an extra endianness swapped image named *u-boot-swap.bin* is
+generated and required for Qemu.
+
+Example usage
+-------------
+
+Build for 32 bit, big endian:
+
+.. code-block:: bash
+
+ make malta_defconfig
+ make
+ UBOOT_BIN=u-boot.bin
+ QEMU_BIN=qemu-system-mips
+ QEMU_CPU=24Kc
+
+Build for 32 bit, little endian:
+
+.. code-block:: bash
+
+ make maltael_defconfig
+ make
+ UBOOT_BIN=u-boot-swap.bin
+ QEMU_BIN=qemu-system-mipsel
+ QEMU_CPU=24Kc
+
+Build for 64 bit, big endian:
+
+.. code-block:: bash
+
+ make malta64_defconfig
+ make
+ UBOOT_BIN=u-boot.bin
+ QEMU_BIN=qemu-system-mips64
+ QEMU_CPU=MIPS64R2-generic
+
+Build for 64 bit, little endian:
+
+.. code-block:: bash
+
+ make malta64el_defconfig
+ make
+ UBOOT_BIN=u-boot-swap.bin
+ QEMU_BIN=qemu-system-mips64el
+ QEMU_CPU=MIPS64R2-generic
+
+Generate NOR flash image with U-Boot binary:
+
+.. code-block:: bash
+
+ dd if=/dev/zero bs=1M count=4 | tr '\000' '\377' > pflash.img
+ dd if=${UBOOT_BIN} of=pflash.img conv=notrunc
+
+Start Qemu:
+
+.. code-block:: bash
+
+ mkdir tftproot
+ ${QEMU_BIN} -nographic -cpu ${QEMU_CPU} -m 256 -drive if=pflash,file="$(pwd)/pflash.img",format=raw -netdev user,id=net0,tftp="$(pwd)/tftproot" -device pcnet,netdev=net0
+
+.. code-block:: bash
+
+ U-Boot 2021.04-00963-g60279a2b1d (Apr 21 2021 - 19:54:32 +0200)
+
+ Board: MIPS Malta CoreLV
+ DRAM: 256 MiB
+ Flash: 4 MiB
+ Loading Environment from Flash... *** Warning - bad CRC, using default environment
+
+ In: serial@3f8
+ Out: serial@3f8
+ Err: serial@3f8
+ Net: pcnet#0
+ IDE: Bus 0: not available
+ maltael #
+
+How to debug U-Boot
+-------------------
+
+In order to debug U-Boot you need to start qemu with gdb server support (-s)
+and waiting the connection to start the CPU (-S). Start Qemu in the first console:
+
+.. code-block:: bash
+
+ mkdir tftproot
+ ${QEMU_BIN} -s -S -nographic -cpu ${QEMU_CPU} -m 256 -drive if=pflash,file="$(pwd)/pflash.img",format=raw -netdev user,id=net0,tftp="$(pwd)/tftproot" -device pcnet,netdev=net0
+
+In the second console start gdb:
+
+.. code-block:: bash
+
+ gdb-multiarch --eval-command "target remote :1234" u-boot
+
+.. code-block:: bash
+
+ GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
+ Copyright (C) 2020 Free Software Foundation, Inc.
+ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+ This is free software: you are free to change and redistribute it.
+ There is NO WARRANTY, to the extent permitted by law.
+ Type "show copying" and "show warranty" for details.
+ This GDB was configured as "x86_64-linux-gnu".
+ Type "show configuration" for configuration details.
+ For bug reporting instructions, please see:
+ <http://www.gnu.org/software/gdb/bugs/>.
+ Find the GDB manual and other documentation resources online at:
+ <http://www.gnu.org/software/gdb/documentation/>.
+
+ For help, type "help".
+ Type "apropos word" to search for commands related to "word"...
+ Reading symbols from u-boot...
+ Remote debugging using :1234
+ 0xbfc00000 in ?? ()
+ (gdb) c
+ Continuing.
diff --git a/roms/u-boot/doc/board/emulation/qemu-ppce500.rst b/roms/u-boot/doc/board/emulation/qemu-ppce500.rst
new file mode 100644
index 000000000..5de0aaf55
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu-ppce500.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+
+QEMU PPC E500
+=============
+
+QEMU for PPC supports a special 'ppce500' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+
+The QEMU ppce500 machine models a generic PowerPC E500 virtual machine with
+support for the VirtIO standard networking device connected to the built-in
+PCI host controller. Some common devices in the CCSBAR space are modeled,
+including MPIC, 16550A UART devices, GPIO, I2C and PCI host controller with
+MSI delivery to MPIC. It uses device-tree to pass configuration information
+to guest software.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable as usual, and run::
+
+ $ make qemu-ppce500_defconfig
+ $ make
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is::
+
+ $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot
+
+You can also run U-Boot using 'qemu-system-ppc64'::
+
+ $ qemu-system-ppc64 -nographic -machine ppce500 -bios u-boot
+
+The commands above create a target with 128 MiB memory by default. A freely
+configurable amount of RAM can be created via the '-m' parameter. For example,
+'-m 2G' creates 2 GiB memory for the target, and the memory node in the
+embedded DTB created by QEMU reflects the new setting.
+
+Both qemu-system-ppc and qemu-system-ppc64 provide emulation for the following
+32-bit PowerPC CPUs:
+
+* e500v2
+* e500mc
+
+Additionally qemu-system-ppc64 provides support for the following 64-bit CPUs:
+
+* e5500
+* e6500
+
+The CPU type can be specified via the '-cpu' command line. If not specified,
+it creates a machine with e500v2 core. The following example shows an e6500
+based machine creation::
+
+ $ qemu-system-ppc64 -nographic -machine ppce500 -cpu e6500 -bios u-boot
+
+When U-Boot boots, you will notice the following::
+
+ CPU: Unknown, Version: 0.0, (0x00000000)
+ Core: e6500, Version: 2.0, (0x80400020)
+
+This is because we only specified a core name to QEMU and it does not have a
+meaningful SVR value which represents an actual SoC that integrates such core.
+You can specify a real world SoC device that QEMU has built-in support but all
+these SoCs are e500v2 based MPC85xx series, hence you cannot test anything
+built for P4080 (e500mc), P5020 (e5500) and T2080 (e6500).
+
+By default a VirtIO standard PCI networking device is connected as an ethernet
+interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by::
+
+ $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot \
+ -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
+
+The QEMU ppce500 machine can also dynamically instantiate an eTSEC device if
+"-device eTSEC" is given to QEMU::
+
+ -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device eTSEC,netdev=net0
+
+VirtIO BLK driver is also enabled to support booting from a disk image where
+a kernel image is stored. Append the following to QEMU::
+
+ -drive file=disk.img,format=raw,id=disk0 -device virtio-blk-pci,drive=disk0
+
+Pericom pt7c4338 RTC is supported so we can use the 'date' command::
+
+ => date
+ Date: 2021-02-18 (Thursday) Time: 15:33:20
+
+Additionally, 'poweroff' command is supported to shut down the QEMU session::
+
+ => poweroff
+ poweroff ...
+
+These have been tested in QEMU 5.2.0.
diff --git a/roms/u-boot/doc/board/emulation/qemu-riscv.rst b/roms/u-boot/doc/board/emulation/qemu-riscv.rst
new file mode 100644
index 000000000..4b8e104a2
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu-riscv.rst
@@ -0,0 +1,115 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+QEMU RISC-V
+===========
+
+QEMU for RISC-V supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+Both 32-bit and 64-bit targets are supported, running in either machine or
+supervisor mode.
+
+The QEMU virt machine models a generic RISC-V virtual machine with support for
+the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
+16550A UART devices in addition to VirtIO and it also uses device-tree to pass
+configuration information to guest software. It implements RISC-V privileged
+architecture spec v1.10.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable as usual, and run:
+
+- For 32-bit RISC-V::
+
+ make qemu-riscv32_defconfig
+ make
+
+- For 64-bit RISC-V::
+
+ make qemu-riscv64_defconfig
+ make
+
+This will compile U-Boot for machine mode. To build supervisor mode binaries,
+use the configurations qemu-riscv32_smode_defconfig and
+qemu-riscv64_smode_defconfig instead. Note that U-Boot running in supervisor
+mode requires a supervisor binary interface (SBI), such as RISC-V OpenSBI.
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is:
+
+- For 32-bit RISC-V::
+
+ qemu-system-riscv32 -nographic -machine virt -bios u-boot
+
+- For 64-bit RISC-V::
+
+ qemu-system-riscv64 -nographic -machine virt -bios u-boot
+
+The commands above create targets with 128MiB memory by default.
+A freely configurable amount of RAM can be created via the '-m'
+parameter. For example, '-m 2G' creates 2GiB memory for the target,
+and the memory node in the embedded DTB created by QEMU reflects
+the new setting.
+
+For instructions on how to run U-Boot in supervisor mode on QEMU
+with OpenSBI, see the documentation available with OpenSBI:
+https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md
+
+These have been tested in QEMU 5.0.0.
+
+Running U-Boot SPL
+------------------
+In the default SPL configuration, U-Boot SPL starts in machine mode. U-Boot
+proper and OpenSBI (FW_DYNAMIC firmware) are bundled as FIT image and made
+available to U-Boot SPL. Both are then loaded by U-Boot SPL and the location
+of U-Boot proper is passed to OpenSBI. After initialization, U-Boot proper is
+started in supervisor mode by OpenSBI.
+
+OpenSBI must be compiled before compiling U-Boot. Version 0.4 and higher is
+supported by U-Boot. Clone the OpenSBI repository and run the following command.
+
+.. code-block:: console
+
+ git clone https://github.com/riscv/opensbi.git
+ cd opensbi
+ make PLATFORM=generic
+
+See the OpenSBI documentation for full details:
+https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md
+
+To make the FW_DYNAMIC binary (build/platform/qemu/virt/firmware/fw_dynamic.bin)
+available to U-Boot, either copy it into the U-Boot root directory or specify
+its location with the OPENSBI environment variable. Afterwards, compile U-Boot
+with the following commands.
+
+- For 32-bit RISC-V::
+
+ make qemu-riscv32_spl_defconfig
+ make
+
+- For 64-bit RISC-V::
+
+ make qemu-riscv64_spl_defconfig
+ make
+
+The minimal QEMU commands to run U-Boot SPL in both 32-bit and 64-bit
+configurations are:
+
+- For 32-bit RISC-V::
+
+ qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \
+ -device loader,file=u-boot.itb,addr=0x80200000
+
+- For 64-bit RISC-V::
+
+ qemu-system-riscv64 -nographic -machine virt -bios spl/u-boot-spl \
+ -device loader,file=u-boot.itb,addr=0x80200000
+
+An attached disk can be emulated by adding::
+
+ -device ich9-ahci,id=ahci \
+ -drive if=none,file=riscv64.img,format=raw,id=mydisk \
+ -device ide-hd,drive=mydisk,bus=ahci.0
+
+You will have to run 'scsi scan' to use it.
diff --git a/roms/u-boot/doc/board/emulation/qemu-x86.rst b/roms/u-boot/doc/board/emulation/qemu-x86.rst
new file mode 100644
index 000000000..db842f2ec
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu-x86.rst
@@ -0,0 +1,118 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+QEMU x86
+========
+
+Build instructions for bare mode
+--------------------------------
+
+To build u-boot.rom for QEMU x86 targets, just simply run::
+
+ $ make qemu-x86_defconfig (for 32-bit)
+ $ make qemu-x86_64_defconfig (for 64-bit)
+ $ make all
+
+Note this default configuration will build a U-Boot for the QEMU x86 i440FX
+board. To build a U-Boot against QEMU x86 Q35 board, you can change the build
+configuration during the 'make menuconfig' process like below::
+
+ Device Tree Control --->
+ ...
+ (qemu-x86_q35) Default Device Tree for DT control
+
+Test with QEMU for bare mode
+----------------------------
+
+QEMU is a fancy emulator that can enable us to test U-Boot without access to
+a real x86 board. Please make sure your QEMU version is 2.3.0 or above test
+U-Boot. To launch QEMU with u-boot.rom, call QEMU as follows::
+
+ $ qemu-system-i386 -nographic -bios path/to/u-boot.rom
+
+This will instantiate an emulated x86 board with i440FX and PIIX chipset. QEMU
+also supports emulating an x86 board with Q35 and ICH9 based chipset, which is
+also supported by U-Boot. To instantiate such a machine, call QEMU with::
+
+ $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -M q35
+
+Note by default QEMU instantiated boards only have 128 MiB system memory. But
+it is enough to have U-Boot boot and function correctly. You can increase the
+system memory by pass '-m' parameter to QEMU if you want more memory::
+
+ $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024
+
+This creates a board with 1 GiB system memory. Currently U-Boot for QEMU only
+supports 3 GiB maximum system memory and reserves the last 1 GiB address space
+for PCI device memory-mapped I/O and other stuff, so the maximum value of '-m'
+would be 3072.
+
+QEMU emulates a graphic card which U-Boot supports. Removing '-nographic' will
+show QEMU's VGA console window. Note this will disable QEMU's serial output.
+If you want to check both consoles, use '-serial stdio'.
+
+Multicore is also supported by QEMU via '-smp n' where n is the number of cores
+to instantiate. Note, the maximum supported CPU number in QEMU is 255.
+
+U-Boot uses 'distro_bootcmd' by default when booting on x86 QEMU. This tries to
+load a boot script, kernel, and ramdisk from several different interfaces. For
+the default boot order, see 'qemu-x86.h'. For more information, see
+'README.distro'. Most Linux distros can be booted by writing a uboot script.
+For example, Debian (stretch) can be booted by creating a script file named
+'boot.txt' with the contents::
+
+ setenv bootargs root=/dev/sda1 ro
+ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /vmlinuz
+ load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /initrd.img
+ zboot ${kernel_addr_r} - ${ramdisk_addr_r} ${filesize}
+
+Then compile and install it with::
+
+ $ apt install u-boot-tools && \
+ mkimage -T script -C none -n "Boot script" -d boot.txt /boot/boot.scr
+
+The fw_cfg interface in QEMU also provides information about kernel data,
+initrd, command-line arguments and more. U-Boot supports directly accessing
+these informtion from fw_cfg interface, which saves the time of loading them
+from hard disk or network again, through emulated devices. To use it , simply
+providing them in QEMU command line::
+
+ $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 \
+ -kernel /path/to/bzImage -append 'root=/dev/ram console=ttyS0' \
+ -initrd /path/to/initrd -smp 8
+
+Note: -initrd and -smp are both optional
+
+Then start QEMU, in U-Boot command line use the following U-Boot command to
+setup kernel::
+
+ => qfw
+ qfw - QEMU firmware interface
+
+ Usage:
+ qfw <command>
+ - list : print firmware(s) currently loaded
+ - cpus : print online cpu number
+ - load <kernel addr> <initrd addr> : load kernel and initrd (if any) and setup for zboot
+
+ => qfw load
+ loading kernel to address 01000000 size 5d9d30 initrd 04000000 size 1b1ab50
+
+Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then,
+'zboot' can be used to boot the kernel::
+
+ => zboot 01000000 - 04000000 1b1ab50
+
+To run 64-bit U-Boot, qemu-system-x86_64 should be used instead, e.g.::
+
+ $ qemu-system-x86_64 -nographic -bios path/to/u-boot.rom
+
+A specific CPU can be specified via the '-cpu' parameter but please make
+sure the specified CPU supports 64-bit like '-cpu core2duo'. Conversely
+'-cpu pentium' won't work for obvious reasons that the processor only
+supports 32-bit.
+
+Note 64-bit support is very preliminary at this point. Lots of features
+are missing in the 64-bit world. One notable feature is the VGA console
+support which is currently missing, so that you must specify '-nographic'
+to get 64-bit U-Boot up and running.
diff --git a/roms/u-boot/doc/board/emulation/qemu_capsule_update.rst b/roms/u-boot/doc/board/emulation/qemu_capsule_update.rst
new file mode 100644
index 000000000..33ce4bcd3
--- /dev/null
+++ b/roms/u-boot/doc/board/emulation/qemu_capsule_update.rst
@@ -0,0 +1,210 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020, Linaro Limited
+
+Enabling UEFI Capsule Update feature
+------------------------------------
+
+Support has been added for the UEFI capsule update feature which
+enables updating the U-Boot image using the UEFI firmware management
+protocol (fmp). The capsules are not passed to the firmware through
+the UpdateCapsule runtime service. Instead, capsule-on-disk
+functionality is used for fetching the capsule from the EFI System
+Partition (ESP) by placing the capsule file under the
+\EFI\UpdateCapsule directory.
+
+Currently, support has been added on the QEMU ARM64 virt platform for
+updating the U-Boot binary as a raw image when the platform is booted
+in non-secure mode, i.e. with CONFIG_TFABOOT disabled. For this
+configuration, the QEMU platform needs to be booted with
+'secure=off'. The U-Boot binary placed on the first bank of the NOR
+flash at offset 0x0. The U-Boot environment is placed on the second
+NOR flash bank at offset 0x4000000.
+
+The capsule update feature is enabled with the following configuration
+settings::
+
+ CONFIG_MTD=y
+ CONFIG_FLASH_CFI_MTD=y
+ CONFIG_CMD_MTDPARTS=y
+ CONFIG_CMD_DFU=y
+ CONFIG_DFU_MTD=y
+ CONFIG_PCI_INIT_R=y
+ CONFIG_EFI_CAPSULE_ON_DISK=y
+ CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
+ CONFIG_EFI_CAPSULE_FIRMWARE=y
+ CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+ CONFIG_EFI_CAPSULE_FMP_HEADER=y
+
+In addition, the following config needs to be disabled(QEMU ARM specific)::
+
+ CONFIG_TFABOOT
+
+The capsule file can be generated by using the GenerateCapsule.py
+script in EDKII::
+
+ $ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
+ <capsule_file_name> --fw-version <val> --lsv <val> --guid \
+ e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index \
+ <val> --verbose <u-boot.bin>
+
+The above is a wrapper script(GenerateCapsule) which eventually calls
+the actual GenerateCapsule.py script.
+
+As per the UEFI specification, the capsule file needs to be placed on
+the EFI System Partition, under the \EFI\UpdateCapsule directory. The
+EFI System Partition can be a virtio-blk-device.
+
+Before initiating the firmware update, the efi variables BootNext,
+BootXXXX and OsIndications need to be set. The BootXXXX variable needs
+to be pointing to the EFI System Partition which contains the capsule
+file. The BootNext, BootXXXX and OsIndications variables can be set
+using the following commands::
+
+ => efidebug boot add -b 0 Boot0000 virtio 0:1 <capsule_file_name>
+ => efidebug boot next 0
+ => setenv -e -nv -bs -rt -v OsIndications =0x04
+ => saveenv
+
+Finally, the capsule update can be initiated with the following
+command::
+
+ => efidebug capsule disk-update
+
+The updated U-Boot image will be booted on subsequent boot.
+
+Enabling Capsule Authentication
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The UEFI specification defines a way of authenticating the capsule to
+be updated by verifying the capsule signature. The capsule signature
+is computed and prepended to the capsule payload at the time of
+capsule generation. This signature is then verified by using the
+public key stored as part of the X509 certificate. This certificate is
+in the form of an efi signature list (esl) file, which is embedded as
+part of the platform's device tree blob using the mkeficapsule
+utility.
+
+On the QEMU virt platforms, the device-tree is generated on the fly
+based on the devices configured. This device tree is then passed on to
+the various software components booting on the platform, including
+U-Boot. Therefore, on the QEMU virt platform, the signatute is
+embedded on an overlay. This overlay is then applied at runtime to the
+base platform device-tree. Steps needed for embedding the esl file in
+the overlay are highlighted below.
+
+The capsule authentication feature can be enabled through the
+following config, in addition to the configs listed above for capsule
+update::
+
+ CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+
+The public and private keys used for the signing process are generated
+and used by the steps highlighted below::
+
+ 1. Install utility commands on your host
+ * OPENSSL
+ * efitools
+
+ 2. Create signing keys and certificate files on your host
+
+ $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \
+ -keyout CRT.key -out CRT.crt -nodes -days 365
+ $ cert-to-efi-sig-list CRT.crt CRT.esl
+
+ $ openssl x509 -in CRT.crt -out CRT.cer -outform DER
+ $ openssl x509 -inform DER -in CRT.cer -outform PEM -out CRT.pub.pem
+
+ $ openssl pkcs12 -export -out CRT.pfx -inkey CRT.key -in CRT.crt
+ $ openssl pkcs12 -in CRT.pfx -nodes -out CRT.pem
+
+The capsule file can be generated by using the GenerateCapsule.py
+script in EDKII::
+
+ $ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
+ <capsule_file_name> --monotonic-count <val> --fw-version \
+ <val> --lsv <val> --guid \
+ e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose \
+ --update-image-index <val> --signer-private-cert \
+ /path/to/CRT.pem --trusted-public-cert \
+ /path/to/CRT.pub.pem --other-public-cert /path/to/CRT.pub.pem \
+ <u-boot.bin>
+
+Place the capsule generated in the above step on the EFI System
+Partition under the EFI/UpdateCapsule directory
+
+For embedding the public key certificate, the following steps need to
+be followed::
+
+ 1. Generate a skeleton overlay dts file, with a single fragment
+ node and an empty __overlay__ node
+
+ A typical skeleton overlay file will look like this
+
+ /dts-v1/;
+ /plugin/;
+
+ / {
+ fragment@0 {
+ target-path = "/";
+ __overlay__ {
+ };
+ };
+ };
+
+
+ 2. Convert the dts to a corresponding dtb with the following
+ command
+ ./scripts/dtc/dtc -@ -I dts -O dtb -o <ov_dtb_file_name> \
+ <dts_file>
+
+ 3. Run the dtb file generated above through the mkeficapsule tool
+ in U-Boot
+ ./tools/mkeficapsule -O <pub_key.esl> -D <ov_dtb>
+
+Running the above command results in the creation of a 'signature'
+node in the dtb, under which the public key is stored as a
+'capsule-key' property. The '-O' option is to be used since the
+public key certificate(esl) file is being embedded in an overlay.
+
+The dtb file embedded with the certificate is now to be placed on an
+EFI System Partition. This would then be loaded and "merged" with the
+base platform flattened device-tree(dtb) at runtime.
+
+Build U-Boot with the following steps(QEMU ARM64)::
+
+ $ make qemu_arm64_defconfig
+ $ make menuconfig
+ Disable CONFIG_TFABOOT
+ Enable CONFIG_EFI_CAPSULE_AUTHENTICATE
+ Enable all configs needed for capsule update(listed above)
+ $ make all
+
+Boot the platform and perform the following steps on the U-Boot
+command line::
+
+ 1. Enable capsule authentication by setting the following env
+ variable
+
+ => setenv capsule_authentication_enabled 1
+ => saveenv
+
+ 2. Load the overlay dtb to memory and merge it with the base fdt
+
+ => fatload virtio 0:1 <$fdtovaddr> EFI/<ov_dtb_file>
+ => fdt addr $fdtcontroladdr
+ => fdt resize <size_of_ov_dtb_file>
+ => fdt apply <$fdtovaddr>
+
+ 3. Set the following environment and UEFI boot variables
+
+ => setenv -e -nv -bs -rt -v OsIndications =0x04
+ => efidebug boot add -b 0 Boot0000 virtio 0:1 <capsule_file_name>
+ => efidebug boot next 0
+ => saveenv
+
+ 4. Finally, the capsule update can be initiated with the following
+ command
+
+ => efidebug capsule disk-update
+
+On subsequent reboot, the platform should boot the updated U-Boot binary.
diff --git a/roms/u-boot/doc/board/freescale/b4860qds.rst b/roms/u-boot/doc/board/freescale/b4860qds.rst
new file mode 100644
index 000000000..de14d857b
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/b4860qds.rst
@@ -0,0 +1,453 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+B4860QDS
+========
+
+The B4860QDS is a Freescale reference board that hosts the B4860 SoC
+(and variants).
+
+B4860 Overview
+--------------
+The B4860 QorIQ Qonverge device is a Freescale high-end, multicore SoC based on
+StarCore and Power Architecture® cores. It targets the broadband wireless
+infrastructure and builds upon the proven success of the existing multicore
+DSPs and Power CPUs. It is designed to bolster the rapidly changing and
+expanding wireless markets, such as 3GLTE (FDD and TDD), LTE-Advanced, and UMTS.
+
+The B4860 is a highly-integrated StarCore and Power Architecture processor that
+contains:
+
+* Six fully-programmable StarCore SC3900 FVP subsystems, divided into three
+ clusters-each core runs up to 1.2 GHz, with an architecture highly optimized
+ for wireless base station applications
+* Four dual-thread e6500 Power Architecture processors organized in one
+ cluster-each core runs up to 1.8 GHz
+* Two DDR3/3L controllers for high-speed, industry-standard memory interface
+ each runs at up to 1866.67 MHz
+* MAPLE-B3 hardware acceleration-for forward error correction schemes including
+ Turbo or Viterbi decoding, Turbo encoding and rate matching, MIMO MMSE
+ equalization scheme, matrix operations, CRC insertion and check, DFT/iDFT and
+ FFT/iFFT calculations, PUSCH/PDSCH acceleration, and UMTS chip rate
+ acceleration
+* CoreNet fabric that fully supports coherency using MESI protocol between the
+ e6500 cores, SC3900 FVP cores, memories and external interfaces.
+ CoreNet fabric interconnect runs at 667 MHz and supports coherent and
+ non-coherent out of order transactions with prioritization and bandwidth
+ allocation amongst CoreNet endpoints.
+* Data Path Acceleration Architecture, which includes the following:
+
+ * Frame Manager (FMan), which supports in-line packet parsing and general
+ classification to enable policing and QoS-based packet distribution
+ * Queue Manager (QMan) and Buffer Manager (BMan), which allow offloading
+ of queue management, task management, load distribution, flow ordering,
+ buffer management, and allocation tasks from the cores
+ * Security engine (SEC 5.3)-crypto-acceleration for protocols such as
+ IPsec, SSL, and 802.16
+ * RapidIO manager (RMAN) - Support SRIO types 8, 9, 10, and 11 (inbound
+ and outbound). Supports types 5, 6 (outbound only)
+
+* Large internal cache memory with snooping and stashing capabilities for
+ bandwidth saving and high utilization of processor elements. The 9856-Kbyte
+ internal memory space includes the following:
+
+ * 32 Kbyte L1 ICache per e6500/SC3900 core
+ * 32 Kbyte L1 DCache per e6500/SC3900 core
+ * 2048 Kbyte unified L2 cache for each SC3900 FVP cluster
+ * 2048 Kbyte unified L2 cache for the e6500 cluster
+ * Two 512 Kbyte shared L3 CoreNet platform caches (CPC)
+
+* Sixteen 10-GHz SerDes lanes serving:
+
+ * Two Serial RapidIO interfaces
+ * Each supports up to 4 lanes and a total of up to 8 lanes
+
+* Up to 8-lanes Common Public Radio Interface (CPRI) controller for
+ glue-less antenna connection
+* Two 10-Gbit Ethernet controllers (10GEC)
+* Six 1G/2.5-Gbit Ethernet controllers for network communications
+* PCI Express controller
+* Debug (Aurora)
+* Two OCeaN DMAs
+* Various system peripherals
+* 182 32-bit timers
+
+B4860QDS Overview
+-----------------
+- DDRC1: Ten separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s,
+ ECC, 4 GB of memory in two ranks of 2 GB.
+- DDRC2: Five separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s,
+ ECC, 2 GB of memory. Single rank.
+- SerDes 1 multiplexing: Two Vitesse (transmit and receive path) cross-point
+ 16x16 switch VSC3316
+- SerDes 2 multiplexing: Two Vitesse (transmit and receive path) cross-point
+ 8x8 switch VSC3308
+- USB 2.0 ULPI PHY USB3315 by SMSC supports USB port in host mode.
+ B4860 UART port is available over USB-to-UART translator USB2SER or over
+ RS232 flat cable.
+- A Vitesse dual SGMII phy VSC8662 links the B4860 SGMII lines to 2xRJ-45
+ copper connectors for Stand-alone mode and to the 1000Base-X over AMC
+ MicroTCA connector ports 0 and 2 for AMC mode.
+- The B4860 configuration may be loaded from nine bits coded reset configuration
+ reset source. The RCW source is set by appropriate DIP-switches.
+- 16-bit NOR Flash / PROMJet
+- QIXIS 8-bit NOR Flash Emulator
+- 8-bit NAND Flash
+- 24-bit SPI Flash
+- Long address I2C EEPROM
+- Available debug interfaces are:
+
+ - On-board eCWTAP controller with ETH and USB I/F
+ - JTAG/COP 16-pin header for any external TAP controller
+ - External JTAG source over AMC to support B2B configuration
+ - 70-pin Aurora debug connector
+
+- QIXIS (FPGA) logic:
+ - 2 KB internal memory space including
+
+- IDT840NT4 clock synthesizer provides B4860 essential clocks : SYSCLK,
+ DDRCLK1,2 and RTCCLK.
+- Two 8T49N222A SerDes ref clock devices support two SerDes port clock
+ frequency - total four refclk, including CPRI clock scheme.
+
+
+B4420 Personality
+-----------------
+
+B4420 is a reduced personality of B4860 with less core/clusters(both SC3900
+and e6500), less DDR controllers, less serdes lanes, less SGMII interfaces
+and reduced target frequencies.
+
+Key differences between B4860 and B4420
+---------------------------------------
+
+B4420 has:
+
+1. Less e6500 cores: 1 cluster with 2 e6500 cores
+2. Less SC3900 cores/clusters: 1 cluster with 2 SC3900 cores per cluster
+3. Single DDRC
+4. 2X 4 lane serdes
+5. 3 SGMII interfaces
+6. no sRIO
+7. no 10G
+
+B4860QDS Default Settings
+-------------------------
+
+Switch Settings
+^^^^^^^^^^^^^^^
+
+.. code-block:: none
+
+ SW1 OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0]
+ SW2 ON ON ON ON ON ON OFF OFF
+ SW3 OFF OFF OFF ON OFF OFF ON OFF
+ SW5 OFF OFF OFF OFF OFF OFF ON ON
+
+Note:
+
+- PCIe slots modes: All the PCIe devices work as Root Complex.
+- Boot location: NOR flash.
+
+SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple
+66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz
+
+NAND boot::
+
+ SW1 [1.1] = 0
+ SW2 [1.1] = 1
+ SW3 [1:4] = 0001
+
+NOR boot::
+
+ SW1 [1.1] = 1
+ SW2 [1.1] = 0
+ SW3 [1:4] = 1000
+
+B4420QDS Default Settings
+-------------------------
+
+Switch Settings
+^^^^^^^^^^^^^^^
+
+.. code-block:: none
+
+ SW1 OFF[0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0] OFF [0]
+ SW2 ON OFF ON OFF ON ON OFF OFF
+ SW3 OFF OFF OFF ON OFF OFF ON OFF
+ SW5 OFF OFF OFF OFF OFF OFF ON ON
+
+Note:
+
+- PCIe slots modes: All the PCIe devices work as Root Complex.
+- Boot location: NOR flash.
+
+SysClk/Core(e6500)/CCB/DDR/FMan/DDRCLK/StarCore/CPRI-Maple/eTVPE-Maple/ULB-Maple
+66MHz/1.6GHz/667MHz/1.6GHz data rate/667MHz/133MHz/1200MHz/500MHz/800MHz/667MHz
+
+NAND boot::
+
+ SW1 [1.1] = 0
+ SW2 [1.1] = 1
+ SW3 [1:4] = 0001
+
+NOR boot::
+
+ SW1 [1.1] = 1
+ SW2 [1.1] = 0
+ SW3 [1:4] = 1000
+
+Memory map on B4860QDS
+----------------------
+The addresses in brackets are physical addresses.
+
+============= ============= =============== =======
+Start Address End Address Description Size
+============= ============= =============== =======
+0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB
+0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB
+0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB
+0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB
+0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB
+0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB
+0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB
+0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB
+0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB
+0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB
+0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB
+0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB
+0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB
+0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB
+0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB
+0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB
+0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB
+0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB
+0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB
+0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB
+0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB
+0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB
+0x0_8000_0000 0x0_FFFF_FFFF DDRC1 2 GB
+0x0_0000_0000 0x0_7FFF_FFFF DDRC2 2 GB
+============= ============= =============== =======
+
+Memory map on B4420QDS
+----------------------
+The addresses in brackets are physical addresses.
+
+============= ============= =============== =======
+Start Address End Address Description Size
+============= ============= =============== =======
+0xF_FFDF_1000 0xF_FFFF_FFFF Free 2 MB
+0xF_FFDF_0000 0xF_FFDF_0FFF IFC - FPGA 4 KB
+0xF_FF81_0000 0xF_FFDE_FFFF Free 5 MB
+0xF_FF80_0000 0xF_FF80_FFFF IFC NAND Flash 64 KB
+0xF_FF00_0000 0xF_FF7F_FFFF Free 8 MB
+0xF_FE00_0000 0xF_FEFF_FFFF CCSRBAR 16 MB
+0xF_F801_0000 0xF_FDFF_FFFF Free 95 MB
+0xF_F800_0000 0xF_F800_FFFF PCIe I/O Space 64 KB
+0xF_F600_0000 0xF_F7FF_FFFF QMAN s/w portal 32 MB
+0xF_F400_0000 0xF_F5FF_FFFF BMAN s/w portal 32 MB
+0xF_F000_0000 0xF_F3FF_FFFF Free 64 MB
+0xF_E800_0000 0xF_EFFF_FFFF IFC NOR Flash 128 MB
+0xF_E000_0000 0xF_E7FF_FFFF Promjet 128 MB
+0xF_A0C0_0000 0xF_DFFF_FFFF Free 1012 MB
+0xF_A000_0000 0xF_A0BF_FFFF MAPLE0/1/2 12 MB
+0xF_0040_0000 0xF_9FFF_FFFF Free 12 GB
+0xF_0000_0000 0xF_01FF_FFFF DCSR 32 MB
+0xC_4000_0000 0xE_FFFF_FFFF Free 11 GB
+0xC_3000_0000 0xC_3FFF_FFFF sRIO-2 I/O 256 MB
+0xC_2000_0000 0xC_2FFF_FFFF sRIO-1 I/O 256 MB
+0xC_0000_0000 0xC_1FFF_FFFF PCIe Mem Space 512 MB
+0x1_0000_0000 0xB_FFFF_FFFF Free 44 GB
+0x0_0000_0000 0x0_FFFF_FFFF DDRC1 4 GB
+============= ============= =============== =======
+
+NOR Flash memory Map on B4860 and B4420QDS
+------------------------------------------
+
+============= ============= ============================== =========
+ Start End Definition Size
+============= ============= ============================== =========
+0xEFF40000 0xEFFFFFFF U-Boot (current bank) 768KB
+0xEFF20000 0xEFF3FFFF U-Boot env (current bank) 128KB
+0xEFF00000 0xEFF1FFFF FMAN Ucode (current bank) 128KB
+0xEF300000 0xEFEFFFFF rootfs (alternate bank) 12MB
+0xEE800000 0xEE8FFFFF device tree (alternate bank) 1MB
+0xEE020000 0xEE6FFFFF Linux.uImage (alternate bank) 6MB+896KB
+0xEE000000 0xEE01FFFF RCW (alternate bank) 128KB
+0xEDF40000 0xEDFFFFFF U-Boot (alternate bank) 768KB
+0xEDF20000 0xEDF3FFFF U-Boot env (alternate bank) 128KB
+0xEDF00000 0xEDF1FFFF FMAN ucode (alternate bank) 128KB
+0xED300000 0xEDEFFFFF rootfs (current bank) 12MB
+0xEC800000 0xEC8FFFFF device tree (current bank) 1MB
+0xEC020000 0xEC6FFFFF Linux.uImage (current bank) 6MB+896KB
+0xEC000000 0xEC01FFFF RCW (current bank) 128KB
+============= ============= ============================== =========
+
+Various Software configurations/environment variables/commands
+--------------------------------------------------------------
+The below commands apply to both B4860QDS and B4420QDS.
+
+U-Boot environment variable hwconfig
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The default hwconfig is:
+
+.. code-block:: none
+
+ hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=cs0_cs1;usb1:dr_mode=host,phy_type=ulpi
+
+Note: For USB gadget set "dr_mode=peripheral"
+
+FMAN Ucode versions
+^^^^^^^^^^^^^^^^^^^
+
+fsl_fman_ucode_B4860_106_3_6.bin
+
+Switching to alternate bank
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Commands for switching to alternate bank.
+
+1. To change from vbank0 to vbank2
+
+.. code-block:: none
+
+ => qixis_reset altbank (it will boot using vbank2)
+
+2. To change from vbank2 to vbank0
+
+.. code-block:: none
+
+ => qixis reset (it will boot using vbank0)
+
+To change personality of board
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For changing personality from B4860 to B4420
+
+1. Boot from vbank0
+2. Flash vbank2 with b4420 rcw and U-Boot
+3. Give following commands to uboot prompt
+
+.. code-block:: none
+
+ => mw.b ffdf0040 0x30;
+ => mw.b ffdf0010 0x00;
+ => mw.b ffdf0062 0x02;
+ => mw.b ffdf0050 0x02;
+ => mw.b ffdf0010 0x30;
+ => reset
+
+Note:
+
+- Power off cycle will lead to default switch settings.
+- 0xffdf0000 is the address of the QIXIS FPGA.
+
+Switching between NOR and NAND boot(RCW src changed from NOR <-> NAND)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To change from NOR to NAND boot give following command on uboot prompt
+
+.. code-block:: none
+
+ => mw.b ffdf0040 0x30
+ => mw.b ffdf0010 0x00
+ => mw.b 0xffdf0050 0x08
+ => mw.b 0xffdf0060 0x82
+ => mw.b ffdf0061 0x00
+ => mw.b ffdf0010 0x30
+ => reset
+
+To change from NAND to NOR boot give following command on uboot prompt:
+
+.. code-block:: none
+
+ => mw.b ffdf0040 0x30
+ => mw.b ffdf0010 0x00
+ => mw.b 0xffdf0050 0x00(for vbank0) or (mw.b 0xffdf0050 0x02 for vbank2)
+ => mw.b 0xffdf0060 0x12
+ => mw.b ffdf0061 0x01
+ => mw.b ffdf0010 0x30
+ => reset
+
+Note:
+
+- Power off cycle will lead to default switch settings.
+- 0xffdf0000 is the address of the QIXIS FPGA.
+
+Ethernet interfaces for B4860QDS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Serdes protocosl tested:
+* 0x2a, 0x8d (serdes1, serdes2) [DEFAULT]
+* 0x2a, 0xb2 (serdes1, serdes2)
+
+When using [DEFAULT] RCW, which including 2 * 1G SGMII on board and 2 * 1G
+SGMII on SGMII riser card.
+
+Under U-Boot these network interfaces are recognized as::
+
+ FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 and FM1@DTSEC6.
+
+On Linux the interfaces are renamed as::
+
+ eth2 -> fm1-gb2
+ eth3 -> fm1-gb3
+ eth4 -> fm1-gb4
+ eth5 -> fm1-gb5
+
+RCW and Ethernet interfaces for B4420QDS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Serdes protocosl tested:
+* 0x18, 0x9e (serdes1, serdes2)
+
+Under U-Boot these network interfaces are recognized as::
+
+ FM1@DTSEC3, FM1@DTSEC4 and e1000#0.
+
+On Linux the interfaces are renamed as::
+
+ eth2 -> fm1-gb2
+ eth3 -> fm1-gb3
+
+NAND boot with 2 Stage boot loader
+----------------------------------
+PBL initialise the internal SRAM and copy SPL(160KB) in SRAM.
+SPL further initialise DDR using SPD and environment variables and copy
+U-Boot(768 KB) from flash to DDR.
+Finally SPL transer control to U-Boot for futher booting.
+
+SPL has following features:
+ - Executes within 256K
+ - No relocation required
+
+Run time view of SPL framework during boot:
+
++----------------------------------------------+
+|Area | Address |
++----------------------------------------------+
+|Secure boot | 0xFFFC0000 (32KB) |
+|headers | |
++----------------------------------------------+
+|GD, BD | 0xFFFC8000 (4KB) |
++----------------------------------------------+
+|ENV | 0xFFFC9000 (8KB) |
++----------------------------------------------+
+|HEAP | 0xFFFCB000 (30KB) |
++----------------------------------------------+
+|STACK | 0xFFFD8000 (22KB) |
++----------------------------------------------+
+|U-Boot SPL | 0xFFFD8000 (160KB) |
++----------------------------------------------+
+
+NAND Flash memory Map on B4860 and B4420QDS
+-------------------------------------------
+
+============= ============= ============================= =====
+Start End Definition Size
+============= ============= ============================= =====
+0x000000 0x0FFFFF U-Boot 1MB
+0x140000 0x15FFFF U-Boot env 128KB
+0x1A0000 0x1BFFFF FMAN Ucode 128KB
+============= ============= ============================= =====
diff --git a/roms/u-boot/doc/board/freescale/imx8mm_evk.rst b/roms/u-boot/doc/board/freescale/imx8mm_evk.rst
new file mode 100644
index 000000000..7fd3d7256
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imx8mm_evk.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx8mm_evk
+==========
+
+U-Boot for the NXP i.MX8MM EVK board
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get ddr firmware
+- Build U-Boot
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+Note: builddir is U-Boot build directory (source directory for in-tree builds)
+Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
+branch: imx_5.4.47_2.2.0
+
+.. code-block:: bash
+
+ $ make PLAT=imx8mm bl31
+ $ cp build/imx8mm/release/bl31.bin $(builddir)
+
+Get the ddr firmware
+--------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
+ $ chmod +x firmware-imx-8.9.bin
+ $ ./firmware-imx-8.9
+ $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-poky-linux-
+ $ make imx8mm_evk_defconfig
+ $ export ATF_LOAD_ADDR=0x920000
+ $ make
+
+Burn the flash.bin to MicroSD card offset 33KB:
+
+.. code-block:: bash
+
+ $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=notrunc
+ $sudo dd if=u-boot.itb of=/dev/sdc bs=1024 seek=384 conv=sync
+
+Boot
+----
+Set Boot switch to SD boot
diff --git a/roms/u-boot/doc/board/freescale/imx8mn_evk.rst b/roms/u-boot/doc/board/freescale/imx8mn_evk.rst
new file mode 100644
index 000000000..9fbb94703
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imx8mn_evk.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx8mn_evk
+==========
+
+U-Boot for the NXP i.MX8MN EVK board
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get firmware-imx package
+- Build U-Boot
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+Note: srctree is U-Boot source directory
+Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
+branch: imx_5.4.47_2.2.0
+
+.. code-block:: bash
+
+ $ make PLAT=imx8mn bl31
+ $ cp build/imx8mn/release/bl31.bin $(srctree)
+
+Get the ddr firmware
+--------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
+ $ chmod +x firmware-imx-8.9.bin
+ $ ./firmware-imx-8.9
+ $ cp firmware-imx-8.9/firmware/ddr/synopsys/ddr4*.bin $(srctree)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-poky-linux-
+ $ make imx8mn_ddr4_evk_defconfig
+ $ export ATF_LOAD_ADDR=0x960000
+ $ make
+
+Burn the flash.bin to MicroSD card offset 32KB:
+
+.. code-block:: bash
+
+ $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=notrunc
+ $sudo dd if=u-boot.itb of=/dev/sd[x] bs=1024 seek=384 conv=notrunc
+
+Boot
+----
+
+Set Boot switch to SD boot
diff --git a/roms/u-boot/doc/board/freescale/imx8mp_evk.rst b/roms/u-boot/doc/board/freescale/imx8mp_evk.rst
new file mode 100644
index 000000000..609a29f3e
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imx8mp_evk.rst
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx8mp_evk
+==========
+
+U-Boot for the NXP i.MX8MP EVK board
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get the firmware-imx package
+- Build U-Boot
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
+branch: imx_5.4.70_2.3.0
+
+.. code-block:: bash
+
+ $ make PLAT=imx8mp bl31
+
+Get the ddr firmware
+--------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.10.bin
+ $ chmod +x firmware-imx-8.10.bin
+ $ ./firmware-imx-8.10.bin
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-poky-linux-
+ $ make O=build imx8mp_evk_defconfig
+ $ cp ../imx-atf/build/imx8mp/release/bl31.bin ./build/bl31.bin
+ $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin ./build/
+ $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin ./build/
+ $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin ./build/
+ $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin ./build/
+ $ export ATF_LOAD_ADDR=0x970000
+ $ make O=build
+
+Burn the flash.bin to the MicroSD card at offset 32KB:
+
+.. code-block:: bash
+
+ $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
+ $sudo dd if=build/u-boot.itb of=/dev/sd[x] bs=1K seek=384 conv=notrunc; sync
+
+Boot
+----
+
+Set Boot switch to SD boot
+Use /dev/ttyUSB2 for U-Boot console
diff --git a/roms/u-boot/doc/board/freescale/imx8mq_evk.rst b/roms/u-boot/doc/board/freescale/imx8mq_evk.rst
new file mode 100644
index 000000000..c269fdebe
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imx8mq_evk.rst
@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx8mq_evk
+==========
+
+U-Boot for the NXP i.MX8MQ EVK board
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get ddr and hdmi fimware
+- Build U-Boot
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+Note: srctree is U-Boot source directory
+Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
+branch: imx_5.4.47_2.2.0
+
+.. code-block:: bash
+
+ $ make PLAT=imx8mq bl31
+ $ cp build/imx8mq/release/bl31.bin $(builddir)
+
+Get the ddr and hdmi firmware
+-----------------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
+ $ chmod +x firmware-imx-8.9.bin
+ $ ./firmware-imx-8.9.bin
+ $ cp firmware-imx-8.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(builddir)
+ $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-poky-linux-
+ $ make imx8mq_evk_defconfig
+ $ make flash.bin
+
+Burn the flash.bin to MicroSD card offset 33KB:
+
+.. code-block:: bash
+
+ $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=notrunc
+
+Boot
+----
+Set Boot switch SW801: 1100 and Bmode: 10 to boot from Micro SD.
diff --git a/roms/u-boot/doc/board/freescale/imx8qxp_mek.rst b/roms/u-boot/doc/board/freescale/imx8qxp_mek.rst
new file mode 100644
index 000000000..215627cfa
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imx8qxp_mek.rst
@@ -0,0 +1,66 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx8qxp_mek
+===========
+
+U-Boot for the NXP i.MX8QXP EVK board
+
+Quick Start
+-----------
+
+- Build the ARM Trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Flash the binary into the SD card
+- Boot
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ git clone https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ git checkout origin/imx_4.19.35_1.1.0 -b imx_4.19.35_1.1.0
+ $ make PLAT=imx8qx bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.2.7.1.bin
+ $ chmod +x imx-sc-firmware-1.2.7.1.bin
+ $ ./imx-sc-firmware-1.2.7.1.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-2.3.1.bin
+ $ chmod +x imx-seco-2.3.1.bin
+ $ ./imx-seco-2.3.1.bin
+
+Copy the following binaries to U-Boot folder:
+
+.. code-block:: bash
+
+ $ cp imx-atf/build/imx8qx/release/bl31.bin .
+ $ cp imx-seco-2.3.1/firmware/seco/mx8qx-ahab-container.img ./ahab-container.img
+ $ cp imx-sc-firmware-1.2.7.1/mx8qx-mek-scfw-tcm.bin .
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ make imx8qxp_mek_defconfig
+ $ make flash.bin
+
+Flash the binary into the SD card
+---------------------------------
+
+Burn the flash.bin binary to SD card offset 32KB:
+
+.. code-block:: bash
+
+ $ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=notrunc
+
+Boot
+----
+Set Boot switch SW2: 1100.
diff --git a/roms/u-boot/doc/board/freescale/imxrt1020-evk.rst b/roms/u-boot/doc/board/freescale/imxrt1020-evk.rst
new file mode 100644
index 000000000..267f80c51
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imxrt1020-evk.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imxrt1020-evk
+=============
+
+How to use U-Boot on NXP i.MXRT1020 EVK
+---------------------------------------
+
+- Build U-Boot for i.MXRT1020 EVK:
+
+.. code-block:: bash
+
+ $ make mrproper
+ $ make imxrt1020-evk_defconfig
+ $ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+- Flash the SPL image into the micro SD card:
+
+.. code-block:: bash
+
+ $sudo dd if=SPL of=/dev/sdX bs=1k seek=1 conv=notrunc; sync
+
+- Flash the u-boot.img image into the micro SD card:
+
+.. code-block:: bash
+
+ $sudo dd if=u-boot.img of=/dev/sdX bs=1k seek=128 conv=notrunc; sync
+
+- Jumper settings::
+
+ SW8: 0 1 1 0
+
+where 0 means bottom position and 1 means top position (from the
+switch label numbers reference).
+
+- Connect the USB cable between the EVK and the PC for the console.
+ The USB console connector is the one close the ethernet connector
+
+- Insert the micro SD card in the board, power it up and U-Boot messages should come up.
diff --git a/roms/u-boot/doc/board/freescale/imxrt1050-evk.rst b/roms/u-boot/doc/board/freescale/imxrt1050-evk.rst
new file mode 100644
index 000000000..c1fb48f0c
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/imxrt1050-evk.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imxrt1050-evk
+=============
+
+How to use U-Boot on NXP i.MXRT1050 EVK
+---------------------------------------
+
+- Build U-Boot for i.MXRT1050 EVK:
+
+.. code-block:: bash
+
+ $ make mrproper
+ $ make imxrt1050-evk_defconfig
+ $ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+- Flash the SPL image into the micro SD card:
+
+.. code-block:: bash
+
+ $sudo dd if=SPL of=/dev/sdX bs=1k seek=1 conv=notrunc; sync
+
+- Flash the u-boot.img image into the micro SD card:
+
+.. code-block:: bash
+
+ $sudo dd if=u-boot.img of=/dev/sdX bs=1k seek=128 conv=notrunc; sync
+
+- Jumper settings::
+
+ SW7: 1 0 1 0
+
+where 0 means bottom position and 1 means top position (from the
+switch label numbers reference).
+
+- Connect the USB cable between the EVK and the PC for the console.
+ The USB console connector is the one close the ethernet connector
+
+- Insert the micro SD card in the board, power it up and U-Boot messages should come up.
diff --git a/roms/u-boot/doc/board/freescale/index.rst b/roms/u-boot/doc/board/freescale/index.rst
new file mode 100644
index 000000000..313cf409a
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/index.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Freescale
+=========
+
+.. toctree::
+ :maxdepth: 2
+
+ b4860qds
+ imx8mm_evk
+ imx8mn_evk
+ imx8mp_evk
+ imx8mq_evk
+ imx8qxp_mek
+ imxrt1020-evk
+ imxrt1050-evk
+ mx6sabreauto
+ mx6sabresd
+ mx6ul_14x14_evk
+ mx6ullevk
diff --git a/roms/u-boot/doc/board/freescale/mx6sabreauto.rst b/roms/u-boot/doc/board/freescale/mx6sabreauto.rst
new file mode 100644
index 000000000..fe4cd9d21
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/mx6sabreauto.rst
@@ -0,0 +1,100 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+mx6sabreauto
+============
+
+How to use and build U-Boot on mx6sabreauto
+-------------------------------------------
+
+mx6sabreauto_defconfig target supports mx6q/mx6dl/mx6qp sabreauto variants.
+
+In order to build it:
+
+.. code-block:: bash
+
+ $ make mx6sabreauto_defconfig
+ $ make
+
+This will generate the SPL and u-boot-dtb.img binaries.
+
+- Flash the SPL binary into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 conv=notrunc && sync
+
+- Flash the u-boot-dtb.img binary into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 conv=notrunc && sync
+
+Booting via Falcon mode
+-----------------------
+
+Write in mx6sabreauto_defconfig the following define below:
+
+CONFIG_SPL_OS_BOOT=y
+
+In order to build it:
+
+.. code-block:: bash
+
+ $ make mx6sabreauto_defconfig
+ $ make
+
+This will generate the SPL image called SPL and the u-boot-dtb.img.
+
+- Flash the SPL image into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 conv=notrunc && sync
+
+- Flash the u-boot-dtb.img image into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1K seek=69 conv=notrunc && sync
+
+Create a FAT16 boot partition to store uImage and the dtb file, then copy the files there:
+
+.. code-block:: bash
+
+ $ sudo cp uImage /media/boot
+ $ sudo cp imx6dl-sabreauto.dtb /media/boot
+
+Create a partition for root file system and extract it there:
+
+.. code-block:: bash
+
+ $ sudo tar xvf rootfs.tar.gz -C /media/root
+
+The SD card must have enough space for raw "args" and "kernel".
+To configure Falcon mode for the first time, on U-Boot do the following commands:
+
+- Load dtb file from boot partition::
+
+ # load mmc 0:1 ${fdt_addr} imx6dl-sabreauto.dtb
+
+- Load kernel image from boot partition::
+
+ # load mmc 0:1 ${loadaddr} uImage
+
+- Write kernel at 2MB offset::
+
+ # mmc write ${loadaddr} 0x1000 0x4000
+
+- Setup kernel bootargs::
+
+ # setenv bootargs "console=ttymxc3,115200 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait quiet rw"
+
+- Prepare args::
+
+ # spl export fdt ${loadaddr} - ${fdt_addr}
+
+- Write args 1MB data (0x800 sectors) to 1MB offset (0x800 sectors)::
+
+ # mmc write 18000000 0x800 0x800
+
+- Restart the board and then SPL binary will launch the kernel directly.
diff --git a/roms/u-boot/doc/board/freescale/mx6sabresd.rst b/roms/u-boot/doc/board/freescale/mx6sabresd.rst
new file mode 100644
index 000000000..fe15ba7b7
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/mx6sabresd.rst
@@ -0,0 +1,132 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+mx6sabresd
+==========
+
+How to use and build U-Boot on mx6sabresd
+-----------------------------------------
+
+The following methods can be used for booting mx6sabresd boards:
+
+1. Booting from SD card
+
+2. Booting from eMMC
+
+3. Booting via Falcon mode (SPL launches the kernel directly)
+
+
+1. Booting from SD card via SPL
+-------------------------------
+
+mx6sabresd_defconfig target supports mx6q/mx6dl/mx6qp sabresd variants.
+
+In order to build it:
+
+.. code-block:: bash
+
+ $ make mx6sabresd_defconfig
+ $ make
+
+This will generate the SPL and u-boot-dtb.img binaries.
+
+- Flash the SPL binary into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 conv=notrunc && sync
+
+- Flash the u-boot-dtb.img binary into the SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 conv=notrunc && sync
+
+2. Booting from eMMC
+--------------------
+
+.. code-block:: bash
+
+ $ make mx6sabresd_defconfig
+ $ make
+
+This will generate the SPL and u-boot-dtb.img binaries.
+
+- Boot first from SD card as shown in the previous section
+
+In U-boot change the eMMC partition config::
+
+ => mmc partconf 2 1 0 0
+
+Mount the eMMC in the host PC::
+
+ => ums 0 mmc 2
+
+- Flash SPL and u-boot-dtb.img binaries into the eMMC:
+
+.. code-block:: bash
+
+ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 conv=notrunc && sync
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 conv=notrunc && sync
+
+Set SW6 to eMMC 8-bit boot: 11010110
+
+3. Booting via Falcon mode
+--------------------------
+
+.. code-block:: bash
+
+ $ make mx6sabresd_defconfig
+ $ make
+
+This will generate the SPL image called SPL and the u-boot-dtb.img.
+
+- Flash the SPL image into the SD card
+
+.. code-block:: bash
+
+ $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 oflag=sync status=none conv=notrunc && sync
+
+- Flash the u-boot-dtb.img image into the SD card
+
+.. code-block:: bash
+
+ $ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 oflag=sync status=none conv=notrunc && sync
+
+Create a partition for root file system and extract it there
+
+.. code-block:: bash
+
+ $ sudo tar xvf rootfs.tar.gz -C /media/root
+
+The SD card must have enough space for raw "args" and "kernel".
+To configure Falcon mode for the first time, on U-Boot do the following commands:
+
+- Setup the IP server::
+
+ # setenv serverip <server_ip_address>
+
+- Download dtb file::
+
+ # dhcp ${fdt_addr} imx6q-sabresd.dtb
+
+- Download kernel image::
+
+ # dhcp ${loadaddr} uImage
+
+- Write kernel at 2MB offset::
+
+ # mmc write ${loadaddr} 0x1000 0x4000
+
+- Setup kernel bootargs::
+
+ # setenv bootargs "console=ttymxc0,115200 root=/dev/mmcblk1p1 rootfstype=ext4 rootwait quiet rw"
+
+- Prepare args::
+
+ # spl export fdt ${loadaddr} - ${fdt_addr}
+
+- Write args 1MB data (0x800 sectors) to 1MB offset (0x800 sectors)::
+
+ # mmc write 18000000 0x800 0x800
+
+- Press KEY_VOL_UP key, power up the board and then SPL binary will launch the kernel directly.
diff --git a/roms/u-boot/doc/board/freescale/mx6ul_14x14_evk.rst b/roms/u-boot/doc/board/freescale/mx6ul_14x14_evk.rst
new file mode 100644
index 000000000..8298bf8e1
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/mx6ul_14x14_evk.rst
@@ -0,0 +1,98 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+mx6ul_14x14_evk
+===============
+
+How to use U-Boot on Freescale MX6UL 14x14 EVK
+-----------------------------------------------
+
+- Build U-Boot for MX6UL 14x14 EVK:
+
+.. code-block:: bash
+
+ $ make mrproper
+ $ make mx6ul_14x14_evk_defconfig
+ $ make
+
+This will generate the SPL image called SPL and the u-boot.img.
+
+1. Booting via SDCard
+---------------------
+
+- Flash the SPL image into the micro SD card:
+
+.. code-block:: bash
+
+ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1 conv=notrunc; sync
+
+- Flash the u-boot.img image into the micro SD card:
+
+.. code-block:: bash
+
+ sudo dd if=u-boot.img of=/dev/mmcblk0 bs=1k seek=69 conv=notrunc; sync
+
+- Jumper settings::
+
+ SW601: 0 0 1 0
+ Sw602: 1 0
+
+where 0 means bottom position and 1 means top position (from the
+switch label numbers reference).
+
+- Connect the USB cable between the EVK and the PC for the console.
+ The USB console connector is the one close the push buttons
+
+- Insert the micro SD card in the board, power it up and U-Boot messages should come up.
+
+2. Booting via Serial Download Protocol (SDP)
+---------------------------------------------
+
+The mx6ulevk board can boot from USB OTG port using the SDP, target will
+enter in SDP mode in case an SD Card is not connect or boot switches are
+set as below::
+
+ Sw602: 0 1
+ SW601: x x x x
+
+The following tools can be used to boot via SDP, for both tools you must
+connect an USB cable in USB OTG port.
+
+- Method 1: Universal Update Utility (uuu)
+
+The UUU binary can be downloaded in release tab from link below:
+https://github.com/NXPmicro/mfgtools
+
+The following script should be created to boot SPL + u-boot-dtb.img binaries:
+
+.. code-block:: bash
+
+ $ cat uuu_script
+ uuu_version 1.1.4
+
+ SDP: boot -f SPL
+ SDPU: write -f u-boot-dtb.img -addr 0x877fffc0
+ SDPU: jump -addr 0x877fffc0
+ SDPU: done
+
+Please note that the address above is calculated based on SYS_TEXT_BASE address:
+
+0x877fffc0 = 0x87800000 (SYS_TEXT_BASE) - 0x40 (U-Boot proper Header size)
+
+Power on the target and run the following command from U-Boot root directory:
+
+.. code-block:: bash
+
+ $ sudo ./uuu uuu_script
+
+- Method 2: imx usb loader tool (imx_usb):
+
+The imx_usb_loader tool can be downloaded in link below:
+https://github.com/boundarydevices/imx_usb_loader
+
+Build the source code and run the following commands from U-Boot root
+directory:
+
+.. code-block:: bash
+
+ $ sudo ./imx_usb SPL
+ $ sudo ./imx_usb u-boot-dtb.img
diff --git a/roms/u-boot/doc/board/freescale/mx6ullevk.rst b/roms/u-boot/doc/board/freescale/mx6ullevk.rst
new file mode 100644
index 000000000..a26248a1e
--- /dev/null
+++ b/roms/u-boot/doc/board/freescale/mx6ullevk.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+mx6ullevk
+=========
+
+How to use U-Boot on Freescale MX6ULL 14x14 EVK
+-----------------------------------------------
+
+- First make sure you have installed the dtc package (device tree compiler):
+
+.. code-block:: bash
+
+ $ sudo apt-get install device-tree-compiler
+
+- Build U-Boot for MX6ULL 14x14 EVK:
+
+.. code-block:: bash
+
+ $ make mrproper
+ $ make mx6ull_14x14_evk_defconfig
+ $ make
+
+This generates the u-boot-dtb.imx image in the current directory.
+
+- Flash the u-boot-dtb.imx image into the micro SD card:
+
+.. code-block:: bash
+
+ $ sudo dd if=u-boot-dtb.imx of=/dev/sdb bs=1K seek=1 conv=notrunc && sync
+
+- Jumper settings::
+
+ SW601: 0 0 1 0
+ Sw602: 1 0
+
+Where 0 means bottom position and 1 means top position (from the switch label
+numbers reference).
+
+Connect the USB cable between the EVK and the PC for the console.
+(The USB console connector is the one close the push buttons)
+
+Insert the micro SD card in the board, power it up and U-Boot messages should
+come up.
+
+The link for the board: http://www.nxp.com/products/microcontrollers-and- \
+processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/ \
+i.mx6qp/evaluation-kit-for-the-i.mx-6ull-applications-processor:MCIMX6ULL-EVK
diff --git a/roms/u-boot/doc/board/google/chromebook_coral.rst b/roms/u-boot/doc/board/google/chromebook_coral.rst
new file mode 100644
index 000000000..4b585678d
--- /dev/null
+++ b/roms/u-boot/doc/board/google/chromebook_coral.rst
@@ -0,0 +1,442 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Chromebook Coral
+================
+
+Coral is a Chromebook (or really about 20 different Chromebooks) which use the
+Intel Apollo Lake platform (APL). The 'reef' Chromebooks use the same APL SoC so
+should also work. Some later ones based on Glacier Lake (GLK) need various
+changes in GPIOs, etc. but are very similar.
+
+It is hoped that this port can enable ports to embedded APL boards which are
+starting to appear.
+
+Note that booting U-Boot on APL is already supported by coreboot and
+Slim Bootloader. This documentation refers to a 'bare metal' port.
+
+
+Building
+--------
+
+First, you need the following binary blobs:
+
+ * descriptor.bin - Intel flash descriptor
+ * fitimage.bin - Base flash image structure
+ * fsp_m.bin - FSP-M, for setting up SDRAM
+ * fsp_s.bin - FSP-S, for setting up Silicon
+ * vbt.bin - for setting up display
+
+These binaries do not seem to be available publicly. If you have a ROM image,
+such as santa.bin then you can do this::
+
+ cbfstool santa.bin extract -n fspm.bin -f fsp-m.bin
+ cbfstool santa.bin extract -n fsps.bin -f fsp-s.bin
+ cbfstool santa.bin extract -n vbt-santa.bin -f vbt.bin
+ mkdir tmp
+ cd tmp
+ dump_fmap -x ../santa.bin
+ mv SI_DESC ../descriptor.bin
+ mv IFWI ../fitimage.bin
+
+Put all of these files in `board/google/chromebook_coral` so they can be found
+by the build.
+
+To build::
+
+ make O=/tmp/b/chromebook_coral chromebook_coral_defconfig
+ make O=/tmp/b/chromebook_coral -s -j30 all
+
+That should produce `/tmp/b/chrombook_coral/u-boot.rom` which you can use with
+a Dediprog em100::
+
+ em100 -s -c w25q128fw -d /tmp/b/chromebook_coral/u-boot.rom -r
+
+or you can use flashrom to write it to the board. If you do that, make sure you
+have a way to restore the old ROM without booting the board. Otherwise you may
+brick it. Having said that, you may find these instructions useful if you want
+to unbrick your device:
+
+ https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging.md
+
+You can buy Suzy-Q from Sparkfun:
+
+ https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/ccd.md#suzyq-suzyqable
+
+Note that it will hang at the SPL prompt for 21 seconds. When booting into
+Chrome OS it will always select developer mode, so will wipe anything you have
+on the device if you let it proceed. You have two seconds in U-Boot to stop the
+auto-boot prompt and several seconds at the 'developer wipe' screen to stop it
+wiping the disk.
+
+Here is the console output::
+
+ U-Boot TPL 2021.04-rc1-00128-g344eefcdfec-dirty (Feb 11 2021 - 20:13:08 -0700)
+ Trying to boot from Mapped SPI
+
+ U-Boot SPL 2021.04-rc1-00128-g344eefcdfec-dirty (Feb 11 2021 - 20:13:08 -0700)
+ Trying to boot from Mapped SPI
+
+
+ U-Boot 2021.04-rc1-00128-g344eefcdfec-dirty (Feb 11 2021 - 20:13:08 -0700)
+
+ CPU: Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
+ DRAM: 3.9 GiB
+ MMC: sdmmc@1b,0: 1, emmc@1c,0: 2
+ Video: 1024x768x32 @ b0000000
+ Model: Google Coral
+ Net: No ethernet found.
+ SF: Detected w25q128fw with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+ Hit any key to stop autoboot: 0
+ cmdline=console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=${uuid}/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none rw 1,0 3788800 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3788800 alg=sha1 root_hexdigest=55052b629d3ac889f25a9583ea12cdcd3ea15ff8 salt=a2d4d9e574069f4fed5e3961b99054b7a4905414b60a25d89974a7334021165c" noinitrd vt.global_cursor_default=0 kern_guid=${uuid} add_efi_memmap boot=local noresume noswap i915.modeset=1 Kernel command line: "console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=35c775e7-3735-d745-93e5-d9e0238f7ed0/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none rw 1,0 3788800 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3788800 alg=sha1 root_hexdigest=55052b629d3ac889f25a9583ea12cdcd3ea15ff8 salt=a2d4d9e574069f4fed5e3961b99054b7a4905414b60a25d89974a7334021165c" noinitrd vt.global_cursor_default=0 kern_guid=35c775e7-3735-d745-93e5-d9e0238f7ed0 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic disablevmx=off "
+ Setup located at 00090000:
+
+ ACPI RSDP addr : 7991f000
+ E820: 14 entries
+ Addr Size Type
+ d0000000 1000000 <NULL>
+ 0 a0000 RAM
+ a0000 60000 Reserved
+ 7b000000 800000 Reserved
+ 7b800000 4800000 Reserved
+ 7ac00000 400000 Reserved
+ 100000 ff00000 RAM
+ 10000000 2151000 Reserved
+ 12151000 68aaf000 RAM
+ 100000000 80000000 RAM
+ e0000000 10000000 Reserved
+ 7991bfd0 12e4030 Reserved
+ d0000000 10000000 Reserved
+ fed10000 8000 Reserved
+ Setup sectors : 1e
+ Root flags : 1
+ Sys size : 63420
+ RAM size : 0
+ Video mode : ffff
+ Root dev : 0
+ Boot flag : 0
+ Jump : 66eb
+ Header : 53726448
+ Kernel V2
+ Version : 20d
+ Real mode switch : 0
+ Start sys : 1000
+ Kernel version : 38cc
+ @00003acc:
+ Type of loader : 80
+ U-Boot, version 0
+ Load flags : 81
+ : loaded-high can-use-heap
+ Setup move size : 8000
+ Code32 start : 100000
+ Ramdisk image : 0
+ Ramdisk size : 0
+ Bootsect kludge : 0
+ Heap end ptr : 8e00
+ Ext loader ver : 0
+ Ext loader type : 0
+ Command line ptr : 99000
+ console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=35c775e7-3735-d745-93e5-d9e0238f7ed0/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none rw 1,0 3788800 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3788800 alg=sha1 root_hexdigest=55052b629d3ac889f25a9583ea12cdcd3ea15ff8 salt=a2d4d9e574069f4fed5e3961b99054b7a4905414b60a25d89974a7334021165c" noinitrd vt.global_cursor_default=0 kern_guid=35c775e7-3735-d745-93e5-d9e0238f7ed0 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic disablevmx=off
+ Initrd addr max : 7fffffff
+ Kernel alignment : 200000
+ Relocatable kernel : 1
+ Min alignment : 15
+ : 200000
+ Xload flags : 3
+ : 64-bit-entry can-load-above-4gb
+ Cmdline size : 7ff
+ Hardware subarch : 0
+ HW subarch data : 0
+ Payload offset : 26e
+ Payload length : 612045
+ Setup data : 0
+ Pref address : 1000000
+ Init size : 1383000
+ Handover offset : 0
+
+ Starting kernel ...
+
+ Timer summary in microseconds (17 records):
+ Mark Elapsed Stage
+ 0 0 reset
+ 155,279 155,279 TPL
+ 237,088 81,809 end phase
+ 237,533 445 SPL
+ 816,456 578,923 end phase
+ 817,357 901 board_init_f
+ 1,061,751 244,394 board_init_r
+ 1,402,435 340,684 id=64
+ 1,430,071 27,636 main_loop
+ 5,532,057 4,101,986 start_kernel
+
+ Accumulated time:
+ 685 dm_r
+ 2,817 fast_spi
+ 33,095 dm_spl
+ 52,468 dm_f
+ 208,242 fsp-m
+ 242,221 fsp-s
+ 332,710 mmap_spi
+
+
+Boot flow - TPL
+---------------
+
+Apollo Lake boots via an IFWI (Integrated Firmware Image). TPL is placed in
+this, in the IBBL entry.
+
+On boot, an on-chip microcontroller called the CSE (Converged Security Engine)
+sets up some SDRAM at ffff8000 and loads the TPL image to that address. The
+SRAM extends up to the top of 32-bit address space, but the last 2KB is the
+start16 region, so the TPL image must be 30KB at most, and CONFIG_TPL_TEXT_BASE
+must be ffff8000. Actually the start16 region is small and it could probably
+move from f800 to fe00, providing another 1.5KB, but TPL is only about 19KB so
+there is no need to change it at present. The size limit is enforced by
+CONFIG_TPL_SIZE_LIMIT to avoid producing images that won't boot.
+
+TPL (running from start.S) first sets up CAR (Cache-as-RAM) which provides
+larger area of RAM for use while booting. CAR is mapped at CONFIG_SYS_CAR_ADDR
+(fef00000) and is 768KB in size. It then sets up the stack in the botttom 64KB
+of this space (i.e. below fef10000). This means that the stack and early
+malloc() region in TPL can be 64KB at most.
+
+TPL operates without CONFIG_TPL_PCI enabled so PCI config access must use the
+x86-specific functions pci_x86_write_config(), etc. SPL creates a simple-bus
+device so that PCI devices are bound by driver model. Then arch_cpu_init_tpl()
+is called to early init on various devices. This includes placing PCI devices
+at hard-coded addresses in the memory map. PCI auto-config is not used.
+
+Most of the 16KB ROM is mapped into the very top of memory, except for the
+Intel descriptor (first 4KB) and the space for SRAM as above.
+
+TPL does not set up a bloblist since at present it does not have anything to
+pass to SPL.
+
+Once TPL is done it loads SPL from ROM using either the memory-mapped SPI or by
+using the Intel fast SPI driver. SPL is loaded into CAR, at the address given
+by CONFIG_SPL_TEXT_BASE, which is normally fef10000.
+
+Note that booting using the SPI driver results in an TPL image that is about
+26KB in size instead of 19KB. Also boot speed is worse by about 340ms. If you
+really want to use the driver, enable CONFIG_APL_SPI_FLASH_BOOT and set
+BOOT_FROM_FAST_SPI_FLASH to true[2].
+
+
+Boot flow - SPL
+---------------
+
+SPL (running from start_from_tpl.S) continues to use the same stack as TPL.
+It calls arch_cpu_init_spl() to set up a few devices, then init_dram() loads
+the FSP-M binary into CAR and runs to, to set up SDRAM. The address of the
+output 'HOB' list (Hand-off-block) is stored into gd->arch.hob_list for parsing.
+There is a 2GB chunk of SDRAM starting at 0 and the rest is at 4GB.
+
+PCI auto-config is not used in SPL either, but CONFIG_SPL_PCI is defined, so
+proper PCI access is available and normal dm_pci_read_config() calls can be
+used. However PCI auto-config is not used so the same static memory mapping set
+up by TPL is still active.
+
+SPL on x86 always runs with CONFIG_SPL_SEPARATE_BSS=y and BSS is at 120000
+(see u-boot-spl.lds). This works because SPL doesn't access BSS until after
+board_init_r(), as per the rules, and DRAM is available then.
+
+SPL sets up a bloblist and passes the SPL hand-off information to U-Boot proper.
+This includes a pointer to the HOB list as well as DRAM information. See
+struct arch_spl_handoff. The bloblist address is set by CONFIG_BLOBLIST_ADDR,
+normally 100000.
+
+SPL uses SPI flash to update the MRC caches in ROM. This speeds up subsequent
+boots. Be warned that SPL can take 30 seconds without this cache! This is a
+known issue with Intel SoCs with modern DRAM and apparently cannot be improved.
+The MRC caches are used to work around this.
+
+Once SPL is finished it loads U-Boot into SDRAM at CONFIG_SYS_TEXT_BASE, which
+is normally 1110000. Note that CAR is still active.
+
+
+Boot flow - U-Boot pre-relocation
+---------------------------------
+
+U-Boot (running from start_from_spl.S) starts running in RAM and uses the same
+stack as SPL. It does various init activities before relocation. Notably
+arch_cpu_init_dm() sets up the pin muxing for the chip using a very large table
+in the device tree.
+
+PCI auto-config is not used before relocation, but CONFIG_PCI of course is
+defined, so proper PCI access is available. The same static memory mapping set
+up by TPL is still active until relocation.
+
+As per usual, U-Boot allocates memory at the top of available RAM (a bit below
+2GB in this case) and copies things there ready to relocate itself. Notably
+reserve_arch() does not reserve space for the HOB list returned by FSP-M since
+this is already located in RAM.
+
+U-Boot then shuts down CAR and jumps to its relocated version.
+
+
+Boot flow - U-Boot post-relocation
+----------------------------------
+
+U-Boot starts up normally, running near the top of RAM. After driver model is
+running, arch_fsp_init_r() is called which loads and runs the FSP-S binary.
+This updates the HOB list to include graphics information, used by the fsp_video
+driver.
+
+PCI autoconfig is done and a few devices are probed to complete init. Most
+others are started only when they are used.
+
+Note that FSP-S is supposed to run after CAR has been shut down, which happens
+immediately before U-Boot starts up in its relocated position. Therefore we
+cannot run FSP-S before relocation. On the other hand we must run it before
+PCI auto-config is done, since FSP-S may show or hide devices. The first device
+that probes PCI after relocation is the serial port, in initr_serial(), so FSP-S
+must run before that. A corollary is that loading FSP-S must be done without
+using the SPI driver, to avoid probing PCI and causing an autoconfig, so
+memory-mapped reading is always used for FSP-S.
+
+It would be possible to tear down CAR in SPL instead of U-Boot. The SPL handoff
+information could make sure it does not include any pointers into CAR (in fact
+it doesn't). But tearing down CAR in U-Boot allows the initial state used by TPL
+and SPL to be read by U-Boot, which seems useful. It also matches how older
+platforms start up (those that don't use SPL).
+
+
+Performance
+-----------
+
+Bootstage is used through all phases of U-Boot to keep accurate timimgs for
+boot. Use 'bootstage report' in U-Boot to see the report, e.g.::
+
+ Timer summary in microseconds (16 records):
+ Mark Elapsed Stage
+ 0 0 reset
+ 155,325 155,325 TPL
+ 204,014 48,689 end TPL
+ 204,385 371 SPL
+ 738,633 534,248 end SPL
+ 739,161 528 board_init_f
+ 842,764 103,603 board_init_r
+ 1,166,233 323,469 main_loop
+ 1,166,283 50 id=175
+
+ Accumulated time:
+ 62 fast_spi
+ 202 dm_r
+ 7,779 dm_spl
+ 15,555 dm_f
+ 208,357 fsp-m
+ 239,847 fsp-s
+ 292,143 mmap_spi
+
+CPU performance is about 3500 DMIPS::
+
+ => dhry
+ 1000000 iterations in 161 ms: 6211180/s, 3535 DMIPS
+
+
+Partial memory map
+------------------
+
+::
+
+ ffffffff Top of ROM (and last byte of 32-bit address space)
+ ffff8000 TPL loaded here (from IFWI)
+ ff000000 Bottom of ROM
+ fefc0000 Top of CAR region
+ fef96000 Stack for FSP-M
+ fef40000 59000 FSP-M (also VPL loads here)
+ fef11000 SPL loaded here
+ fef10000 CONFIG_BLOBLIST_ADDR
+ fef10000 Stack top in TPL, SPL and U-Boot before relocation
+ fef00000 1000 CONFIG_BOOTSTAGE_STASH_ADDR
+ fef00000 Base of CAR region
+
+ 30000 AP_DEFAULT_BASE (used to start up additional CPUs)
+ f0000 CONFIG_ROM_TABLE_ADDR
+ 120000 BSS (defined in u-boot-spl.lds)
+ 200000 FSP-S (which is run after U-Boot is relocated)
+ 1110000 CONFIG_SYS_TEXT_BASE
+
+
+Speeding up SPL for development
+-------------------------------
+
+The 21-second wait for memory training is annoying during development, since
+every new image incurs this cost when booting. There is no cache to fall back on
+since that area of the image is empty on start-up.
+
+You can add suitable cache contents to the image to fix this, for development
+purposes only, like this::
+
+ # Read the image back after booting through SPL
+ em100 -s -c w25q128fw -u image.bin
+
+ # Extract the two cache regions
+ binman extract -i image.bin extra *cache
+
+ # Move them into the source directory
+ mv *cache board/google/chromebook_coral
+
+Then add something like this to the devicetree::
+
+ #if IS_ENABLED(CONFIG_HAVE_MRC) || IS_ENABLED(CONFIG_FSP_VERSION2)
+ /* Provide initial contents of the MRC data for faster development */
+ rw-mrc-cache {
+ type = "blob";
+ /* Mirror the offset in spi-flash@0 */
+ offset = <0xff8e0000>;
+ size = <0x10000>;
+ filename = "board/google/chromebook_coral/rw-mrc-cache";
+ };
+ rw-var-mrc-cache {
+ type = "blob";
+ size = <0x1000>;
+ filename = "board/google/chromebook_coral/rw-var-mrc-cache";
+ };
+ #endif
+
+This tells binman to put the cache contents in the same place as the
+`rw-mrc-cache` and `rw-var-mrc-cache` regions defined by the SPI-flash driver.
+
+
+Supported peripherals
+---------------------
+
+The following have U-Boot drivers:
+
+ - UART
+ - SPI flash
+ - Video
+ - MMC (dev 0) and micro-SD (dev 1)
+ - Chrome OS EC
+ - Cr50 (security chip)
+ - Keyboard
+ - USB
+
+
+To do
+-----
+
+- Finish peripherals
+ - Sound (Intel I2S support exists, but need da7219 driver)
+- Use FSP-T binary instead of our own CAR implementation
+- Use the official FSP package instead of the coreboot one
+- Suspend / resume
+- Fix MMC which seems to try to read even though the card is empty
+- Fix USB3 crash "WARN halted endpoint, queueing URB anyway."
+
+
+Credits
+-------
+
+This is a spare-time project conducted slowly over a long period of time.
+
+Much of the code for this port came from Coreboot, an open-source firmware
+project similar to U-Boot's SPL in terms of features.
+
+Also see [2] for information about the boot flow used by coreboot. It is
+similar, but has an extra postcar stage. U-Boot doesn't need this since it
+supports relocating itself in memory.
+
+
+[2] Intel PDF https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf
diff --git a/roms/u-boot/doc/board/google/chromebook_link.rst b/roms/u-boot/doc/board/google/chromebook_link.rst
new file mode 100644
index 000000000..16080304d
--- /dev/null
+++ b/roms/u-boot/doc/board/google/chromebook_link.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Chromebook Link
+===============
+
+First, you need the following binary blobs:
+
+ * descriptor.bin - Intel flash descriptor
+ * me.bin - Intel Management Engine
+ * mrc.bin - Memory Reference Code, which sets up SDRAM
+ * video ROM - sets up the display
+
+You can get these binary blobs by::
+
+ $ git clone http://review.coreboot.org/p/blobs.git
+ $ cd blobs
+
+Find the following files:
+
+ * ./mainboard/google/link/descriptor.bin
+ * ./mainboard/google/link/me.bin
+ * ./northbridge/intel/sandybridge/systemagent-r6.bin
+
+The 3rd one should be renamed to mrc.bin.
+As for the video ROM, you can get it `here`_ and rename it to vga.bin.
+Make sure all these binary blobs are put in the board directory.
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make chromebook_link_defconfig
+ $ make all
+
+.. _here: http://www.coreboot.org/~stepan/pci8086,0166.rom
diff --git a/roms/u-boot/doc/board/google/chromebook_samus.rst b/roms/u-boot/doc/board/google/chromebook_samus.rst
new file mode 100644
index 000000000..eab1128e4
--- /dev/null
+++ b/roms/u-boot/doc/board/google/chromebook_samus.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Chromebook Samus
+================
+
+First, you need the following binary blobs:
+
+ * descriptor.bin - Intel flash descriptor
+ * me.bin - Intel Management Engine
+ * mrc.bin - Memory Reference Code, which sets up SDRAM
+ * refcode.elf - Additional Reference code
+ * vga.bin - video ROM, which sets up the display
+
+If you have a samus you can obtain them from your flash, for example, in
+developer mode on the Chromebook (use Ctrl-Alt-F2 to obtain a terminal and
+log in as 'root')::
+
+ cd /tmp
+ flashrom -w samus.bin
+ scp samus.bin username@ip_address:/path/to/somewhere
+
+If not see the coreboot tree where you can use::
+
+ bash crosfirmware.sh samus
+
+to get the image. There is also an 'extract_blobs.sh' scripts that you can use
+on the 'coreboot-Google_Samus.*' file to short-circuit some of the below.
+
+Then 'ifdtool -x samus.bin' on your development machine will produce::
+
+ flashregion_0_flashdescriptor.bin
+ flashregion_1_bios.bin
+ flashregion_2_intel_me.bin
+
+Rename flashregion_0_flashdescriptor.bin to descriptor.bin
+Rename flashregion_2_intel_me.bin to me.bin
+You can ignore flashregion_1_bios.bin - it is not used.
+
+To get the rest, use 'cbfstool samus.bin print'::
+
+ samus.bin: 8192 kB, bootblocksize 2864, romsize 8388608, offset 0x700000
+ alignment: 64 bytes, architecture: x86
+
+============================ ======== =========== ======
+Name Offset Type Size
+============================ ======== =========== ======
+cmos_layout.bin 0x700000 cmos_layout 1164
+pci8086,0406.rom 0x7004c0 optionrom 65536
+spd.bin 0x710500 (unknown) 4096
+cpu_microcode_blob.bin 0x711540 microcode 70720
+fallback/romstage 0x722a00 stage 54210
+fallback/ramstage 0x72fe00 stage 96382
+config 0x7476c0 raw 6075
+fallback/vboot 0x748ec0 stage 15980
+fallback/refcode 0x74cd80 stage 75578
+fallback/payload 0x75f500 payload 62878
+u-boot.dtb 0x76eb00 (unknown) 5318
+(empty) 0x770000 null 196504
+mrc.bin 0x79ffc0 (unknown) 222876
+(empty) 0x7d66c0 null 167320
+============================ ======== =========== ======
+
+You can extract what you need::
+
+ cbfstool samus.bin extract -n pci8086,0406.rom -f vga.bin
+ cbfstool samus.bin extract -n fallback/refcode -f refcode.rmod
+ cbfstool samus.bin extract -n mrc.bin -f mrc.bin
+ cbfstool samus.bin extract -n fallback/refcode -f refcode.bin -U
+
+Note that the -U flag is only supported by the latest cbfstool. It unpacks
+and decompresses the stage to produce a coreboot rmodule. This is a simple
+representation of an ELF file. You need the patch "Support decoding a stage
+with compression".
+
+Put all 5 files into board/google/chromebook_samus.
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make chromebook_samus_defconfig
+ $ make all
+
+If you are using em100, then this command will flash write -Boot::
+
+ em100 -s -d filename.rom -c W25Q64CV -r
+
+Flash map for samus / broadwell:
+
+ :fffff800: SYS_X86_START16
+ :ffff0000: RESET_SEG_START
+ :fffd8000: TPL_TEXT_BASE
+ :fffa0000: X86_MRC_ADDR
+ :fff90000: VGA_BIOS_ADDR
+ :ffed0000: SYS_TEXT_BASE
+ :ffea0000: X86_REFCODE_ADDR
+ :ffe70000: SPL_TEXT_BASE
+ :ffbf8000: CONFIG_ENV_OFFSET (environemnt offset)
+ :ffbe0000: rw-mrc-cache (Memory-reference-code cache)
+ :ffa00000: <spare>
+ :ff801000: intel-me (address set by descriptor.bin)
+ :ff800000: intel-descriptor
diff --git a/roms/u-boot/doc/board/google/index.rst b/roms/u-boot/doc/board/google/index.rst
new file mode 100644
index 000000000..061c79771
--- /dev/null
+++ b/roms/u-boot/doc/board/google/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Google
+======
+
+.. toctree::
+ :maxdepth: 2
+
+ chromebook_coral
+ chromebook_link
+ chromebook_samus
diff --git a/roms/u-boot/doc/board/index.rst b/roms/u-boot/doc/board/index.rst
new file mode 100644
index 000000000..747511f7d
--- /dev/null
+++ b/roms/u-boot/doc/board/index.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Board-specific doc
+==================
+
+.. toctree::
+ :maxdepth: 2
+
+ actions/index
+ advantech/index
+ AndesTech/index
+ amlogic/index
+ atmel/index
+ congatec/index
+ coreboot/index
+ emulation/index
+ freescale/index
+ google/index
+ intel/index
+ kontron/index
+ microchip/index
+ rockchip/index
+ sifive/index
+ sipeed/index
+ st/index
+ tbs/index
+ toradex/index
+ xen/index
+ xilinx/index
diff --git a/roms/u-boot/doc/board/intel/bayleybay.rst b/roms/u-boot/doc/board/intel/bayleybay.rst
new file mode 100644
index 000000000..db97f645f
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/bayleybay.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Bayley Bay CRB
+==============
+
+This uses as FSP as with Crown Bay, except it is for the Atom E3800 series.
+Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at
+the time of writing). Put it in the corresponding board directory and rename
+it to fsp.bin.
+
+Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same
+board directory as vga.bin.
+
+You still need two more binary blobs. For Bayley Bay, they can be extracted
+from the sample SPI image provided in the FSP (SPI.bin at the time of writing)::
+
+ $ ./tools/ifdtool -x BayleyBay/SPI.bin
+ $ cp flashregion_0_flashdescriptor.bin board/intel/bayleybay/descriptor.bin
+ $ cp flashregion_2_intel_me.bin board/intel/bayleybay/me.bin
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make bayleybay_defconfig
+ $ make all
+
+Note that the debug version of the FSP is bigger in size. If this version
+is used, CONFIG_FSP_ADDR needs to be configured to 0xfffb0000 instead of
+the default value 0xfffc0000.
diff --git a/roms/u-boot/doc/board/intel/cherryhill.rst b/roms/u-boot/doc/board/intel/cherryhill.rst
new file mode 100644
index 000000000..151f0613f
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/cherryhill.rst
@@ -0,0 +1,30 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Cherry Hill CRB
+===============
+
+This uses Intel FSP for Braswell platform. Download it from Intel FSP website,
+put the .fd file to the board directory and rename it to fsp.bin.
+
+Extract descriptor.bin and me.bin from the original BIOS on the board using
+ifdtool and put them to the board directory as well.
+
+Note the FSP package for Braswell does not ship a traditional legacy VGA BIOS
+image for the integrated graphics device. Instead a new binary called Video
+BIOS Table (VBT) is shipped. Put it to the board directory and rename it to
+vbt.bin if you want graphics support in U-Boot.
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make cherryhill_defconfig
+ $ make all
+
+An important note for programming u-boot.rom to the on-board SPI flash is that
+you need make sure the SPI flash's 'quad enable' bit in its status register
+matches the settings in the descriptor.bin, otherwise the board won't boot.
+
+For the on-board SPI flash MX25U6435F, this can be done by writing 0x40 to the
+status register by DediProg in: Config > Modify Status Register > Write Status
+Register(s) > Register1 Value(Hex). This is is a one-time change. Once set, it
+persists in SPI flash part regardless of the u-boot.rom image burned.
diff --git a/roms/u-boot/doc/board/intel/cougarcanyon2.rst b/roms/u-boot/doc/board/intel/cougarcanyon2.rst
new file mode 100644
index 000000000..5e3e7a182
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/cougarcanyon2.rst
@@ -0,0 +1,24 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Cougar Canyon 2 CRB
+===================
+
+This uses Intel FSP for 3rd generation Intel Core and Intel Celeron processors
+with mobile Intel HM76 and QM77 chipsets platform. Download it from Intel FSP
+website and put the .fd file (CHIEFRIVER_FSP_GOLD_001_09-OCTOBER-2013.fd at the
+time of writing) in the board directory and rename it to fsp.bin.
+
+Now build U-Boot and obtain u-boot.rom::
+
+ $ make cougarcanyon2_defconfig
+ $ make all
+
+The board has two 8MB SPI flashes mounted, which are called SPI-0 and SPI-1 in
+the board manual. The SPI-0 flash should have flash descriptor plus ME firmware
+and SPI-1 flash is used to store U-Boot. For convenience, the complete 8MB SPI-0
+flash image is included in the FSP package (named Rom00_8M_MB_PPT.bin). Program
+this image to the SPI-0 flash according to the board manual just once and we are
+all set. For programming U-Boot we just need to program SPI-1 flash. Since the
+default u-boot.rom image for this board is set to 2MB, it should be programmed
+to the last 2MB of the 8MB chip, address range [600000, 7FFFFF].
diff --git a/roms/u-boot/doc/board/intel/crownbay.rst b/roms/u-boot/doc/board/intel/crownbay.rst
new file mode 100644
index 000000000..4fcf9811c
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/crownbay.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Crown Bay CRB
+=============
+
+U-Boot support of Intel `Crown Bay`_ board relies on a binary blob called
+Firmware Support Package (`FSP`_) to perform all the necessary initialization
+steps as documented in the BIOS Writer Guide, including initialization of the
+CPU, memory controller, chipset and certain bus interfaces.
+
+Download the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T,
+install it on your host and locate the FSP binary blob. Note this platform
+also requires a Chipset Micro Code (CMC) state machine binary to be present in
+the SPI flash where u-boot.rom resides, and this CMC binary blob can be found
+in this FSP package too.
+
+ * ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd
+ * ./Microcode/C0_22211.BIN
+
+Rename the first one to fsp.bin and second one to cmc.bin and put them in the
+board directory.
+
+Note the FSP release version 001 has a bug which could cause random endless
+loop during the FspInit call. This bug was published by Intel although Intel
+did not describe any details. We need manually apply the patch to the FSP
+binary using any hex editor (eg: bvi). Go to the offset 0x1fcd8 of the FSP
+binary, change the following five bytes values from orginally E8 42 FF FF FF
+to B8 00 80 0B 00.
+
+As for the video ROM, you need manually extract it from the Intel provided
+BIOS for Crown Bay `here`_, using the AMI `MMTool`_. Check PCI option
+ROM ID 8086:4108, extract and save it as vga.bin in the board directory.
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make crownbay_defconfig
+ $ make all
+
+.. _`Crown Bay`: http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-platforms/atom-e660-eg20t-development-kit.html
+.. _`FSP`: http://www.intel.com/fsp
+.. _`here`: http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/e6xx-35-b1-cmc22211.html
+.. _`MMTool`: http://www.ami.com/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/
diff --git a/roms/u-boot/doc/board/intel/edison.rst b/roms/u-boot/doc/board/intel/edison.rst
new file mode 100644
index 000000000..5a65673d1
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/edison.rst
@@ -0,0 +1,170 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+Edison
+======
+
+Build Instructions for U-Boot as main bootloader
+------------------------------------------------
+
+Simple you can build U-Boot and obtain u-boot.bin::
+
+ $ make edison_defconfig
+ $ make all
+
+Updating U-Boot on Edison
+-------------------------
+
+By default Intel Edison boards are shipped with preinstalled heavily
+patched U-Boot v2014.04. Though it supports DFU which we may be able to
+use.
+
+1. Prepare u-boot.bin as described in chapter above. You still need one
+ more step (if and only if you have original U-Boot), i.e. run the
+ following command::
+
+ $ truncate -s %4096 u-boot.bin
+
+2. Run your board and interrupt booting to U-Boot console. In the console
+ call::
+
+ => run do_force_flash_os
+
+3. Wait for few seconds, it will prepare environment variable and runs
+ DFU. Run DFU command from the host system::
+
+ $ dfu-util -v -d 8087:0a99 --alt u-boot0 -D u-boot.bin
+
+4. Return to U-Boot console and following hint. i.e. push Ctrl+C, and
+ reset the board::
+
+ => reset
+
+Updating U-Boot using xFSTK
+---------------------------
+
+You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
+One way to do that is to follow the `xFSTK`_ instructions. In short, after you
+install all necessary dependencies and clone repository, it will look like this:
+
+.. code-block:: sh
+
+ cd xFSTK
+ export DISTRIBUTION_NAME=ubuntu20.04
+ export BUILD_VERSION=1.8.5
+ git checkout v$BUILD_VERSION
+ ...
+
+Once you have built it, you can copy xfstk-dldr-solo to /usr/local/bin and
+libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
+it will work. You might find this `drive`_ helpful.
+
+If it does, then you can download and unpack the Edison recovery image,
+install dfu-util, reset your board and flash U-Boot like this:
+
+.. code-block:: sh
+
+ xfstk-dldr-solo --gpflags 0x80000007 \
+ --osimage u-boot-edison.img \
+ --fwdnx recover/edison_dnx_fwr.bin \
+ --fwimage recover/edison_ifwi-dbg-00.bin \
+ --osdnx recover/edison_dnx_osr.bin
+
+This should show the following
+
+.. code-block:: none
+
+ XFSTK Downloader Solo 1.8.5
+ Copyright (c) 2015 Intel Corporation
+ Build date and time: Aug 15 2020 15:07:13
+
+ .Intel SoC Device Detection Found
+ Parsing Commandline....
+ Registering Status Callback....
+ .Initiating Download Process....
+ .......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1
+ .......(even more dots)......................
+
+You have about 10 seconds after resetting the board to type the above command.
+If you want to check if the board is ready, type:
+
+.. code-block:: none
+
+ lsusb | egrep "8087|8086"
+ Bus 001 Device 004: ID 8086:e005 Intel Corp.
+
+If you see a device with the same ID as above, the board is waiting for your
+command.
+
+After about 5 seconds you should see some console output from the board:
+
+.. code-block:: none
+
+ ******************************
+ PSH KERNEL VERSION: b0182b2b
+ WR: 20104000
+ ******************************
+
+ SCU IPC: 0x800000d0 0xfffce92c
+
+ PSH miaHOB version: TNG.B0.VVBD.0000000c
+
+ microkernel built 11:24:08 Feb 5 2015
+
+ ******* PSH loader *******
+ PCM page cache size = 192 KB
+ Cache Constraint = 0 Pages
+ Arming IPC driver ..
+ Adding page store pool ..
+ PagestoreAddr(IMR Start Address) = 0x04899000
+ pageStoreSize(IMR Size) = 0x00080000
+
+ *** Ready to receive application ***
+
+After another 10 seconds the xFSTK tool completes and the board resets. About
+10 seconds after that should see the above message again and then within a few
+seconds U-Boot should start on your board:
+
+.. code-block:: none
+
+ U-Boot 2020.10-rc3 (Sep 03 2020 - 18:44:28 -0600)
+
+ CPU: Genuine Intel(R) CPU 4000 @ 500MHz
+ DRAM: 980.6 MiB
+ WDT: Started with servicing (60s timeout)
+ MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1
+ Loading Environment from MMC... OK
+ In: serial
+ Out: serial
+ Err: serial
+ Saving Environment to MMC... Writing to redundant MMC(0)... OK
+ Saving Environment to MMC... Writing to MMC(0)... OK
+ Net: No ethernet found.
+ Hit any key to stop autoboot: 0
+ Target:blank
+ Partitioning using GPT
+ Writing GPT: success!
+ Saving Environment to MMC... Writing to redundant MMC(0)... OK
+ Flashing already done...
+ 5442816 bytes read in 238 ms (21.8 MiB/s)
+ Valid Boot Flag
+ Setup Size = 0x00003c00
+ Magic signature found
+ Using boot protocol version 2.0c
+ Linux kernel version 3.10.17-poky-edison+ (ferry@kalamata) #1 SMP PREEMPT Mon Jan 11 14:54:18 CET 2016
+ Building boot_params at 0x00090000
+ Loading bzImage at address 100000 (5427456 bytes)
+ Magic signature found
+ Kernel command line: "rootwait ..."
+ Magic signature found
+
+ Starting kernel ...
+
+ ...
+
+ Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2
+
+ edison login:
+
+.. _xFSTK: https://github.com/edison-fw/xFSTK
+.. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
diff --git a/roms/u-boot/doc/board/intel/galileo.rst b/roms/u-boot/doc/board/intel/galileo.rst
new file mode 100644
index 000000000..f51a06bb9
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/galileo.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Galileo
+=======
+
+Only one binary blob is needed for Remote Management Unit (RMU) within Intel
+Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is
+needed by the Quark SoC itself.
+
+You can get the binary blob from Quark Board Support Package from Intel website:
+
+ * ./QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode/RMU.bin
+
+Rename the file and put it to the board directory by::
+
+ $ cp RMU.bin board/intel/galileo/rmu.bin
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make galileo_defconfig
+ $ make all
diff --git a/roms/u-boot/doc/board/intel/index.rst b/roms/u-boot/doc/board/intel/index.rst
new file mode 100644
index 000000000..f545dee87
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Intel
+=====
+
+.. toctree::
+ :maxdepth: 2
+
+ bayleybay
+ cherryhill
+ cougarcanyon2
+ crownbay
+ edison
+ galileo
+ minnowmax
+ slimbootloader
diff --git a/roms/u-boot/doc/board/intel/minnowmax.rst b/roms/u-boot/doc/board/intel/minnowmax.rst
new file mode 100644
index 000000000..028121735
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/minnowmax.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Minnowboard MAX
+===============
+
+This uses as FSP as with Crown Bay, except it is for the Atom E3800 series.
+Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at
+the time of writing). Put it in the corresponding board directory and rename
+it to fsp.bin.
+
+Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same
+board directory as vga.bin.
+
+You still need two more binary blobs. For Minnowboard MAX, we can reuse the
+same ME firmware above, but for flash descriptor, we need get that somewhere
+else, as the one above does not seem to work, probably because it is not
+designed for the Minnowboard MAX. Now download the original firmware image
+for this board from:
+
+ * http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip
+
+Unzip it::
+
+ $ unzip 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip
+
+Use ifdtool in the U-Boot tools directory to extract the images from that
+file, for example::
+
+ $ ./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
+
+This will provide the descriptor file - copy this into the correct place::
+
+ $ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin
+
+Now you can build U-Boot and obtain u-boot.rom::
+
+ $ make minnowmax_defconfig
+ $ make all
+
+Checksums are as follows (but note that newer versions will invalidate this)::
+
+ $ md5sum -b board/intel/minnowmax/*.bin
+ ffda9a3b94df5b74323afb328d51e6b4 board/intel/minnowmax/descriptor.bin
+ 69f65b9a580246291d20d08cbef9d7c5 board/intel/minnowmax/fsp.bin
+ 894a97d371544ec21de9c3e8e1716c4b board/intel/minnowmax/me.bin
+ a2588537da387da592a27219d56e9962 board/intel/minnowmax/vga.bin
+
+The ROM image is broken up into these parts:
+
+====== ================== ============================
+Offset Description Controlling config
+====== ================== ============================
+000000 descriptor.bin Hard-coded to 0 in ifdtool
+001000 me.bin Set by the descriptor
+500000 <spare>
+6ef000 Environment CONFIG_ENV_OFFSET
+6f0000 MRC cache CONFIG_ENABLE_MRC_CACHE
+700000 u-boot-dtb.bin CONFIG_SYS_TEXT_BASE
+7b0000 vga.bin CONFIG_VGA_BIOS_ADDR
+7c0000 fsp.bin CONFIG_FSP_ADDR
+7f8000 <spare> (depends on size of fsp.bin)
+7ff800 U-Boot 16-bit boot CONFIG_SYS_X86_START16
+====== ================== ============================
+
+Overall ROM image size is controlled by CONFIG_ROM_SIZE.
+
+Note that the debug version of the FSP is bigger in size. If this version
+is used, CONFIG_FSP_ADDR needs to be configured to 0xfffb0000 instead of
+the default value 0xfffc0000.
diff --git a/roms/u-boot/doc/board/intel/slimbootloader.rst b/roms/u-boot/doc/board/intel/slimbootloader.rst
new file mode 100644
index 000000000..18f1cc056
--- /dev/null
+++ b/roms/u-boot/doc/board/intel/slimbootloader.rst
@@ -0,0 +1,177 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Aiden Park <aiden.park@intel.com>
+
+Slim Bootloader
+===============
+
+Introduction
+------------
+
+This target is to enable U-Boot_ as a payload of `Slim Bootloader`_ (a.k.a SBL)
+boot firmware which currently supports QEMU, Apollolake, Whiskeylake,
+Coffeelake-R platforms.
+
+The `Slim Bootloader`_ is designed with multi-stages (Stage1A/B, Stage2, Payload)
+architecture to cover from reset vector to OS booting and it consumes
+`Intel FSP`_ for silicon initialization.
+
+* Stage1A: Reset vector, CAR init with FSP-T
+* Stage1B: Memory init with FSP-M, CAR teardown, Continue execution in memory
+* Stage2 : Rest of Silicon init with FSP-S, Create HOB, Hand-off to Payload
+* Payload: Payload init with HOB, Load OS from media, Booting OS
+
+The Slim Bootloader stages (Stage1A/B, Stage2) focus on chipset, hardware and
+platform specific initialization, and it provides useful information to a
+payload in a HOB (Hand-Off Block) which has serial port, memory map, performance
+data info and so on. This is Slim Bootloader architectural design to make a
+payload light-weight, platform independent and more generic across different
+boot solutions or payloads, and to minimize hardware re-initialization in a
+payload.
+
+Build Instruction for U-Boot as a Slim Bootloader payload
+---------------------------------------------------------
+
+Build U-Boot and obtain u-boot-dtb.bin::
+
+ $ make distclean
+ $ make slimbootloader_defconfig
+ $ make all
+
+Prepare Slim Bootloader
+-----------------------
+
+1. Setup Build Environment for Slim Bootloader.
+
+ Refer to `Getting Started`_ page in `Slim Bootloader`_ document site.
+
+2. Get source code. Let's simply clone the repo::
+
+ $ git clone https://github.com/slimbootloader/slimbootloader.git
+
+3. Copy u-boot-dtb.bin to Slim Bootloader.
+ Slim Bootloader looks for a payload from the specific location.
+ Copy the build u-boot-dtb.bin to the expected location::
+
+ $ mkdir -p <Slim Bootloader Dir>/PayloadPkg/PayloadBins/
+ $ cp <U-Boot Dir>/u-boot-dtb.bin <Slim Bootloader Dir>/PayloadPkg/PayloadBins/u-boot-dtb.bin
+
+Build Instruction for Slim Bootloader for QEMU target
+-----------------------------------------------------
+
+Slim Bootloader supports multiple payloads, and a board of Slim Bootloader
+detects its target payload by PayloadId in board configuration.
+The PayloadId can be any 4 Bytes value.
+
+1. Update PayloadId. Let's use 'U-BT' as an example::
+
+ $ vi Platform/QemuBoardPkg/CfgData/CfgDataExt_Brd1.dlt
+ -GEN_CFG_DATA.PayloadId | 'AUTO'
+ +GEN_CFG_DATA.PayloadId | 'U-BT'
+
+2. Update payload text base. PAYLOAD_EXE_BASE must be the same as U-Boot
+ CONFIG_SYS_TEXT_BASE in board/intel/slimbootloader/Kconfig.
+ PAYLOAD_LOAD_HIGH must be 0::
+
+ $ vi Platform/QemuBoardPkg/BoardConfig.py
+ + self.PAYLOAD_LOAD_HIGH = 0
+ + self.PAYLOAD_EXE_BASE = 0x00100000
+
+3. Build QEMU target. Make sure u-boot-dtb.bin and U-BT PayloadId
+ in build command. The output is Outputs/qemu/SlimBootloader.bin::
+
+ $ python BuildLoader.py build qemu -p "OsLoader.efi:LLDR:Lz4;u-boot-dtb.bin:U-BT:Lzma"
+
+4. Launch Slim Bootloader on QEMU.
+ You should reach at U-Boot serial console::
+
+ $ qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash Outputs/qemu/SlimBootloader.bin
+
+Test Linux booting on QEMU target
+---------------------------------
+
+Let's use LeafHill (APL) Yocto image for testing.
+Download it from http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/machines/leafhill/.
+
+1. Prepare Yocto hard disk image::
+
+ $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/machines/leafhill/leafhill-4.0-jethro-2.0.tar.bz2
+ $ tar -xvf leafhill-4.0-jethro-2.0.tar.bz2
+ $ ls -l leafhill-4.0-jethro-2.0/binary/core-image-sato-intel-corei7-64.hddimg
+
+2. Launch Slim Bootloader on QEMU with disk image::
+
+ $ qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash Outputs/qemu/SlimBootloader.bin -drive id=mydrive,if=none,file=/path/to/core-image-sato-intel-corei7-64.hddimg,format=raw -device ide-hd,drive=mydrive
+
+3. Update boot environment values on shell::
+
+ => setenv bootfile vmlinuz
+ => setenv bootdev scsi
+ => boot
+
+Build Instruction for Slim Bootloader for LeafHill (APL) target
+---------------------------------------------------------------
+
+Prepare U-Boot and Slim Bootloader as described at the beginning of this page.
+Also, the PayloadId needs to be set for APL board.
+
+1. Update PayloadId. Let's use 'U-BT' as an example::
+
+ $ vi Platform/ApollolakeBoardPkg/CfgData/CfgData_Int_LeafHill.dlt
+ -GEN_CFG_DATA.PayloadId | 'AUTO
+ +GEN_CFG_DATA.PayloadId | 'U-BT'
+
+2. Update payload text base.
+
+* PAYLOAD_EXE_BASE must be the same as U-Boot CONFIG_SYS_TEXT_BASE
+ in board/intel/slimbootloader/Kconfig.
+* PAYLOAD_LOAD_HIGH must be 0::
+
+ $ vi Platform/ApollolakeBoardPkg/BoardConfig.py
+ + self.PAYLOAD_LOAD_HIGH = 0
+ + self.PAYLOAD_EXE_BASE = 0x00100000
+
+3. Build APL target. Make sure u-boot-dtb.bin and U-BT PayloadId
+ in build command. The output is Outputs/apl/Stitch_Components.zip::
+
+ $ python BuildLoader.py build apl -p "OsLoader.efi:LLDR:Lz4;u-boot-dtb.bin:U-BT:Lzma"
+
+4. Stitch IFWI.
+
+ Refer to Apollolake_ page in Slim Bootloader document site::
+
+ $ python Platform/ApollolakeBoardPkg/Script/StitchLoader.py -i <Existing IFWI> -s Outputs/apl/Stitch_Components.zip -o <Output IFWI>
+
+5. Flash IFWI.
+
+ Use DediProg to flash IFWI. You should reach at U-Boot serial console.
+
+
+Build Instruction to use ELF U-Boot
+-----------------------------------
+
+1. Enable CONFIG_OF_EMBED::
+
+ $ vi configs/slimbootloader_defconfig
+ +CONFIG_OF_EMBED=y
+
+2. Build U-Boot::
+
+ $ make distclean
+ $ make slimbootloader_defconfig
+ $ make all
+ $ strip u-boot (removing symbol for reduced size)
+
+3. Do same steps as above
+
+* Copy u-boot (ELF) to PayloadBins directory
+* Update PayloadId 'U-BT' as above.
+* No need to set PAYLOAD_LOAD_HIGH and PAYLOAD_EXE_BASE.
+* Build Slim Bootloader. Use u-boot instead of u-boot-dtb.bin::
+
+ $ python BuildLoader.py build <qemu or apl> -p "OsLoader.efi:LLDR:Lz4;u-boot:U-BT:Lzma"
+
+.. _U-Boot: https://source.denx.de/
+.. _`Slim Bootloader`: https://github.com/slimbootloader/
+.. _`Intel FSP`: https://github.com/IntelFsp/
+.. _`Getting Started`: https://slimbootloader.github.io/getting-started/
+.. _Apollolake: https://slimbootloader.github.io/supported-hardware/apollo-lake-crb.html#stitching
diff --git a/roms/u-boot/doc/board/kontron/index.rst b/roms/u-boot/doc/board/kontron/index.rst
new file mode 100644
index 000000000..543b22e2f
--- /dev/null
+++ b/roms/u-boot/doc/board/kontron/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Kontron
+=======
+
+.. toctree::
+ :maxdepth: 2
+
+ sl28
diff --git a/roms/u-boot/doc/board/kontron/sl28.rst b/roms/u-boot/doc/board/kontron/sl28.rst
new file mode 100644
index 000000000..e458fbc60
--- /dev/null
+++ b/roms/u-boot/doc/board/kontron/sl28.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Summary
+=======
+
+The Kontron SMARC-sAL28 board is a TSN-enabled dual-core ARM A72
+processor module with an on-chip 6-port TSN switch and a 3D GPU.
+
+
+Quickstart
+==========
+
+Compile U-Boot
+--------------
+
+Configure and compile the binary::
+
+ $ make kontron_sl28_defconfig
+ $ CROSS_COMPILE=aarch64-linux-gnu make
+
+Copy u-boot.rom to a TFTP server.
+
+Install the bootloader on the board
+-----------------------------------
+
+Please note, this bootloader doesn't support the builtin watchdog (yet),
+therefore you have to disable it, see below. Otherwise you'll end up in
+the failsafe bootloader on every reset::
+
+ > tftp path/to/u-boot.rom
+ > sf probe 0
+ > sf update $fileaddr 0x210000 $filesize
+
+The board is fully failsafe, you can't break anything. But because you've
+disabled the builtin watchdog you might have to manually enter failsafe
+mode by asserting the ``FORCE_RECOV#`` line during board reset.
+
+Disable the builtin watchdog
+----------------------------
+
+- boot into the failsafe bootloader, either by asserting the
+ ``FORCE_RECOV#`` line or if you still have the original bootloader
+ installed you can use the command::
+
+ > wdt dev cpld_watchdog@4a; wdt expire 1
+
+- in the failsafe bootloader use the "sl28 nvm" command to disable
+ the automatic start of the builtin watchdog::
+
+ > sl28 nvm 0008
+
+- power-cycle the board
+
+
+Useful I2C tricks
+=================
+
+The board has a board management controller which is not supported in
+u-boot (yet). But you can use the i2c command to access it.
+
+- reset into failsafe bootloader::
+
+ > i2c mw 4a 5.1 0; i2c mw 4a 6.1 6b; i2c mw 4a 4.1 42
+
+- read board management controller version::
+
+ > i2c md 4a 3.1 1
+
+
+Non-volatile Board Configuration Bits
+=====================================
+
+The board has 16 configuration bits which are stored in the CPLD and are
+non-volatile. These can be changed by the `sl28 nvm` command.
+
+=== ===============================================================
+Bit Description
+=== ===============================================================
+ 0 Power-on inhibit
+ 1 Enable eMMC boot
+ 2 Enable watchdog by default
+ 3 Disable failsafe watchdog by default
+ 4 Clock generator selection bit 0
+ 5 Clock generator selection bit 1
+ 6 Disable CPU SerDes clock #2 and PCIe-A clock output
+ 7 Disable PCIe-B and PCIe-C clock output
+ 8 Keep onboard PHYs in reset
+ 9 Keep USB hub in reset
+ 10 Keep eDP-to-LVDS converter in reset
+ 11 Enable I2C stuck recovery on I2C PM and I2C GP busses
+ 12 Enable automatic onboard PHY H/W reset
+ 13 reserved
+ 14 Used by the RCW to determine boot source
+ 15 Used by the RCW to determine boot source
+=== ===============================================================
+
+Please note, that if the board is in failsafe mode, the bits will have the
+factory defaults, ie. all bits are off.
+
+Power-On Inhibit
+----------------
+
+If this is set, the board doesn't automatically turn on when power is
+applied. Instead, the user has to either toggle the ``PWR_BTN#`` line or
+use any other wake-up source such as RTC alarm or Wake-on-LAN.
+
+eMMC Boot
+---------
+
+If this is set, the RCW will be fetched from the on-board eMMC at offset
+1MiB. For further details, have a look at the `Reset Configuration Word
+Documentation`_.
+
+Watchdog
+--------
+
+By default, the CPLD watchdog is enabled in failsafe mode. Using bits 2 and
+3, the user can change its mode or disable it altogether.
+
+===== ===== ===============================
+Bit 2 Bit 3 Description
+===== ===== ===============================
+ 0 0 Watchdog enabled, failsafe mode
+ 0 1 Watchdog disabled
+ 1 0 Watchdog enabled, failsafe mode
+ 1 1 Watchdog enabled, normal mode
+===== ===== ===============================
+
+Clock Generator Select
+----------------------
+
+The board is prepared to supply different SerDes clock speeds. But for now,
+only setting 0 is supported, otherwise the CPU will hang because the PLL
+will not lock.
+
+Clock Output Disable And Keep Devices In Reset
+----------------------------------------------
+
+To safe power, the user might disable different devices and clock output of
+the board. It is not supported to disable the "CPU SerDes clock #2" for
+now, otherwise the CPU will hang because the PLL will not lock.
+
+Automatic reset of the onboard PHYs
+-----------------------------------
+
+By default, there is no hardware reset of the onboard PHY. This is because
+for Wake-on-LAN, some registers have to retain their values. If you don't
+use the WOL feature and a soft reset of the PHY is not enough you can
+enable the hardware reset. The onboard PHY hardware reset follows the
+power-on reset.
+
+
+Further documentation
+=====================
+
+- `Vendor Documentation`_
+- `Reset Configuration Word Documentation`_
+
+.. _Reset Configuration Word Documentation: https://raw.githubusercontent.com/kontron/rcw-smarc-sal28/master/README.md
+.. _Vendor Documentation: https://raw.githubusercontent.com/kontron/u-boot-smarc-sal28/master/board/kontron/sl28/README.md
diff --git a/roms/u-boot/doc/board/microchip/index.rst b/roms/u-boot/doc/board/microchip/index.rst
new file mode 100644
index 000000000..affc5a9e0
--- /dev/null
+++ b/roms/u-boot/doc/board/microchip/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Microchip
+=========
+
+.. toctree::
+ :maxdepth: 2
+
+ mpfs_icicle
diff --git a/roms/u-boot/doc/board/microchip/mpfs_icicle.rst b/roms/u-boot/doc/board/microchip/mpfs_icicle.rst
new file mode 100644
index 000000000..c71c2f3ca
--- /dev/null
+++ b/roms/u-boot/doc/board/microchip/mpfs_icicle.rst
@@ -0,0 +1,825 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Microchip PolarFire SoC Icicle Kit
+==================================
+
+RISC-V PolarFire SoC
+--------------------
+
+The PolarFire SoC is the 4+1 64-bit RISC-V SoC from Microchip.
+
+The Icicle Kit development platform is based on PolarFire SoC and capable
+of running Linux.
+
+Mainline support
+----------------
+
+The support for following drivers are already enabled:
+
+1. NS16550 UART Driver.
+2. Microchip Clock Driver.
+3. Cadence MACB ethernet driver for networking support.
+4. Cadence MMC Driver for eMMC/SD support.
+
+Booting from eMMC using HSS
+---------------------------
+
+Building U-Boot
+~~~~~~~~~~~~~~~
+
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation environment variable:
+
+.. code-block:: none
+
+ export CROSS_COMPILE=<riscv64 toolchain prefix>
+
+3. make microchip_mpfs_icicle_defconfig
+4. make
+
+Flashing
+~~~~~~~~
+
+The current U-Boot port is supported in S-mode only and loaded from DRAM.
+
+A prior stage M-mode firmware/bootloader (e.g HSS with OpenSBI) is required to
+boot the u-boot.bin in S-mode.
+
+Currently, the u-boot.bin is used as a payload of the HSS firmware (Microchip
+boot-flow) and OpenSBI generic platform fw_payload.bin (with u-boot.bin embedded)
+as HSS payload (Custom boot-flow)
+
+Microchip boot-flow
+~~~~~~~~~~~~~~~~~~~
+
+HSS with OpenSBI (M-Mode) -> U-Boot (S-Mode) -> Linux (S-Mode)
+
+Build the HSS (Hart Software Services) - Microchip boot-flow
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+(Note: HSS git repo is at https://github.com/polarfire-soc/hart-software-services)
+
+1. Configure
+
+.. code-block:: none
+
+ make BOARD=icicle-kit-es config
+
+Alternatively, copy the default config for Microchip boot-flow.
+
+.. code-block:: none
+
+ cp boards/icicle-kit-es/def_config .config
+
+2. make BOARD=icicle-kit-es
+3. In the Default subdirectory, the standard build will create hss.elf and
+ various binary formats (hss.hex and hss.bin).
+
+The FPGA design will use the hss.hex or hss.bin.
+
+FPGA design with HSS programming file
+'''''''''''''''''''''''''''''''''''''
+
+https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md
+
+The HSS firmware runs from the PolarFire SoC eNVM on reset.
+
+Creating the HSS payload - Microchip boot-flow
+''''''''''''''''''''''''''''''''''''''''''''''
+
+1. You will be creating a payload from `u-boot-dtb.bin`.
+ Copy this file to the HSS/tools/hss-payload-generator/test directory.
+2. Go to hss-payload-generator source directory.
+
+.. code-block:: none
+
+ cd hart-software-services/tools/hss-payload-generator
+
+3. Edit test/uboot.yaml file for hart entry points and correct name of the binary file.
+
+ hart-entry-points: {u54_1: '0x80200000', u54_2: '0x80200000', u54_3: '0x80200000', u54_4: '0x80200000'}
+
+ payloads:
+ test/u-boot-dtb.bin: {exec-addr: '0x80200000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_s}
+
+4. Generate payload
+
+.. code-block:: none
+
+ ./hss-payload-generator -c test/uboot.yaml payload.bin
+
+Once the payload binary is generated, it should be copied to the eMMC.
+
+Please refer to HSS documenation to build the HSS firmware for payload.
+(Note: HSS git repo is at https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md)
+
+Custom boot-flow
+~~~~~~~~~~~~~~~~
+
+HSS without OpenSBI (M-Mode) -> OpenSBI (M-Mode) -> U-Boot (S-Mode) -> Linux (S-Mode)
+
+Build OpenSBI
+'''''''''''''
+
+1. Get the OpenSBI source
+
+.. code-block:: none
+
+ git clone https://github.com/riscv/opensbi.git
+ cd opensbi
+
+2. Build
+
+.. code-block:: none
+
+ make PLATFORM=generic FW_PAYLOAD_PATH=<u-boot-directory>/u-boot.bin
+ FW_FDT_PATH=<u-boot-directory>/arch/riscv/dts/microchip-mpfs-icicle-kit-.dtb
+
+3. Output "fw_payload.bin" file available at
+ "<opensbi-directory>/build/platform/generic/firmware/fw_payload.bin"
+
+Build the HSS (Hart Software Services)- Custom boot-flow
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+(Note: HSS git repo is at https://github.com/polarfire-soc/hart-software-services)
+
+1. Configure
+
+.. code-block:: none
+
+ make BOARD=icicle-kit-es config
+
+Alternatively, copy the default custom config for Custom boot-flow.
+
+.. code-block:: none
+
+ cp boards/icicle-kit-es/def_config_custom .config
+
+2. make BOARD=icicle-kit-es
+3. In the Default subdirectory, the standard build will create hss.elf and
+ various binary formats (hss.hex and hss.bin).
+
+The FPGA design will use the hss.hex or hss.bin.
+
+Creating the HSS payload - Custom boot-flow
+'''''''''''''''''''''''''''''''''''''''''''
+
+1. You will be creating a payload from `fw_payload.bin`.
+ Copy this file to the HSS/tools/hss-payload-generator/test directory.
+2. Go to hss-payload-generator source directory.
+
+.. code-block:: none
+
+ cd hart-software-services/tools/hss-payload-generator
+
+3. Edit test/uboot.yaml file for hart entry points and correct name of the binary file.
+
+ hart-entry-points: {u54_1: '0x80000000', u54_2: '0x80000000', u54_3: '0x80000000', u54_4: '0x80000000'}
+
+ payloads:
+ test/fw_payload.bin: {exec-addr: '0x80000000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_m}
+
+4. Generate payload
+
+.. code-block:: none
+
+ ./hss-payload-generator -c test/uboot.yaml payload.bin
+
+Once the payload binary is generated, it should be copied to the eMMC.
+
+Please refer to HSS documenation to build the HSS firmware for payload.
+(Note: HSS git repo is at https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md
+and also refer the HSS payload generator at https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/software-development/hss-payloads.md)
+
+eMMC
+~~~~
+
+Program eMMC with payload binary is explained in the PolarFire SoC documentation.
+(Note: PolarFire SoC Documentation git repo is at https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md#eMMC)
+
+Once the payload image is copied to the eMMC, press CTRL+C in the HSS command
+line interface, then type 'boot' and enter to boot the newly copied image.
+
+.. code-block:: none
+
+ sudo dd if=<payload_binary> of=/dev/sdX bs=512
+
+GUID type
+~~~~~~~~~
+
+The HSS always picks up HSS payload from a GPT partition with
+GIUD type "21686148-6449-6E6F-744E-656564454649" or sector '0' of the eMMC if no
+GPT partition.
+
+Booting
+~~~~~~~
+
+You should see the U-Boot prompt on UART0.
+
+Sample boot log from MPFS Icicle Kit
+''''''''''''''''''''''''''''''''''''
+
+.. code-block:: none
+
+ U-Boot 2021.01-00314-g7303332537-dirty (Jan 14 2021 - 10:09:43 +0530)
+
+ CPU: rv64imafdc
+ Model: Microchip MPFS Icicle Kit
+ DRAM: 1 GiB
+ MMC: sdhc@20008000: 0
+ In: serial@20100000
+ Out: serial@20100000
+ Err: serial@20100000
+ Net: eth0: ethernet@20112000
+ Hit any key to stop autoboot: 0
+
+Now you can configure your networking, tftp server and use tftp boot method to
+load uImage (with initramfs).
+
+.. code-block:: none
+
+ RISC-V # setenv kernel_addr_r 0x80200000
+ RISC-V # setenv fdt_addr_r 0x82200000
+
+ RISC-V # setenv ipaddr 192.168.1.5
+ RISC-V # setenv netmask 255.255.255.0
+ RISC-V # setenv serverip 192.168.1.3
+ RISC-V # setenv gateway 192.168.1.1
+
+ RISC-V # tftpboot ${kernel_addr_r} uImage
+ ethernet@20112000: PHY present at 9
+ ethernet@20112000: Starting autonegotiation...
+ ethernet@20112000: Autonegotiation complete
+ ethernet@20112000: link up, 1000Mbps full-duplex (lpa: 0x7800)
+ Using ethernet@20112000 device
+ TFTP from server 192.168.1.3; our IP address is 192.168.1.5
+ Filename 'uImage'.
+ Load address: 0x80200000
+ Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ############
+ 6.4 MiB/s
+ done
+ Bytes transferred = 14482480 (dcfc30 hex)
+
+ RISC-V # tftpboot ${fdt_addr_r} microchip-mpfs-icicle-kit.dtb
+ ethernet@20112000: PHY present at 9
+ ethernet@20112000: Starting autonegotiation...
+ ethernet@20112000: Autonegotiation complete
+ ethernet@20112000: link up, 1000Mbps full-duplex (lpa: 0x7800)
+ Using ethernet@20112000 device
+ TFTP from server 192.168.1.3; our IP address is 192.168.1.5
+ Filename 'microchip-mpfs-icicle-kit.dtb'.
+ Load address: 0x82200000
+ Loading: #
+ 2.5 MiB/s
+ done
+ Bytes transferred = 10282 (282a hex)
+
+ RISC-V # bootm ${kernel_addr_r} - ${fdt_addr_r}
+ ## Booting kernel from Legacy Image at 80200000 ...
+ Image Name: Linux
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 14482416 Bytes = 13.8 MiB
+ Load Address: 80200000
+ Entry Point: 80200000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 82200000
+ Booting using the fdt blob at 0x82200000
+ Loading Kernel Image
+ Using Device Tree in place at 000000008fffa000, end 000000008ffff829 ... OK
+
+ Starting kernel ...
+
+ [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
+ [ 0.000000] Linux version 5.6.17 (padmarao@padmarao-VirtualBox) (gcc version 7.2.0 (GCC)) #2 SMP Tue Jun 16 21:27:50 IST 2020
+ [ 0.000000] initrd not found or empty - disabling initrd
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] Normal empty
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] software IO TLB: mapped [mem 0xbb1f5000-0xbf1f5000] (64MB)
+ [ 0.000000] elf_hwcap is 0x112d
+ [ 0.000000] percpu: Embedded 14 pages/cpu s24856 r0 d32488 u57344
+ [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 258055
+ [ 0.000000] Kernel command line: console=ttyS0,115200n8
+ [ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+ [ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+ [ 0.000000] Memory: 950308K/1046528K available (3289K kernel code, 212K rwdata, 900K rodata, 9476K init, 250K bss, 96220K reserved, 0K cma-reserved)
+ [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+ [ 0.000000] rcu: Hierarchical RCU implementation.
+ [ 0.000000] rcu: RCU event tracing is enabled.
+ [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
+ [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+ [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+ [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
+ [ 0.000000] plic: mapped 186 interrupts with 4 handlers for 9 contexts.
+ [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [1]
+ [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
+ [ 0.000015] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
+ [ 0.000311] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000)
+ [ 0.000349] pid_max: default: 32768 minimum: 301
+ [ 0.000846] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+ [ 0.000964] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+ [ 0.005630] rcu: Hierarchical SRCU implementation.
+ [ 0.006901] smp: Bringing up secondary CPUs ...
+ [ 0.012545] smp: Brought up 1 node, 4 CPUs
+ [ 0.014431] devtmpfs: initialized
+ [ 0.020526] random: get_random_bytes called from setup_net+0x36/0x192 with crng_init=0
+ [ 0.020928] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+ [ 0.020999] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
+ [ 0.022768] NET: Registered protocol family 16
+ [ 0.035478] microchip-pfsoc-clkcfg 20002000.clkcfg: Registered PFSOC core clocks
+ [ 0.048429] SCSI subsystem initialized
+ [ 0.049694] pps_core: LinuxPPS API ver. 1 registered
+ [ 0.049719] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+ [ 0.049780] PTP clock support registered
+ [ 0.051781] clocksource: Switched to clocksource riscv_clocksource
+ [ 0.055326] NET: Registered protocol family 2
+ [ 0.056922] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
+ [ 0.057053] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
+ [ 0.057648] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
+ [ 0.058579] TCP: Hash tables configured (established 8192 bind 8192)
+ [ 0.059648] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
+ [ 0.059837] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
+ [ 0.060707] NET: Registered protocol family 1
+ [ 0.266229] workingset: timestamp_bits=62 max_order=18 bucket_order=0
+ [ 0.287107] io scheduler mq-deadline registered
+ [ 0.287140] io scheduler kyber registered
+ [ 0.429601] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ [ 0.433979] printk: console [ttyS0] disabled
+ [ 0.434154] 20000000.serial: ttyS0 at MMIO 0x20000000 (irq = 18, base_baud = 9375000) is a 16550A
+ [ 0.928039] printk: console [ttyS0] enabled
+ [ 0.939804] libphy: Fixed MDIO Bus: probed
+ [ 0.948702] libphy: MACB_mii_bus: probed
+ [ 0.993698] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 21 (56:34:12:00:fc:00)
+ [ 1.006751] mousedev: PS/2 mouse device common for all mice
+ [ 1.013803] i2c /dev entries driver
+ [ 1.019451] sdhci: Secure Digital Host Controller Interface driver
+ [ 1.027242] sdhci: Copyright(c) Pierre Ossman
+ [ 1.032731] sdhci-pltfm: SDHCI platform and OF driver helper
+ [ 1.091826] mmc0: SDHCI controller on 20008000.sdhc [20008000.sdhc] using ADMA 64-bit
+ [ 1.102738] NET: Registered protocol family 17
+ [ 1.170326] Freeing unused kernel memory: 9476K
+ [ 1.176067] This architecture does not have kernel memory protection.
+ [ 1.184157] Run /init as init process
+ Starting logging: OK
+ Starting mdev...
+ /etc/init.d/S10mdev: line 21: can't create /proc/sys/kernel/hotplug: nonexiste[ 1.331981] mmc0: mmc_select_hs200 failed, error -74
+ nt directory
+ [ 1.355011] mmc0: new MMC card at address 0001
+ [ 1.363981] mmcblk0: mmc0:0001 DG4008 7.28 GiB
+ [ 1.372248] mmcblk0boot0: mmc0:0001 DG4008 partition 1 4.00 MiB
+ [ 1.382292] mmcblk0boot1: mmc0:0001 DG4008 partition 2 4.00 MiB
+ [ 1.390265] mmcblk0rpmb: mmc0:0001 DG4008 partition 3 4.00 MiB, chardev (251:0)
+ [ 1.425234] GPT:Primary header thinks Alt. header is not at the end of the disk.
+ [ 1.434656] GPT:2255809 != 15273599
+ [ 1.439038] GPT:Alternate GPT header not at the end of the disk.
+ [ 1.446671] GPT:2255809 != 15273599
+ [ 1.451048] GPT: Use GNU Parted to correct GPT errors.
+ [ 1.457755] mmcblk0: p1 p2 p3
+ sort: /sys/devices/platform/Fixed: No such file or directory
+ modprobe: can't change directory to '/lib/modules': No such file or directory
+ Initializing random number generator... [ 2.830198] random: dd: uninitialized urandom read (512 bytes read)
+ done.
+ Starting network...
+ [ 3.061867] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
+ [ 3.074674] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
+ [ 3.084263] pps pps0: new PPS source ptp0
+ [ 3.089710] macb 20112000.ethernet: gem-ptp-timer ptp clock registered.
+ udhcpc (v1.24.2) started
+ Sending discover...
+ Sending discover...
+ [ 6.380169] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx
+ Sending discover...
+ Sending select for 192.168.1.2...
+ Lease of 192.168.1.2 obtained, lease time 86400
+ deleting routers
+ adding dns 192.168.1.1
+ Starting dropbear sshd: [ 11.385619] random: dropbear: uninitialized urandom read (32 bytes read)
+ OK
+
+ Welcome to Buildroot
+ buildroot login: root
+ Password:
+ #
+
+Booting U-Boot and Linux from eMMC
+----------------------------------
+
+FPGA design with HSS programming file and Linux Image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md
+
+The HSS firmware runs from the PolarFire SoC eNVM on reset.
+
+eMMC
+~~~~
+
+Program eMMC with payload binary and Linux image is explained in the
+PolarFire SoC documentation.
+The payload binary should be copied to partition 2 of the eMMC.
+
+(Note: PolarFire SoC Documentation git repo is at https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md#eMMC)
+
+Once the Linux image and payload binary is copied to the eMMC, press CTRL+C
+in the HSS command line interface, then type 'boot' and enter to boot the newly
+copied payload and Linux image.
+
+.. code-block:: none
+
+ zcat <linux-image>.wic.gz | sudo dd of=/dev/sdX bs=4096 iflag=fullblock oflag=direct conv=fsync status=progress
+
+ sudo dd if=<payload_binary> of=/dev/sdX2 bs=512
+
+You should see the U-Boot prompt on UART0.
+
+GUID type
+~~~~~~~~~
+
+The HSS always picks up the HSS payload from a GPT partition with
+GIUD type "21686148-6449-6E6F-744E-656564454649" or sector '0' of the eMMC if no
+GPT partition.
+
+Sample boot log from MPFS Icicle Kit
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: none
+
+ U-Boot 2021.01-00314-g7303332537-dirty (Jan 14 2021 - 10:09:43 +0530)
+
+ CPU: rv64imafdc
+ Model: Microchip MPFS Icicle Kit
+ DRAM: 1 GiB
+ MMC: sdhc@20008000: 0
+ In: serial@20100000
+ Out: serial@20100000
+ Err: serial@20100000
+ Net: eth0: ethernet@20112000
+ Hit any key to stop autoboot: 0
+
+ RISC-V # mmc info
+ Device: sdhc@20008000
+ Manufacturer ID: 45
+ OEM: 100
+ Name: DG400
+ Bus Speed: 52000000
+ Mode: MMC High Speed (52MHz)
+ Rd Block Len: 512
+ MMC version 5.1
+ High Capacity: Yes
+ Capacity: 7.3 GiB
+ Bus Width: 4-bit
+ Erase Group Size: 512 KiB
+ HC WP Group Size: 8 MiB
+ User Capacity: 7.3 GiB WRREL
+ Boot Capacity: 4 MiB ENH
+ RPMB Capacity: 4 MiB ENH
+
+ RISC-V # mmc part
+ Partition Map for MMC device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00002000 0x0000b031 "boot"
+ attrs: 0x0000000000000004
+ type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
+ guid: 99ff6a94-f2e7-44dd-a7df-f3a2da106ef9
+ 2 0x0000b032 0x0000f031 "primary"
+ attrs: 0x0000000000000000
+ type: 21686148-6449-6e6f-744e-656564454649
+ guid: 12006052-e64b-4423-beb0-b956ea00f1ba
+ 3 0x00010000 0x00226b9f "root"
+ attrs: 0x0000000000000000
+ type: 0fc63daf-8483-4772-8e79-3d69d8477de4
+ guid: dd2c5619-2272-4c3c-8dc2-e21942e17ce6
+
+ RISC-V # load mmc 0 ${ramdisk_addr_r} fitimage
+ RISC-V # bootm ${ramdisk_addr_r}
+ ## Loading kernel from FIT Image at 88300000 ...
+ Using 'conf@microchip_icicle-kit-es-a000-microchip.dtb' configuration
+ Trying 'kernel@1' kernel subimage
+ Description: Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x883000fc
+ Data Size: 3574555 Bytes = 3.4 MiB
+ Architecture: RISC-V
+ OS: Linux
+ Load Address: 0x80200000
+ Entry Point: 0x80200000
+ Hash algo: sha256
+ Hash value: 21f18d72cf2f0a7192220abb577ad25c77c26960052d779aa02bf55dbf0a6403
+ Verifying Hash Integrity ... sha256+ OK
+ ## Loading fdt from FIT Image at 88300000 ...
+ Using 'conf@microchip_icicle-kit-es-a000-microchip.dtb' configuration
+ Trying 'fdt@microchip_icicle-kit-es-a000-microchip.dtb' fdt subimage
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x88668d44
+ Data Size: 9760 Bytes = 9.5 KiB
+ Architecture: RISC-V
+ Load Address: 0x82200000
+ Hash algo: sha256
+ Hash value: 5c3a9f30d41b6b8e53b47916e1f339b3a4d454006554d1f7e1f552ed62409f4b
+ Verifying Hash Integrity ... sha256+ OK
+ Loading fdt from 0x88668d48 to 0x82200000
+ Booting using the fdt blob at 0x82200000
+ Uncompressing Kernel Image
+ Loading Device Tree to 000000008fffa000, end 000000008ffff61f ... OK
+
+ Starting kernel ...
+
+ [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
+ [ 0.000000] Linux version 5.6.16 (oe-user@oe-host) (gcc version 9.3.0 (GCC)) #1 SMP Fri Oct 9 11:49:47 UTC 2020
+ [ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
+ [ 0.000000] printk: bootconsole [sbi0] enabled
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] Normal empty
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] Zeroed struct page in unavailable ranges: 512 pages
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
+ [ 0.000000] software IO TLB: mapped [mem 0xb9e00000-0xbde00000] (64MB)
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] elf_hwcap is 0x112d
+ [ 0.000000] percpu: Embedded 17 pages/cpu s29784 r8192 d31656 u69632
+ [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 258055
+ [ 0.000000] Kernel command line: earlycon=sbi root=/dev/mmcblk0p3 rootwait console=ttyS0,115200n8 uio_pdrv_genirq.of_id=generic-uio
+ [ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+ [ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+ [ 0.000000] Memory: 941440K/1046528K available (4118K kernel code, 280K rwdata, 1687K rodata, 169K init, 273K bss, 105088K reserved, 0K cma-reserved)
+ [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+ [ 0.000000] rcu: Hierarchical RCU implementation.
+ [ 0.000000] rcu: RCU event tracing is enabled.
+ [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=5 to nr_cpu_ids=4.
+ [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+ [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+ [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
+ [ 0.000000] plic: mapped 53 interrupts with 4 handlers for 9 contexts.
+ [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [1]
+ [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
+ [ 0.000015] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
+ [ 0.008679] Console: colour dummy device 80x25
+ [ 0.013112] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000)
+ [ 0.023368] pid_max: default: 32768 minimum: 301
+ [ 0.028314] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+ [ 0.035766] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+ [ 0.047099] rcu: Hierarchical SRCU implementation.
+ [ 0.052813] smp: Bringing up secondary CPUs ...
+ [ 0.061581] smp: Brought up 1 node, 4 CPUs
+ [ 0.067069] devtmpfs: initialized
+ [ 0.073621] random: get_random_u32 called from bucket_table_alloc.isra.0+0x4e/0x150 with crng_init=0
+ [ 0.074409] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+ [ 0.093399] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
+ [ 0.101879] NET: Registered protocol family 16
+ [ 0.110336] microchip-pfsoc-clkcfg 20002000.clkcfg: Registered PFSOC core clocks
+ [ 0.132717] usbcore: registered new interface driver usbfs
+ [ 0.138225] usbcore: registered new interface driver hub
+ [ 0.143813] usbcore: registered new device driver usb
+ [ 0.148939] pps_core: LinuxPPS API ver. 1 registered
+ [ 0.153929] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+ [ 0.163071] PTP clock support registered
+ [ 0.168521] clocksource: Switched to clocksource riscv_clocksource
+ [ 0.174927] VFS: Disk quotas dquot_6.6.0
+ [ 0.179016] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
+ [ 0.205536] NET: Registered protocol family 2
+ [ 0.210944] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
+ [ 0.219393] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
+ [ 0.227497] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
+ [ 0.235440] TCP: Hash tables configured (established 8192 bind 8192)
+ [ 0.242537] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
+ [ 0.249285] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
+ [ 0.256690] NET: Registered protocol family 1
+ [ 0.262585] workingset: timestamp_bits=62 max_order=18 bucket_order=0
+ [ 0.281036] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
+ [ 0.288481] io scheduler mq-deadline registered
+ [ 0.292983] io scheduler kyber registered
+ [ 0.298895] microsemi,mss-gpio 20122000.gpio: Microsemi MSS GPIO registered 32 GPIOs
+ [ 0.453723] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ [ 0.462911] printk: console [ttyS0] disabled
+ [ 0.467216] 20100000.serial: ttyS0 at MMIO 0x20100000 (irq = 12, base_baud = 9375000) is a 16550A
+ [ 0.476201] printk: console [ttyS0] enabled
+ [ 0.476201] printk: console [ttyS0] enabled
+ [ 0.484576] printk: bootconsole [sbi0] disabled
+ [ 0.484576] printk: bootconsole [sbi0] disabled
+ [ 0.494920] 20102000.serial: ttyS1 at MMIO 0x20102000 (irq = 13, base_baud = 9375000) is a 16550A
+ [ 0.505068] 20104000.serial: ttyS2 at MMIO 0x20104000 (irq = 14, base_baud = 9375000) is a 16550A
+ [ 0.533336] loop: module loaded
+ [ 0.572284] Rounding down aligned max_sectors from 4294967295 to 4294967288
+ [ 0.580000] db_root: cannot open: /etc/target
+ [ 0.585413] libphy: Fixed MDIO Bus: probed
+ [ 0.591526] libphy: MACB_mii_bus: probed
+ [ 0.598060] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (56:34:12:00:fc:00)
+ [ 0.608352] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ [ 0.615001] ehci-platform: EHCI generic platform driver
+ [ 0.620446] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+ [ 0.626632] ohci-platform: OHCI generic platform driver
+ [ 0.632326] usbcore: registered new interface driver cdc_acm
+ [ 0.637996] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
+ [ 0.646459] i2c /dev entries driver
+ [ 0.650852] microsemi-mss-i2c 2010b000.i2c: Microsemi I2C Probe Complete
+ [ 0.658010] sdhci: Secure Digital Host Controller Interface driver
+ [ 0.664326] sdhci: Copyright(c) Pierre Ossman
+ [ 0.668754] sdhci-pltfm: SDHCI platform and OF driver helper
+ [ 0.706845] mmc0: SDHCI controller on 20008000.sdhc [20008000.sdhc] using ADMA 64-bit
+ [ 0.715052] usbcore: registered new interface driver usbhid
+ [ 0.720722] usbhid: USB HID core driver
+ [ 0.725174] pac193x 0-0010: Chip revision: 0x03
+ [ 0.733339] pac193x 0-0010: :pac193x_prep_iio_channels: Channel 0 active
+ [ 0.740127] pac193x 0-0010: :pac193x_prep_iio_channels: Channel 1 active
+ [ 0.746881] pac193x 0-0010: :pac193x_prep_iio_channels: Channel 2 active
+ [ 0.753686] pac193x 0-0010: :pac193x_prep_iio_channels: Channel 3 active
+ [ 0.760495] pac193x 0-0010: :pac193x_prep_iio_channels: Active chip channels: 25
+ [ 0.778006] NET: Registered protocol family 10
+ [ 0.784929] Segment Routing with IPv6
+ [ 0.788875] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+ [ 0.795743] NET: Registered protocol family 17
+ [ 0.801191] hctosys: unable to open rtc device (rtc0)
+ [ 0.807774] Waiting for root device /dev/mmcblk0p3...
+ [ 0.858506] mmc0: mmc_select_hs200 failed, error -74
+ [ 0.865764] mmc0: new MMC card at address 0001
+ [ 0.872564] mmcblk0: mmc0:0001 DG4008 7.28 GiB
+ [ 0.878777] mmcblk0boot0: mmc0:0001 DG4008 partition 1 4.00 MiB
+ [ 0.886182] mmcblk0boot1: mmc0:0001 DG4008 partition 2 4.00 MiB
+ [ 0.892633] mmcblk0rpmb: mmc0:0001 DG4008 partition 3 4.00 MiB, chardev (247:0)
+ [ 0.919029] GPT:Primary header thinks Alt. header is not at the end of the disk.
+ [ 0.926448] GPT:2255841 != 15273599
+ [ 0.930019] GPT:Alternate GPT header not at the end of the disk.
+ [ 0.936029] GPT:2255841 != 15273599
+ [ 0.939583] GPT: Use GNU Parted to correct GPT errors.
+ [ 0.944800] mmcblk0: p1 p2 p3
+ [ 0.966696] EXT4-fs (mmcblk0p3): INFO: recovery required on readonly filesystem
+ [ 0.974105] EXT4-fs (mmcblk0p3): write access will be enabled during recovery
+ [ 1.052362] random: fast init done
+ [ 1.057961] EXT4-fs (mmcblk0p3): recovery complete
+ [ 1.065734] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
+ [ 1.074002] VFS: Mounted root (ext4 filesystem) readonly on device 179:3.
+ [ 1.081654] Freeing unused kernel memory: 168K
+ [ 1.086108] This architecture does not have kernel memory protection.
+ [ 1.092629] Run /sbin/init as init process
+ [ 1.702217] systemd[1]: System time before build time, advancing clock.
+ [ 1.754192] systemd[1]: systemd 244.3+ running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=hybrid)
+ [ 1.776361] systemd[1]: Detected architecture riscv64.
+
+ Welcome to OpenEmbedded nodistro.0!
+
+ [ 1.829651] systemd[1]: Set hostname to <icicle-kit-es>.
+ [ 2.648597] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 2.657485] systemd[1]: Created slice system-getty.slice.
+ [ OK ] Created slice system-getty.slice.
+ [ 2.698779] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 2.706317] systemd[1]: Created slice system-serial\x2dgetty.slice.
+ [ OK ] Created slice system-serial\x2dgetty.slice.
+ [ 2.748716] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 2.756098] systemd[1]: Created slice User and Session Slice.
+ [ OK ] Created slice User and Session Slice.
+ [ 2.789065] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
+ [ OK ] Started Dispatch Password …ts to Console Directory Watch.
+ [ 2.828974] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
+ [ OK ] Started Forward Password R…uests to Wall Directory Watch.
+ [ 2.869009] systemd[1]: Reached target Paths.
+ [ OK ] Reached target Paths.
+ [ 2.898808] systemd[1]: Reached target Remote File Systems.
+ [ OK ] Reached target Remote File Systems.
+ [ 2.938771] systemd[1]: Reached target Slices.
+ [ OK ] Reached target Slices.
+ [ 2.968754] systemd[1]: Reached target Swap.
+ [ OK ] Reached target Swap.
+ [ 2.999283] systemd[1]: Listening on initctl Compatibility Named Pipe.
+ [ OK ] Listening on initctl Compatibility Named Pipe.
+ [ 3.060458] systemd[1]: Condition check resulted in Journal Audit Socket being skipped.
+ [ 3.069826] systemd[1]: Listening on Journal Socket (/dev/log).
+ [ OK ] Listening on Journal Socket (/dev/log).
+ [ 3.109601] systemd[1]: Listening on Journal Socket.
+ [ OK ] Listening on Journal Socket.
+ [ 3.149868] systemd[1]: Listening on Network Service Netlink Socket.
+ [ OK ] Listening on Network Service Netlink Socket.
+ [ 3.189419] systemd[1]: Listening on udev Control Socket.
+ [ OK ] Listening on udev Control Socket.
+ [ 3.229179] systemd[1]: Listening on udev Kernel Socket.
+ [ OK ] Listening on udev Kernel Socket.
+ [ 3.269520] systemd[1]: Condition check resulted in Huge Pages File System being skipped.
+ [ 3.278477] systemd[1]: Condition check resulted in POSIX Message Queue File System being skipped.
+ [ 3.288200] systemd[1]: Condition check resulted in Kernel Debug File System being skipped.
+ [ 3.302570] systemd[1]: Mounting Temporary Directory (/tmp)...
+ Mounting Temporary Directory (/tmp)...
+ [ 3.339226] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped.
+ [ 3.355883] systemd[1]: Starting File System Check on Root Device...
+ Starting File System Check on Root Device...
+ [ 3.407220] systemd[1]: Starting Journal Service...
+ Starting Journal Service...
+ [ 3.422441] systemd[1]: Condition check resulted in Load Kernel Modules being skipped.
+ [ 3.431770] systemd[1]: Condition check resulted in FUSE Control File System being skipped.
+ [ 3.446415] systemd[1]: Mounting Kernel Configuration File System...
+ Mounting Kernel Configuration File System...
+ [ 3.458983] systemd[1]: Starting Apply Kernel Variables...
+ Starting Apply Kernel Variables...
+ [ 3.471368] systemd[1]: Starting udev Coldplug all Devices...
+ Starting udev Coldplug all Devices...
+ [ 3.491071] systemd[1]: Mounted Temporary Directory (/tmp).
+ [ OK 3.498114] systemd[1]: Mounted Kernel Configuration File System.
+ 0m] Mounted Temporary Directory (/tmp).
+ [ OK ] Mounted Kernel Configuration File System.
+ [ 3.550853] systemd[1]: Started Apply Kernel Variables.
+ [ OK 3.557535] systemd[1]: Started Journal Service.
+ 0m] Started Apply Kernel Variables.
+ [ OK ] Started Journal Service.
+ [ OK ] Started udev Coldplug all Devices.
+ [ OK ] Started File System Check on Root Device.
+ Starting Remount Root and Kernel File Systems...
+ [ 8.133469] EXT4-fs (mmcblk0p3): re-mounted. Opts: (null)
+ [ OK ] Started Remount Root and Kernel File Systems.
+ Starting Flush Journal to Persistent Storage...
+ [ 8.215327] systemd-journald[77]: Received client request to flush runtime journal.
+ Starting Create Static Device Nodes in /dev...
+ [ OK ] Started Flush Journal to Persistent Storage.
+ [ OK ] Started Create Static Device Nodes in /dev.
+ [ OK ] Reached target Local File Systems (Pre).
+ Mounting /var/volatile...
+ Starting udev Kernel Device Manager...
+ [ OK ] Mounted /var/volatile.
+ Starting Load/Save Random Seed...
+ [ OK ] Reached target Local File Systems.
+ Starting Create Volatile Files and Directories...
+ [ OK ] Started udev Kernel Device Manager.
+ [ OK ] Started Create Volatile Files and Directories.
+ Starting Network Time Synchronization...
+ Starting Update UTMP about System Boot/Shutdown...
+ [ OK ] Started Update UTMP about System Boot/Shutdown.
+ [ OK ] Started Network Time Synchronization.
+ [ 11.618575] random: crng init done
+ [ 11.622007] random: 7 urandom warning(s) missed due to ratelimiting
+ [ OK ] Started Load/Save Random Seed.
+ [ OK ] Reached target System Initialization.
+ [ OK ] Started Daily Cleanup of Temporary Directories.
+ [ OK ] Reached target System Time Set.
+ [ OK ] Reached target System Time Synchronized.
+ [ OK ] Reached target Timers.
+ [ OK ] Listening on D-Bus System Message Bus Socket.
+ [ OK ] Listening on dropbear.socket.
+ [ OK ] Reached target Sockets.
+ [ OK ] Reached target Basic System.
+ [ OK ] Started D-Bus System Message Bus.
+ Starting IPv6 Packet Filtering Framework...
+ Starting IPv4 Packet Filtering Framework...
+ Starting Login Service...
+ [ OK ] Started IPv6 Packet Filtering Framework.
+ [ OK ] Started IPv4 Packet Filtering Framework.
+ [ OK ] Reached target Network (Pre).
+ Starting Network Service...
+ [ OK ] Started Login Service.
+ [ 12.602455] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
+ [ 12.612795] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
+ [ 12.622153] pps pps0: new PPS source ptp0
+ [ OK 12.626725] macb 20112000.ethernet: gem-ptp-timer ptp clock registered.
+ 0m] Started Network Service.
+ Starting Network Name Resolution...
+ [ OK ] Started Network Name Resolution.
+ [ OK ] Reached target Network.
+ [ OK ] Reached target Host and Network Name Lookups.
+ [ OK ] Started Collectd.
+ [ OK ] Started Collectd.
+ Starting Permit User Sessions...
+ [ OK ] Started Permit User Sessions.
+ [ OK ] Started Getty on tty1.
+ [ OK ] Started Serial Getty on ttyS0.
+ [ OK ] Reached target Login Prompts.
+ [ OK ] Reached target Multi-User System.
+ Starting Update UTMP about System Runlevel Changes...
+ [ OK ] Started Update UTMP about System Runlevel Changes.
+
+ OpenEmbedded nodistro.0 icicle-kit-es ttyS0
+
+ icicle-kit-es login: [ 15.795564] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx
+ [ 15.803306] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
+
+ icicle-kit-es login: root
+ root@icicle-kit-es:~#
diff --git a/roms/u-boot/doc/board/rockchip/index.rst b/roms/u-boot/doc/board/rockchip/index.rst
new file mode 100644
index 000000000..0c377e9bb
--- /dev/null
+++ b/roms/u-boot/doc/board/rockchip/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+
+Rockchip
+========
+
+.. toctree::
+ :maxdepth: 2
+
+ rockchip
diff --git a/roms/u-boot/doc/board/rockchip/rockchip.rst b/roms/u-boot/doc/board/rockchip/rockchip.rst
new file mode 100644
index 000000000..fbb998398
--- /dev/null
+++ b/roms/u-boot/doc/board/rockchip/rockchip.rst
@@ -0,0 +1,238 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+
+ROCKCHIP
+========
+
+About this
+----------
+
+This document describes the information about Rockchip supported boards
+and it's usage steps.
+
+Rockchip boards
+---------------
+
+Rockchip is SoC solutions provider for tablets & PCs, streaming media
+TV boxes, AI audio & vision, IoT hardware.
+
+A wide range of Rockchip SoCs with associated boardsare supported in
+mainline U-Boot.
+
+List of mainline supported rockchip boards:
+
+* rk3036
+ - Rockchip Evb-RK3036 (evb-rk3036)
+ - Kylin (kylin_rk3036)
+* rk3128
+ - Rockchip Evb-RK3128 (evb-rk3128)
+* rk3229
+ - Rockchip Evb-RK3229 (evb-rk3229)
+* rk3288
+ - Rockchip Evb-RK3288 (evb-rk3288)
+ - Firefly-RK3288 (firefly-rk3288)
+ - MQmaker MiQi (miqi-rk3288)
+ - Phytec RK3288 PCM-947 (phycore-rk3288)
+ - PopMetal-RK3288 (popmetal-rk3288)
+ - Radxa Rock 2 Square (rock2)
+ - Tinker-RK3288 (tinker-rk3288)
+ - Google Jerry (chromebook_jerry)
+ - Google Mickey (chromebook_mickey)
+ - Google Minnie (chromebook_minnie)
+ - Google Speedy (chromebook_speedy)
+ - Amarula Vyasa-RK3288 (vyasa-rk3288)
+* rk3308
+ - Rockchip Evb-RK3308 (evb-rk3308)
+ - Roc-cc-RK3308 (roc-cc-rk3308)
+* rk3328
+ - Rockchip Evb-RK3328 (evb-rk3328)
+ - Pine64 Rock64 (rock64-rk3328)
+ - Firefly-RK3328 (roc-cc-rk3328)
+ - Radxa Rockpi E (rock-pi-e-rk3328)
+* rk3368
+ - GeekBox (geekbox)
+ - PX5 EVB (evb-px5)
+ - Rockchip Sheep (sheep-rk3368)
+ - Theobroma Systems RK3368-uQ7 SoM - Lion (lion-rk3368)
+* rk3399
+ - 96boards RK3399 Ficus (ficus-rk3399)
+ - 96boards Rock960 (rock960-rk3399)
+ - Firefly-RK3399 (firefly_rk3399)
+ - Firefly ROC-RK3399-PC
+ - FriendlyElec NanoPC-T4 (nanopc-t4-rk3399)
+ - FriendlyElec NanoPi M4 (nanopi-m4-rk3399)
+ - FriendlyElec NanoPi M4B (nanopi-m4b-rk3399)
+ - FriendlyARM NanoPi NEO4 (nanopi-neo4-rk3399)
+ - Google Bob (chromebook_bob)
+ - Khadas Edge (khadas-edge-rk3399)
+ - Khadas Edge-Captain (khadas-edge-captain-rk3399)
+ - Khadas Edge-V (hadas-edge-v-rk3399)
+ - Orange Pi RK3399 (orangepi-rk3399)
+ - Pine64 RockPro64 (rockpro64-rk3399)
+ - Radxa ROCK Pi 4 (rock-pi-4-rk3399)
+ - Rockchip Evb-RK3399 (evb_rk3399)
+ - Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399)
+* rv1108
+ - Rockchip Evb-rv1108 (evb-rv1108)
+ - Elgin-R1 (elgin-rv1108)
+* rv3188
+ - Radxa Rock (rock)
+
+Building
+--------
+
+TF-A
+^^^^
+
+TF-A would require to build for ARM64 Rockchip SoCs platforms.
+
+To build TF-A::
+
+ git clone https://github.com/ARM-software/arm-trusted-firmware.git
+ cd arm-trusted-firmware
+ make realclean
+ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+Specify the PLAT= with desired rockchip platform to build TF-A for.
+
+U-Boot
+^^^^^^
+
+To build rk3328 boards::
+
+ export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+ make evb-rk3328_defconfig
+ make
+
+To build rk3288 boards::
+
+ make evb-rk3288_defconfig
+ make
+
+To build rk3368 boards::
+
+ export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+ make evb-px5_defconfig
+ make
+
+To build rk3399 boards::
+
+ export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+ make evb-rk3399_defconfig
+ make
+
+Flashing
+--------
+
+1. Package the image with U-Boot TPL/SPL
+-----------------------------------------
+
+SD Card
+^^^^^^^
+
+All rockchip platforms, except rk3128 (which doesn't use SPL) are now
+supporting single boot image using binman and pad_cat.
+
+To write an image that boots from an SD card (assumed to be /dev/sda)::
+
+ sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
+ sync
+
+eMMC
+^^^^
+
+eMMC flash would probe on mmc0 in most of the rockchip platforms.
+
+Create GPT partition layout as defined in configurations::
+
+ mmc dev 0
+ gpt write mmc 0 $partitions
+
+Connect the USB-OTG cable between host and target device.
+
+Launch fastboot at target::
+
+ fastboot 0
+
+Upon successful gadget connection,host show the USB device like::
+
+ lsusb
+ Bus 001 Device 020: ID 2207:330c Fuzhou Rockchip Electronics Company RK3399 in Mask ROM mode
+
+Program the flash::
+
+ sudo fastboot -i 0x2207 flash loader1 idbloader.img
+ sudo fastboot -i 0x2207 flash loader2 u-boot.itb
+
+Note: for rockchip 32-bit platforms the U-Boot proper image
+is u-boot-dtb.img
+
+SPI
+^^^
+
+Generating idbloader for SPI boot would require to input a multi image
+image format to mkimage tool instead of concerting (like for MMC boot).
+
+SPL-alone SPI boot image::
+
+ ./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
+
+TPL+SPL SPI boot image::
+
+ ./tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
+
+Copy SPI boot images into SD card and boot from SD::
+
+ sf probe
+ load mmc 1:1 $kernel_addr_r idbloader.img
+ sf erase 0 +$filesize
+ sf write $kernel_addr_r 0 ${filesize}
+ load mmc 1:1 ${kernel_addr_r} u-boot.itb
+ sf erase 0x60000 +$filesize
+ sf write $kernel_addr_r 0x60000 ${filesize}
+
+2. Package the image with Rockchip miniloader
+---------------------------------------------
+
+Image package with Rockchip miniloader requires robin [1].
+
+Create idbloader.img
+
+.. code-block:: none
+
+ cd u-boot
+ ./tools/mkimage -n px30 -T rksd -d rkbin/bin/rk33/px30_ddr_333MHz_v1.15.bin idbloader.img
+ cat rkbin/bin/rk33/px30_miniloader_v1.22.bin >> idbloader.img
+ sudo dd if=idbloader.img of=/dev/sda seek=64
+
+Create trust.img
+
+.. code-block:: none
+
+ cd rkbin
+ ./tools/trust_merger RKTRUST/PX30TRUST.ini
+ sudo dd if=trust.img of=/dev/sda seek=24576
+
+Create uboot.img
+
+.. code-block:: none
+
+ rbink/tools/loaderimage --pack --uboot u-boot-dtb.bin uboot.img 0x200000
+ sudo dd if=uboot.img of=/dev/sda seek=16384
+
+Note:
+1. 0x200000 is load address and it's an optional in some platforms.
+2. rkbin binaries are kept on updating, so would recommend to use the latest versions.
+
+TODO
+----
+
+- Add rockchip idbloader image building
+- Add rockchip TPL image building
+- Document SPI flash boot
+- Add missing SoC's with it boards list
+
+[1] https://github.com/rockchip-linux/rkbin
+
+.. Jagan Teki <jagan@amarulasolutions.com>
+.. Wednesday 28 October 2020 06:47:26 PM IST
diff --git a/roms/u-boot/doc/board/sifive/index.rst b/roms/u-boot/doc/board/sifive/index.rst
new file mode 100644
index 000000000..a43937a3e
--- /dev/null
+++ b/roms/u-boot/doc/board/sifive/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+SiFive
+======
+
+.. toctree::
+ :maxdepth: 2
+
+ unleashed
+ unmatched
diff --git a/roms/u-boot/doc/board/sifive/unleashed.rst b/roms/u-boot/doc/board/sifive/unleashed.rst
new file mode 100644
index 000000000..4e4c852ff
--- /dev/null
+++ b/roms/u-boot/doc/board/sifive/unleashed.rst
@@ -0,0 +1,579 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+HiFive Unleashed
+================
+
+FU540-C000 RISC-V SoC
+---------------------
+The FU540-C000 is the world’s first 4+1 64-bit RISC-V SoC from SiFive.
+
+The HiFive Unleashed development platform is based on FU540-C000 and capable
+of running Linux.
+
+Mainline support
+----------------
+
+The support for following drivers are already enabled:
+
+1. SiFive UART Driver.
+2. SiFive PRCI Driver for clock.
+3. Cadence MACB ethernet driver for networking support.
+4. SiFive SPI Driver.
+5. MMC SPI Driver for MMC/SD support.
+
+Booting from MMC using FSBL
+---------------------------
+
+Building
+~~~~~~~~
+
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation environment variable:
+
+.. code-block:: none
+
+ export CROSS_COMPILE=<riscv64 toolchain prefix>
+
+3. make sifive_fu540_defconfig
+4. make
+
+Flashing
+~~~~~~~~
+
+The current U-Boot port is supported in S-mode only and loaded from DRAM.
+
+A prior stage M-mode firmware/bootloader (e.g OpenSBI) is required to
+boot the u-boot.bin in S-mode and provide M-mode runtime services.
+
+Currently, the u-boot.bin is used as a payload of the OpenSBI FW_PAYLOAD
+firmware. We need to compile OpenSBI with below command:
+
+.. code-block:: none
+
+ make PLATFORM=generic FW_PAYLOAD_PATH=<path to u-boot-dtb.bin>
+
+More detailed description of steps required to build FW_PAYLOAD firmware
+is beyond the scope of this document. Please refer OpenSBI documenation.
+(Note: OpenSBI git repo is at https://github.com/riscv/opensbi.git)
+
+Once the prior stage firmware/bootloader binary is generated, it should be
+copied to the first partition of the sdcard.
+
+.. code-block:: none
+
+ sudo dd if=<prior_stage_firmware_binary> of=/dev/disk2s1 bs=1024
+
+Booting
+~~~~~~~
+
+Once you plugin the sdcard and power up, you should see the U-Boot prompt.
+
+Sample boot log from HiFive Unleashed board
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: none
+
+ U-Boot 2019.07-00024-g350ff02f5b (Jul 22 2019 - 11:45:02 +0530)
+
+ CPU: rv64imafdc
+ Model: SiFive HiFive Unleashed A00
+ DRAM: 8 GiB
+ MMC: spi@10050000:mmc@0: 0
+ In: serial@10010000
+ Out: serial@10010000
+ Err: serial@10010000
+ Net: eth0: ethernet@10090000
+ Hit any key to stop autoboot: 0
+ => version
+ U-Boot 2019.07-00024-g350ff02f5b (Jul 22 2019 - 11:45:02 +0530)
+
+ riscv64-linux-gcc.br_real (Buildroot 2018.11-rc2-00003-ga0787e9) 8.2.0
+ GNU ld (GNU Binutils) 2.31.1
+ => mmc info
+ Device: spi@10050000:mmc@0
+ Manufacturer ID: 3
+ OEM: 5344
+ Name: SU08G
+ Bus Speed: 20000000
+ Mode: SD Legacy
+ Rd Block Len: 512
+ SD version 2.0
+ High Capacity: Yes
+ Capacity: 7.4 GiB
+ Bus Width: 1-bit
+ Erase Group Size: 512 Bytes
+ => mmc part
+
+ Partition Map for MMC device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00000800 0x000107ff "bootloader"
+ attrs: 0x0000000000000000
+ type: 2e54b353-1271-4842-806f-e436d6af6985
+ guid: 393bbd36-7111-491c-9869-ce24008f6403
+ 2 0x00040800 0x00ecdfde ""
+ attrs: 0x0000000000000000
+ type: 0fc63daf-8483-4772-8e79-3d69d8477de4
+ guid: 7fc9a949-5480-48c7-b623-04923080757f
+
+Now you can configure your networking, tftp server and use tftp boot method to
+load uImage.
+
+.. code-block:: none
+
+ => setenv ipaddr 10.206.7.133
+ => setenv netmask 255.255.252.0
+ => setenv serverip 10.206.4.143
+ => setenv gateway 10.206.4.1
+
+If you want to use a flat kernel image such as Image file
+
+.. code-block:: none
+
+ => tftpboot ${kernel_addr_r} /sifive/fu540/Image
+ ethernet@10090000: PHY present at 0
+ ethernet@10090000: Starting autonegotiation...
+ ethernet@10090000: Autonegotiation complete
+ ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x3c00)
+ Using ethernet@10090000 device
+ TFTP from server 10.206.4.143; our IP address is 10.206.7.133
+ Filename '/sifive/fu540/Image'.
+ Load address: 0x84000000
+ Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ##########################################
+ 1.2 MiB/s
+ done
+ Bytes transferred = 8867100 (874d1c hex)
+
+Or if you want to use a compressed kernel image file such as Image.gz
+
+.. code-block:: none
+
+ => tftpboot ${kernel_addr_r} /sifive/fu540/Image.gz
+ ethernet@10090000: PHY present at 0
+ ethernet@10090000: Starting autonegotiation...
+ ethernet@10090000: Autonegotiation complete
+ ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x3c00)
+ Using ethernet@10090000 device
+ TFTP from server 10.206.4.143; our IP address is 10.206.7.133
+ Filename '/sifive/fu540/Image.gz'.
+ Load address: 0x84000000
+ Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ##########################################
+ 1.2 MiB/s
+ done
+ Bytes transferred = 4809458 (4962f2 hex)
+ =>setenv kernel_comp_addr_r 0x90000000
+ =>setenv kernel_comp_size 0x500000
+
+By this time, correct kernel image is loaded and required environment variables
+are set. You can proceed to load the ramdisk and device tree from the tftp server
+as well.
+
+.. code-block:: none
+
+ => tftpboot ${ramdisk_addr_r} /sifive/fu540/uRamdisk
+ ethernet@10090000: PHY present at 0
+ ethernet@10090000: Starting autonegotiation...
+ ethernet@10090000: Autonegotiation complete
+ ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x3c00)
+ Using ethernet@10090000 device
+ TFTP from server 10.206.4.143; our IP address is 10.206.7.133
+ Filename '/sifive/fu540/uRamdisk'.
+ Load address: 0x88300000
+ Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ##############
+ 418.9 KiB/s
+ done
+ Bytes transferred = 2398272 (249840 hex)
+ => tftpboot ${fdt_addr_r} /sifive/fu540/hifive-unleashed-a00.dtb
+ ethernet@10090000: PHY present at 0
+ ethernet@10090000: Starting autonegotiation...
+ ethernet@10090000: Autonegotiation complete
+ ethernet@10090000: link up, 1000Mbps full-duplex (lpa: 0x7c00)
+ Using ethernet@10090000 device
+ TFTP from server 10.206.4.143; our IP address is 10.206.7.133
+ Filename '/sifive/fu540/hifive-unleashed-a00.dtb'.
+ Load address: 0x88000000
+ Loading: ##
+ 1000 Bytes/s
+ done
+ Bytes transferred = 5614 (15ee hex)
+ => setenv bootargs "root=/dev/ram rw console=ttySIF0 ip=dhcp earlycon=sbi"
+ => booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
+ ## Loading init Ramdisk from Legacy Image at 88300000 ...
+ Image Name: Linux RootFS
+ Image Type: RISC-V Linux RAMDisk Image (uncompressed)
+ Data Size: 2398208 Bytes = 2.3 MiB
+ Load Address: 00000000
+ Entry Point: 00000000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 88000000
+ Booting using the fdt blob at 0x88000000
+ Using Device Tree in place at 0000000088000000, end 00000000880045ed
+
+ Starting kernel ...
+
+ [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
+ [ 0.000000] Linux version 5.3.0-rc1-00003-g460ac558152f (anup@anup-lab-machine) (gcc version 8.2.0 (Buildroot 2018.11-rc2-00003-ga0787e9)) #6 SMP Mon Jul 22 10:01:01 IST 2019
+ [ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
+ [ 0.000000] printk: bootconsole [sbi0] enabled
+ [ 0.000000] Initial ramdisk at: 0x(____ptrval____) (2398208 bytes)
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000ffffffff]
+ [ 0.000000] Normal [mem 0x0000000100000000-0x000000027fffffff]
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000080200000-0x000000027fffffff]
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000027fffffff]
+ [ 0.000000] software IO TLB: mapped [mem 0xfbfff000-0xfffff000] (64MB)
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] elf_hwcap is 0x112d
+ [ 0.000000] percpu: Embedded 18 pages/cpu s34584 r8192 d30952 u73728
+ [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2067975
+ [ 0.000000] Kernel command line: root=/dev/ram rw console=ttySIF0 ip=dhcp earlycon=sbi
+ [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
+ [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+ [ 0.000000] Memory: 8182308K/8386560K available (5916K kernel code, 368K rwdata, 1840K rodata, 213K init, 304K bss, 204252K reserved, 0K cma-reserved)
+ [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+ [ 0.000000] rcu: Hierarchical RCU implementation.
+ [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
+ [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+ [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+ [ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
+ [ 0.000000] plic: mapped 53 interrupts with 4 handlers for 9 contexts.
+ [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [1]
+ [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
+ [ 0.000006] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
+ [ 0.008559] Console: colour dummy device 80x25
+ [ 0.012989] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
+ [ 0.023104] pid_max: default: 32768 minimum: 301
+ [ 0.028273] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+ [ 0.035765] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+ [ 0.045307] rcu: Hierarchical SRCU implementation.
+ [ 0.049875] smp: Bringing up secondary CPUs ...
+ [ 0.055729] smp: Brought up 1 node, 4 CPUs
+ [ 0.060599] devtmpfs: initialized
+ [ 0.064819] random: get_random_u32 called from bucket_table_alloc.isra.10+0x4e/0x160 with crng_init=0
+ [ 0.073720] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+ [ 0.083176] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
+ [ 0.090721] NET: Registered protocol family 16
+ [ 0.106319] vgaarb: loaded
+ [ 0.108670] SCSI subsystem initialized
+ [ 0.112515] usbcore: registered new interface driver usbfs
+ [ 0.117758] usbcore: registered new interface driver hub
+ [ 0.123167] usbcore: registered new device driver usb
+ [ 0.128905] clocksource: Switched to clocksource riscv_clocksource
+ [ 0.141239] NET: Registered protocol family 2
+ [ 0.145506] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear)
+ [ 0.153754] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
+ [ 0.163466] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
+ [ 0.173468] TCP: Hash tables configured (established 65536 bind 65536)
+ [ 0.179739] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear)
+ [ 0.186627] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear)
+ [ 0.194117] NET: Registered protocol family 1
+ [ 0.198417] RPC: Registered named UNIX socket transport module.
+ [ 0.203887] RPC: Registered udp transport module.
+ [ 0.208664] RPC: Registered tcp transport module.
+ [ 0.213429] RPC: Registered tcp NFSv4.1 backchannel transport module.
+ [ 0.219944] PCI: CLS 0 bytes, default 64
+ [ 0.224170] Unpacking initramfs...
+ [ 0.262347] Freeing initrd memory: 2336K
+ [ 0.266531] workingset: timestamp_bits=62 max_order=21 bucket_order=0
+ [ 0.280406] NFS: Registering the id_resolver key type
+ [ 0.284798] Key type id_resolver registered
+ [ 0.289048] Key type id_legacy registered
+ [ 0.293114] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+ [ 0.300262] NET: Registered protocol family 38
+ [ 0.304432] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
+ [ 0.311862] io scheduler mq-deadline registered
+ [ 0.316461] io scheduler kyber registered
+ [ 0.356421] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ [ 0.363004] 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 4, base_baud = 0) is a SiFive UART v0
+ [ 0.371468] printk: console [ttySIF0] enabled
+ [ 0.371468] printk: console [ttySIF0] enabled
+ [ 0.380223] printk: bootconsole [sbi0] disabled
+ [ 0.380223] printk: bootconsole [sbi0] disabled
+ [ 0.389589] 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 1, base_baud = 0) is a SiFive UART v0
+ [ 0.398680] [drm] radeon kernel modesetting enabled.
+ [ 0.412395] loop: module loaded
+ [ 0.415214] sifive_spi 10040000.spi: mapped; irq=3, cs=1
+ [ 0.420628] sifive_spi 10050000.spi: mapped; irq=5, cs=1
+ [ 0.425897] libphy: Fixed MDIO Bus: probed
+ [ 0.429964] macb 10090000.ethernet: Registered clk switch 'sifive-gemgxl-mgmt'
+ [ 0.436743] macb: GEM doesn't support hardware ptp.
+ [ 0.441621] libphy: MACB_mii_bus: probed
+ [ 0.601316] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL)
+ [ 0.615857] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 6 (70:b3:d5:92:f2:f3)
+ [ 0.625634] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
+ [ 0.631381] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
+ [ 0.637382] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ [ 0.643799] ehci-pci: EHCI PCI platform driver
+ [ 0.648261] ehci-platform: EHCI generic platform driver
+ [ 0.653497] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+ [ 0.659599] ohci-pci: OHCI PCI platform driver
+ [ 0.664055] ohci-platform: OHCI generic platform driver
+ [ 0.669448] usbcore: registered new interface driver uas
+ [ 0.674575] usbcore: registered new interface driver usb-storage
+ [ 0.680642] mousedev: PS/2 mouse device common for all mice
+ [ 0.709493] mmc_spi spi1.0: SD/MMC host mmc0, no DMA, no WP, no poweroff, cd polling
+ [ 0.716615] usbcore: registered new interface driver usbhid
+ [ 0.722023] usbhid: USB HID core driver
+ [ 0.726738] NET: Registered protocol family 10
+ [ 0.731359] Segment Routing with IPv6
+ [ 0.734332] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+ [ 0.740687] NET: Registered protocol family 17
+ [ 0.744660] Key type dns_resolver registered
+ [ 0.806775] mmc0: host does not support reading read-only switch, assuming write-enable
+ [ 0.814020] mmc0: new SDHC card on SPI
+ [ 0.820137] mmcblk0: mmc0:0000 SU08G 7.40 GiB
+ [ 0.850220] mmcblk0: p1 p2
+ [ 3.821524] macb 10090000.ethernet eth0: link up (1000/Full)
+ [ 3.828938] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
+ [ 3.848919] Sending DHCP requests .., OK
+ [ 6.252076] IP-Config: Got DHCP answer from 10.206.4.1, my address is 10.206.7.133
+ [ 6.259624] IP-Config: Complete:
+ [ 6.262831] device=eth0, hwaddr=70:b3:d5:92:f2:f3, ipaddr=10.206.7.133, mask=255.255.252.0, gw=10.206.4.1
+ [ 6.272809] host=dhcp-10-206-7-133, domain=sdcorp.global.sandisk.com, nis-domain=(none)
+ [ 6.281228] bootserver=10.206.126.11, rootserver=10.206.126.11, rootpath=
+ [ 6.281232] nameserver0=10.86.1.1, nameserver1=10.86.2.1
+ [ 6.294179] ntpserver0=10.86.1.1, ntpserver1=10.86.2.1
+ [ 6.301026] Freeing unused kernel memory: 212K
+ [ 6.304683] This architecture does not have kernel memory protection.
+ [ 6.311121] Run /init as init process
+ _ _
+ | ||_|
+ | | _ ____ _ _ _ _
+ | || | _ \| | | |\ \/ /
+ | || | | | | |_| |/ \
+ |_||_|_| |_|\____|\_/\_/
+
+ Busybox Rootfs
+
+ Please press Enter to activate this console.
+ / #
+
+Booting from MMC using U-Boot SPL
+---------------------------------
+
+Building
+~~~~~~~~
+
+Before building U-Boot SPL, OpenSBI must be built first. OpenSBI can be
+cloned and built for FU540 as below:
+
+.. code-block:: console
+
+ git clone https://github.com/riscv/opensbi.git
+ cd opensbi
+ make PLATFORM=generic
+ export OPENSBI=<path to opensbi/build/platform/generic/firmware/fw_dynamic.bin>
+
+Now build the U-Boot SPL and U-Boot proper
+
+.. code-block:: console
+
+ cd <U-Boot-dir>
+ make sifive_fu540_defconfig
+ make
+
+This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
+
+
+Flashing
+~~~~~~~~
+
+ZSBL loads the U-Boot SPL (u-boot-spl.bin) from a partition with GUID type
+5B193300-FC78-40CD-8002-E86C45580B47
+
+U-Boot SPL expects a U-Boot FIT image (u-boot.itb) from a partition with GUID
+type 2E54B353-1271-4842-806F-E436D6AF6985
+
+FIT image (u-boot.itb) is a combination of fw_dynamic.bin, u-boot-nodtb.bin and
+device tree blob (hifive-unleashed-a00.dtb)
+
+Format the SD card (make sure the disk has GPT, otherwise use gdisk to switch)
+
+.. code-block:: none
+
+ # sudo sgdisk --clear \
+ > --set-alignment=2 \
+ > --new=1:34:2081 --change-name=1:loader1 --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+ > --new=2:2082:10273 --change-name=2:loader2 --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+ > --new=3:10274: --change-name=3:rootfs --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
+ > /dev/sda
+
+Program the SD card
+
+.. code-block:: none
+
+ sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
+ sudo dd if=u-boot.itb of=/dev/sda seek=2082
+
+Booting
+~~~~~~~
+
+Once you plugin the sdcard and power up, you should see the U-Boot prompt.
+
+Sample boot log from HiFive Unleashed board
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: none
+
+ U-Boot SPL 2020.04-rc2-00109-g63efc7e07e-dirty (Apr 30 2020 - 13:52:36 +0530)
+ Trying to boot from MMC1
+
+
+ U-Boot 2020.04-rc2-00109-g63efc7e07e-dirty (Apr 30 2020 - 13:52:36 +0530)
+
+ CPU: rv64imafdc
+ Model: SiFive HiFive Unleashed A00
+ DRAM: 8 GiB
+ MMC: spi@10050000:mmc@0: 0
+ In: serial@10010000
+ Out: serial@10010000
+ Err: serial@10010000
+ Net: eth0: ethernet@10090000
+ Hit any key to stop autoboot: 0
+ => version
+ U-Boot 2020.04-rc2-00109-g63efc7e07e-dirty (Apr 30 2020 - 13:52:36 +0530)
+
+ riscv64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0.37-3f461da) 9.2.0
+ GNU ld (crosstool-NG 1.24.0.37-3f461da) 2.32
+ => mmc info
+ Device: spi@10050000:mmc@0
+ Manufacturer ID: 3
+ OEM: 5344
+ Name: SC16G
+ Bus Speed: 20000000
+ Mode: SD Legacy
+ Rd Block Len: 512
+ SD version 2.0
+ High Capacity: Yes
+ Capacity: 14.8 GiB
+ Bus Width: 1-bit
+ Erase Group Size: 512 Bytes
+ => mmc part
+
+ Partition Map for MMC device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00000022 0x00000821 "loader1"
+ attrs: 0x0000000000000000
+ type: 5b193300-fc78-40cd-8002-e86c45580b47
+ guid: 66e2b5d2-74db-4df8-ad6f-694b3617f87f
+ 2 0x00000822 0x00002821 "loader2"
+ attrs: 0x0000000000000000
+ type: 2e54b353-1271-4842-806f-e436d6af6985
+ guid: 8befaeaf-bca0-435d-b002-e201f37c0a2f
+ 3 0x00002822 0x01dacbde "rootfs"
+ attrs: 0x0000000000000000
+ type: 0fc63daf-8483-4772-8e79-3d69d8477de4
+ type: linux
+ guid: 9faa81b6-39b1-4418-af5e-89c48f29c20d
+
+Booting from SPI
+----------------
+
+Use Building steps from "Booting from MMC using U-Boot SPL" section.
+
+Partition the SPI in Linux via mtdblock. (Require to boot the board in
+SD boot mode by enabling MTD block in Linux)
+
+Use prebuilt image from here [1], which support to partition the SPI flash.
+
+.. code-block:: none
+
+ # sgdisk --clear \
+ > --set-alignment=2 \
+ > --new=1:40:2087 --change-name=1:loader1 --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+ > --new=2:2088:10279 --change-name=2:loader2 --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+ > --new=3:10536:65494 --change-name=3:rootfs --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
+ > /dev/mtdblock0
+
+Program the SPI (Require to boot the board in SD boot mode)
+
+Execute below steps on U-Boot proper,
+
+.. code-block:: none
+
+ tftpboot $kernel_addr_r u-boot-spl.bin
+ sf erase 0x5000 $filesize
+ sf write $kernel_addr_r 0x5000 $filesize
+
+ tftpboot $kernel_addr_r u-boot.itb
+ sf erase 0x105000 $filesize
+ sf write $kernel_addr_r 0x105000 $filesize
+
+Power off the board
+
+Change DIP switches MSEL[3:0] are set to 0110
+
+Power up the board.
+
+[1] https://github.com/amarula/bsp-sifive
diff --git a/roms/u-boot/doc/board/sifive/unmatched.rst b/roms/u-boot/doc/board/sifive/unmatched.rst
new file mode 100644
index 000000000..e65b0d320
--- /dev/null
+++ b/roms/u-boot/doc/board/sifive/unmatched.rst
@@ -0,0 +1,536 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+HiFive Unmatched
+================
+
+FU740-C000 RISC-V SoC
+---------------------
+The FU740-C000 is a 4+1 64-bit RISC-V core SoC from SiFive.
+
+The HiFive Unmatched development platform is based on FU740-C000 and capable
+of running Linux.
+
+Mainline support
+----------------
+The support for following drivers are already enabled:
+
+1. SiFive UART Driver.
+2. SiFive PRCI Driver for clock.
+3. Cadence MACB ethernet driver for networking support.
+4. SiFive SPI Driver.
+5. MMC SPI Driver for MMC/SD support.
+
+Booting from uSD using U-Boot SPL
+---------------------------------
+
+Building
+--------
+
+Before building U-Boot SPL, OpenSBI must be built first. OpenSBI can be
+cloned and built for FU740 as below:
+
+.. code-block:: console
+
+ git clone https://github.com/riscv/opensbi.git
+ cd opensbi
+ make PLATFORM=generic
+ export OPENSBI=<path to opensbi/build/platform/generic/firmware/fw_dynamic.bin>
+
+Now build the U-Boot SPL and U-Boot proper
+
+.. code-block:: console
+
+ cd <U-Boot-dir>
+ make sifive_unmatched_defconfig
+ make
+
+This will generate spl/u-boot-spl.bin and u-boot.itb
+
+
+Flashing
+--------
+
+ZSBL loads the U-Boot SPL (u-boot-spl.bin) from a partition with GUID type
+5B193300-FC78-40CD-8002-E86C45580B47
+
+U-Boot SPL expects u-boot.itb from a partition with GUID
+type 2E54B353-1271-4842-806F-E436D6AF6985
+
+u-boot.itb is a combination of fw_dynamic.bin, u-boot-nodtb.bin and
+device tree blob (hifive-unmatched-a00.dtb)
+
+Format the SD card (make sure the disk has GPT, otherwise use gdisk to switch)
+
+.. code-block:: none
+
+ # sudo sgdisk -g --clear -a 1 \
+ > --new=1:34:2081 --change-name=1:spl --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+ > --new=2:2082:10273 --change-name=2:uboot --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+ > --new=3:16384:282623 --change-name=3:boot --typecode=3:0x0700 \
+ > --new=4:286720:13918207 --change-name=4:root --typecode=4:0x8300 \
+ > /dev/sdb
+
+Copy linux Image.gz and hifive-unmatched-a00.dtb to boot partition
+
+.. code-block:: none
+
+ sudo mkfs.vfat /dev/sdb3
+ sudo mkfs.ext4 /dev/sdb4
+
+ sudo mount /dev/sdb3 /media/sdb3
+ sudo cp Image.gz hifive-unmatched-a00.dtb /media/sdb3/
+
+Program the SD card
+
+.. code-block:: none
+
+ sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
+ sudo dd if=u-boot.itb of=/dev/sda seek=2082
+
+Booting
+-------
+Once you plugin the sdcard and power up, you should see the U-Boot prompt.
+
+
+Loading the kernel and dtb
+
+.. code-block:: none
+
+ fatload mmc 0:3 ${kernel_addr_r} Image.gz
+ fatload mmc 0:3 ${fdt_addr_r} hifive-unmatched-a00.dtb
+ booti ${kernel_addr_r} - ${fdt_addr_r}
+
+
+Sample boot log from HiFive Unmatched board
+-------------------------------------------
+
+.. code-block:: none
+
+ U-Boot SPL 2021.04-rc4-00009-g7d70643cc3-dirty (Mar 16 2021 - 18:03:14 +0800)
+ Trying to boot from MMC1
+
+ U-Boot 2021.04-rc4-00009-g7d70643cc3-dirty (Mar 16 2021 - 18:03:14 +0800)
+
+ CPU: rv64imafdc
+ Model: SiFive HiFive Unmatched A00
+ DRAM: 16 GiB
+ MMC: spi@10050000:mmc@0: 0
+ In: serial@10010000
+ Out: serial@10010000
+ Err: serial@10010000
+ Model: SiFive HiFive Unmatched A00
+ Net:
+ Error: ethernet@10090000 address not set.
+ No ethernet found.
+
+ Hit any key to stop autoboot: 0
+ PCIe Link up, Gen1
+
+ Device 0: Vendor: 0x126f Rev: S1111A0L Prod: AA000000000000001995
+ Type: Hard Disk
+ Capacity: 488386.3 MB = 476.9 GB (1000215216 x 512)
+ ... is now current device
+ Scanning nvme 0:1...
+ libfdt fdt_check_header(): FDT_ERR_BADMAGIC
+ Scanning disk mmc@0.blk...
+ ** Unrecognized filesystem type **
+ ** Unrecognized filesystem type **
+ Scanning disk nvme#0.blk#0...
+ Found 8 disks
+ No EFI system partition
+
+ Error: ethernet@10090000 address not set.
+ BootOrder not defined
+ EFI boot manager: Cannot load any image
+ starting USB...
+ Bus xhci_pci: Register 4000840 NbrPorts 4
+ Starting the controller
+ USB XHCI 1.00
+ scanning bus xhci_pci for devices... 3 USB Device(s) found
+ scanning usb for storage devices... 0 Storage Device(s) found
+
+ Device 0: unknown device
+ switch to partitions #0, OK
+ mmc0 is current device
+ Scanning mmc 0:3...
+ Found /extlinux/extlinux.conf
+ Retrieving file: /extlinux/extlinux.conf
+ 205 bytes read in 9 ms (21.5 KiB/s)
+ 1: OpenEmbedded-SiFive-HiFive-Unmatched
+ Retrieving file: /Image.gz
+ 7225919 bytes read in 4734 ms (1.5 MiB/s)
+ append: root=/dev/mmcblk0p4 rootfstype=ext4 rootwait console=ttySIF0,115200 earlycon=sbi
+ Retrieving file: /hifive-unmatched-a00.dtb
+ 10445 bytes read in 13 ms (784.2 KiB/s)
+ Uncompressing Kernel Image
+ Moving Image from 0x84000000 to 0x80200000, end=81629000
+ ## Flattened Device Tree blob at 88000000
+ Booting using the fdt blob at 0x88000000
+ Using Device Tree in place at 0000000088000000, end 00000000880058cc
+
+ Starting kernel ...
+
+ [ 0.000000] Linux version 5.10.15 (oe-user@oe-host) (riscv64-oe-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.0.201
+ [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
+ [ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
+ [ 0.000000] printk: bootconsole [sbi0] enabled
+ [ 0.000000] efi: UEFI not found.
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000ffffffff]
+ [ 0.000000] Normal [mem 0x0000000100000000-0x000000027fffffff]
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000080200000-0x000000027fffffff]
+ [ 0.000000] Zeroed struct page in unavailable ranges: 512 pages
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000027fffffff]
+ [ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
+ [ 0.000000] SBI specification v0.3 detected
+ [ 0.000000] SBI implementation ID=0x1 Version=0x9
+ [ 0.000000] SBI v0.2 TIME extension detected
+ [ 0.000000] SBI v0.2 IPI extension detected
+ [ 0.000000] SBI v0.2 RFENCE extension detected
+ [ 0.000000] SBI v0.2 HSM extension detected
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] riscv: ISA extensions acdfim
+ [ 0.000000] riscv: ELF capabilities acdfim
+ [ 0.000000] percpu: Embedded 26 pages/cpu s66904 r8192 d31400 u106496
+ [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2067975
+ [ 0.000000] Kernel command line: root=/dev/mmcblk0p4 rootfstype=ext4 rootwait console=ttySIF0,115200 earlycon=sbi
+ [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
+ [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+ [ 0.000000] Memory: 8155880K/8386560K available (8490K kernel code, 5515K rwdata, 4096K rodata, 285K init, 383K bss, 23)
+ [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+ [ 0.000000] rcu: Hierarchical RCU implementation.
+ [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
+ [ 0.000000] Tracing variant of Tasks RCU enabled.
+ [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+ [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+ [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
+ [ 0.000000] CPU with hartid=0 is not available
+ [ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
+ [ 0.000000] riscv-intc: 64 local interrupts mapped
+ [ 0.000000] plic: interrupt-controller@c000000: mapped 69 interrupts with 4 handlers for 9 contexts.
+ [ 0.000000] random: get_random_bytes called from 0xffffffe000002a6a with crng_init=0
+ [ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [1]
+ [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 352636161696s
+ [ 0.000007] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
+ [ 0.008626] Console: colour dummy device 80x25
+ [ 0.013049] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
+ [ 0.023115] pid_max: default: 32768 minimum: 301
+ [ 0.028423] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+ [ 0.035919] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear)
+ [ 0.045957] rcu: Hierarchical SRCU implementation.
+ [ 0.050393] EFI services will not be available.
+ [ 0.055132] smp: Bringing up secondary CPUs ...
+ [ 0.061824] smp: Brought up 1 node, 4 CPUs
+ [ 0.067458] devtmpfs: initialized
+ [ 0.072700] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+ [ 0.081789] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
+ [ 0.089738] NET: Registered protocol family 16
+ [ 0.093999] thermal_sys: Registered thermal governor 'step_wise'
+ [ 0.109208] iommu: Default domain type: Translated
+ [ 0.119694] vgaarb: loaded
+ [ 0.122571] SCSI subsystem initialized
+ [ 0.126499] usbcore: registered new interface driver usbfs
+ [ 0.131686] usbcore: registered new interface driver hub
+ [ 0.137071] usbcore: registered new device driver usb
+ [ 0.142286] EDAC MC: Ver: 3.0.0
+ [ 0.145760] Advanced Linux Sound Architecture Driver Initialized.
+ [ 0.152205] clocksource: Switched to clocksource riscv_clocksource
+ [ 1.046286] VFS: Disk quotas dquot_6.6.0
+ [ 1.049651] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
+ [ 1.062844] NET: Registered protocol family 2
+ [ 1.067172] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear)
+ [ 1.075455] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear)
+ [ 1.085428] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
+ [ 1.096548] TCP: Hash tables configured (established 65536 bind 65536)
+ [ 1.103043] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear)
+ [ 1.109879] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear)
+ [ 1.117413] NET: Registered protocol family 1
+ [ 1.121881] RPC: Registered named UNIX socket transport module.
+ [ 1.127139] RPC: Registered udp transport module.
+ [ 1.131901] RPC: Registered tcp transport module.
+ [ 1.136677] RPC: Registered tcp NFSv4.1 backchannel transport module.
+ [ 1.143194] PCI: CLS 0 bytes, default 64
+ [ 1.148359] Initialise system trusted keyrings
+ [ 1.152364] workingset: timestamp_bits=62 max_order=21 bucket_order=0
+ [ 1.165382] NFS: Registering the id_resolver key type
+ [ 1.169781] Key type id_resolver registered
+ [ 1.174011] Key type id_legacy registered
+ [ 1.178179] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+ [ 1.184874] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
+ [ 1.192453] 9p: Installing v9fs 9p2000 file system support
+ [ 1.198116] NET: Registered protocol family 38
+ [ 1.201886] Key type asymmetric registered
+ [ 1.206046] Asymmetric key parser 'x509' registered
+ [ 1.211029] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
+ [ 1.218468] io scheduler mq-deadline registered
+ [ 1.223072] io scheduler kyber registered
+ [ 1.228803] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
+ [ 1.235017] fu740-pcie e00000000.pcie: FPGA PCIE PROBE
+ [ 1.281706] fu740-pcie e00000000.pcie: PCIE-PERSTN is GPIO 504
+ [ 1.286922] fu740-pcie e00000000.pcie: PWREN is GPIO 501
+ [ 1.292377] fu740-pcie e00000000.pcie: host bridge /soc/pcie@e00000000 ranges:
+ [ 1.299603] fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000
+ [ 1.307922] fu740-pcie e00000000.pcie: MEM 0x0060090000..0x0070ffffff -> 0x0060090000
+ [ 1.316244] fu740-pcie e00000000.pcie: MEM 0x2000000000..0x3fffffffff -> 0x2000000000
+ [ 1.432223] fu740-pcie e00000000.pcie: PWREN enabling
+ [ 1.436607] fu740-pcie e00000000.pcie: PWREN valid
+ [ 1.560226] fu740-pcie e00000000.pcie: invalid resource
+ [ 1.664802] fu740-pcie e00000000.pcie: Link up
+ [ 1.768582] fu740-pcie e00000000.pcie: Link up
+ [ 1.872369] fu740-pcie e00000000.pcie: Link up
+ [ 1.876116] fu740-pcie e00000000.pcie: Link up, Gen3
+ [ 1.881352] fu740-pcie e00000000.pcie: PCI host bridge to bus 0000:00
+ [ 1.887700] pci_bus 0000:00: root bus resource [bus 00-ff]
+ [ 1.893247] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff])
+ [ 1.902807] pci_bus 0000:00: root bus resource [mem 0x60090000-0x70ffffff]
+ [ 1.909748] pci_bus 0000:00: root bus resource [mem 0x2000000000-0x3fffffffff pref]
+ [ 1.917517] pci 0000:00:00.0: [f15e:0000] type 01 class 0x060400
+ [ 1.923569] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
+ [ 1.929902] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
+ [ 1.936723] pci 0000:00:00.0: supports D1
+ [ 1.940755] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
+ [ 1.947619] pci 0000:01:00.0: [1b21:2824] type 01 class 0x060400
+ [ 1.953052] pci 0000:01:00.0: enabling Extended Tags
+ [ 1.958165] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
+ [ 1.976890] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 1.984425] pci 0000:02:00.0: [1b21:2824] type 01 class 0x060400
+ [ 1.990396] pci 0000:02:00.0: enabling Extended Tags
+ [ 1.995509] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
+ [ 2.001938] pci 0000:02:02.0: [1b21:2824] type 01 class 0x060400
+ [ 2.007682] pci 0000:02:02.0: enabling Extended Tags
+ [ 2.012793] pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
+ [ 2.019167] pci 0000:02:03.0: [1b21:2824] type 01 class 0x060400
+ [ 2.024966] pci 0000:02:03.0: enabling Extended Tags
+ [ 2.030075] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
+ [ 2.036468] pci 0000:02:04.0: [1b21:2824] type 01 class 0x060400
+ [ 2.042250] pci 0000:02:04.0: enabling Extended Tags
+ [ 2.047359] pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
+ [ 2.053811] pci 0000:02:08.0: [1b21:2824] type 01 class 0x060400
+ [ 2.059534] pci 0000:02:08.0: enabling Extended Tags
+ [ 2.064647] pci 0000:02:08.0: PME# supported from D0 D3hot D3cold
+ [ 2.071499] pci 0000:02:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 2.078837] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 2.086911] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 2.094987] pci 0000:02:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 2.103075] pci 0000:02:08.0: bridge configuration invalid ([bus 00-00]), reconfiguring
+ [ 2.111901] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
+ [ 2.118031] pci 0000:04:00.0: [1b21:1142] type 00 class 0x0c0330
+ [ 2.123968] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit]
+ [ 2.131038] pci 0000:04:00.0: PME# supported from D3cold
+ [ 2.148888] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
+ [ 2.155588] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
+ [ 2.162286] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
+ [ 2.168408] pci 0000:07:00.0: [126f:2263] type 00 class 0x010802
+ [ 2.174351] pci 0000:07:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
+ [ 2.192890] pci_bus 0000:07: busn_res: [bus 07-ff] end is updated to 07
+ [ 2.198837] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 07
+ [ 2.205522] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 07
+ [ 2.212241] pci 0000:00:00.0: BAR 0: assigned [mem 0x60100000-0x601fffff]
+ [ 2.219067] pci 0000:00:00.0: BAR 14: assigned [mem 0x60200000-0x603fffff]
+ [ 2.226010] pci 0000:00:00.0: BAR 6: assigned [mem 0x60090000-0x6009ffff pref]
+ [ 2.233308] pci 0000:01:00.0: BAR 14: assigned [mem 0x60200000-0x603fffff]
+ [ 2.240259] pci 0000:02:02.0: BAR 14: assigned [mem 0x60200000-0x602fffff]
+ [ 2.247203] pci 0000:02:08.0: BAR 14: assigned [mem 0x60300000-0x603fffff]
+ [ 2.254150] pci 0000:02:00.0: PCI bridge to [bus 03]
+ [ 2.259217] pci 0000:04:00.0: BAR 0: assigned [mem 0x60200000-0x60207fff 64bit]
+ [ 2.266594] pci 0000:02:02.0: PCI bridge to [bus 04]
+ [ 2.271615] pci 0000:02:02.0: bridge window [mem 0x60200000-0x602fffff]
+ [ 2.278485] pci 0000:02:03.0: PCI bridge to [bus 05]
+ [ 2.283529] pci 0000:02:04.0: PCI bridge to [bus 06]
+ [ 2.288572] pci 0000:07:00.0: BAR 0: assigned [mem 0x60300000-0x60303fff 64bit]
+ [ 2.295952] pci 0000:02:08.0: PCI bridge to [bus 07]
+ [ 2.300973] pci 0000:02:08.0: bridge window [mem 0x60300000-0x603fffff]
+ [ 2.307842] pci 0000:01:00.0: PCI bridge to [bus 02-07]
+ [ 2.313133] pci 0000:01:00.0: bridge window [mem 0x60200000-0x603fffff]
+ [ 2.320009] pci 0000:00:00.0: PCI bridge to [bus 01-07]
+ [ 2.325288] pci 0000:00:00.0: bridge window [mem 0x60200000-0x603fffff]
+ [ 2.332808] pcieport 0000:00:00.0: AER: enabled with IRQ 51
+ [ 2.337946] pcieport 0000:01:00.0: enabling device (0000 -> 0002)
+ [ 2.344786] pcieport 0000:02:02.0: enabling device (0000 -> 0002)
+ [ 2.351328] pcieport 0000:02:08.0: enabling device (0000 -> 0002)
+ [ 2.357091] pci 0000:04:00.0: enabling device (0000 -> 0002)
+ [ 2.362751] switchtec: loaded.
+ [ 2.365933] L2CACHE: DataError @ 0x00000003.00964470
+ [ 2.365992] L2CACHE: No. of Banks in the cache: 4
+ [ 2.375414] L2CACHE: No. of ways per bank: 16
+ [ 2.379846] L2CACHE: Sets per bank: 512
+ [ 2.383751] L2CACHE: Bytes per cache block: 64
+ [ 2.388267] L2CACHE: Index of the largest way enabled: 15
+ [ 2.434865] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+ [ 2.441695] 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 115200) is a SiFive UART v0
+ [ 2.450625] printk: console [ttySIF0] enabled
+ [ 2.450625] printk: console [ttySIF0] enabled
+ [ 2.459360] printk: bootconsole [sbi0] disabled
+ [ 2.459360] printk: bootconsole [sbi0] disabled
+ [ 2.468824] 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 115200) is a SiFive UART v0
+ [ 2.493853] loop: module loaded
+ [ 2.526475] nvme nvme0: pci function 0000:07:00.0
+ [ 2.530852] nvme 0000:07:00.0: enabling device (0000 -> 0002)
+ [ 2.537716] Rounding down aligned max_sectors from 4294967295 to 4294967288
+ [ 2.544470] db_root: cannot open: /etc/target
+ [ 2.545926] nvme nvme0: allocated 64 MiB host memory buffer.
+ [ 2.549020] sifive_spi 10040000.spi: mapped; irq=4, cs=1
+ [ 2.559941] spi-nor spi0.0: is25wp256 (32768 Kbytes)
+ [ 2.566431] sifive_spi 10050000.spi: mapped; irq=6, cs=1
+ [ 2.566707] nvme nvme0: 4/0/0 default/read/poll queues
+ [ 2.571935] libphy: Fixed MDIO Bus: probed
+ [ 2.580950] macb 10090000.ethernet: Registered clk switch 'sifive-gemgxl-mgmt'
+ [ 2.587536] macb 10090000.ethernet: invalid hw address, using random
+ [ 2.588100] nvme0n1: p1 p2
+ [ 2.593875] BEU: Load or Store TILINK BUS ERR occurred
+ [ 2.594342] libphy: MACB_mii_bus: probed
+ [ 2.599312] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 7 (5e:57:b8:ab:24:4a)
+ [ 2.615501] e1000e: Intel(R) PRO/1000 Network Driver
+ [ 2.620251] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
+ [ 2.626463] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ [ 2.632684] ehci-pci: EHCI PCI platform driver
+ [ 2.637144] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+ [ 2.643273] ohci-pci: OHCI PCI platform driver
+ [ 2.647731] uhci_hcd: USB Universal Host Controller Interface driver
+ [ 2.654315] xhci_hcd 0000:04:00.0: xHCI Host Controller
+ [ 2.659450] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 1
+ [ 2.807373] xhci_hcd 0000:04:00.0: hcc params 0x0200e081 hci version 0x100 quirks 0x0000000010000410
+ [ 2.816609] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
+ [ 2.824115] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+ [ 2.831312] usb usb1: Product: xHCI Host Controller
+ [ 2.836174] usb usb1: Manufacturer: Linux 5.10.15 xhci-hcd
+ [ 2.841652] usb usb1: SerialNumber: 0000:04:00.0
+ [ 2.846639] hub 1-0:1.0: USB hub found
+ [ 2.850037] hub 1-0:1.0: 2 ports detected
+ [ 2.854306] xhci_hcd 0000:04:00.0: xHCI Host Controller
+ [ 2.859335] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 2
+ [ 2.866599] xhci_hcd 0000:04:00.0: Host supports USB 3.0 SuperSpeed
+ [ 2.873638] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
+ [ 2.881074] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
+ [ 2.889212] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+ [ 2.896422] usb usb2: Product: xHCI Host Controller
+ [ 2.901282] usb usb2: Manufacturer: Linux 5.10.15 xhci-hcd
+ [ 2.906752] usb usb2: SerialNumber: 0000:04:00.0
+ [ 2.911671] hub 2-0:1.0: USB hub found
+ [ 2.915130] hub 2-0:1.0: 2 ports detected
+ [ 2.919486] usbcore: registered new interface driver usb-storage
+ [ 2.925212] usbcore: registered new interface driver usbserial_generic
+ [ 2.931620] usbserial: USB Serial support registered for generic
+ [ 2.937771] mousedev: PS/2 mouse device common for all mice
+ [ 2.943220] usbcore: registered new interface driver usbtouchscreen
+ [ 2.949466] i2c /dev entries driver
+ [ 2.954218] lm90 0-004c: supply vcc not found, using dummy regulator
+ [ 2.961629] EDAC DEVICE0: Giving out device to module Sifive ECC Manager controller sifive_edac.0: DEV sifive_edac.0 (I)
+ [ 2.997874] mmc_spi spi1.0: SD/MMC host mmc0, no DMA, no WP, no poweroff, cd polling
+ [ 3.005138] ledtrig-cpu: registered to indicate activity on CPUs
+ [ 3.010980] usbcore: registered new interface driver usbhid
+ [ 3.016407] usbhid: USB HID core driver
+ [ 3.020540] usbcore: registered new interface driver snd-usb-audio
+ [ 3.027209] NET: Registered protocol family 10
+ [ 3.031878] Segment Routing with IPv6
+ [ 3.034864] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
+ [ 3.041232] NET: Registered protocol family 17
+ [ 3.045324] 9pnet: Installing 9P2000 support
+ [ 3.049397] Key type dns_resolver registered
+ [ 3.053786] Loading compiled-in X.509 certificates
+ [ 3.059729] ALSA device list:
+ [ 3.061943] No soundcards found.
+ [ 3.066057] Waiting for root device /dev/mmcblk0p4...
+ [ 3.077319] mmc0: host does not support reading read-only switch, assuming write-enable
+ [ 3.084564] mmc0: new SDHC card on SPI
+ [ 3.089699] mmcblk0: mmc0:0000 SD32G 29.7 GiB
+ [ 3.126488] GPT:Primary header thinks Alt. header is not at the end of the disk.
+ [ 3.133144] GPT:13918241 != 62333951
+ [ 3.136679] GPT:Alternate GPT header not at the end of the disk.
+ [ 3.142673] GPT:13918241 != 62333951
+ [ 3.146231] GPT: Use GNU Parted to correct GPT errors.
+ [ 3.151398] mmcblk0: p1 p2 p3 p4
+ [ 3.212226] usb 1-2: new high-speed USB device number 2 using xhci_hcd
+ [ 3.258310] EXT4-fs (mmcblk0p4): INFO: recovery required on readonly filesystem
+ [ 3.264855] EXT4-fs (mmcblk0p4): write access will be enabled during recovery
+ [ 3.458247] usb 1-2: New USB device found, idVendor=174c, idProduct=2074, bcdDevice= 0.01
+ [ 3.465662] usb 1-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
+ [ 3.472775] usb 1-2: Product: AS2107
+ [ 3.476336] usb 1-2: Manufacturer: ASMedia
+ [ 3.480419] usb 1-2: SerialNumber: USB2.0 Hub
+ [ 3.533583] EXT4-fs (mmcblk0p4): recovery complete
+ [ 3.543756] EXT4-fs (mmcblk0p4): mounted filesystem with ordered data mode. Opts: (null)
+ [ 3.551132] VFS: Mounted root (ext4 filesystem) readonly on device 179:4.
+ [ 3.554682] hub 1-2:1.0: USB hub found
+ [ 3.561105] devtmpfs: mounted
+ [ 3.561778] hub 1-2:1.0: 4 ports detected
+ [ 3.565546] Freeing unused kernel memory: 284K
+ [ 3.572964] Kernel memory protection not selected by kernel config.
+ [ 3.579225] Run /sbin/init as init process
+ [ 3.613136] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
+ [ 3.643539] usb 2-2: New USB device found, idVendor=174c, idProduct=3074, bcdDevice= 0.01
+ [ 3.650948] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
+ [ 3.658072] usb 2-2: Product: AS2107
+ [ 3.661630] usb 2-2: Manufacturer: ASMedia
+ [ 3.665709] usb 2-2: SerialNumber: USB2.0 Hub
+ [ 3.762380] hub 2-2:1.0: USB hub found
+ [ 3.766074] hub 2-2:1.0: 4 ports detected
+ [ 7.487226] systemd[1]: System time before build time, advancing clock.
+ [ 7.788093] systemd[1]: systemd 247.2+ running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +U)
+ [ 7.809694] systemd[1]: Detected architecture riscv64.
+
+ Welcome to OpenEmbedded nodistro.0!
+
+ [ 7.832648] systemd[1]: Set hostname to <unmatched>.
+ [ 9.397499] systemd[1]: Queued start job for default target Multi-User System.
+ [ 9.408518] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 9.429329] systemd[1]: Created slice system-getty.slice.
+ [ OK ] Created slice system-getty.slice.
+ [ 9.440400] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 9.447086] systemd[1]: Created slice system-modprobe.slice.
+ [ OK ] Created slice system-modprobe.slice.
+ [ 9.458480] random: systemd: uninitialized urandom read (16 bytes read)
+ [ 9.465436] systemd[1]: Created slice system-serial\x2dgetty.slice.
+ [ OK ] Created slice system-serial\x2dgetty.slice.
+ [ 9.478594] systemd[1]: Created slice User and Session Slice.
+ [ OK ] Created slice User and Session Slice.
+ [ 9.490225] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
+ [ OK ] Started Dispatch Password ��…ts to Console Directory Watch.
+ [ 9.506407] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
+ [ OK ] Started Forward Password R��…uests to Wall Directory Watch.
+ [ 9.522312] systemd[1]: Reached target Paths.
+ [ OK ] Reached target Paths.
+ [ 9.531078] systemd[1]: Reached target Remote File Systems.
+ [ OK ] Reached target Remote File Systems.
+ [ 9.542855] systemd[1]: Reached target Slices.
+ [ OK ] Reached target Slices.
+ [ 9.552712] systemd[1]: Reached target Swap.
+ [ OK ] Reached target Swap.
+ [ 9.561566] systemd[1]: Listening on initctl Compatibility Named Pipe.
+ [ OK ] Listening on initctl Compatibility Named Pipe.
+ [ 9.578686] systemd[1]: Condition check resulted in Journal Audit Socket being skipped.
+ [ 9.586545] systemd[1]: Listening on Journal Socket (/dev/log).
+ [ OK ] Listening on Journal Socket (/dev/log).
+
+ [snip]
+
+ [ OK ] Reached target System Time Synchronized.
+ [ OK ] Reached target Timers.
+ [ OK ] Listening on D-Bus System Message Bus Socket.
+ [ OK ] Reached target Sockets.
+ [ OK ] Reached target Basic System.
+ [ OK ] Started D-Bus System Message Bus.
+ Starting User Login Management...
+ Starting Permit User Sessions...
+ [ OK ] Started Xinetd A Powerful Replacement For Inetd.
+ [ OK ] Finished Permit User Sessions.
+ [ OK ] Started Getty on tty1.
+ [ OK ] Started Serial Getty on hvc0.
+ [ OK ] Started Serial Getty on ttySIF0.
+ [ OK ] Reached target Login Prompts.
+ [ OK ] Started User Login Management.
+ [ OK ] Reached target Multi-User System.
+ Starting Update UTMP about System Runlevel Changes...
+ [ OK ] Finished Update UTMP about System Runlevel Changes.
+
+ OpenEmbedded nodistro.0 unmatched hvc0
+
+ unmatched login:
+ OpenEmbedded nodistro.0 unmatched ttySIF0
+
+ unmatched login:
diff --git a/roms/u-boot/doc/board/sipeed/index.rst b/roms/u-boot/doc/board/sipeed/index.rst
new file mode 100644
index 000000000..3518e2d8f
--- /dev/null
+++ b/roms/u-boot/doc/board/sipeed/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sipeed
+======
+
+.. toctree::
+ :maxdepth: 2
+
+ maix
diff --git a/roms/u-boot/doc/board/sipeed/maix.rst b/roms/u-boot/doc/board/sipeed/maix.rst
new file mode 100644
index 000000000..ef79297ef
--- /dev/null
+++ b/roms/u-boot/doc/board/sipeed/maix.rst
@@ -0,0 +1,697 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2020 Sean Anderson <seanga2@gmail.com>
+
+MAIX
+====
+
+Several of the Sipeed Maix series of boards cotain the Kendryte K210 processor,
+a 64-bit RISC-V CPU. This processor contains several peripherals to accelerate
+neural network processing and other "ai" tasks. This includes a "KPU" neural
+network processor, an audio processor supporting beamforming reception, and a
+digital video port supporting capture and output at VGA resolution. Other
+peripherals include 8M of SRAM (accessible with and without caching); remappable
+pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA controller;
+and I2C, I2S, and SPI controllers. Maix peripherals vary, but include spi flash;
+on-board usb-serial bridges; ports for cameras, displays, and sd cards; and
+ESP32 chips.
+
+Currently, only the Sipeed MAIX BiT V2.0 (bitm) and Sipeed MAIXDUINO are
+supported, but the boards are fairly similar.
+
+Documentation for Maix boards is available from
+`Sipeed's website <http://dl.sipeed.com/MAIX/HDK/>`_.
+Documentation for the Kendryte K210 is available from
+`Kendryte's website <https://kendryte.com/downloads/>`_. However, hardware
+details are rather lacking, so most technical reference has been taken from the
+`standalone sdk <https://github.com/kendryte/kendryte-standalone-sdk>`_.
+
+Build and boot steps
+--------------------
+
+To build U-Boot, run
+
+.. code-block:: none
+
+ make <defconfig>
+ make CROSS_COMPILE=<your cross compile prefix>
+
+To flash U-Boot, run
+
+.. code-block:: none
+
+ kflash -tp /dev/<your tty here> -B <board_id> u-boot-dtb.bin
+
+The board provides two serial devices, e.g.
+
+* /dev/serial/by-id/usb-Kongou_Hikari_Sipeed-Debug_12345678AB-if00-port0
+* /dev/serial/by-id/usb-Kongou_Hikari_Sipeed-Debug_12345678AB-if01-port0
+
+Which one is used for flashing depends on the board.
+
+Currently only a small subset of the board features are supported. So we can
+use the same default configuration and device tree. In the long run we may need
+separate settings.
+
+======================== ========================== ========== ==========
+Board defconfig board_id TTY device
+======================== ========================== ========== ==========
+Sipeed MAIX BiT sipeed_maix_bitm_defconfig bit first
+Sipeed MAIX BiT with Mic sipeed_maix_bitm_defconfig bit_mic first
+Sipeed MAIXDUINO sipeed_maix_bitm_defconfig maixduino first
+Sipeed MAIX GO goE second
+Sipeed MAIX ONE DOCK dan first
+======================== ========================== ========== ==========
+
+Flashing causes a reboot of the device. Parameter -t specifies that the serial
+console shall be opened immediately. Boot output should look like the following:
+
+.. code-block:: none
+
+ U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
+
+ DRAM: 8 MiB
+ MMC: spi@53000000:slot@0: 0
+ In: serial@38000000
+ Out: serial@38000000
+ Err: serial@38000000
+ =>
+
+OpenSBI
+^^^^^^^
+
+OpenSBI is an open source supervisor execution environment implementing the
+RISC-V Supervisor Binary Interface Specification [1]. One of its features is
+to intercept run-time exceptions, e.g. for unaligned access or illegal
+instructions, and to emulate the failing instructions.
+
+The OpenSBI source can be downloaded via:
+
+.. code-block:: bash
+
+ git clone https://github.com/riscv/opensbi
+
+As OpenSBI will be loaded at 0x80000000 we have to adjust the U-Boot text base.
+Furthermore we have to enable building U-Boot for S-mode::
+
+ CONFIG_SYS_TEXT_BASE=0x80020000
+ CONFIG_RISCV_SMODE=y
+
+Both settings are contained in sipeed_maix_smode_defconfig so we can build
+U-Boot with:
+
+.. code-block:: bash
+
+ make sipeed_maix_smode_defconfig
+ make
+
+To build OpenSBI with U-Boot as a payload:
+
+.. code-block:: bash
+
+ cd opensbi
+ make \
+ PLATFORM=kendryte/k210 \
+ FW_PAYLOAD=y \
+ FW_PAYLOAD_OFFSET=0x20000 \
+ FW_PAYLOAD_PATH=<path to U-Boot>/u-boot-dtb.bin
+
+The value of FW_PAYLOAD_OFFSET must match CONFIG_SYS_TEXT_BASE - 0x80000000.
+
+The file to flash is build/platform/kendryte/k210/firmware/fw_payload.bin.
+
+Booting
+^^^^^^^
+
+The default boot process is to load and boot the files ``/uImage`` and
+``/k210.dtb`` off of the first partition of the MMC. For Linux, this will result
+in an output like
+
+.. code-block:: none
+
+ U-Boot 2020.10-00691-gd1d651d988-dirty (Oct 16 2020 - 17:05:24 -0400)
+
+ DRAM: 8 MiB
+ MMC: spi@53000000:slot@0: 0
+ Loading Environment from SPIFlash... SF: Detected w25q128fw with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+ OK
+ In: serial@38000000
+ Out: serial@38000000
+ Err: serial@38000000
+ Hit any key to stop autoboot: 0
+ 1827380 bytes read in 1044 ms (1.7 MiB/s)
+ 13428 bytes read in 10 ms (1.3 MiB/s)
+ ## Booting kernel from Legacy Image at 80060000 ...
+ Image Name: linux
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 1827316 Bytes = 1.7 MiB
+ Load Address: 80000000
+ Entry Point: 80000000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 80400000
+ Booting using the fdt blob at 0x80400000
+ Loading Kernel Image
+ Loading Device Tree to 00000000803f9000, end 00000000803ff473 ... OK
+
+ Starting kernel ...
+
+ [ 0.000000] Linux version 5.9.0-00021-g6dcc2f0814c6-dirty (sean@godwin) (riscv64-linux-gnu-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #34 SMP Fri Oct 16 14:40:57 EDT 2020
+ [ 0.000000] earlycon: sifive0 at MMIO 0x0000000038000000 (options '115200n8')
+ [ 0.000000] printk: bootconsole [sifive0] enabled
+ [ 0.000000] Zone ranges:
+ [ 0.000000] DMA32 [mem 0x0000000080000000-0x00000000807fffff]
+ [ 0.000000] Normal empty
+ [ 0.000000] Movable zone start for each node
+ [ 0.000000] Early memory node ranges
+ [ 0.000000] node 0: [mem 0x0000000080000000-0x00000000807fffff]
+ [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000807fffff]
+ [ 0.000000] riscv: ISA extensions acdfgim
+ [ 0.000000] riscv: ELF capabilities acdfim
+ [ 0.000000] percpu: max_distance=0x18000 too large for vmalloc space 0x0
+ [ 0.000000] percpu: Embedded 12 pages/cpu s18848 r0 d30304 u49152
+ [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020
+ [ 0.000000] Kernel command line: earlycon console=ttySIF0
+ [ 0.000000] Dentry cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
+ [ 0.000000] Inode-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
+ [ 0.000000] Sorting __ex_table...
+ [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
+ [ 0.000000] Memory: 6004K/8192K available (1139K kernel code, 126K rwdata, 198K rodata, 90K init, 81K bss, 2188K reserved, 0K cma-reserved)
+ [ 0.000000] rcu: Hierarchical RCU implementation.
+ [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+ [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
+ [ 0.000000] riscv-intc: 64 local interrupts mapped
+ [ 0.000000] plic: interrupt-controller@C000000: mapped 65 interrupts with 2 handlers for 2 contexts.
+ [ 0.000000] random: get_random_bytes called from 0x00000000800019a8 with crng_init=0
+ [ 0.000000] k210-clk: clock-controller
+ [ 0.000000] k210-clk: clock-controller: fixed-rate 26 MHz osc base clock
+ [ 0.000000] clint: clint@2000000: timer running at 7800000 Hz
+ [ 0.000000] clocksource: clint_clocksource: mask: 0xffffffffffffffff max_cycles: 0x3990be68b, max_idle_ns: 881590404272 ns
+ [ 0.000014] sched_clock: 64 bits at 7MHz, resolution 128ns, wraps every 4398046511054ns
+ [ 0.008450] Console: colour dummy device 80x25
+ [ 0.012494] Calibrating delay loop (skipped), value calculated using timer frequency.. 15.60 BogoMIPS (lpj=31200)
+ [ 0.022693] pid_max: default: 4096 minimum: 301
+ [ 0.027352] Mount-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
+ [ 0.034428] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes, linear)
+ [ 0.045099] rcu: Hierarchical SRCU implementation.
+ [ 0.050048] smp: Bringing up secondary CPUs ...
+ [ 0.055417] smp: Brought up 1 node, 2 CPUs
+ [ 0.059602] devtmpfs: initialized
+ [ 0.082796] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
+ [ 0.091820] futex hash table entries: 16 (order: -2, 1024 bytes, linear)
+ [ 0.098507] pinctrl core: initialized pinctrl subsystem
+ [ 0.140938] clocksource: Switched to clocksource clint_clocksource
+ [ 0.247216] workingset: timestamp_bits=62 max_order=11 bucket_order=0
+ [ 0.277392] k210-fpioa 502b0000.pinmux: K210 FPIOA pin controller
+ [ 0.291724] k210-sysctl 50440000.syscon: K210 system controller
+ [ 0.305317] k210-rst 50440000.syscon:reset-controller: K210 reset controller
+ [ 0.313808] 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 115200) is a SiFive UART v0
+ [ 0.322712] printk: console [ttySIF0] enabled
+ [ 0.322712] printk: console [ttySIF0] enabled
+ [ 0.331328] printk: bootconsole [sifive0] disabled
+ [ 0.331328] printk: bootconsole [sifive0] disabled
+ [ 0.353347] Freeing unused kernel memory: 88K
+ [ 0.357004] This architecture does not have kernel memory protection.
+ [ 0.363397] Run /init as init process
+
+Loading, Booting, and Storing Images
+------------------------------------
+
+.. _loading:
+
+Loading Images
+^^^^^^^^^^^^^^
+
+Serial
+""""""
+
+Use the ``loady`` command to load images over serial.
+
+.. code-block:: none
+
+ => loady $loadaddr 1500000
+ ## Switch baudrate to 1500000 bps and press ENTER ...
+
+ *** baud: 1500000
+
+ *** baud: 1500000 ***
+ ## Ready for binary (ymodem) download to 0x80000000 at 1500000 bps...
+ C
+ *** file: loader.bin
+ $ sz -vv loader.bin
+ Sending: loader.bin
+ Bytes Sent:2478208 BPS:72937
+ Sending:
+ Ymodem sectors/kbytes sent: 0/ 0k
+ Transfer complete
+
+ *** exit status: 0 ***
+ ## Total Size = 0x0025d052 = 2478162 Bytes
+ ## Switch baudrate to 115200 bps and press ESC ...
+
+ *** baud: 115200
+
+ *** baud: 115200 ***
+ =>
+
+This command does not set ``$filesize``, so it may need to be set manually.
+
+SPI Flash
+"""""""""
+
+To load an image off of SPI flash, first set up a partition as described in
+:ref:`k210_partitions`. Then, use ``mtd`` to load that partition
+
+.. code-block:: none
+
+ => sf probe
+ SF: Detected w25q128fw with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+ => mtd read linux $loadaddr
+ Reading 2097152 byte(s) at offset 0x00000000
+
+This command does not set ``$filesize``, so it may need to be set manually.
+
+MMC
+"""
+
+The MMC device number is 0. To list partitions on the device, use ``part``:
+
+.. code-block:: none
+
+ => part list mmc 0
+
+ Partition Map for MMC device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00000800 0x039effde "boot"
+ attrs: 0x0000000000000000
+ type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
+ guid: 96161f7d-7113-4cc7-9a24-08ab7fc5cb72
+
+To list files, use ``ls``:
+
+.. code-block:: none
+
+ => ls mmc 0:1
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 16384 lost+found
+ 13428 k210.dtb
+ 1827380 uImage
+
+To load a file, use ``load``:
+
+.. code-block:: none
+
+ => load mmc 0:1 $loadaddr uImage
+ 1827380 bytes read in 1049 ms (1.7 MiB/s)
+
+Running Programs
+^^^^^^^^^^^^^^^^
+
+Binaries
+""""""""
+
+To run a bare binary, use the ``go`` command:
+
+.. code-block:: none
+
+ => go 80000000
+ ## Starting application at 0x80000000 ...
+ Example expects ABI version 9
+ Actual U-Boot ABI version 9
+ Hello World
+ argc = 1
+ argv[0] = "80000000"
+ argv[1] = "<NULL>"
+ Hit any key to exit ...
+
+Note that this will only start a program on one hart. As-of this writing it is
+only possible to start a program on multiple harts using the ``bootm`` command.
+
+Legacy Images
+"""""""""""""
+
+To create a legacy image, use ``tools/mkimage``:
+
+.. code-block:: none
+
+ $ tools/mkimage -A riscv -O linux -T kernel -C none -a 0x80000000 -e 0x80000000 -n linux -d ../linux-git/arch/riscv/boot/Image uImage
+ Image Name: linux
+ Created: Fri Oct 16 17:36:32 2020
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 1827316 Bytes = 1784.49 KiB = 1.74 MiB
+ Load Address: 80000000
+ Entry Point: 80000000
+
+The ``bootm`` command also requires an FDT, even if the image doesn't require
+one. After loading the image to ``$loadaddr`` and the FDT to ``$fdt_addr_r``,
+boot with:
+
+.. code-block:: none
+
+ => bootm $loadaddr - $fdt_addr_r
+ ## Booting kernel from Legacy Image at 80060000 ...
+ Image Name: linux
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 1827316 Bytes = 1.7 MiB
+ Load Address: 80000000
+ Entry Point: 80000000
+ Verifying Checksum ... OK
+ ## Flattened Device Tree blob at 80400000
+ Booting using the fdt blob at 0x80400000
+ Loading Kernel Image
+ Loading Device Tree to 00000000803f9000, end 00000000803ff473 ... OK
+
+ Starting kernel ...
+
+The FDT is verified after the kernel is relocated, so it must be loaded high
+enough so that it won't be overwritten. The default values for ``$loadaddr``
+and ``$fdt_addr_r`` should provide ample headroom for most use-cases.
+
+Flashing Images
+^^^^^^^^^^^^^^^
+
+SPI Flash
+"""""""""
+
+To flash data to SPI flash, first load it using one of the methods in
+:ref:`loading`. Addiotionally, create some partitions as described in
+:ref:`partitions`. Then use the ``mtd`` command:
+
+.. code-block:: none
+
+ => sf probe
+ SF: Detected w25q128fw with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+ => mtd write linux $loadaddr 0 $filesize
+ Writing 2478162 byte(s) at offset 0x00000000
+
+Note that in order to write a bootable image, a header and tailer must be added.
+
+MMC
+"""
+
+MMC writes are unsupported for now.
+
+SPI Flash
+^^^^^^^^^
+
+Sipeed MAIX boards typically provide around 16 MiB of SPI NOR flash. U-Boot is
+stored in the first 1 MiB or so of this flash. U-Boot's environment is stored at
+the end of flash.
+
+.. _k210_partitions:
+
+Partitions
+""""""""""
+
+There is no set data layout. The default partition layout only allocates
+partitions for U-Boot and its default environment
+
+.. code-block:: none
+
+ => mtd list
+ List of MTD devices:
+ * nor0
+ - type: NOR flash
+ - block size: 0x1000 bytes
+ - min I/O: 0x1 bytes
+ - 0x000000000000-0x000001000000 : "nor0"
+ - 0x000000000000-0x000000100000 : "u-boot"
+ - 0x000000fff000-0x000001000000 : "env"
+
+As an example, to allocate 2MiB for Linux and (almost) 13 MiB for other data,
+set the ``mtdparts`` like:
+
+.. code-block:: none
+
+ => env set mtdparts nor0:1M(u-boot),2M(linux),0xcff000(data),0x1000@0xfff000(env)
+ => mtd list
+ List of MTD devices:
+ * nor0
+ - type: NOR flash
+ - block size: 0x1000 bytes
+ - min I/O: 0x1 bytes
+ - 0x000000000000-0x000001000000 : "nor0"
+ - 0x000000000000-0x000000100000 : "u-boot"
+ - 0x000000100000-0x000000300000 : "linux"
+ - 0x000000300000-0x000000fff000 : "data"
+ - 0x000000fff000-0x000001000000 : "env"
+
+To make these changes permanent, save the environment:
+
+.. code-block:: none
+
+ => env save
+ Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
+ OK
+
+U-Boot will always load the environment from the last 4 KiB of flash.
+
+Pin Assignment
+--------------
+
+The K210 contains a Fully Programmable I/O Array (FPIOA), which can remap any of
+its 256 input functions to any any of 48 output pins. The following table has
+the default pin assignments for the BitM.
+
+===== ========== =======
+Pin Function Comment
+===== ========== =======
+IO_0 JTAG_TCLK
+IO_1 JTAG_TDI
+IO_2 JTAG_TMS
+IO_3 JTAG_TDO
+IO_4 UARTHS_RX
+IO_5 UARTHS_TX
+IO_6 Not set
+IO_7 Not set
+IO_8 GPIO_0
+IO_9 GPIO_1
+IO_10 GPIO_2
+IO_11 GPIO_3
+IO_12 GPIO_4 Green LED
+IO_13 GPIO_5 Red LED
+IO_14 GPIO_6 Blue LED
+IO_15 GPIO_7
+IO_16 GPIOHS_0 ISP
+IO_17 GPIOHS_1
+IO_18 I2S0_SCLK MIC CLK
+IO_19 I2S0_WS MIC WS
+IO_20 I2S0_IN_D0 MIC SD
+IO_21 GPIOHS_5
+IO_22 GPIOHS_6
+IO_23 GPIOHS_7
+IO_24 GPIOHS_8
+IO_25 GPIOHS_9
+IO_26 SPI1_D1 MMC MISO
+IO_27 SPI1_SCLK MMC CLK
+IO_28 SPI1_D0 MMC MOSI
+IO_29 GPIOHS_13 MMC CS
+IO_30 GPIOHS_14
+IO_31 GPIOHS_15
+IO_32 GPIOHS_16
+IO_33 GPIOHS_17
+IO_34 GPIOHS_18
+IO_35 GPIOHS_19
+IO_36 GPIOHS_20 Panel CS
+IO_37 GPIOHS_21 Panel RST
+IO_38 GPIOHS_22 Panel DC
+IO_39 SPI0_SCK Panel WR
+IO_40 SCCP_SDA
+IO_41 SCCP_SCLK
+IO_42 DVP_RST
+IO_43 DVP_VSYNC
+IO_44 DVP_PWDN
+IO_45 DVP_HSYNC
+IO_46 DVP_XCLK
+IO_47 DVP_PCLK
+===== ========== =======
+
+Over- and Under-clocking
+------------------------
+
+To change the clock speed of the K210, you will need to enable
+``CONFIG_CLK_K210_SET_RATE`` and edit the board's device tree. To do this, add a
+section to ``arch/riscv/arch/riscv/dts/k210-maix-bit.dts`` like the following:
+
+.. code-block:: none
+
+ &sysclk {
+ assigned-clocks = <&sysclk K210_CLK_PLL0>;
+ assigned-clock-rates = <800000000>;
+ };
+
+There are three PLLs on the K210: PLL0 is the parent of most of the components,
+including the CPU and RAM. PLL1 is the parent of the neural network coprocessor.
+PLL2 is the parent of the sound processing devices. Note that child clocks of
+PLL0 and PLL2 run at *half* the speed of the PLLs. For example, if PLL0 is
+running at 800 MHz, then the CPU will run at 400 MHz. This is the example given
+above. The CPU can be overclocked to around 600 MHz, and underclocked to 26 MHz.
+
+It is possible to set PLL2's parent to PLL0. The plls are more accurate when
+converting between similar frequencies. This makes it easier to get an accurate
+frequency for I2S. As an example, consider sampling an I2S device at 44.1 kHz.
+On this device, the I2S serial clock runs at 64 times the sample rate.
+Therefore, we would like to run PLL2 at an even multiple of 2.8224 MHz. If
+PLL2's parent is IN0, we could use a frequency of 390 MHz (the same as the CPU's
+default speed). Dividing by 138 yields a serial clock of about 2.8261 MHz. This
+results in a sample rate of 44.158 kHz---around 50 Hz or .1% too fast. If,
+instead, we set PLL2's parent to PLL1 running at 390 MHz, and request a rate of
+2.8224 * 136 = 383.8464 MHz, the achieved rate is 383.90625 MHz. Dividing by 136
+yields a serial clock of about 2.8228 MHz. This results in a sample rate of
+44.107 kHz---just 7 Hz or .02% too fast. This configuration is shown in the
+following example:
+
+.. code-block:: none
+
+ &sysclk {
+ assigned-clocks = <&sysclk K210_CLK_PLL1>, <&sysclk K210_CLK_PLL2>;
+ assigned-clock-parents = <0>, <&sysclk K210_CLK_PLL1>;
+ assigned-clock-rates = <390000000>, <383846400>;
+ };
+
+There are a couple of quirks to the PLLs. First, there are more frequency ratios
+just above and below 1.0, but there is a small gap around 1.0. To be explicit,
+if the input frequency is 100 MHz, it would be impossible to have an output of
+99 or 101 MHz. In addition, there is a maximum frequency for the internal VCO,
+so higher input/output frequencies will be less accurate than lower ones.
+
+Technical Details
+-----------------
+
+Boot Sequence
+^^^^^^^^^^^^^
+
+1. ``RESET`` pin is deasserted. The pin is connected to the ``RESET`` button. It
+ can also be set to low via either the ``DTR`` or the ``RTS`` line of the
+ serial interface (depending on the board).
+2. Both harts begin executing at ``0x00001000``.
+3. Both harts jump to firmware at ``0x88000000``.
+4. One hart is chosen as a boot hart.
+5. Firmware reads the value of pin ``IO_16`` (ISP). This pin is connected to the
+ ``BOOT`` button. The pin can equally be set to low via either the ``DTR`` or
+ ``RTS`` line of the serial interface (depending on the board).
+
+ * If the pin is low, enter ISP mode. This mode allows loading data to ram,
+ writing it to flash, and booting from specific addresses.
+ * If the pin is high, continue boot.
+6. Firmware reads the next stage from flash (SPI3) to address ``0x80000000``.
+
+ * If byte 0 is 1, the next stage is decrypted using the built-in AES
+ accelerator and the one-time programmable, 128-bit AES key.
+ * Bytes 1 to 4 hold the length of the next stage.
+ * The SHA-256 sum of the next stage is automatically calculated, and verified
+ against the 32 bytes following the next stage.
+7. The boot hart sends an IPI to the other hart telling it to jump to the next
+ stage.
+8. The boot hart jumps to ``0x80000000``.
+
+Debug UART
+^^^^^^^^^^
+
+The Debug UART is provided with the following settings::
+
+ CONFIG_DEBUG_UART=y
+ CONFIG_DEBUG_UART_SIFIVE=y
+ CONFIG_DEBUG_UART_BASE=0x38000000
+ CONFIG_DEBUG_UART_CLOCK=390000000
+
+Resetting the board
+^^^^^^^^^^^^^^^^^^^
+
+The MAIX boards can be reset using the DTR and RTS lines of the serial console.
+How the lines are used depends on the specific board. See the code of kflash.py
+for details.
+
+This is the reset sequence for the MAXDUINO and MAIX BiT with Mic:
+
+.. code-block:: python
+
+ def reset(self):
+ self.device.setDTR(False)
+ self.device.setRTS(False)
+ time.sleep(0.1)
+ self.device.setDTR(True)
+ time.sleep(0.1)
+ self.device.setDTR(False)
+ time.sleep(0.1)
+
+and this for the MAIX Bit:
+
+.. code-block:: python
+
+ def reset(self):
+ self.device.setDTR(False)
+ self.device.setRTS(False)
+ time.sleep(0.1)
+ self.device.setRTS(True)
+ time.sleep(0.1)
+ self.device.setRTS(False)
+ time.sleep(0.1)
+
+Memory Map
+^^^^^^^^^^
+
+========== ========= ===========
+Address Size Description
+========== ========= ===========
+0x00000000 0x1000 debug
+0x00001000 0x1000 rom
+0x02000000 0xC000 clint
+0x0C000000 0x4000000 plic
+0x38000000 0x1000 uarths
+0x38001000 0x1000 gpiohs
+0x40000000 0x400000 sram0 (non-cached)
+0x40400000 0x200000 sram1 (non-cached)
+0x40600000 0x200000 airam (non-cached)
+0x40800000 0xC00000 kpu
+0x42000000 0x400000 fft
+0x50000000 0x1000 dmac
+0x50200000 0x200000 apb0
+0x50200000 0x80 gpio
+0x50210000 0x100 uart0
+0x50220000 0x100 uart1
+0x50230000 0x100 uart2
+0x50240000 0x100 spi slave
+0x50250000 0x200 i2s0
+0x50250200 0x200 apu
+0x50260000 0x200 i2s1
+0x50270000 0x200 i2s2
+0x50280000 0x100 i2c0
+0x50290000 0x100 i2c1
+0x502A0000 0x100 i2c2
+0x502B0000 0x100 fpioa
+0x502C0000 0x100 sha256
+0x502D0000 0x100 timer0
+0x502E0000 0x100 timer1
+0x502F0000 0x100 timer2
+0x50400000 0x200000 apb1
+0x50400000 0x100 wdt0
+0x50410000 0x100 wdt1
+0x50420000 0x100 otp control
+0x50430000 0x100 dvp
+0x50440000 0x100 sysctl
+0x50450000 0x100 aes
+0x50460000 0x100 rtc
+0x52000000 0x4000000 apb2
+0x52000000 0x100 spi0
+0x53000000 0x100 spi1
+0x54000000 0x200 spi3
+0x80000000 0x400000 sram0 (cached)
+0x80400000 0x200000 sram1 (cached)
+0x80600000 0x200000 airam (cached)
+0x88000000 0x20000 otp
+0x88000000 0xC200 firmware
+0x8801C000 0x1000 riscv priv spec 1.9 config
+0x8801D000 0x2000 flattened device tree (contains only addresses and
+ interrupts)
+0x8801F000 0x1000 credits
+========== ========= ===========
+
+Links
+-----
+
+[1] https://github.com/riscv/riscv-sbi-doc
+ RISC-V Supervisor Binary Interface Specification
diff --git a/roms/u-boot/doc/board/st/index.rst b/roms/u-boot/doc/board/st/index.rst
new file mode 100644
index 000000000..91f1d51b4
--- /dev/null
+++ b/roms/u-boot/doc/board/st/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+STMicroelectronics
+==================
+
+.. toctree::
+ :maxdepth: 2
+
+ stm32mp1
diff --git a/roms/u-boot/doc/board/st/stm32mp1.rst b/roms/u-boot/doc/board/st/stm32mp1.rst
new file mode 100644
index 000000000..f0c2b09b9
--- /dev/null
+++ b/roms/u-boot/doc/board/st/stm32mp1.rst
@@ -0,0 +1,614 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Patrick Delaunay <patrick.delaunay@foss.st.com>
+
+STM32MP15x boards
+=================
+
+This is a quick instruction for setup STM32MP15x boards.
+
+Supported devices
+-----------------
+
+U-Boot supports STMP32MP15x SoCs:
+
+ - STM32MP157
+ - STM32MP153
+ - STM32MP151
+
+The STM32MP15x is a Cortex-A MPU aimed at various applications.
+
+It features:
+
+ - Dual core Cortex-A7 application core (Single on STM32MP151)
+ - 2D/3D image composition with GPU (only on STM32MP157)
+ - Standard memories interface support
+ - Standard connectivity, widely inherited from the STM32 MCU family
+ - Comprehensive security support
+
+Each line comes with a security option (cryptography & secure boot) and
+a Cortex-A frequency option:
+
+ - A : Cortex-A7 @ 650 MHz
+ - C : Secure Boot + HW Crypto + Cortex-A7 @ 650 MHz
+ - D : Cortex-A7 @ 800 MHz
+ - F : Secure Boot + HW Crypto + Cortex-A7 @ 800 MHz
+
+Everything is supported in Linux but U-Boot is limited to:
+
+ 1. UART
+ 2. SD card/MMC controller (SDMMC)
+ 3. NAND controller (FMC)
+ 4. NOR controller (QSPI)
+ 5. USB controller (OTG DWC2)
+ 6. Ethernet controller
+
+And the necessary drivers
+
+ 1. I2C
+ 2. STPMIC1 (PMIC and regulator)
+ 3. Clock, Reset, Sysreset
+ 4. Fuse
+
+Currently the following boards are supported:
+
+ + stm32mp157a-dk1.dts
+ + stm32mp157c-dk2.dts
+ + stm32mp157c-ed1.dts
+ + stm32mp157c-ev1.dts
+ + stm32mp15xx-dhcor-avenger96.dts
+
+Boot Sequences
+--------------
+
+3 boot configurations are supported with:
+
++----------+------------------------+-------------------------+--------------+
+| **ROM** | **FSBL** | **SSBL** | **OS** |
++ **code** +------------------------+-------------------------+--------------+
+| | First Stage Bootloader | Second Stage Bootloader | Linux Kernel |
++ +------------------------+-------------------------+--------------+
+| | embedded RAM | DDR |
++----------+------------------------+-------------------------+--------------+
+
+The **Trusted** boot chain
+``````````````````````````
+
+defconfig_file : stm32mp15_trusted_defconfig
+
+ +-------------+-------------------------+------------+-------+
+ | ROM code | FSBL | SSBL | OS |
+ + +-------------------------+------------+-------+
+ | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
+ +-------------+-------------------------+------------+-------+
+ | TrustZone |secure monitor |
+ +-------------+-------------------------+------------+-------+
+
+TF-A performs a full initialization of Secure peripherals and installs a
+secure monitor, BL32:
+
+ * SPMin provided by TF-A or
+ * OP-TEE from specific partitions (teeh, teed, teex).
+
+U-Boot is running in normal world and uses the secure monitor to access
+to secure resources.
+
+The **Basic** boot chain
+````````````````````````
+
+defconfig_file : stm32mp15_basic_defconfig
+
+ +-------------+------------+------------+-------+
+ | ROM code | FSBL | SSBL | OS |
+ + +------------+------------+-------+
+ | |U-Boot SPL | U-Boot | Linux |
+ +-------------+------------+------------+-------+
+ | TrustZone | | PSCI from U-Boot |
+ +-------------+------------+------------+-------+
+
+SPL has limited security initialization
+
+U-Boot is running in secure mode and provide a secure monitor to the kernel
+with only PSCI support (Power State Coordination Interface defined by ARM).
+
+All the STM32MP15x boards supported by U-Boot use the same generic board
+stm32mp1 which support all the bootable devices.
+
+Each board is configured only with the associated device tree.
+
+Device Tree Selection
+---------------------
+
+You need to select the appropriate device tree for your board,
+the supported device trees for STM32MP15x are:
+
++ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
+
+ + stm32mp157c-ev1
+
++ ed1: daughter board with pmic stpmic1
+
+ + stm32mp157c-ed1
+
++ dk1: Discovery board
+
+ + stm32mp157a-dk1
+
++ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
+
+ + stm32mp157c-dk2
+
++ avenger96: Avenger96 board from Arrow Electronics based on DH Elec. DHCOR SoM
+
+ + stm32mp15xx-dhcor-avenger96
+
+Build Procedure
+---------------
+
+1. Install the required tools for U-Boot
+
+ * install package needed in U-Boot makefile
+ (libssl-dev, swig, libpython-dev...)
+
+ * install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
+ from SDK for STM32MP15x, or any crosstoolchains from your distribution)
+ (you can use any gcc cross compiler compatible with U-Boot)
+
+2. Set the cross compiler::
+
+ # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
+
+3. Select the output directory (optional)::
+
+ # export KBUILD_OUTPUT=/path/to/output
+
+ for example: use one output directory for each configuration::
+
+ # export KBUILD_OUTPUT=stm32mp15_trusted
+ # export KBUILD_OUTPUT=stm32mp15_basic
+
+ you can build outside of code directory::
+
+ # export KBUILD_OUTPUT=../build/stm32mp15_trusted
+
+4. Configure U-Boot::
+
+ # make <defconfig_file>
+
+ with <defconfig_file>:
+
+ - For **trusted** boot mode : **stm32mp15_trusted_defconfig**
+ - For basic boot mode: stm32mp15_basic_defconfig
+
+5. Configure the device-tree and build the U-Boot image::
+
+ # make DEVICE_TREE=<name> all
+
+ Examples:
+
+ a) trusted boot on ev1::
+
+ # export KBUILD_OUTPUT=stm32mp15_trusted
+ # make stm32mp15_trusted_defconfig
+ # make DEVICE_TREE=stm32mp157c-ev1 all
+
+ b) trusted with OP-TEE boot on dk2::
+
+ # export KBUILD_OUTPUT=stm32mp15_trusted
+ # make stm32mp15_trusted_defconfig
+ # make DEVICE_TREE=stm32mp157c-dk2 all
+
+ c) basic boot on ev1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157c-ev1 all
+
+ d) basic boot on ed1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157c-ed1 all
+
+ e) basic boot on dk1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157a-dk1 all
+
+ f) basic boot on avenger96::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp15xx-dhcor-avenger96 all
+
+6. Output files
+
+ BootRom and TF-A expect binaries with STM32 image header
+ SPL expects file with U-Boot uImage header
+
+ So in the output directory (selected by KBUILD_OUTPUT),
+ you can found the needed files:
+
+ - For **Trusted** boot (with or without OP-TEE)
+
+ - FSBL = **tf-a.stm32** (provided by TF-A compilation)
+ - SSBL = **u-boot.stm32**
+
+ - For Basic boot
+
+ - FSBL = spl/u-boot-spl.stm32
+ - SSBL = u-boot.img (without CONFIG_SPL_LOAD_FIT) or
+ u-boot.itb (with CONFIG_SPL_LOAD_FIT=y)
+
+Switch Setting for Boot Mode
+----------------------------
+
+You can select the boot mode, on the board with one switch, to select
+the boot pin values = BOOT0, BOOT1, BOOT2
+
+ +-------------+---------+---------+---------+
+ |*Boot Mode* | *BOOT2* | *BOOT1* | *BOOT0* |
+ +=============+=========+=========+=========+
+ | Recovery | 0 | 0 | 0 |
+ +-------------+---------+---------+---------+
+ | NOR | 0 | 0 | 1 |
+ +-------------+---------+---------+---------+
+ | eMMC | 0 | 1 | 0 |
+ +-------------+---------+---------+---------+
+ | NAND | 0 | 1 | 1 |
+ +-------------+---------+---------+---------+
+ | Reserved | 1 | 0 | 0 |
+ +-------------+---------+---------+---------+
+ | SD-Card | 1 | 0 | 1 |
+ +-------------+---------+---------+---------+
+ | Recovery | 1 | 1 | 0 |
+ +-------------+---------+---------+---------+
+ | SPI-NAND | 1 | 1 | 1 |
+ +-------------+---------+---------+---------+
+
+- on the **daugther board ed1 = MB1263** with the switch SW1
+- on **Avenger96** with switch S3 (NOR and SPI-NAND are not applicable)
+- on board **DK1/DK2** with the switch SW1 = BOOT0, BOOT2
+ with only 2 pins available (BOOT1 is forced to 0 and NOR not supported),
+ the possible value becomes:
+
+ +-------------+---------+---------+
+ |*Boot Mode* | *BOOT2* | *BOOT0* |
+ +=============+=========+=========+
+ | Recovery | 0 | 0 |
+ +-------------+---------+---------+
+ | NOR (NA)| 0 | 1 |
+ +-------------+---------+---------+
+ | Reserved | 1 | 0 |
+ +-------------+---------+---------+
+ | SD-Card | 1 | 1 |
+ +-------------+---------+---------+
+
+Recovery is a boot from serial link (UART/USB) and it is used with
+STM32CubeProgrammer tool to load executable in RAM and to update the flash
+devices available on the board (NOR/NAND/eMMC/SD card).
+
+The communication between HOST and board is based on
+
+ - for UARTs : the uart protocol used with all MCU STM32
+ - for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
+
+Prepare an SD card
+------------------
+
+The minimal requirements for STMP32MP15x boot up to U-Boot are:
+
+- GPT partitioning (with gdisk or with sgdisk)
+- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
+- one ssbl partition for U-Boot
+
+Then the minimal GPT partition is:
+
+ +-------+--------+---------+-------------+
+ | *Num* | *Name* | *Size* | *Content* |
+ +=======+========+=========+=============+
+ | 1 | fsbl1 | 256 KiB | TF-A or SPL |
+ +-------+--------+---------+-------------+
+ | 2 | fsbl2 | 256 KiB | TF-A or SPL |
+ +-------+--------+---------+-------------+
+ | 3 | ssbl | enought | U-Boot |
+ +-------+--------+---------+-------------+
+ | 4 | <any> | <any> | Rootfs |
+ +-------+--------+---------+-------------+
+
+Add a 4th partition (Rootfs) marked bootable with a file extlinux.conf
+following the Generic Distribution feature (doc/README.distro for use).
+
+According the used card reader select the correct block device
+(for example /dev/sdx or /dev/mmcblk0).
+
+In the next example, it is /dev/mmcblk0
+
+For example: with gpt table with 128 entries
+
+a) remove previous formatting::
+
+ # sgdisk -o /dev/<SD card dev>
+
+b) create minimal image::
+
+ # sgdisk --resize-table=128 -a 1 \
+ -n 1:34:545 -c 1:fsbl1 \
+ -n 2:546:1057 -c 2:fsbl2 \
+ -n 3:1058:5153 -c 3:ssbl \
+ -n 4:5154: -c 4:rootfs \
+ -p /dev/<SD card dev>
+
+ With other partition for kernel one partition rootfs for kernel.
+
+c) copy the FSBL (2 times) and SSBL file on the correct partition.
+ in this example in partition 1 to 3
+
+ for basic boot mode : <SD card dev> = /dev/mmcblk0::
+
+ # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
+ # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
+ # dd if=u-boot.img of=/dev/mmcblk0p3 # Without CONFIG_SPL_LOAD_FIT
+ OR
+ dd if=u-boot.itb of=/dev/mmcblk0p3 # With CONFIG_SPL_LOAD_FIT=y
+
+ for trusted boot mode: ::
+
+ # dd if=tf-a.stm32 of=/dev/mmcblk0p1
+ # dd if=tf-a.stm32 of=/dev/mmcblk0p2
+ # dd if=u-boot.stm32 of=/dev/mmcblk0p3
+
+To boot from SD card, select BootPinMode = 1 0 1 and reset.
+
+Prepare eMMC
+------------
+
+You can use U-Boot to copy binary in eMMC.
+
+In the next example, you need to boot from SD card and the images
+(u-boot-spl.stm32, u-boot.img for systems without CONFIG_SPL_LOAD_FIT
+or u-boot.itb for systems with CONFIG_SPL_LOAD_FIT=y) are presents on
+SD card (mmc 0) in ext4 partition 4 (bootfs).
+
+To boot from SD card, select BootPinMode = 1 0 1 and reset.
+
+Then you update the eMMC with the next U-Boot command :
+
+a) prepare GPT on eMMC,
+ example with 2 partitions, bootfs and roots::
+
+ # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
+ # gpt write mmc 1 ${emmc_part}
+
+b) copy SPL on eMMC on firts boot partition
+ (SPL max size is 256kB, with LBA 512, 0x200)::
+
+ # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
+ # mmc dev 1
+ # mmc partconf 1 1 1 1
+ # mmc write ${fileaddr} 0 200
+ # mmc partconf 1 1 1 0
+
+c) copy U-Boot in first GPT partition of eMMC::
+
+ # ext4load mmc 0:4 0xC0000000 u-boot.img # Without CONFIG_SPL_LOAD_FIT
+ OR
+ ext4load mmc 0:4 0xC0000000 u-boot.itb # With CONFIG_SPL_LOAD_FIT=y
+ # mmc dev 1
+ # part start mmc 1 1 partstart
+ # mmc write ${fileaddr} ${partstart} ${filesize}
+
+To boot from eMMC, select BootPinMode = 0 1 0 and reset.
+
+MAC Address
+-----------
+
+Please read doc/README.enetaddr for the implementation guidelines for mac id
+usage. Basically, environment has precedence over board specific storage.
+
+For STMicroelectonics board, it is retrieved in STM32MP15x OTP :
+
+ - OTP_57[31:0] = MAC_ADDR[31:0]
+ - OTP_58[15:0] = MAC_ADDR[47:32]
+
+To program a MAC address on virgin OTP words above, you can use the fuse command
+on bank 0 to access to internal OTP and lock them:
+
+Prerequisite: check if a MAC address isn't yet programmed in OTP
+
+1) check OTP: their value must be equal to 0::
+
+ STM32MP> fuse sense 0 57 2
+ Sensing bank 0:
+ Word 0x00000039: 00000000 00000000
+
+2) check environment variable::
+
+ STM32MP> env print ethaddr
+ ## Error: "ethaddr" not defined
+
+3) check lock status of fuse 57 & 58 (at 0x39, 0=unlocked, 1=locked)::
+
+ STM32MP> fuse sense 0 0x10000039 2
+ Sensing bank 0:
+ Word 0x10000039: 00000000 00000000
+
+Example to set mac address "12:34:56:78:9a:bc"
+
+1) Write OTP::
+
+ STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
+
+2) Read OTP::
+
+ STM32MP> fuse sense 0 57 2
+ Sensing bank 0:
+ Word 0x00000039: 78563412 0000bc9a
+
+3) Lock OTP::
+
+ STM32MP> fuse prog 0 0x10000039 1 1
+
+ STM32MP> fuse sense 0 0x10000039 2
+ Sensing bank 0:
+ Word 0x10000039: 00000001 00000001
+
+4) next REBOOT, in the trace::
+
+ ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
+
+5) check env update::
+
+ STM32MP> env print ethaddr
+ ethaddr=12:34:56:78:9a:bc
+
+.. warning:: This command can't be executed twice on the same board as
+ OTP are protected. It is already done for the board
+ provided by STMicroelectronics.
+
+Coprocessor firmware
+--------------------
+
+U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
+
+a) Manuallly by using rproc commands (update the bootcmd)
+
+ Configurations::
+
+ # env set name_copro "rproc-m4-fw.elf"
+ # env set dev_copro 0
+ # env set loadaddr_copro 0xC1000000
+
+ Load binary from bootfs partition (number 4) on SD card (mmc 0)::
+
+ # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
+
+ => ${filesize} variable is updated with the size of the loaded file.
+
+ Start M4 firmware with remote proc command::
+
+ # rproc init
+ # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
+ # rproc start ${dev_copro}"00270033
+
+b) Automatically by using FIT feature and generic DISTRO bootcmd
+
+ see examples in the board stm32mp1 directory: fit_copro_kernel_dtb.its
+
+ Generate FIT including kernel + device tree + M4 firmware with cfg with M4 boot::
+
+ $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
+
+ Then using DISTRO configuration file: see extlinux.conf to select the correct
+ configuration:
+
+ - stm32mp157c-ev1-m4
+ - stm32mp157c-dk2-m4
+
+DFU support
+-----------
+
+The DFU is supported on ST board.
+
+The env variable dfu_alt_info is automatically build, and all
+the memory present on the ST boards are exported.
+
+The dfu mode is started by the command::
+
+ STM32MP> dfu 0
+
+On EV1 board, booting from SD card, without OP-TEE::
+
+ STM32MP> dfu 0 list
+ DFU alt settings list:
+ dev: RAM alt: 0 name: uImage layout: RAM_ADDR
+ dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
+ dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
+ dev: eMMC alt: 3 name: mmc0_fsbl1 layout: RAW_ADDR
+ dev: eMMC alt: 4 name: mmc0_fsbl2 layout: RAW_ADDR
+ dev: eMMC alt: 5 name: mmc0_ssbl layout: RAW_ADDR
+ dev: eMMC alt: 6 name: mmc0_bootfs layout: RAW_ADDR
+ dev: eMMC alt: 7 name: mmc0_vendorfs layout: RAW_ADDR
+ dev: eMMC alt: 8 name: mmc0_rootfs layout: RAW_ADDR
+ dev: eMMC alt: 9 name: mmc0_userfs layout: RAW_ADDR
+ dev: eMMC alt: 10 name: mmc1_boot1 layout: RAW_ADDR
+ dev: eMMC alt: 11 name: mmc1_boot2 layout: RAW_ADDR
+ dev: eMMC alt: 12 name: mmc1_ssbl layout: RAW_ADDR
+ dev: eMMC alt: 13 name: mmc1_bootfs layout: RAW_ADDR
+ dev: eMMC alt: 14 name: mmc1_vendorfs layout: RAW_ADDR
+ dev: eMMC alt: 15 name: mmc1_rootfs layout: RAW_ADDR
+ dev: eMMC alt: 16 name: mmc1_userfs layout: RAW_ADDR
+ dev: MTD alt: 17 name: nor0 layout: RAW_ADDR
+ dev: MTD alt: 18 name: nand0 layout: RAW_ADDR
+ dev: VIRT alt: 19 name: OTP layout: RAW_ADDR
+ dev: VIRT alt: 20 name: PMIC layout: RAW_ADDR
+
+All the supported device are exported for dfu-util tool::
+
+ $> dfu-util -l
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="PMIC", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="OTP", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nand0", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor0", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="mmc1_userfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="mmc1_rootfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="mmc1_vendorfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="mmc1_bootfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="mmc1_ssbl", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="mmc1_boot2", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="mmc1_boot1", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="mmc0_userfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="mmc0_rootfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="mmc0_vendorfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="mmc0_bootfs", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="mmc0_ssbl", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="mmc0_fsbl2", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="mmc0_fsbl1", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
+ Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
+
+You can update the boot device:
+
+- SD card (mmc0) ::
+
+ $> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
+
+- EMMC (mmc1)::
+
+ $> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
+
+- you can also dump the OTP and the PMIC NVM with::
+
+ $> dfu-util -d 0483:5720 -a 19 -U otp.bin
+ $> dfu-util -d 0483:5720 -a 20 -U pmic.bin
+
+
+When the board is booting for nor0 or nand0,
+only the MTD partition on the boot devices are available, for example:
+
+- NOR (nor0 = alt 20) & NAND (nand0 = alt 26) ::
+
+ $> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 22 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 27 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
+
+- NAND (nand0 = alt 21)::
+
+ $> dfu-util -d 0483:5720 -a 22 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 24 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 25 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
diff --git a/roms/u-boot/doc/board/tbs/index.rst b/roms/u-boot/doc/board/tbs/index.rst
new file mode 100644
index 000000000..b677bc624
--- /dev/null
+++ b/roms/u-boot/doc/board/tbs/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+TBS
+===
+
+.. toctree::
+ :maxdepth: 2
+
+ tbs2910
diff --git a/roms/u-boot/doc/board/tbs/tbs2910.rst b/roms/u-boot/doc/board/tbs/tbs2910.rst
new file mode 100644
index 000000000..e97f2b6e6
--- /dev/null
+++ b/roms/u-boot/doc/board/tbs/tbs2910.rst
@@ -0,0 +1,191 @@
+TBS2910 Matrix ARM miniPC
+=========================
+
+Building
+--------
+To build u-boot for the TBS2910 Matrix ARM miniPC, you can use the following
+procedure:
+
+First add the ARM toolchain to your PATH
+
+Then setup the ARCH and cross compilation environment variables.
+
+When this is done you can then build u-boot for the TBS2910 Matrix ARM miniPC
+with the following commands:
+
+.. code-block:: none
+
+ make mrproper
+ make tbs2910_defconfig
+ make
+
+Once the build is complete, you can find the resulting image as u-boot.imx in
+the current directory.
+
+UART
+----
+The UART voltage is at 3.3V and its settings are 115200bps 8N1
+
+BOOT/UPDATE boot switch:
+------------------------
+The BOOT/UPDATE switch (SW11) is connected to the BOOT_MODE0 and
+BOOT_MODE1 SoC pins. It has "BOOT" and "UPDATE" markings both on
+the PCB and on the plastic case.
+
+When set to the "UPDATE" position, the SoC will use the "Boot From Fuses"
+configuration, and since BT_FUSE_SEL is 0, this makes the SOC jump to serial
+downloader.
+
+When set in the "BOOT" position, the SoC will use the "Internal boot"
+configuration, and since BT_FUSE_SEL is 0, it will then use the GPIO pins
+for the boot configuration.
+
+SW6 binary DIP switch array on the PCB revision 2.1:
+----------------------------------------------------
+On that PCB revision, SW6 has 8 positions.
+
+Switching a position to ON sets the corresponding
+register to 1.
+
+See the following table for a correspondence between the switch positions and
+registers:
+
+=============== ============
+Switch position Register
+=============== ============
+1 BOOT_CFG2[3]
+2 BOOT_CFG2[4]
+3 BOOT_CFG2[5]
+4 BOOT_CFG2[6]
+5 BOOT_CFG1[4]
+6 BOOT_CFG1[5]
+7 BOOT_CFG1[6]
+8 BOOT_CFG1[7]
+=============== ============
+
+For example:
+
+ - To boot from the eMMC: 1:ON , 2:ON, 3:ON, 4:OFF, 5:OFF, 6:ON, 7:ON, 8:OFF
+ - To boot from the microSD slot: 1: ON, 2: OFF, 3: OFF, 4: OFF, 5:OFF, 6:OFF,
+ 7:ON, 8:OFF
+ - To boot from the SD slot: 1: OFF, 2: ON, 3: OFF, 4: OFF, 5:OFF, 6:OFF, 7:ON,
+ 8:OFF
+ - To boot from SATA: 1: OFF, 2: OFF, 3: OFF, 4: OFF, 5:OFF, 6:ON, 7:OFF, 8:OFF
+
+You can refer to the BOOT_CFG registers in the I.MX6Q reference manual for
+additional details.
+
+SW6 binary DIP switch array on the PCB revision 2.3:
+----------------------------------------------------
+On that PCB revision, SW6 has only 4 positions.
+
+Switching a position to ON sets the corresponding
+register to 1.
+
+See the following table for a correspondence between the switch positions and
+registers:
+
+=============== ============
+Switch position Register
+=============== ============
+1 BOOT_CFG2[3]
+2 BOOT_CFG2[4]
+3 BOOT_CFG2[5]
+4 BOOT_CFG1[5]
+=============== ============
+
+For example:
+
+- To boot from the eMMC: 1:ON, 2:ON, 3:ON, 4:ON
+- To boot from the microSD slot: 1:ON, 2:OFF, 3:OFF, 4:OFF
+- To boot from the SD slot: 1:OFF, 2:ON, 3:OFF, 4:OFF
+
+You can refer to the BOOT_CFG registers in the I.MX6Q reference manual for
+additional details.
+
+Loading u-boot from USB:
+------------------------
+If you need to load u-boot from USB, you can use the following instructions:
+
+First build imx_usb_loader, as we will need it to load u-boot from USB. This
+can be done with the following commands:
+
+.. code-block:: none
+
+ git clone git://github.com/boundarydevices/imx_usb_loader.git
+ cd imx_usb_loader
+ make
+
+This will create the resulting imx_usb binary.
+
+When this is done, you can copy the u-boot.imx image that you built earlier
+in in the imx_usb_loader directory.
+
+You will then need to power off the TBS2910 Matrix ARM miniPC and make sure that
+the boot switch is set to "UPDATE"
+
+Once this is done you can connect an USB cable between the computer that will
+run imx_usb and the TBS2910 Matrix ARM miniPC.
+
+If you also need to access the u-boot console, you will also need to connect an
+UART cable between the computer running imx_usb and the TBS2910 Matrix ARM
+miniPC.
+
+Once everything is connected you can finally power on the TBS2910 Matrix ARM
+miniPC. The SoC will then jump to the serial download and wait for you.
+
+Finlay, you can load u-boot through USB with with the following command:
+
+.. code-block:: none
+
+ sudo ./imx_usb -v u-boot.imx
+
+The u-boot boot messages will then appear in the serial console.
+
+Install u-boot on the eMMC:
+---------------------------
+To install u-boot on the eMMC, you first need to boot the TBS2910 Matrix ARM
+miniPC.
+
+Once booted, you can flash u-boot.imx to mmcblk0boot0 with the
+following commands:
+
+.. code-block:: none
+
+ sudo echo 0 >/sys/block/mmcblk0boot0/force_ro
+ sudo dd if=u-boot.imx of=/dev/mmcblk0boot0 bs=1k seek=1; sync
+
+Note that the eMMC card node may vary, so adjust this as needed.
+
+Once the new u-boot version is installed, to boot on it you then need to power
+off the TBS2910 Matrix ARM miniPC.
+
+Once it is off, you need make sure that the boot switch is set to "BOOT" and
+that the SW6 switch is set to boot on the eMMC as described in the previous
+sections.
+
+If you also need to access the u-boot console, you will also need to connect an
+UART cable between the computer running imx_usb and the TBS2910 Matrix ARM
+miniPC.
+
+You can then power up the TBS2910 Matrix ARM miniPC and U-Boot messages will
+appear in the serial console.
+
+Booting a distribution:
+-----------------------
+When booting on the TBS2910 Matrix ARM miniPC, by default U-Boot will first try
+to boot from hardcoded offsets from the start of the eMMC. This is for
+compatibility with the stock GNU/Linux distribution.
+
+If that fails it will then try to boot from several interfaces using
+'distro_bootcmd': It will first try to boot from the microSD slot, then the
+SD slot, then the internal eMMC, then the SATA interface and finally the USB
+interface. For more information on how to configure your distribution to boot,
+see 'README.distro'.
+
+Links:
+------
+ - https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-SCH_rev2.1.pdf
+ - The schematics for the revision 2.1 of the TBS2910 Matrix ARM miniPC.
+ - https://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf - The
+ SoC reference manual for additional details on the BOOT_CFG registers.
diff --git a/roms/u-boot/doc/board/toradex/apalix-imx8.rst b/roms/u-boot/doc/board/toradex/apalix-imx8.rst
new file mode 100644
index 000000000..29593faf1
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/apalix-imx8.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Apalis iMX8QM V1.0B Module
+==========================
+
+Quick Start
+-----------
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ git clone -b imx_4.14.78_1.0.0_ga https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+ bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
+ $ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+ $ chmod +x firmware-imx-8.0.bin
+ $ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+ $ cp imx-atf/build/imx8qm/release/bl31.bin .
+ $ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+ $ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+------------
+.. code-block:: bash
+
+ $ make apalis-imx8_defconfig
+ $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+--------------------------------
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute uuu:
+
+.. code-block:: bash
+
+ sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-------------------------------------
+
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
+partition and boot:
+
+.. code-block:: bash
+
+ load mmc 1:1 $loadaddr u-boot-dtb.imx
+ setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ mmc dev 0 1
+ mmc write ${loadaddr} 0x0 ${blkcnt}
diff --git a/roms/u-boot/doc/board/toradex/apalix-imx8x.rst b/roms/u-boot/doc/board/toradex/apalix-imx8x.rst
new file mode 100644
index 000000000..e62578b15
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/apalix-imx8x.rst
@@ -0,0 +1,77 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Apalis iMX8X V1.1A Module (SoC NXP i.MX8QXP RevB)
+=================================================
+
+Quick Start
+-----------
+
+- Get and Build the ARM trusted firmware
+- Get System Controller firmware
+- Get SECO container
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Note: builddir is U-Boot build directory (source directory for in-tree builds)
+
+Get and Build the ARM Trusted Firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ cd $(builddir)
+ $ git clone -b toradex_imx_5.4.70_2.3.0 http://git.toradex.com/cgit/imx-atf.git
+ $ make PLAT=imx8qx bl31 -C imx-atf
+ $ cp imx-atf/build/imx8qx/release/bl31.bin $(builddir)
+
+Get System Controller firmware
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://github.com/toradex/i.MX-System-Controller-Firmware/raw/master/src/scfw_export_mx8qx_b0/build_mx8qx_b0/mx8qx-apalis-scfw-tcm.bin
+
+Get SECO container
+---------------------------------------
+
+.. code-block:: bash
+
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin
+ $ sh imx-seco-3.7.4.bin
+ $ cp imx-seco-3.7.4/firmware/seco/mx8qxb0-ahab-container.img $(builddir)/mx8qx-ahab-container.img
+
+Build U-Boot
+------------
+.. code-block:: bash
+
+ $ make apalis-imx8x_defconfig
+ $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+--------------------------------
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute uuu:
+
+.. code-block:: bash
+
+ sudo ./uuu $(builddir)/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-------------------------------------
+
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
+partition and boot:
+
+.. code-block:: bash
+
+ load mmc 1:1 $loadaddr u-boot-dtb.imx
+ setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ mmc dev 0 1
+ mmc write ${loadaddr} 0x0 ${blkcnt}
diff --git a/roms/u-boot/doc/board/toradex/colibri-imx8x.rst b/roms/u-boot/doc/board/toradex/colibri-imx8x.rst
new file mode 100644
index 000000000..616f40ae0
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/colibri-imx8x.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX8QXP V1.0B Module
+============================
+
+Quick Start
+-----------
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--------------------------------------
+
+.. code-block:: bash
+
+ $ git clone -b imx_4.14.78_1.0.0_ga https://source.codeaurora.org/external/imx/imx-atf
+ $ cd imx-atf/
+ $ make PLAT=imx8qxp bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---------------------------------------
+.. code-block:: bash
+
+ $ wget https://github.com/toradex/meta-fsl-bsp-release/blob/
+ toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+ bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
+ $ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+ $ chmod +x firmware-imx-8.0.bin
+ $ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+ $ cp imx-atf/build/imx8qxp/release/bl31.bin .
+ $ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+ $ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ make colibri-imx8x_defconfig
+ $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+--------------------------------
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute ``uuu``:
+
+.. code-block:: bash
+
+ sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-------------------------------------
+
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area partition:
+
+.. code-block:: bash
+
+ load mmc 1:1 $loadaddr u-boot-dtb.imx
+ setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ mmc dev 0 1
+ mmc write ${loadaddr} 0x0 ${blkcnt}
diff --git a/roms/u-boot/doc/board/toradex/colibri_imx7.rst b/roms/u-boot/doc/board/toradex/colibri_imx7.rst
new file mode 100644
index 000000000..a30e72137
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/colibri_imx7.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX7
+============
+
+Quick Start
+-----------
+
+- Build U-Boot
+- NAND IMX image adjustments before flashing
+- Flashing manually U-Boot to eMMC
+- Flashing manually U-Boot to NAND
+- Using ``update_uboot`` script
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=arm-linux-gnueabi-
+ $ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
+ $ make
+
+After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
+image, ready for flashing (but check next section for additional
+adjustments).
+
+Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
+<https://www.nxp.com/webapp/Download?colCode=IMX7DRM>`_):
+
+* **Image vector table** (IVT) for BootROM
+* **Boot data** -indicates the program image location, program image size
+ in bytes, and the plugin flag.
+* **Device configuration data**
+* **User image**: U-Boot image (``u-boot-dtb.bin``)
+
+
+IMX image adjustments prior to flashing
+---------------------------------------
+
+1. U-Boot for both Colibri iMX7 NAND and eMMC versions
+is built with HABv4 support (`AN4581.pdf
+<https://www.nxp.com/docs/en/application-note/AN4581.pdf>`_)
+enabled by default, which requires to generate a proper
+Command Sequence File (CSF) by srktool from NXP (not included in the
+U-Boot tree, check additional details in introduction_habv4.txt)
+and concatenate it to the final ``u-boot-dtb.imx``.
+
+2. In case if you don't want to generate a proper ``CSF`` (for any reason),
+you still need to pad the IMX image so i has the same size as specified in
+in **Boot Data** section of IMX image.
+To obtain this value, run:
+
+.. code-block:: bash
+
+ $ od -X -N 0x30 u-boot-dtb.imx
+ 0000000 402000d1 87800000 00000000 877ff42c
+ 0000020 877ff420 877ff400 878a5000 00000000
+ ^^^^^^^^
+ 0000040 877ff000 000a8060 00000000 40b401d2
+ ^^^^^^^^ ^^^^^^^^
+
+Where:
+
+* ``877ff400`` - IVT self address
+* ``877ff000`` - Program image address
+* ``000a8060`` - Program image size
+
+To calculate the padding:
+
+* IVT offset = ``0x877ff400`` - ``0x877ff000`` = ``0x400``
+* Program image size = ``0xa8060`` - ``0x400`` = ``0xa7c60``
+
+and then pad the image:
+
+.. code-block:: bash
+
+ $ objcopy -I binary -O binary --pad-to 0xa7c60 --gap-fill=0x00 \
+ u-boot-dtb.imx u-boot-dtb.imx.zero-padded
+
+3. Also, according to requirement from ``6.6.7.1``, the final image
+should have ``0x400`` offset for initial IVT table.
+
+For eMMC setup we handle this by flashing it to ``0x400``, howewer
+for NAND setup we adjust the image prior to flashing, adding padding in the
+beginning of the image.
+
+.. code-block:: bash
+
+ $ dd if=u-boot-dtb.imx.zero-padded of=u-boot-dtb.imx.ready bs=1024 seek=1
+
+Flash U-Boot IMX image to eMMC
+------------------------------
+
+Flash the ``u-boot-dtb.imx.zero-padded`` binary to the primary eMMC hardware
+boot area partition:
+
+.. code-block:: bash
+
+
+ => load mmc 1:1 $loadaddr u-boot-dtb.imx.zero-padded
+ => setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ => mmc dev 0 1
+ => mmc write ${loadaddr} 0x2 ${blkcnt}
+
+Flash U-Boot IMX image to NAND
+------------------------------
+
+.. code-block:: bash
+
+ => load mmc 1:1 $loadaddr u-boot-dtb.imx.ready
+ => nand erase.part u-boot1
+ => nand write ${loadaddr} u-boot1 ${filesize}
+ => nand erase.part u-boot2
+ => nand write ${loadaddr} u-boot2 ${filesize}
+
+Using update_uboot script
+-------------------------
+
+You can also usb U-Boot env update_uboot script,
+which wraps all eMMC/NAND specific command invocation:
+
+.. code-block:: bash
+
+ => load mmc 1:1 $loadaddr u-boot-dtb.imx.ready
+ => run update_uboot
diff --git a/roms/u-boot/doc/board/toradex/index.rst b/roms/u-boot/doc/board/toradex/index.rst
new file mode 100644
index 000000000..abba648f8
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/index.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Toradex
+=======
+
+.. toctree::
+ :maxdepth: 2
+
+ apalix-imx8
+ apalix-imx8x
+ colibri_imx7
+ colibri-imx8x
+ verdin-imx8mm
diff --git a/roms/u-boot/doc/board/toradex/verdin-imx8mm.rst b/roms/u-boot/doc/board/toradex/verdin-imx8mm.rst
new file mode 100644
index 000000000..b9f7dc39c
--- /dev/null
+++ b/roms/u-boot/doc/board/toradex/verdin-imx8mm.rst
@@ -0,0 +1,98 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Verdin iMX8M Mini Module
+========================
+
+Quick Start
+-----------
+
+- Build the ARM trusted firmware binary
+- Get the DDR firmware
+- Build U-Boot
+- Flash to eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware (Trusted Firmware A)
+-----------------------------------------------------------
+
+.. code-block:: bash
+
+ $ echo "Downloading and building TF-A..."
+ $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
+ $ cd trusted-firmware-a
+
+Then build ATF (TF-A):
+
+.. code-block:: bash
+
+ $ make PLAT=imx8mm IMX_BOOT_UART_BASE=0x30860000 bl31
+ $ cp build/imx8mm/release/bl31.bin ../
+
+Get the DDR Firmware
+--------------------
+
+.. code-block:: bash
+
+ $ cd ..
+ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
+ $ chmod +x firmware-imx-8.4.1.bin
+ $ ./firmware-imx-8.4.1.bin
+ $ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
+
+Build U-Boot
+------------
+.. code-block:: bash
+
+ $ export CROSS_COMPILE=aarch64-linux-gnu-
+ $ export ATF_LOAD_ADDR=0x920000
+ $ make verdin-imx8mm_defconfig
+ $ make flash.bin
+
+Flash to eMMC
+-------------
+
+.. code-block:: bash
+
+ > tftpboot ${loadaddr} flash.bin
+ > setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ > mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
+
+As a convenience, instead of the last two commands one may also use the update
+U-Boot wrapper:
+
+.. code-block:: bash
+
+ > run update_uboot
+
+Boot
+----
+
+ATF, U-Boot proper and u-boot.dtb images are packed into FIT image,
+which is loaded and parsed by SPL.
+
+Boot sequence is:
+
+* SPL ---> ATF (TF-A) ---> U-Boot proper
+
+Output:
+
+.. code-block:: bash
+
+ U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
+ Normal Boot
+ Trying to boot from MMC1
+
+ U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
+
+ CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
+ Reset cause: POR
+ DRAM: 2 GiB
+ MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
+ Loading Environment from MMC... OK
+ In: serial
+ Out: serial
+ Err: serial
+ Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial:
+ Net: eth0: ethernet@30be0000
+ Hit any key to stop autoboot: 0
+ Verdin iMX8MM #
diff --git a/roms/u-boot/doc/board/xen/index.rst b/roms/u-boot/doc/board/xen/index.rst
new file mode 100644
index 000000000..e58fe9e35
--- /dev/null
+++ b/roms/u-boot/doc/board/xen/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+XenGuestARM64
+=============
+
+.. toctree::
+ :maxdepth: 2
+
+ xenguest_arm64
diff --git a/roms/u-boot/doc/board/xen/xenguest_arm64.rst b/roms/u-boot/doc/board/xen/xenguest_arm64.rst
new file mode 100644
index 000000000..1327f88f9
--- /dev/null
+++ b/roms/u-boot/doc/board/xen/xenguest_arm64.rst
@@ -0,0 +1,81 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xen guest ARM64 board
+=====================
+
+This board specification
+------------------------
+
+This board is to be run as a virtual Xen [1] guest with U-boot as its primary
+bootloader. Xen is a type 1 hypervisor that allows multiple operating systems
+to run simultaneously on a single physical server. Xen is capable of running
+virtual machines in both full virtualization and para-virtualization (PV)
+modes. Xen runs virtual machines, which are called “domains”.
+
+Paravirtualized drivers are a special type of device drivers that are used in
+a guest system in the Xen domain and perform I/O operations using a special
+interface provided by the virtualization system and the host system.
+
+Xen support for U-boot is implemented by introducing a new Xen guest ARM64
+board and porting essential drivers from MiniOS [3] as well as some of the work
+previously done by NXP [4]:
+
+- PV block device frontend driver with XenStore based device enumeration and
+ UCLASS_PVBLOCK class;
+- PV serial console device frontend driver;
+- Xen hypervisor support with minimal set of the essential headers adapted from
+ the Linux kernel;
+- Xen grant table support;
+- Xen event channel support in polling mode;
+- XenBus support;
+- dynamic RAM size as defined in the device tree instead of the statically
+ defined values;
+- position-independent pre-relocation code is used as we cannot statically
+ define any start addresses at compile time which is up to Xen to choose at
+ run-time;
+- new defconfig introduced: xenguest_arm64_defconfig.
+
+
+Board limitations
+-----------------
+
+1. U-boot runs without MMU enabled at the early stages.
+ According to Xen on ARM ABI (xen/include/public/arch-arm.h): all memory
+ which is shared with other entities in the system (including the hypervisor
+ and other guests) must reside in memory which is mapped as Normal Inner
+ Write-Back Outer Write-Back Inner-Shareable.
+ Thus, page attributes must be equally set for all the entities working with
+ that page.
+ Before MMU is set up the data cache is turned off and pages are seen by the
+ vCPU and Xen in different ways - cacheable by Xen and non-cacheable by vCPU.
+ So it means that manual data cache maintenance is required at the early
+ stages.
+
+2. No serial console until MMU is up.
+ Because data cache maintenance is required until the MMU setup the
+ early/debug serial console is not implemented. Therefore, we do not have
+ usual prints like U-boot’s banner etc. until the serial driver is
+ initialized.
+
+3. Single RAM bank supported.
+ If a Xen guest is given much memory it is possible that Xen allocates two
+ memory banks for it. The first one is allocated under 4GB address space and
+ in some cases may represent the whole guest’s memory. It is assumed that
+ U-boot most likely won’t require high memory bank for its work andlaunching
+ OS, so it is enough to take the first one.
+
+
+Board default configuration
+---------------------------
+
+One can select the configuration as follows:
+
+ - make xenguest_arm64_defconfig
+
+[1] - https://xenproject.org/
+
+[2] - https://wiki.xenproject.org/wiki/Paravirtualization_(PV)
+
+[3] - https://wiki.xenproject.org/wiki/Mini-OS
+
+[4] - https://source.codeaurora.org/external/imx/uboot-imx/tree/?h=imx_v2018.03_4.14.98_2.0.0_ga
diff --git a/roms/u-boot/doc/board/xilinx/index.rst b/roms/u-boot/doc/board/xilinx/index.rst
new file mode 100644
index 000000000..2e31fe3f3
--- /dev/null
+++ b/roms/u-boot/doc/board/xilinx/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xilinx
+======
+
+.. toctree::
+ :maxdepth: 2
+
+ xilinx
+ zynq
+ zynqmp
+ zynqmp-r5
diff --git a/roms/u-boot/doc/board/xilinx/xilinx.rst b/roms/u-boot/doc/board/xilinx/xilinx.rst
new file mode 100644
index 000000000..8c9afb482
--- /dev/null
+++ b/roms/u-boot/doc/board/xilinx/xilinx.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2019 Xilinx, Inc.
+
+U-Boot device tree bindings
+----------------------------
+
+All the device tree bindings used in U-Boot are specified in Linux
+kernel. Please refer dt bindings from below specified paths in Linux
+kernel.
+
+* ata
+ - Documentation/devicetree/bindings/ata/ahci-ceva.txt
+* clock
+ - Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
+* firmware
+ - Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+* fpga
+ - Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
+* gpio
+ - Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+ - Documentation/devicetree/bindings/gpio/gpio-zynq.txt
+* i2c
+ - Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+ - Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
+* mmc
+ - Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
+* net
+ - Documentation/devicetree/bindings/net/macb.txt
+ - Documentation/devicetree/bindings/net/xilinx_axienet.txt
+ - Documentation/devicetree/bindings/net/xilinx_emaclite.txt
+* nvmem
+ - Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
+* power
+ - Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt
+* serial
+ - Documentation/devicetree/bindings/serial/cdns,uart.txt
+ - Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt
+* spi
+ - Documentation/devicetree/bindings/spi/spi-cadence.txt
+ - Documentation/devicetree/bindings/spi/spi-xilinx.txt
+ - Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+ - Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
+* usb
+ - Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
+ - Documentation/devicetree/bindings/usb/dwc3.txt
+ - Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+* wdt
+ - Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
diff --git a/roms/u-boot/doc/board/xilinx/zynq.rst b/roms/u-boot/doc/board/xilinx/zynq.rst
new file mode 100644
index 000000000..438912fe4
--- /dev/null
+++ b/roms/u-boot/doc/board/xilinx/zynq.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2013 Xilinx, Inc.
+
+ZYNQ
+====
+
+About this
+----------
+
+This document describes the information about Xilinx Zynq U-Boot -
+like supported boards, ML status and TODO list.
+
+Zynq boards
+-----------
+
+Xilinx Zynq-7000 All Programmable SoCs enable extensive system level
+differentiation, integration, and flexibility through hardware, software,
+and I/O programmability.
+
+* zc702 (single qspi, gem0, mmc) [1]
+* zc706 (dual parallel qspi, gem0, mmc) [2]
+* zed (single qspi, gem0, mmc) [3]
+* microzed (single qspi, gem0, mmc) [4]
+* zc770
+ - zc770-xm010 (single qspi, gem0, mmc)
+ - zc770-xm011 (8 or 16 bit nand)
+ - zc770-xm012 (nor)
+ - zc770-xm013 (dual parallel qspi, gem1)
+
+Building
+--------
+
+configure and build for zc702 board::
+
+ $ export DEVICE_TREE=zynq-zc702
+ $ make xilinx_zynq_virt_defconfig
+ $ make
+
+Bootmode
+--------
+
+Zynq has a facility to read the bootmode from the slcr bootmode register
+once user is setting through jumpers on the board - see page no:1546 on [5]
+
+All possible bootmode values are defined in Table 6-2:Boot_Mode MIO Pins
+on [5].
+
+board_late_init() will read the bootmode values using slcr bootmode register
+at runtime and assign the modeboot variable to specific bootmode string which
+is intern used in autoboot.
+
+SLCR bootmode register Bit[3:0] values
+
+.. code-block:: c
+
+ #define ZYNQ_BM_NOR 0x02
+ #define ZYNQ_BM_SD 0x05
+ #define ZYNQ_BM_JTAG 0x0
+
+"modeboot" variable can assign any of "norboot", "sdboot" or "jtagboot"
+bootmode strings at runtime.
+
+Flashing
+--------
+
+SD Card
+^^^^^^^
+
+To write an image that boots from a SD card first create a FAT32 partition
+and a FAT32 filesystem on the SD card::
+
+ sudo fdisk /dev/sdx
+ sudo mkfs.vfat -F 32 /dev/sdx1
+
+Mount the SD card and copy the SPL and U-Boot to the root directory of the
+SD card::
+
+ sudo mount -t vfat /dev/sdx1 /mnt
+ sudo cp spl/boot.bin /mnt
+ sudo cp u-boot.img /mnt
+
+Mainline status
+---------------
+
+- Added basic board configurations support.
+- Added zynq u-boot bsp code - arch/arm/mach-zynq
+- Added zynq boards named - zc70x, zed, microzed, zc770_xm010/xm011/xm012/xm013
+- Added zynq drivers:
+
+ :serial: drivers/serial/serial_zynq.c
+ :net: drivers/net/zynq_gem.c
+ :mmc: drivers/mmc/zynq_sdhci.c
+ :spi: drivers/spi/zynq_spi.c
+ :qspi: drivers/spi/zynq_qspi.c
+ :i2c: drivers/i2c/zynq_i2c.c
+ :nand: drivers/mtd/nand/raw/zynq_nand.c
+
+- Done proper cleanups on board configurations
+- Added basic FDT support for zynq boards
+- d-cache support for zynq_gem.c
+
+* [1] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm
+* [2] http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm
+* [3] http://zedboard.org/product/zedboard
+* [4] http://zedboard.org/product/microzed
+* [5] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
+
+
+.. Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
+.. Sun Dec 15 14:52:41 IST 2013
diff --git a/roms/u-boot/doc/board/xilinx/zynqmp-r5.rst b/roms/u-boot/doc/board/xilinx/zynqmp-r5.rst
new file mode 100644
index 000000000..2cd368b03
--- /dev/null
+++ b/roms/u-boot/doc/board/xilinx/zynqmp-r5.rst
@@ -0,0 +1,137 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. (C) Copyright 2020 Xilinx, Inc.
+
+ZYNQMP-R5
+=========
+
+About this
+----------
+
+This document describes the information about Xilinx Zynq UltraScale+ MPSOC
+U-Boot Cortex R5 support.
+
+ZynqMP R5 boards
+----------------
+
+* zynqmp-r5 - U-Boot running on RPU Cortex-R5
+
+Building
+--------
+
+configure and build armv7 toolchain::
+
+ $ make xilinx_zynqmp_r5_defconfig
+ $ make
+
+Notes
+^^^^^
+
+Output fragment is u-boot.
+
+Loading
+-------
+
+ZynqMP R5 U-Boot was created for supporting loading OS on RPU. There are two
+ways how to start U-Boot on R5.
+
+Bootgen
+^^^^^^^
+
+The first way is to use Xilinx FSBL (First stage
+bootloader) to load u-boot and start it. The following bif can be used for boot
+image generation via Xilinx bootgen utility::
+
+
+ the_ROM_image:
+ {
+ [bootloader,destination_cpu=r5-0] fsbl_rpu.elf
+ [destination_cpu=r5-0]u-boot.elf
+ }
+
+Bootgen command for building boot.bin::
+
+ bootgen -image <bif>.bif -r -w -o i boot.bin
+
+
+U-Boot cpu command
+^^^^^^^^^^^^^^^^^^
+
+The second way to load U-Boot to Cortex R5 is from U-Boot running on A53 as is
+visible from the following log::
+
+ U-Boot SPL 2020.10-rc4-00090-g801b3d5c5757 (Sep 15 2020 - 14:07:24 +0200)
+ PMUFW: v1.1
+ Loading new PMUFW cfg obj (2024 bytes)
+ EL Level: EL3
+ Multiboot: 0
+ Trying to boot from MMC2
+ spl: could not initialize mmc. error: -19
+ Trying to boot from MMC1
+ spl_load_image_fat_os: error reading image u-boot.bin, err - -2
+ NOTICE: ATF running on XCZU7EG/EV/silicon v4/RTL5.1 at 0xfffea000
+ NOTICE: BL31: v2.2(release):v2.2-614-ged9dc512fb9c
+ NOTICE: BL31: Built : 09:32:09, Mar 13 2020
+
+
+ U-Boot 2020.10-rc4-00090-g801b3d5c5757 (Sep 15 2020 - 14:07:24 +0200)
+
+ Model: ZynqMP ZCU104 RevC
+ Board: Xilinx ZynqMP
+ DRAM: 2 GiB
+ PMUFW: v1.1
+ EL Level: EL2
+ Chip ID: zu7e
+ WDT: Started with servicing (60s timeout)
+ NAND: 0 MiB
+ MMC: mmc@ff170000: 0
+ Loading Environment from FAT... *** Warning - bad CRC, using default environment
+
+ In: serial
+ Out: serial
+ Err: serial
+ Bootmode: LVL_SHFT_SD_MODE1
+ Reset reason: SOFT
+ Net:
+ ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id
+ eth0: ethernet@ff0e0000
+ Hit any key to stop autoboot: 0
+ ZynqMP> setenv autoload no
+ ZynqMP> dhcp
+ BOOTP broadcast 1
+ DHCP client bound to address 192.168.0.167 (8 ms)
+ ZynqMP> tftpboot 20000000 192.168.0.105:u-boot-r5-2.elf
+ Using ethernet@ff0e0000 device
+ TFTP from server 192.168.0.105; our IP address is 192.168.0.167
+ Filename 'u-boot-r5-2.elf'.
+ Load address: 0x20000000
+ Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ################
+ 376 KiB/s
+ done
+ Bytes transferred = 2075464 (1fab48 hex)
+ ZynqMP> setenv autostart no
+ ZynqMP> bootelf -p 20000000
+ ZynqMP> cpu 4 release 10000000 lockstep
+ Using TCM jump trampoline for address 0x10000000
+ R5 lockstep mode
+ ZynqMP>
+
+Then on second uart you can see U-Boot up and running on R5::
+
+ U-Boot 2020.10-rc4-00071-g7045622cc9ba (Sep 16 2020 - 13:38:53 +0200)
+
+ Model: Xilinx ZynqMP R5
+ DRAM: 512 MiB
+ MMC:
+ In: serial@ff010000
+ Out: serial@ff010000
+ Err: serial@ff010000
+ Net: No ethernet found.
+ ZynqMP r5>
+
+Please make sure MIO pins for uart are properly configured to see output.
diff --git a/roms/u-boot/doc/board/xilinx/zynqmp.rst b/roms/u-boot/doc/board/xilinx/zynqmp.rst
new file mode 100644
index 000000000..a035cff1a
--- /dev/null
+++ b/roms/u-boot/doc/board/xilinx/zynqmp.rst
@@ -0,0 +1,115 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. (C) Copyright 2020 Xilinx, Inc.
+
+ZYNQMP
+======
+
+About this
+----------
+
+This document describes the information about Xilinx Zynq UltraScale+ MPSOC
+U-Boot support. Core support is available in arch/arm/mach-zynqmp folder.
+
+ZynqMP boards
+-------------
+
+* zcu100 (ultra96 v1), zcu102, zcu104, zcu106 - Evaluation boards
+* zc1232 - Characterization boards
+* zcu111, zcu208, zcu216 - RFSOC evaluation boards
+* zcu1254, zcu1275, zcu1285 - RFSOC characterization boards
+* a2197 - System Controller on Versal boards
+* mini - Mini U-Boot running out of OCM
+* zc1751 - Characterization Processor boards
+ - zc1751-xm015-dc1
+ - zc1751-xm016-dc2
+ - zc1751-xm017-dc3
+ - zc1751-xm018-dc4
+ - zc1751-xm019-dc5
+
+Building
+--------
+
+Configure and build for zcu102 board::
+
+ $ source arm64 toolchain
+ $ export DEVICE_TREE=zynqmp-zcu102-revA
+ $ make xilinx_zynqmp_virt_defconfig
+ $ make
+
+U-Boot SPL flow
+---------------
+
+For getting U-Boot SPL flow up and running it is necessary to do some additional
+steps because booting device requires external images which are not the part of
+U-Boot repository.
+
+PMU firmware
+^^^^^^^^^^^^
+The Platform Management Unit (PMU) RAM can be loaded with a firmware (PMU
+Firmware) at run-time and can be used to extend or customize the functionality
+of PMU. The PMU firmware is the part of boot image (boot.bin) and it is
+automatically loaded by BootROM. boot.bin can be directly generated by mkimage
+tool as the part of make. If you want to create boot.bin with PMU Firmware
+include please point CONFIG_PMUFW_INIT_FILE to PMU firmware binary. For example:::
+
+ CONFIG_PMUFW_INIT_FILE="<path>/pmu.bin"
+
+If you see below message you need to load PMU Firmware::
+
+ PMUFW is not found - Please load it!
+
+The second external blob is PMU Configuration object which is object which is
+passed from U-Boot SPL to PMU Firmware for initial system configuration. PMU
+configuration object is the part of U-Boot SPL image. For pointing to this
+object please use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE symbol. For example:::
+
+ CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="<path>/pmu_obj.bin"
+
+
+PMU configuration object
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Object can be obtain in several ways. The easiest way is to take pm_cfg_obj.c
+from SDK/Vitis design and build it:::
+
+ $ git clone https://github.com/Xilinx/embeddedsw.git
+ $ export EMBEDDED_SW=$PWD/embeddedsw
+ $ gcc -c pm_cfg_obj.c -I ${EMBEDDED_SW}/lib/bsp/standalone/src/common/ -I ${EMBEDDED_SW}/lib/sw_services/xilpm/src/zynqmp/client/common/
+ $ objcopy -O binary pm_cfg_obj.o pmu_obj.bin
+
+The second way is to use tools/zynqmp_pm_cfg_obj_convert.py. For more
+information about this tool please run it with -h parameter.
+
+The third way is to extract it from Xilinx FSBL elf file. Object is starting at
+XPm_ConfigObject symbol.
+
+
+Arm Trusted Firmware (ATF)
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+U-Boot itself can run from EL3 to EL1. Without ATF U-Boot runs in EL3. Boot flow
+is U-Boot SPL->U-Boot in EL3. When ATF is used U-Boot normally runs in EL2. Boot
+flow is U-Boot SPL->ATF->U-Boot in EL2. As the part of build process u-boot.itb
+is generated. When BL31 shell variable is present u-boot.itb is generated with
+ATF included. You can point to it by:::
+
+ $ export BL31=<path>/bl31.bin
+
+Flashing
+--------
+
+SD Card
+^^^^^^^
+
+To write an image that boots from a SD card first create a FAT32 partition
+and a FAT32 filesystem on the SD card::
+
+ sudo fdisk /dev/sdx
+ sudo mkfs.vfat -F 32 /dev/sdx1
+
+Mount the SD card and copy the SPL and U-Boot to the root directory of the
+SD card::
+
+ sudo mount -t vfat /dev/sdx1 /mnt
+ sudo cp spl/boot.bin /mnt
+ sudo cp u-boot.itb /mnt
diff --git a/roms/u-boot/doc/bounces b/roms/u-boot/doc/bounces
new file mode 100644
index 000000000..d1c5f0d24
--- /dev/null
+++ b/roms/u-boot/doc/bounces
@@ -0,0 +1,3 @@
+# List of addresses picked up by patman/get_maintainer.pl that are known to
+# bounce. Addresses are listed one per line and need to match the author
+# information recorded in git.
diff --git a/roms/u-boot/doc/build/clang.rst b/roms/u-boot/doc/build/clang.rst
new file mode 100644
index 000000000..1d35616eb
--- /dev/null
+++ b/roms/u-boot/doc/build/clang.rst
@@ -0,0 +1,76 @@
+Building with Clang
+===================
+
+The biggest problem when trying to compile U-Boot with Clang is that almost all
+archs rely on storing gd in a global register and the Clang 3.5 user manual
+states: "Clang does not support global register variables; this is unlikely to
+be implemented soon because it requires additional LLVM backend support."
+
+The ARM backend can be instructed not to use the r9 and x18 registers using
+-ffixed-r9 or -ffixed-x18 respectively. As global registers themselves are not
+supported inline assembly is needed to get and set the r9 or x18 value. This
+leads to larger code then strictly necessary, but at least works.
+
+**NOTE:** target compilation only work for _some_ ARM boards at the moment.
+Also AArch64 is not supported currently due to a lack of private libgcc
+support. Boards which reassign gd in c will also fail to compile, but there is
+in no strict reason to do so in the ARM world, since crt0.S takes care of this.
+These assignments can be avoided by changing the init calls but this is not in
+mainline yet.
+
+
+Debian based
+------------
+
+Required packages can be installed via apt, e.g.
+
+.. code-block:: bash
+
+ sudo apt-get install clang
+
+Note that we still use binutils for some tools so we must continue to set
+CROSS_COMPILE. To compile U-Boot with Clang on Linux without IAS use e.g.
+
+.. code-block:: bash
+
+ make HOSTCC=clang rpi_2_defconfig
+ make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \
+ CC="clang -target arm-linux-gnueabi" -j8
+
+It can also be used to compile sandbox:
+
+.. code-block:: bash
+
+ make HOSTCC=clang sandbox_defconfig
+ make HOSTCC=clang CC=clang -j8
+
+
+FreeBSD 11
+----------
+
+Since llvm 3.4 is currently in the base system, the integrated assembler as
+is incapable of building U-Boot. Therefore gas from devel/arm-gnueabi-binutils
+is used instead. It needs a symlink to be picked up correctly though:
+
+.. code-block:: bash
+
+ ln -s /usr/local/bin/arm-gnueabi-freebsd-as /usr/bin/arm-freebsd-eabi-as
+
+The following commands compile U-Boot using the Clang xdev toolchain.
+
+**NOTE:** CROSS_COMPILE and target differ on purpose!
+
+.. code-block:: bash
+
+ export CROSS_COMPILE=arm-gnueabi-freebsd-
+ gmake rpi_2_defconfig
+ gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd" -j8
+
+Given that U-Boot will default to gcc, above commands can be
+simplified with a simple wrapper script - saved as
+/usr/local/bin/arm-gnueabi-freebsd-gcc - listed below:
+
+.. code-block:: bash
+
+ #!/bin/sh
+ exec clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd "$@"
diff --git a/roms/u-boot/doc/build/docker.rst b/roms/u-boot/doc/build/docker.rst
new file mode 100644
index 000000000..953d1b28a
--- /dev/null
+++ b/roms/u-boot/doc/build/docker.rst
@@ -0,0 +1,14 @@
+GitLab CI / U-Boot runner container
+===================================
+
+In order to have a reproducible and portable build environment for CI we use a container for building in. This means that developers can also reproduce the CI environment, to a large degree at least, locally. This file is located in the tools/docker directory. To build the image yourself
+
+.. code-block:: bash
+
+ sudo docker build -t your-namespace:your-tag .
+
+Or to use an existing container
+
+.. code-block:: bash
+
+ sudo docker pull trini/u-boot-gitlab-ci-runner:bionic-20200807-02Sep2020
diff --git a/roms/u-boot/doc/build/gcc.rst b/roms/u-boot/doc/build/gcc.rst
new file mode 100644
index 000000000..c51b3e73b
--- /dev/null
+++ b/roms/u-boot/doc/build/gcc.rst
@@ -0,0 +1,139 @@
+Building with GCC
+=================
+
+Dependencies
+------------
+
+For building U-Boot you need a GCC compiler for your host platform. If you
+are not building on the target platform you further need a GCC cross compiler.
+
+Debian based
+~~~~~~~~~~~~
+
+On Debian based systems the cross compiler packages are named
+gcc-<architecture>-linux-gnu.
+
+You could install GCC and the GCC cross compiler for the ARMv8 architecture with
+
+.. code-block:: bash
+
+ sudo apt-get install gcc gcc-aarch64-linux-gnu
+
+Depending on the build targets further packages maybe needed
+
+.. code-block:: bash
+
+ sudo apt-get install bc bison build-essential coccinelle \
+ device-tree-compiler dfu-util efitools flex gdisk liblz4-tool \
+ libguestfs-tools libncurses-dev libpython3-dev libsdl2-dev libssl-dev \
+ lzma-alone openssl python3 python3-coverage python3-pyelftools \
+ python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme swig
+
+SUSE based
+~~~~~~~~~~
+
+On suse based systems the cross compiler packages are named
+cross-<architecture>-gcc<version>.
+
+You could install GCC and the GCC 10 cross compiler for the ARMv8 architecture
+with
+
+.. code-block:: bash
+
+ sudo zypper install gcc cross-aarch64-gcc10
+
+Depending on the build targets further packages maybe needed.
+
+.. code-block:: bash
+
+ zypper install bc bison flex gcc libopenssl-devel libSDL2-devel make \
+ ncurses-devel python3-devel python3-pytest swig
+
+Prerequisites
+-------------
+
+For some boards you have to build prerequisite files before you can build
+U-Boot, e.g. for the some boards you will need to build the ARM Trusted Firmware
+beforehand. Please, refer to the board specific documentation
+:doc:`../board/index`.
+
+Configuration
+-------------
+
+Directory configs/ contains the template configuration files for the maintained
+boards following the naming scheme::
+
+ <board name>_defconfig
+
+These files have been stripped of default settings. So you cannot use them
+directly. Instead their name serves as a make target to generate the actual
+configuration file .config. For instance the configuration template for the
+Odroid C2 board is called odroid-c2_defconfig. The corresponding .config file
+is generated by
+
+.. code-block:: bash
+
+ make odroid-c2_defconfig
+
+You can adjust the configuration using
+
+.. code-block:: bash
+
+ make menuconfig
+
+Building
+--------
+
+When cross compiling you will have to specify the prefix of the cross-compiler.
+You can either specify the value of the CROSS_COMPILE variable on the make
+command line or export it beforehand.
+
+.. code-block:: bash
+
+ CROSS_COMPILE=<compiler-prefix> make
+
+Assuming cross compiling on Debian for ARMv8 this would be
+
+.. code-block:: bash
+
+ CROSS_COMPILE=aarch64-linux-gnu- make
+
+Build parameters
+~~~~~~~~~~~~~~~~
+
+A list of available parameters for the make command can be obtained via
+
+.. code-block:: bash
+
+ make help
+
+You can speed up compilation by parallelization using the -j parameter, e.g.
+
+.. code-block:: bash
+
+ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc)
+
+Further important build parameters are
+
+* O=<dir> - generate all output files in directory <dir>, including .config
+* V=1 - verbose build
+
+Other build targets
+~~~~~~~~~~~~~~~~~~~
+
+A list of all make targets can be obtained via
+
+.. code-block:: bash
+
+ make help
+
+Important ones are
+
+* clean - remove most generated files but keep the configuration
+* mrproper - remove all generated files + config + various backup files
+
+Installation
+------------
+
+The process for installing U-Boot on the target device is device specific.
+Please, refer to the board specific documentation :doc:`../board/index`.
diff --git a/roms/u-boot/doc/build/index.rst b/roms/u-boot/doc/build/index.rst
new file mode 100644
index 000000000..69952f90d
--- /dev/null
+++ b/roms/u-boot/doc/build/index.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Build U-Boot
+============
+
+.. toctree::
+ :maxdepth: 2
+
+ source
+ gcc
+ clang
+ docker
+ tools
diff --git a/roms/u-boot/doc/build/source.rst b/roms/u-boot/doc/build/source.rst
new file mode 100644
index 000000000..470f79398
--- /dev/null
+++ b/roms/u-boot/doc/build/source.rst
@@ -0,0 +1,30 @@
+Obtaining the source
+=====================
+
+The source of the U-Boot project is maintained in a Git repository.
+
+You can download the source via
+
+.. code-block:: bash
+
+ git clone https://source.denx.de/u-boot/u-boot.git
+
+A mirror of the source is maintained on Github
+
+.. code-block:: bash
+
+ git clone https://github.com/u-boot/u-boot
+
+The released versions are available as tags which use the naming scheme::
+
+ v<year>.<month>
+
+Release candidates are named::
+
+ v<year>.<month>-rc<number>
+
+To checkout the October 2020 release you would use:
+
+.. code-block:: bash
+
+ git checkout v2020.10
diff --git a/roms/u-boot/doc/build/tools.rst b/roms/u-boot/doc/build/tools.rst
new file mode 100644
index 000000000..c06f91527
--- /dev/null
+++ b/roms/u-boot/doc/build/tools.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Host tools
+==========
+
+Building tools for Linux
+------------------------
+
+To allow distributions to distribute all possible tools in a generic way,
+avoiding the need of specific tools building for each machine, a tools only
+defconfig file is provided.
+
+Using this, we can build the tools by doing::
+
+ $ make tools-only_defconfig
+ $ make tools-only
+
+Building tools for Windows
+--------------------------
+If you wish to generate Windows versions of the utilities in the tools directory
+you can use MSYS2, a software distro and building platform for Windows.
+
+Download the MSYS2 installer from https://www.msys2.org. Make sure you have
+installed all required packages below in order to build these host tools::
+
+ * gcc (9.1.0)
+ * make (4.2.1)
+ * bison (3.4.2)
+ * diffutils (3.7)
+ * openssl-devel (1.1.1.d)
+
+Note the version numbers in these parentheses above are the package versions
+at the time being when writing this document. The MSYS2 installer tested is
+http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe.
+
+There are 3 MSYS subsystems installed: MSYS2, MinGW32 and MinGW64. Each
+subsystem provides an environment to build Windows applications. The MSYS2
+environment is for building POSIX compliant software on Windows using an
+emulation layer. The MinGW32/64 subsystems are for building native Windows
+applications using a linux toolchain (gcc, bash, etc), targeting respectively
+32 and 64 bit Windows.
+
+Launch the MSYS2 shell of the MSYS2 environment, and do the following::
+
+ $ make tools-only_defconfig
+ $ make tools-only NO_SDL=1
diff --git a/roms/u-boot/doc/chromium/chainload.rst b/roms/u-boot/doc/chromium/chainload.rst
new file mode 100644
index 000000000..7b6bb10d3
--- /dev/null
+++ b/roms/u-boot/doc/chromium/chainload.rst
@@ -0,0 +1,257 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2020 Google LLC
+
+Running U-Boot from coreboot on Chromebooks
+===========================================
+
+U-Boot can be used as a secondary boot loader in a few situations such as from
+UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on
+ARM platforms to start up the machine.
+
+This document aims to provide a guide to booting U-Boot on a Chromebook. It
+is only a starting point, and there are many guides on the interwebs. But
+placing this information in the U-Boot tree should make it easier to find for
+those who use U-Boot habitually.
+
+Most of these platforms are supported by U-Boot natively, but it is risky to
+replace the ROM unless you have a servo board and cable to restore it with.
+
+
+For all of these the standard U-Boot build instructions apply. For example on
+ARM::
+
+ sudo apt install gcc-arm-linux-gnueabi
+ mkdir b
+ make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all
+
+You can obtain the vbutil_kernel utility here:
+
+ https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U
+
+
+Snow (Samsung ARM Chromebook)
+-----------------------------
+
+See here:
+
+https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook
+
+
+Nyan-big
+--------
+
+Compiled based on information here::
+
+ https://lists.denx.de/pipermail/u-boot/2015-March/209530.html
+ https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big
+ https://lists.denx.de/pipermail/u-boot/2017-May/289491.html
+ https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card
+
+1. Build U-Boot
+
+Steps::
+
+ mkdir b
+ make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all
+
+
+2. Select a .its file
+
+Select something from doc/chromium which matches your board, or create your
+own.
+
+Note that the device tree node is required, even though it is not actually
+used by U-Boot. This is because the Chromebook expects to pass it to the
+kernel, and crashes if it is not present.
+
+
+3. Build and sign an image
+
+Steps::
+
+ ./b/nyan-big/tools/mkimage -f doc/chromium/files/nyan-big.its u-boot-chromium.fit
+ echo test >dummy.txt
+ vbutil_kernel --arch arm \
+ --keyblock doc/chromium/files/devkeys/kernel.keyblock \
+ --signprivate doc/chromium/files/devkeys/kernel_data_key.vbprivk \
+ --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \
+ --bootloader dummy.txt --pack u-boot.kpart
+
+
+4. Prepare an SD card
+
+Steps::
+
+ DISK=/dev/sdc # Replace with your actual SD card device
+ sudo cgpt create $DISK
+ sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK
+ sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK
+ sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk
+
+
+5. Write U-Boot to the SD card
+
+Steps::
+
+ sudo dd if=u-boot.kpart of=/dev/sdc1; sync
+
+
+6. Start it up
+
+Reboot the device in dev mode. Make sure that you have USB booting enabled. To
+do this, login as root (via Ctrl-Alt-forward_arrow) and type
+'enable_dev_usb_boot'. You only need to do this once.
+
+Reboot the device with the SD card inserted. Press Clrl-U at the developer
+mode screen. It should show something like the following on the display::
+
+ U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600)
+
+ Model: Acer Chromebook 13 CB5-311
+ Board: Google/NVIDIA Nyan-big, ID: 1
+
+ Net: No ethernet found.
+ Hit any key to stop autoboot: 0
+ Tegra124 (Nyan-big) #
+
+
+7. Known problems
+
+On the serial console the word MMC is chopped at the start of the line::
+
+ C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0
+
+This is likely due to some problem with change-over of the serial driver
+during relocation (or perhaps updating the clock setup in board_init()).
+
+
+9. Notes
+
+To check that you copied the u-boot.its file correctly, use these commands.
+You should see that the data at 0x100 in u-boot-chromium.fit is the first few
+bytes of U-Boot::
+
+ hd u-boot-chromium.fit |head -20
+ ...
+ 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
+
+ hd b/nyan-big/u-boot.bin |head
+ 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
+
+
+The 'data' property of the FIT is set up to start at offset 0x100 bytes into
+the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes
+from the load address. If this changes, you either need to modify U-Boot to be
+fully relocatable, or expect it to hang.
+
+
+chromebook_jerry
+----------------
+
+The instruction are similar to those for Nyan with changes as noted below:
+
+1. Patch U-Boot
+
+Open include/configs/rk3288_common.h
+
+Change::
+
+ #define CONFIG_SYS_TEXT_BASE 0x00100000
+
+to::
+
+ #define CONFIG_SYS_TEXT_BASE 0x02000100
+
+
+
+2. Build U-Boot
+
+Steps::
+
+ mkdir b
+ make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \
+ chromebook_jerry_defconfig all
+
+
+3. See above
+
+4. Build and sign an image
+
+Steps::
+
+ ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \
+ u-boot-chromium.fit
+ echo test >dummy.txt
+ vbutil_kernel --arch arm \
+ --keyblock doc/chromium/files/devkeys/kernel.keyblock \
+ --signprivate doc/chromium/files/devkeys/kernel_data_key.vbprivk \
+ --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \
+ --bootloader dummy.txt --pack u-boot.kpart
+
+
+5. See above
+
+6. See above
+
+7. Start it up
+
+Reboot the device in dev mode. Make sure that you have USB booting enabled. To
+do this, login as root (via Ctrl-Alt-forward_arrow) and type
+'enable_dev_usb_boot'. You only need to do this once.
+
+Reboot the device with the SD card inserted. Press Clrl-U at the developer
+mode screen. It should show something like the following on the display::
+
+ U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600)
+
+ Model: Google Jerry
+ Net: Net Initialization Skipped
+ No ethernet found.
+ Hit any key to stop autoboot: 0
+
+
+8. Known problems
+
+None as yet.
+
+
+9. Notes
+
+None as yet.
+
+
+Other notes
+-----------
+
+flashrom
+~~~~~~~~
+
+Used to make a backup of your firmware, or to replace it.
+
+See: https://www.chromium.org/chromium-os/packages/cros-flashrom
+
+
+coreboot
+~~~~~~~~
+
+Coreboot itself is not designed to actually boot an OS. Instead, a program
+called Depthcharge is used. This originally came out of U-Boot and was then
+heavily hacked and modified such that is is almost unrecognisable. It does
+include a very small part of the U-Boot command-line interface but is not
+usable as a general-purpose boot loader.
+
+In addition, it has a very unusual design in that it does not do device init
+itself, but instead relies on coreboot. This is similar to (in U-Boot) having
+a SPI driver with an empty probe() method, relying on whatever was set up
+beforehand. It can be quite hard to figure out between these two code bases
+what settings are actually used. When chain-loading into U-Boot we must be
+careful to reinit anything that U-Boot expects. If not, some peripherals (or
+the whole machine) may not work. This makes the process of chainloading more
+complicated than it could be on some platforms.
+
+Finally, it supports only a subset of the U-Boot's FIT format. In particular
+it uses a fixed address to load the FIT and does not support load/exec
+addresses. This means that U-Boot must be able to boot from whatever
+address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting
+in Depthcharge). In practice this means that the data in the kernel@1 FIT node
+(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE.
diff --git a/roms/u-boot/doc/chromium/files/chromebook_jerry.its b/roms/u-boot/doc/chromium/files/chromebook_jerry.its
new file mode 100644
index 000000000..7505a2053
--- /dev/null
+++ b/roms/u-boot/doc/chromium/files/chromebook_jerry.its
@@ -0,0 +1,42 @@
+/dts-v1/;
+
+/ {
+ description = "U-Boot mainline";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "U-Boot mainline";
+ type = "kernel_noload";
+ arch = "arm";
+ os = "linux";
+ data = /incbin/("../../b/chromebook_jerry/u-boot.bin");
+ compression = "none";
+ load = <0>;
+ entry = <0>;
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+
+ fdt-1{
+ description = "rk3288-veryron-jerry.dtb";
+ data = /incbin/("../../b/chromebook_jerry/u-boot.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash-1{
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "Boot U-Boot";
+ kernel = "kernel";
+ fdt = "fdt-1";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/chromium/files/devkeys/kernel.keyblock b/roms/u-boot/doc/chromium/files/devkeys/kernel.keyblock
new file mode 100644
index 000000000..9740be4e6
--- /dev/null
+++ b/roms/u-boot/doc/chromium/files/devkeys/kernel.keyblock
Binary files differ
diff --git a/roms/u-boot/doc/chromium/files/devkeys/kernel_data_key.vbprivk b/roms/u-boot/doc/chromium/files/devkeys/kernel_data_key.vbprivk
new file mode 100644
index 000000000..8d392fb29
--- /dev/null
+++ b/roms/u-boot/doc/chromium/files/devkeys/kernel_data_key.vbprivk
Binary files differ
diff --git a/roms/u-boot/doc/chromium/files/nyan-big.its b/roms/u-boot/doc/chromium/files/nyan-big.its
new file mode 100644
index 000000000..bd412915e
--- /dev/null
+++ b/roms/u-boot/doc/chromium/files/nyan-big.its
@@ -0,0 +1,42 @@
+/dts-v1/;
+
+/ {
+ description = "U-Boot mainline";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "U-Boot mainline ";
+ type = "kernel_noload";
+ arch = "arm";
+ os = "linux";
+ data = /incbin/("../.././b/nyan-big/u-boot.bin");
+ compression = "none";
+ load = <0>;
+ entry = <0>;
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+
+ fdt-1{
+ description = "tegra124-nyan-big.dtb";
+ data = /incbin/("../.././b/nyan-big/u-boot.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash-1{
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "Boot U-Boot";
+ kernel = "kernel";
+ fdt = "fdt-1";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/chromium/index.rst b/roms/u-boot/doc/chromium/index.rst
new file mode 100644
index 000000000..0722c2500
--- /dev/null
+++ b/roms/u-boot/doc/chromium/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2020 Google LLC
+
+Chromium OS-specific doc
+========================
+
+This provides some information about Chromium OS and U-Boot.
+
+.. toctree::
+ :maxdepth: 2
+
+ overview
+ run_vboot
+ chainload
diff --git a/roms/u-boot/doc/chromium/overview.rst b/roms/u-boot/doc/chromium/overview.rst
new file mode 100644
index 000000000..790233cb6
--- /dev/null
+++ b/roms/u-boot/doc/chromium/overview.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2020 Google LLC
+
+Chromium OS Support in U-Boot
+=============================
+
+Introduction
+------------
+
+This describes how to use U-Boot with Chromium OS. Several options are
+available:
+
+ - Running U-Boot from the 'altfw' feature, which is available on selected
+ Chromebooks from 2019 onwards (initially Grunt). Press '1' from the
+ developer-mode screen to get into U-Boot. See here for details:
+ https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md
+
+ - Running U-Boot from the disk partition. This involves signing U-Boot and
+ placing it on the disk, for booting as a 'kernel'. See
+ :doc:`chainload` for information on this. This is the only
+ option on non-U-Boot Chromebooks from 2013 to 2018 and is somewhat
+ more involved.
+
+ - Running U-Boot with Chromium OS verified boot. This allows U-Boot to be
+ used instead of either or both of depthcharge (a bootloader which forked
+ from U-Boot in 2013) and coreboot. See :doc:`run_vboot` for more
+ information on this.
+
+ - Running U-Boot from coreboot. This allows U-Boot to run on more devices
+ since many of them only support coreboot as the bootloader and have
+ no bare-metal support in U-Boot. For this, use the 'coreboot' target.
+
+ - Running U-Boot and booting into a Chrome OS image, but without verified
+ boot. This can be useful for testing.
+
+
+Talks and documents
+-------------------
+
+Here is some material relevant to Chromium OS verified boot with U-Boot:
+
+ - "U-Boot with Chrome OS and firmware packaging"
+
+ - Author: Simon Glass
+ - Presented at Open Source Firmware Conference 2018, Erlangen
+ - Describes the work in progress as at the end of 2018
+ - Slides at `OSFC <https://2018.osfc.io/uploads/talk/paper/26/U-Boot_with_Chrome_OS_and_firmware_packaging.pdf>`_
+ - `Youtube video 'OSFC - U-Boot with Chrome OS and firmware packaging' <https://www.youtube.com/watch?v=1jknxUvmwpo>`_
+
+ - "Verified Boot in Chrome OS and how to make it work for you"
+
+ - Author: Simon Glass
+ - Presented at ELCE 2013, Edinburgh
+ - Describes the original 2013 implementation as shipped on snow (first
+ `ARM Chromebook was a Samsung Chromebook <https://www.cnet.com/products/samsung-series-3-chromebook-xe303c12-11-6-exynos-5250-2-gb-ram-16-gb-ssd-bilingual-english-french/>`_
+ with Samsung Exynos5250 `review <https://www.cnet.com/reviews/samsung-chromebook-series-3-review/>`_),
+ spring (`HP Chromebook 11 <https://www.cnet.com/products/hp-chromebook-11-g2-11-6-exynos-5250-4-gb-ram-16-gb-emmc/>`_)
+ and pit/pi (`Samsung Chromebook 2 <https://www.cnet.com/products/samsung-chromebook-2-xe503c12-11-6-exynos-5-octa-4-gb-ram-16-gb-ssd/>`_
+ with Exynos 5 Octa 5420 in 2014).
+ - Slides at `Google research <https://research.google/pubs/pub42038/>`_
+ - `Youtube video 'Verified Boot on Chrome OS and How to do it yourself' <https://www.youtube.com/watch?v=kdpZC9jFzZA>`_
+
+ - "Chrome University 2018: Chrome OS Firmware and Verified Boot 201"
+
+ - Author: Duncan Laurie
+ - Describes Chrome OS firmware as of 2018 and includes a wide range of
+ topics. This has no U-Boot information, but does cover coreboot and also
+ talks about the Chrome OS EC and Security chip. This is probably the
+ best introduction talk.
+ - `Youtube video 'Chrome University 2018: Chrome OS Firmware and Verified Boot 201' <https://www.youtube.com/watch?v=WY2sWpuda2g>`_
+
+ - `Chromium OS U-Boot <https://www.chromium.org/developers/u-boot>`_
+
+ - `Firmware porting Guide <https://www.chromium.org/chromium-os/firmware-porting-guide>`_
diff --git a/roms/u-boot/doc/chromium/run_vboot.rst b/roms/u-boot/doc/chromium/run_vboot.rst
new file mode 100644
index 000000000..41b4f6318
--- /dev/null
+++ b/roms/u-boot/doc/chromium/run_vboot.rst
@@ -0,0 +1,204 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2020 Google LLC
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+
+Running U-Boot with Chromium OS verified boot
+=============================================
+
+To obtain::
+
+ git clone https://github.com/sjg20/u-boot.git
+ cd u-boot
+ git checkout cros-master
+
+ cd ..
+ git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference
+ cd vboot_reference
+ git checkout 45964294
+ # futility: updater: Correct output version for Snow
+
+To build for sandbox::
+
+ UB=/tmp/b/chromeos_sandbox # U-Boot build directory
+ cd u-boot
+ make O=$UB chromeos_sandbox_defconfig
+ make O=$UB -j20 -s VBOOT_SOURCE=/path/to/vboot_reference \
+ MAKEFLAGS_VBOOT=DEBUG=1 QUIET=1
+
+Replace sandbox with another supported target.
+
+This produces $UB/image.bin which contains the firmware binaries in a SPI
+flash image.
+
+To run on sandbox::
+
+ CROS=~/cosarm
+ IMG=$CROS/src/build/images/coral/latest/chromiumos_image.bin
+ $UB/tpl/u-boot-tpl -d $UB/u-boot.dtb.out \
+ -L6 -c "host bind 0 $IMG; vboot go auto" \
+ -l -w -s state.dtb -r -n -m $UB/ram
+
+ $UB/tpl/u-boot-tpl -d $UB/u-boot.dtb.out -L6 -l \
+ -c "host bind 0 $IMG; vboot go auto" -w -s $UB/state.dtb -r -n -m $UB/mem
+
+
+To run on other boards:
+
+ - Install image.bin in the SPI flash of your device
+ - Boot your system
+
+
+Sandbox
+-------
+
+Most Chromium OS development with U-Boot is undertaken using sandbox. There is
+a sandbox target available (chromeos_sandbox) which allows running U-Boot on
+a Linux machine completion with emulations of the display, TPM, disk, etc.
+
+Running sandbox starts TPL, which contains the first phase of vboot, providing
+a device tree and binding a Chromium OS disk image for use to find kernels
+(any Chromium OS image will do). It also saves driver state between U-Boot
+phases into state.dtb and will automatically ensure that memory is shared
+between all phases. TPL will jump to SPL and then on to U-Boot proper.
+
+It is possible to run with debugging on, e.g.::
+
+ gdb --args $UB/tpl/u-boot-tpl -d ....
+
+Breakpoints can be set in any U-Boot phase. Overall this is a good debugging
+environment for new verified-boot features.
+
+
+Samus
+-----
+
+Basic support is available for samus, using the chromeos_samus target. If you
+have an em100, use::
+
+ sudo em100 -s -c W25Q128FW -d $UB/image.bin -t -r
+
+to write the image and then boot samus (Power-Refresh).
+
+
+Boot flow
+---------
+
+Verified boot starts in TPL, which selects the A or B SPL, which in turn selects
+the A or B U-Boot. Then this jumps to the selected kernel. If anything goes
+wrong, the device reboots and the recovery SPL and U-Boot are used instead.
+
+More details are available here:
+
+ https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery
+
+
+New uclasses
+------------
+
+Several uclasses are provided in cros/:
+
+UCLASS_CROS_AUX_FW
+ Chrome OS auxiliary firmware
+
+UCLASS_CROS_FWSTORE
+ Chrome OS firmware storage
+
+UCLASS_CROS_NVDATA
+ Chrome OS non-volatile data device
+
+UCLASS_CROS_VBOOT_EC
+ Chrome OS vboot EC operations
+
+UCLASS_CROS_VBOOT_FLAG
+ Chrome OS verified boot flag
+
+The existing UCLASS_CROS_EC is also used.
+
+
+Commands
+--------
+
+A new 'vboot' command is provided to run particular vboot stages. The most
+useful command is 'vboot go auto', which continues where the last stage left
+off.
+
+Note that TPL and SPL do not supports commands as yet, so the vboot code is
+called directly from the SPL boot devices (BOOT_DEVICE_CROS_VBOOT). See
+cros_load_image_tpl() and cros_load_image_spl() which both call
+vboot_run_auto().
+
+
+Config options
+--------------
+
+The main option is CONFIG_CHROMEOS, which enables a wide array of other options
+so that the required features are present.
+
+
+Device-tree config
+------------------
+
+Various options are available which control the operation of verified boot.
+See cros/dts/bindings/config.txt for details. Most config is handled at run-
+time, although build-time config (with Kconfig) could also be added fairly
+easily.
+
+
+Porting to other hardware
+-------------------------
+
+A basic port to samus (Chromebook Pixel 2015) is in a basic working state,
+using the chromeos_samus target. Patches will likely be forthcoming in early
+2019. Ports to an ARM board and coreboot (for x86 Chromebooks) are in the
+dreaming state.
+
+
+Tests
+-----
+
+Chromium OS firmware has a very limited set of tests. The tests that originally
+existed in U-Boot were not brought over to coreboot or depthcharge.
+
+The U-Boot tests ('make check') do operate, but at present there are no
+Chromium OS tests available. These will hopefully come together over time. Of
+course the above sandbox feature provides a sort of functional test and can
+detect problems that affect the flow or particular vboot features.
+
+
+U-Boot without Chromium OS verified boot
+----------------------------------------
+
+The following script can be used to boot a Chrome OS image on coral::
+
+ # Read the image header and obtain the address of the kernel
+ # The offset 4f0 is defined by verified boot and may change for other
+ # Chromebooks
+ read mmc 2:2 100000 0 80; setexpr loader *001004f0;
+
+ # Get the kernel size and calculate the number of blocks (0x200 bytes each)
+ setexpr size *00100518; setexpr blocks $size / 200;
+
+ # Read the full kernel and calculate the address of the setup block
+ read mmc 2:2 100000 80 $blocks; setexpr setup $loader - 1000;
+
+ # Locate the command line
+ setexpr cmdline $loader - 2000;
+
+ # Start the zboot process with the loaded kernel, setup block and cmdline
+ zboot start 100000 0 0 0 $setup $cmdline;
+
+ # Load the kernel, fix up the 'setup' block, dump information
+ zboot load; zboot setup; zboot dump
+
+ # Boot into Chrome OS
+ zboot go
+
+
+TO DO
+-----
+
+Get the full ACPI tables working with Coral
+
+
+7 October 2018
diff --git a/roms/u-boot/doc/conf.py b/roms/u-boot/doc/conf.py
new file mode 100644
index 000000000..eb74b86ae
--- /dev/null
+++ b/roms/u-boot/doc/conf.py
@@ -0,0 +1,644 @@
+# -*- coding: utf-8 -*-
+#
+# The U-Boot documentation build configuration file, created by
+# sphinx-quickstart on Fri Feb 12 13:51:46 2016.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+import sphinx
+
+from subprocess import check_output
+
+# Get Sphinx version
+major, minor, patch = sphinx.version_info[:3]
+
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath('sphinx'))
+from load_config import loadConfig
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+needs_sphinx = '1.3'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
+ 'kfigure', 'sphinx.ext.ifconfig', # 'automarkup',
+ 'maintainers_include', 'sphinx.ext.autosectionlabel',
+ 'kernel_abi', 'kernel_feat']
+
+#
+# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
+# of the docs correctly, but not all. Scream bloody murder but allow
+# the process to proceed; hopefully somebody will fix this properly soon.
+#
+if major >= 3:
+ sys.stderr.write('''WARNING: The kernel documentation build process
+ support for Sphinx v3.0 and above is brand new. Be prepared for
+ possible issues in the generated output.
+ ''')
+ if (major > 3) or (minor > 0 or patch >= 2):
+ # Sphinx c function parser is more pedantic with regards to type
+ # checking. Due to that, having macros at c:function cause problems.
+ # Those needed to be scaped by using c_id_attributes[] array
+ c_id_attributes = [
+ # GCC Compiler types not parsed by Sphinx:
+ "__restrict__",
+
+ # include/linux/compiler_types.h:
+ "__iomem",
+ "__kernel",
+ "noinstr",
+ "notrace",
+ "__percpu",
+ "__rcu",
+ "__user",
+
+ # include/linux/compiler_attributes.h:
+ "__alias",
+ "__aligned",
+ "__aligned_largest",
+ "__always_inline",
+ "__assume_aligned",
+ "__cold",
+ "__attribute_const__",
+ "__copy",
+ "__pure",
+ "__designated_init",
+ "__visible",
+ "__printf",
+ "__scanf",
+ "__gnu_inline",
+ "__malloc",
+ "__mode",
+ "__no_caller_saved_registers",
+ "__noclone",
+ "__nonstring",
+ "__noreturn",
+ "__packed",
+ "__pure",
+ "__section",
+ "__always_unused",
+ "__maybe_unused",
+ "__used",
+ "__weak",
+ "noinline",
+
+ # include/efi.h
+ "EFIAPI",
+
+ # include/efi_loader.h
+ "__efi_runtime",
+
+ # include/linux/memblock.h:
+ "__init_memblock",
+ "__meminit",
+
+ # include/linux/init.h:
+ "__init",
+ "__ref",
+
+ # include/linux/linkage.h:
+ "asmlinkage",
+ ]
+
+else:
+ extensions.append('cdomain')
+ if major == 1 and minor < 7:
+ sys.stderr.write('WARNING: Sphinx 1.7 or greater will be required as of '
+ 'the v2021.04 release\n')
+
+# Ensure that autosectionlabel will produce unique names
+autosectionlabel_prefix_document = True
+autosectionlabel_maxdepth = 2
+
+# The name of the math extension changed on Sphinx 1.4
+if (major == 1 and minor > 3) or (major > 1):
+ extensions.append("sphinx.ext.imgmath")
+else:
+ extensions.append("sphinx.ext.pngmath")
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'Das U-Boot'
+copyright = 'The U-Boot development community'
+author = 'The U-Boot development community'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# In a normal build, version and release are are set to KERNELVERSION and
+# KERNELRELEASE, respectively, from the Makefile via Sphinx command line
+# arguments.
+#
+# The following code tries to extract the information by reading the Makefile,
+# when Sphinx is run directly (e.g. by Read the Docs).
+try:
+ makefile_version = None
+ makefile_patchlevel = None
+ for line in open('../Makefile'):
+ key, val = [x.strip() for x in line.split('=', 2)]
+ if key == 'VERSION':
+ makefile_version = val
+ elif key == 'PATCHLEVEL':
+ makefile_patchlevel = val
+ if makefile_version and makefile_patchlevel:
+ break
+except:
+ pass
+finally:
+ if makefile_version and makefile_patchlevel:
+ version = release = makefile_version + '.' + makefile_patchlevel
+ else:
+ version = release = "unknown version"
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['output']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+primary_domain = 'c'
+highlight_language = 'none'
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+
+# The Read the Docs theme is available from
+# - https://github.com/snide/sphinx_rtd_theme
+# - https://pypi.python.org/pypi/sphinx_rtd_theme
+# - python-sphinx-rtd-theme package (on Debian)
+try:
+ import sphinx_rtd_theme
+ html_theme = 'sphinx_rtd_theme'
+ html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+except ImportError:
+ sys.stderr.write('Warning: The Sphinx \'sphinx_rtd_theme\' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme.\n')
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+html_logo = '../tools/logos/u-boot_logo.svg'
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+
+html_static_path = ['sphinx-static']
+
+html_context = {
+ 'css_files': [
+ '_static/theme_overrides.css',
+ ],
+}
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+html_use_smartypants = False
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
+# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'TheUBootdoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+'papersize': 'a4paper',
+
+# The font size ('10pt', '11pt' or '12pt').
+'pointsize': '11pt',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+
+# Don't mangle with UTF-8 chars
+'inputenc': '',
+'utf8extra': '',
+
+# Additional stuff for the LaTeX preamble.
+ 'preamble': '''
+ % Use some font with UTF-8 support with XeLaTeX
+ \\usepackage{fontspec}
+ \\setsansfont{DejaVu Sans}
+ \\setromanfont{DejaVu Serif}
+ \\setmonofont{DejaVu Sans Mono}
+ '''
+}
+
+# At least one book (translations) may have Asian characters
+# with are only displayed if xeCJK is used
+
+cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
+if cjk_cmd.find("Noto Sans CJK SC") >= 0:
+ print ("enabling CJK for LaTeX builder")
+ latex_elements['preamble'] += '''
+ % This is needed for translations
+ \\usepackage{xeCJK}
+ \\setCJKmainfont{Noto Sans CJK SC}
+ '''
+
+# Fix reference escape troubles with Sphinx 1.4.x
+if major == 1 and minor > 3:
+ latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
+
+if major == 1 and minor <= 4:
+ latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
+elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
+ latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
+ latex_elements['preamble'] += '\\fvset{fontsize=auto}\n'
+
+# Customize notice background colors on Sphinx < 1.6:
+if major == 1 and minor < 6:
+ latex_elements['preamble'] += '''
+ \\usepackage{ifthen}
+
+ % Put notes in color and let them be inside a table
+ \\definecolor{NoteColor}{RGB}{204,255,255}
+ \\definecolor{WarningColor}{RGB}{255,204,204}
+ \\definecolor{AttentionColor}{RGB}{255,255,204}
+ \\definecolor{ImportantColor}{RGB}{192,255,204}
+ \\definecolor{OtherColor}{RGB}{204,204,204}
+ \\newlength{\\mynoticelength}
+ \\makeatletter\\newenvironment{coloredbox}[1]{%
+ \\setlength{\\fboxrule}{1pt}
+ \\setlength{\\fboxsep}{7pt}
+ \\setlength{\\mynoticelength}{\\linewidth}
+ \\addtolength{\\mynoticelength}{-2\\fboxsep}
+ \\addtolength{\\mynoticelength}{-2\\fboxrule}
+ \\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\mynoticelength}}{\\end{minipage}\\end{lrbox}%
+ \\ifthenelse%
+ {\\equal{\\py@noticetype}{note}}%
+ {\\colorbox{NoteColor}{\\usebox{\\@tempboxa}}}%
+ {%
+ \\ifthenelse%
+ {\\equal{\\py@noticetype}{warning}}%
+ {\\colorbox{WarningColor}{\\usebox{\\@tempboxa}}}%
+ {%
+ \\ifthenelse%
+ {\\equal{\\py@noticetype}{attention}}%
+ {\\colorbox{AttentionColor}{\\usebox{\\@tempboxa}}}%
+ {%
+ \\ifthenelse%
+ {\\equal{\\py@noticetype}{important}}%
+ {\\colorbox{ImportantColor}{\\usebox{\\@tempboxa}}}%
+ {\\colorbox{OtherColor}{\\usebox{\\@tempboxa}}}%
+ }%
+ }%
+ }%
+ }\\makeatother
+
+ \\makeatletter
+ \\renewenvironment{notice}[2]{%
+ \\def\\py@noticetype{#1}
+ \\begin{coloredbox}{#1}
+ \\bf\\it
+ \\par\\strong{#2}
+ \\csname py@noticestart@#1\\endcsname
+ }
+ {
+ \\csname py@noticeend@\\py@noticetype\\endcsname
+ \\end{coloredbox}
+ }
+ \\makeatother
+
+ '''
+
+# With Sphinx 1.6, it is possible to change the Bg color directly
+# by using:
+# \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
+# \definecolor{sphinxwarningBgColor}{RGB}{255,204,204}
+# \definecolor{sphinxattentionBgColor}{RGB}{255,255,204}
+# \definecolor{sphinximportantBgColor}{RGB}{192,255,204}
+#
+# However, it require to use sphinx heavy box with:
+#
+# \renewenvironment{sphinxlightbox} {%
+# \\begin{sphinxheavybox}
+# }
+# \\end{sphinxheavybox}
+# }
+#
+# Unfortunately, the implementation is buggy: if a note is inside a
+# table, it isn't displayed well. So, for now, let's use boring
+# black and white notes.
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+# author, documentclass [howto, manual, or own class]).
+# Sorted in alphabetical order
+latex_documents = [
+ ('index', 'u-boot-hacker-manual.tex', 'U-Boot Hacker Manual',
+ 'The U-Boot development community', 'manual'),
+]
+
+# Add all other index files from Documentation/ subdirectories
+for fn in os.listdir('.'):
+ doc = os.path.join(fn, "index")
+ if os.path.exists(doc + ".rst"):
+ has = False
+ for l in latex_documents:
+ if l[0] == doc:
+ has = True
+ break
+ if not has:
+ latex_documents.append((doc, fn + '.tex',
+ 'U-Boot %s Documentation' % fn.capitalize(),
+ 'The U-Boot development community',
+ 'manual'))
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+ (master_doc, 'dasuboot', 'The U-Boot Documentation',
+ [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+# dir menu entry, description, category)
+texinfo_documents = [
+ (master_doc, 'DasUBoot', 'The U-Boot Documentation',
+ author, 'DasUBoot', 'One line description of project.',
+ 'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+
+# -- Options for Epub output ----------------------------------------------
+
+# Bibliographic Dublin Core info.
+epub_title = project
+epub_author = author
+epub_publisher = author
+epub_copyright = copyright
+
+# The basename for the epub file. It defaults to the project name.
+#epub_basename = project
+
+# The HTML theme for the epub output. Since the default themes are not
+# optimized for small screen space, using the same theme for HTML and epub
+# output is usually not wise. This defaults to 'epub', a theme designed to save
+# visual space.
+#epub_theme = 'epub'
+
+# The language of the text. It defaults to the language option
+# or 'en' if the language is not set.
+#epub_language = ''
+
+# The scheme of the identifier. Typical schemes are ISBN or URL.
+#epub_scheme = ''
+
+# The unique identifier of the text. This can be a ISBN number
+# or the project homepage.
+#epub_identifier = ''
+
+# A unique identification for the text.
+#epub_uid = ''
+
+# A tuple containing the cover image and cover page html template filenames.
+#epub_cover = ()
+
+# A sequence of (type, uri, title) tuples for the guide element of content.opf.
+#epub_guide = ()
+
+# HTML files that should be inserted before the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_pre_files = []
+
+# HTML files that should be inserted after the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_post_files = []
+
+# A list of files that should not be packed into the epub file.
+epub_exclude_files = ['search.html']
+
+# The depth of the table of contents in toc.ncx.
+#epub_tocdepth = 3
+
+# Allow duplicate toc entries.
+#epub_tocdup = True
+
+# Choose between 'default' and 'includehidden'.
+#epub_tocscope = 'default'
+
+# Fix unsupported image types using the Pillow.
+#epub_fix_images = False
+
+# Scale large images.
+#epub_max_image_width = 0
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#epub_show_urls = 'inline'
+
+# If false, no index is generated.
+#epub_use_index = True
+
+#=======
+# rst2pdf
+#
+# Grouping the document tree into PDF files. List of tuples
+# (source start file, target name, title, author, options).
+#
+# See the Sphinx chapter of https://ralsina.me/static/manual.pdf
+#
+# FIXME: Do not add the index file here; the result will be too big. Adding
+# multiple PDF files here actually tries to get the cross-referencing right
+# *between* PDF files.
+pdf_documents = [
+ ('uboot-documentation', u'U-Boot', u'U-Boot', u'J. Random Bozo'),
+]
+
+# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
+# the Docs). In a normal build, these are supplied from the Makefile via command
+# line arguments.
+kerneldoc_bin = '../scripts/kernel-doc'
+kerneldoc_srctree = '..'
+
+# ------------------------------------------------------------------------------
+# Since loadConfig overwrites settings from the global namespace, it has to be
+# the last statement in the conf.py file
+# ------------------------------------------------------------------------------
+loadConfig(globals())
diff --git a/roms/u-boot/doc/develop/coccinelle.rst b/roms/u-boot/doc/develop/coccinelle.rst
new file mode 100644
index 000000000..70274c3f5
--- /dev/null
+++ b/roms/u-boot/doc/develop/coccinelle.rst
@@ -0,0 +1,505 @@
+.. Copyright 2010 Nicolas Palix <npalix@diku.dk>
+.. Copyright 2010 Julia Lawall <julia@diku.dk>
+.. Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
+
+.. highlight:: none
+
+.. _devtools_coccinelle:
+
+Coccinelle
+==========
+
+Coccinelle is a tool for pattern matching and text transformation that has
+many uses in kernel development, including the application of complex,
+tree-wide patches and detection of problematic programming patterns.
+
+Getting Coccinelle
+------------------
+
+The semantic patches included in the kernel use features and options
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by
+the Coccinelle files and coccicheck have been updated.
+
+Coccinelle is available through the package manager
+of many distributions, e.g. :
+
+ - Debian
+ - Fedora
+ - Ubuntu
+ - OpenSUSE
+ - Arch Linux
+ - NetBSD
+ - FreeBSD
+
+Some distribution packages are obsolete and it is recommended
+to use the latest version released from the Coccinelle homepage at
+http://coccinelle.lip6.fr/
+
+Or from Github at:
+
+https://github.com/coccinelle/coccinelle
+
+Once you have it, run the following commands::
+
+ ./autogen
+ ./configure
+ make
+
+as a regular user, and install it with::
+
+ sudo make install
+
+More detailed installation instructions to build from source can be
+found at:
+
+https://github.com/coccinelle/coccinelle/blob/master/install.txt
+
+Supplemental documentation
+--------------------------
+
+For supplemental documentation refer to the wiki:
+
+https://bottest.wiki.kernel.org/coccicheck
+
+The wiki documentation always refers to the linux-next version of the script.
+
+For Semantic Patch Language(SmPL) grammar documentation refer to:
+
+http://coccinelle.lip6.fr/documentation.php
+
+Using Coccinelle on the Linux kernel
+------------------------------------
+
+A Coccinelle-specific target is defined in the top level
+Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
+front-end in the ``scripts`` directory.
+
+Four basic modes are defined: ``patch``, ``report``, ``context``, and
+``org``. The mode to use is specified by setting the MODE variable with
+``MODE=<mode>``.
+
+- ``patch`` proposes a fix, when possible.
+
+- ``report`` generates a list in the following format:
+ file:line:column-column: message
+
+- ``context`` highlights lines of interest and their context in a
+ diff-like style.Lines of interest are indicated with ``-``.
+
+- ``org`` generates a report in the Org mode format of Emacs.
+
+Note that not all semantic patches implement all modes. For easy use
+of Coccinelle, the default mode is "report".
+
+Two other modes provide some common combinations of these modes.
+
+- ``chain`` tries the previous modes in the order above until one succeeds.
+
+- ``rep+ctxt`` runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
+
+Examples
+~~~~~~~~
+
+To make a report for every semantic patch, run the following command::
+
+ make coccicheck MODE=report
+
+To produce patches, run::
+
+ make coccicheck MODE=patch
+
+
+The coccicheck target applies every semantic patch available in the
+sub-directories of ``scripts/coccinelle`` to the entire Linux kernel.
+
+For each semantic patch, a commit message is proposed. It gives a
+description of the problem being checked by the semantic patch, and
+includes a reference to Coccinelle.
+
+As any static code analyzer, Coccinelle produces false
+positives. Thus, reports must be carefully checked, and patches
+reviewed.
+
+To enable verbose messages set the V= variable, for example::
+
+ make coccicheck MODE=report V=1
+
+Coccinelle parallelization
+--------------------------
+
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs::
+
+ make coccicheck MODE=report J=4
+
+As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization,
+if support for this is detected you will benefit from parmap parallelization.
+
+When parmap is enabled coccicheck will enable dynamic load balancing by using
+``--chunksize 1`` argument, this ensures we keep feeding threads with work
+one by one, so that we avoid the situation where most work gets done by only
+a few threads. With dynamic load balancing, if a thread finishes early we keep
+feeding it more work.
+
+When parmap is enabled, if an error occurs in Coccinelle, this error
+value is propagated back, the return value of the ``make coccicheck``
+captures this return value.
+
+Using Coccinelle with a single semantic patch
+---------------------------------------------
+
+The optional make variable COCCI can be used to check a single
+semantic patch. In that case, the variable must be initialized with
+the name of the semantic patch to apply.
+
+For instance::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=patch
+
+or::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=report
+
+
+Controlling Which Files are Processed by Coccinelle
+---------------------------------------------------
+
+By default the entire kernel source tree is checked.
+
+To apply Coccinelle to a specific directory, ``M=`` can be used.
+For example, to check drivers/net/wireless/ one may write::
+
+ make coccicheck M=drivers/net/wireless/
+
+To apply Coccinelle on a file basis, instead of a directory basis, the
+following command may be used::
+
+ make C=1 CHECK="scripts/coccicheck"
+
+To check only newly edited code, use the value 2 for the C flag, i.e.::
+
+ make C=2 CHECK="scripts/coccicheck"
+
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
+
+This runs every semantic patch in scripts/coccinelle by default. The
+COCCI variable may additionally be used to only apply a single
+semantic patch as shown in the previous section.
+
+The "report" mode is the default. You can select another one with the
+MODE variable explained above.
+
+Debugging Coccinelle SmPL patches
+---------------------------------
+
+Using coccicheck is best as it provides in the spatch command line
+include options matching the options used when we compile the kernel.
+You can learn what these options are by using V=1, you could then
+manually run Coccinelle with debug options added.
+
+Alternatively you can debug running Coccinelle against SmPL patches
+by asking for stderr to be redirected to stderr, by default stderr
+is redirected to /dev/null, if you'd like to capture stderr you
+can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For
+instance::
+
+ rm -f cocci.err
+ make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
+ cat cocci.err
+
+You can use SPFLAGS to add debugging flags, for instance you may want to
+add both --profile --show-trying to SPFLAGS when debugging. For instance
+you may want to use::
+
+ rm -f err.log
+ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+
+err.log will now have the profiling information, while stdout will
+provide some progress information as Coccinelle moves forward with
+work.
+
+DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
+
+.cocciconfig support
+--------------------
+
+Coccinelle supports reading .cocciconfig for default Coccinelle options that
+should be used every time spatch is spawned, the order of precedence for
+variables for .cocciconfig is as follows:
+
+- Your current user's home directory is processed first
+- Your directory from which spatch is called is processed next
+- The directory provided with the --dir option is processed last, if used
+
+Since coccicheck runs through make, it naturally runs from the kernel
+proper dir, as such the second rule above would be implied for picking up a
+.cocciconfig when using ``make coccicheck``.
+
+``make coccicheck`` also supports using M= targets. If you do not supply
+any M= target, it is assumed you want to target the entire kernel.
+The kernel coccicheck script has::
+
+ if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $srctree $COCCIINCLUDE"
+ else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+ fi
+
+KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
+the spatch --dir argument is used, as such third rule applies when whether M=
+is used or not, and when M= is used the target directory can have its own
+.cocciconfig file. When M= is not passed as an argument to coccicheck the
+target directory is the same as the directory from where spatch was called.
+
+If not using the kernel's coccicheck target, keep the above precedence
+order logic of .cocciconfig reading. If using the kernel's coccicheck target,
+override any of the kernel's .coccicheck's settings using SPFLAGS.
+
+We help Coccinelle when used against Linux with a set of sensible defaults
+options for Linux with our own Linux .cocciconfig. This hints to coccinelle
+git can be used for ``git grep`` queries over coccigrep. A timeout of 200
+seconds should suffice for now.
+
+The options picked up by coccinelle when reading a .cocciconfig do not appear
+as arguments to spatch processes running on your system, to confirm what
+options will be used by Coccinelle run::
+
+ spatch --print-options-only
+
+You can override with your own preferred index option by using SPFLAGS. Take
+note that when there are conflicting options Coccinelle takes precedence for
+the last options passed. Using .cocciconfig is possible to use idutils, however
+given the order of precedence followed by Coccinelle, since the kernel now
+carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if
+desired. See below section "Additional flags" for more details on how to use
+idutils.
+
+Additional flags
+----------------
+
+Additional flags can be passed to spatch through the SPFLAGS
+variable. This works as Coccinelle respects the last flags
+given to it when options are in conflict. ::
+
+ make SPFLAGS=--use-glimpse coccicheck
+
+Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
+When no ID file is specified coccinelle assumes your ID database file
+is in the file .id-utils.index on the top level of the kernel, coccinelle
+carries a script scripts/idutils_index.sh which creates the database with::
+
+ mkid -i C --output .id-utils.index
+
+If you have another database filename you can also just symlink with this
+name. ::
+
+ make SPFLAGS=--use-idutils coccicheck
+
+Alternatively you can specify the database filename explicitly, for
+instance::
+
+ make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
+
+See ``spatch --help`` to learn more about spatch options.
+
+Note that the ``--use-glimpse`` and ``--use-idutils`` options
+require external tools for indexing the code. None of them is
+thus active by default. However, by indexing the code with
+one of these tools, and according to the cocci file used,
+spatch could proceed the entire code base more quickly.
+
+SmPL patch specific options
+---------------------------
+
+SmPL patches can have their own requirements for options passed
+to Coccinelle. SmPL patch specific options can be provided by
+providing them at the top of the SmPL patch, for instance::
+
+ // Options: --no-includes --include-headers
+
+SmPL patch Coccinelle requirements
+----------------------------------
+
+As Coccinelle features get added some more advanced SmPL patches
+may require newer versions of Coccinelle. If an SmPL patch requires
+at least a version of Coccinelle, this can be specified as follows,
+as an example if requiring at least Coccinelle >= 1.0.5::
+
+ // Requires: 1.0.5
+
+Proposing new semantic patches
+------------------------------
+
+New semantic patches can be proposed and submitted by kernel
+developers. For sake of clarity, they should be organized in the
+sub-directories of ``scripts/coccinelle/``.
+
+
+Detailed description of the ``report`` mode
+-------------------------------------------
+
+``report`` generates a list in the following format::
+
+ file:line:column-column: message
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on report@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ coccilib.report.print_report(p[0], msg)
+ </smpl>
+
+This SmPL excerpt generates entries on the standard output, as
+illustrated below::
+
+ /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
+ /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
+ /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg
+
+
+Detailed description of the ``patch`` mode
+------------------------------------------
+
+When the ``patch`` mode is available, it proposes a fix for each problem
+identified.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on !context && patch && !org && !report @
+ expression x;
+ @@
+
+ - ERR_PTR(PTR_ERR(x))
+ + ERR_CAST(x)
+ </smpl>
+
+This SmPL excerpt generates patch hunks on the standard output, as
+illustrated below::
+
+ diff -u -p a/crypto/ctr.c b/crypto/ctr.c
+ --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
+ @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+ + return ERR_CAST(alg);
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``context`` mode
+--------------------------------------------
+
+``context`` highlights lines of interest and their context
+in a diff-like style.
+
+ **NOTE**: The diff-like output generated is NOT an applicable patch. The
+ intent of the ``context`` mode is to highlight the important lines
+ (annotated with minus, ``-``) and gives some surrounding context
+ lines around. This output can be used with the diff mode of
+ Emacs to review the code.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on context && !patch && !org && !report@
+ expression x;
+ @@
+
+ * ERR_PTR(PTR_ERR(x))
+ </smpl>
+
+This SmPL excerpt generates diff hunks on the standard output, as
+illustrated below::
+
+ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
+ --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ /tmp/nothing
+ @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``org`` mode
+----------------------------------------
+
+``org`` generates a report in the Org mode format of Emacs.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on org@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ msg_safe=msg.replace("[","@(").replace("]",")")
+ coccilib.org.print_todo(p[0], msg_safe)
+ </smpl>
+
+This SmPL excerpt generates Org entries on the standard output, as
+illustrated below::
+
+ * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
+ * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
+ * TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]]
diff --git a/roms/u-boot/doc/develop/commands.rst b/roms/u-boot/doc/develop/commands.rst
new file mode 100644
index 000000000..c72d1b0aa
--- /dev/null
+++ b/roms/u-boot/doc/develop/commands.rst
@@ -0,0 +1,226 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Implementing shell commands
+===========================
+
+Command definition
+------------------
+
+Commands are added to U-Boot by creating a new command structure.
+This is done by first including command.h, then using the U_BOOT_CMD() or the
+U_BOOT_CMD_COMPLETE macro to fill in a struct cmd_tbl structure.
+
+.. code-block:: c
+
+ U_BOOT_CMD(name, maxargs, repeatable, command, "usage", "help")
+ U_BOOT_CMD_COMPLETE(name, maxargs, repeatable, command, "usage, "help", comp)
+
+name
+ The name of the command. This is **not** a string.
+
+maxargs
+ The maximum number of arguments this function takes including
+ the command itself.
+
+repeatable
+ Either 0 or 1 to indicate if autorepeat is allowed.
+
+command
+ Pointer to the command function. This is the function that is
+ called when the command is issued.
+
+usage
+ Short description. This is a string.
+
+help
+ Long description. This is a string. The long description is
+ only available if CONFIG_SYS_LONGHELP is defined.
+
+comp
+ Pointer to the completion function. May be NULL.
+ This function is called if the user hits the TAB key while
+ entering the command arguments to complete the entry. Command
+ completion is only available if CONFIG_AUTO_COMPLETE is defined.
+
+Sub-command definition
+----------------------
+
+Likewise an array of struct cmd_tbl holding sub-commands can be created using
+either of the following macros:
+
+.. code-block:: c
+
+ U_BOOT_CMD_MKENT(name, maxargs, repeatable, command, "usage", "help")
+ U_BOOT_CMD_MKENTCOMPLETE(name, maxargs, repeatable, command, "usage, "help", comp)
+
+This table has to be evaluated in the command function of the main command, e.g.
+
+.. code-block:: c
+
+ static struct cmd_tbl cmd_sub[] = {
+ U_BOOT_CMD_MKENT(foo, CONFIG_SYS_MAXARGS, 1, do_foo, "", ""),
+ U_BOOT_CMD_MKENT(bar, CONFIG_SYS_MAXARGS, 1, do_bar, "", ""),
+ };
+
+ static int do_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+ {
+ struct cmd_tbl *cp;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ /* drop sub-command argument */
+ argc--;
+ argv++;
+
+ cp = find_cmd_tbl(argv[0], cmd_ut_sub, ARRAY_SIZE(cmd_sub));
+
+ if (cp)
+ return cp->cmd(cmdtp, flag, argc, argv);
+
+ return CMD_RET_USAGE;
+ }
+
+Command function
+----------------
+
+The command function pointer has to be of type
+
+.. code-block:: c
+
+ int (*cmd)(struct cmd_tbl *cmdtp, int flag, int argc, const char *argv[]);
+
+cmdtp
+ Table entry describing the command (see above).
+
+flag
+ A bitmap which may contain the following bits
+
+ * CMD_FLAG_REPEAT - The last command is repeated.
+ * CMD_FLAG_BOOTD - The command is called by the bootd command.
+ * CMD_FLAG_ENV - The command is called by the run command.
+
+argc
+ Number of arguments including the command.
+
+argv
+ Arguments.
+
+Allowable return value are:
+
+CMD_RET_SUCCESS
+ The command was successfully executed.
+
+CMD_RET_FAILURE
+ The command failed.
+
+CMD_RET_USAGE
+ The command was called with invalid parameters. This value
+ leads to the display of the usage string.
+
+Completion function
+-------------------
+
+The completion function pointer has to be of type
+
+.. code-block:: c
+
+ int (*complete)(int argc, char *const argv[], char last_char,
+ int maxv, char *cmdv[]);
+
+argc
+ Number of arguments including the command.
+
+argv
+ Arguments.
+
+last_char
+ The last character in the command line buffer.
+
+maxv
+ Maximum number of possible completions that may be returned by
+ the function.
+
+cmdv
+ Used to return possible values for the last argument. The last
+ possible completion must be followed by NULL.
+
+The function returns the number of possible completions (without the terminating
+NULL value).
+
+Behind the scene
+----------------
+
+The structure created is named with a special prefix and placed by
+the linker in a special section using the linker lists mechanism
+(see include/linker_lists.h)
+
+This makes it possible for the final link to extract all commands
+compiled into any object code and construct a static array so the
+command array can be iterated over using the linker lists macros.
+
+The linker lists feature ensures that the linker does not discard
+these symbols when linking full U-Boot even though they are not
+referenced in the source code as such.
+
+If a new board is defined do not forget to define the command section
+by writing in u-boot.lds ($(srctree)/board/boardname/u-boot.lds) these
+3 lines:
+
+.. code-block:: c
+
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*)));
+ }
+
+Writing tests
+-------------
+
+All new commands should have tests. Tests for existing commands are very
+welcome.
+
+It is fairly easy to write a test for a command. Enable it in sandbox, and
+then add code that runs the command and checks the output.
+
+Here is an example:
+
+.. code-block:: c
+
+ /* Test 'acpi items' command */
+ static int dm_test_acpi_cmd_items(struct unit_test_state *uts)
+ {
+ struct acpi_ctx ctx;
+ void *buf;
+
+ buf = malloc(BUF_SIZE);
+ ut_assertnonnull(buf);
+
+ ctx.current = buf;
+ ut_assertok(acpi_fill_ssdt(&ctx));
+ console_record_reset();
+ run_command("acpi items", 0);
+ ut_assert_nextline("dev 'acpi-test', type 1, size 2");
+ ut_assert_nextline("dev 'acpi-test2', type 1, size 2");
+ ut_assert_console_end();
+
+ ctx.current = buf;
+ ut_assertok(acpi_inject_dsdt(&ctx));
+ console_record_reset();
+ run_command("acpi items", 0);
+ ut_assert_nextline("dev 'acpi-test', type 2, size 2");
+ ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
+ ut_assert_console_end();
+
+ console_record_reset();
+ run_command("acpi items -d", 0);
+ ut_assert_nextline("dev 'acpi-test', type 2, size 2");
+ ut_assert_nextlines_are_dump(2);
+ ut_assert_nextline("%s", "");
+ ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
+ ut_assert_nextlines_are_dump(2);
+ ut_assert_nextline("%s", "");
+ ut_assert_console_end();
+
+ return 0;
+ }
+ DM_TEST(dm_test_acpi_cmd_items, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
diff --git a/roms/u-boot/doc/develop/crash_dumps.rst b/roms/u-boot/doc/develop/crash_dumps.rst
new file mode 100644
index 000000000..85030b4e3
--- /dev/null
+++ b/roms/u-boot/doc/develop/crash_dumps.rst
@@ -0,0 +1,124 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2020 Heinrich Schuchardt
+
+Analyzing crash dumps
+=====================
+
+When the CPU detects an instruction that it cannot execute it raises an
+interrupt. U-Boot then writes a crash dump. This chapter describes how such
+dump can be analyzed.
+
+Creating a crash dump voluntarily
+---------------------------------
+
+For describing the analysis of a crash dump we need an example. U-Boot comes
+with a command 'exception' that comes in handy here. The command is enabled
+by::
+
+ CONFIG_CMD_EXCEPTION=y
+
+The example output below was recorded when running qemu\_arm64\_defconfig on
+QEMU::
+
+ => exception undefined
+ "Synchronous Abort" handler, esr 0x02000000
+ elr: 00000000000101fc lr : 00000000000214ec (reloc)
+ elr: 000000007ff291fc lr : 000000007ff3a4ec
+ x0 : 000000007ffbd7f8 x1 : 0000000000000000
+ x2 : 0000000000000001 x3 : 000000007eedce18
+ x4 : 000000007ff291fc x5 : 000000007eedce50
+ x6 : 0000000000000064 x7 : 000000007eedce10
+ x8 : 0000000000000000 x9 : 0000000000000004
+ x10: 6db6db6db6db6db7 x11: 000000000000000d
+ x12: 0000000000000006 x13: 000000000001869f
+ x14: 000000007edd7dc0 x15: 0000000000000002
+ x16: 000000007ff291fc x17: 0000000000000000
+ x18: 000000007eed8dc0 x19: 0000000000000000
+ x20: 000000007ffbd7f8 x21: 0000000000000000
+ x22: 000000007eedce10 x23: 0000000000000002
+ x24: 000000007ffd4c80 x25: 0000000000000000
+ x26: 0000000000000000 x27: 0000000000000000
+ x28: 000000007eedce70 x29: 000000007edd7b40
+
+ Code: b00003c0 912ad000 940029d6 17ffff52 (e7f7defb)
+ Resetting CPU ...
+
+ resetting ...
+
+The first line provides us with the type of interrupt that occurred.
+On ARMv8 a synchronous abort is an exception thrown when hitting an unallocated
+instruction. The exception syndrome register ESR register contains information
+describing the reason for the exception. Bit 25 set here indicates that a 32 bit
+instruction led to the exception.
+
+The second line provides the contents of the elr and the lr register after
+subtracting the relocation offset. - U-Boot relocates itself after being
+loaded. - The relocation offset can also be displayed using the bdinfo command.
+
+After the contents of the registers we get a line indicating the machine
+code of the instructions preceding the crash and in parentheses the instruction
+leading to the dump.
+
+Analyzing the code location
+---------------------------
+
+We can convert the instructions in the line starting with 'Code:' into mnemonics
+using the objdump command. To make things easier scripts/decodecode is
+supplied::
+
+ $echo 'Code: b00003c0 912ad000 940029d6 17ffff52 (e7f7defb)' | \
+ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 scripts/decodecode
+ Code: b00003c0 912ad000 940029d6 17ffff52 (e7f7defb)
+ All code
+ ========
+ 0: b00003c0 adrp x0, 0x79000
+ 4: 912ad000 add x0, x0, #0xab4
+ 8: 940029d6 bl 0xa760
+ c: 17ffff52 b 0xfffffffffffffd54
+ 10:* e7f7defb .inst 0xe7f7defb ; undefined <-- trapping instruction
+
+ Code starting with the faulting instruction
+ ===========================================
+ 0: e7f7defb .inst 0xe7f7defb ; undefined
+
+Now lets use the locations provided by the elr and lr registers after
+subtracting the relocation offset to find out where in the code the crash
+occurred and from where it was invoked.
+
+File u-boot.map contains the memory layout of the U-Boot binary. Here we find
+these lines::
+
+ .text.do_undefined
+ 0x00000000000101fc 0xc cmd/built-in.o
+ .text.exception_complete
+ 0x0000000000010208 0x90 cmd/built-in.o
+ ...
+ .text.cmd_process
+ 0x00000000000213b8 0x164 common/built-in.o
+ 0x00000000000213b8 cmd_process
+ .text.cmd_process_error
+ 0x000000000002151c 0x40 common/built-in.o
+ 0x000000000002151c cmd_process_error
+
+So the error occurred at the start of function do\_undefined() and this
+function was invoked from somewhere inside function cmd\_process().
+
+If we want to dive deeper, we can disassemble the U-Boot binary::
+
+ $ aarch64-linux-gnu-objdump -S -D u-boot | less
+
+ 00000000000101fc <do_undefined>:
+ {
+ /*
+ * 0xe7f...f. is undefined in ARM mode
+ * 0xde.. is undefined in Thumb mode
+ */
+ asm volatile (".word 0xe7f7defb\n");
+ 101fc: e7f7defb .inst 0xe7f7defb ; undefined
+ return CMD_RET_FAILURE;
+ }
+ 10200: 52800020 mov w0, #0x1 // #1
+ 10204: d65f03c0 ret
+
+This example is based on the ARMv8 architecture but the same procedures can be
+used on other architectures as well.
diff --git a/roms/u-boot/doc/develop/driver-model/bind.rst b/roms/u-boot/doc/develop/driver-model/bind.rst
new file mode 100644
index 000000000..b19661b5f
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/bind.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Patrice Chotard <patrice.chotard@foss.st.com>
+
+Binding/unbinding a driver
+==========================
+
+This document aims to describe the bind and unbind commands.
+
+For debugging purpose, it should be useful to bind or unbind a driver from
+the U-boot command line.
+
+The unbind command calls the remove device driver callback and unbind the
+device from its driver.
+
+The bind command binds a device to its driver.
+
+In some cases it can be useful to be able to bind a device to a driver from
+the command line.
+The obvious example is for versatile devices such as USB gadget.
+Another use case is when the devices are not yet ready at startup and
+require some setup before the drivers are bound (ex: FPGA which bitsream is
+fetched from a mass storage or ethernet)
+
+usage:
+
+bind <node path> <driver>
+bind <class> <index> <driver>
+
+unbind <node path>
+unbind <class> <index>
+unbind <class> <index> <driver>
+
+Where:
+ - <node path> is the node's device tree path
+ - <class> is one of the class available in the list given by the "dm uclass"
+ command or first column of "dm tree" command.
+ - <index> is the index of the parent's node (second column of "dm tree" output).
+ - <driver> is the driver name to bind given by the "dm drivers" command or the by
+ the fourth column of "dm tree" output.
+
+example:
+
+bind usb_dev_generic 0 usb_ether
+unbind usb_dev_generic 0 usb_ether
+or
+unbind eth 1
+
+bind /ocp/omap_dwc3@48380000/usb@48390000 usb_ether
+unbind /ocp/omap_dwc3@48380000/usb@48390000
diff --git a/roms/u-boot/doc/develop/driver-model/debugging.rst b/roms/u-boot/doc/develop/driver-model/debugging.rst
new file mode 100644
index 000000000..bbb279434
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/debugging.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Debugging driver model
+======================
+
+This document aims to provide help when you cannot work out why driver model is
+not doing what you expect.
+
+
+Useful techniques in general
+----------------------------
+
+Here are some useful debugging features generally.
+
+ - If you are writing a new feature, consider doing it in sandbox instead of
+ on your board. Sandbox has no limits, allows easy debugging (e.g. gdb) and
+ you can write emulators for most common devices.
+ - Put '#define DEBUG' at the top of a file, to activate all the debug() and
+ log_debug() statements in that file.
+ - Where logging is used, change the logging level, e.g. in SPL with
+ CONFIG_SPL_LOG_MAX_LEVEL=7 (which is LOGL_DEBUG) and
+ CONFIG_LOG_DEFAULT_LEVEL=7
+ - Where logging of return values is implemented with log_msg_ret(), set
+ CONFIG_LOG_ERROR_RETURN=y to see exactly where the error is happening
+ - Make sure you have a debug UART enabled - see CONFIG_DEBUG_UART. With this
+ you can get serial output (printf(), etc.) before the serial driver is
+ running.
+ - Use a JTAG emulator to set breakpoints and single-step through code
+
+Not that most of these increase code/data size somewhat when enabled.
+
+
+Failure to locate a device
+--------------------------
+
+Let's say you have uclass_first_device_err() and it is not finding anything.
+
+If it is returning an error, then that gives you a clue. Look up linux/errno.h
+to see errors. Common ones are:
+
+ - -ENOMEM which indicates that memory is short. If it happens in SPL or
+ before relocation in U-Boot, check CONFIG_SPL_SYS_MALLOC_F_LEN and
+ CONFIG_SYS_MALLOC_F_LEN as they may need to be larger. Add '#define DEBUG'
+ at the very top of malloc_simple.c to get an idea of where your memory is
+ going.
+ - -EINVAL which typically indicates that something was missing or wrong in
+ the device tree node. Check that everything is correct and look at the
+ of_to_plat() method in the driver.
+
+If there is no error, you should check if the device is actually bound. Call
+dm_dump_all() just before you locate the device to make sure it exists.
+
+If it does not exist, check your device tree compatible strings match up with
+what the driver expects (in the struct udevice_id array).
+
+If you are using of-platdata (e.g. CONFIG_SPL_OF_PLATDATA), check that the
+driver name is the same as the first compatible string in the device tree (with
+invalid-variable characters converted to underscore).
+
+If you are really stuck, putting '#define LOG_DEBUG' at the top of
+drivers/core/lists.c should show you what is going on.
diff --git a/roms/u-boot/doc/develop/driver-model/design.rst b/roms/u-boot/doc/develop/driver-model/design.rst
new file mode 100644
index 000000000..b0e633703
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/design.rst
@@ -0,0 +1,1149 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Design Details
+==============
+
+This README contains high-level information about driver model, a unified
+way of declaring and accessing drivers in U-Boot. The original work was done
+by:
+
+ * Marek Vasut <marex@denx.de>
+ * Pavel Herrmann <morpheus.ibis@gmail.com>
+ * Viktor Křivák <viktor.krivak@gmail.com>
+ * Tomas Hlavacek <tmshlvck@gmail.com>
+
+This has been both simplified and extended into the current implementation
+by:
+
+ * Simon Glass <sjg@chromium.org>
+
+
+Terminology
+-----------
+
+Uclass
+ a group of devices which operate in the same way. A uclass provides
+ a way of accessing individual devices within the group, but always
+ using the same interface. For example a GPIO uclass provides
+ operations for get/set value. An I2C uclass may have 10 I2C ports,
+ 4 with one driver, and 6 with another.
+
+Driver
+ some code which talks to a peripheral and presents a higher-level
+ interface to it.
+
+Device
+ an instance of a driver, tied to a particular port or peripheral.
+
+
+How to try it
+-------------
+
+Build U-Boot sandbox and run it::
+
+ make sandbox_defconfig
+ make
+ ./u-boot -d u-boot.dtb
+
+ (type 'reset' to exit U-Boot)
+
+
+There is a uclass called 'demo'. This uclass handles
+saying hello, and reporting its status. There are two drivers in this
+uclass:
+
+ - simple: Just prints a message for hello, doesn't implement status
+ - shape: Prints shapes and reports number of characters printed as status
+
+The demo class is pretty simple, but not trivial. The intention is that it
+can be used for testing, so it will implement all driver model features and
+provide good code coverage of them. It does have multiple drivers, it
+handles parameter data and plat (data which tells the driver how
+to operate on a particular platform) and it uses private driver data.
+
+To try it, see the example session below::
+
+ =>demo hello 1
+ Hello '@' from 07981110: red 4
+ =>demo status 2
+ Status: 0
+ =>demo hello 2
+ g
+ r@
+ e@@
+ e@@@
+ n@@@@
+ g@@@@@
+ =>demo status 2
+ Status: 21
+ =>demo hello 4 ^
+ y^^^
+ e^^^^^
+ l^^^^^^^
+ l^^^^^^^
+ o^^^^^
+ w^^^
+ =>demo status 4
+ Status: 36
+ =>
+
+
+Running the tests
+-----------------
+
+The intent with driver model is that the core portion has 100% test coverage
+in sandbox, and every uclass has its own test. As a move towards this, tests
+are provided in test/dm. To run them, try::
+
+ ./test/py/test.py --bd sandbox --build -k ut_dm -v
+
+You should see something like this::
+
+ (venv)$ ./test/py/test.py --bd sandbox --build -k ut_dm -v
+ +make O=/root/u-boot/build-sandbox -s sandbox_defconfig
+ +make O=/root/u-boot/build-sandbox -s -j8
+ ============================= test session starts ==============================
+ platform linux2 -- Python 2.7.5, pytest-2.9.0, py-1.4.31, pluggy-0.3.1 -- /root/u-boot/venv/bin/python
+ cachedir: .cache
+ rootdir: /root/u-boot, inifile:
+ collected 199 items
+
+ test/py/tests/test_ut.py::test_ut_dm_init PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_bind] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_multi_channel_conversion] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_multi_channel_shot] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_single_channel_conversion] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_single_channel_shot] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_supply] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_adc_wrong_channel_selection] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_autobind] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_autobind_uclass_pdata_alloc] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_autobind_uclass_pdata_valid] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_autoprobe] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_child_post_bind] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_child_post_bind_uclass] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_child_pre_probe_uclass] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_children] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_children_funcs] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_children_iterators] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_parent_data] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_parent_data_uclass] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_parent_ops] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_parent_platdata] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_bus_parent_platdata_uclass] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_children] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_clk_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_clk_periph] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_device_get_uclass_id] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_eth] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_eth_act] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_eth_alias] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_eth_prime] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_eth_rotate] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_fdt] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_fdt_offset] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_fdt_pre_reloc] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_fdt_uclass_seq] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio_anon] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio_copy] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio_leak] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio_phandles] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_gpio_requestf] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_bytewise] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_find] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_offset] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_offset_len] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_probe_empty] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_read_write] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_i2c_speed] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_leak] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_led_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_led_gpio] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_led_label] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_lifecycle] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_mmc_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_net_retry] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_operations] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_ordering] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_pci_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_pci_busnum] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_pci_swapcase] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_platdata] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_pmic_get] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_pmic_io] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_autoset] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_autoset_list] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_get] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_set_get_current] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_set_get_enable] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_set_get_mode] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_power_regulator_set_get_voltage] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_pre_reloc] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_ram_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_regmap_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_regmap_syscon] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_remoteproc_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_remove] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_reset_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_reset_walk] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_rtc_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_rtc_dual] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_rtc_reset] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_rtc_set_get] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_spi_find] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_spi_flash] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_spi_xfer] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_syscon_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_syscon_by_driver_data] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_timer_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass_before_ready] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass_devices_find] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass_devices_find_by_name] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass_devices_get] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_uclass_devices_get_by_name] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_flash] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_keyb] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_multi] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_remove] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_tree] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_tree_remove] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_usb_tree_reorder] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_base] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_bmp] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_bmp_comp] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_chars] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_context] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_rotation1] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_rotation2] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_rotation3] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_text] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_truetype] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_truetype_bs] PASSED
+ test/py/tests/test_ut.py::test_ut[ut_dm_video_truetype_scroll] PASSED
+
+ ======================= 84 tests deselected by '-kut_dm' =======================
+ ================== 115 passed, 84 deselected in 3.77 seconds ===================
+
+What is going on?
+-----------------
+
+Let's start at the top. The demo command is in cmd/demo.c. It does
+the usual command processing and then:
+
+.. code-block:: c
+
+ struct udevice *demo_dev;
+
+ ret = uclass_get_device(UCLASS_DEMO, devnum, &demo_dev);
+
+UCLASS_DEMO means the class of devices which implement 'demo'. Other
+classes might be MMC, or GPIO, hashing or serial. The idea is that the
+devices in the class all share a particular way of working. The class
+presents a unified view of all these devices to U-Boot.
+
+This function looks up a device for the demo uclass. Given a device
+number we can find the device because all devices have registered with
+the UCLASS_DEMO uclass.
+
+The device is automatically activated ready for use by uclass_get_device().
+
+Now that we have the device we can do things like:
+
+.. code-block:: c
+
+ return demo_hello(demo_dev, ch);
+
+This function is in the demo uclass. It takes care of calling the 'hello'
+method of the relevant driver. Bearing in mind that there are two drivers,
+this particular device may use one or other of them.
+
+The code for demo_hello() is in drivers/demo/demo-uclass.c:
+
+.. code-block:: c
+
+ int demo_hello(struct udevice *dev, int ch)
+ {
+ const struct demo_ops *ops = device_get_ops(dev);
+
+ if (!ops->hello)
+ return -ENOSYS;
+
+ return ops->hello(dev, ch);
+ }
+
+As you can see it just calls the relevant driver method. One of these is
+in drivers/demo/demo-simple.c:
+
+.. code-block:: c
+
+ static int simple_hello(struct udevice *dev, int ch)
+ {
+ const struct dm_demo_pdata *pdata = dev_get_plat(dev);
+
+ printf("Hello from %08x: %s %d\n", map_to_sysmem(dev),
+ pdata->colour, pdata->sides);
+
+ return 0;
+ }
+
+
+So that is a trip from top (command execution) to bottom (driver action)
+but it leaves a lot of topics to address.
+
+
+Declaring Drivers
+-----------------
+
+A driver declaration looks something like this (see
+drivers/demo/demo-shape.c):
+
+.. code-block:: c
+
+ static const struct demo_ops shape_ops = {
+ .hello = shape_hello,
+ .status = shape_status,
+ };
+
+ U_BOOT_DRIVER(demo_shape_drv) = {
+ .name = "demo_shape_drv",
+ .id = UCLASS_DEMO,
+ .ops = &shape_ops,
+ .priv_data_size = sizeof(struct shape_data),
+ };
+
+
+This driver has two methods (hello and status) and requires a bit of
+private data (accessible through dev_get_priv(dev) once the driver has
+been probed). It is a member of UCLASS_DEMO so will register itself
+there.
+
+In U_BOOT_DRIVER it is also possible to specify special methods for bind
+and unbind, and these are called at appropriate times. For many drivers
+it is hoped that only 'probe' and 'remove' will be needed.
+
+The U_BOOT_DRIVER macro creates a data structure accessible from C,
+so driver model can find the drivers that are available.
+
+The methods a device can provide are documented in the device.h header.
+Briefly, they are:
+
+ * bind - make the driver model aware of a device (bind it to its driver)
+ * unbind - make the driver model forget the device
+ * of_to_plat - convert device tree data to plat - see later
+ * probe - make a device ready for use
+ * remove - remove a device so it cannot be used until probed again
+
+The sequence to get a device to work is bind, of_to_plat (if using
+device tree) and probe.
+
+
+Platform Data
+-------------
+
+Note: platform data is the old way of doing things. It is
+basically a C structure which is passed to drivers to tell them about
+platform-specific settings like the address of its registers, bus
+speed, etc. Device tree is now the preferred way of handling this.
+Unless you have a good reason not to use device tree (the main one
+being you need serial support in SPL and don't have enough SRAM for
+the cut-down device tree and libfdt libraries) you should stay away
+from platform data.
+
+Platform data is like Linux platform data, if you are familiar with that.
+It provides the board-specific information to start up a device.
+
+Why is this information not just stored in the device driver itself? The
+idea is that the device driver is generic, and can in principle operate on
+any board that has that type of device. For example, with modern
+highly-complex SoCs it is common for the IP to come from an IP vendor, and
+therefore (for example) the MMC controller may be the same on chips from
+different vendors. It makes no sense to write independent drivers for the
+MMC controller on each vendor's SoC, when they are all almost the same.
+Similarly, we may have 6 UARTs in an SoC, all of which are mostly the same,
+but lie at different addresses in the address space.
+
+Using the UART example, we have a single driver and it is instantiated 6
+times by supplying 6 lots of platform data. Each lot of platform data
+gives the driver name and a pointer to a structure containing information
+about this instance - e.g. the address of the register space. It may be that
+one of the UARTS supports RS-485 operation - this can be added as a flag in
+the platform data, which is set for this one port and clear for the rest.
+
+Think of your driver as a generic piece of code which knows how to talk to
+a device, but needs to know where it is, any variant/option information and
+so on. Platform data provides this link between the generic piece of code
+and the specific way it is bound on a particular board.
+
+Examples of platform data include:
+
+ - The base address of the IP block's register space
+ - Configuration options, like:
+ - the SPI polarity and maximum speed for a SPI controller
+ - the I2C speed to use for an I2C device
+ - the number of GPIOs available in a GPIO device
+
+Where does the platform data come from? It is either held in a structure
+which is compiled into U-Boot, or it can be parsed from the Device Tree
+(see 'Device Tree' below).
+
+For an example of how it can be compiled in, see demo-pdata.c which
+sets up a table of driver names and their associated platform data.
+The data can be interpreted by the drivers however they like - it is
+basically a communication scheme between the board-specific code and
+the generic drivers, which are intended to work on any board.
+
+Drivers can access their data via dev->info->plat. Here is
+the declaration for the platform data, which would normally appear
+in the board file.
+
+.. code-block:: c
+
+ static const struct dm_demo_pdata red_square = {
+ .colour = "red",
+ .sides = 4.
+ };
+
+ static const struct driver_info info[] = {
+ {
+ .name = "demo_shape_drv",
+ .plat = &red_square,
+ },
+ };
+
+ demo1 = driver_bind(root, &info[0]);
+
+
+Device Tree
+-----------
+
+While plat is useful, a more flexible way of providing device data is
+by using device tree. In U-Boot you should use this where possible. Avoid
+sending patches which make use of the U_BOOT_DRVINFO() macro unless strictly
+necessary.
+
+With device tree we replace the above code with the following device tree
+fragment:
+
+.. code-block:: c
+
+ red-square {
+ compatible = "demo-shape";
+ colour = "red";
+ sides = <4>;
+ };
+
+This means that instead of having lots of U_BOOT_DRVINFO() declarations in
+the board file, we put these in the device tree. This approach allows a lot
+more generality, since the same board file can support many types of boards
+(e,g. with the same SoC) just by using different device trees. An added
+benefit is that the Linux device tree can be used, thus further simplifying
+the task of board-bring up either for U-Boot or Linux devs (whoever gets to
+the board first!).
+
+The easiest way to make this work it to add a few members to the driver:
+
+.. code-block:: c
+
+ .plat_auto = sizeof(struct dm_test_pdata),
+ .of_to_plat = testfdt_of_to_plat,
+
+The 'auto' feature allowed space for the plat to be allocated
+and zeroed before the driver's of_to_plat() method is called. The
+of_to_plat() method, which the driver write supplies, should parse
+the device tree node for this device and place it in dev->plat. Thus
+when the probe method is called later (to set up the device ready for use)
+the platform data will be present.
+
+Note that both methods are optional. If you provide an of_to_plat
+method then it will be called first (during activation). If you provide a
+probe method it will be called next. See Driver Lifecycle below for more
+details.
+
+If you don't want to have the plat automatically allocated then you
+can leave out plat_auto. In this case you can use malloc
+in your of_to_plat (or probe) method to allocate the required memory,
+and you should free it in the remove method.
+
+The driver model tree is intended to mirror that of the device tree. The
+root driver is at device tree offset 0 (the root node, '/'), and its
+children are the children of the root node.
+
+In order for a device tree to be valid, the content must be correct with
+respect to either device tree specification
+(https://www.devicetree.org/specifications/) or the device tree bindings that
+are found in the doc/device-tree-bindings directory. When not U-Boot specific
+the bindings in this directory tend to come from the Linux Kernel. As such
+certain design decisions may have been made already for us in terms of how
+specific devices are described and bound. In most circumstances we wish to
+retain compatibility without additional changes being made to the device tree
+source files.
+
+Declaring Uclasses
+------------------
+
+The demo uclass is declared like this:
+
+.. code-block:: c
+
+ UCLASS_DRIVER(demo) = {
+ .id = UCLASS_DEMO,
+ };
+
+It is also possible to specify special methods for probe, etc. The uclass
+numbering comes from include/dm/uclass-id.h. To add a new uclass, add to the
+end of the enum there, then declare your uclass as above.
+
+
+Device Sequence Numbers
+-----------------------
+
+U-Boot numbers devices from 0 in many situations, such as in the command
+line for I2C and SPI buses, and the device names for serial ports (serial0,
+serial1, ...). Driver model supports this numbering and permits devices
+to be locating by their 'sequence'. This numbering uniquely identifies a
+device in its uclass, so no two devices within a particular uclass can have
+the same sequence number.
+
+Sequence numbers start from 0 but gaps are permitted. For example, a board
+may have I2C buses 1, 4, 5 but no 0, 2 or 3. The choice of how devices are
+numbered is up to a particular board, and may be set by the SoC in some
+cases. While it might be tempting to automatically renumber the devices
+where there are gaps in the sequence, this can lead to confusion and is
+not the way that U-Boot works.
+
+Where a device gets its sequence number is controlled by the DM_SEQ_ALIAS
+Kconfig option, which can have a different value in U-Boot proper and SPL.
+If this option is not set, aliases are ignored.
+
+Even if CONFIG_DM_SEQ_ALIAS is enabled, the uclass must still have the
+DM_UC_FLAG_SEQ_ALIAS flag set, for its devices to be sequenced by aliases.
+
+With those options set, devices with an alias (e.g. "serial2") will get that
+sequence number (e.g. 2). Other devices get the next available number after all
+aliases and all existing numbers. This means that if there is just a single
+alias "serial2", unaliased serial devices will be assigned 3 or more, with 0 and
+1 being unused.
+
+If CONFIG_DM_SEQ_ALIAS or DM_UC_FLAG_SEQ_ALIAS are not set, all devices will get
+sequence numbers in a simple ordering starting from 0. To find the next number
+to allocate, driver model scans through to find the maximum existing number,
+then uses the next one. It does not attempt to fill in gaps.
+
+.. code-block:: none
+
+ aliases {
+ serial2 = "/serial@22230000";
+ };
+
+This indicates that in the uclass called "serial", the named node
+("/serial@22230000") will be given sequence number 2. Any command or driver
+which requests serial device 2 will obtain this device.
+
+More commonly you can use node references, which expand to the full path:
+
+.. code-block:: none
+
+ aliases {
+ serial2 = &serial_2;
+ };
+ ...
+ serial_2: serial@22230000 {
+ ...
+ };
+
+The alias resolves to the same string in this case, but this version is
+easier to read.
+
+Device sequence numbers are resolved when a device is bound and the number does
+not change for the life of the device.
+
+There are some situations where the uclass must allocate sequence numbers,
+since a strictly increase sequence (with devicetree nodes bound first) is not
+suitable. An example of this is the PCI bus. In this case, you can set the
+uclass DM_UC_FLAG_NO_AUTO_SEQ flag. With this flag set, only devices with an
+alias will be assigned a number by driver model. The rest is left to the uclass
+to sort out, e.g. when enumerating the bus.
+
+Note that changing the sequence number for a device (e.g. in a driver) is not
+permitted. If it is felt to be necessary, ask on the mailing list.
+
+Bus Drivers
+-----------
+
+A common use of driver model is to implement a bus, a device which provides
+access to other devices. Example of buses include SPI and I2C. Typically
+the bus provides some sort of transport or translation that makes it
+possible to talk to the devices on the bus.
+
+Driver model provides some useful features to help with implementing buses.
+Firstly, a bus can request that its children store some 'parent data' which
+can be used to keep track of child state. Secondly, the bus can define
+methods which are called when a child is probed or removed. This is similar
+to the methods the uclass driver provides. Thirdly, per-child platform data
+can be provided to specify things like the child's address on the bus. This
+persists across child probe()/remove() cycles.
+
+For consistency and ease of implementation, the bus uclass can specify the
+per-child platform data, so that it can be the same for all children of buses
+in that uclass. There are also uclass methods which can be called when
+children are bound and probed.
+
+Here an explanation of how a bus fits with a uclass may be useful. Consider
+a USB bus with several devices attached to it, each from a different (made
+up) uclass::
+
+ xhci_usb (UCLASS_USB)
+ eth (UCLASS_ETH)
+ camera (UCLASS_CAMERA)
+ flash (UCLASS_FLASH_STORAGE)
+
+Each of the devices is connected to a different address on the USB bus.
+The bus device wants to store this address and some other information such
+as the bus speed for each device.
+
+To achieve this, the bus device can use dev->parent_plat in each of its
+three children. This can be auto-allocated if the bus driver (or bus uclass)
+has a non-zero value for per_child_plat_auto. If not, then
+the bus device or uclass can allocate the space itself before the child
+device is probed.
+
+Also the bus driver can define the child_pre_probe() and child_post_remove()
+methods to allow it to do some processing before the child is activated or
+after it is deactivated.
+
+Similarly the bus uclass can define the child_post_bind() method to obtain
+the per-child platform data from the device tree and set it up for the child.
+The bus uclass can also provide a child_pre_probe() method. Very often it is
+the bus uclass that controls these features, since it avoids each driver
+having to do the same processing. Of course the driver can still tweak and
+override these activities.
+
+Note that the information that controls this behaviour is in the bus's
+driver, not the child's. In fact it is possible that child has no knowledge
+that it is connected to a bus. The same child device may even be used on two
+different bus types. As an example. the 'flash' device shown above may also
+be connected on a SATA bus or standalone with no bus::
+
+ xhci_usb (UCLASS_USB)
+ flash (UCLASS_FLASH_STORAGE) - parent data/methods defined by USB bus
+
+ sata (UCLASS_AHCI)
+ flash (UCLASS_FLASH_STORAGE) - parent data/methods defined by SATA bus
+
+ flash (UCLASS_FLASH_STORAGE) - no parent data/methods (not on a bus)
+
+Above you can see that the driver for xhci_usb/sata controls the child's
+bus methods. In the third example the device is not on a bus, and therefore
+will not have these methods at all. Consider the case where the flash
+device defines child methods. These would be used for *its* children, and
+would be quite separate from the methods defined by the driver for the bus
+that the flash device is connetced to. The act of attaching a device to a
+parent device which is a bus, causes the device to start behaving like a
+bus device, regardless of its own views on the matter.
+
+The uclass for the device can also contain data private to that uclass.
+But note that each device on the bus may be a member of a different
+uclass, and this data has nothing to do with the child data for each child
+on the bus. It is the bus' uclass that controls the child with respect to
+the bus.
+
+
+Driver Lifecycle
+----------------
+
+Here are the stages that a device goes through in driver model. Note that all
+methods mentioned here are optional - e.g. if there is no probe() method for
+a device then it will not be called. A simple device may have very few
+methods actually defined.
+
+Bind stage
+^^^^^^^^^^
+
+U-Boot discovers devices using one of these two methods:
+
+- Scan the U_BOOT_DRVINFO() definitions. U-Boot looks up the name specified
+ by each, to find the appropriate U_BOOT_DRIVER() definition. In this case,
+ there is no path by which driver_data may be provided, but the U_BOOT_DRVINFO()
+ may provide plat.
+
+- Scan through the device tree definitions. U-Boot looks at top-level
+ nodes in the the device tree. It looks at the compatible string in each node
+ and uses the of_match table of the U_BOOT_DRIVER() structure to find the
+ right driver for each node. In this case, the of_match table may provide a
+ driver_data value, but plat cannot be provided until later.
+
+For each device that is discovered, U-Boot then calls device_bind() to create a
+new device, initializes various core fields of the device object such as name,
+uclass & driver, initializes any optional fields of the device object that are
+applicable such as of_offset, driver_data & plat, and finally calls the
+driver's bind() method if one is defined.
+
+At this point all the devices are known, and bound to their drivers. There
+is a 'struct udevice' allocated for all devices. However, nothing has been
+activated (except for the root device). Each bound device that was created
+from a U_BOOT_DRVINFO() declaration will hold the plat pointer specified
+in that declaration. For a bound device created from the device tree,
+plat will be NULL, but of_offset will be the offset of the device tree
+node that caused the device to be created. The uclass is set correctly for
+the device.
+
+The device's sequence number is assigned, either the requested one or the next
+available one (after all aliases are processed) if nothing particular is
+requested.
+
+The device's bind() method is permitted to perform simple actions, but
+should not scan the device tree node, not initialise hardware, nor set up
+structures or allocate memory. All of these tasks should be left for
+the probe() method.
+
+Note that compared to Linux, U-Boot's driver model has a separate step of
+probe/remove which is independent of bind/unbind. This is partly because in
+U-Boot it may be expensive to probe devices and we don't want to do it until
+they are needed, or perhaps until after relocation.
+
+Reading ofdata
+^^^^^^^^^^^^^^
+
+Most devices have data in the device tree which they can read to find out the
+base address of hardware registers and parameters relating to driver
+operation. This is called 'ofdata' (Open-Firmware data).
+
+The device's of_to_plat() implemnents allocation and reading of
+plat. A parent's ofdata is always read before a child.
+
+The steps are:
+
+ 1. If priv_auto is non-zero, then the device-private space
+ is allocated for the device and zeroed. It will be accessible as
+ dev->priv. The driver can put anything it likes in there, but should use
+ it for run-time information, not platform data (which should be static
+ and known before the device is probed).
+
+ 2. If plat_auto is non-zero, then the platform data space
+ is allocated. This is only useful for device tree operation, since
+ otherwise you would have to specify the platform data in the
+ U_BOOT_DRVINFO() declaration. The space is allocated for the device and
+ zeroed. It will be accessible as dev->plat.
+
+ 3. If the device's uclass specifies a non-zero per_device_auto,
+ then this space is allocated and zeroed also. It is allocated for and
+ stored in the device, but it is uclass data. owned by the uclass driver.
+ It is possible for the device to access it.
+
+ 4. If the device's immediate parent specifies a per_child_auto
+ then this space is allocated. This is intended for use by the parent
+ device to keep track of things related to the child. For example a USB
+ flash stick attached to a USB host controller would likely use this
+ space. The controller can hold information about the USB state of each
+ of its children.
+
+ 5. If the driver provides an of_to_plat() method, then this is
+ called to convert the device tree data into platform data. This should
+ do various calls like dev_read_u32(dev, ...) to access the node and store
+ the resulting information into dev->plat. After this point, the device
+ works the same way whether it was bound using a device tree node or
+ U_BOOT_DRVINFO() structure. In either case, the platform data is now stored
+ in the plat structure. Typically you will use the
+ plat_auto feature to specify the size of the platform data
+ structure, and U-Boot will automatically allocate and zero it for you before
+ entry to of_to_plat(). But if not, you can allocate it yourself in
+ of_to_plat(). Note that it is preferable to do all the device tree
+ decoding in of_to_plat() rather than in probe(). (Apart from the
+ ugliness of mixing configuration and run-time data, one day it is possible
+ that U-Boot will cache platform data for devices which are regularly
+ de/activated).
+
+ 6. The device is marked 'plat valid'.
+
+Note that ofdata reading is always done (for a child and all its parents)
+before probing starts. Thus devices go through two distinct states when
+probing: reading platform data and actually touching the hardware to bring
+the device up.
+
+Having probing separate from ofdata-reading helps deal with of-platdata, where
+the probe() method is common to both DT/of-platdata operation, but the
+of_to_plat() method is implemented differently.
+
+Another case has come up where this separate is useful. Generation of ACPI
+tables uses the of-platdata but does not want to probe the device. Probing
+would cause U-Boot to violate one of its design principles, viz that it
+should only probe devices that are used. For ACPI we want to generate a
+table for each device, even if U-Boot does not use it. In fact it may not
+even be possible to probe the device - e.g. an SD card which is not
+present will cause an error on probe, yet we still must tell Linux about
+the SD card connector in case it is used while Linux is running.
+
+It is important that the of_to_plat() method does not actually probe
+the device itself. However there are cases where other devices must be probed
+in the of_to_plat() method. An example is where a device requires a
+GPIO for it to operate. To select a GPIO obviously requires that the GPIO
+device is probed. This is OK when used by common, core devices such as GPIO,
+clock, interrupts, reset and the like.
+
+If your device relies on its parent setting up a suitable address space, so
+that dev_read_addr() works correctly, then make sure that the parent device
+has its setup code in of_to_plat(). If it has it in the probe method,
+then you cannot call dev_read_addr() from the child device's
+of_to_plat() method. Move it to probe() instead. Buses like PCI can
+fall afoul of this rule.
+
+Activation/probe
+^^^^^^^^^^^^^^^^
+
+When a device needs to be used, U-Boot activates it, by first reading ofdata
+as above and then following these steps (see device_probe()):
+
+ 1. All parent devices are probed. It is not possible to activate a device
+ unless its predecessors (all the way up to the root device) are activated.
+ This means (for example) that an I2C driver will require that its bus
+ be activated.
+
+ 2. The device's probe() method is called. This should do anything that
+ is required by the device to get it going. This could include checking
+ that the hardware is actually present, setting up clocks for the
+ hardware and setting up hardware registers to initial values. The code
+ in probe() can access:
+
+ - platform data in dev->plat (for configuration)
+ - private data in dev->priv (for run-time state)
+ - uclass data in dev->uclass_priv (for things the uclass stores
+ about this device)
+
+ Note: If you don't use priv_auto then you will need to
+ allocate the priv space here yourself. The same applies also to
+ plat_auto. Remember to free them in the remove() method.
+
+ 3. The device is marked 'activated'
+
+ 4. The uclass's post_probe() method is called, if one exists. This may
+ cause the uclass to do some housekeeping to record the device as
+ activated and 'known' by the uclass.
+
+Running stage
+^^^^^^^^^^^^^
+
+The device is now activated and can be used. From now until it is removed
+all of the above structures are accessible. The device appears in the
+uclass's list of devices (so if the device is in UCLASS_GPIO it will appear
+as a device in the GPIO uclass). This is the 'running' state of the device.
+
+Removal stage
+^^^^^^^^^^^^^
+
+When the device is no-longer required, you can call device_remove() to
+remove it. This performs the probe steps in reverse:
+
+ 1. The uclass's pre_remove() method is called, if one exists. This may
+ cause the uclass to do some housekeeping to record the device as
+ deactivated and no-longer 'known' by the uclass.
+
+ 2. All the device's children are removed. It is not permitted to have
+ an active child device with a non-active parent. This means that
+ device_remove() is called for all the children recursively at this point.
+
+ 3. The device's remove() method is called. At this stage nothing has been
+ deallocated so platform data, private data and the uclass data will all
+ still be present. This is where the hardware can be shut down. It is
+ intended that the device be completely inactive at this point, For U-Boot
+ to be sure that no hardware is running, it should be enough to remove
+ all devices.
+
+ 4. The device memory is freed (platform data, private data, uclass data,
+ parent data).
+
+ Note: Because the platform data for a U_BOOT_DRVINFO() is defined with a
+ static pointer, it is not de-allocated during the remove() method. For
+ a device instantiated using the device tree data, the platform data will
+ be dynamically allocated, and thus needs to be deallocated during the
+ remove() method, either:
+
+ - if the plat_auto is non-zero, the deallocation happens automatically
+ within the driver model core in the unbind stage; or
+
+ - when plat_auto is 0, both the allocation (in probe()
+ or preferably of_to_plat()) and the deallocation in remove()
+ are the responsibility of the driver author.
+
+ 5. The device is marked inactive. Note that it is still bound, so the
+ device structure itself is not freed at this point. Should the device be
+ activated again, then the cycle starts again at step 2 above.
+
+Unbind stage
+^^^^^^^^^^^^
+
+The device is unbound. This is the step that actually destroys the device.
+If a parent has children these will be destroyed first. After this point
+the device does not exist and its memory has be deallocated.
+
+
+Special cases for removal
+-------------------------
+
+Some devices need to do clean-up before the OS is called. For example, a USB
+driver may want to stop the bus. This can be done in the remove() method.
+Some special flags are used to determine whether to remove the device:
+
+ DM_FLAG_OS_PREPARE - indicates that the device needs to get ready for OS
+ boot. The device will be removed just before the OS is booted
+ DM_REMOVE_ACTIVE_DMA - indicates that the device uses DMA. This is
+ effectively the same as DM_FLAG_OS_PREPARE, so the device is removed
+ before the OS is booted
+ DM_FLAG_VITAL - indicates that the device is 'vital' to the operation of
+ other devices. It is possible to remove this device after all regular
+ devices are removed. This is useful e.g. for a clock, which need to
+ be active during the device-removal phase.
+
+The dm_remove_devices_flags() function can be used to remove devices based on
+their driver flags.
+
+
+Error codes
+-----------
+
+Driver model tries to use errors codes in a consistent way, as follows:
+
+\-EAGAIN
+ Try later, e.g. dependencies not ready
+
+\-EINVAL
+ Invalid argument, such as `dev_read_...()` failed or any other
+ devicetree-related access. Also used when a driver method is passed an
+ argument it considers invalid or does not support.
+
+\-EIO
+ Failed to perform an I/O operation. This is used when a local device
+ (i.e. part of the SOC) does not work as expected. Use -EREMOTEIO for
+ failures to talk to a separate device, e.g. over an I2C or SPI
+ channel.
+
+\-ENODEV
+ Do not bind the device. This should not be used to indicate an
+ error probing the device or for any other purpose, lest driver model get
+ confused. Using `-ENODEV` inside a driver method makes no sense, since
+ clearly there is a device.
+
+\-ENOENT
+ Entry or object not found. This is used when a device, file or directory
+ cannot be found (e.g. when looked up by name), It can also indicate a
+ missing devicetree subnode.
+
+\-ENOMEM
+ Out of memory
+
+\-ENOSPC
+ Ran out of space (e.g. in a buffer or limited-size array)
+
+\-ENOSYS
+ Function not implemented. This is returned by uclasses where the driver does
+ not implement a particular method. It can also be returned by drivers when
+ a particular sub-method is not implemented. This is widely checked in the
+ wider code base, where a feature may or may not be compiled into U-Boot. It
+ indicates that the feature is not available, but this is often just normal
+ operation. Please do not use -ENOSUPP. If an incorrect or unknown argument
+ is provided to a method (e.g. an unknown clock ID), return -EINVAL.
+
+\-ENXIO
+ Couldn't find device/address. This is used when a device or address
+ could not be obtained or is not valid. It is often used to indicate a
+ different type of problem, if -ENOENT is already used for something else in
+ the driver.
+
+\-EPERM
+ This is -1 so some older code may use it as a generic error. This indicates
+ that an operation is not permitted, e.g. a security violation or policy
+ constraint. It is returned internally when binding devices before relocation,
+ if the device is not marked for pre-relocation use.
+
+\-EPFNOSUPPORT
+ Missing uclass. This is deliberately an uncommon error code so that it can
+ easily be distinguished. If you see this very early in U-Boot, it means that
+ a device exists with a particular uclass but the uclass does not (mostly
+ likely because it is not compiled in). Enable DEBUG in uclass.c or lists.c
+ to see which uclass ID or driver is causing the problem.
+
+\-EREMOTEIO
+ This indicates an error in talking to a peripheral over a comms link, such
+ as I2C or SPI. It might indicate that the device is not present or is not
+ responding as expected.
+
+\-ETIMEDOUT
+ Hardware access or some other operation has timed out. This is used where
+ there is an expected time of response and that was exceeded by enough of
+ a margin that there is probably something wrong.
+
+
+Less common ones:
+
+\-ECOMM
+ Not widely used, but similar to -EREMOTEIO. Can be useful as a secondary
+ error to distinguish the problem from -EREMOTEIO.
+
+\-EKEYREJECTED
+ Attempt to remove a device which does not match the removal flags. See
+ device_remove().
+
+\-EILSEQ
+ Devicetree read failure, specifically trying to read a string index which
+ does not exist, in a string-listg property
+
+\-ENOEXEC
+ Attempt to use a uclass method on a device not in that uclass. This is
+ seldom checked at present, since it is generally a programming error and a
+ waste of code space. A DEBUG-only check would be useful here.
+
+\-ENODATA
+ Devicetree read error, where a property exists but has no data associated
+ with it
+
+\-EOVERFLOW
+ Devicetree read error, where the property is longer than expected
+
+\-EPROBE_DEFER
+ Attempt to remove a non-vital device when the removal flags indicate that
+ only vital devices should be removed
+
+\-ERANGE
+ Returned by regmap functions when arguments are out of range. This can be
+ useful for disinguishing regmap errors from other errors obtained while
+ probing devices.
+
+Drivers should use the same conventions so that things function as expected.
+In particular, if a driver fails to probe, or a uclass operation fails, the
+error code is the primary way to indicate what actually happened.
+
+Printing error messages in drivers is discouraged due to code size bloat and
+since it can result in messages appearing in normal operation. For example, if
+a command tries two different devices and uses whichever one probes correctly,
+we don't want an error message displayed, even if the command itself might show
+a warning or informational message. Ideally, messages in drivers should only be
+displayed when debugging, e.g. by using log_debug() although in extreme cases
+log_warning() or log_error() may be used.
+
+Error messages can be logged using `log_msg_ret()`, so that enabling
+`CONFIG_LOG` and `CONFIG_LOG_ERROR_RETURN` shows a trace of error codes returned
+through the call stack. That can be a handy way of quickly figuring out where
+an error occurred. Get into the habit of return errors with
+`return log_msg_ret("here", ret)` instead of just `return ret`. The string
+just needs to be long enough to find in a single function, since a log record
+stores (and can print with `CONFIG_LOGF_FUNC`) the function where it was
+generated.
+
+
+Data Structures
+---------------
+
+Driver model uses a doubly-linked list as the basic data structure. Some
+nodes have several lists running through them. Creating a more efficient
+data structure might be worthwhile in some rare cases, once we understand
+what the bottlenecks are.
+
+
+Changes since v1
+----------------
+
+For the record, this implementation uses a very similar approach to the
+original patches, but makes at least the following changes:
+
+- Tried to aggressively remove boilerplate, so that for most drivers there
+ is little or no 'driver model' code to write.
+- Moved some data from code into data structure - e.g. store a pointer to
+ the driver operations structure in the driver, rather than passing it
+ to the driver bind function.
+- Rename some structures to make them more similar to Linux (struct udevice
+ instead of struct instance, struct plat, etc.)
+- Change the name 'core' to 'uclass', meaning U-Boot class. It seems that
+ this concept relates to a class of drivers (or a subsystem). We shouldn't
+ use 'class' since it is a C++ reserved word, so U-Boot class (uclass) seems
+ better than 'core'.
+- Remove 'struct driver_instance' and just use a single 'struct udevice'.
+ This removes a level of indirection that doesn't seem necessary.
+- Built in device tree support, to avoid the need for plat
+- Removed the concept of driver relocation, and just make it possible for
+ the new driver (created after relocation) to access the old driver data.
+ I feel that relocation is a very special case and will only apply to a few
+ drivers, many of which can/will just re-init anyway. So the overhead of
+ dealing with this might not be worth it.
+- Implemented a GPIO system, trying to keep it simple
+
+
+Pre-Relocation Support
+----------------------
+
+For pre-relocation we simply call the driver model init function. Only
+drivers marked with DM_FLAG_PRE_RELOC or the device tree 'u-boot,dm-pre-reloc'
+property are initialised prior to relocation. This helps to reduce the driver
+model overhead. This flag applies to SPL and TPL as well, if device tree is
+enabled (CONFIG_OF_CONTROL) there.
+
+Note when device tree is enabled, the device tree 'u-boot,dm-pre-reloc'
+property can provide better control granularity on which device is bound
+before relocation. While with DM_FLAG_PRE_RELOC flag of the driver all
+devices with the same driver are bound, which requires allocation a large
+amount of memory. When device tree is not used, DM_FLAG_PRE_RELOC is the
+only way for statically declared devices via U_BOOT_DRVINFO() to be bound
+prior to relocation.
+
+It is possible to limit this to specific relocation steps, by using
+the more specialized 'u-boot,dm-spl' and 'u-boot,dm-tpl' flags
+in the device tree node. For U-Boot proper you can use 'u-boot,dm-pre-proper'
+which means that it will be processed (and a driver bound) in U-Boot proper
+prior to relocation, but will not be available in SPL or TPL.
+
+To reduce the size of SPL and TPL, only the nodes with pre-relocation properties
+('u-boot,dm-pre-reloc', 'u-boot,dm-spl' or 'u-boot,dm-tpl') are keept in their
+device trees (see README.SPL for details); the remaining nodes are always bound.
+
+Then post relocation we throw that away and re-init driver model again.
+For drivers which require some sort of continuity between pre- and
+post-relocation devices, we can provide access to the pre-relocation
+device pointers, but this is not currently implemented (the root device
+pointer is saved but not made available through the driver model API).
+
+
+SPL Support
+-----------
+
+Driver model can operate in SPL. Its efficient implementation and small code
+size provide for a small overhead which is acceptable for all but the most
+constrained systems.
+
+To enable driver model in SPL, define CONFIG_SPL_DM. You might want to
+consider the following option also. See the main README for more details.
+
+ - CONFIG_SYS_MALLOC_SIMPLE
+ - CONFIG_DM_WARN
+ - CONFIG_DM_DEVICE_REMOVE
+ - CONFIG_DM_STDIO
+
+
+Enabling Driver Model
+---------------------
+
+Driver model is being brought into U-Boot gradually. As each subsystems gets
+support, a uclass is created and a CONFIG to enable use of driver model for
+that subsystem.
+
+For example CONFIG_DM_SERIAL enables driver model for serial. With that
+defined, the old serial support is not enabled, and your serial driver must
+conform to driver model. With that undefined, the old serial support is
+enabled and driver model is not available for serial. This means that when
+you convert a driver, you must either convert all its boards, or provide for
+the driver to be compiled both with and without driver model (generally this
+is not very hard).
+
+See the main README for full details of the available driver model CONFIG
+options.
+
+
+Things to punt for later
+------------------------
+
+Uclasses are statically numbered at compile time. It would be possible to
+change this to dynamic numbering, but then we would require some sort of
+lookup service, perhaps searching by name. This is slightly less efficient
+so has been left out for now. One small advantage of dynamic numbering might
+be fewer merge conflicts in uclass-id.h.
diff --git a/roms/u-boot/doc/develop/driver-model/ethernet.rst b/roms/u-boot/doc/develop/driver-model/ethernet.rst
new file mode 100644
index 000000000..cdbccca34
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/ethernet.rst
@@ -0,0 +1,321 @@
+Ethernet Driver Guide
+=======================
+
+The networking stack in Das U-Boot is designed for multiple network devices
+to be easily added and controlled at runtime. This guide is meant for people
+who wish to review the net driver stack with an eye towards implementing your
+own ethernet device driver. Here we will describe a new pseudo 'APE' driver.
+
+Most existing drivers do already - and new network driver MUST - use the
+U-Boot core driver model. Generic information about this can be found in
+doc/driver-model/design.rst, this document will thus focus on the network
+specific code parts.
+Some drivers are still using the old Ethernet interface, differences between
+the two and hints about porting will be handled at the end.
+
+Driver framework
+------------------
+
+A network driver following the driver model must declare itself using
+the UCLASS_ETH .id field in the U-Boot driver struct:
+
+.. code-block:: c
+
+ U_BOOT_DRIVER(eth_ape) = {
+ .name = "eth_ape",
+ .id = UCLASS_ETH,
+ .of_match = eth_ape_ids,
+ .of_to_plat = eth_ape_of_to_plat,
+ .probe = eth_ape_probe,
+ .ops = &eth_ape_ops,
+ .priv_auto = sizeof(struct eth_ape_priv),
+ .plat_auto = sizeof(struct eth_ape_pdata),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+ };
+
+struct eth_ape_priv contains runtime per-instance data, like buffers, pointers
+to current descriptors, current speed settings, pointers to PHY related data
+(like struct mii_dev) and so on. Declaring its size in .priv_auto
+will let the driver framework allocate it at the right time.
+It can be retrieved using a dev_get_priv(dev) call.
+
+struct eth_ape_pdata contains static platform data, like the MMIO base address,
+a hardware variant, the MAC address. ``struct eth_pdata eth_pdata``
+as the first member of this struct helps to avoid duplicated code.
+If you don't need any more platform data beside the standard member,
+just use sizeof(struct eth_pdata) for the plat_auto.
+
+PCI devices add a line pointing to supported vendor/device ID pairs:
+
+.. code-block:: c
+
+ static struct pci_device_id supported[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_APE, 0x4223) },
+ {}
+ };
+
+ U_BOOT_PCI_DEVICE(eth_ape, supported);
+
+It is also possible to declare support for a whole class of PCI devices::
+
+ { PCI_DEVICE_CLASS(PCI_CLASS_SYSTEM_SDHCI << 8, 0xffff00) },
+
+Device probing and instantiation will be handled by the driver model framework,
+so follow the guidelines there. The probe() function would initialise the
+platform specific parts of the hardware, like clocks, resets, GPIOs, the MDIO
+bus. Also it would take care of any special PHY setup (power rails, enable
+bits for internal PHYs, etc.).
+
+Driver methods
+----------------
+
+The real work will be done in the driver method functions the driver provides
+by defining the members of struct eth_ops:
+
+.. code-block:: c
+
+ struct eth_ops {
+ int (*start)(struct udevice *dev);
+ int (*send)(struct udevice *dev, void *packet, int length);
+ int (*recv)(struct udevice *dev, int flags, uchar **packetp);
+ int (*free_pkt)(struct udevice *dev, uchar *packet, int length);
+ void (*stop)(struct udevice *dev);
+ int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
+ int (*write_hwaddr)(struct udevice *dev);
+ int (*read_rom_hwaddr)(struct udevice *dev);
+ };
+
+An up-to-date version of this struct together with more information can be
+found in include/net.h.
+
+Only start, stop, send and recv are required, the rest are optional and are
+handled by generic code or ignored if not provided.
+
+The **start** function initialises the hardware and gets it ready for send/recv
+operations. You often do things here such as resetting the MAC
+and/or PHY, and waiting for the link to autonegotiate. You should also take
+the opportunity to program the device's MAC address with the enetaddr member
+of the generic struct eth_pdata (which would be the first member of your
+own plat struct). This allows the rest of U-Boot to dynamically change
+the MAC address and have the new settings be respected.
+
+The **send** function does what you think -- transmit the specified packet
+whose size is specified by length (in bytes). The packet buffer can (and
+will!) be reused for subsequent calls to send(), so it must be no longer
+used when the send() function returns. The easiest way to achieve this is
+to wait until the transmission is complete. Alternatively, if supported by
+the hardware, just waiting for the buffer to be consumed (by some DMA engine)
+might be an option as well.
+Another way of consuming the buffer could be to copy the data to be send,
+then just queue the copied packet (for instance handing it over to a DMA
+engine), and return immediately afterwards.
+In any case you should leave the state such that the send function can be
+called multiple times in a row.
+
+The **recv** function polls for availability of a new packet. If none is
+available, it must return with -EAGAIN.
+If a packet has been received, make sure it is accessible to the CPU
+(invalidate caches if needed), then write its address to the packetp pointer,
+and return the length. If there is an error (receive error, too short or too
+long packet), return 0 if you require the packet to be cleaned up normally,
+or a negative error code otherwise (cleanup not necessary or already done).
+The U-Boot network stack will then process the packet.
+
+If **free_pkt** is defined, U-Boot will call it after a received packet has
+been processed, so the packet buffer can be freed or recycled. Typically you
+would hand it back to the hardware to acquire another packet. free_pkt() will
+be called after recv(), for the same packet, so you don't necessarily need
+to infer the buffer to free from the ``packet`` pointer, but can rely on that
+being the last packet that recv() handled.
+The common code sets up packet buffers for you already in the .bss
+(net_rx_packets), so there should be no need to allocate your own. This doesn't
+mean you must use the net_rx_packets array however; you're free to use any
+buffer you wish.
+
+The **stop** function should turn off / disable the hardware and place it back
+in its reset state. It can be called at any time (before any call to the
+related start() function), so make sure it can handle this sort of thing.
+
+The (optional) **write_hwaddr** function should program the MAC address stored
+in pdata->enetaddr into the Ethernet controller.
+
+So the call graph at this stage would look something like:
+
+.. code-block:: c
+
+ (some net operation (ping / tftp / whatever...))
+ eth_init()
+ ops->start()
+ eth_send()
+ ops->send()
+ eth_rx()
+ ops->recv()
+ (process packet)
+ if (ops->free_pkt)
+ ops->free_pkt()
+ eth_halt()
+ ops->stop()
+
+
+CONFIG_PHYLIB / CONFIG_CMD_MII
+--------------------------------
+
+If your device supports banging arbitrary values on the MII bus (pretty much
+every device does), you should add support for the mii command. Doing so is
+fairly trivial and makes debugging mii issues a lot easier at runtime.
+
+In your driver's ``probe()`` function, add a call to mdio_alloc() and
+mdio_register() like so:
+
+.. code-block:: c
+
+ bus = mdio_alloc();
+ if (!bus) {
+ ...
+ return -ENOMEM;
+ }
+
+ bus->read = ape_mii_read;
+ bus->write = ape_mii_write;
+ mdio_register(bus);
+
+And then define the mii_read and mii_write functions if you haven't already.
+Their syntax is straightforward::
+
+ int mii_read(struct mii_dev *bus, int addr, int devad, int reg);
+ int mii_write(struct mii_dev *bus, int addr, int devad, int reg,
+ u16 val);
+
+The read function should read the register 'reg' from the phy at address 'addr'
+and return the result to its caller. The implementation for the write function
+should logically follow.
+
+................................................................
+
+Legacy network drivers
+------------------------
+
+!!! WARNING !!!
+
+This section below describes the old way of doing things. No new Ethernet
+drivers should be implemented this way. All new drivers should be written
+against the U-Boot core driver model, as described above.
+
+The actual callback functions are fairly similar, the differences are:
+
+- ``start()`` is called ``init()``
+- ``stop()`` is called ``halt()``
+- The ``recv()`` function must loop until all packets have been received, for
+ each packet it must call the net_process_received_packet() function,
+ handing it over the pointer and the length. Afterwards it should free
+ the packet, before checking for new data.
+
+For porting an old driver to the new driver model, split the existing recv()
+function into the actual new recv() function, just fetching **one** packet,
+remove the call to net_process_received_packet(), then move the packet
+cleanup into the ``free_pkt()`` function.
+
+Registering the driver and probing a device is handled very differently,
+follow the recommendations in the driver model design documentation for
+instructions on how to port this over. For the records, the old way of
+initialising a network driver is as follows:
+
+Old network driver registration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When U-Boot initializes, it will call the common function eth_initialize().
+This will in turn call the board-specific board_eth_init() (or if that fails,
+the cpu-specific cpu_eth_init()). These board-specific functions can do random
+system handling, but ultimately they will call the driver-specific register
+function which in turn takes care of initializing that particular instance.
+
+Keep in mind that you should code the driver to avoid storing state in global
+data as someone might want to hook up two of the same devices to one board.
+Any such information that is specific to an interface should be stored in a
+private, driver-defined data structure and pointed to by eth->priv (see below).
+
+So the call graph at this stage would look something like:
+
+.. code-block:: c
+
+ board_init()
+ eth_initialize()
+ board_eth_init() / cpu_eth_init()
+ driver_register()
+ initialize eth_device
+ eth_register()
+
+At this point in time, the only thing you need to worry about is the driver's
+register function. The pseudo code would look something like:
+
+.. code-block:: c
+
+ int ape_register(struct bd_info *bis, int iobase)
+ {
+ struct ape_priv *priv;
+ struct eth_device *dev;
+ struct mii_dev *bus;
+
+ priv = malloc(sizeof(*priv));
+ if (priv == NULL)
+ return -ENOMEM;
+
+ dev = malloc(sizeof(*dev));
+ if (dev == NULL) {
+ free(priv);
+ return -ENOMEM;
+ }
+
+ /* setup whatever private state you need */
+
+ memset(dev, 0, sizeof(*dev));
+ sprintf(dev->name, "APE");
+
+ /*
+ * if your device has dedicated hardware storage for the
+ * MAC, read it and initialize dev->enetaddr with it
+ */
+ ape_mac_read(dev->enetaddr);
+
+ dev->iobase = iobase;
+ dev->priv = priv;
+ dev->init = ape_init;
+ dev->halt = ape_halt;
+ dev->send = ape_send;
+ dev->recv = ape_recv;
+ dev->write_hwaddr = ape_write_hwaddr;
+
+ eth_register(dev);
+
+ #ifdef CONFIG_PHYLIB
+ bus = mdio_alloc();
+ if (!bus) {
+ free(priv);
+ free(dev);
+ return -ENOMEM;
+ }
+
+ bus->read = ape_mii_read;
+ bus->write = ape_mii_write;
+ mdio_register(bus);
+ #endif
+
+ return 1;
+ }
+
+The exact arguments needed to initialize your device are up to you. If you
+need to pass more/less arguments, that's fine. You should also add the
+prototype for your new register function to include/netdev.h.
+
+The return value for this function should be as follows:
+< 0 - failure (hardware failure, not probe failure)
+>=0 - number of interfaces detected
+
+You might notice that many drivers seem to use xxx_initialize() rather than
+xxx_register(). This is the old naming convention and should be avoided as it
+causes confusion with the driver-specific init function.
+
+Other than locating the MAC address in dedicated hardware storage, you should
+not touch the hardware in anyway. That step is handled in the driver-specific
+init function. Remember that we are only registering the device here, we are
+not checking its state or doing random probing.
diff --git a/roms/u-boot/doc/develop/driver-model/fdt-fixup.rst b/roms/u-boot/doc/develop/driver-model/fdt-fixup.rst
new file mode 100644
index 000000000..974c09031
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/fdt-fixup.rst
@@ -0,0 +1,132 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. 2017-01-06, Mario Six <mario.six@gdsys.cc>
+
+Pre-relocation device tree manipulation
+=======================================
+
+Purpose
+-------
+
+In certain markets, it is beneficial for manufacturers of embedded devices to
+offer certain ranges of products, where the functionality of the devices within
+one series either don't differ greatly from another, or can be thought of as
+"extensions" of each other, where one device only differs from another in the
+addition of a small number of features (e.g. an additional output connector).
+
+To realize this in hardware, one method is to have a motherboard, and several
+possible daughter boards that can be attached to this mother board. Different
+daughter boards then either offer the slightly different functionality, or the
+addition of the daughter board to the device realizes the "extension" of
+functionality to the device described previously.
+
+For the software, we obviously want to reuse components for all these
+variations of the device. This means that the software somehow needs to cope
+with the situation that certain ICs may or may not be present on any given
+system, depending on which daughter boards are connected to the motherboard.
+
+In the Linux kernel, one possible solution to this problem is to employ the
+device tree overlay mechanism: There exists one "base" device tree, which
+features only the components guaranteed to exist in all varieties of the
+device. At the start of the kernel, the presence and type of the daughter
+boards is then detected, and the corresponding device tree overlays are applied
+to support the components on the daughter boards.
+
+Note that the components present on every variety of the board must, of course,
+provide a way to find out if and which daughter boards are installed for this
+mechanism to work.
+
+In the U-Boot boot loader, support for device tree overlays has recently been
+integrated, and is used on some boards to alter the device tree that is later
+passed to Linux. But since U-Boot's driver model, which is device tree-based as
+well, is being used in more and more drivers, the same problem of altering the
+device tree starts cropping up in U-Boot itself as well.
+
+An additional problem with the device tree in U-Boot is that it is read-only,
+and the current mechanisms don't allow easy manipulation of the device tree
+after the driver model has been initialized. While migrating to a live device
+tree (at least after the relocation) would greatly simplify the solution of
+this problem, it is a non-negligible task to implement it, an a interim
+solution is needed to address the problem at least in the medium-term.
+
+Hence, we propose a solution to this problem by offering a board-specific
+call-back function, which is passed a writeable pointer to the device tree.
+This function is called before the device tree is relocated, and specifically
+before the main U-Boot's driver model is instantiated, hence the main U-Boot
+"sees" all modifications to the device tree made in this function. Furthermore,
+we have the pre-relocation driver model at our disposal at this stage, which
+means that we can query the hardware for the existence and variety of the
+components easily.
+
+Implementation
+--------------
+
+To take advantage of the pre-relocation device tree manipulation mechanism,
+boards have to implement the function board_fix_fdt, which has the following
+signature:
+
+.. code-block:: c
+
+ int board_fix_fdt (void *rw_fdt_blob)
+
+The passed-in void pointer is a writeable pointer to the device tree, which can
+be used to manipulate the device tree using e.g. functions from
+include/fdt_support.h. The return value should either be 0 in case of
+successful execution of the device tree manipulation or something else for a
+failure. Note that returning a non-null value from the function will
+unrecoverably halt the boot process, as with any function from init_sequence_f
+(in common/board_f.c).
+
+Furthermore, the Kconfig option OF_BOARD_FIXUP has to be set for the function
+to be called::
+
+ Device Tree Control
+ -> [*] Board-specific manipulation of Device Tree
+
++----------------------------------------------------------+
+| WARNING: The actual manipulation of the device tree has |
+| to be the _last_ set of operations in board_fix_fdt! |
+| Since the pre-relocation driver model does not adapt to |
+| changes made to the device tree either, its references |
+| into the device tree will be invalid after manipulating |
+| it, and unpredictable behavior might occur when |
+| functions that rely on them are executed! |
++----------------------------------------------------------+
+
+Hence, the recommended layout of the board_fixup_fdt call-back function is the
+following:
+
+.. code-block:: c
+
+ int board_fix_fdt(void *rw_fdt_blob)
+ {
+ /*
+ * Collect information about device's hardware and store
+ * them in e.g. local variables
+ */
+
+ /* Do device tree manipulation using the values previously collected */
+
+ /* Return 0 on successful manipulation and non-zero otherwise */
+ }
+
+If this convention is kept, both an "additive" approach, meaning that nodes for
+detected components are added to the device tree, as well as a "subtractive"
+approach, meaning that nodes for absent components are removed from the tree,
+as well as a combination of both approaches should work.
+
+Example
+-------
+
+The controlcenterdc board (board/gdsys/a38x/controlcenterdc.c) features a
+board_fix_fdt function, in which six GPIO expanders (which might be present or
+not, since they are on daughter boards) on a I2C bus are queried for, and
+subsequently deactivated in the device tree if they are not present.
+
+Note that the dm_i2c_simple_probe function does not use the device tree, hence
+it is safe to call it after the tree has already been manipulated.
+
+Work to be done
+---------------
+
+* The application of device tree overlay should be possible in board_fixup_fdt,
+ but has not been tested at this stage.
diff --git a/roms/u-boot/doc/develop/driver-model/fs_firmware_loader.rst b/roms/u-boot/doc/develop/driver-model/fs_firmware_loader.rst
new file mode 100644
index 000000000..a44708cb4
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/fs_firmware_loader.rst
@@ -0,0 +1,154 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2018-2019 Intel Corporation <www.intel.com>
+
+File System Firmware Loader
+===========================
+
+This is file system firmware loader for U-Boot framework, which has very close
+to some Linux Firmware API. For the details of Linux Firmware API, you can refer
+to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html.
+
+File system firmware loader can be used to load whatever(firmware, image,
+and binary) from the storage device in file system format into target location
+such as memory, then consumer driver such as FPGA driver can program FPGA image
+from the target location into FPGA.
+
+To enable firmware loader, CONFIG_FS_LOADER need to be set at
+<board_name>_defconfig such as "CONFIG_FS_LOADER=y".
+
+Firmware Loader API core features
+---------------------------------
+
+Firmware storage device described in device tree source
+-------------------------------------------------------
+For passing data like storage device phandle and partition where the
+firmware loading from to the firmware loader driver, those data could be
+defined in fs-loader node as shown in below:
+
+Example for block device::
+
+ fs_loader0: fs-loader {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = <&mmc 1>;
+ };
+
+<&mmc 1> means block storage device pointer and its partition.
+
+Above example is a description for block storage, but for UBI storage
+device, it can be described in FDT as shown in below:
+
+Example for ubi::
+
+ fs_loader1: fs-loader {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ mtdpart = "UBI",
+ ubivol = "ubi0";
+ };
+
+Then, firmware-loader property can be added with any device node, which
+driver would use the firmware loader for loading.
+
+The value of the firmware-loader property should be set with phandle
+of the fs-loader node. For example::
+
+ firmware-loader = <&fs_loader0>;
+
+If there are majority of devices using the same fs-loader node, then
+firmware-loader property can be added under /chosen node instead of
+adding to each of device node.
+
+For example::
+
+ /{
+ chosen {
+ firmware-loader = <&fs_loader0>;
+ };
+ };
+
+In each respective driver of devices using firmware loader, the firmware
+loaded instance should be created by DT phandle.
+
+For example of getting DT phandle from /chosen and creating instance:
+
+.. code-block:: c
+
+ chosen_node = ofnode_path("/chosen");
+ if (!ofnode_valid(chosen_node)) {
+ debug("/chosen node was not found.\n");
+ return -ENOENT;
+ }
+
+ phandle_p = ofnode_get_property(chosen_node, "firmware-loader", &size);
+ if (!phandle_p) {
+ debug("firmware-loader property was not found.\n");
+ return -ENOENT;
+ }
+
+ phandle = fdt32_to_cpu(*phandle_p);
+ ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
+ phandle, &dev);
+ if (ret)
+ return ret;
+
+Firmware loader driver is also designed to support U-boot environment
+variables, so all these data from FDT can be overwritten
+through the U-boot environment variable during run time.
+
+For examples:
+
+storage_interface:
+ Storage interface, it can be "mmc", "usb", "sata" or "ubi".
+fw_dev_part:
+ Block device number and its partition, it can be "0:1".
+fw_ubi_mtdpart:
+ UBI device mtd partition, it can be "UBI".
+fw_ubi_volume:
+ UBI volume, it can be "ubi0".
+
+When above environment variables are set, environment values would be
+used instead of data from FDT.
+The benefit of this design allows user to change storage attribute data
+at run time through U-boot console and saving the setting as default
+environment values in the storage for the next power cycle, so no
+compilation is required for both driver and FDT.
+
+File system firmware Loader API
+-------------------------------
+
+.. code-block:: c
+
+ int request_firmware_into_buf(struct udevice *dev,
+ const char *name,
+ void *buf, size_t size, u32 offset)
+
+Load firmware into a previously allocated buffer
+
+Parameters:
+
+* struct udevice \*dev: An instance of a driver
+* const char \*name: name of firmware file
+* void \*buf: address of buffer to load firmware into
+* size_t size: size of buffer
+* u32 offset: offset of a file for start reading into buffer
+
+Returns:
+ size of total read
+ -ve when error
+
+Description:
+ The firmware is loaded directly into the buffer pointed to by buf
+
+Example of calling request_firmware_into_buf API after creating firmware loader
+instance:
+
+.. code-block:: c
+
+ ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
+ phandle, &dev);
+ if (ret)
+ return ret;
+
+ request_firmware_into_buf(dev, filename, buffer_location, buffer_size,
+ offset_ofreading);
diff --git a/roms/u-boot/doc/develop/driver-model/i2c-howto.rst b/roms/u-boot/doc/develop/driver-model/i2c-howto.rst
new file mode 100644
index 000000000..27e7440cd
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/i2c-howto.rst
@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+How to port an I2C driver to driver model
+=========================================
+
+Over half of the I2C drivers have been converted as at November 2016. These
+ones remain:
+
+ * adi_i2c
+ * davinci_i2c
+ * fti2c010
+ * ihs_i2c
+ * kona_i2c
+ * lpc32xx_i2c
+ * pca9564_i2c
+ * ppc4xx_i2c
+ * rcar_i2c
+ * sh_i2c
+ * soft_i2c
+ * zynq_i2c
+
+The deadline for this work is the end of June 2017. If no one steps
+forward to convert these, at some point there may come a patch to remove them!
+
+Here is a suggested approach for converting your I2C driver over to driver
+model. Please feel free to update this file with your ideas and suggestions.
+
+- #ifdef out all your own I2C driver code (#if !CONFIG_IS_ENABLED(DM_I2C))
+- Define CONFIG_DM_I2C for your board, vendor or architecture
+- If the board does not already use driver model, you need CONFIG_DM also
+- Your board should then build, but will not work fully since there will be
+ no I2C driver
+- Add the U_BOOT_DRIVER piece at the end (e.g. copy tegra_i2c.c for example)
+- Add a private struct for the driver data - avoid using static variables
+- Implement each of the driver methods, perhaps by calling your old methods
+- You may need to adjust the function parameters so that the old and new
+ implementations can share most of the existing code
+- If you convert all existing users of the driver, remove the pre-driver-model
+ code
+
+In terms of patches a conversion series typically has these patches:
+- clean up / prepare the driver for conversion
+- add driver model code
+- convert at least one existing board to use driver model serial
+- (if no boards remain that don't use driver model) remove the old code
+
+This may be a good time to move your board to use device tree also. Mostly
+this involves these steps:
+
+- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE
+- add your device tree files to arch/<arch>/dts
+- update the Makefile there
+- Add stdout-path to your /chosen device tree node if it is not already there
+- build and get u-boot-dtb.bin so you can test it
+- Your drivers can now use device tree
+- For device tree in SPL, define CONFIG_SPL_OF_CONTROL
diff --git a/roms/u-boot/doc/develop/driver-model/index.rst b/roms/u-boot/doc/develop/driver-model/index.rst
new file mode 100644
index 000000000..7366ef818
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/index.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Driver Model
+============
+
+The following holds information on the U-Boot device driver framework:
+driver-model, including the design details of itself and several driver
+subsystems
+
+.. toctree::
+ :maxdepth: 2
+
+ bind
+ debugging
+ design
+ ethernet
+ fdt-fixup
+ fs_firmware_loader
+ i2c-howto
+ livetree
+ migration
+ nvme
+ of-plat
+ pci-info
+ pmic-framework
+ remoteproc-framework
+ serial-howto
+ soc-framework
+ spi-howto
+ usb-info
+ virtio
diff --git a/roms/u-boot/doc/develop/driver-model/livetree.rst b/roms/u-boot/doc/develop/driver-model/livetree.rst
new file mode 100644
index 000000000..9f654f3b8
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/livetree.rst
@@ -0,0 +1,286 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Live Device Tree
+================
+
+
+Introduction
+------------
+
+Traditionally U-Boot has used a 'flat' device tree. This means that it
+reads directly from the device tree binary structure. It is called a flat
+device tree because nodes are listed one after the other, with the
+hierarchy detected by tags in the format.
+
+This document describes U-Boot's support for a 'live' device tree, meaning
+that the tree is loaded into a hierarchical data structure within U-Boot.
+
+
+Motivation
+----------
+
+The flat device tree has several advantages:
+
+- it is the format produced by the device tree compiler, so no translation
+ is needed
+
+- it is fairly compact (e.g. there is no need for pointers)
+
+- it is accessed by the libfdt library, which is well tested and stable
+
+
+However the flat device tree does have some limitations. Adding new
+properties can involve copying large amounts of data around to make room.
+The overall tree has a fixed maximum size so sometimes the tree must be
+rebuilt in a new location to create more space. Even if not adding new
+properties or nodes, scanning the tree can be slow. For example, finding
+the parent of a node is a slow process. Reading from nodes involves a
+small amount parsing which takes a little time.
+
+Driver model scans the entire device tree sequentially on start-up which
+avoids the worst of the flat tree's limitations. But if the tree is to be
+modified at run-time, a live tree is much faster. Even if no modification
+is necessary, parsing the tree once and using a live tree from then on
+seems to save a little time.
+
+
+Implementation
+--------------
+
+In U-Boot a live device tree ('livetree') is currently supported only
+after relocation. Therefore we need a mechanism to specify a device
+tree node regardless of whether it is in the flat tree or livetree.
+
+The 'ofnode' type provides this. An ofnode can point to either a flat tree
+node (when the live tree node is not yet set up) or a livetree node. The
+caller of an ofnode function does not need to worry about these details.
+
+The main users of the information in a device tree are drivers. These have
+a 'struct udevice \*' which is attached to a device tree node. Therefore it
+makes sense to be able to read device tree properties using the
+'struct udevice \*', rather than having to obtain the ofnode first.
+
+The 'dev_read\_...()' interface provides this. It allows properties to be
+easily read from the device tree using only a device pointer. Under the
+hood it uses ofnode so it works with both flat and live device trees.
+
+
+Enabling livetree
+-----------------
+
+CONFIG_OF_LIVE enables livetree. When this option is enabled, the flat
+tree will be used in SPL and before relocation in U-Boot proper. Just
+before relocation a livetree is built, and this is used for U-Boot proper
+after relocation.
+
+Most checks for livetree use CONFIG_IS_ENABLED(OF_LIVE). This means that
+for SPL, the CONFIG_SPL_OF_LIVE option is checked. At present this does
+not exist, since SPL does not support livetree.
+
+
+Porting drivers
+---------------
+
+Many existing drivers use the fdtdec interface to read device tree
+properties. This only works with a flat device tree. The drivers should be
+converted to use the dev_read_() interface.
+
+For example, the old code may be like this:
+
+.. code-block:: c
+
+ struct udevice *bus;
+ const void *blob = gd->fdt_blob;
+ int node = dev_of_offset(bus);
+
+ i2c_bus->regs = (struct i2c_ctlr *)devfdt_get_addr(dev);
+ plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency", 500000);
+
+The new code is:
+
+.. code-block:: c
+
+ struct udevice *bus;
+
+ i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
+ plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 500000);
+
+The dev_read\_...() interface is more convenient and works with both the
+flat and live device trees. See include/dm/read.h for a list of functions.
+
+Where properties must be read from sub-nodes or other nodes, you must fall
+back to using ofnode. For example, for old code like this:
+
+.. code-block:: c
+
+ const void *blob = gd->fdt_blob;
+ int subnode;
+
+ fdt_for_each_subnode(subnode, blob, dev_of_offset(dev)) {
+ freq = fdtdec_get_int(blob, node, "spi-max-frequency", 500000);
+ ...
+ }
+
+you should use:
+
+.. code-block:: c
+
+ ofnode subnode;
+
+ ofnode_for_each_subnode(subnode, dev_ofnode(dev)) {
+ freq = ofnode_read_u32(node, "spi-max-frequency", 500000);
+ ...
+ }
+
+
+Useful ofnode functions
+-----------------------
+
+The internal data structures of the livetree are defined in include/dm/of.h :
+
+ :struct device_node: holds information about a device tree node
+ :struct property: holds information about a property within a node
+
+Nodes have pointers to their first property, their parent, their first child
+and their sibling. This allows nodes to be linked together in a hierarchical
+tree.
+
+Properties have pointers to the next property. This allows all properties of
+a node to be linked together in a chain.
+
+It should not be necessary to use these data structures in normal code. In
+particular, you should refrain from using functions which access the livetree
+directly, such as of_read_u32(). Use ofnode functions instead, to allow your
+code to work with a flat tree also.
+
+Some conversion functions are used internally. Generally these are not needed
+for driver code. Note that they will not work if called in the wrong context.
+For example it is invalid to call ofnode_to_no() when a flat tree is being
+used. Similarly it is not possible to call ofnode_to_offset() on a livetree
+node.
+
+ofnode_to_np():
+ converts ofnode to struct device_node *
+ofnode_to_offset():
+ converts ofnode to offset
+
+no_to_ofnode():
+ converts node pointer to ofnode
+offset_to_ofnode():
+ converts offset to ofnode
+
+
+Other useful functions:
+
+of_live_active():
+ returns true if livetree is in use, false if flat tree
+ofnode_valid():
+ return true if a given node is valid
+ofnode_is_np():
+ returns true if a given node is a livetree node
+ofnode_equal():
+ compares two ofnodes
+ofnode_null():
+ returns a null ofnode (for which ofnode_valid() returns false)
+
+
+Phandles
+--------
+
+There is full phandle support for live tree. All functions make use of
+struct ofnode_phandle_args, which has an ofnode within it. This supports both
+livetree and flat tree transparently. See for example
+ofnode_parse_phandle_with_args().
+
+
+Reading addresses
+-----------------
+
+You should use dev_read_addr() and friends to read addresses from device-tree
+nodes.
+
+
+fdtdec
+------
+
+The existing fdtdec interface will eventually be retired. Please try to avoid
+using it in new code.
+
+
+Modifying the livetree
+----------------------
+
+This is not currently supported. Once implemented it should provide a much
+more efficient implementation for modification of the device tree than using
+the flat tree.
+
+
+Internal implementation
+-----------------------
+
+The dev_read\_...() functions have two implementations. When
+CONFIG_DM_DEV_READ_INLINE is enabled, these functions simply call the ofnode
+functions directly. This is useful when livetree is not enabled. The ofnode
+functions call ofnode_is_np(node) which will always return false if livetree
+is disabled, just falling back to flat tree code.
+
+This optimisation means that without livetree enabled, the dev_read\_...() and
+ofnode interfaces do not noticeably add to code size.
+
+The CONFIG_DM_DEV_READ_INLINE option defaults to enabled when livetree is
+disabled.
+
+Most livetree code comes directly from Linux and is modified as little as
+possible. This is deliberate since this code is fairly stable and does what
+we want. Some features (such as get/put) are not supported. Internal macros
+take care of removing these features silently.
+
+Within the of_access.c file there are pointers to the alias node, the chosen
+node and the stdout-path alias.
+
+
+Errors
+------
+
+With a flat device tree, libfdt errors are returned (e.g. -FDT_ERR_NOTFOUND).
+For livetree normal 'errno' errors are returned (e.g. -ENOTFOUND). At present
+the ofnode and dev_read\_...() functions return either one or other type of
+error. This is clearly not desirable. Once tests are added for all the
+functions this can be tidied up.
+
+
+Adding new access functions
+---------------------------
+
+Adding a new function for device-tree access involves the following steps:
+
+ - Add two dev_read() functions:
+ - inline version in the read.h header file, which calls an ofnode function
+ - standard version in the read.c file (or perhaps another file), which
+ also calls an ofnode function
+
+ The implementations of these functions can be the same. The purpose
+ of the inline version is purely to reduce code size impact.
+
+ - Add an ofnode function. This should call ofnode_is_np() to work out
+ whether a livetree or flat tree is used. For the livetree it should
+ call an of\_...() function. For the flat tree it should call an
+ fdt\_...() function. The livetree version will be optimised out at
+ compile time if livetree is not enabled.
+
+ - Add an of\_...() function for the livetree implementation. If a similar
+ function is available in Linux, the implementation should be taken
+ from there and modified as little as possible (generally not at all).
+
+
+Future work
+-----------
+
+Live tree support was introduced in U-Boot 2017.07. There is still quite a bit
+of work to do to flesh this out:
+
+- tests for all access functions
+- support for livetree modification
+- addition of more access functions as needed
+- support for livetree in SPL and before relocation (if desired)
diff --git a/roms/u-boot/doc/develop/driver-model/migration.rst b/roms/u-boot/doc/develop/driver-model/migration.rst
new file mode 100644
index 000000000..8d0bb7635
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/migration.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Migration Schedule
+==================
+
+U-Boot has been migrating to a new driver model since its introduction in
+2014. This file describes the schedule for deprecation of pre-driver-model
+features.
+
+CONFIG_DM
+---------
+
+* Status: In progress
+* Deadline: 2020.01
+
+Starting with the 2010.01 release CONFIG_DM will be enabled for all boards.
+This does not concern CONFIG_DM_SPL and CONFIG_DM_TPL. The conversion date for
+these configuration items still needs to be defined.
+
+CONFIG_DM_MMC
+-------------
+
+* Status: In progress
+* Deadline: 2019.04
+
+The subsystem itself has been converted and maintainers should submit patches
+switching over to using CONFIG_DM_MMC and other base driver model options in
+time for inclusion in the 2019.04 rerelease.
+
+CONFIG_DM_USB
+-------------
+
+* Status: In progress
+* Deadline: 2019.07
+
+The subsystem itself has been converted along with many of the host controller
+and maintainers should submit patches switching over to using CONFIG_DM_USB and
+other base driver model options in time for inclusion in the 2019.07 rerelease.
+
+CONFIG_SATA
+-----------
+
+* Status: In progress
+* Deadline: 2019.07
+
+The subsystem itself has been converted along with many of the host controller
+and maintainers should submit patches switching over to using CONFIG_AHCI and
+other base driver model options in time for inclusion in the 2019.07 rerelease.
+
+CONFIG_BLK
+----------
+
+* Status: In progress
+* Deadline: 2019.07
+
+In concert with maintainers migrating their block device usage to the
+appropriate DM driver, CONFIG_BLK needs to be set as well. The final deadline
+here coincides with the final deadline for migration of the various block
+subsystems. At this point we will be able to audit and correct the logic in
+Kconfig around using CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE and make
+use of CONFIG_BLK / CONFIG_SPL_BLK as needed.
+
+CONFIG_DM_SPI / CONFIG_DM_SPI_FLASH
+-----------------------------------
+
+Board Maintainers should submit the patches for enabling DM_SPI and DM_SPI_FLASH
+to move the migration with in the deadline.
+
+Partially converted::
+
+ drivers/spi/fsl_espi.c
+ drivers/spi/mxc_spi.c
+ drivers/spi/sh_qspi.c
+
+* Status: In progress
+* Deadline: 2019.07
+
+CONFIG_DM_PCI
+-------------
+Deadline: 2019.07
+
+The PCI subsystem has supported driver model since mid 2015. Maintainers should
+submit patches switching over to using CONFIG_DM_PCI and other base driver
+model options in time for inclusion in the 2019.07 release.
+
+
+CONFIG_DM_VIDEO
+---------------
+Deadline: 2019.07
+
+The video subsystem has supported driver model since early 2016. Maintainers
+should submit patches switching over to using CONFIG_DM_VIDEO and other base
+driver model options in time for inclusion in the 2019.07 release.
+
+CONFIG_DM_ETH
+-------------
+Deadline: 2020.07
+
+The network subsystem has supported the driver model since early 2015.
+Maintainers should submit patches switching over to using CONFIG_DM_ETH and
+other base driver model options in time for inclusion in the 2020.07 release.
+
+CONFIG_DM_I2C
+-------------
+Deadline: 2021.10
+
+The I2C subsystem has supported the driver model since early 2015.
+Maintainers should submit patches switching over to using CONFIG_DM_I2C and
+other base driver model options in time for inclusion in the 2021.10 release.
diff --git a/roms/u-boot/doc/develop/driver-model/nvme.rst b/roms/u-boot/doc/develop/driver-model/nvme.rst
new file mode 100644
index 000000000..736c0a063
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/nvme.rst
@@ -0,0 +1,97 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2017 NXP Semiconductors
+.. Copyright (C) 2017 Bin Meng <bmeng.cn@gmail.com>
+
+NVMe Support
+============
+
+What is NVMe
+------------
+
+NVM Express (NVMe) is a register level interface that allows host software to
+communicate with a non-volatile memory subsystem. This interface is optimized
+for enterprise and client solid state drives, typically attached to the PCI
+express interface. It is a scalable host controller interface designed to
+address the needs of enterprise and client systems that utilize PCI express
+based solid state drives (SSD). The interface provides optimized command
+submission and completion paths. It includes support for parallel operation by
+supporting up to 64K I/O queues with up to 64K commands per I/O queue.
+
+The device is comprised of some number of controllers, where each controller
+is comprised of some number of namespaces, where each namespace is comprised
+of some number of logical blocks. A namespace is a quantity of non-volatile
+memory that is formatted into logical blocks. An NVMe namespace is equivalent
+to a SCSI LUN. Each namespace is operated as an independent "device".
+
+How it works
+------------
+There is an NVMe uclass driver (driver name "nvme"), an NVMe host controller
+driver (driver name "nvme") and an NVMe namespace block driver (driver name
+"nvme-blk"). The host controller driver is supposed to probe the hardware and
+do necessary initialization to put the controller into a ready state at which
+it is able to scan all available namespaces attached to it. Scanning namespace
+is triggered by the NVMe uclass driver and the actual work is done in the NVMe
+namespace block driver.
+
+Status
+------
+It only support basic block read/write functions in the NVMe driver.
+
+Config options
+--------------
+CONFIG_NVME Enable NVMe device support
+CONFIG_CMD_NVME Enable basic NVMe commands
+
+Usage in U-Boot
+---------------
+To use an NVMe hard disk from U-Boot shell, a 'nvme scan' command needs to
+be executed for all NVMe hard disks attached to the NVMe controller to be
+identified.
+
+To list all of the NVMe hard disks, try:
+
+.. code-block:: none
+
+ => nvme info
+ Device 0: Vendor: 0x8086 Rev: 8DV10131 Prod: CVFT535600LS400BGN
+ Type: Hard Disk
+ Capacity: 381554.0 MB = 372.6 GB (781422768 x 512)
+
+and print out detailed information for controller and namespaces via:
+
+.. code-block:: none
+
+ => nvme detail
+
+Raw block read/write to can be done via the 'nvme read/write' commands:
+
+.. code-block:: none
+
+ => nvme read a0000000 0 11000
+
+ => tftp 80000000 /tftpboot/kernel.itb
+ => nvme write 80000000 0 11000
+
+Of course, file system command can be used on the NVMe hard disk as well:
+
+.. code-block:: none
+
+ => fatls nvme 0:1
+ 32376967 kernel.itb
+ 22929408 100m
+
+ 2 file(s), 0 dir(s)
+
+ => fatload nvme 0:1 a0000000 /kernel.itb
+ => bootm a0000000
+
+Testing NVMe with QEMU x86
+--------------------------
+QEMU supports NVMe emulation and we can test NVMe driver with QEMU x86 running
+U-Boot. Please see README.x86 for how to build u-boot.rom image for QEMU x86.
+
+Example command line to call QEMU x86 below with emulated NVMe device:
+
+.. code-block:: bash
+
+ $ ./qemu-system-i386 -drive file=nvme.img,if=none,id=drv0 -device nvme,drive=drv0,serial=QEMUNVME0001 -bios u-boot.rom
diff --git a/roms/u-boot/doc/develop/driver-model/of-plat.rst b/roms/u-boot/doc/develop/driver-model/of-plat.rst
new file mode 100644
index 000000000..74f193247
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/of-plat.rst
@@ -0,0 +1,913 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Compiled-in Device Tree / Platform Data
+=======================================
+
+
+Introduction
+------------
+
+Device tree is the standard configuration method in U-Boot. It is used to
+define what devices are in the system and provide configuration information
+to these devices.
+
+The overhead of adding devicetree access to U-Boot is fairly modest,
+approximately 3KB on Thumb 2 (plus the size of the DT itself). This means
+that in most cases it is best to use devicetree for configuration.
+
+However there are some very constrained environments where U-Boot needs to
+work. These include SPL with severe memory limitations. For example, some
+SoCs require a 16KB SPL image which must include a full MMC stack. In this
+case the overhead of devicetree access may be too great.
+
+It is possible to create platform data manually by defining C structures
+for it, and reference that data in a `U_BOOT_DRVINFO()` declaration. This
+bypasses the use of devicetree completely, effectively creating a parallel
+configuration mechanism. But it is an available option for SPL.
+
+As an alternative, the 'of-platdata' feature is provided. This converts the
+devicetree contents into C code which can be compiled into the SPL binary.
+This saves the 3KB of code overhead and perhaps a few hundred more bytes due
+to more efficient storage of the data.
+
+
+How it works
+------------
+
+The feature is enabled by CONFIG OF_PLATDATA. This is only available in
+SPL/TPL and should be tested with:
+
+.. code-block:: c
+
+ #if CONFIG_IS_ENABLED(OF_PLATDATA)
+
+A tool called 'dtoc' converts a devicetree file either into a set of
+struct declarations, one for each compatible node, and a set of
+`U_BOOT_DRVINFO()` declarations along with the actual platform data for each
+device. As an example, consider this MMC node:
+
+.. code-block:: none
+
+ sdmmc: dwmmc@ff0c0000 {
+ compatible = "rockchip,rk3288-dw-mshc";
+ clock-freq-min-max = <400000 150000000>;
+ clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
+ <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
+ fifo-depth = <0x100>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xff0c0000 0x4000>;
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ disable-wp;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
+ vmmc-supply = <&vcc_sd>;
+ status = "okay";
+ u-boot,dm-pre-reloc;
+ };
+
+
+Some of these properties are dropped by U-Boot under control of the
+CONFIG_OF_SPL_REMOVE_PROPS option. The rest are processed. This will produce
+the following C struct declaration:
+
+.. code-block:: c
+
+ struct dtd_rockchip_rk3288_dw_mshc {
+ fdt32_t bus_width;
+ bool cap_mmc_highspeed;
+ bool cap_sd_highspeed;
+ fdt32_t card_detect_delay;
+ fdt32_t clock_freq_min_max[2];
+ struct phandle_1_arg clocks[4];
+ bool disable_wp;
+ fdt32_t fifo_depth;
+ fdt32_t interrupts[3];
+ fdt32_t num_slots;
+ fdt32_t reg[2];
+ fdt32_t vmmc_supply;
+ };
+
+and the following device declarations:
+
+.. code-block:: c
+
+ /* Node /clock-controller@ff760000 index 0 */
+ ...
+
+ /* Node /dwmmc@ff0c0000 index 2 */
+ static struct dtd_rockchip_rk3288_dw_mshc dtv_dwmmc_at_ff0c0000 = {
+ .fifo_depth = 0x100,
+ .cap_sd_highspeed = true,
+ .interrupts = {0x0, 0x20, 0x4},
+ .clock_freq_min_max = {0x61a80, 0x8f0d180},
+ .vmmc_supply = 0xb,
+ .num_slots = 0x1,
+ .clocks = {{0, 456},
+ {0, 68},
+ {0, 114},
+ {0, 118}},
+ .cap_mmc_highspeed = true,
+ .disable_wp = true,
+ .bus_width = 0x4,
+ .u_boot_dm_pre_reloc = true,
+ .reg = {0xff0c0000, 0x4000},
+ .card_detect_delay = 0xc8,
+ };
+
+ U_BOOT_DRVINFO(dwmmc_at_ff0c0000) = {
+ .name = "rockchip_rk3288_dw_mshc",
+ .plat = &dtv_dwmmc_at_ff0c0000,
+ .plat_size = sizeof(dtv_dwmmc_at_ff0c0000),
+ .parent_idx = -1,
+ };
+
+The device is then instantiated at run-time and the platform data can be
+accessed using:
+
+.. code-block:: c
+
+ struct udevice *dev;
+ struct dtd_rockchip_rk3288_dw_mshc *plat = dev_get_plat(dev);
+
+This avoids the code overhead of converting the devicetree data to
+platform data in the driver. The `of_to_plat()` method should
+therefore do nothing in such a driver.
+
+Note that for the platform data to be matched with a driver, the 'name'
+property of the `U_BOOT_DRVINFO()` declaration has to match a driver declared
+via `U_BOOT_DRIVER()`. This effectively means that a `U_BOOT_DRIVER()` with a
+'name' corresponding to the devicetree 'compatible' string (after converting
+it to a valid name for C) is needed, so a dedicated driver is required for
+each 'compatible' string.
+
+In order to make this a bit more flexible, the `DM_DRIVER_ALIAS()` macro can be
+used to declare an alias for a driver name, typically a 'compatible' string.
+This macro produces no code, but is used by dtoc tool. It must be located in the
+same file as its associated driver, ideally just after it.
+
+The parent_idx is the index of the parent `driver_info` structure within its
+linker list (instantiated by the `U_BOOT_DRVINFO()` macro). This is used to
+support `dev_get_parent()`.
+
+During the build process dtoc parses both `U_BOOT_DRIVER()` and
+`DM_DRIVER_ALIAS()` to build a list of valid driver names and driver aliases.
+If the 'compatible' string used for a device does not not match a valid driver
+name, it will be checked against the list of driver aliases in order to get the
+right driver name to use. If in this step there is no match found a warning is
+issued to avoid run-time failures.
+
+Where a node has multiple compatible strings, dtoc generates a `#define` to
+make them equivalent, e.g.:
+
+.. code-block:: c
+
+ #define dtd_rockchip_rk3299_dw_mshc dtd_rockchip_rk3288_dw_mshc
+
+
+Converting of-platdata to a useful form
+---------------------------------------
+
+Of course it would be possible to use the of-platdata directly in your driver
+whenever configuration information is required. However this means that the
+driver will not be able to support devicetree, since the of-platdata
+structure is not available when devicetree is used. It would make no sense
+to use this structure if devicetree were available, since the structure has
+all the limitations metioned in caveats below.
+
+Therefore it is recommended that the of-platdata structure should be used
+only in the `probe()` method of your driver. It cannot be used in the
+`of_to_plat()` method since this is not called when platform data is
+already present.
+
+
+How to structure your driver
+----------------------------
+
+Drivers should always support devicetree as an option. The of-platdata
+feature is intended as a add-on to existing drivers.
+
+Your driver should convert the plat struct in its `probe()` method. The
+existing devicetree decoding logic should be kept in the
+`of_to_plat()` method and wrapped with `#if`.
+
+For example:
+
+.. code-block:: c
+
+ #include <dt-structs.h>
+
+ struct mmc_plat {
+ #if CONFIG_IS_ENABLED(OF_PLATDATA)
+ /* Put this first since driver model will copy the data here */
+ struct dtd_mmc dtplat;
+ #endif
+ /*
+ * Other fields can go here, to be filled in by decoding from
+ * the devicetree (or the C structures when of-platdata is used).
+ */
+ int fifo_depth;
+ };
+
+ static int mmc_of_to_plat(struct udevice *dev)
+ {
+ #if !CONFIG_IS_ENABLED(OF_PLATDATA)
+ /* Decode the devicetree data */
+ struct mmc_plat *plat = dev_get_plat(dev);
+ const void *blob = gd->fdt_blob;
+ int node = dev_of_offset(dev);
+
+ plat->fifo_depth = fdtdec_get_int(blob, node, "fifo-depth", 0);
+ #endif
+
+ return 0;
+ }
+
+ static int mmc_probe(struct udevice *dev)
+ {
+ struct mmc_plat *plat = dev_get_plat(dev);
+
+ #if CONFIG_IS_ENABLED(OF_PLATDATA)
+ /* Decode the of-platdata from the C structures */
+ struct dtd_mmc *dtplat = &plat->dtplat;
+
+ plat->fifo_depth = dtplat->fifo_depth;
+ #endif
+ /* Set up the device from the plat data */
+ writel(plat->fifo_depth, ...)
+ }
+
+ static const struct udevice_id mmc_ids[] = {
+ { .compatible = "vendor,mmc" },
+ { }
+ };
+
+ U_BOOT_DRIVER(mmc_drv) = {
+ .name = "mmc_drv",
+ .id = UCLASS_MMC,
+ .of_match = mmc_ids,
+ .of_to_plat = mmc_of_to_plat,
+ .probe = mmc_probe,
+ .priv_auto = sizeof(struct mmc_priv),
+ .plat_auto = sizeof(struct mmc_plat),
+ };
+
+ DM_DRIVER_ALIAS(mmc_drv, vendor_mmc) /* matches compatible string */
+
+Note that `struct mmc_plat` is defined in the C file, not in a header. This
+is to avoid needing to include dt-structs.h in a header file. The idea is to
+keep the use of each of-platdata struct to the smallest possible code area.
+There is just one driver C file for each struct, that can convert from the
+of-platdata struct to the standard one used by the driver.
+
+In the case where SPL_OF_PLATDATA is enabled, `plat_auto` is
+still used to allocate space for the platform data. This is different from
+the normal behaviour and is triggered by the use of of-platdata (strictly
+speaking it is a non-zero `plat_size` which triggers this).
+
+The of-platdata struct contents is copied from the C structure data to the
+start of the newly allocated area. In the case where devicetree is used,
+the platform data is allocated, and starts zeroed. In this case the
+`of_to_plat()` method should still set up the platform data (and the
+of-platdata struct will not be present).
+
+SPL must use either of-platdata or devicetree. Drivers cannot use both at
+the same time, but they must support devicetree. Supporting of-platdata is
+optional.
+
+The devicetree becomes inaccessible when CONFIG_SPL_OF_PLATDATA is enabled,
+since the devicetree access code is not compiled in. A corollary is that
+a board can only move to using of-platdata if all the drivers it uses support
+it. There would be little point in having some drivers require the device
+tree data, since then libfdt would still be needed for those drivers and
+there would be no code-size benefit.
+
+
+Build-time instantiation
+------------------------
+
+Even with of-platdata there is a fair amount of code required in driver model.
+It is possible to have U-Boot handle the instantiation of devices at build-time,
+so avoiding the need for the `device_bind()` code and some parts of
+`device_probe()`.
+
+The feature is enabled by CONFIG_OF_PLATDATA_INST.
+
+Here is an example device, as generated by dtoc::
+
+ /*
+ * Node /serial index 6
+ * driver sandbox_serial parent root_driver
+ */
+
+ #include <asm/serial.h>
+ struct sandbox_serial_plat __attribute__ ((section (".priv_data")))
+ _sandbox_serial_plat_serial = {
+ .dtplat = {
+ .sandbox_text_colour = "cyan",
+ },
+ };
+ #include <asm/serial.h>
+ u8 _sandbox_serial_priv_serial[sizeof(struct sandbox_serial_priv)]
+ __attribute__ ((section (".priv_data")));
+ #include <serial.h>
+ u8 _sandbox_serial_uc_priv_serial[sizeof(struct serial_dev_priv)]
+ __attribute__ ((section (".priv_data")));
+
+ DM_DEVICE_INST(serial) = {
+ .driver = DM_DRIVER_REF(sandbox_serial),
+ .name = "sandbox_serial",
+ .plat_ = &_sandbox_serial_plat_serial,
+ .priv_ = _sandbox_serial_priv_serial,
+ .uclass = DM_UCLASS_REF(serial),
+ .uclass_priv_ = _sandbox_serial_uc_priv_serial,
+ .uclass_node = {
+ .prev = &DM_UCLASS_REF(serial)->dev_head,
+ .next = &DM_UCLASS_REF(serial)->dev_head,
+ },
+ .child_head = {
+ .prev = &DM_DEVICE_REF(serial)->child_head,
+ .next = &DM_DEVICE_REF(serial)->child_head,
+ },
+ .sibling_node = {
+ .prev = &DM_DEVICE_REF(i2c_at_0)->sibling_node,
+ .next = &DM_DEVICE_REF(spl_test)->sibling_node,
+ },
+ .seq_ = 0,
+ };
+
+Here is part of the driver, for reference::
+
+ static const struct udevice_id sandbox_serial_ids[] = {
+ { .compatible = "sandbox,serial" },
+ { }
+ };
+
+ U_BOOT_DRIVER(sandbox_serial) = {
+ .name = "sandbox_serial",
+ .id = UCLASS_SERIAL,
+ .of_match = sandbox_serial_ids,
+ .of_to_plat = sandbox_serial_of_to_plat,
+ .plat_auto = sizeof(struct sandbox_serial_plat),
+ .priv_auto = sizeof(struct sandbox_serial_priv),
+ .probe = sandbox_serial_probe,
+ .remove = sandbox_serial_remove,
+ .ops = &sandbox_serial_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+ };
+
+
+The `DM_DEVICE_INST()` macro declares a struct udevice so you can see that the
+members are from that struct. The private data is declared immediately above,
+as `_sandbox_serial_priv_serial`, so there is no need for run-time memory
+allocation. The #include lines are generated as well, since dtoc searches the
+U-Boot source code for the definition of `struct sandbox_serial_priv` and adds
+the relevant header so that the code will compile without errors.
+
+The `plat_` member is set to the dtv data which is declared immediately above
+the device. This is similar to how it would look without of-platdata-inst, but
+node that the `dtplat` member inside is part of the wider
+`_sandbox_serial_plat_serial` struct. This is because the driver declares its
+own platform data, and the part generated by dtoc can only be a portion of it.
+The `dtplat` part is always first in the struct. If the device has no
+`.plat_auto` field, then a simple dtv struct can be used as with this example::
+
+ static struct dtd_sandbox_clk dtv_clk_sbox = {
+ .assigned_clock_rates = 0x141,
+ .assigned_clocks = {0x7, 0x3},
+ };
+
+ #include <asm/clk.h>
+ u8 _sandbox_clk_priv_clk_sbox[sizeof(struct sandbox_clk_priv)]
+ __attribute__ ((section (".priv_data")));
+
+ DM_DEVICE_INST(clk_sbox) = {
+ .driver = DM_DRIVER_REF(sandbox_clk),
+ .name = "sandbox_clk",
+ .plat_ = &dtv_clk_sbox,
+
+Here is part of the driver, for reference::
+
+ static const struct udevice_id sandbox_clk_ids[] = {
+ { .compatible = "sandbox,clk" },
+ { }
+ };
+
+ U_BOOT_DRIVER(sandbox_clk) = {
+ .name = "sandbox_clk",
+ .id = UCLASS_CLK,
+ .of_match = sandbox_clk_ids,
+ .ops = &sandbox_clk_ops,
+ .probe = sandbox_clk_probe,
+ .priv_auto = sizeof(struct sandbox_clk_priv),
+ };
+
+
+You can see that `dtv_clk_sbox` just has the devicetree contents and there is
+no need for the `dtplat` separation, since the driver has no platform data of
+its own, besides that provided by the devicetree (i.e. no `.plat_auto` field).
+
+The doubly linked lists are handled by explicitly declaring the value of each
+node, as you can see with the `.prev` and `.next` values in the example above.
+Since dtoc knows the order of devices it can link them into the appropriate
+lists correctly.
+
+One of the features of driver model is the ability for a uclass to have a
+small amount of private data for each device in that uclass. This is used to
+provide a generic data structure that the uclass can use for all devices, thus
+allowing generic features to be implemented in common code. An example is I2C,
+which stores the bus speed there.
+
+Similarly, parent devices can have data associated with each of their children.
+This is used to provide information common to all children of a particular bus.
+For an I2C bus, this is used to store the I2C address of each child on the bus.
+
+This is all handled automatically by dtoc::
+
+ #include <asm/i2c.h>
+ u8 _sandbox_i2c_priv_i2c_at_0[sizeof(struct sandbox_i2c_priv)]
+ __attribute__ ((section (".priv_data")));
+ #include <i2c.h>
+ u8 _sandbox_i2c_uc_priv_i2c_at_0[sizeof(struct dm_i2c_bus)]
+ __attribute__ ((section (".priv_data")));
+
+ DM_DEVICE_INST(i2c_at_0) = {
+ .driver = DM_DRIVER_REF(sandbox_i2c),
+ .name = "sandbox_i2c",
+ .plat_ = &dtv_i2c_at_0,
+ .priv_ = _sandbox_i2c_priv_i2c_at_0,
+ .uclass = DM_UCLASS_REF(i2c),
+ .uclass_priv_ = _sandbox_i2c_uc_priv_i2c_at_0,
+ ...
+
+Part of driver, for reference::
+
+ static const struct udevice_id sandbox_i2c_ids[] = {
+ { .compatible = "sandbox,i2c" },
+ { }
+ };
+
+ U_BOOT_DRIVER(sandbox_i2c) = {
+ .name = "sandbox_i2c",
+ .id = UCLASS_I2C,
+ .of_match = sandbox_i2c_ids,
+ .ops = &sandbox_i2c_ops,
+ .priv_auto = sizeof(struct sandbox_i2c_priv),
+ };
+
+Part of I2C uclass, for reference::
+
+ UCLASS_DRIVER(i2c) = {
+ .id = UCLASS_I2C,
+ .name = "i2c",
+ .flags = DM_UC_FLAG_SEQ_ALIAS,
+ .post_bind = i2c_post_bind,
+ .pre_probe = i2c_pre_probe,
+ .post_probe = i2c_post_probe,
+ .per_device_auto = sizeof(struct dm_i2c_bus),
+ .per_child_plat_auto = sizeof(struct dm_i2c_chip),
+ .child_post_bind = i2c_child_post_bind,
+ };
+
+Here, `_sandbox_i2c_uc_priv_i2c_at_0` is required by the uclass but is declared
+in the device, as required by driver model. The required header file is included
+so that the code will compile without errors. A similar mechanism is used for
+child devices, but is not shown by this example.
+
+It would not be that useful to avoid binding devices but still need to allocate
+uclasses at runtime. So dtoc generates uclass instances as well::
+
+ struct list_head uclass_head = {
+ .prev = &DM_UCLASS_REF(serial)->sibling_node,
+ .next = &DM_UCLASS_REF(clk)->sibling_node,
+ };
+
+ DM_UCLASS_INST(clk) = {
+ .uc_drv = DM_UCLASS_DRIVER_REF(clk),
+ .sibling_node = {
+ .prev = &uclass_head,
+ .next = &DM_UCLASS_REF(i2c)->sibling_node,
+ },
+ .dev_head = {
+ .prev = &DM_DEVICE_REF(clk_sbox)->uclass_node,
+ .next = &DM_DEVICE_REF(clk_fixed)->uclass_node,
+ },
+ };
+
+At the top is the list head. Driver model uses this on start-up, instead of
+creating its own.
+
+Below that are a set of `DM_UCLASS_INST()` macros, each declaring a
+`struct uclass`. The doubly linked lists work as for devices.
+
+All private data is placed into a `.priv_data` section so that it is contiguous
+in the resulting output binary.
+
+
+Indexes
+-------
+
+U-Boot stores drivers, devices and many other things in linker_list structures.
+These are sorted by name, so dtoc knows the order that they will appear when
+the linker runs. Each driver_info / udevice is referenced by its index in the
+linker_list array, called 'idx' in the code.
+
+When CONFIG_OF_PLATDATA_INST is enabled, idx is the udevice index, otherwise it
+is the driver_info index. In either case, indexes are used to reference devices
+using device_get_by_ofplat_idx(). This allows phandles to work as expected.
+
+
+Phases
+------
+
+U-Boot operates in several phases, typically TPL, SPL and U-Boot proper.
+The latter does not use dtoc.
+
+In some rare cases different drivers are used for two phases. For example,
+in TPL it may not be necessary to use the full PCI subsystem, so a simple
+driver can be used instead.
+
+This works in the build system simply by compiling in one driver or the
+other (e.g. PCI driver + uclass for SPL; simple_bus for TPL). But dtoc has
+no way of knowing which code is compiled in for which phase, since it does
+not inspect Makefiles or dependency graphs.
+
+So to make this work for dtoc, we need to be able to explicitly mark
+drivers with their phase. This is done by adding a macro to the driver::
+
+ /* code in tpl.c only compiled into TPL */
+ U_BOOT_DRIVER(pci_x86) = {
+ .name = "pci_x86",
+ .id = UCLASS_SIMPLE_BUS,
+ .of_match = of_match_ptr(tpl_fake_pci_ids),
+ DM_PHASE(tpl)
+ };
+
+
+ /* code in pci_x86.c compiled into SPL and U-Boot proper */
+ U_BOOT_DRIVER(pci_x86) = {
+ .name = "pci_x86",
+ .id = UCLASS_PCI,
+ .of_match = pci_x86_ids,
+ .ops = &pci_x86_ops,
+ };
+
+
+Notice that the second driver has the same name but no DM_PHASE(), so it will be
+used for SPL and U-Boot.
+
+Note also that this only affects the code generated by dtoc. You still need to
+make sure that only the required driver is build into each phase.
+
+
+Header files
+------------
+
+With OF_PLATDATA_INST, dtoc must include the correct header file in the
+generated code for any structs that are used, so that the code will compile.
+For example, if `struct ns16550_plat` is used, the code must include the
+`ns16550.h` header file.
+
+Typically dtoc can detect the header file needed for a driver by looking
+for the structs that it uses. For example, if a driver as a `.priv_auto`
+that uses `struct ns16550_plat`, then dtoc can search header files for the
+definition of that struct and use the file.
+
+In some cases, enums are used in drivers, typically with the `.data` field
+of `struct udevice_id`. Since dtoc does not support searching for these,
+you must use the `DM_HDR()` macro to tell dtoc which header to use. This works
+as a macro included in the driver definition::
+
+ static const struct udevice_id apl_syscon_ids[] = {
+ { .compatible = "intel,apl-punit", .data = X86_SYSCON_PUNIT },
+ { }
+ };
+
+ U_BOOT_DRIVER(intel_apl_punit) = {
+ .name = "intel_apl_punit",
+ .id = UCLASS_SYSCON,
+ .of_match = apl_syscon_ids,
+ .probe = apl_punit_probe,
+ DM_HEADER(<asm/cpu.h>) /* for X86_SYSCON_PUNIT */
+ };
+
+
+
+Caveats
+-------
+
+There are various complications with this feature which mean it should only
+be used when strictly necessary, i.e. in SPL with limited memory. Notable
+caveats include:
+
+ - Device tree does not describe data types. But the C code must define a
+ type for each property. These are guessed using heuristics which
+ are wrong in several fairly common cases. For example an 8-byte value
+ is considered to be a 2-item integer array, and is byte-swapped. A
+ boolean value that is not present means 'false', but cannot be
+ included in the structures since there is generally no mention of it
+ in the devicetree file.
+
+ - Naming of nodes and properties is automatic. This means that they follow
+ the naming in the devicetree, which may result in C identifiers that
+ look a bit strange.
+
+ - It is not possible to find a value given a property name. Code must use
+ the associated C member variable directly in the code. This makes
+ the code less robust in the face of devicetree changes. To avoid having
+ a second struct with similar members and names you need to explicitly
+ declare it as an alias with `DM_DRIVER_ALIAS()`.
+
+ - The platform data is provided to drivers as a C structure. The driver
+ must use the same structure to access the data. Since a driver
+ normally also supports devicetree it must use `#ifdef` to separate
+ out this code, since the structures are only available in SPL. This could
+ be fixed fairly easily by making the structs available outside SPL, so
+ that `IS_ENABLED()` could be used.
+
+ - With CONFIG_OF_PLATDATA_INST all binding happens at build-time, meaning
+ that (by default) it is not possible to call `device_bind()` from C code.
+ This means that all devices must have an associated devicetree node and
+ compatible string. For example if a GPIO device currently creates child
+ devices in its `bind()` method, it will not work with
+ CONFIG_OF_PLATDATA_INST. Arguably this is bad practice anyway and the
+ devicetree binding should be updated to declare compatible strings for
+ the child devices. It is possible to disable OF_PLATDATA_NO_BIND but this
+ is not recommended since it increases code size.
+
+
+Internals
+---------
+
+Generated files
+```````````````
+
+When enabled, dtoc generates the following five files:
+
+include/generated/dt-decl.h (OF_PLATDATA_INST only)
+ Contains declarations for all drivers, devices and uclasses. This allows
+ any `struct udevice`, `struct driver` or `struct uclass` to be located by its
+ name
+
+include/generated/dt-structs-gen.h
+ Contains the struct definitions for the devicetree nodes that are used. This
+ is the same as without OF_PLATDATA_INST
+
+spl/dts/dt-plat.c (only with !OF_PLATDATA_INST)
+ Contains the `U_BOOT_DRVINFO()` declarations that U-Boot uses to bind devices
+ at start-up. See above for an example
+
+spl/dts/dt-device.c (only with OF_PLATDATA_INST)
+ Contains `DM_DEVICE_INST()` declarations for each device that can be used at
+ run-time. These are declared in the file along with any private/platform data
+ that they use. Every device has an idx, as above. Since each device must be
+ part of a double-linked list, the nodes are declared in the code as well.
+
+spl/dts/dt-uclass.c (only with OF_PLATDATA_INST)
+ Contains `DM_UCLASS_INST()` declarations for each uclass that can be used at
+ run-time. These are declared in the file along with any private data
+ associated with the uclass itself (the `.priv_auto` member). Since each
+ uclass must be part of a double-linked list, the nodes are declared in the
+ code as well.
+
+The dt-structs.h file includes the generated file
+`(include/generated/dt-structs.h`) if CONFIG_SPL_OF_PLATDATA is enabled.
+Otherwise (such as in U-Boot proper) these structs are not available. This
+prevents them being used inadvertently. All usage must be bracketed with
+`#if CONFIG_IS_ENABLED(OF_PLATDATA)`.
+
+The dt-plat.c file contains the device declarations and is is built in
+spl/dt-plat.c.
+
+
+CONFIG options
+``````````````
+
+Several CONFIG options are used to control the behaviour of of-platdata, all
+available for both SPL and TPL:
+
+OF_PLATDATA
+ This is the main option which enables the of-platdata feature
+
+OF_PLATDATA_PARENT
+ This allows `device_get_parent()` to work. Without this, all devices exist as
+ direct children of the root node. This option is highly desirable (if not
+ always absolutely essential) for buses such as I2C.
+
+OF_PLATDATA_INST
+ This controls the instantiation of devices at build time. With it disabled,
+ only `U_BOOT_DRVINFO()` records are created, with U-Boot handling the binding
+ in `device_bind()` on start-up. With it enabled, only `DM_DEVICE_INST()` and
+ `DM_UCLASS_INST()` records are created, and `device_bind()` is not needed at
+ runtime.
+
+OF_PLATDATA_NO_BIND
+ This controls whether `device_bind()` is supported. It is enabled by default
+ with OF_PLATDATA_INST since code-size reduction is really the main point of
+ the feature. It can be disabled if needed but is not likely to be supported
+ in the long term.
+
+OF_PLATDATA_DRIVER_RT
+ This controls whether the `struct driver_rt` records are used by U-Boot.
+ Normally when a device is bound, U-Boot stores the device pointer in one of
+ these records. There is one for every `struct driver_info` in the system,
+ i.e. one for every device that is bound from those records. It provides a
+ way to locate a device in the code and is used by
+ `device_get_by_ofplat_idx()`. This option is always enabled with of-platdata,
+ provided OF_PLATDATA_INST is not. In that case the records are useless since
+ we don't have any `struct driver_info` records.
+
+OF_PLATDATA_RT
+ This controls whether the `struct udevice_rt` records are used by U-Boot.
+ It moves the updatable fields from `struct udevice` (currently only `flags`)
+ into a separate structure, allowing the records to be kept in read-only
+ memory. It is generally enabled if OF_PLATDATA_INST is enabled. This option
+ also controls whether the private data is used in situ, or first copied into
+ an allocated region. Again this is to allow the private data declared by
+ dtoc-generated code to be in read-only memory. Note that access to private
+ data must be done via accessor functions, such as `dev_get_priv()`, so that
+ the relocation is handled.
+
+READ_ONLY
+ This indicates that the data generated by dtoc should not be modified. Only
+ a few fields actually do get changed in U-Boot, such as device flags. This
+ option causes those to move into an allocated space (see OF_PLATDATA_RT).
+ Also, since updating doubly linked lists is generally impossible when some of
+ the nodes cannot be updated, OF_PLATDATA_NO_BIND is enabled.
+
+Data structures
+```````````````
+
+A few extra data structures are used with of-platdata:
+
+`struct udevice_rt`
+ Run-time information for devices. When OF_PLATDATA_RT is enabled, this holds
+ the flags for each device, so that `struct udevice` can remain unchanged by
+ U-Boot, and potentially reside in read-only memory. Access to flags is then
+ via functions like `dev_get_flags()` and `dev_or_flags()`. This data
+ structure is allocated on start-up, where the private data is also copied.
+ All flags values start at 0 and any changes are handled by `dev_or_flags()`
+ and `dev_bic_flags()`. It would be more correct for the flags to be set to
+ `DM_FLAG_BOUND`, or perhaps `DM_FLAG_BOUND | DM_FLAG_ALLOC_PDATA`, but since
+ there is no code to bind/unbind devices and no code to allocate/free
+ private data / platform data, it doesn't matter.
+
+`struct driver_rt`
+ Run-time information for `struct driver_info` records. When
+ OF_PLATDATA_DRIVER_RT is enabled, this holds a pointer to the device
+ created by each record. This is needed so that is it possible to locate a
+ device from C code. Specifically, the code can use `DM_DRVINFO_GET(name)` to
+ get a reference to a particular `struct driver_info`, with `name` being the
+ name of the devicetree node. This is very convenient. It is also fast, since
+ no searching or string comparison is needed. This data structure is
+ allocated on start-up, filled out by `device_bind()` and used by
+ `device_get_by_ofplat_idx()`.
+
+Other changes
+`````````````
+
+Some other changes are made with of-platdata:
+
+Accessor functions
+ Accessing private / platform data via functions such as `dev_get_priv()` has
+ always been encouraged. With OF_PLATDATA_RT this is essential, since the
+ `priv_` and `plat_` (etc.) values point to the data generated by dtoc, not
+ the read-write copy that is sometimes made on start-up. Changing the
+ private / platform data pointers has always been discouraged (the API is
+ marked internal) but with OF_PLATDATA_RT this is not currently supported in
+ general, since it assumes that all such pointers point to the relocated data.
+ Note also that the renaming of struct members to have a trailing underscore
+ was partly done to make people aware that they should not be accessed
+ directly.
+
+`gd->uclass_root_s`
+ Normally U-Boot sets up the head of the uclass list here and makes
+ `gd->uclass_root` point to it. With OF_PLATDATA_INST, dtoc generates a
+ declaration of `uclass_head` in `dt-uclass.c` since it needs to link the
+ head node into the list. In that case, `gd->uclass_root_s` is not used and
+ U-Boot just makes `gd->uclass_root` point to `uclass_head`.
+
+`gd->dm_driver_rt`
+ This holds a pointer to a list of `struct driver_rt` records, one for each
+ `struct driver_info`. The list is in alphabetical order by the name used
+ in `U_BOOT_DRVINFO(name)` and indexed by idx, with the first record having
+ an index of 0. It is only used if OF_PLATDATA_INST is not enabled. This is
+ accessed via macros so that it can be used inside IS_ENABLED(), rather than
+ requiring #ifdefs in the C code when it is not present.
+
+`gd->dm_udevice_rt`
+ This holds a pointer to a list of `struct udevice_rt` records, one for each
+ `struct udevice`. The list is in alphabetical order by the name used
+ in `DM_DEVICE_INST(name)` (a C version of the devicetree node) and indexed by
+ idx, with the first record having an index of 0. It is only used if
+ OF_PLATDATA_INST is enabled. This is accessed via macros so that it can be
+ used inside `IS_ENABLED()`, rather than requiring #ifdefs in the C code when
+ it is not present.
+
+`gd->dm_priv_base`
+ When OF_PLATDATA_RT is enabled, the private/platform data for each device is
+ copied into an allocated region by U-Boot on start-up. This points to that
+ region. All calls to accessor functions (e.g. `dev_get_priv()`) then
+ translate from the pointer provided by the caller (assumed to lie between
+ `__priv_data_start` and `__priv_data_end`) to the new allocated region. This
+ member is accessed via macros so that it can be used inside IS_ENABLED(),
+ rather than required #ifdefs in the C code when it is not present.
+
+`struct udevice->flags_`
+ When OF_PLATDATA_RT is enabled, device flags are no-longer part of
+ `struct udevice`, but are instead kept in `struct udevice_rt`, as described
+ above. Flags are accessed via functions, such as `dev_get_flags()` and
+ `dev_or_flags()`.
+
+`struct udevice->node_`
+ When OF_PLATDATA is enabled, there is no devicetree at runtime, so no need
+ for this field. It is removed, just to save space.
+
+`DM_PHASE`
+ This macro is used to indicate which phase of U-Boot a driver is intended
+ for. See above for details.
+
+`DM_HDR`
+ This macro is used to indicate which header file dtoc should use to allow
+ a driver declaration to compile correctly. See above for details.
+
+`device_get_by_ofplat_idx()`
+ There used to be a function called `device_get_by_driver_info()` which
+ looked up a `struct driver_info` pointer and returned the `struct udevice`
+ that was created from it. It was only available for use with of-platdata.
+ This has been removed in favour of `device_get_by_ofplat_idx()` which uses
+ `idx`, the index of the `struct driver_info` or `struct udevice` in the
+ linker_list. Similarly, the `struct phandle_0_arg` (etc.) structs have been
+ updated to use this index instead of a pointer to `struct driver_info`.
+
+`DM_DRVINFO_GET`
+ This has been removed since we now use indexes to obtain a driver from
+ `struct phandle_0_arg` and the like.
+
+Two-pass binding
+ The original of-platdata tried to order `U_BOOT_DRVINFO()` in the generated
+ files so as to have parents declared ahead of children. This was convenient
+ as it avoided any special code in U-Boot. With OF_PLATDATA_INST this does
+ not work as the idx value relies on using alphabetical order for everything,
+ so that dtoc and U-Boot's linker_lists agree on the idx value. Devices are
+ then bound in order of idx, having no regard to parent/child relationships.
+ For this reason, device binding now hapens in multiple passes, with parents
+ being bound before their children. This is important so that children can
+ find their parents in the bind() method if needed.
+
+Root device
+ The root device is generally bound by U-Boot but with OF_PLATDATA_INST it
+ cannot be, since binding needs to be done at build time. So in this case
+ dtoc sets up a root device using `DM_DEVICE_INST()` in `dt-device.c` and
+ U-Boot makes use of that. When OF_PLATDATA_INST is not enabled, U-Boot
+ generally ignores the root node and does not create a `U_BOOT_DRVINFO()`
+ record for it. This means that the idx numbers used by `struct driver_info`
+ (when OF_PLATDATA_INST is disabled) and the idx numbers used by
+ `struct udevice` (when OF_PLATDATA_INST is enabled) differ, since one has a
+ root node and the other does not. This does not actually matter, since only
+ one of them is actually used for any particular build, but it is worth
+ keeping in mind if comparing index values and switching OF_PLATDATA_INST on
+ and off.
+
+`__priv_data_start` and `__priv_data_end`
+ The private/platform data declared by dtoc is all collected together in
+ a linker section and these symbols mark the start and end of it. This allows
+ U-Boot to relocate the area to a new location if needed (with
+ OF_PLATDATA_RT)
+
+`dm_priv_to_rw()`
+ This function converts a private- or platform-data pointer value generated by
+ dtoc into one that can be used by U-Boot. It is a NOP unless OF_PLATDATA_RT
+ is enabled, in which case it translates the address to the relocated
+ region. See above for more information.
+
+The dm_populate_phandle_data() function that was previous needed has now been
+removed, since dtoc can address the drivers directly from dt-plat.c and does
+not need to fix up things at runtime.
+
+The pylibfdt Python module is used to access the devicetree.
+
+
+Credits
+-------
+
+This is an implementation of an idea by Tom Rini <trini@konsulko.com>.
+
+
+Future work
+-----------
+- Consider programmatically reading binding files instead of devicetree
+ contents
+- Allow IS_ENABLED() to be used in the C code instead of #if
+
+
+.. Simon Glass <sjg@chromium.org>
+.. Google, Inc
+.. 6/6/16
+.. Updated Independence Day 2016
+.. Updated 1st October 2020
+.. Updated 5th February 2021
diff --git a/roms/u-boot/doc/develop/driver-model/pci-info.rst b/roms/u-boot/doc/develop/driver-model/pci-info.rst
new file mode 100644
index 000000000..251601a51
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/pci-info.rst
@@ -0,0 +1,172 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+PCI with Driver Model
+=====================
+
+How busses are scanned
+----------------------
+
+Any config read will end up at pci_read_config(). This uses
+uclass_get_device_by_seq() to get the PCI bus for a particular bus number.
+Bus number 0 will need to be requested first, and the alias in the device
+tree file will point to the correct device::
+
+ aliases {
+ pci0 = &pcic;
+ };
+
+ pcic: pci@0 {
+ compatible = "sandbox,pci";
+ ...
+ };
+
+
+If there is no alias the devices will be numbered sequentially in the device
+tree.
+
+The call to uclass_get_device() will cause the PCI bus to be probed.
+This does a scan of the bus to locate available devices. These devices are
+bound to their appropriate driver if available. If there is no driver, then
+they are bound to a generic PCI driver which does nothing.
+
+After probing a bus, the available devices will appear in the device tree
+under that bus.
+
+Note that this is all done on a lazy basis, as needed, so until something is
+touched on PCI (eg: a call to pci_find_devices()) it will not be probed.
+
+PCI devices can appear in the flattened device tree. If they do, their node
+often contains extra information which cannot be derived from the PCI IDs or
+PCI class of the device. Each PCI device node must have a <reg> property, as
+defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible
+string list is optional and generally not needed, since PCI is discoverable
+bus, albeit there are justified exceptions. If the compatible string is
+present, matching on it takes precedence over PCI IDs and PCI classes.
+
+Note we must describe PCI devices with the same bus hierarchy as the
+hardware, otherwise driver model cannot detect the correct parent/children
+relationship during PCI bus enumeration thus PCI devices won't be bound to
+their drivers accordingly. A working example like below::
+
+ pci {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "pci-x86";
+ u-boot,dm-pre-reloc;
+ ranges = <0x02000000 0x0 0x40000000 0x40000000 0 0x80000000
+ 0x42000000 0x0 0xc0000000 0xc0000000 0 0x20000000
+ 0x01000000 0x0 0x2000 0x2000 0 0xe000>;
+
+ pcie@17,0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "pci-bridge";
+ u-boot,dm-pre-reloc;
+ reg = <0x0000b800 0x0 0x0 0x0 0x0>;
+
+ topcliff@0,0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "pci-bridge";
+ u-boot,dm-pre-reloc;
+ reg = <0x00010000 0x0 0x0 0x0 0x0>;
+
+ pciuart0: uart@a,1 {
+ compatible = "pci8086,8811.00",
+ "pci8086,8811",
+ "pciclass,070002",
+ "pciclass,0700",
+ "x86-uart";
+ u-boot,dm-pre-reloc;
+ reg = <0x00025100 0x0 0x0 0x0 0x0
+ 0x01025110 0x0 0x0 0x0 0x0>;
+ ......
+ };
+
+ ......
+ };
+ };
+
+ ......
+ };
+
+In this example, the root PCI bus node is the "/pci" which matches "pci-x86"
+driver. It has a subnode "pcie@17,0" with driver "pci-bridge". "pcie@17,0"
+also has subnode "topcliff@0,0" which is a "pci-bridge" too. Under that bridge,
+a PCI UART device "uart@a,1" is described. This exactly reflects the hardware
+bus hierarchy: on the root PCI bus, there is a PCIe root port which connects
+to a downstream device Topcliff chipset. Inside Topcliff chipset, it has a
+PCIe-to-PCI bridge and all the chipset integrated devices like the PCI UART
+device are on the PCI bus. Like other devices in the device tree, if we want
+to bind PCI devices before relocation, "u-boot,dm-pre-reloc" must be declared
+in each of these nodes.
+
+If PCI devices are not listed in the device tree, U_BOOT_PCI_DEVICE can be used
+to specify the driver to use for the device. The device tree takes precedence
+over U_BOOT_PCI_DEVICE. Please note with U_BOOT_PCI_DEVICE, only drivers with
+DM_FLAG_PRE_RELOC will be bound before relocation. If neither device tree nor
+U_BOOT_PCI_DEVICE is provided, the built-in driver (either pci_bridge_drv or
+pci_generic_drv) will be used.
+
+
+Sandbox
+-------
+
+With sandbox we need a device emulator for each device on the bus since there
+is no real PCI bus. This works by looking in the device tree node for an
+emulator driver. For example::
+
+ pci@1f,0 {
+ compatible = "pci-generic";
+ reg = <0xf800 0 0 0 0>;
+ sandbox,emul = <&emul_1f>;
+ };
+ pci-emul {
+ compatible = "sandbox,pci-emul-parent";
+ emul_1f: emul@1f,0 {
+ compatible = "sandbox,swap-case";
+ #emul-cells = <0>;
+ };
+ };
+
+This means that there is a 'sandbox,swap-case' driver at that bus position.
+Note that the first cell in the 'reg' value is the bus/device/function. See
+PCI_BDF() for the encoding (it is also specified in the IEEE Std 1275-1994
+PCI bus binding document, v2.1)
+
+The pci-emul node should go outside the pci bus node, since otherwise it will
+be scanned as a PCI device, causing confusion.
+
+When this bus is scanned we will end up with something like this::
+
+ `- * pci@0 @ 05c660c8, 0
+ `- pci@1f,0 @ 05c661c8, 63488
+ `- emul@1f,0 @ 05c662c8
+
+When accesses go to the pci@1f,0 device they are forwarded to its emulator.
+
+The sandbox PCI drivers also support dynamic driver binding, allowing device
+driver to declare the driver binding information via U_BOOT_PCI_DEVICE(),
+eliminating the need to provide any device tree node under the host controller
+node. It is required a "sandbox,dev-info" property must be provided in the
+host controller node for this functionality to work.
+
+.. code-block:: none
+
+ pci1: pci@1 {
+ compatible = "sandbox,pci";
+ ...
+ sandbox,dev-info = <0x08 0x00 0x1234 0x5678
+ 0x0c 0x00 0x1234 0x5678>;
+ };
+
+The "sandbox,dev-info" property specifies all dynamic PCI devices on this bus.
+Each dynamic PCI device is encoded as 4 cells a group. The first and second
+cells are PCI device number and function number respectively. The third and
+fourth cells are PCI vendor ID and device ID respectively.
+
+When this bus is scanned we will end up with something like this::
+
+ pci [ + ] pci_sandbo |-- pci1
+ pci_emul [ ] sandbox_sw | |-- sandbox_swap_case_emul
+ pci_emul [ ] sandbox_sw | `-- sandbox_swap_case_emul
diff --git a/roms/u-boot/doc/develop/driver-model/pmic-framework.rst b/roms/u-boot/doc/develop/driver-model/pmic-framework.rst
new file mode 100644
index 000000000..d24a1badd
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/pmic-framework.rst
@@ -0,0 +1,143 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2014-2015 Samsung Electronics
+.. sectionauthor:: Przemyslaw Marczak <p.marczak@samsung.com>
+
+PMIC framework based on Driver Model
+====================================
+
+Introduction
+------------
+This is an introduction to driver-model multi uclass PMIC IC's support.
+At present it's based on two uclass types:
+
+UCLASS_PMIC:
+ basic uclass type for PMIC I/O, which provides common
+ read/write interface.
+UCLASS_REGULATOR:
+ additional uclass type for specific PMIC features, which are
+ Voltage/Current regulators.
+
+New files:
+
+UCLASS_PMIC:
+ - drivers/power/pmic/pmic-uclass.c
+ - include/power/pmic.h
+UCLASS_REGULATOR:
+ - drivers/power/regulator/regulator-uclass.c
+ - include/power/regulator.h
+
+Commands:
+- common/cmd_pmic.c
+- common/cmd_regulator.c
+
+How doees it work
+-----------------
+The Power Management Integrated Circuits (PMIC) are used in embedded systems
+to provide stable, precise and specific voltage power source with over-voltage
+and thermal protection circuits.
+
+The single PMIC can provide various functions by single or multiple interfaces,
+like in the example below::
+
+ -- SoC
+ |
+ | ______________________________________
+ | BUS 0 | Multi interface PMIC IC |--> LDO out 1
+ | e.g.I2C0 | |--> LDO out N
+ |-----------|---- PMIC device 0 (READ/WRITE ops) |
+ | or SPI0 | |_ REGULATOR device (ldo/... ops) |--> BUCK out 1
+ | | |_ CHARGER device (charger ops) |--> BUCK out M
+ | | |_ MUIC device (microUSB con ops) |
+ | BUS 1 | |_ ... |---> BATTERY
+ | e.g.I2C1 | |
+ |-----------|---- PMIC device 1 (READ/WRITE ops) |---> USB in 1
+ . or SPI1 | |_ RTC device (rtc ops) |---> USB in 2
+ . |______________________________________|---> USB out
+ .
+
+Since U-Boot provides driver model features for I2C and SPI bus drivers,
+the PMIC devices should also support this. By the pmic and regulator API's,
+PMIC drivers can simply provide a common functions, for multi-interface and
+and multi-instance device support.
+
+Basic design assumptions:
+
+- Common I/O API:
+ UCLASS_PMIC. For the multi-function PMIC devices, this can be used as
+ parent I/O device for each IC's interface. Then, each children uses the
+ same dev for read/write.
+
+- Common regulator API:
+ UCLASS_REGULATOR. For driving the regulator attributes, auto setting
+ function or command line interface, based on kernel-style regulator device
+ tree constraints.
+
+For simple implementations, regulator drivers are not required, so the code can
+use pmic read/write directly.
+
+Pmic uclass
+-----------
+The basic information:
+
+* Uclass: 'UCLASS_PMIC'
+* Header: 'include/power/pmic.h'
+* Core: 'drivers/power/pmic/pmic-uclass.c' (config 'CONFIG_DM_PMIC')
+* Command: 'common/cmd_pmic.c' (config 'CONFIG_CMD_PMIC')
+* Example: 'drivers/power/pmic/max77686.c'
+
+For detailed API description, please refer to the header file.
+
+As an example of the pmic driver, please refer to the MAX77686 driver.
+
+Please pay attention for the driver's bind() method. Exactly the function call:
+'pmic_bind_children()', which is used to bind the regulators by using the array
+of regulator's node, compatible prefixes.
+
+The 'pmic; command also supports the new API. So the pmic command can be enabled
+by adding CONFIG_CMD_PMIC.
+The new pmic command allows to:
+- list pmic devices
+- choose the current device (like the mmc command)
+- read or write the pmic register
+- dump all pmic registers
+
+This command can use only UCLASS_PMIC devices, since this uclass is designed
+for pmic I/O operations only.
+
+For more information, please refer to the core file.
+
+Regulator uclass
+----------------
+The basic information:
+
+* Uclass: 'UCLASS_REGULATOR'
+
+* Header: 'include/power/regulator.h'
+
+* Core: 'drivers/power/regulator/regulator-uclass.c'
+ (config 'CONFIG_DM_REGULATOR')
+
+* Binding: 'doc/device-tree-bindings/regulator/regulator.txt'
+
+* Command: 'common/cmd_regulator.c' (config 'CONFIG_CMD_REGULATOR')
+
+* Example: 'drivers/power/regulator/max77686.c'
+ 'drivers/power/pmic/max77686.c' (required I/O driver for the above)
+
+* Example: 'drivers/power/regulator/fixed.c'
+ (config 'CONFIG_DM_REGULATOR_FIXED')
+
+For detailed API description, please refer to the header file.
+
+For the example regulator driver, please refer to the MAX77686 regulator driver,
+but this driver can't operate without pmic's example driver, which provides an
+I/O interface for MAX77686 regulator.
+
+The second example is a fixed Voltage/Current regulator for a common use.
+
+The 'regulator' command also supports the new API. The command allow:
+- list regulator devices
+- choose the current device (like the mmc command)
+- do all regulator-specific operations
+
+For more information, please refer to the command file.
diff --git a/roms/u-boot/doc/develop/driver-model/remoteproc-framework.rst b/roms/u-boot/doc/develop/driver-model/remoteproc-framework.rst
new file mode 100644
index 000000000..566495a21
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/remoteproc-framework.rst
@@ -0,0 +1,169 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2015
+.. Texas Instruments Incorporated - http://www.ti.com/
+
+Remote Processor Framework
+==========================
+
+Introduction
+------------
+
+This is an introduction to driver-model for Remote Processors found
+on various System on Chip(SoCs). The term remote processor is used to
+indicate that this is not the processor on which U-Boot is operating
+on, instead is yet another processing entity that may be controlled by
+the processor on which we are functional.
+
+The simplified model depends on a single UCLASS - UCLASS_REMOTEPROC
+
+UCLASS_REMOTEPROC:
+ - drivers/remoteproc/rproc-uclass.c
+ - include/remoteproc.h
+
+Commands:
+ - common/cmd_remoteproc.c
+
+Configuration:
+ - CONFIG_REMOTEPROC is selected by drivers as needed
+ - CONFIG_CMD_REMOTEPROC for the commands if required.
+
+How does it work - The driver
+-----------------------------
+
+Overall, the driver statemachine transitions are typically as follows::
+
+ (entry)
+ +-------+
+ +---+ init |
+ | | | <---------------------+
+ | +-------+ |
+ | |
+ | |
+ | +--------+ |
+ Load| | reset | |
+ | | | <----------+ |
+ | +--------+ | |
+ | |Load | |
+ | | | |
+ | +----v----+ reset | |
+ +-> | | (opt) | |
+ | Loaded +-----------+ |
+ | | |
+ +----+----+ |
+ | Start |
+ +---v-----+ (opt) |
+ +->| Running | Stop |
+ Ping +- | +--------------------+
+ (opt) +---------+
+
+(is_running does not change state)
+opt: Optional state transition implemented by driver.
+
+NOTE: It depends on the remote processor as to the exact behavior
+of the statemachine, remoteproc core does not intent to implement
+statemachine logic. Certain processors may allow start/stop without
+reloading the image in the middle, certain other processors may only
+allow us to start the processor(image from a EEPROM/OTP) etc.
+
+It is hence the responsibility of the driver to handle the requisite
+state transitions of the device as necessary.
+
+Basic design assumptions:
+
+Remote processor can operate on a certain firmware that maybe loaded
+and released from reset.
+
+The driver follows a standard UCLASS DM.
+
+in the bare minimum form:
+
+.. code-block:: c
+
+ static const struct dm_rproc_ops sandbox_testproc_ops = {
+ .load = sandbox_testproc_load,
+ .start = sandbox_testproc_start,
+ };
+
+ static const struct udevice_id sandbox_ids[] = {
+ {.compatible = "sandbox,test-processor"},
+ {}
+ };
+
+ U_BOOT_DRIVER(sandbox_testproc) = {
+ .name = "sandbox_test_proc",
+ .of_match = sandbox_ids,
+ .id = UCLASS_REMOTEPROC,
+ .ops = &sandbox_testproc_ops,
+ .probe = sandbox_testproc_probe,
+ };
+
+This allows for the device to be probed as part of the "init" command
+or invocation of 'rproc_init()' function as the system dependencies define.
+
+The driver is expected to maintain it's own statemachine which is
+appropriate for the device it maintains. It must, at the very least
+provide a load and start function. We assume here that the device
+needs to be loaded and started, else, there is no real purpose of
+using the remoteproc framework.
+
+Describing the device using platform data
+-----------------------------------------
+
+*IMPORTANT* NOTE: THIS SUPPORT IS NOT MEANT FOR USE WITH NEWER PLATFORM
+SUPPORT. THIS IS ONLY FOR LEGACY DEVICES. THIS MODE OF INITIALIZATION
+*WILL* BE EVENTUALLY REMOVED ONCE ALL NECESSARY PLATFORMS HAVE MOVED
+TO DM/FDT.
+
+Considering that many platforms are yet to move to device-tree model,
+a simplified definition of a device is as follows:
+
+.. code-block:: c
+
+ struct dm_rproc_uclass_pdata proc_3_test = {
+ .name = "proc_3_legacy",
+ .mem_type = RPROC_INTERNAL_MEMORY_MAPPED,
+ .driver_plat_data = &mydriver_data;
+ };
+
+ U_BOOT_DRVINFO(proc_3_demo) = {
+ .name = "sandbox_test_proc",
+ .plat = &proc_3_test,
+ };
+
+There can be additional data that may be desired depending on the
+remoteproc driver specific needs (for example: SoC integration
+details such as clock handle or something similar). See appropriate
+documentation for specific remoteproc driver for further details.
+These are passed via driver_plat_data.
+
+Describing the device using device tree
+---------------------------------------
+
+.. code-block: none
+
+ / {
+ ...
+ aliases {
+ ...
+ remoteproc0 = &rproc_1;
+ remoteproc1 = &rproc_2;
+
+ };
+ ...
+
+ rproc_1: rproc@1 {
+ compatible = "sandbox,test-processor";
+ remoteproc-name = "remoteproc-test-dev1";
+ };
+
+ rproc_2: rproc@2 {
+ compatible = "sandbox,test-processor";
+ internal-memory-mapped;
+ remoteproc-name = "remoteproc-test-dev2";
+ };
+ ...
+ };
+
+aliases usage is optional, but it is usually recommended to ensure the
+users have a consistent usage model for a platform.
+the compatible string used here is specific to the remoteproc driver involved.
diff --git a/roms/u-boot/doc/develop/driver-model/serial-howto.rst b/roms/u-boot/doc/develop/driver-model/serial-howto.rst
new file mode 100644
index 000000000..146913112
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/serial-howto.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+How to port a serial driver to driver model
+===========================================
+
+Almost all of the serial drivers have been converted as at January 2016. These
+ones remain:
+
+ * serial_bfin.c
+ * serial_pxa.c
+
+The deadline for this work was the end of January 2016. If no one steps
+forward to convert these, at some point there may come a patch to remove them!
+
+Here is a suggested approach for converting your serial driver over to driver
+model. Please feel free to update this file with your ideas and suggestions.
+
+- #ifdef out all your own serial driver code (#ifndef CONFIG_DM_SERIAL)
+- Define CONFIG_DM_SERIAL for your board, vendor or architecture
+- If the board does not already use driver model, you need CONFIG_DM also
+- Your board should then build, but will not boot since there will be no serial
+ driver
+- Add the U_BOOT_DRIVER piece at the end (e.g. copy serial_s5p.c for example)
+- Add a private struct for the driver data - avoid using static variables
+- Implement each of the driver methods, perhaps by calling your old methods
+- You may need to adjust the function parameters so that the old and new
+ implementations can share most of the existing code
+- If you convert all existing users of the driver, remove the pre-driver-model
+ code
+
+In terms of patches a conversion series typically has these patches:
+- clean up / prepare the driver for conversion
+- add driver model code
+- convert at least one existing board to use driver model serial
+- (if no boards remain that don't use driver model) remove the old code
+
+This may be a good time to move your board to use device tree also. Mostly
+this involves these steps:
+
+- define CONFIG_OF_CONTROL and CONFIG_OF_SEPARATE
+- add your device tree files to arch/<arch>/dts
+- update the Makefile there
+- Add stdout-path to your /chosen device tree node if it is not already there
+- build and get u-boot-dtb.bin so you can test it
+- Your drivers can now use device tree
+- For device tree in SPL, define CONFIG_SPL_OF_CONTROL
diff --git a/roms/u-boot/doc/develop/driver-model/soc-framework.rst b/roms/u-boot/doc/develop/driver-model/soc-framework.rst
new file mode 100644
index 000000000..2609fda64
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/soc-framework.rst
@@ -0,0 +1,68 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2020
+.. Texas Instruments Incorporated - http://www.ti.com/
+
+SOC ID Framework
+================
+
+Introduction
+------------
+
+The driver-model SOC ID framework is able to provide identification
+information about a specific SoC in use at runtime, and also provide matching
+from a set of identification information from an array. This can be useful for
+enabling small quirks in drivers that exist between SoC variants that are
+impractical to implement using device tree flags. It is based on UCLASS_SOC.
+
+UCLASS_SOC:
+ - drivers/soc/soc-uclass.c
+ - include/soc.h
+
+Configuration:
+ - CONFIG_SOC_DEVICE is selected by drivers as needed.
+
+Implementing a UCLASS_SOC provider
+----------------------------------
+
+The purpose of this framework is to allow UCLASS_SOC provider drivers to supply
+identification information about the SoC in use at runtime. The framework
+allows drivers to define soc_ops that return identification strings. All
+soc_ops need not be defined and can be left as NULL, in which case the
+framework will return -ENOSYS and not consider the value when doing an
+soc_device_match.
+
+It is left to the driver implementor to decide how the information returned is
+determined, but in general the same SOC should always return the same set of
+identifying information. Information returned must be in the form of a NULL
+terminated string.
+
+See include/soc.h for documentation of the available soc_ops and the intended
+meaning of the values that can be returned. See drivers/soc/soc_sandbox.c for
+an example UCLASS_SOC provider driver.
+
+Using a UCLASS_SOC driver
+-------------------------
+
+The framework provides the ability to retrieve and use the identification
+strings directly. It also has the ability to return a match from a list of
+different sets of SoC data using soc_device_match.
+
+An array of 'struct soc_attr' can be defined, each containing ID information
+for a specific SoC, and when passed to soc_device_match, the identifier values
+for each entry in the list will be compared against the values provided by the
+UCLASS_SOC driver that is in use. The first entry in the list that matches all
+non-null values will be returned by soc_device_match.
+
+An example of various uses of the framework can be found at test/dm/soc.c.
+
+Describing the device using device tree
+---------------------------------------
+
+.. code-block:: none
+
+ chipid: chipid {
+ compatible = "sandbox,soc";
+ };
+
+All that is required in a DT node is a compatible for a corresponding
+UCLASS_SOC driver.
diff --git a/roms/u-boot/doc/develop/driver-model/spi-howto.rst b/roms/u-boot/doc/develop/driver-model/spi-howto.rst
new file mode 100644
index 000000000..97fbf750c
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/spi-howto.rst
@@ -0,0 +1,692 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+How to port a SPI driver to driver model
+========================================
+
+Here is a rough step-by-step guide. It is based around converting the
+exynos SPI driver to driver model (DM) and the example code is based
+around U-Boot v2014.10-rc2 (commit be9f643). This has been updated for
+v2015.04.
+
+It is quite long since it includes actual code examples.
+
+Before driver model, SPI drivers have their own private structure which
+contains 'struct spi_slave'. With driver model, 'struct spi_slave' still
+exists, but now it is 'per-child data' for the SPI bus. Each child of the
+SPI bus is a SPI slave. The information that was stored in the
+driver-specific slave structure can now be port in private data for the
+SPI bus.
+
+For example, struct tegra_spi_slave looks like this:
+
+.. code-block:: c
+
+ struct tegra_spi_slave {
+ struct spi_slave slave;
+ struct tegra_spi_ctrl *ctrl;
+ };
+
+In this case 'slave' will be in per-child data, and 'ctrl' will be in the
+SPI's buses private data.
+
+
+How long does this take?
+------------------------
+
+You should be able to complete this within 2 hours, including testing but
+excluding preparing the patches. The API is basically the same as before
+with only minor changes:
+
+- methods to set speed and mode are separated out
+- cs_info is used to get information on a chip select
+
+
+Enable driver mode for SPI and SPI flash
+----------------------------------------
+
+Add these to your board config:
+
+* CONFIG_DM_SPI
+* CONFIG_DM_SPI_FLASH
+
+
+Add the skeleton
+----------------
+
+Put this code at the bottom of your existing driver file:
+
+.. code-block:: c
+
+ struct spi_slave *spi_setup_slave(unsigned int busnum, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+ {
+ return NULL;
+ }
+
+ struct spi_slave *spi_setup_slave_fdt(const void *blob, int slave_node,
+ int spi_node)
+ {
+ return NULL;
+ }
+
+ static int exynos_spi_of_to_plat(struct udevice *dev)
+ {
+ return -ENODEV;
+ }
+
+ static int exynos_spi_probe(struct udevice *dev)
+ {
+ return -ENODEV;
+ }
+
+ static int exynos_spi_remove(struct udevice *dev)
+ {
+ return -ENODEV;
+ }
+
+ static int exynos_spi_claim_bus(struct udevice *dev)
+ {
+
+ return -ENODEV;
+ }
+
+ static int exynos_spi_release_bus(struct udevice *dev)
+ {
+
+ return -ENODEV;
+ }
+
+ static int exynos_spi_xfer(struct udevice *dev, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags)
+ {
+
+ return -ENODEV;
+ }
+
+ static int exynos_spi_set_speed(struct udevice *dev, uint speed)
+ {
+ return -ENODEV;
+ }
+
+ static int exynos_spi_set_mode(struct udevice *dev, uint mode)
+ {
+ return -ENODEV;
+ }
+
+ static int exynos_cs_info(struct udevice *bus, uint cs,
+ struct spi_cs_info *info)
+ {
+ return -EINVAL;
+ }
+
+ static const struct dm_spi_ops exynos_spi_ops = {
+ .claim_bus = exynos_spi_claim_bus,
+ .release_bus = exynos_spi_release_bus,
+ .xfer = exynos_spi_xfer,
+ .set_speed = exynos_spi_set_speed,
+ .set_mode = exynos_spi_set_mode,
+ .cs_info = exynos_cs_info,
+ };
+
+ static const struct udevice_id exynos_spi_ids[] = {
+ { .compatible = "samsung,exynos-spi" },
+ { }
+ };
+
+ U_BOOT_DRIVER(exynos_spi) = {
+ .name = "exynos_spi",
+ .id = UCLASS_SPI,
+ .of_match = exynos_spi_ids,
+ .ops = &exynos_spi_ops,
+ .of_to_plat = exynos_spi_of_to_plat,
+ .probe = exynos_spi_probe,
+ .remove = exynos_spi_remove,
+ };
+
+
+Replace 'exynos' in the above code with your driver name
+--------------------------------------------------------
+
+
+#ifdef out all of the code in your driver except for the above
+--------------------------------------------------------------
+
+This will allow you to get it building, which means you can work
+incrementally. Since all the methods return an error initially, there is
+less chance that you will accidentally leave something in.
+
+Also, even though your conversion is basically a rewrite, it might help
+reviewers if you leave functions in the same place in the file,
+particularly for large drivers.
+
+
+Add some includes
+-----------------
+
+Add these includes to your driver:
+
+.. code-block:: c
+
+ #include <dm.h>
+ #include <errno.h>
+
+
+Build
+-----
+
+At this point you should be able to build U-Boot for your board with the
+empty SPI driver. You still have empty methods in your driver, but we will
+write these one by one.
+
+Set up your platform data structure
+-----------------------------------
+
+This will hold the information your driver to operate, like its hardware
+address or maximum frequency.
+
+You may already have a struct like this, or you may need to create one
+from some of the #defines or global variables in the driver.
+
+Note that this information is not the run-time information. It should not
+include state that changes. It should be fixed throughout the live of
+U-Boot. Run-time information comes later.
+
+Here is what was in the exynos spi driver:
+
+.. code-block:: c
+
+ struct spi_bus {
+ enum periph_id periph_id;
+ s32 frequency; /* Default clock frequency, -1 for none */
+ struct exynos_spi *regs;
+ int inited; /* 1 if this bus is ready for use */
+ int node;
+ uint deactivate_delay_us; /* Delay to wait after deactivate */
+ };
+
+Of these, inited is handled by DM and node is the device tree node, which
+DM tells you. The name is not quite right. So in this case we would use:
+
+.. code-block:: c
+
+ struct exynos_spi_plat {
+ enum periph_id periph_id;
+ s32 frequency; /* Default clock frequency, -1 for none */
+ struct exynos_spi *regs;
+ uint deactivate_delay_us; /* Delay to wait after deactivate */
+ };
+
+
+Write of_to_plat() [for device tree only]
+-------------------------------------------------
+
+This method will convert information in the device tree node into a C
+structure in your driver (called platform data). If you are not using
+device tree, go to 8b.
+
+DM will automatically allocate the struct for us when we are using device
+tree, but we need to tell it the size:
+
+.. code-block:: c
+
+ U_BOOT_DRIVER(spi_exynos) = {
+ ...
+ .plat_auto = sizeof(struct exynos_spi_plat),
+
+
+Here is a sample function. It gets a pointer to the platform data and
+fills in the fields from device tree.
+
+.. code-block:: c
+
+ static int exynos_spi_of_to_plat(struct udevice *bus)
+ {
+ struct exynos_spi_plat *plat = bus->plat;
+ const void *blob = gd->fdt_blob;
+ int node = dev_of_offset(bus);
+
+ plat->regs = (struct exynos_spi *)fdtdec_get_addr(blob, node, "reg");
+ plat->periph_id = pinmux_decode_periph_id(blob, node);
+
+ if (plat->periph_id == PERIPH_ID_NONE) {
+ debug("%s: Invalid peripheral ID %d\n", __func__,
+ plat->periph_id);
+ return -FDT_ERR_NOTFOUND;
+ }
+
+ /* Use 500KHz as a suitable default */
+ plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
+ 500000);
+ plat->deactivate_delay_us = fdtdec_get_int(blob, node,
+ "spi-deactivate-delay", 0);
+ debug("%s: regs=%p, periph_id=%d, max-frequency=%d, deactivate_delay=%d\n",
+ __func__, plat->regs, plat->periph_id, plat->frequency,
+ plat->deactivate_delay_us);
+
+ return 0;
+ }
+
+
+Add the platform data [non-device-tree only]
+--------------------------------------------
+
+Specify this data in a U_BOOT_DRVINFO() declaration in your board file:
+
+.. code-block:: c
+
+ struct exynos_spi_plat platdata_spi0 = {
+ .periph_id = ...
+ .frequency = ...
+ .regs = ...
+ .deactivate_delay_us = ...
+ };
+
+ U_BOOT_DRVINFO(board_spi0) = {
+ .name = "exynos_spi",
+ .plat = &platdata_spi0,
+ };
+
+You will unfortunately need to put the struct definition into a header file
+in this case so that your board file can use it.
+
+
+Add the device private data
+---------------------------
+
+Most devices have some private data which they use to keep track of things
+while active. This is the run-time information and needs to be stored in
+a structure. There is probably a structure in the driver that includes a
+'struct spi_slave', so you can use that.
+
+.. code-block:: c
+
+ struct exynos_spi_slave {
+ struct spi_slave slave;
+ struct exynos_spi *regs;
+ unsigned int freq; /* Default frequency */
+ unsigned int mode;
+ enum periph_id periph_id; /* Peripheral ID for this device */
+ unsigned int fifo_size;
+ int skip_preamble;
+ struct spi_bus *bus; /* Pointer to our SPI bus info */
+ ulong last_transaction_us; /* Time of last transaction end */
+ };
+
+
+We should rename this to make its purpose more obvious, and get rid of
+the slave structure, so we have:
+
+.. code-block:: c
+
+ struct exynos_spi_priv {
+ struct exynos_spi *regs;
+ unsigned int freq; /* Default frequency */
+ unsigned int mode;
+ enum periph_id periph_id; /* Peripheral ID for this device */
+ unsigned int fifo_size;
+ int skip_preamble;
+ ulong last_transaction_us; /* Time of last transaction end */
+ };
+
+
+DM can auto-allocate this also:
+
+.. code-block:: c
+
+ U_BOOT_DRIVER(spi_exynos) = {
+ ...
+ .priv_auto = sizeof(struct exynos_spi_priv),
+
+
+Note that this is created before the probe method is called, and destroyed
+after the remove method is called. It will be zeroed when the probe
+method is called.
+
+
+Add the probe() and remove() methods
+------------------------------------
+
+Note: It's a good idea to build repeatedly as you are working, to avoid a
+huge amount of work getting things compiling at the end.
+
+The probe method is supposed to set up the hardware. U-Boot used to use
+spi_setup_slave() to do this. So take a look at this function and see
+what you can copy out to set things up.
+
+.. code-block:: c
+
+ static int exynos_spi_probe(struct udevice *bus)
+ {
+ struct exynos_spi_plat *plat = dev_get_plat(bus);
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+
+ priv->regs = plat->regs;
+ if (plat->periph_id == PERIPH_ID_SPI1 ||
+ plat->periph_id == PERIPH_ID_SPI2)
+ priv->fifo_size = 64;
+ else
+ priv->fifo_size = 256;
+
+ priv->skip_preamble = 0;
+ priv->last_transaction_us = timer_get_us();
+ priv->freq = plat->frequency;
+ priv->periph_id = plat->periph_id;
+
+ return 0;
+ }
+
+This implementation doesn't actually touch the hardware, which is somewhat
+unusual for a driver. In this case we will do that when the device is
+claimed by something that wants to use the SPI bus.
+
+For remove we could shut down the clocks, but in this case there is
+nothing to do. DM frees any memory that it allocated, so we can just
+remove exynos_spi_remove() and its reference in U_BOOT_DRIVER.
+
+
+Implement set_speed()
+---------------------
+
+This should set up clocks so that the SPI bus is running at the right
+speed. With the old API spi_claim_bus() would normally do this and several
+of the following functions, so let's look at that function:
+
+.. code-block:: c
+
+ int spi_claim_bus(struct spi_slave *slave)
+ {
+ struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
+ struct exynos_spi *regs = spi_slave->regs;
+ u32 reg = 0;
+ int ret;
+
+ ret = set_spi_clk(spi_slave->periph_id,
+ spi_slave->freq);
+ if (ret < 0) {
+ debug("%s: Failed to setup spi clock\n", __func__);
+ return ret;
+ }
+
+ exynos_pinmux_config(spi_slave->periph_id, PINMUX_FLAG_NONE);
+
+ spi_flush_fifo(slave);
+
+ reg = readl(&regs->ch_cfg);
+ reg &= ~(SPI_CH_CPHA_B | SPI_CH_CPOL_L);
+
+ if (spi_slave->mode & SPI_CPHA)
+ reg |= SPI_CH_CPHA_B;
+
+ if (spi_slave->mode & SPI_CPOL)
+ reg |= SPI_CH_CPOL_L;
+
+ writel(reg, &regs->ch_cfg);
+ writel(SPI_FB_DELAY_180, &regs->fb_clk);
+
+ return 0;
+ }
+
+
+It sets up the speed, mode, pinmux, feedback delay and clears the FIFOs.
+With DM these will happen in separate methods.
+
+
+Here is an example for the speed part:
+
+.. code-block:: c
+
+ static int exynos_spi_set_speed(struct udevice *bus, uint speed)
+ {
+ struct exynos_spi_plat *plat = bus->plat;
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+ int ret;
+
+ if (speed > plat->frequency)
+ speed = plat->frequency;
+ ret = set_spi_clk(priv->periph_id, speed);
+ if (ret)
+ return ret;
+ priv->freq = speed;
+ debug("%s: regs=%p, speed=%d\n", __func__, priv->regs, priv->freq);
+
+ return 0;
+ }
+
+
+Implement set_mode()
+--------------------
+
+This should adjust the SPI mode (polarity, etc.). Again this code probably
+comes from the old spi_claim_bus(). Here is an example:
+
+.. code-block:: c
+
+ static int exynos_spi_set_mode(struct udevice *bus, uint mode)
+ {
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+ uint32_t reg;
+
+ reg = readl(&priv->regs->ch_cfg);
+ reg &= ~(SPI_CH_CPHA_B | SPI_CH_CPOL_L);
+
+ if (mode & SPI_CPHA)
+ reg |= SPI_CH_CPHA_B;
+
+ if (mode & SPI_CPOL)
+ reg |= SPI_CH_CPOL_L;
+
+ writel(reg, &priv->regs->ch_cfg);
+ priv->mode = mode;
+ debug("%s: regs=%p, mode=%d\n", __func__, priv->regs, priv->mode);
+
+ return 0;
+ }
+
+
+Implement claim_bus()
+---------------------
+
+This is where a client wants to make use of the bus, so claims it first.
+At this point we need to make sure everything is set up ready for data
+transfer. Note that this function is wholly internal to the driver - at
+present the SPI uclass never calls it.
+
+Here again we look at the old claim function and see some code that is
+needed. It is anything unrelated to speed and mode:
+
+.. code-block:: c
+
+ static int exynos_spi_claim_bus(struct udevice *bus)
+ {
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+
+ exynos_pinmux_config(priv->periph_id, PINMUX_FLAG_NONE);
+ spi_flush_fifo(priv->regs);
+
+ writel(SPI_FB_DELAY_180, &priv->regs->fb_clk);
+
+ return 0;
+ }
+
+The spi_flush_fifo() function is in the removed part of the code, so we
+need to expose it again (perhaps with an #endif before it and '#if 0'
+after it). It only needs access to priv->regs which is why we have
+passed that in:
+
+.. code-block:: c
+
+ /**
+ * Flush spi tx, rx fifos and reset the SPI controller
+ *
+ * @param regs Pointer to SPI registers
+ */
+ static void spi_flush_fifo(struct exynos_spi *regs)
+ {
+ clrsetbits_le32(&regs->ch_cfg, SPI_CH_HS_EN, SPI_CH_RST);
+ clrbits_le32(&regs->ch_cfg, SPI_CH_RST);
+ setbits_le32(&regs->ch_cfg, SPI_TX_CH_ON | SPI_RX_CH_ON);
+ }
+
+
+Implement release_bus()
+-----------------------
+
+This releases the bus - in our example the old code in spi_release_bus()
+is a call to spi_flush_fifo, so we add:
+
+.. code-block:: c
+
+ static int exynos_spi_release_bus(struct udevice *bus)
+ {
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+
+ spi_flush_fifo(priv->regs);
+
+ return 0;
+ }
+
+
+Implement xfer()
+----------------
+
+This is the final method that we need to create, and it is where all the
+work happens. The method parameters are the same as the old spi_xfer() with
+the addition of a 'struct udevice' so conversion is pretty easy. Start
+by copying the contents of spi_xfer() to your new xfer() method and proceed
+from there.
+
+If (flags & SPI_XFER_BEGIN) is non-zero then xfer() normally calls an
+activate function, something like this:
+
+.. code-block:: c
+
+ void spi_cs_activate(struct spi_slave *slave)
+ {
+ struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
+
+ /* If it's too soon to do another transaction, wait */
+ if (spi_slave->bus->deactivate_delay_us &&
+ spi_slave->last_transaction_us) {
+ ulong delay_us; /* The delay completed so far */
+ delay_us = timer_get_us() - spi_slave->last_transaction_us;
+ if (delay_us < spi_slave->bus->deactivate_delay_us)
+ udelay(spi_slave->bus->deactivate_delay_us - delay_us);
+ }
+
+ clrbits_le32(&spi_slave->regs->cs_reg, SPI_SLAVE_SIG_INACT);
+ debug("Activate CS, bus %d\n", spi_slave->slave.bus);
+ spi_slave->skip_preamble = spi_slave->mode & SPI_PREAMBLE;
+ }
+
+The new version looks like this:
+
+.. code-block:: c
+
+ static void spi_cs_activate(struct udevice *dev)
+ {
+ struct udevice *bus = dev->parent;
+ struct exynos_spi_plat *pdata = dev_get_plat(bus);
+ struct exynos_spi_priv *priv = dev_get_priv(bus);
+
+ /* If it's too soon to do another transaction, wait */
+ if (pdata->deactivate_delay_us &&
+ priv->last_transaction_us) {
+ ulong delay_us; /* The delay completed so far */
+ delay_us = timer_get_us() - priv->last_transaction_us;
+ if (delay_us < pdata->deactivate_delay_us)
+ udelay(pdata->deactivate_delay_us - delay_us);
+ }
+
+ clrbits_le32(&priv->regs->cs_reg, SPI_SLAVE_SIG_INACT);
+ debug("Activate CS, bus '%s'\n", bus->name);
+ priv->skip_preamble = priv->mode & SPI_PREAMBLE;
+ }
+
+All we have really done here is change the pointers and print the device name
+instead of the bus number. Other local static functions can be treated in
+the same way.
+
+
+Set up the per-child data and child pre-probe function
+------------------------------------------------------
+
+To minimise the pain and complexity of the SPI subsystem while the driver
+model change-over is in place, struct spi_slave is used to reference a
+SPI bus slave, even though that slave is actually a struct udevice. In fact
+struct spi_slave is the device's child data. We need to make sure this space
+is available. It is possible to allocate more space that struct spi_slave
+needs, but this is the minimum.
+
+.. code-block:: c
+
+ U_BOOT_DRIVER(exynos_spi) = {
+ ...
+ .per_child_auto = sizeof(struct spi_slave),
+ }
+
+
+Optional: Set up cs_info() if you want it
+-----------------------------------------
+
+Sometimes it is useful to know whether a SPI chip select is valid, but this
+is not obvious from outside the driver. In this case you can provide a
+method for cs_info() to deal with this. If you don't provide it, then the
+device tree will be used to determine what chip selects are valid.
+
+Return -EINVAL if the supplied chip select is invalid, or 0 if it is valid.
+If you don't provide the cs_info() method, 0 is assumed for all chip selects
+that do not appear in the device tree.
+
+
+Test it
+-------
+
+Now that you have the code written and it compiles, try testing it using
+the 'sf test' command. You may need to enable CONFIG_CMD_SF_TEST for your
+board.
+
+
+Prepare patches and send them to the mailing lists
+--------------------------------------------------
+
+You can use 'tools/patman/patman' to prepare, check and send patches for
+your work. See tools/patman/README for details.
+
+A little note about SPI uclass features
+---------------------------------------
+
+The SPI uclass keeps some information about each device 'dev' on the bus:
+
+ struct dm_spi_slave_plat:
+ This is device_get_parent_plat(dev).
+ This is where the chip select number is stored, along with
+ the default bus speed and mode. It is automatically read
+ from the device tree in spi_child_post_bind(). It must not
+ be changed at run-time after being set up because platform
+ data is supposed to be immutable at run-time.
+ struct spi_slave:
+ This is device_get_parentdata(dev).
+ Already mentioned above. It holds run-time information about
+ the device.
+
+There are also some SPI uclass methods that get called behind the scenes:
+
+ spi_post_bind():
+ Called when a new bus is bound.
+ This scans the device tree for devices on the bus, and binds
+ each one. This in turn causes spi_child_post_bind() to be
+ called for each, which reads the device tree information
+ into the parent (per-child) platform data.
+ spi_child_post_bind():
+ Called when a new child is bound.
+ As mentioned above this reads the device tree information
+ into the per-child platform data
+ spi_child_pre_probe():
+ Called before a new child is probed.
+ This sets up the mode and speed in struct spi_slave by
+ copying it from the parent's platform data for this child.
+ It also sets the 'dev' pointer, needed to permit passing
+ 'struct spi_slave' around the place without needing a
+ separate 'struct udevice' pointer.
+
+The above housekeeping makes it easier to write your SPI driver.
diff --git a/roms/u-boot/doc/develop/driver-model/usb-info.rst b/roms/u-boot/doc/develop/driver-model/usb-info.rst
new file mode 100644
index 000000000..24d1e81a6
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/usb-info.rst
@@ -0,0 +1,423 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+How USB works with driver model
+===============================
+
+Introduction
+------------
+
+Driver model USB support makes use of existing features but changes how
+drivers are found. This document provides some information intended to help
+understand how things work with USB in U-Boot when driver model is enabled.
+
+
+Enabling driver model for USB
+-----------------------------
+
+A new CONFIG_DM_USB option is provided to enable driver model for USB. This
+causes the USB uclass to be included, and drops the equivalent code in
+usb.c. In particular the usb_init() function is then implemented by the
+uclass.
+
+
+Support for EHCI and XHCI
+-------------------------
+
+So far OHCI is not supported. Both EHCI and XHCI drivers should be declared
+as drivers in the USB uclass. For example:
+
+.. code-block:: c
+
+ static const struct udevice_id ehci_usb_ids[] = {
+ { .compatible = "nvidia,tegra20-ehci", .data = USB_CTLR_T20 },
+ { .compatible = "nvidia,tegra30-ehci", .data = USB_CTLR_T30 },
+ { .compatible = "nvidia,tegra114-ehci", .data = USB_CTLR_T114 },
+ { }
+ };
+
+ U_BOOT_DRIVER(usb_ehci) = {
+ .name = "ehci_tegra",
+ .id = UCLASS_USB,
+ .of_match = ehci_usb_ids,
+ .of_to_plat = ehci_usb_of_to_plat,
+ .probe = tegra_ehci_usb_probe,
+ .remove = tegra_ehci_usb_remove,
+ .ops = &ehci_usb_ops,
+ .plat_auto = sizeof(struct usb_plat),
+ .priv_auto = sizeof(struct fdt_usb),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+ };
+
+Here ehci_usb_ids is used to list the controllers that the driver supports.
+Each has its own data value. Controllers must be in the UCLASS_USB uclass.
+
+The of_to_plat() method allows the controller driver to grab any
+necessary settings from the device tree.
+
+The ops here are ehci_usb_ops. All EHCI drivers will use these same ops in
+most cases, since they are all EHCI-compatible. For EHCI there are also some
+special operations that can be overridden when calling ehci_register().
+
+The driver can use priv_auto to set the size of its private data.
+This can hold run-time information needed by the driver for operation. It
+exists when the device is probed (not when it is bound) and is removed when
+the driver is removed.
+
+Note that usb_plat is currently only used to deal with setting up a bus
+in USB device mode (OTG operation). It can be omitted if that is not
+supported.
+
+The driver's probe() method should do the basic controller init and then
+call ehci_register() to register itself as an EHCI device. It should call
+ehci_deregister() in the remove() method. Registering a new EHCI device
+does not by itself cause the bus to be scanned.
+
+The old ehci_hcd_init() function is no-longer used. Nor is it necessary to
+set up the USB controllers from board init code. When 'usb start' is used,
+each controller will be probed and its bus scanned.
+
+XHCI works in a similar way.
+
+
+Data structures
+---------------
+
+The following primary data structures are in use:
+
+- struct usb_device:
+ This holds information about a device on the bus. All devices have
+ this structure, even the root hub. The controller itself does not
+ have this structure. You can access it for a device 'dev' with
+ dev_get_parent_priv(dev). It matches the old structure except that the
+ parent and child information is not present (since driver model
+ handles that). Once the device is set up, you can find the device
+ descriptor and current configuration descriptor in this structure.
+
+- struct usb_plat:
+ This holds platform data for a controller. So far this is only used
+ as a work-around for controllers which can act as USB devices in OTG
+ mode, since the gadget framework does not use driver model.
+
+- struct usb_dev_plat:
+ This holds platform data for a device. You can access it for a
+ device 'dev' with dev_get_parent_plat(dev). It holds the device
+ address and speed - anything that can be determined before the device
+ driver is actually set up. When probing the bus this structure is
+ used to provide essential information to the device driver.
+
+- struct usb_bus_priv:
+ This is private information for each controller, maintained by the
+ controller uclass. It is mostly used to keep track of the next
+ device address to use.
+
+Of these, only struct usb_device was used prior to driver model.
+
+
+USB buses
+---------
+
+Given a controller, you know the bus - it is the one attached to the
+controller. Each controller handles exactly one bus. Every controller has a
+root hub attached to it. This hub, which is itself a USB device, can provide
+one or more 'ports' to which additional devices can be attached. It is
+possible to power up a hub and find out which of its ports have devices
+attached.
+
+Devices are given addresses starting at 1. The root hub is always address 1,
+and from there the devices are numbered in sequence. The USB uclass takes
+care of this numbering automatically during enumeration.
+
+USB devices are enumerated by finding a device on a particular hub, and
+setting its address to the next available address. The USB bus stretches out
+in a tree structure, potentially with multiple hubs each with several ports
+and perhaps other hubs. Some hubs will have their own power since otherwise
+the 5V 500mA power supplied by the controller will not be sufficient to run
+very many devices.
+
+Enumeration in U-Boot takes a long time since devices are probed one at a
+time, and each is given sufficient time to wake up and announce itself. The
+timeouts are set for the slowest device.
+
+Up to 127 devices can be on each bus. USB has four bus speeds: low
+(1.5Mbps), full (12Mbps), high (480Mbps) which is only available with USB2
+and newer (EHCI), and super (5Gbps) which is only available with USB3 and
+newer (XHCI). If you connect a super-speed device to a high-speed hub, you
+will only get high-speed.
+
+
+USB operations
+--------------
+
+As before driver model, messages can be sent using submit_bulk_msg() and the
+like. These are now implemented by the USB uclass and route through the
+controller drivers. Note that messages are not sent to the driver of the
+device itself - i.e. they don't pass down the stack to the controller.
+U-Boot simply finds the controller to which the device is attached, and sends
+the message there with an appropriate 'pipe' value so it can be addressed
+properly. Having said that, the USB device which should receive the message
+is passed in to the driver methods, for use by sandbox. This design decision
+is open for review and the code impact of changing it is small since the
+methods are typically implemented by the EHCI and XHCI stacks.
+
+Controller drivers (in UCLASS_USB) themselves provide methods for sending
+each message type. For XHCI an additional alloc_device() method is provided
+since XHCI needs to allocate a device context before it can even read the
+device's descriptor.
+
+These methods use a 'pipe' which is a collection of bit fields used to
+describe the type of message, direction of transfer and the intended
+recipient (device number).
+
+
+USB Devices
+-----------
+
+USB devices are found using a simple algorithm which works through the
+available hubs in a depth-first search. Devices can be in any uclass, but
+are attached to a parent hub (or controller in the case of the root hub) and
+so have parent data attached to them (this is struct usb_device).
+
+By the time the device's probe() method is called, it is enumerated and is
+ready to talk to the host.
+
+The enumeration process needs to work out which driver to attach to each USB
+device. It does this by examining the device class, interface class, vendor
+ID, product ID, etc. See struct usb_driver_entry for how drivers are matched
+with USB devices - you can use the USB_DEVICE() macro to declare a USB
+driver. For example, usb_storage.c defines a USB_DEVICE() to handle storage
+devices, and it will be used for all USB devices which match.
+
+
+
+Technical details on enumeration flow
+-------------------------------------
+
+It is useful to understand precisely how a USB bus is enumerating to avoid
+confusion when dealing with USB devices.
+
+Device initialisation happens roughly like this:
+
+- At some point the 'usb start' command is run
+- This calls usb_init() which works through each controller in turn
+- The controller is probed(). This does no enumeration.
+- Then usb_scan_bus() is called. This calls usb_scan_device() to scan the
+ (only) device that is attached to the controller - a root hub
+- usb_scan_device() sets up a fake struct usb_device and calls
+ usb_setup_device(), passing the port number to be scanned, in this case
+ port 0
+- usb_setup_device() first calls usb_prepare_device() to set the device
+ address, then usb_select_config() to select the first configuration
+- at this point the device is enumerated but we do not have a real struct
+ udevice for it. But we do have the descriptor in struct usb_device so we can
+ use this to figure out what driver to use
+- back in usb_scan_device(), we call usb_find_child() to try to find an
+ existing device which matches the one we just found on the bus. This can
+ happen if the device is mentioned in the device tree, or if we previously
+ scanned the bus and so the device was created before
+- if usb_find_child() does not find an existing device, we call
+ usb_find_and_bind_driver() which tries to bind one
+- usb_find_and_bind_driver() searches all available USB drivers (declared
+ with USB_DEVICE()). If it finds a match it binds that driver to create a
+ new device.
+- If it does not, it binds a generic driver. A generic driver is good enough
+ to allow access to the device (sending it packets, etc.) but all
+ functionality will need to be implemented outside the driver model.
+- in any case, when usb_find_child() and/or usb_find_and_bind_driver() are
+ done, we have a device with the correct uclass. At this point we want to
+ probe the device
+- first we store basic information about the new device (address, port,
+ speed) in its parent platform data. We cannot store it its private data
+ since that will not exist until the device is probed.
+- then we call device_probe() which probes the device
+- the first probe step is actually the USB controller's (or USB hubs's)
+ child_pre_probe() method. This gets called before anything else and is
+ intended to set up a child device ready to be used with its parent bus. For
+ USB this calls usb_child_pre_probe() which grabs the information that was
+ stored in the parent platform data and stores it in the parent private data
+ (which is struct usb_device, a real one this time). It then calls
+ usb_select_config() again to make sure that everything about the device is
+ set up
+- note that we have called usb_select_config() twice. This is inefficient
+ but the alternative is to store additional information in the platform data.
+ The time taken is minimal and this way is simpler
+- at this point the device is set up and ready for use so far as the USB
+ subsystem is concerned
+- the device's probe() method is then called. It can send messages and do
+ whatever else it wants to make the device work.
+
+Note that the first device is always a root hub, and this must be scanned to
+find any devices. The above steps will have created a hub (UCLASS_USB_HUB),
+given it address 1 and set the configuration.
+
+For hubs, the hub uclass has a post_probe() method. This means that after
+any hub is probed, the uclass gets to do some processing. In this case
+usb_hub_post_probe() is called, and the following steps take place:
+
+- usb_hub_post_probe() calls usb_hub_scan() to scan the hub, which in turn
+ calls usb_hub_configure()
+- hub power is enabled
+- we loop through each port on the hub, performing the same steps for each
+- first, check if there is a device present. This happens in
+ usb_hub_port_connect_change(). If so, then usb_scan_device() is called to
+ scan the device, passing the appropriate port number.
+- you will recognise usb_scan_device() from the steps above. It sets up the
+ device ready for use. If it is a hub, it will scan that hub before it
+ continues here (recursively, depth-first)
+- once all hub ports are scanned in this way, the hub is ready for use and
+ all of its downstream devices also
+- additional controllers are scanned in the same way
+
+The above method has some nice properties:
+
+- the bus enumeration happens by virtue of driver model's natural device flow
+- most logic is in the USB controller and hub uclasses; the actual device
+ drivers do not need to know they are on a USB bus, at least so far as
+ enumeration goes
+- hub scanning happens automatically after a hub is probed
+
+
+Hubs
+----
+
+USB hubs are scanned as in the section above. While hubs have their own
+uclass, they share some common elements with controllers:
+
+- they both attach private data to their children (struct usb_device,
+ accessible for a child with dev_get_parent_priv(child))
+- they both use usb_child_pre_probe() to set up their children as proper USB
+ devices
+
+
+Example - Mass Storage
+----------------------
+
+As an example of a USB device driver, see usb_storage.c. It uses its own
+uclass and declares itself as follows:
+
+.. code-block:: c
+
+ U_BOOT_DRIVER(usb_mass_storage) = {
+ .name = "usb_mass_storage",
+ .id = UCLASS_MASS_STORAGE,
+ .of_match = usb_mass_storage_ids,
+ .probe = usb_mass_storage_probe,
+ };
+
+ static const struct usb_device_id mass_storage_id_table[] = {
+ { .match_flags = USB_DEVICE_ID_MATCH_INT_CLASS,
+ .bInterfaceClass = USB_CLASS_MASS_STORAGE},
+ { } /* Terminating entry */
+ };
+
+ USB_DEVICE(usb_mass_storage, mass_storage_id_table);
+
+The USB_DEVICE() macro attaches the given table of matching information to
+the given driver. Note that the driver is declared in U_BOOT_DRIVER() as
+'usb_mass_storage' and this must match the first parameter of USB_DEVICE.
+
+When usb_find_and_bind_driver() is called on a USB device with the
+bInterfaceClass value of USB_CLASS_MASS_STORAGE, it will automatically find
+this driver and use it.
+
+
+Counter-example: USB Ethernet
+-----------------------------
+
+As an example of the old way of doing things, see usb_ether.c. When the bus
+is scanned, all Ethernet devices will be created as generic USB devices (in
+uclass UCLASS_USB_DEV_GENERIC). Then, when the scan is completed,
+usb_host_eth_scan() will be called. This looks through all the devices on
+each bus and manually figures out which are Ethernet devices in the ways of
+yore.
+
+In fact, usb_ether should be moved to driver model. Each USB Ethernet driver
+(e.g drivers/usb/eth/asix.c) should include a USB_DEVICE() declaration, so
+that it will be found as part of normal USB enumeration. Then, instead of a
+generic USB driver, a real (driver-model-aware) driver will be used. Since
+Ethernet now supports driver model, this should be fairly easy to achieve,
+and then usb_ether.c and the usb_host_eth_scan() will melt away.
+
+
+Sandbox
+-------
+
+All driver model uclasses must have tests and USB is no exception. To
+achieve this, a sandbox USB controller is provided. This can make use of
+emulation drivers which pretend to be USB devices. Emulations are provided
+for a hub and a flash stick. These are enough to create a pretend USB bus
+(defined by the sandbox device tree sandbox.dts) which can be scanned and
+used.
+
+Tests in test/dm/usb.c make use of this feature. It allows much of the USB
+stack to be tested without real hardware being needed.
+
+Here is an example device tree fragment:
+
+.. code-block:: none
+
+ usb@1 {
+ compatible = "sandbox,usb";
+ hub {
+ compatible = "usb-hub";
+ usb,device-class = <USB_CLASS_HUB>;
+ hub-emul {
+ compatible = "sandbox,usb-hub";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ flash-stick {
+ reg = <0>;
+ compatible = "sandbox,usb-flash";
+ sandbox,filepath = "flash.bin";
+ };
+ };
+ };
+ };
+
+This defines a single controller, containing a root hub (which is required).
+The hub is emulated by a hub emulator, and the emulated hub has a single
+flash stick to emulate on one of its ports.
+
+When 'usb start' is used, the following 'dm tree' output will be available::
+
+ usb [ + ] `-- usb@1
+ usb_hub [ + ] `-- hub
+ usb_emul [ + ] |-- hub-emul
+ usb_emul [ + ] | `-- flash-stick
+ usb_mass_st [ + ] `-- usb_mass_storage
+
+
+This may look confusing. Most of it mirrors the device tree, but the
+'usb_mass_storage' device is not in the device tree. This is created by
+usb_find_and_bind_driver() based on the USB_DRIVER in usb_storage.c. While
+'flash-stick' is the emulation device, 'usb_mass_storage' is the real U-Boot
+USB device driver that talks to it.
+
+
+Future work
+-----------
+
+It is pretty uncommon to have a large USB bus with lots of hubs on an
+embedded system. In fact anything other than a root hub is uncommon. Still
+it would be possible to speed up enumeration in two ways:
+
+- breadth-first search would allow devices to be reset and probed in
+ parallel to some extent
+- enumeration could be lazy, in the sense that we could enumerate just the
+ root hub at first, then only progress to the next 'level' when a device is
+ used that we cannot find. This could be made easier if the devices were
+ statically declared in the device tree (which is acceptable for production
+ boards where the same, known, things are on each bus).
+
+But in common cases the current algorithm is sufficient.
+
+Other things that need doing:
+- Convert usb_ether to use driver model as described above
+- Test that keyboards work (and convert to driver model)
+- Move the USB gadget framework to driver model
+- Implement OHCI in driver model
+- Implement USB PHYs in driver model
+- Work out a clever way to provide lazy init for USB devices
+
+
+.. Simon Glass <sjg@chromium.org>
+.. 23-Mar-15
diff --git a/roms/u-boot/doc/develop/driver-model/virtio.rst b/roms/u-boot/doc/develop/driver-model/virtio.rst
new file mode 100644
index 000000000..8ac9c94ca
--- /dev/null
+++ b/roms/u-boot/doc/develop/driver-model/virtio.rst
@@ -0,0 +1,287 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+VirtIO Support
+==============
+
+This document describes the information about U-Boot support for VirtIO_
+devices, including supported boards, build instructions, driver details etc.
+
+What's VirtIO?
+--------------
+VirtIO is a virtualization standard for network and disk device drivers where
+just the guest's device driver "knows" it is running in a virtual environment,
+and cooperates with the hypervisor. This enables guests to get high performance
+network and disk operations, and gives most of the performance benefits of
+paravirtualization. In the U-Boot case, the guest is U-Boot itself, while the
+virtual environment are normally QEMU_ targets like ARM, RISC-V and x86.
+
+Status
+------
+VirtIO can use various different buses, aka transports as described in the
+spec. While VirtIO devices are commonly implemented as PCI devices on x86,
+embedded devices models like ARM/RISC-V, which does not normally come with
+PCI support might use simple memory mapped device (MMIO) instead of the PCI
+device. The memory mapped virtio device behaviour is based on the PCI device
+specification. Therefore most operations including device initialization,
+queues configuration and buffer transfers are nearly identical. Both MMIO
+and PCI transport options are supported in U-Boot.
+
+The VirtIO spec defines a lots of VirtIO device types, however at present only
+network and block device, the most two commonly used devices, are supported.
+
+The following QEMU targets are supported.
+
+ - qemu_arm_defconfig
+ - qemu_arm64_defconfig
+ - qemu-riscv32_defconfig
+ - qemu-riscv64_defconfig
+ - qemu-x86_defconfig
+ - qemu-x86_64_defconfig
+
+Note ARM and RISC-V targets are configured with VirtIO MMIO transport driver,
+and on x86 it's the PCI transport driver.
+
+Build Instructions
+------------------
+Building U-Boot for pre-configured QEMU targets is no different from others.
+For example, we can do the following with the CROSS_COMPILE environment
+variable being properly set to a working toolchain for ARM:
+
+.. code-block:: bash
+
+ $ make qemu_arm_defconfig
+ $ make
+
+You can even create a QEMU ARM target with VirtIO devices showing up on both
+MMIO and PCI buses. In this case, you can enable the PCI transport driver
+from 'make menuconfig':
+
+.. code-block:: none
+
+ Device Drivers --->
+ ...
+ VirtIO Drivers --->
+ ...
+ [*] PCI driver for virtio devices
+
+Other drivers are at the same location and can be tuned to suit the needs.
+
+Requirements
+------------
+It is required that QEMU v2.5.0+ should be used to test U-Boot VirtIO support
+on QEMU ARM and x86, and v2.12.0+ on QEMU RISC-V.
+
+Testing
+-------
+The following QEMU command line is used to get U-Boot up and running with
+VirtIO net and block devices on ARM.
+
+.. code-block:: bash
+
+ $ qemu-system-arm -nographic -machine virt -bios u-boot.bin \
+ -netdev tap,ifname=tap0,id=net0 \
+ -device virtio-net-device,netdev=net0 \
+ -drive if=none,file=test.img,format=raw,id=hd0 \
+ -device virtio-blk-device,drive=hd0
+
+On x86, command is slightly different to create PCI VirtIO devices.
+
+.. code-block:: bash
+
+ $ qemu-system-i386 -nographic -bios u-boot.rom \
+ -netdev tap,ifname=tap0,id=net0 \
+ -device virtio-net-pci,netdev=net0 \
+ -drive if=none,file=test.img,format=raw,id=hd0 \
+ -device virtio-blk-pci,drive=hd0
+
+Additional net and block devices can be created by appending more '-device'
+parameters. It is also possible to specify both MMIO and PCI VirtIO devices.
+For example, the following commnad creates 3 VirtIO devices, with 1 on MMIO
+and 2 on PCI bus.
+
+.. code-block:: bash
+
+ $ qemu-system-arm -nographic -machine virt -bios u-boot.bin \
+ -netdev tap,ifname=tap0,id=net0 \
+ -device virtio-net-pci,netdev=net0 \
+ -drive if=none,file=test0.img,format=raw,id=hd0 \
+ -device virtio-blk-device,drive=hd0 \
+ -drive if=none,file=test1.img,format=raw,id=hd1 \
+ -device virtio-blk-pci,drive=hd1
+
+By default QEMU creates VirtIO legacy devices by default. To create non-legacy
+(aka modern) devices, pass additional device property/value pairs like below:
+
+.. code-block:: bash
+
+ $ qemu-system-i386 -nographic -bios u-boot.rom \
+ -netdev tap,ifname=tap0,id=net0 \
+ -device virtio-net-pci,netdev=net0,disable-legacy=true,disable-modern=false \
+ -drive if=none,file=test.img,format=raw,id=hd0 \
+ -device virtio-blk-pci,drive=hd0,disable-legacy=true,disable-modern=false
+
+A 'virtio' command is provided in U-Boot shell.
+
+.. code-block:: none
+
+ => virtio
+ virtio - virtio block devices sub-system
+
+ Usage:
+ virtio scan - initialize virtio bus
+ virtio info - show all available virtio block devices
+ virtio device [dev] - show or set current virtio block device
+ virtio part [dev] - print partition table of one or all virtio block devices
+ virtio read addr blk# cnt - read `cnt' blocks starting at block
+ `blk#' to memory address `addr'
+ virtio write addr blk# cnt - write `cnt' blocks starting at block
+ `blk#' from memory address `addr'
+
+To probe all the VirtIO devices, type:
+
+.. code-block:: none
+
+ => virtio scan
+
+Then we can show the connected block device details by:
+
+.. code-block:: none
+
+ => virtio info
+ Device 0: QEMU VirtIO Block Device
+ Type: Hard Disk
+ Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
+
+And list the directories and files on the disk by:
+
+.. code-block:: none
+
+ => ls virtio 0 /
+ <DIR> 4096 .
+ <DIR> 4096 ..
+ <DIR> 16384 lost+found
+ <DIR> 4096 dev
+ <DIR> 4096 proc
+ <DIR> 4096 sys
+ <DIR> 4096 var
+ <DIR> 4096 etc
+ <DIR> 4096 usr
+ <SYM> 7 bin
+ <SYM> 8 sbin
+ <SYM> 7 lib
+ <SYM> 9 lib64
+ <DIR> 4096 run
+ <DIR> 4096 boot
+ <DIR> 4096 home
+ <DIR> 4096 media
+ <DIR> 4096 mnt
+ <DIR> 4096 opt
+ <DIR> 4096 root
+ <DIR> 4096 srv
+ <DIR> 4096 tmp
+ 0 .autorelabel
+
+Driver Internals
+----------------
+There are 3 level of drivers in the VirtIO driver family.
+
+.. code-block:: none
+
+ +---------------------------------------+
+ | virtio device drivers |
+ | +-------------+ +------------+ |
+ | | virtio-net | | virtio-blk | |
+ | +-------------+ +------------+ |
+ +---------------------------------------+
+ +---------------------------------------+
+ | virtio transport drivers |
+ | +-------------+ +------------+ |
+ | | virtio-mmio | | virtio-pci | |
+ | +-------------+ +------------+ |
+ +---------------------------------------+
+ +----------------------+
+ | virtio uclass driver |
+ +----------------------+
+
+The root one is the virtio uclass driver (virtio-uclass.c), which does lots of
+common stuff for the transport drivers (virtio_mmio.c, virtio_pci.c). The real
+virtio device is discovered in the transport driver's probe() method, and its
+device ID is saved in the virtio uclass's private data of the transport device.
+Then in the virtio uclass's post_probe() method, the real virtio device driver
+(virtio_net.c, virtio_blk.c) is bound if there is a match on the device ID.
+
+The child_post_bind(), child_pre_probe() and child_post_probe() methods of the
+virtio uclass driver help bring the virtio device driver online. They do things
+like acknowledging device, feature negotiation, etc, which are really common
+for all virtio devices.
+
+The transport drivers provide a set of ops (struct dm_virtio_ops) for the real
+virtio device driver to call. These ops APIs's parameter is designed to remind
+the caller to pass the correct 'struct udevice' id of the virtio device, eg:
+
+.. code-block:: C
+
+ int virtio_get_status(struct udevice *vdev, u8 *status)
+
+So the parameter 'vdev' indicates the device should be the real virtio device.
+But we also have an API like:
+
+.. code-block:: C
+
+ struct virtqueue *vring_create_virtqueue(unsigned int index, unsigned int num,
+ unsigned int vring_align,
+ struct udevice *udev)
+
+Here the parameter 'udev' indicates the device should be the transport device.
+Similar naming is applied in other functions that are even not APIs, eg:
+
+.. code-block:: C
+
+ static int virtio_uclass_post_probe(struct udevice *udev)
+ static int virtio_uclass_child_pre_probe(struct udevice *vdev)
+
+So it's easy to tell which device these functions are operating on.
+
+Development Flow
+----------------
+At present only VirtIO network card (device ID 1) and block device (device
+ID 2) are supported. If you want to develop new driver for new devices,
+please follow the guideline below.
+
+1. add new device ID in virtio.h
+
+.. code-block:: C
+
+ #define VIRTIO_ID_XXX X
+
+2. update VIRTIO_ID_MAX_NUM to be the largest device ID plus 1
+
+3. add new driver name string in virtio.h
+
+.. code-block:: C
+
+ #define VIRTIO_XXX_DRV_NAME "virtio-xxx"
+
+4. create a new driver with name set to the name string above
+
+.. code-block:: C
+
+ U_BOOT_DRIVER(virtio_xxx) = {
+ .name = VIRTIO_XXX_DRV_NAME,
+ ...
+ .remove = virtio_reset,
+ .flags = DM_FLAG_ACTIVE_DMA,
+ }
+
+Note the driver needs to provide the remove method and normally this can be
+hooked to virtio_reset(). The driver flags should contain DM_FLAG_ACTIVE_DMA
+for the remove method to be called before jumping to OS.
+
+5. provide bind() method in the driver, where virtio_driver_features_init()
+ should be called for driver to negotiate feature support with the device.
+
+6. do funny stuff with the driver
+
+.. _VirtIO: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
+.. _QEMU: https://www.qemu.org
diff --git a/roms/u-boot/doc/develop/global_data.rst b/roms/u-boot/doc/develop/global_data.rst
new file mode 100644
index 000000000..230ebcd86
--- /dev/null
+++ b/roms/u-boot/doc/develop/global_data.rst
@@ -0,0 +1,55 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Global data
+===========
+
+Globally required fields are held in the global data structure. A pointer to the
+structure is available as symbol gd. The symbol is made available by the macro
+%DECLARE_GLOBAL_DATA_PTR.
+
+Register pointing to global data
+--------------------------------
+
+On most architectures the global data pointer is stored in a register.
+
++------------+----------+
+| ARC | r25 |
++------------+----------+
+| ARM 32bit | r9 |
++------------+----------+
+| ARM 64bit | x18 |
++------------+----------+
+| M68000 | d7 |
++------------+----------+
+| MicroBlaze | r31 |
++------------+----------+
+| NDS32 | r10 |
++------------+----------+
+| Nios II | gp |
++------------+----------+
+| PowerPC | r2 |
++------------+----------+
+| RISC-V | gp (x3) |
++------------+----------+
+| SuperH | r13 |
++------------+----------+
+| x86 32bit | fs |
++------------+----------+
+
+The sandbox, x86_64, and Xtensa are notable exceptions.
+
+Clang for ARM does not support assigning a global register. When using Clang
+gd is defined as an inline function using assembly code. This adds a few bytes
+to the code size.
+
+Binaries called by U-Boot are not aware of the register usage and will not
+conserve gd. UEFI binaries call the API provided by U-Boot and may return to
+U-Boot. The value of gd has to be saved every time U-Boot is left and restored
+whenever U-Boot is reentered. This is also relevant for the implementation of
+function tracing. For setting the value of gd function set_gd() can be used.
+
+Global data structure
+---------------------
+
+.. kernel-doc:: include/asm-generic/global_data.h
+ :internal:
diff --git a/roms/u-boot/doc/develop/index.rst b/roms/u-boot/doc/develop/index.rst
new file mode 100644
index 000000000..3edffbc63
--- /dev/null
+++ b/roms/u-boot/doc/develop/index.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Develop U-Boot
+==============
+
+Implementation
+--------------
+
+.. toctree::
+ :maxdepth: 1
+
+ commands
+ driver-model/index
+ global_data
+ logging
+ menus
+ uefi/index
+ version
+
+Debugging
+---------
+
+.. toctree::
+ :maxdepth: 1
+
+ crash_dumps
+ trace
+
+Packaging
+---------
+
+.. toctree::
+ :maxdepth: 1
+
+ package/index
+
+Testing
+-------
+
+.. toctree::
+ :maxdepth: 1
+
+ coccinelle
+ testing
+ py_testing
+ tests_writing
+ tests_sandbox
diff --git a/roms/u-boot/doc/develop/logging.rst b/roms/u-boot/doc/develop/logging.rst
new file mode 100644
index 000000000..f4e925048
--- /dev/null
+++ b/roms/u-boot/doc/develop/logging.rst
@@ -0,0 +1,319 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2017 Simon Glass <sjg@chromium.org>
+
+Logging in U-Boot
+=================
+
+Introduction
+------------
+
+U-Boot's internal operation involves many different steps and actions. From
+setting up the board to displaying a start-up screen to loading an Operating
+System, there are many component parts each with many actions.
+
+Most of the time this internal detail is not useful. Displaying it on the
+console would delay booting (U-Boot's primary purpose) and confuse users.
+
+But for digging into what is happening in a particular area, or for debugging
+a problem it is often useful to see what U-Boot is doing in more detail than
+is visible from the basic console output.
+
+U-Boot's logging feature aims to satisfy this goal for both users and
+developers.
+
+Logging levels
+--------------
+
+There are a number logging levels available.
+
+See enum :c:type:`log_level_t`
+
+Logging category
+----------------
+
+Logging can come from a wide variety of places within U-Boot. Each log message
+has a category which is intended to allow messages to be filtered according to
+their source.
+
+See enum :c:type:`log_category_t`
+
+Enabling logging
+----------------
+
+The following options are used to enable logging at compile time:
+
+* CONFIG_LOG - Enables the logging system
+* CONFIG_LOG_MAX_LEVEL - Max log level to build (anything higher is compiled
+ out)
+* CONFIG_LOG_CONSOLE - Enable writing log records to the console
+
+If CONFIG_LOG is not set, then no logging will be available.
+
+The above have SPL and TPL versions also, e.g. CONFIG_SPL_LOG_MAX_LEVEL and
+CONFIG_TPL_LOG_MAX_LEVEL.
+
+Temporary logging within a single file
+--------------------------------------
+
+Sometimes it is useful to turn on logging just in one file. You can use this
+
+.. code-block:: c
+
+ #define LOG_DEBUG
+
+to enable building in of all logging statements in a single file. Put it at
+the top of the file, before any #includes.
+
+To actually get U-Boot to output this you need to also set the default logging
+level - e.g. set CONFIG_LOG_DEFAULT_LEVEL to 7 (:c:data:`LOGL_DEBUG`) or more.
+Otherwise debug output is suppressed and will not be generated.
+
+Using DEBUG
+-----------
+
+U-Boot has traditionally used a #define called DEBUG to enable debugging on a
+file-by-file basis. The debug() macro compiles to a printf() statement if
+DEBUG is enabled, and an empty statement if not.
+
+With logging enabled, debug() statements are interpreted as logging output
+with a level of LOGL_DEBUG and a category of LOGC_NONE.
+
+The logging facilities are intended to replace DEBUG, but if DEBUG is defined
+at the top of a file, then it takes precedence. This means that debug()
+statements will result in output to the console and this output will not be
+logged.
+
+Logging statements
+------------------
+
+The main logging function is:
+
+.. code-block:: c
+
+ log(category, level, format_string, ...)
+
+Also debug() and error() will generate log records - these use LOG_CATEGORY
+as the category, so you should #define this right at the top of the source
+file to ensure the category is correct.
+
+Generally each log format_string ends with a newline. If it does not, then the
+next log statement will have the LOGRECF_CONT flag set. This can be used to
+continue the statement on the same line as the previous one without emitting
+new header information (such as category/level). This behaviour is implemented
+with log_console. Here is an example that prints a list all on one line with
+the tags at the start:
+
+.. code-block:: c
+
+ log_debug("Here is a list:");
+ for (i = 0; i < count; i++)
+ log_debug(" item %d", i);
+ log_debug("\n");
+
+Also see the special category LOGL_CONT and level LOGC_CONT.
+
+You can also define CONFIG_LOG_ERROR_RETURN to enable the log_ret() macro. This
+can be used whenever your function returns an error value:
+
+.. code-block:: c
+
+ return log_ret(uclass_first_device_err(UCLASS_MMC, &dev));
+
+This will write a log record when an error code is detected (a value < 0). This
+can make it easier to trace errors that are generated deep in the call stack.
+
+The log_msg_ret() variant will print a short string if CONFIG_LOG_ERROR_RETURN
+is enabled. So long as the string is unique within the function you can normally
+determine exactly which call failed:
+
+.. code-block:: c
+
+ ret = gpio_request_by_name(dev, "cd-gpios", 0, &desc, GPIOD_IS_IN);
+ if (ret)
+ return log_msg_ret("gpio", ret);
+
+Some functions return 0 for success and any other value is an error. For these,
+log_retz() and log_msg_retz() are available.
+
+Convenience functions
+~~~~~~~~~~~~~~~~~~~~~
+
+A number of convenience functions are available to shorten the code needed
+for logging:
+
+* log_err(_fmt...)
+* log_warning(_fmt...)
+* log_notice(_fmt...)
+* log_info(_fmt...)
+* log_debug(_fmt...)
+* log_content(_fmt...)
+* log_io(_fmt...)
+
+With these the log level is implicit in the name. The category is set by
+LOG_CATEGORY, which you can only define once per file, above all #includes, e.g.
+
+.. code-block:: c
+
+ #define LOG_CATEGORY LOGC_ALLOC
+
+or
+
+.. code-block:: c
+
+ #define LOG_CATEGORY UCLASS_SPI
+
+Remember that all uclasses IDs are log categories too.
+
+Logging destinations
+--------------------
+
+If logging information goes nowhere then it serves no purpose. U-Boot provides
+several possible determinations for logging information, all of which can be
+enabled or disabled independently:
+
+* console - goes to stdout
+* syslog - broadcast RFC 3164 messages to syslog servers on UDP port 514
+
+The syslog driver sends the value of environmental variable 'log_hostname' as
+HOSTNAME if available.
+
+Filters
+-------
+
+Filters are attached to log drivers to control what those drivers emit. FIlters
+can either allow or deny a log message when they match it. Only records which
+are allowed by a filter make it to the driver.
+
+Filters can be based on several criteria:
+
+* minimum or maximum log level
+* in a set of categories
+* in a set of files
+
+If no filters are attached to a driver then a default filter is used, which
+limits output to records with a level less than CONFIG_MAX_LOG_LEVEL.
+
+Log command
+-----------
+
+The 'log' command provides access to several features:
+
+* level - list log levels or set the default log level
+* categories - list log categories
+* drivers - list log drivers
+* filter-list - list filters
+* filter-add - add a new filter
+* filter-remove - remove filters
+* format - access the console log format
+* rec - output a log record
+
+Type 'help log' for details.
+
+Log format
+~~~~~~~~~~
+
+You can control the log format using the 'log format' command. The basic
+format is::
+
+ LEVEL.category,file.c:123-func() message
+
+In the above, file.c:123 is the filename where the log record was generated and
+func() is the function name. By default ('log format default') only the message
+is displayed on the console. You can control which fields are present, but not
+the field order.
+
+Adding Filters
+~~~~~~~~~~~~~~
+
+To add new filters at runtime, use the 'log filter-add' command. For example, to
+suppress messages from the SPI and MMC subsystems, run::
+
+ log filter-add -D -c spi -c mmc
+
+You will also need to add another filter to allow other messages (because the
+default filter no longer applies)::
+
+ log filter-add -A -l info
+
+Log levels may be either symbolic names (like above) or numbers. For example, to
+disable all debug and above (log level 7) messages from ``drivers/core/lists.c``
+and ``drivers/core/ofnode.c``, run::
+
+ log filter-add -D -f drivers/core/lists.c,drivers/core/ofnode.c -L 7
+
+To view active filters, use the 'log filter-list' command. Some example output
+is::
+
+ => log filter-list
+ num policy level categories files
+ 2 deny >= DEBUG drivers/core/lists.c,drivers/core/ofnode.c
+ 0 deny <= IO spi
+ mmc
+ 1 allow <= INFO
+
+Note that filters are processed in-order from top to bottom, not in the order of
+their filter number. Filters are added to the top of the list if they deny when
+they match, and to the bottom if they allow when they match. For more
+information, consult the usage of the 'log' command, by running 'help log'.
+
+Code size
+---------
+
+Code size impact depends largely on what is enabled. The following numbers are
+generated by 'buildman -S' for snow, which is a Thumb-2 board (all units in
+bytes)::
+
+ This series: adds bss +20.0 data +4.0 rodata +4.0 text +44.0
+ CONFIG_LOG: bss -52.0 data +92.0 rodata -635.0 text +1048.0
+ CONFIG_LOG_MAX_LEVEL=7: bss +188.0 data +4.0 rodata +49183.0 text +98124.0
+
+The last option turns every debug() statement into a logging call, which
+bloats the code hugely. The advantage is that it is then possible to enable
+all logging within U-Boot.
+
+To Do
+-----
+
+There are lots of useful additions that could be made. None of the below is
+implemented! If you do one, please add a test in test/log/log_test.c
+log filter-add -D -f drivers/core/lists.c,drivers/core/ofnode.c -l 6
+Convenience functions to support setting the category:
+
+* log_arch(level, format_string, ...) - category LOGC_ARCH
+* log_board(level, format_string, ...) - category LOGC_BOARD
+* log_core(level, format_string, ...) - category LOGC_CORE
+* log_dt(level, format_string, ...) - category LOGC_DT
+
+More logging destinations:
+
+* device - goes to a device (e.g. serial)
+* buffer - recorded in a memory buffer
+
+Convert debug() statements in the code to log() statements
+
+Support making printf() emit log statements at L_INFO level
+
+Convert error() statements in the code to log() statements
+
+Figure out what to do with BUG(), BUG_ON() and warn_non_spl()
+
+Add a way to browse log records
+
+Add a way to record log records for browsing using an external tool
+
+Add commands to add and remove log devices
+
+Allow sharing of printf format strings in log records to reduce storage size
+for large numbers of log records
+
+Consider making log() calls emit an automatic newline, perhaps with a logn()
+function to avoid that
+
+Passing log records through to linux (e.g. via device tree /chosen)
+
+Provide a command to access the number of log records generated, and the
+number dropped due to them being generated before the log system was ready.
+
+Add a printf() format string pragma so that log statements are checked properly
+
+Add a command to delete existing log records.
diff --git a/roms/u-boot/doc/develop/menus.rst b/roms/u-boot/doc/develop/menus.rst
new file mode 100644
index 000000000..dda8f963f
--- /dev/null
+++ b/roms/u-boot/doc/develop/menus.rst
@@ -0,0 +1,131 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2010-2011 Calxeda, Inc.
+
+Menus
+=====
+
+U-Boot provides a set of interfaces for creating and using simple, text
+based menus. Menus are displayed as lists of labeled entries on the
+console, and an entry can be selected by entering its label.
+
+To use the menu code, enable CONFIG_MENU, and include "menu.h" where
+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_AUTOBOOT_MENU_SHOW. You have to code the int menu_show(int bootdelay)
+function, which handle your menu. This function returns the remaining
+bootdelay.
+
+Interfaces
+----------
+
+.. code-block:: c
+
+ #include "menu.h"
+
+ /*
+ * Consumers of the menu interfaces will use a struct menu * as the
+ * handle for a menu. struct menu is only fully defined in menu.c,
+ * preventing consumers of the menu interfaces from accessing its
+ * contents directly.
+ */
+ struct menu;
+
+ /*
+ * NOTE: See comments in common/menu.c for more detailed documentation on
+ * these interfaces.
+ */
+
+ /*
+ * menu_create() - Creates a menu handle with default settings
+ */
+ struct menu *menu_create(char *title, int timeout, int prompt,
+ void (*item_data_print)(void *),
+ char *(*item_choice)(void *),
+ void *item_choice_data);
+
+ /*
+ * menu_item_add() - Adds or replaces a menu item
+ */
+ int menu_item_add(struct menu *m, char *item_key, void *item_data);
+
+ /*
+ * menu_default_set() - Sets the default choice for the menu
+ */
+ int menu_default_set(struct menu *m, char *item_key);
+
+ /*
+ * menu_default_choice() - Set *choice to point to the default item's data
+ */
+ int menu_default_choice(struct menu *m, void **choice);
+
+ /*
+ * menu_get_choice() - Returns the user's selected menu entry, or the
+ * default if the menu is set to not prompt or the timeout expires.
+ */
+ int menu_get_choice(struct menu *m, void **choice);
+
+ /*
+ * menu_destroy() - frees the memory used by a menu and its items.
+ */
+ 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
+------------
+
+This example creates a menu that always prompts, and allows the user
+to pick from a list of tools. The item key and data are the same.
+
+.. code-block:: c
+
+ #include "menu.h"
+
+ char *tools[] = {
+ "Hammer",
+ "Screwdriver",
+ "Nail gun",
+ NULL
+ };
+
+ char *pick_a_tool(void)
+ {
+ struct menu *m;
+ int i;
+ char *tool = NULL;
+
+ m = menu_create("Tools", 0, 1, NULL);
+
+ for(i = 0; tools[i]; i++) {
+ if (menu_item_add(m, tools[i], tools[i]) != 1) {
+ printf("failed to add item!");
+ menu_destroy(m);
+ return NULL;
+ }
+ }
+
+ if (menu_get_choice(m, (void **)&tool) != 1)
+ printf("Problem picking tool!\n");
+
+ menu_destroy(m);
+
+ return tool;
+ }
+
+ void caller(void)
+ {
+ char *tool = pick_a_tool();
+
+ if (tool) {
+ printf("picked a tool: %s\n", tool);
+ use_tool(tool);
+ }
+ }
diff --git a/roms/u-boot/doc/develop/package/binman.rst b/roms/u-boot/doc/develop/package/binman.rst
new file mode 120000
index 000000000..2e26e84b7
--- /dev/null
+++ b/roms/u-boot/doc/develop/package/binman.rst
@@ -0,0 +1 @@
+../../../tools/binman/binman.rst \ No newline at end of file
diff --git a/roms/u-boot/doc/develop/package/entries.rst b/roms/u-boot/doc/develop/package/entries.rst
new file mode 120000
index 000000000..ecedcebaa
--- /dev/null
+++ b/roms/u-boot/doc/develop/package/entries.rst
@@ -0,0 +1 @@
+../../../tools/binman/entries.rst \ No newline at end of file
diff --git a/roms/u-boot/doc/develop/package/index.rst b/roms/u-boot/doc/develop/package/index.rst
new file mode 100644
index 000000000..9374be2e6
--- /dev/null
+++ b/roms/u-boot/doc/develop/package/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Package U-Boot
+==============
+
+U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
+images that it it reads and boots. Documentation about FIT is available at
+doc/uImage.FIT
+
+U-Boot also provides binman for cases not covered by FIT. Examples include
+initial execution (since FIT itself does not have an executable header) and
+dealing with device boundaries, such as the read-only/read-write separation in
+SPI flash.
+
+
+.. toctree::
+ :maxdepth: 2
+
+ binman
diff --git a/roms/u-boot/doc/develop/py_testing.rst b/roms/u-boot/doc/develop/py_testing.rst
new file mode 100644
index 000000000..c4cecc0a0
--- /dev/null
+++ b/roms/u-boot/doc/develop/py_testing.rst
@@ -0,0 +1,427 @@
+U-Boot pytest suite
+===================
+
+Introduction
+------------
+
+This tool aims to test U-Boot by executing U-Boot shell commands using the
+console interface. A single top-level script exists to execute or attach to the
+U-Boot console, run the entire script of tests against it, and summarize the
+results. Advantages of this approach are:
+
+- Testing is performed in the same way a user or script would interact with
+ U-Boot; there can be no disconnect.
+- There is no need to write or embed test-related code into U-Boot itself.
+ It is asserted that writing test-related code in Python is simpler and more
+ flexible than writing it all in C. But see :doc:`tests_writing` for caveats
+ and more discussion / analysis.
+- It is reasonably simple to interact with U-Boot in this way.
+
+Requirements
+------------
+
+The test suite is implemented using pytest. Interaction with the U-Boot console
+involves executing some binary and interacting with its stdin/stdout. You will
+need to implement various "hook" scripts that are called by the test suite at
+the appropriate time.
+
+In order to run the test suite at a minimum we require that both Python 3 and
+pip for Python 3 are installed. All of the required python modules are
+described in the requirements.txt file in the /test/py/ directory and can be
+installed via the command
+
+.. code-block:: bash
+
+ pip install -r requirements.txt
+
+In order to execute certain tests on their supported platforms other tools
+will be required. The following is an incomplete list:
+
+* gdisk
+* dfu-util
+* dtc
+* openssl
+* sudo OR guestmount
+* e2fsprogs
+* util-linux
+* coreutils
+* dosfstools
+* efitools
+* mount
+* mtools
+* sbsigntool
+* udisks2
+
+Please use the appropriate commands for your distribution to match these tools
+up with the package that provides them.
+
+The test script supports either:
+
+- Executing a sandbox port of U-Boot on the local machine as a sub-process,
+ and interacting with it over stdin/stdout.
+- Executing an external "hook" scripts to flash a U-Boot binary onto a
+ physical board, attach to the board's console stream, and reset the board.
+ Further details are described later.
+
+Using `virtualenv` to provide requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The recommended way to run the test suite, in order to ensure reproducibility
+is to use `virtualenv` to set up the necessary environment. This can be done
+via the following commands:
+
+
+.. code-block:: console
+
+ $ cd /path/to/u-boot
+ $ sudo apt-get install python3 python3-virtualenv
+ $ virtualenv -p /usr/bin/python3 venv
+ $ . ./venv/bin/activate
+ $ pip install -r test/py/requirements.txt
+
+Testing sandbox
+---------------
+
+To run the test suite on the sandbox port (U-Boot built as a native user-space
+application), simply execute:
+
+.. code-block:: bash
+
+ ./test/py/test.py --bd sandbox --build
+
+The `--bd` option tells the test suite which board type is being tested. This
+lets the test suite know which features the board has, and hence exactly what
+can be tested.
+
+The `--build` option tells U-Boot to compile U-Boot. Alternatively, you may
+omit this option and build U-Boot yourself, in whatever way you choose, before
+running the test script.
+
+The test script will attach to U-Boot, execute all valid tests for the board,
+then print a summary of the test process. A complete log of the test session
+will be written to `${build_dir}/test-log.html`. This is best viewed in a web
+browser, but may be read directly as plain text, perhaps with the aid of the
+`html2text` utility.
+
+Testing under a debugger
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you need to run sandbox under a debugger, you may pass the command-line
+option `--gdbserver COMM`. This causes two things to happens:
+
+- Instead of running U-Boot directly, it will be run under gdbserver, with
+ debug communication via the channel `COMM`. You can attach a debugger to the
+ sandbox process in order to debug it. See `man gdbserver` and the example
+ below for details of valid values for `COMM`.
+- All timeouts in tests are disabled, allowing U-Boot an arbitrary amount of
+ time to execute commands. This is useful if U-Boot is stopped at a breakpoint
+ during debugging.
+
+A usage example is:
+
+Window 1:
+
+.. code-block:: bash
+
+ ./test/py/test.py --bd sandbox --gdbserver localhost:1234
+
+Window 2:
+
+.. code-block:: bash
+
+ gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'
+
+Alternatively, you could leave off the `-ex` option and type the command
+manually into gdb once it starts.
+
+You can use any debugger you wish, as long as it speaks the gdb remote
+protocol, or any graphical wrapper around gdb.
+
+Some tests deliberately cause the sandbox process to exit, e.g. to test the
+reset command, or sandbox's CTRL-C handling. When this happens, you will need
+to attach the debugger to the new sandbox instance. If these tests are not
+relevant to your debugging session, you can skip them using pytest's -k
+command-line option; see the next section.
+
+Command-line options
+--------------------
+
+--board-type, --bd, -B
+ set the type of the board to be tested. For example, `sandbox` or `seaboard`.
+
+--board-identity`, --id
+ sets the identity of the board to be tested. This allows differentiation
+ between multiple instances of the same type of physical board that are
+ attached to the same host machine. This parameter is not interpreted by th
+ test script in any way, but rather is simply passed to the hook scripts
+ described below, and may be used in any site-specific way deemed necessary.
+
+--build
+ indicates that the test script should compile U-Boot itself before running
+ the tests. If using this option, make sure that any environment variables
+ required by the build process are already set, such as `$CROSS_COMPILE`.
+
+--buildman
+ indicates that `--build` should use buildman to build U-Boot. There is no need
+ to set $CROSS_COMPILE` in this case since buildman handles it.
+
+--build-dir
+ sets the directory containing the compiled U-Boot binaries. If omitted, this
+ is `${source_dir}/build-${board_type}`.
+
+--result-dir
+ sets the directory to write results, such as log files, into.
+ If omitted, the build directory is used.
+
+--persistent-data-dir
+ sets the directory used to store persistent test data. This is test data that
+ may be re-used across test runs, such as file-system images.
+
+`pytest` also implements a number of its own command-line options. Commonly used
+options are mentioned below. Please see `pytest` documentation for complete
+details. Execute `py.test --version` for a brief summary. Note that U-Boot's
+test.py script passes all command-line arguments directly to `pytest` for
+processing.
+
+-k
+ selects which tests to run. The default is to run all known tests. This
+ option takes a single argument which is used to filter test names. Simple
+ logical operators are supported. For example:
+
+ - `'-k ums'` runs only tests with "ums" in their name.
+ - `'-k ut_dm'` runs only tests with "ut_dm" in their name. Note that in this
+ case, "ut_dm" is a parameter to a test rather than the test name. The full
+ test name is e.g. "test_ut[ut_dm_leak]".
+ - `'-k not reset'` runs everything except tests with "reset" in their name.
+ - `'-k ut or hush'` runs only tests with "ut" or "hush" in their name.
+ - `'-k not (ut or hush)'` runs everything except tests with "ut" or "hush" in
+ their name.
+
+-s
+ prevents pytest from hiding a test's stdout. This allows you to see
+ U-Boot's console log in real time on pytest's stdout.
+
+Testing real hardware
+---------------------
+
+The tools and techniques used to interact with real hardware will vary
+radically between different host and target systems, and the whims of the user.
+For this reason, the test suite does not attempt to directly interact with real
+hardware in any way. Rather, it executes a standardized set of "hook" scripts
+via `$PATH`. These scripts implement certain actions on behalf of the test
+suite. This keeps the test suite simple and isolated from system variances
+unrelated to U-Boot features.
+
+Hook scripts
+~~~~~~~~~~~~
+
+Environment variables
+'''''''''''''''''''''
+
+The following environment variables are set when running hook scripts:
+
+- `UBOOT_BOARD_TYPE` the board type being tested.
+- `UBOOT_BOARD_IDENTITY` the board identity being tested, or `na` if none was
+ specified.
+- `UBOOT_SOURCE_DIR` the U-Boot source directory.
+- `UBOOT_TEST_PY_DIR` the full path to `test/py/` in the source directory.
+- `UBOOT_BUILD_DIR` the U-Boot build directory.
+- `UBOOT_RESULT_DIR` the test result directory.
+- `UBOOT_PERSISTENT_DATA_DIR` the test persistent data directory.
+
+u-boot-test-console
+'''''''''''''''''''
+
+This script provides access to the U-Boot console. The script's stdin/stdout
+should be connected to the board's console. This process should continue to run
+indefinitely, until killed. The test suite will run this script in parallel
+with all other hooks.
+
+This script may be implemented e.g. by executing `cu`, `kermit`, `conmux`, etc.
+via exec().
+
+If you are able to run U-Boot under a hardware simulator such as QEMU, then
+you would likely spawn that simulator from this script. However, note that
+`u-boot-test-reset` may be called multiple times per test script run, and must
+cause U-Boot to start execution from scratch each time. Hopefully your
+simulator includes a virtual reset button! If not, you can launch the
+simulator from `u-boot-test-reset` instead, while arranging for this console
+process to always communicate with the current simulator instance.
+
+u-boot-test-flash
+'''''''''''''''''
+
+Prior to running the test suite against a board, some arrangement must be made
+so that the board executes the particular U-Boot binary to be tested. Often
+this involves writing the U-Boot binary to the board's flash ROM. The test
+suite calls this hook script for that purpose.
+
+This script should perform the entire flashing process synchronously; the
+script should only exit once flashing is complete, and a board reset will
+cause the newly flashed U-Boot binary to be executed.
+
+It is conceivable that this script will do nothing. This might be useful in
+the following cases:
+
+- Some other process has already written the desired U-Boot binary into the
+ board's flash prior to running the test suite.
+- The board allows U-Boot to be downloaded directly into RAM, and executed
+ from there. Use of this feature will reduce wear on the board's flash, so
+ may be preferable if available, and if cold boot testing of U-Boot is not
+ required. If this feature is used, the `u-boot-test-reset` script should
+ perform this download, since the board could conceivably be reset multiple
+ times in a single test run.
+
+It is up to the user to determine if those situations exist, and to code this
+hook script appropriately.
+
+This script will typically be implemented by calling out to some SoC- or
+board-specific vendor flashing utility.
+
+u-boot-test-reset
+'''''''''''''''''
+
+Whenever the test suite needs to reset the target board, this script is
+executed. This is guaranteed to happen at least once, prior to executing the
+first test function. If any test fails, the test infra-structure will execute
+this script again to restore U-Boot to an operational state before running the
+next test function.
+
+This script will likely be implemented by communicating with some form of
+relay or electronic switch attached to the board's reset signal.
+
+The semantics of this script require that when it is executed, U-Boot will
+start running from scratch. If the U-Boot binary to be tested has been written
+to flash, pulsing the board's reset signal is likely all this script needs to
+do. However, in some scenarios, this script may perform other actions. For
+example, it may call out to some SoC- or board-specific vendor utility in order
+to download the U-Boot binary directly into RAM and execute it. This would
+avoid the need for `u-boot-test-flash` to actually write U-Boot to flash, thus
+saving wear on the flash chip(s).
+
+Examples
+''''''''
+
+https://source.denx.de/u-boot/u-boot-test-hooks contains some working example hook
+scripts, and may be useful as a reference when implementing hook scripts for
+your platform. These scripts are not considered part of U-Boot itself.
+
+Board-type-specific configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each board has a different configuration and behaviour. Many of these
+differences can be automatically detected by parsing the `.config` file in the
+build directory. However, some differences can't yet be handled automatically.
+
+For each board, an optional Python module `u_boot_board_${board_type}` may exist
+to provide board-specific information to the test script. Any global value
+defined in these modules is available for use by any test function. The data
+contained in these scripts must be purely derived from U-Boot source code.
+Hence, these configuration files are part of the U-Boot source tree too.
+
+Execution environment configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each user's hardware setup may enable testing different subsets of the features
+implemented by a particular board's configuration of U-Boot. For example, a
+U-Boot configuration may support USB device mode and USB Mass Storage, but this
+can only be tested if a USB cable is connected between the board and the host
+machine running the test script.
+
+For each board, optional Python modules `u_boot_boardenv_${board_type}` and
+`u_boot_boardenv_${board_type}_${board_identity}` may exist to provide
+board-specific and board-identity-specific information to the test script. Any
+global value defined in these modules is available for use by any test
+function. The data contained in these is specific to a particular user's
+hardware configuration. Hence, these configuration files are not part of the
+U-Boot source tree, and should be installed outside of the source tree. Users
+should set `$PYTHONPATH` prior to running the test script to allow these
+modules to be loaded.
+
+Board module parameter usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test scripts rely on the following variables being defined by the board
+module:
+
+- none at present
+
+U-Boot `.config` feature usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test scripts rely on various U-Boot `.config` features, either directly in
+order to test those features, or indirectly in order to query information from
+the running U-Boot instance in order to test other features.
+
+One example is that testing of the `md` command requires knowledge of a RAM
+address to use for the test. This data is parsed from the output of the
+`bdinfo` command, and hence relies on CONFIG_CMD_BDI being enabled.
+
+For a complete list of dependencies, please search the test scripts for
+instances of:
+
+- `buildconfig.get(...`
+- `@pytest.mark.buildconfigspec(...`
+- `@pytest.mark.notbuildconfigspec(...`
+
+Complete invocation example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assuming that you have installed the hook scripts into $HOME/ubtest/bin, and
+any required environment configuration Python modules into $HOME/ubtest/py,
+then you would likely invoke the test script as follows:
+
+If U-Boot has already been built:
+
+.. code-block:: bash
+
+ PATH=$HOME/ubtest/bin:$PATH \
+ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \
+ ./test/py/test.py --bd seaboard
+
+If you want the test script to compile U-Boot for you too, then you likely
+need to set `$CROSS_COMPILE` to allow this, and invoke the test script as
+follows:
+
+.. code-block:: bash
+
+ CROSS_COMPILE=arm-none-eabi- \
+ PATH=$HOME/ubtest/bin:$PATH \
+ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \
+ ./test/py/test.py --bd seaboard --build
+
+or, using buildman to handle it:
+
+.. code-block:: bash
+
+ PATH=$HOME/ubtest/bin:$PATH \
+ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \
+ ./test/py/test.py --bd seaboard --build --buildman
+
+Writing tests
+-------------
+
+Please refer to the pytest documentation for details of writing pytest tests.
+Details specific to the U-Boot test suite are described below.
+
+A test fixture named `u_boot_console` should be used by each test function. This
+provides the means to interact with the U-Boot console, and retrieve board and
+environment configuration information.
+
+The function `u_boot_console.run_command()` executes a shell command on the
+U-Boot console, and returns all output from that command. This allows
+validation or interpretation of the command output. This function validates
+that certain strings are not seen on the U-Boot console. These include shell
+error messages and the U-Boot sign-on message (in order to detect unexpected
+board resets). See the source of `u_boot_console_base.py` for a complete list of
+"bad" strings. Some test scenarios are expected to trigger these strings. Use
+`u_boot_console.disable_check()` to temporarily disable checking for specific
+strings. See `test_unknown_cmd.py` for an example.
+
+Board- and board-environment configuration values may be accessed as sub-fields
+of the `u_boot_console.config` object, for example
+`u_boot_console.config.ram_base`.
+
+Build configuration values (from `.config`) may be accessed via the dictionary
+`u_boot_console.config.buildconfig`, with keys equal to the Kconfig variable
+names.
diff --git a/roms/u-boot/doc/develop/testing.rst b/roms/u-boot/doc/develop/testing.rst
new file mode 100644
index 000000000..ced13ac8b
--- /dev/null
+++ b/roms/u-boot/doc/develop/testing.rst
@@ -0,0 +1,126 @@
+Testing in U-Boot
+=================
+
+U-Boot has a large amount of code. This file describes how this code is
+tested and what tests you should write when adding a new feature.
+
+
+Running tests
+-------------
+
+To run most tests on sandbox, type this::
+
+ make check
+
+in the U-Boot directory. Note that only the pytest suite is run using this
+command.
+
+Some tests take ages to run and are marked with @pytest.mark.slow. To run just
+the quick ones, type this::
+
+ make qcheck
+
+It is also possible to run just the tests for tools (patman, binman, etc.).
+Such tests are included with those tools, i.e. no actual U-Boot unit tests are
+run. Type this::
+
+ make tcheck
+
+All of the above use the test/run script with a paremeter to select which tests
+are run.
+
+
+Sandbox
+-------
+U-Boot can be built as a user-space application (e.g. for Linux). This
+allows test to be executed without needing target hardware. The 'sandbox'
+target provides this feature and it is widely used in tests.
+
+See :doc:`tests_sandbox` for more information.
+
+Pytest Suite
+------------
+
+Many tests are available using the pytest suite, in test/py. This can run
+either on sandbox or on real hardware. It relies on the U-Boot console to
+inject test commands and check the result. It is slower to run than C code,
+but provides the ability to unify lots of tests and summarise their results.
+
+You can run the tests on sandbox with::
+
+ ./test/py/test.py --bd sandbox --build
+
+This will produce HTML output in build-sandbox/test-log.html
+
+Some tests run with other versions of sandbox. For example sandbox_flattree
+runs the tests with livetree (the hierachical devicetree) disabled. You can
+also select particular tests with -k::
+
+ ./test/py/test.py --bd sandbox_flattree --build -k hello
+
+There are some special tests that run in SPL. For this you need the sandbox_spl
+build::
+
+ ./test/py/test.py --bd sandbox_spl --build -k test_spl
+
+See test/py/README.md for more information about the pytest suite.
+
+See :doc:`tests_sandbox` for how to run tests directly (not through pytest).
+
+
+tbot
+----
+
+Tbot provides a way to execute tests on target hardware. It is intended for
+trying out both U-Boot and Linux (and potentially other software) on a
+number of boards automatically. It can be used to create a continuous test
+environment. See http://www.tbot.tools for more information.
+
+
+Ad-hoc tests
+------------
+
+There are several ad-hoc tests which run outside the pytest environment:
+
+test/fs
+ File system test (shell script)
+test/image
+ FIT and legacy image tests (shell script and Python)
+test/stdint
+ A test that stdint.h can be used in U-Boot (shell script)
+trace
+ Test for the tracing feature (shell script)
+
+TODO: Move these into pytest.
+
+
+When to write tests
+-------------------
+
+If you add code to U-Boot without a test you are taking a risk. Even if you
+perform thorough manual testing at the time of submission, it may break when
+future changes are made to U-Boot. It may even break when applied to mainline,
+if other changes interact with it. A good mindset is that untested code
+probably doesn't work and should be deleted.
+
+You can assume that the Pytest suite will be run before patches are accepted
+to mainline, so this provides protection against future breakage.
+
+On the other hand there is quite a bit of code that is not covered with tests,
+or is covered sparingly. So here are some suggestions:
+
+- If you are adding a new uclass, add a sandbox driver and a test that uses it
+- If you are modifying code covered by an existing test, add a new test case
+ to cover your changes
+- If the code you are modifying has not tests, consider writing one. Even a
+ very basic test is useful, and may be picked up and enhanced by others. It
+ is much easier to add onto a test - writing a new large test can seem
+ daunting to most contributors.
+
+See doc:`tests_writing` for how to write tests.
+
+
+Future work
+-----------
+
+Converting existing shell scripts into pytest tests.
diff --git a/roms/u-boot/doc/develop/tests_sandbox.rst b/roms/u-boot/doc/develop/tests_sandbox.rst
new file mode 100644
index 000000000..84608dcb8
--- /dev/null
+++ b/roms/u-boot/doc/develop/tests_sandbox.rst
@@ -0,0 +1,209 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sandbox tests
+=============
+
+Test Design
+-----------
+
+Most uclasses and many functions of U-Boot have sandbox tests. This allows much
+of the code to be checked in an developer-friendly environment.
+
+Sandbox provides a way to write and run unit tests. The traditional approach to
+unit tests is to build lots of little executables, one for each test or
+category of tests. With sandbox, so far as possible, all the tests share a
+small number of executables (e.g. 'u-boot' for sandbox, 'u-boot-spl' and
+'u-boot' for sandbox_spl) and can be run very quickly. The vast majority of
+tests can run on the 'sandbox' build,
+
+Available tests
+---------------
+
+Some of the available tests are:
+
+ - command_ut: Unit tests for command parsing and handling
+ - compression: Unit tests for U-Boot's compression algorithms, useful for
+ security checking. It supports gzip, bzip2, lzma and lzo.
+ - image: Unit tests for images:
+
+ - test/image/test-imagetools.sh - multi-file images
+ - test/py/tests/test-fit.py - FIT images
+ - tracing: test/trace/test-trace.sh tests the tracing system (see
+ README.trace)
+ - verified boot: test/py/tests/test_vboot.py
+
+If you change or enhance any U-Boot subsystem, you should write or expand a
+test and include it with your patch series submission. Test coverage in some
+older areas of U-Boot is still somewhat limited and we need to work to improve
+it.
+
+Note that many of these tests are implemented as commands which you can
+run natively on your board if desired (and enabled).
+
+To run all tests, use 'make check'.
+
+
+Running sandbox tests directly
+------------------------------
+
+Typically tests are run using the pytest suite. Running pytests on sandbox is
+easy and always gets things right. For example some tests require files to be
+set up before they can work.
+
+But it is also possible to run some sandbox tests directly. For example, this
+runs the dm_test_gpio() test which you can find in test/dm/gpio.c::
+
+ $ ./u-boot -T -c "ut dm gpio"
+
+
+ U-Boot 2021.01
+
+ Model: sandbox
+ DRAM: 128 MiB
+ WDT: Started with servicing (60s timeout)
+ MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
+ In: serial
+ Out: vidconsole
+ Err: vidconsole
+ Model: sandbox
+ SCSI:
+ Net: eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth6: eth@10004000
+ Test: dm_test_gpio: gpio.c
+ Test: dm_test_gpio: gpio.c (flat tree)
+ Failures: 0
+
+The -T option tells the U-Boot sandbox to run with the 'test' devicetree
+(test.dts) instead of -D which selects the normal sandbox.dts - this is
+necessary because many tests rely on nodes or properties in the test devicetree.
+If you try running tests without -T then you may see failures, like::
+
+ $ ./u-boot -c "ut dm gpio"
+
+
+ U-Boot 2021.01
+
+ DRAM: 128 MiB
+ WDT: Not found!
+ MMC:
+ In: serial
+ Out: serial
+ Err: serial
+ SCSI:
+ Net: No ethernet found.
+ Please run with test device tree:
+ ./u-boot -d arch/sandbox/dts/test.dtb
+ Test: dm_test_gpio: gpio.c
+ test/dm/gpio.c:37, dm_test_gpio(): 0 == gpio_lookup_name("b4", &dev, &offset, &gpio): Expected 0x0 (0), got 0xffffffea (-22)
+ Test: dm_test_gpio: gpio.c (flat tree)
+ test/dm/gpio.c:37, dm_test_gpio(): 0 == gpio_lookup_name("b4", &dev, &offset, &gpio): Expected 0x0 (0), got 0xffffffea (-22)
+ Failures: 2
+
+The message above should provide a hint if you forget to use the -T flag. Even
+running with -D will produce different results.
+
+You can easily use gdb on these tests, without needing --gdbserver::
+
+ $ gdb u-boot --args -T -c "ut dm gpio"
+ ...
+ (gdb) break dm_test_gpio
+ Breakpoint 1 at 0x1415bd: file test/dm/gpio.c, line 37.
+ (gdb) run -T -c "ut dm gpio"
+ Starting program: u-boot -T -c "ut dm gpio"
+ Test: dm_test_gpio: gpio.c
+
+ Breakpoint 1, dm_test_gpio (uts=0x5555558029a0 <global_dm_test_state>)
+ at files/test/dm/gpio.c:37
+ 37 ut_assertok(gpio_lookup_name("b4", &dev, &offset, &gpio));
+ (gdb)
+
+You can then single-step and look at variables as needed.
+
+
+Running sandbox_spl tests directly
+----------------------------------
+
+SPL is the phase before U-Boot proper. It is present in the sandbox_spl build,
+so you can run SPL like this::
+
+ ./spl/u-boot-spl
+
+SPL tests are special in that they run (only in the SPL phase, of course) if the
+-u flag is given::
+
+ ./spl/u-boot-spl -u
+
+ U-Boot SPL 2021.01-00723-g43c77b51be5-dirty (Jan 24 2021 - 16:38:24 -0700)
+ Running 5 driver model tests
+ Test: dm_test_of_plat_base: of_platdata.c (flat tree)
+ Test: dm_test_of_plat_dev: of_platdata.c (flat tree)
+ Test: dm_test_of_plat_parent: of_platdata.c (flat tree)
+ Test: dm_test_of_plat_phandle: of_platdata.c (flat tree)
+ Test: dm_test_of_plat_props: of_platdata.c (flat tree)
+ Failures: 0
+
+
+ U-Boot 2021.01-00723-g43c77b51be5-dirty (Jan 24 2021 - 16:38:24 -0700)
+
+ DRAM: 128 MiB
+ ...
+
+It is not possible to run SPL tests in U-Boot proper, firstly because they are
+not built into U-Boot proper and secondly because the environment is very
+different, e.g. some SPL tests rely on of-platdata which is only available in
+SPL.
+
+Note that after running, SPL continues to boot into U-Boot proper. You can add
+'-c exit' to make U-Boot quit without doing anything further. It is not
+currently possible to run SPL tests and then stop, since the pytests require
+that U-Boot produces the expected banner.
+
+You can use the -k flag to select which tests run::
+
+ ./spl/u-boot-spl -u -k dm_test_of_plat_parent
+
+Of course you can use gdb with sandbox_spl, just as with sandbox.
+
+
+Running all tests directly
+--------------------------
+
+A fast way to run all sandbox tests is::
+
+ ./u-boot -T -c "ut all"
+
+It typically runs single-thread in 6 seconds on 2021 hardware, with 2s of that
+to the delays in the time test.
+
+This should not be considered a substitute for 'make check', but can be helpful
+for git bisect, etc.
+
+
+What tests are built in?
+------------------------
+
+Whatever sandbox build is used, which tests are present is determined by which
+source files are built. For sandbox_spl, the of_platdata tests are built
+because of the build rule in test/dm/Makefile::
+
+ ifeq ($(CONFIG_SPL_BUILD),y)
+ obj-$(CONFIG_SPL_OF_PLATDATA) += of_platdata.o
+ else
+ ...other tests for non-spl
+ endif
+
+You can get a list of tests in a U-Boot ELF file by looking for the
+linker_list::
+
+ $ nm /tmp/b/sandbox_spl/spl/u-boot-spl |grep 2_dm_test
+ 000000000001f200 D _u_boot_list_2_dm_test_2_dm_test_of_plat_base
+ 000000000001f220 D _u_boot_list_2_dm_test_2_dm_test_of_plat_dev
+ 000000000001f240 D _u_boot_list_2_dm_test_2_dm_test_of_plat_parent
+ 000000000001f260 D _u_boot_list_2_dm_test_2_dm_test_of_plat_phandle
+ 000000000001f280 D _u_boot_list_2_dm_test_2_dm_test_of_plat_props
+
+
+Writing tests
+-------------
+
+See :doc:`tests_writing` for how to write new tests.
+
diff --git a/roms/u-boot/doc/develop/tests_writing.rst b/roms/u-boot/doc/develop/tests_writing.rst
new file mode 100644
index 000000000..1ddf7a353
--- /dev/null
+++ b/roms/u-boot/doc/develop/tests_writing.rst
@@ -0,0 +1,346 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2021 Google LLC
+.. sectionauthor:: Simon Glass <sjg@chromium.org>
+
+Writing Tests
+=============
+
+This describes how to write tests in U-Boot and describes the possible options.
+
+Test types
+----------
+
+There are two basic types of test in U-Boot:
+
+ - Python tests, in test/py/tests
+ - C tests, in test/ and its subdirectories
+
+(there are also UEFI tests in lib/efi_selftest/ not considered here.)
+
+Python tests talk to U-Boot via the command line. They support both sandbox and
+real hardware. They typically do not require building test code into U-Boot
+itself. They are fairly slow to run, due to the command-line interface and there
+being two separate processes. Python tests are fairly easy to write. They can
+be a little tricky to debug sometimes due to the voluminous output of pytest.
+
+C tests are written directly in U-Boot. While they can be used on boards, they
+are more commonly used with sandbox, as they obviously add to U-Boot code size.
+C tests are easy to write so long as the required facilities exist. Where they
+do not it can involve refactoring or adding new features to sandbox. They are
+fast to run and easy to debug.
+
+Regardless of which test type is used, all tests are collected and run by the
+pytest framework, so there is typically no need to run them separately. This
+means that C tests can be used when it makes sense, and Python tests when it
+doesn't.
+
+
+This table shows how to decide whether to write a C or Python test:
+
+===================== =========================== =============================
+Attribute C test Python test
+===================== =========================== =============================
+Fast to run? Yes No (two separate processes)
+Easy to write? Yes, if required test Yes
+ features exist in sandbox
+ or the target system
+Needs code in U-Boot? Yes No, provided the test can be
+ executed and the result
+ determined using the command
+ line
+Easy to debug? Yes No, since access to the U-Boot
+ state is not available and the
+ amount of output can
+ sometimes require a bit of
+ digging
+Can use gdb? Yes, directly Yes, with --gdbserver
+Can run on boards? Some can, but only if Some
+ compiled in and not
+ dependent on sandboxau
+===================== =========================== =============================
+
+
+Python or C
+-----------
+
+Typically in U-Boot we encourage C test using sandbox for all features. This
+allows fast testing, easy development and allows contributors to make changes
+without needing dozens of boards to test with.
+
+When a test requires setup or interaction with the running host (such as to
+generate images and then running U-Boot to check that they can be loaded), or
+cannot be run on sandbox, Python tests should be used. These should typically
+NOT rely on running with sandbox, but instead should function correctly on any
+board supported by U-Boot.
+
+
+How slow are Python tests?
+--------------------------
+
+Under the hood, when running on sandbox, Python tests work by starting a sandbox
+test and connecting to it via a pipe. Each interaction with the U-Boot process
+requires at least a context switch to handle the pipe interaction. The test
+sends a command to U-Boot, which then reacts and shows some output, then the
+test sees that and continues. Of course on real hardware, communications delays
+(e.g. with a serial console) make this slower.
+
+For comparison, consider a test that checks the 'md' (memory dump). All times
+below are approximate, as measured on an AMD 2950X system. Here is is the test
+in Python::
+
+ @pytest.mark.buildconfigspec('cmd_memory')
+ def test_md(u_boot_console):
+ """Test that md reads memory as expected, and that memory can be modified
+ using the mw command."""
+
+ ram_base = u_boot_utils.find_ram_base(u_boot_console)
+ addr = '%08x' % ram_base
+ val = 'a5f09876'
+ expected_response = addr + ': ' + val
+ u_boot_console.run_command('mw ' + addr + ' 0 10')
+ response = u_boot_console.run_command('md ' + addr + ' 10')
+ assert(not (expected_response in response))
+ u_boot_console.run_command('mw ' + addr + ' ' + val)
+ response = u_boot_console.run_command('md ' + addr + ' 10')
+ assert(expected_response in response)
+
+This runs a few commands and checks the output. Note that it runs a command,
+waits for the response and then checks it agains what is expected. If run by
+itself it takes around 800ms, including test collection. For 1000 runs it takes
+19 seconds, or 19ms per run. Of course 1000 runs it not that useful since we
+only want to run it once.
+
+There is no exactly equivalent C test, but here is a similar one that tests 'ms'
+(memory search)::
+
+ /* Test 'ms' command with bytes */
+ static int mem_test_ms_b(struct unit_test_state *uts)
+ {
+ u8 *buf;
+
+ buf = map_sysmem(0, BUF_SIZE + 1);
+ memset(buf, '\0', BUF_SIZE);
+ buf[0x0] = 0x12;
+ buf[0x31] = 0x12;
+ buf[0xff] = 0x12;
+ buf[0x100] = 0x12;
+ ut_assertok(console_record_reset_enable());
+ run_command("ms.b 1 ff 12", 0);
+ ut_assert_nextline("00000030: 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................");
+ ut_assert_nextline("--");
+ ut_assert_nextline("000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 ................");
+ ut_assert_nextline("2 matches");
+ ut_assert_console_end();
+
+ ut_asserteq(2, env_get_hex("memmatches", 0));
+ ut_asserteq(0xff, env_get_hex("memaddr", 0));
+ ut_asserteq(0xfe, env_get_hex("mempos", 0));
+
+ unmap_sysmem(buf);
+
+ return 0;
+ }
+ MEM_TEST(mem_test_ms_b, UT_TESTF_CONSOLE_REC);
+
+This runs the command directly in U-Boot, then checks the console output, also
+directly in U-Boot. If run by itself this takes 100ms. For 1000 runs it takes
+660ms, or 0.66ms per run.
+
+So overall running a C test is perhaps 8 times faster individually and the
+interactions are perhaps 25 times faster.
+
+It should also be noted that the C test is fairly easy to debug. You can set a
+breakpoint on do_mem_search(), which is what implements the 'ms' command,
+single step to see what might be wrong, etc. That is also possible with the
+pytest, but requires two terminals and --gdbserver.
+
+
+Why does speed matter?
+----------------------
+
+Many development activities rely on running tests:
+
+ - 'git bisect run make qcheck' can be used to find a failing commit
+ - test-driven development relies on quick iteration of build/test
+ - U-Boot's continuous integration (CI) systems make use of tests. Running
+ all sandbox tests typically takes 90 seconds and running each qemu test
+ takes about 30 seconds. This is currently dwarfed by the time taken to
+ build all boards
+
+As U-Boot continues to grow its feature set, fast and reliable tests are a
+critical factor factor in developer productivity and happiness.
+
+
+Writing C tests
+---------------
+
+C tests are arranged into suites which are typically executed by the 'ut'
+command. Each suite is in its own file. This section describes how to accomplish
+some common test tasks.
+
+(there are also UEFI C tests in lib/efi_selftest/ not considered here.)
+
+Add a new driver model test
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use this when adding a test for a new or existing uclass, adding new operations
+or features to a uclass, adding new ofnode or dev_read_() functions, or anything
+else related to driver model.
+
+Find a suitable place for your test, perhaps near other test functions in
+existing code, or in a new file. Each uclass should have its own test file.
+
+Declare the test with::
+
+ /* Test that ... */
+ static int dm_test_uclassname_what(struct unit_test_state *uts)
+ {
+ /* test code here */
+
+ return 0;
+ }
+ DM_TEST(dm_test_uclassname_what, UT_TESTF_SCAN_FDT);
+
+Replace 'uclassname' with the name of your uclass, if applicable. Replace 'what'
+with what you are testing.
+
+The flags for DM_TEST() are defined in test/test.h and you typically want
+UT_TESTF_SCAN_FDT so that the devicetree is scanned and all devices are bound
+and ready for use. The DM_TEST macro adds UT_TESTF_DM automatically so that
+the test runner knows it is a driver model test.
+
+Driver model tests are special in that the entire driver model state is
+recreated anew for each test. This ensures that if a previous test deletes a
+device, for example, it does not affect subsequent tests. Driver model tests
+also run both with livetree and flattree, to ensure that both devicetree
+implementations work as expected.
+
+Example commit: c48cb7ebfb4 ("sandbox: add ADC unit tests") [1]
+
+[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/c48cb7ebfb4
+
+
+Add a C test to an existing suite
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use this when you are adding to or modifying an existing feature outside driver
+model. An example is bloblist.
+
+Add a new function in the same file as the rest of the suite and register it
+with the suite. For example, to add a new mem_search test::
+
+ /* Test 'ms' command with 32-bit values */
+ static int mem_test_ms_new_thing(struct unit_test_state *uts)
+ {
+ /* test code here*/
+
+ return 0;
+ }
+ MEM_TEST(mem_test_ms_new_thing, UT_TESTF_CONSOLE_REC);
+
+Note that the MEM_TEST() macros is defined at the top of the file.
+
+Example commit: 9fe064646d2 ("bloblist: Support relocating to a larger space") [1]
+
+[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fe064646d2
+
+
+Add a new test suite
+~~~~~~~~~~~~~~~~~~~~
+
+Each suite should focus on one feature or subsystem, so if you are writing a
+new one of those, you should add a new suite.
+
+Create a new file in test/ or a subdirectory and define a macro to register the
+suite. For example::
+
+ #include <common.h>
+ #include <console.h>
+ #include <mapmem.h>
+ #include <dm/test.h>
+ #include <test/ut.h>
+
+ /* Declare a new wibble test */
+ #define WIBBLE_TEST(_name, _flags) UNIT_TEST(_name, _flags, wibble_test)
+
+ /* Tetss go here */
+
+ /* At the bottom of the file: */
+
+ int do_ut_wibble(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+ {
+ struct unit_test *tests = UNIT_TEST_SUITE_START(wibble_test);
+ const int n_ents = UNIT_TEST_SUITE_COUNT(wibble_test);
+
+ return cmd_ut_category("cmd_wibble", "wibble_test_", tests, n_ents, argc, argv);
+ }
+
+Then add new tests to it as above.
+
+Register this new suite in test/cmd_ut.c by adding to cmd_ut_sub[]::
+
+ /* Within cmd_ut_sub[]... */
+
+ U_BOOT_CMD_MKENT(wibble, CONFIG_SYS_MAXARGS, 1, do_ut_wibble, "", ""),
+
+and adding new help to ut_help_text[]::
+
+ "ut wibble - Test the wibble feature\n"
+
+If your feature is conditional on a particular Kconfig, then you can use #ifdef
+to control that.
+
+Finally, add the test to the build by adding to the Makefile in the same
+directory::
+
+ obj-$(CONFIG_$(SPL_)CMDLINE) += wibble.o
+
+Note that CMDLINE is never enabled in SPL, so this test will only be present in
+U-Boot proper. See below for how to do SPL tests.
+
+As before, you can add an extra Kconfig check if needed::
+
+ ifneq ($(CONFIG_$(SPL_)WIBBLE),)
+ obj-$(CONFIG_$(SPL_)CMDLINE) += wibble.o
+ endif
+
+
+Example commit: 919e7a8fb64 ("test: Add a simple test for bloblist") [1]
+
+[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/919e7a8fb64
+
+
+Making the test run from pytest
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All C tests must run from pytest. Typically this is automatic, since pytest
+scans the U-Boot executable for available tests to run. So long as you have a
+'ut' subcommand for your test suite, it will run. The same applies for driver
+model tests since they use the 'ut dm' subcommand.
+
+See test/py/tests/test_ut.py for how unit tests are run.
+
+
+Add a C test for SPL
+~~~~~~~~~~~~~~~~~~~~
+
+Note: C tests are only available for sandbox_spl at present. There is currently
+no mechanism in other boards to existing SPL tests even if they are built into
+the image.
+
+SPL tests cannot be run from the 'ut' command since there are no commands
+available in SPL. Instead, sandbox (only) calls ut_run_list() on start-up, when
+the -u flag is given. This runs the available unit tests, no matter what suite
+they are in.
+
+To create a new SPL test, follow the same rules as above, either adding to an
+existing suite or creating a new one.
+
+An example SPL test is spl_test_load().
+
+
+Writing Python tests
+--------------------
+
+See :doc:`py_testing` for brief notes how to write Python tests. You
+should be able to use the existing tests in test/py/tests as examples.
diff --git a/roms/u-boot/doc/develop/trace.rst b/roms/u-boot/doc/develop/trace.rst
new file mode 100644
index 000000000..7776c4842
--- /dev/null
+++ b/roms/u-boot/doc/develop/trace.rst
@@ -0,0 +1,355 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2013 The Chromium OS Authors.
+
+Tracing in U-Boot
+=================
+
+U-Boot supports a simple tracing feature which allows a record of excecution
+to be collected and sent to a host machine for analysis. At present the
+main use for this is to profile boot time.
+
+
+Overview
+--------
+
+The trace feature uses GCC's instrument-functions feature to trace all
+function entry/exit points. These are then recorded in a memory buffer.
+The memory buffer can be saved to the host over a network link using
+tftpput or by writing to an attached memory device such as MMC.
+
+On the host, the file is first converted with a tool called 'proftool',
+which extracts useful information from it. The resulting trace output
+resembles that emitted by Linux's ftrace feature, so can be visually
+displayed by pytimechart.
+
+
+Quick-start using Sandbox
+-------------------------
+
+Sandbox is a build of U-Boot that can run under Linux so it is a convenient
+way of trying out tracing before you use it on your actual board. To do
+this, follow these steps:
+
+Add the following to include/configs/sandbox.h (if not already there)
+
+.. code-block:: c
+
+ #define CONFIG_TRACE
+ #define CONFIG_CMD_TRACE
+ #define CONFIG_TRACE_BUFFER_SIZE (16 << 20)
+ #define CONFIG_TRACE_EARLY_SIZE (8 << 20)
+ #define CONFIG_TRACE_EARLY
+ #define CONFIG_TRACE_EARLY_ADDR 0x00100000
+
+Build sandbox U-Boot with tracing enabled:
+
+.. code-block:: console
+
+ $ make FTRACE=1 O=sandbox sandbox_config
+ $ make FTRACE=1 O=sandbox
+
+Run sandbox, wait for a bit of trace information to appear, and then capture
+a trace:
+
+.. code-block:: console
+
+ $ ./sandbox/u-boot
+
+ U-Boot 2013.04-rc2-00100-ga72fcef (Apr 17 2013 - 19:25:24)
+
+ DRAM: 128 MiB
+ trace: enabled
+ Using default environment
+
+ In: serial
+ Out: serial
+ Err: serial
+ =>trace stats
+ 671,406 function sites
+ 69,712 function calls
+ 0 untracked function calls
+ 73,373 traced function calls
+ 16 maximum observed call depth
+ 15 call depth limit
+ 66,491 calls not traced due to depth
+ =>trace stats
+ 671,406 function sites
+ 1,279,450 function calls
+ 0 untracked function calls
+ 950,490 traced function calls (333217 dropped due to overflow)
+ 16 maximum observed call depth
+ 15 call depth limit
+ 1,275,767 calls not traced due to depth
+ =>trace calls 0 e00000
+ Call list dumped to 00000000, size 0xae0a40
+ =>print
+ baudrate=115200
+ profbase=0
+ profoffset=ae0a40
+ profsize=e00000
+ stderr=serial
+ stdin=serial
+ stdout=serial
+
+ Environment size: 117/8188 bytes
+ =>host save host 0 trace 0 ${profoffset}
+ 11405888 bytes written in 10 ms (1.1 GiB/s)
+ =>reset
+
+
+Then run proftool to convert the trace information to ftrace format
+
+.. code-block:: console
+
+ $ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt
+
+Finally run pytimechart to display it
+
+.. code-block:: console
+
+ $ pytimechart trace.txt
+
+Using this tool you can zoom and pan across the trace, with the function
+calls on the left and little marks representing the start and end of each
+function.
+
+
+CONFIG Options
+--------------
+
+CONFIG_TRACE
+ Enables the trace feature in U-Boot.
+
+CONFIG_CMD_TRACE
+ Enables the trace command.
+
+CONFIG_TRACE_BUFFER_SIZE
+ Size of trace buffer to allocate for U-Boot. This buffer is
+ used after relocation, as a place to put function tracing
+ information. The address of the buffer is determined by
+ the relocation code.
+
+CONFIG_TRACE_EARLY
+ Define this to start tracing early, before relocation.
+
+CONFIG_TRACE_EARLY_SIZE
+ Size of 'early' trace buffer. Before U-Boot has relocated
+ it doesn't have a proper trace buffer. On many boards
+ you can define an area of memory to use for the trace
+ buffer until the 'real' trace buffer is available after
+ relocation. The contents of this buffer are then copied to
+ the real buffer.
+
+CONFIG_TRACE_EARLY_ADDR
+ Address of early trace buffer
+
+
+Building U-Boot with Tracing Enabled
+------------------------------------
+
+Pass 'FTRACE=1' to the U-Boot Makefile to actually instrument the code.
+This is kept as a separate option so that it is easy to enable/disable
+instrumenting from the command line instead of having to change board
+config files.
+
+
+Collecting Trace Data
+---------------------
+
+When you run U-Boot on your board it will collect trace data up to the
+limit of the trace buffer size you have specified. Once that is exhausted
+no more data will be collected.
+
+Collecting trace data has an affect on execution time/performance. You
+will notice this particularly with trvial functions - the overhead of
+recording their execution may even exceed their normal execution time.
+In practice this doesn't matter much so long as you are aware of the
+effect. Once you have done your optimisations, turn off tracing before
+doing end-to-end timing.
+
+The best time to start tracing is right at the beginning of U-Boot. The
+best time to stop tracing is right at the end. In practice it is hard
+to achieve these ideals.
+
+This implementation enables tracing early in board_init_f(). This means
+that it captures most of the board init process, missing only the
+early architecture-specific init. However, it also misses the entire
+SPL stage if there is one.
+
+U-Boot typically ends with a 'bootm' command which loads and runs an
+OS. There is useful trace data in the execution of that bootm
+command. Therefore this implementation provides a way to collect trace
+data after bootm has finished processing, but just before it jumps to
+the OS. In practical terms, U-Boot runs the 'fakegocmd' environment
+variable at this point. This variable should have a short script which
+collects the trace data and writes it somewhere.
+
+Trace data collection relies on a microsecond timer, accesed through
+timer_get_us(). So the first think you should do is make sure that
+this produces sensible results for your board. Suitable sources for
+this timer include high resolution timers, PWMs or profile timers if
+available. Most modern SOCs have a suitable timer for this. Make sure
+that you mark this timer (and anything it calls) with
+__attribute__((no_instrument_function)) so that the trace library can
+use it without causing an infinite loop.
+
+
+Commands
+--------
+
+The trace command has variable sub-commands:
+
+stats
+ Display tracing statistics
+
+pause
+ Pause tracing
+
+resume
+ Resume tracing
+
+funclist [<addr> <size>]
+ Dump a list of functions into the buffer
+
+calls [<addr> <size>]
+ Dump function call trace into buffer
+
+If the address and size are not given, these are obtained from environment
+variables (see below). In any case the environment variables are updated
+after the command runs.
+
+
+Environment Variables
+---------------------
+
+The following are used:
+
+profbase
+ Base address of trace output buffer
+
+profoffset
+ Offset of first unwritten byte in trace output buffer
+
+profsize
+ Size of trace output buffer
+
+All of these are set by the 'trace calls' command.
+
+These variables keep track of the amount of data written to the trace
+output buffer by the 'trace' command. The trace commands which write data
+to the output buffer can use these to specify the buffer to write to, and
+update profoffset each time. This allows successive commands to append data
+to the same buffer, for example::
+
+ => trace funclist 10000 e00000
+ => trace calls
+
+(the latter command appends more data to the buffer).
+
+
+fakegocmd
+ Specifies commands to run just before booting the OS. This
+ is a useful time to write the trace data to the host for
+ processing.
+
+
+Writing Out Trace Data
+----------------------
+
+Once the trace data is in an output buffer in memory there are various ways
+to transmit it to the host. Notably you can use tftput to send the data
+over a network link::
+
+ fakegocmd=trace pause; usb start; set autoload n; bootp;
+ trace calls 10000000 1000000;
+ tftpput ${profbase} ${profoffset} 192.168.1.4:/tftpboot/calls
+
+This starts up USB (to talk to an attached USB Ethernet dongle), writes
+a trace log to address 10000000 and sends it to a host machine using
+TFTP. After this, U-Boot will boot the OS normally, albeit a little
+later.
+
+
+Converting Trace Output Data
+----------------------------
+
+The trace output data is kept in a binary format which is not documented
+here. To convert it into something useful, you can use proftool.
+
+This tool must be given the U-Boot map file and the trace data received
+from running that U-Boot. It produces a text output file.
+
+Options
+
+-m <map_file>
+ Specify U-Boot map file
+
+-p <trace_file>
+ Specifiy profile/trace file
+
+Commands:
+
+dump-ftrace
+ Write a text dump of the file in Linux ftrace format to stdout
+
+
+Viewing the Trace Data
+----------------------
+
+You can use pytimechart for this (sudo apt-get pytimechart might work on
+your Debian-style machine, and use your favourite search engine to obtain
+documentation). It expects the file to have a .txt extension. The program
+has terse user interface but is very convenient for viewing U-Boot
+profile information.
+
+
+Workflow Suggestions
+--------------------
+
+The following suggestions may be helpful if you are trying to reduce boot
+time:
+
+1. Enable CONFIG_BOOTSTAGE and CONFIG_BOOTSTAGE_REPORT. This should get
+ you are helpful overall snapshot of the boot time.
+
+2. Build U-Boot with tracing and run it. Note the difference in boot time
+ (it is common for tracing to add 10% to the time)
+
+3. Collect the trace information as descibed above. Use this to find where
+ all the time is being spent.
+
+4. Take a look at that code and see if you can optimise it. Perhaps it is
+ possible to speed up the initialisation of a device, or remove an unused
+ feature.
+
+5. Rebuild, run and collect again. Compare your results.
+
+6. Keep going until you run out of steam, or your boot is fast enough.
+
+
+Configuring Trace
+-----------------
+
+There are a few parameters in the code that you may want to consider.
+There is a function call depth limit (set to 15 by default). When the
+stack depth goes above this then no tracing information is recorded.
+The maximum depth reached is recorded and displayed by the 'trace stats'
+command.
+
+
+Future Work
+-----------
+
+Tracing could be a little tidier in some areas, for example providing
+run-time configuration options for trace.
+
+Some other features that might be useful:
+
+- Trace filter to select which functions are recorded
+- Sample-based profiling using a timer interrupt
+- Better control over trace depth
+- Compression of trace information
+
+
+Simon Glass <sjg@chromium.org>
+April 2013
diff --git a/roms/u-boot/doc/develop/uefi/index.rst b/roms/u-boot/doc/develop/uefi/index.rst
new file mode 100644
index 000000000..7e65dbc5d
--- /dev/null
+++ b/roms/u-boot/doc/develop/uefi/index.rst
@@ -0,0 +1,15 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Unified Extensible Firmware (UEFI)
+==================================
+
+U-Boot provides an implementation of the UEFI API allowing to run UEFI
+compliant software like Linux, GRUB, and iPXE. Furthermore U-Boot itself
+can be run an UEFI payload.
+
+.. toctree::
+ :maxdepth: 2
+
+ uefi.rst
+ u-boot_on_efi.rst
+ iscsi.rst
diff --git a/roms/u-boot/doc/develop/uefi/iscsi.rst b/roms/u-boot/doc/develop/uefi/iscsi.rst
new file mode 100644
index 000000000..51d38cde2
--- /dev/null
+++ b/roms/u-boot/doc/develop/uefi/iscsi.rst
@@ -0,0 +1,184 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2018 Heinrich Schuchardt
+
+iSCSI booting with U-Boot and iPXE
+==================================
+
+Motivation
+----------
+
+U-Boot has only a reduced set of supported network protocols. The focus for
+network booting has been on UDP based protocols. A TCP stack and HTTP support
+are expected to be integrated in 2018 together with a wget command.
+
+For booting a diskless computer this leaves us with BOOTP or DHCP to get the
+address of a boot script. TFTP or NFS can be used to load the boot script, the
+operating system kernel and the initial file system (initrd).
+
+These protocols are insecure. The client cannot validate the authenticity
+of the contacted servers. And the server cannot verify the identity of the
+client.
+
+Furthermore the services providing the operating system loader or kernel are
+not the ones that the operating system typically will use. Especially in a SAN
+environment this makes updating the operating system a hassle. After installing
+a new kernel version the boot files have to be copied to the TFTP server
+directory.
+
+The HTTPS protocol provides certificate based validation of servers. Sensitive
+data like passwords can be securely transmitted.
+
+The iSCSI protocol is used for connecting storage attached networks. It
+provides mutual authentication using the CHAP protocol. It typically runs on
+a TCP transport.
+
+Thus a better solution than DHCP/TFTP/NFS boot would be to load a boot script
+via HTTPS and to download any other files needed for booting via iSCSI from the
+same target where the operating system is installed.
+
+An alternative to implementing these protocols in U-Boot is to use an existing
+software that can run on top of U-Boot. iPXE[1] is the "swiss army knife" of
+network booting. It supports both HTTPS and iSCSI. It has a scripting engine for
+fine grained control of the boot process and can provide a command shell.
+
+iPXE can be built as an EFI application (named snp.efi) which can be loaded and
+run by U-Boot.
+
+Boot sequence
+-------------
+
+U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
+application has network access via the simple network protocol offered by
+U-Boot.
+
+iPXE executes its internal script. This script may optionally chain load a
+secondary boot script via HTTPS or open a shell.
+
+For the further boot process iPXE connects to the iSCSI server. This includes
+the mutual authentication using the CHAP protocol. After the authentication iPXE
+has access to the iSCSI targets.
+
+For a selected iSCSI target iPXE sets up a handle with the block IO protocol. It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and installs the simple file
+protocol. Now iPXE can call the simple file protocol to load GRUB[2]. U-Boot
+uses the block IO protocol offered by iPXE to fulfill the request.
+
+Once GRUB is started it uses the same block IO protocol to load Linux. Via
+the EFI stub Linux is called as an EFI application::
+
+ +--------+ +--------+
+ | | Runs | |
+ | U-Boot |========>| iPXE |
+ | EFI | | snp.efi|
+ +--------+ | | DHCP | |
+ | |<===|********|<========| |
+ | DHCP | | | Get IP | |
+ | Server | | | Address | |
+ | |===>|********|========>| |
+ +--------+ | | Response| |
+ | | | |
+ | | | |
+ +--------+ | | HTTPS | |
+ | |<===|********|<========| |
+ | HTTPS | | | Load | |
+ | Server | | | Script | |
+ | |===>|********|========>| |
+ +--------+ | | | |
+ | | | |
+ | | | |
+ +--------+ | | iSCSI | |
+ | |<===|********|<========| |
+ | iSCSI | | | Auth | |
+ | Server |===>|********|========>| |
+ | | | | | |
+ | | | | Loads | |
+ | |<===|********|<========| | +--------+
+ | | | | GRUB | | Runs | |
+ | |===>|********|========>| |======>| GRUB |
+ | | | | | | | |
+ | | | | | | | |
+ | | | | | | Loads | |
+ | |<===|********|<========|********|<======| | +--------+
+ | | | | | | Linux | | Runs | |
+ | |===>|********|========>|********|======>| |=====>| Linux |
+ | | | | | | | | | |
+ +--------+ +--------+ +--------+ +--------+ | |
+ | |
+ | |
+ | ~ ~ ~ ~|
+
+Security
+--------
+
+The iSCSI protocol is not encrypted. The traffic could be secured using IPsec
+but neither U-Boot nor iPXE does support this. So we should at least separate
+the iSCSI traffic from all other network traffic. This can be achieved using a
+virtual local area network (VLAN).
+
+Configuration
+-------------
+
+iPXE
+~~~~
+
+For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed::
+
+ git clone http://git.ipxe.org/ipxe.git
+ cd ipxe/src
+ make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
+
+The available commands for the boot script are documented at:
+
+http://ipxe.org/cmd
+
+Credentials are managed as environment variables. These are described here:
+
+http://ipxe.org/cfg
+
+iPXE by default will put the CPU to rest when waiting for input. U-Boot does
+not wake it up due to missing interrupt support. To avoid this behavior create
+file src/config/local/nap.h:
+
+.. code-block:: c
+
+ /* nap.h */
+ #undef NAP_EFIX86
+ #undef NAP_EFIARM
+ #define NAP_NULL
+
+The supported commands in iPXE are controlled by an include, too. Putting the
+following into src/config/local/general.h is sufficient for most use cases:
+
+.. code-block:: c
+
+ /* general.h */
+ #define NSLOOKUP_CMD /* Name resolution command */
+ #define PING_CMD /* Ping command */
+ #define NTP_CMD /* NTP commands */
+ #define VLAN_CMD /* VLAN commands */
+ #define IMAGE_EFI /* EFI image support */
+ #define DOWNLOAD_PROTO_HTTPS /* Secure Hypertext Transfer Protocol */
+ #define DOWNLOAD_PROTO_FTP /* File Transfer Protocol */
+ #define DOWNLOAD_PROTO_NFS /* Network File System Protocol */
+ #define DOWNLOAD_PROTO_FILE /* Local file system access */
+
+Open-iSCSI
+~~~~~~~~~~
+
+When the root file system is on an iSCSI drive you should disable pings and set
+the replacement timer to a high value in the configuration file [3]::
+
+ node.conn[0].timeo.noop_out_interval = 0
+ node.conn[0].timeo.noop_out_timeout = 0
+ node.session.timeo.replacement_timeout = 86400
+
+Links
+-----
+
+* [1] https://ipxe.org - iPXE open source boot firmware
+* [2] https://www.gnu.org/software/grub/ -
+ GNU GRUB (Grand Unified Bootloader)
+* [3] https://github.com/open-iscsi/open-iscsi/blob/master/README -
+ Open-iSCSI README
diff --git a/roms/u-boot/doc/develop/uefi/u-boot_on_efi.rst b/roms/u-boot/doc/develop/uefi/u-boot_on_efi.rst
new file mode 100644
index 000000000..c9a41bc91
--- /dev/null
+++ b/roms/u-boot/doc/develop/uefi/u-boot_on_efi.rst
@@ -0,0 +1,235 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2015 Google, Inc
+
+U-Boot on EFI
+=============
+This document provides information about U-Boot running on top of EFI, either
+as an application or just as a means of getting U-Boot onto a new platform.
+
+
+Motivation
+----------
+Running U-Boot on EFI is useful in several situations:
+
+- You have EFI running on a board but U-Boot does not natively support it
+ fully yet. You can boot into U-Boot from EFI and use that until U-Boot is
+ fully ported
+
+- You need to use an EFI implementation (e.g. UEFI) because your vendor
+ requires it in order to provide support
+
+- You plan to use coreboot to boot into U-Boot but coreboot support does
+ not currently exist for your platform. In the meantime you can use U-Boot
+ on EFI and then move to U-Boot on coreboot when ready
+
+- You use EFI but want to experiment with a simpler alternative like U-Boot
+
+
+Status
+------
+Only x86 is supported at present. If you are using EFI on another architecture
+you may want to reconsider. However, much of the code is generic so could be
+ported.
+
+U-Boot supports running as an EFI application for 32-bit EFI only. This is
+not very useful since only a serial port is provided. You can look around at
+memory and type 'help' but that is about it.
+
+More usefully, U-Boot supports building itself as a payload for either 32-bit
+or 64-bit EFI. U-Boot is packaged up and loaded in its entirety by EFI. Once
+started, U-Boot changes to 32-bit mode (currently) and takes over the
+machine. You can use devices, boot a kernel, etc.
+
+
+Build Instructions
+------------------
+First choose a board that has EFI support and obtain an EFI implementation
+for that board. It will be either 32-bit or 64-bit. Alternatively, you can
+opt for using QEMU [1] and the OVMF [2], as detailed below.
+
+To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
+and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app_defconfig) is set up
+for this. Just build U-Boot as normal, e.g.::
+
+ make efi-x86_app_defconfig
+ make
+
+To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable
+CONFIG_EFI, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or
+CONFIG_EFI_STUB_64BIT. The efi-x86_payload configs (efi-x86_payload32_defconfig
+and efi-x86_payload32_defconfig) are set up for this. Then build U-Boot as
+normal, e.g.::
+
+ make efi-x86_payload32_defconfig (or efi-x86_payload64_defconfig)
+ make
+
+You will end up with one of these files depending on what you build for:
+
+* u-boot-app.efi - U-Boot EFI application
+* u-boot-payload.efi - U-Boot EFI payload application
+
+
+Trying it out
+-------------
+QEMU is an emulator and it can emulate an x86 machine. Please make sure your
+QEMU version is 2.3.0 or above to test this. You can run the payload with
+something like this::
+
+ mkdir /tmp/efi
+ cp /path/to/u-boot*.efi /tmp/efi
+ qemu-system-x86_64 -bios bios.bin -hda fat:/tmp/efi/
+
+Add -nographic if you want to use the terminal for output. Once it starts
+type 'fs0:u-boot-payload.efi' to run the payload or 'fs0:u-boot-app.efi' to
+run the application. 'bios.bin' is the EFI 'BIOS'. Check [2] to obtain a
+prebuilt EFI BIOS for QEMU or you can build one from source as well.
+
+To try it on real hardware, put u-boot-app.efi on a suitable boot medium,
+such as a USB stick. Then you can type something like this to start it::
+
+ fs0:u-boot-payload.efi
+
+(or fs0:u-boot-app.efi for the application)
+
+This will start the payload, copy U-Boot into RAM and start U-Boot. Note
+that EFI does not support booting a 64-bit application from a 32-bit
+EFI (or vice versa). Also it will often fail to print an error message if
+you get this wrong.
+
+
+Inner workings
+--------------
+Here follow a few implementation notes for those who want to fiddle with
+this and perhaps contribute patches.
+
+The application and payload approaches sound similar but are in fact
+implemented completely differently.
+
+EFI Application
+~~~~~~~~~~~~~~~
+For the application the whole of U-Boot is built as a shared library. The
+efi_main() function is in lib/efi/efi_app.c. It sets up some basic EFI
+functions with efi_init(), sets up U-Boot global_data, allocates memory for
+U-Boot's malloc(), etc. and enters the normal init sequence (board_init_f()
+and board_init_r()).
+
+Since U-Boot limits its memory access to the allocated regions very little
+special code is needed. The CONFIG_EFI_APP option controls a few things
+that need to change so 'git grep CONFIG_EFI_APP' may be instructive.
+The CONFIG_EFI option controls more general EFI adjustments.
+
+The only available driver is the serial driver. This calls back into EFI
+'boot services' to send and receive characters. Although it is implemented
+as a serial driver the console device is not necessarilly serial. If you
+boot EFI with video output then the 'serial' device will operate on your
+target devices's display instead and the device's USB keyboard will also
+work if connected. If you have both serial and video output, then both
+consoles will be active. Even though U-Boot does the same thing normally,
+These are features of EFI, not U-Boot.
+
+Very little code is involved in implementing the EFI application feature.
+U-Boot is highly portable. Most of the difficulty is in modifying the
+Makefile settings to pass the right build flags. In particular there is very
+little x86-specific code involved - you can find most of it in
+arch/x86/cpu. Porting to ARM (which can also use EFI if you are brave
+enough) should be straightforward.
+
+Use the 'reset' command to get back to EFI.
+
+EFI Payload
+~~~~~~~~~~~
+The payload approach is a different kettle of fish. It works by building
+U-Boot exactly as normal for your target board, then adding the entire
+image (including device tree) into a small EFI stub application responsible
+for booting it. The stub application is built as a normal EFI application
+except that it has a lot of data attached to it.
+
+The stub application is implemented in lib/efi/efi_stub.c. The efi_main()
+function is called by EFI. It is responsible for copying U-Boot from its
+original location into memory, disabling EFI boot services and starting
+U-Boot. U-Boot then starts as normal, relocates, starts all drivers, etc.
+
+The stub application is architecture-dependent. At present it has some
+x86-specific code and a comment at the top of efi_stub.c describes this.
+
+While the stub application does allocate some memory from EFI this is not
+used by U-Boot (the payload). In fact when U-Boot starts it has all of the
+memory available to it and can operate as it pleases (but see the next
+section).
+
+Tables
+~~~~~~
+The payload can pass information to U-Boot in the form of EFI tables. At
+present this feature is used to pass the EFI memory map, an inordinately
+large list of memory regions. You can use the 'efi mem all' command to
+display this list. U-Boot uses the list to work out where to relocate
+itself.
+
+Although U-Boot can use any memory it likes, EFI marks some memory as used
+by 'run-time services', code that hangs around while U-Boot is running and
+is even present when Linux is running. This is common on x86 and provides
+a way for Linux to call back into the firmware to control things like CPU
+fan speed. U-Boot uses only 'conventional' memory, in EFI terminology. It
+will relocate itself to the top of the largest block of memory it can find
+below 4GB.
+
+Interrupts
+~~~~~~~~~~
+U-Boot drivers typically don't use interrupts. Since EFI enables interrupts
+it is possible that an interrupt will fire that U-Boot cannot handle. This
+seems to cause problems. For this reason the U-Boot payload runs with
+interrupts disabled at present.
+
+32/64-bit
+~~~~~~~~~
+While the EFI application can in principle be built as either 32- or 64-bit,
+only 32-bit is currently supported. This means that the application can only
+be used with 32-bit EFI.
+
+The payload stub can be build as either 32- or 64-bits. Only a small amount
+of code is built this way (see the extra- line in lib/efi/Makefile).
+Everything else is built as a normal U-Boot, so is always 32-bit on x86 at
+present.
+
+Future work
+-----------
+This work could be extended in a number of ways:
+
+- Add ARM support
+
+- Add 64-bit application support
+
+- Figure out how to solve the interrupt problem
+
+- Add more drivers to the application side (e.g. video, block devices, USB,
+ environment access). This would mostly be an academic exercise as a strong
+ use case is not readily apparent, but it might be fun.
+
+- Avoid turning off boot services in the stub. Instead allow U-Boot to make
+ use of boot services in case it wants to. It is unclear what it might want
+ though.
+
+Where is the code?
+------------------
+lib/efi
+ payload stub, application, support code. Mostly arch-neutral
+
+arch/x86/cpu/efi
+ x86 support code for running as an EFI application and payload
+
+board/efi/efi-x86_app/efi.c
+ x86 board code for running as an EFI application
+
+board/efi/efi-x86_payload
+ generic x86 EFI payload board support code
+
+common/cmd_efi.c
+ the 'efi' command
+
+--
+Ben Stoltz, Simon Glass
+Google, Inc
+July 2015
+
+* [1] http://www.qemu.org
+* [2] http://www.tianocore.org/ovmf/
diff --git a/roms/u-boot/doc/develop/uefi/uefi.rst b/roms/u-boot/doc/develop/uefi/uefi.rst
new file mode 100644
index 000000000..4f2b8b036
--- /dev/null
+++ b/roms/u-boot/doc/develop/uefi/uefi.rst
@@ -0,0 +1,574 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2018 Heinrich Schuchardt
+
+UEFI on U-Boot
+==============
+
+The Unified Extensible Firmware Interface Specification (UEFI) [1] has become
+the default for booting on AArch64 and x86 systems. It provides a stable API for
+the interaction of drivers and applications with the firmware. The API comprises
+access to block storage, network, and console to name a few. The Linux kernel
+and boot loaders like GRUB or the FreeBSD loader can be executed.
+
+Development target
+------------------
+
+The implementation of UEFI in U-Boot strives to reach the requirements described
+in the "Embedded Base Boot Requirements (EBBR) Specification - Release v1.0"
+[2]. The "Server Base Boot Requirements System Software on ARM Platforms" [3]
+describes a superset of the EBBR specification and may be used as further
+reference.
+
+A full blown UEFI implementation would contradict the U-Boot design principle
+"keep it small".
+
+Building U-Boot for UEFI
+------------------------
+
+The UEFI standard supports only little-endian systems. The UEFI support can be
+activated for ARM and x86 by specifying::
+
+ CONFIG_CMD_BOOTEFI=y
+ CONFIG_EFI_LOADER=y
+
+in the .config file.
+
+Support for attaching virtual block devices, e.g. iSCSI drives connected by the
+loaded UEFI application [4], requires::
+
+ CONFIG_BLK=y
+ CONFIG_PARTITIONS=y
+
+Executing a UEFI binary
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The bootefi command is used to start UEFI applications or to install UEFI
+drivers. It takes two parameters::
+
+ bootefi <image address> [fdt address]
+
+* image address - the memory address of the UEFI binary
+* fdt address - the memory address of the flattened device tree
+
+Below you find the output of an example session starting GRUB::
+
+ => load mmc 0:2 ${fdt_addr_r} boot/dtb
+ 29830 bytes read in 14 ms (2 MiB/s)
+ => load mmc 0:1 ${kernel_addr_r} efi/debian/grubaa64.efi
+ reading efi/debian/grubaa64.efi
+ 120832 bytes read in 7 ms (16.5 MiB/s)
+ => bootefi ${kernel_addr_r} ${fdt_addr_r}
+
+When booting from a memory location it is unknown from which file it was loaded.
+Therefore the bootefi command uses the device path of the block device partition
+or the network adapter and the file name of the most recently loaded PE-COFF
+file when setting up the loaded image protocol.
+
+Launching a UEFI binary from a FIT image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A signed FIT image can be used to securely boot a UEFI image via the
+bootm command. This feature is available if U-Boot is configured with::
+
+ CONFIG_BOOTM_EFI=y
+
+A sample configuration is provided as file doc/uImage.FIT/uefi.its.
+
+Below you find the output of an example session starting GRUB::
+
+ => load mmc 0:1 ${kernel_addr_r} image.fit
+ 4620426 bytes read in 83 ms (53.1 MiB/s)
+ => bootm ${kernel_addr_r}#config-grub-nofdt
+ ## Loading kernel from FIT Image at 40400000 ...
+ Using 'config-grub-nofdt' configuration
+ Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
+ Trying 'efi-grub' kernel subimage
+ Description: GRUB EFI Firmware
+ Created: 2019-11-20 8:18:16 UTC
+ Type: Kernel Image (no loading done)
+ Compression: uncompressed
+ Data Start: 0x404000d0
+ Data Size: 450560 Bytes = 440 KiB
+ Hash algo: sha256
+ Hash value: 4dbee00021112df618f58b3f7cf5e1595533d543094064b9ce991e8b054a9eec
+ Verifying Hash Integrity ... sha256+ OK
+ XIP Kernel Image (no loading done)
+ ## Transferring control to EFI (at address 404000d0) ...
+ Welcome to GRUB!
+
+See doc/uImage.FIT/howto.txt for an introduction to FIT images.
+
+Configuring UEFI secure boot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The UEFI specification[1] defines a secure way of executing UEFI images
+by verifying a signature (or message digest) of image with certificates.
+This feature on U-Boot is enabled with::
+
+ CONFIG_UEFI_SECURE_BOOT=y
+
+To make the boot sequence safe, you need to establish a chain of trust;
+In UEFI secure boot the chain trust is defined by the following UEFI variables
+
+* PK - Platform Key
+* KEK - Key Exchange Keys
+* db - white list database
+* dbx - black list database
+
+An in depth description of UEFI secure boot is beyond the scope of this
+document. Please, refer to the UEFI specification and available online
+documentation. Here is a simple example that you can follow for your initial
+attempt (Please note that the actual steps will depend on your system and
+environment.):
+
+Install the required tools on your host
+
+* openssl
+* efitools
+* sbsigntool
+
+Create signing keys and the key database on your host:
+
+The platform key
+
+.. code-block:: bash
+
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \
+ -keyout PK.key -out PK.crt -nodes -days 365
+ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
+ PK.crt PK.esl;
+ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
+
+The key exchange keys
+
+.. code-block:: bash
+
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \
+ -keyout KEK.key -out KEK.crt -nodes -days 365
+ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
+ KEK.crt KEK.esl
+ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
+
+The whitelist database
+
+.. code-block:: bash
+
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
+ -keyout db.key -out db.crt -nodes -days 365
+ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
+ db.crt db.esl
+ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
+
+Copy the \*.auth files to media, say mmc, that is accessible from U-Boot.
+
+Sign an image with one of the keys in "db" on your host
+
+.. code-block:: bash
+
+ sbsign --key db.key --cert db.crt helloworld.efi
+
+Now in U-Boot install the keys on your board::
+
+ fatload mmc 0:1 <tmpaddr> PK.auth
+ setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK
+ fatload mmc 0:1 <tmpaddr> KEK.auth
+ setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK
+ fatload mmc 0:1 <tmpaddr> db.auth
+ setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize db
+
+Set up boot parameters on your board::
+
+ efidebug boot add -b 1 HELLO mmc 0:1 /helloworld.efi.signed ""
+
+Since kernel 5.7 there's an alternative way of loading an initrd using
+LoadFile2 protocol if CONFIG_EFI_LOAD_FILE2_INITRD is enabled.
+The initrd path can be specified with::
+
+ efidebug boot add -b ABE0 'kernel' mmc 0:1 Image -i mmc 0:1 initrd
+
+Now your board can run the signed image via the boot manager (see below).
+You can also try this sequence by running Pytest, test_efi_secboot,
+on the sandbox
+
+.. code-block:: bash
+
+ cd <U-Boot source directory>
+ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
+
+UEFI binaries may be signed by Microsoft using the following certificates:
+
+* KEK: Microsoft Corporation KEK CA 2011
+ http://go.microsoft.com/fwlink/?LinkId=321185.
+* db: Microsoft Windows Production PCA 2011
+ http://go.microsoft.com/fwlink/p/?linkid=321192.
+* db: Microsoft Corporation UEFI CA 2011
+ http://go.microsoft.com/fwlink/p/?linkid=321194.
+
+Using OP-TEE for EFI variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Instead of implementing UEFI variable services inside U-Boot they can
+also be provided in the secure world by a module for OP-TEE[1]. The
+interface between U-Boot and OP-TEE for variable services is enabled by
+CONFIG_EFI_MM_COMM_TEE=y.
+
+Tianocore EDK II's standalone management mode driver for variables can
+be linked to OP-TEE for this purpose. This module uses the Replay
+Protected Memory Block (RPMB) of an eMMC device for persisting
+non-volatile variables. When calling the variable services via the
+OP-TEE API U-Boot's OP-TEE supplicant relays calls to the RPMB driver
+which has to be enabled via CONFIG_SUPPORT_EMMC_RPMB=y.
+
+EDK2 Build instructions
+***********************
+
+.. code-block:: bash
+
+ $ git clone https://github.com/tianocore/edk2.git
+ $ git clone https://github.com/tianocore/edk2-platforms.git
+ $ cd edk2
+ $ git submodule init && git submodule update --init --recursive
+ $ cd ..
+ $ export WORKSPACE=$(pwd)
+ $ export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms
+ $ export ACTIVE_PLATFORM="Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc"
+ $ export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
+ $ source edk2/edksetup.sh
+ $ make -C edk2/BaseTools
+ $ build -p $ACTIVE_PLATFORM -b RELEASE -a AARCH64 -t GCC5 -n `nproc`
+
+OP-TEE Build instructions
+*************************
+
+.. code-block:: bash
+
+ $ git clone https://github.com/OP-TEE/optee_os.git
+ $ cd optee_os
+ $ ln -s ../Build/MmStandaloneRpmb/RELEASE_GCC5/FV/BL32_AP_MM.fd
+ $ export ARCH=arm
+ $ CROSS_COMPILE32=arm-linux-gnueabihf- make -j32 CFG_ARM64_core=y \
+ PLATFORM=<myboard> CFG_STMM_PATH=BL32_AP_MM.fd CFG_RPMB_FS=y \
+ CFG_RPMB_FS_DEV_ID=0 CFG_CORE_HEAP_SIZE=524288 CFG_RPMB_WRITE_KEY=1 \
+ CFG_CORE_HEAP_SIZE=524288 CFG_CORE_DYN_SHM=y CFG_RPMB_TESTKEY=y \
+ CFG_REE_FS=n CFG_CORE_ARM64_PA_BITS=48 CFG_TEE_CORE_LOG_LEVEL=1 \
+ CFG_TEE_TA_LOG_LEVEL=1 CFG_SCTLR_ALIGNMENT_CHECK=n
+
+U-Boot Build instructions
+*************************
+
+Although the StandAloneMM binary comes from EDK2, using and storing the
+variables is currently available in U-Boot only.
+
+.. code-block:: bash
+
+ $ git clone https://github.com/u-boot/u-boot.git
+ $ cd u-boot
+ $ export CROSS_COMPILE=aarch64-linux-gnu-
+ $ export ARCH=<arch>
+ $ make <myboard>_defconfig
+ $ make menuconfig
+
+Enable ``CONFIG_OPTEE``, ``CONFIG_CMD_OPTEE_RPMB`` and ``CONFIG_EFI_MM_COMM_TEE``
+
+.. warning::
+
+ - Your OP-TEE platform port must support Dynamic shared memory, since that's
+ the only kind of memory U-Boot supports for now.
+
+[1] https://optee.readthedocs.io/en/latest/building/efi_vars/stmm.html
+
+Executing the boot manager
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The UEFI specification foresees to define boot entries and boot sequence via
+UEFI variables. Booting according to these variables is possible via::
+
+ bootefi bootmgr [fdt address]
+
+As of U-Boot v2020.10 UEFI variables cannot be set at runtime. The U-Boot
+command 'efidebug' can be used to set the variables.
+
+Executing the built in hello world application
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A hello world UEFI application can be built with::
+
+ CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
+
+It can be embedded into the U-Boot binary with::
+
+ CONFIG_CMD_BOOTEFI_HELLO=y
+
+The bootefi command is used to start the embedded hello world application::
+
+ bootefi hello [fdt address]
+
+Below you find the output of an example session::
+
+ => bootefi hello ${fdtcontroladdr}
+ ## Starting EFI application at 01000000 ...
+ WARNING: using memory device/image path, this may confuse some payloads!
+ Hello, world!
+ Running on UEFI 2.7
+ Have SMBIOS table
+ Have device tree
+ Load options: root=/dev/sdb3 init=/sbin/init rootwait ro
+ ## Application terminated, r = 0
+
+The environment variable fdtcontroladdr points to U-Boot's internal device tree
+(if available).
+
+Executing the built-in self-test
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An UEFI self-test suite can be embedded in U-Boot by building with::
+
+ CONFIG_CMD_BOOTEFI_SELFTEST=y
+
+For testing the UEFI implementation the bootefi command can be used to start the
+self-test::
+
+ bootefi selftest [fdt address]
+
+The environment variable 'efi_selftest' can be used to select a single test. If
+it is not provided all tests are executed except those marked as 'on request'.
+If the environment variable is set to 'list' a list of all tests is shown.
+
+Below you can find the output of an example session::
+
+ => setenv efi_selftest simple network protocol
+ => bootefi selftest
+ Testing EFI API implementation
+ Selected test: 'simple network protocol'
+ Setting up 'simple network protocol'
+ Setting up 'simple network protocol' succeeded
+ Executing 'simple network protocol'
+ DHCP Discover
+ DHCP reply received from 192.168.76.2 (52:55:c0:a8:4c:02)
+ as broadcast message.
+ Executing 'simple network protocol' succeeded
+ Tearing down 'simple network protocol'
+ Tearing down 'simple network protocol' succeeded
+ Boot services terminated
+ Summary: 0 failures
+ Preparing for reset. Press any key.
+
+The UEFI life cycle
+-------------------
+
+After the U-Boot platform has been initialized the UEFI API provides two kinds
+of services:
+
+* boot services
+* runtime services
+
+The API can be extended by loading UEFI drivers which come in two variants:
+
+* boot drivers
+* runtime drivers
+
+UEFI drivers are installed with U-Boot's bootefi command. With the same command
+UEFI applications can be executed.
+
+Loaded images of UEFI drivers stay in memory after returning to U-Boot while
+loaded images of applications are removed from memory.
+
+An UEFI application (e.g. an operating system) that wants to take full control
+of the system calls ExitBootServices. After a UEFI application calls
+ExitBootServices
+
+* boot services are not available anymore
+* timer events are stopped
+* the memory used by U-Boot except for runtime services is released
+* the memory used by boot time drivers is released
+
+So this is a point of no return. Afterwards the UEFI application can only return
+to U-Boot by rebooting.
+
+The UEFI object model
+---------------------
+
+UEFI offers a flexible and expandable object model. The objects in the UEFI API
+are devices, drivers, and loaded images. These objects are referenced by
+handles.
+
+The interfaces implemented by the objects are referred to as protocols. These
+are identified by GUIDs. They can be installed and uninstalled by calling the
+appropriate boot services.
+
+Handles are created by the InstallProtocolInterface or the
+InstallMultipleProtocolinterfaces service if NULL is passed as handle.
+
+Handles are deleted when the last protocol has been removed with the
+UninstallProtocolInterface or the UninstallMultipleProtocolInterfaces service.
+
+Devices offer the EFI_DEVICE_PATH_PROTOCOL. A device path is the concatenation
+of device nodes. By their device paths all devices of a system are arranged in a
+tree.
+
+Drivers offer the EFI_DRIVER_BINDING_PROTOCOL. This protocol is used to connect
+a driver to devices (which are referenced as controllers in this context).
+
+Loaded images offer the EFI_LOADED_IMAGE_PROTOCOL. This protocol provides meta
+information about the image and a pointer to the unload callback function.
+
+The UEFI events
+---------------
+
+In the UEFI terminology an event is a data object referencing a notification
+function which is queued for calling when the event is signaled. The following
+types of events exist:
+
+* periodic and single shot timer events
+* exit boot services events, triggered by calling the ExitBootServices() service
+* virtual address change events
+* memory map change events
+* read to boot events
+* reset system events
+* system table events
+* events that are only triggered programmatically
+
+Events can be created with the CreateEvent service and deleted with CloseEvent
+service.
+
+Events can be assigned to an event group. If any of the events in a group is
+signaled, all other events in the group are also set to the signaled state.
+
+The UEFI driver model
+---------------------
+
+A driver is specific for a single protocol installed on a device. To install a
+driver on a device the ConnectController service is called. In this context
+controller refers to the device for which the driver is installed.
+
+The relevant drivers are identified using the EFI_DRIVER_BINDING_PROTOCOL. This
+protocol has has three functions:
+
+* supported - determines if the driver is compatible with the device
+* start - installs the driver by opening the relevant protocol with
+ attribute EFI_OPEN_PROTOCOL_BY_DRIVER
+* stop - uninstalls the driver
+
+The driver may create child controllers (child devices). E.g. a driver for block
+IO devices will create the device handles for the partitions. The child
+controllers will open the supported protocol with the attribute
+EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER.
+
+A driver can be detached from a device using the DisconnectController service.
+
+U-Boot devices mapped as UEFI devices
+-------------------------------------
+
+Some of the U-Boot devices are mapped as UEFI devices
+
+* block IO devices
+* console
+* graphical output
+* network adapter
+
+As of U-Boot 2018.03 the logic for doing this is hard coded.
+
+The development target is to integrate the setup of these UEFI devices with the
+U-Boot driver model [5]. So when a U-Boot device is discovered a handle should
+be created and the device path protocol and the relevant IO protocol should be
+installed. The UEFI driver then would be attached by calling ConnectController.
+When a U-Boot device is removed DisconnectController should be called.
+
+UEFI devices mapped as U-Boot devices
+-------------------------------------
+
+UEFI drivers binaries and applications may create new (virtual) devices, install
+a protocol and call the ConnectController service. Now the matching UEFI driver
+is determined by iterating over the implementations of the
+EFI_DRIVER_BINDING_PROTOCOL.
+
+It is the task of the UEFI driver to create a corresponding U-Boot device and to
+proxy calls for this U-Boot device to the controller.
+
+In U-Boot 2018.03 this has only been implemented for block IO devices.
+
+UEFI uclass
+~~~~~~~~~~~
+
+An UEFI uclass driver (lib/efi_driver/efi_uclass.c) has been created that
+takes care of initializing the UEFI drivers and providing the
+EFI_DRIVER_BINDING_PROTOCOL implementation for the UEFI drivers.
+
+A linker created list is used to keep track of the UEFI drivers. To create an
+entry in the list the UEFI driver uses the U_BOOT_DRIVER macro specifying
+UCLASS_EFI as the ID of its uclass, e.g::
+
+ /* Identify as UEFI driver */
+ U_BOOT_DRIVER(efi_block) = {
+ .name = "EFI block driver",
+ .id = UCLASS_EFI,
+ .ops = &driver_ops,
+ };
+
+The available operations are defined via the structure struct efi_driver_ops::
+
+ struct efi_driver_ops {
+ const efi_guid_t *protocol;
+ const efi_guid_t *child_protocol;
+ int (*bind)(efi_handle_t handle, void *interface);
+ };
+
+When the supported() function of the EFI_DRIVER_BINDING_PROTOCOL is called the
+uclass checks if the protocol GUID matches the protocol GUID of the UEFI driver.
+In the start() function the bind() function of the UEFI driver is called after
+checking the GUID.
+The stop() function of the EFI_DRIVER_BINDING_PROTOCOL disconnects the child
+controllers created by the UEFI driver and the UEFI driver. (In U-Boot v2013.03
+this is not yet completely implemented.)
+
+UEFI block IO driver
+~~~~~~~~~~~~~~~~~~~~
+
+The UEFI block IO driver supports devices exposing the EFI_BLOCK_IO_PROTOCOL.
+
+When connected it creates a new U-Boot block IO device with interface type
+IF_TYPE_EFI, adds child controllers mapping the partitions, and installs the
+EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on these. This can be used together with the
+software iPXE to boot from iSCSI network drives [4].
+
+This driver is only available if U-Boot is configured with::
+
+ CONFIG_BLK=y
+ CONFIG_PARTITIONS=y
+
+Miscellaneous
+-------------
+
+Load file 2 protocol
+~~~~~~~~~~~~~~~~~~~~
+
+The load file 2 protocol can be used by the Linux kernel to load the initial
+RAM disk. U-Boot can be configured to provide an implementation with::
+
+ EFI_LOAD_FILE2_INITRD=y
+
+When the option is enabled the user can add the initrd path with the efidebug
+command.
+
+Load options Boot#### have a FilePathList[] member. The first element of
+the array (FilePathList[0]) is the EFI binary to execute. When an initrd
+is specified the Device Path for the initrd is denoted by a VenMedia node
+with the EFI_INITRD_MEDIA_GUID. Each entry of the array is terminated by the
+'end of entire device path' subtype (0xff). If a user wants to define multiple
+initrds, those must by separated by the 'end of this instance' identifier of
+the end node (0x01).
+
+So our final format of the FilePathList[] is::
+
+ Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
+
+Links
+-----
+
+* [1] http://uefi.org/specifications - UEFI specifications
+* [2] https://github.com/ARM-software/ebbr/releases/download/v1.0/ebbr-v1.0.pdf -
+ Embedded Base Boot Requirements (EBBR) Specification - Release v1.0
+* [3] https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11 -
+ Server Base Boot Requirements System Software on ARM Platforms - Version 1.1
+* [4] :doc:`iscsi`
+* [5] :doc:`../driver-model/index`
diff --git a/roms/u-boot/doc/develop/version.rst b/roms/u-boot/doc/develop/version.rst
new file mode 100644
index 000000000..a7797db41
--- /dev/null
+++ b/roms/u-boot/doc/develop/version.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2013 The Chromium OS Authors.
+
+Version information
+===================
+
+U-Boot releases are named by year and patch level, for example 2020.10 means the
+release that came out in October 2020. Release candidates are tagged every few
+weeks as the project heads to the next release. So 2020.10-rc1 was the first
+release candidate (RC), tagged soon after 2020.07 was released.
+
+See https://www.denx.de/wiki/view/U-Boot/ReleaseCycle for full details.
+
+Within the build system, various Makefile variables are created, making use of
+VERSION, PATCHLEVEL and EXTRAVERSION defined at the top of 'Makefile'. There is
+also SUBLEVEL available for downstream use. See also CONFIG_IDENT_STRING.
+
+Some variables end up in a generated header file at
+include/generated/version_autogenerated.h and can be accessed from C source by
+including <version.h>
+
+The following are available:
+
+ UBOOTRELEASE (Makefile)
+ Full release version as a string. If this is not a tagged release, it also
+ includes the number of commits since the last tag as well as the the git
+ hash. If there are uncommitted changes a '-dirty' suffix is added too.
+
+ This is written by scripts/setlocalversion (maintained by Linux) to
+ include/config/uboot.release and ends up in the UBOOTRELEASE Makefile
+ variable.
+
+ Examples::
+
+ 2020.10-rc3
+ 2021.01-rc5-00248-g60dd854f3ba-dirty
+
+ PLAIN_VERSION (string #define)
+ This is UBOOTRELEASE but available in C source.
+
+ Examples::
+
+ 2020.10
+ 2021.01-rc5-00248-g60dd854f3ba-dirty
+
+ UBOOTVERSION (Makefile)
+ This holds just the first three components of UBOOTRELEASE (i.e. not the
+ git hash, etc.)
+
+ Examples::
+
+ 2020.10
+ 2021.01-rc5
+
+ U_BOOT_VERSION (string #define)
+ "U-Boot " followed by UBOOTRELEASE, for example::
+
+ U-Boot 2020.10
+ U-Boot 2021.01-rc5
+
+ This is used as part of the banner string when U-Boot starts.
+
+ U_BOOT_VERSION_STRING (string #define)
+ U_BOOT_VERSION followed by build-time information
+ and CONFIG_IDENT_STRING.
+
+ Examples::
+
+ U-Boot 2020.10 (Jan 06 2021 - 08:50:36 -0700)
+ U-Boot 2021.01-rc5-00248-g60dd854f3ba-dirty (Jan 06 2021 - 08:50:36 -0700) for spring
+
+ U_BOOT_VERSION_NUM (integer #define)
+ Release year, e.g. 2021 for release 2021.01. Note
+ this is an integer, not a string.
+
+ U_BOOT_VERSION_NUM_PATCH (integer #define)
+ Patch number, e.g. 1 for release 2020.01. Note
+ this is an integer, not a string.
+
+Build date/time is also included. See the generated file
+include/generated/timestamp_autogenerated.h for the available
+fields. For example::
+
+ #define U_BOOT_DATE "Jan 06 2021" (US format only)
+ #define U_BOOT_TIME "08:50:36" (24-hour clock)
+ #define U_BOOT_TZ "-0700" (Time zone in hours)
+ #define U_BOOT_DMI_DATE "01/06/2021" (US format only)
+ #define U_BOOT_BUILD_DATE 0x20210106 (hex yyyymmdd format)
+ #define U_BOOT_EPOCH 1609948236
+
+The Epoch is the number of seconds since midnight on 1/1/70. You can convert
+this to a time with::
+
+ $ date -u -d @1609948236
+ Wed 06 Jan 2021 03:50:36 PM UTC
+ $ date -d 'Wed 06 Jan 2021 03:50:36 PM UTC' +%s
+ 1609948236
+
+Every time you build U-Boot this will update based on the time
+on your build machine. See 'Reproducible builds' if you want to
+avoid that.
diff --git a/roms/u-boot/doc/device-tree-bindings/README b/roms/u-boot/doc/device-tree-bindings/README
new file mode 100644
index 000000000..2ea3439a1
--- /dev/null
+++ b/roms/u-boot/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/roms/u-boot/doc/device-tree-bindings/adc/adc.txt b/roms/u-boot/doc/device-tree-bindings/adc/adc.txt
new file mode 100644
index 000000000..463de3c8c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/adc/adc.txt
@@ -0,0 +1,62 @@
+ADC device binding
+
+There are no mandatory properties for ADC. However, if Voltage info is required,
+then there are two options:
+- use microvolts constraint or
+- use regulator phandle to enable/read supply's Voltage
+
+Properties and constraints:
+*optional and always checked, Voltage polarity info:
+- vdd-polarity-negative: positive reference Voltage has a negative polarity
+- vss-polarity-negative: negative reference Voltage has a negative polarity
+
+Chose one option, for each supply (Vdd/Vss):
+
+*optional and always checked, supply Voltage constants:
+- vdd-supply: phandle to Vdd regulator's node
+- vss-supply: phandle to Vss regulator's node
+
+*optional and checked only if the above corresponding, doesn't exist:
+- vdd-microvolts: positive reference Voltage value [uV]
+- vss-microvolts: negative reference Voltage value [uV]
+
+Example with constant 'Vdd' value:
+adc@1000000 {
+ compatible = "some-adc";
+ reg = <0xaabb000 0x100>;
+ status = "enabled";
+ vdd-microvolts = <1800000>;
+};
+
+Example of supply phandle usage, for the ADC's VDD/VSS references as below:
+ _______ _______
+ |Sandbox| |Sandbox|
+ : PMIC : : ADC :
+ . . . .
+ | | (Vdd) | AIN0|-->
+ | BUCK2|-------|VDDref |
+ | (3.3V)| _|VSSref |
+ |_______| | |_______|
+ _|_
+
+For the above PMIC, the node can be defined as follows:
+sandbox_pmic {
+ compatible = "sandbox,pmic";
+ ...
+ buck2: buck2 {
+ regulator-name = "SUPPLY_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ...
+};
+
+For the above ADC, the node can be defined as follows:
+adc@0 {
+ compatible = "sandbox,adc";
+ vdd-supply = <&buck2>;
+ vss-microvolts = <0>;
+};
+
+The ADC uclass code, will enable the supply before start of the conversion,
+but it will not configure the regulator settings.
diff --git a/roms/u-boot/doc/device-tree-bindings/adc/st,stm32-adc.txt b/roms/u-boot/doc/device-tree-bindings/adc/st,stm32-adc.txt
new file mode 100644
index 000000000..07fb6cd76
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/adc/st,stm32-adc.txt
@@ -0,0 +1,141 @@
+STMicroelectronics STM32 ADC device
+
+STM32 ADC is a successive approximation analog-to-digital converter.
+It has several multiplexed input channels. Conversions can be performed
+in single, continuous, scan or discontinuous mode. Result of the ADC is
+stored in a left-aligned or right-aligned 32-bit data register.
+Conversions can be launched in software or using hardware triggers.
+
+The analog watchdog feature allows the application to detect if the input
+voltage goes beyond the user-defined, higher or lower thresholds.
+
+Each STM32 ADC block can have up to 3 ADC instances.
+
+Each instance supports two contexts to manage conversions, each one has its
+own configurable sequence and trigger:
+- regular conversion can be done in sequence, running in background
+- injected conversions have higher priority, and so have the ability to
+ interrupt regular conversion sequence (either triggered in SW or HW).
+ Regular sequence is resumed, in case it has been interrupted.
+
+Contents of a stm32 adc root node:
+-----------------------------------
+Required properties:
+- compatible: Should be one of:
+ "st,stm32f4-adc-core"
+ "st,stm32h7-adc-core"
+ "st,stm32mp1-adc-core"
+- reg: Offset and length of the ADC block register set.
+- interrupts: One or more interrupts for ADC block. Some parts like stm32f4
+ and stm32h7 share a common ADC interrupt line. stm32mp1 has two separate
+ interrupt lines, one for each ADC within ADC block.
+- clocks: Core can use up to two clocks, depending on part used:
+ - "adc" clock: for the analog circuitry, common to all ADCs.
+ It's required on stm32f4.
+ It's optional on stm32h7.
+ - "bus" clock: for registers access, common to all ADCs.
+ It's not present on stm32f4.
+ It's required on stm32h7.
+- clock-names: Must be "adc" and/or "bus" depending on part used.
+- interrupt-controller: Identifies the controller node as interrupt-parent
+- vref-supply: Phandle to the vref input analog reference voltage.
+- #interrupt-cells = <1>;
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties:
+- A pinctrl state named "default" for each ADC channel may be defined to set
+ inX ADC pins in mode of operation for analog input on external pin.
+
+Contents of a stm32 adc child node:
+-----------------------------------
+An ADC block node should contain at least one subnode, representing an
+ADC instance available on the machine.
+
+Required properties:
+- compatible: Should be one of:
+ "st,stm32f4-adc"
+ "st,stm32h7-adc"
+ "st,stm32mp1-adc"
+- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
+- clocks: Input clock private to this ADC instance. It's required only on
+ stm32f4, that has per instance clock input for registers access.
+- interrupt-parent: Phandle to the parent interrupt controller.
+- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc@0, 1 for adc@100 or
+ 2 for adc@200).
+- st,adc-channels: List of single-ended channels muxed for this ADC.
+ It can have up to 16 channels on stm32f4 or 20 channels on stm32h7, numbered
+ from 0 to 15 or 19 (resp. for in0..in15 or in0..in19).
+- st,adc-diff-channels: List of differential channels muxed for this ADC.
+ Depending on part used, some channels can be configured as differential
+ instead of single-ended (e.g. stm32h7). List here positive and negative
+ inputs pairs as <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered
+ from 0 to 19 on stm32h7)
+ Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is required.
+ Both properties can be used together. Some channels can be used as
+ single-ended and some other ones as differential (mixed). But channels
+ can't be configured both as single-ended and differential (invalid).
+- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
+ Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Optional properties:
+- dmas: Phandle to dma channel for this ADC instance.
+ See ../../dma/dma.txt for details.
+- dma-names: Must be "rx" when dmas property is being used.
+- assigned-resolution-bits: Resolution (bits) to use for conversions. Must
+ match device available resolutions:
+ * can be 6, 8, 10 or 12 on stm32f4
+ * can be 8, 10, 12, 14 or 16 on stm32h7
+ Default is maximum resolution if unset.
+- st,min-sample-time-nsecs: Minimum sampling time in nanoseconds.
+ Depending on hardware (board) e.g. high/low analog input source impedance,
+ fine tune of ADC sampling time may be recommended.
+ This can be either one value or an array that matches 'st,adc-channels' list,
+ to set sample time resp. for all channels, or independently for each channel.
+
+Example:
+ adc: adc@40012000 {
+ compatible = "st,stm32f4-adc-core";
+ reg = <0x40012000 0x400>;
+ interrupts = <18>;
+ clocks = <&rcc 0 168>;
+ clock-names = "adc";
+ vref-supply = <&reg_vref>;
+ interrupt-controller;
+ pinctrl-names = "default";
+ pinctrl-0 = <&adc3_in8_pin>;
+
+ #interrupt-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "st,stm32f4-adc";
+ #io-channel-cells = <1>;
+ reg = <0x0>;
+ clocks = <&rcc 0 168>;
+ interrupt-parent = <&adc>;
+ interrupts = <0>;
+ st,adc-channels = <8>;
+ dmas = <&dma2 0 0 0x400 0x0>;
+ dma-names = "rx";
+ assigned-resolution-bits = <8>;
+ };
+ ...
+ other adc child nodes follow...
+ };
+
+Example to setup:
+- channel 1 as single-ended
+- channels 2 & 3 as differential (with resp. 6 & 7 negative inputs)
+
+ adc: adc@40022000 {
+ compatible = "st,stm32h7-adc-core";
+ ...
+ adc1: adc@0 {
+ compatible = "st,stm32h7-adc";
+ ...
+ st,adc-channels = <1>;
+ st,adc-diff-channels = <2 6>, <3 7>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/arm/arm,scmi.txt b/roms/u-boot/doc/device-tree-bindings/arm/arm,scmi.txt
new file mode 100644
index 000000000..a76124f4a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/arm/arm,scmi.txt
@@ -0,0 +1,231 @@
+System Control and Management Interface (SCMI) Message Protocol
+----------------------------------------------------------
+
+The SCMI is intended to allow agents such as OSPM to manage various functions
+that are provided by the hardware platform it is running on, including power
+and performance functions.
+
+This binding is intended to define the interface the firmware implementing
+the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
+and Management Interface Platform Design Document")[0] provide for OSPM in
+the device tree.
+
+Required properties:
+
+The scmi node with the following properties shall be under the /firmware/ node.
+
+- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
+- mboxes: List of phandle and mailbox channel specifiers. It should contain
+ exactly one or two mailboxes, one for transmitting messages("tx")
+ and another optional for receiving the notifications("rx") if
+ supported.
+- shmem : List of phandle pointing to the shared memory(SHM) area as per
+ generic mailbox client binding.
+- #address-cells : should be '1' if the device has sub-nodes, maps to
+ protocol identifier for a given sub-node.
+- #size-cells : should be '0' as 'reg' property doesn't have any size
+ associated with it.
+- arm,smc-id : SMC id required when using smc or hvc transports
+
+Optional properties:
+
+- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
+
+See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
+about the generic mailbox controller and client driver bindings.
+
+The mailbox is the only permitted method of calling the SCMI firmware.
+Mailbox doorbell is used as a mechanism to alert the presence of a
+messages and/or notification.
+
+Each protocol supported shall have a sub-node with corresponding compatible
+as described in the following sections. If the platform supports dedicated
+communication channel for a particular protocol, the 3 properties namely:
+mboxes, mbox-names and shmem shall be present in the sub-node corresponding
+to that protocol.
+
+Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
+
+Power domain bindings for the power domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+ - #power-domain-cells : Should be 1. Contains the device or the power
+ domain ID value used by SCMI commands.
+
+Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
+------------------------------------------------------------
+An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
+and should be always positioned as a root regulator.
+It does not support any current operation.
+
+SCMI Regulators are grouped under a 'regulators' node which in turn is a child
+of the SCMI Voltage protocol node inside the desired SCMI instance node.
+
+This binding uses the common regulator binding[6].
+
+Required properties:
+ - reg : shall identify an existent SCMI Voltage Domain.
+
+Sensor bindings for the sensors based on SCMI Message Protocol
+--------------------------------------------------------------
+SCMI provides an API to access the various sensors on the SoC.
+
+Required properties:
+- #thermal-sensor-cells: should be set to 1. This property follows the
+ thermal device tree bindings[3].
+
+ Valid cell values are raw identifiers (Sensor ID)
+ as used by the firmware. Refer to platform details
+ for your implementation for the IDs to use.
+
+Reset signal bindings for the reset domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI reset domain providers uses the generic reset
+signal binding[5].
+
+Required properties:
+ - #reset-cells : Should be 1. Contains the reset domain ID value used
+ by SCMI commands.
+
+SRAM and Shared Memory for SCMI
+-------------------------------
+
+A small area of SRAM is reserved for SCMI communication between application
+processors and SCP.
+
+The properties should follow the generic mmio-sram description found in [4]
+
+Each sub-node represents the reserved area for SCMI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
+ shared memory
+
+[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power-domain.yaml
+[3] Documentation/devicetree/bindings/thermal/thermal.txt
+[4] Documentation/devicetree/bindings/sram/sram.yaml
+[5] Documentation/devicetree/bindings/reset/reset.txt
+[6] Documentation/devicetree/bindings/regulator/regulator.yaml
+
+Example:
+
+sram@50000000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x50000000 0x0 0x10000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x10000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x200 0x200>;
+ };
+};
+
+mailbox@40000000 {
+ ....
+ #mbox-cells = <1>;
+ reg = <0x0 0x40000000 0x0 0x10000>;
+};
+
+firmware {
+
+ ...
+
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&mailbox 0 &mailbox 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ scmi_devpd: protocol@11 {
+ reg = <0x11>;
+ #power-domain-cells = <1>;
+ };
+
+ scmi_dvfs: protocol@13 {
+ reg = <0x13>;
+ #clock-cells = <1>;
+ };
+
+ scmi_clk: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+
+ scmi_sensors0: protocol@15 {
+ reg = <0x15>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
+
+ scmi_voltage: protocol@17 {
+ reg = <0x17>;
+
+ regulators {
+ regulator_devX: regulator@0 {
+ reg = <0x0>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ regulator_devY: regulator@9 {
+ reg = <0x9>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <4200000>;
+ };
+
+ ...
+ };
+ };
+ };
+};
+
+cpu@0 {
+ ...
+ reg = <0 0>;
+ clocks = <&scmi_dvfs 0>;
+};
+
+hdlcd@7ff60000 {
+ ...
+ reg = <0 0x7ff60000 0 0x1000>;
+ clocks = <&scmi_clk 4>;
+ power-domains = <&scmi_devpd 1>;
+ resets = <&scmi_reset 10>;
+};
+
+thermal-zones {
+ soc_thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <1000>;
+ /* sensor ID */
+ thermal-sensors = <&scmi_sensors0 3>;
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/arm/l2c2x0.txt b/roms/u-boot/doc/device-tree-bindings/arm/l2c2x0.txt
new file mode 100644
index 000000000..fbe6cb21f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/arm/l2c2x0.txt
@@ -0,0 +1,114 @@
+* ARM L2 Cache Controller
+
+ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
+PL310 and variants) based level 2 cache controller. All these various implementations
+of the L2 cache controller have compatible programming models (Note 1).
+Some of the properties that are just prefixed "cache-*" are taken from section
+3.7.3 of the Devicetree Specification which can be found at:
+https://www.devicetree.org/specifications/
+
+The ARM L2 cache representation in the device tree should be done as follows:
+
+Required properties:
+
+- compatible : should be one of:
+ "arm,pl310-cache"
+ "arm,l220-cache"
+ "arm,l210-cache"
+ "bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
+ "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+ offset needs to be added to the address before passing down to the L2
+ cache controller
+ "marvell,aurora-system-cache": Marvell Controller designed to be
+ compatible with the ARM one, with system cache mode (meaning
+ maintenance operations on L1 are broadcasted to the L2 and L2
+ performs the same operation).
+ "marvell,aurora-outer-cache": Marvell Controller designed to be
+ compatible with the ARM one with outer cache mode.
+ "marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
+ with arm,pl310-cache controller.
+- cache-unified : Specifies the cache is a unified cache.
+- cache-level : Should be set to 2 for a level 2 cache.
+- reg : Physical base address and size of cache controller's memory mapped
+ registers.
+
+Optional properties:
+
+- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
+ read, write and setup latencies. Minimum valid values are 1. Controllers
+ without setup latency control should use a value of 0.
+- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
+ read, write and setup latencies. Controllers without setup latency control
+ should use 0. Controllers without separate read and write Tag RAM latency
+ values should only use the first cell.
+- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
+- arm,filter-ranges : <start length> Starting address and length of window to
+ filter. Addresses in the filter window are directed to the M1 port. Other
+ addresses will go to the M0 port.
+- arm,io-coherent : indicates that the system is operating in an hardware
+ I/O coherent mode. Valid only when the arm,pl310-cache compatible
+ string is used.
+- interrupts : 1 combined interrupt.
+- cache-size : specifies the size in bytes of the cache
+- cache-sets : specifies the number of associativity sets of the cache
+- cache-block-size : specifies the size in bytes of a cache block
+- cache-line-size : specifies the size in bytes of a line in the cache,
+ if this is not specified, the line size is assumed to be equal to the
+ cache block size
+- cache-id-part: cache id part number to be used if it is not present
+ on hardware
+- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
+- arm,shared-override : The default behavior of the L220 or PL310 cache
+ controllers with respect to the shareable attribute is to transform "normal
+ memory non-cacheable transactions" into "cacheable no allocate" (for reads)
+ or "write through no write allocate" (for writes).
+ On systems where this may cause DMA buffer corruption, this property must be
+ specified to indicate that such transforms are precluded.
+- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
+- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
+ Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
+ will randomly hang unless outer sync operations are disabled.
+- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
+ (forcibly enable), property absent (retain settings set by firmware)
+- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
+ <1> (forcibly enable), property absent (retain settings set by
+ firmware)
+- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
+ disable), <1> (forcibly enable), property absent (OS specific behavior,
+ preferably retain firmware settings)
+- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
+ <1> (forcibly enable), property absent (OS specific behavior,
+ preferably retain firmware settings)
+- arm,early-bresp-disable : Disable the CA9 optimization Early BRESP (PL310)
+- arm,full-line-zero-disable : Disable the CA9 optimization Full line of zero
+ write (PL310)
+
+Example:
+
+L2: cache-controller {
+ compatible = "arm,pl310-cache";
+ reg = <0xfff12000 0x1000>;
+ arm,data-latency = <1 1 1>;
+ arm,tag-latency = <2 2 2>;
+ arm,filter-ranges = <0x80000000 0x8000000>;
+ cache-unified;
+ cache-level = <2>;
+ interrupts = <45>;
+};
+
+Note 1: The description in this document doesn't apply to integrated L2
+ cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
+ integrated L2 controllers are assumed to be all preconfigured by
+ early secure boot code. Thus no need to deal with their configuration
+ in the kernel at all.
diff --git a/roms/u-boot/doc/device-tree-bindings/ata/intel-sata.txt b/roms/u-boot/doc/device-tree-bindings/ata/intel-sata.txt
new file mode 100644
index 000000000..5e4da832a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/ata/intel-sata.txt
@@ -0,0 +1,26 @@
+Intel Pantherpoint SATA Device Binding
+======================================
+
+The device tree node which describes the operation of the Intel Pantherpoint
+SATA device is as follows:
+
+Required properties :
+- compatible = "intel,pantherpoint-ahci"
+- intel,sata-mode : string, one of:
+ "ahci" : Use AHCI mode (default)
+ "combined" : Use combined IDE + legacy mode
+ "plain-ide" : Use plain IDE mode
+- intel,sata-port-map : Which SATA ports are enabled, bit 0=enable first port,
+ bit 1=enable second port, etc.
+- intel,sata-port0-gen3-tx : Value for the IOBP_SP0G3IR register
+- intel,sata-port1-gen3-tx : Value for the IOBP_SP1G3IR register
+
+Example
+-------
+
+sata {
+ compatible = "intel,pantherpoint-ahci";
+ intel,sata-mode = "ahci";
+ intel,sata-port-map = <1>;
+ intel,sata-port0-gen3-tx = <0x00880a7f>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/axi/gdsys,ihs_axi.txt b/roms/u-boot/doc/device-tree-bindings/axi/gdsys,ihs_axi.txt
new file mode 100644
index 000000000..110788fa9
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/axi/gdsys,ihs_axi.txt
@@ -0,0 +1,22 @@
+gdsys AXI busses of IHS FPGA devices
+
+Certain gdsys IHS FPGAs offer a interface to their built-in AXI bus with which
+the connected devices (usually IP cores) can be controlled via software.
+
+Required properties:
+- compatible: must be "gdsys,ihs_axi"
+- reg: describes the address and length of the AXI bus's register map (within
+ the FPGA's register space)
+
+Example:
+
+fpga0_axi_video0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "gdsys,ihs_axi";
+ reg = <0x170 0x10>;
+
+ axi_dev_1 {
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/bus/simple-pm-bus.txt b/roms/u-boot/doc/device-tree-bindings/bus/simple-pm-bus.txt
new file mode 100644
index 000000000..6f1503713
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/bus/simple-pm-bus.txt
@@ -0,0 +1,44 @@
+Simple Power-Managed Bus
+========================
+
+A Simple Power-Managed Bus is a transparent bus that doesn't need a real
+driver, as it's typically initialized by the boot loader.
+
+However, its bus controller is part of a PM domain, or under the control of a
+functional clock. Hence, the bus controller's PM domain and/or clock must be
+enabled for child devices connected to the bus (either on-SoC or externally)
+to function.
+
+While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
+in the Devicetree Specification, it is not an extension of "simple-bus".
+
+
+Required properties:
+ - compatible: Must contain at least "simple-pm-bus".
+ Must not contain "simple-bus".
+ It's recommended to let this be preceded by one or more
+ vendor-specific compatible values.
+ - #address-cells, #size-cells, ranges: Must describe the mapping between
+ parent address and child address spaces.
+
+Optional platform-specific properties for clock or PM domain control (at least
+one of them is required):
+ - clocks: Must contain a reference to the functional clock(s),
+ - power-domains: Must contain a reference to the PM domain.
+Please refer to the binding documentation for the clock and/or PM domain
+providers for more details.
+
+
+Example:
+
+ bsc: bus@fec10000 {
+ compatible = "renesas,bsc-sh73a0", "renesas,bsc",
+ "simple-pm-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x20000000>;
+ reg = <0xfec10000 0x400>;
+ interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&zb_clk>;
+ power-domains = <&pd_a4s>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/chosen.txt b/roms/u-boot/doc/device-tree-bindings/chosen.txt
new file mode 100644
index 000000000..e5ba6720c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/chosen.txt
@@ -0,0 +1,163 @@
+The chosen node
+---------------
+The chosen node does not represent a real device, but serves as a place
+for passing data like which serial device to used to print the logs etc
+
+
+stdout-path property
+--------------------
+Device trees may specify the device to be used for boot console output
+with a stdout-path property under /chosen.
+
+Example
+-------
+/ {
+ chosen {
+ stdout-path = "/serial@f00:115200";
+ };
+
+ serial@f00 {
+ compatible = "vendor,some-uart";
+ reg = <0xf00 0x10>;
+ };
+};
+
+tick-timer property
+-------------------
+In a system there are multiple timers, specify which timer to be used
+as the tick-timer. Earlier it was hardcoded in the timer driver now
+since device tree has all the timer nodes. Specify which timer to be
+used as tick timer.
+
+Example
+-------
+/ {
+ chosen {
+ tick-timer = "/timer2@f00";
+ };
+
+ timer2@f00 {
+ compatible = "vendor,some-timer";
+ reg = <0xf00 0x10>;
+ };
+};
+
+u-boot,bootcount-device property
+--------------------------------
+
+In a DM-based system, the bootcount may be stored in a device known to
+the DM framework (e.g. in a battery-backed SRAM area within a RTC
+device) managed by a device conforming to UCLASS_BOOTCOUNT. If
+multiple such devices are present in a system concurrently, then the
+u-boot,bootcount-device property can select the preferred target.
+
+Example
+-------
+/ {
+ chosen {
+ u-boot,bootcount-device = &bootcount-rv3029;
+ };
+
+ bootcount-rv3029: bootcount@0 {
+ compatible = "u-boot,bootcount-rtc";
+ rtc = &rv3029;
+ offset = <0x38>;
+ };
+
+ i2c2 {
+ rv3029: rtc@56 {
+ compatible = "mc,rv3029";
+ reg = <0x56>;
+ };
+ };
+};
+
+u-boot,spl-boot-order property
+------------------------------
+
+In a system using an SPL stage and having multiple boot sources
+(e.g. SPI NOR flash, on-board eMMC and a removable SD-card), the boot
+device may be probed by reading the image and verifying an image
+signature.
+
+If the SPL is configured through the device-tree, the boot-order can
+be configured with the spl-boot-order property under the /chosen node.
+Each list element of the property should specify a device to be probed
+in the order they are listed: references (i.e. implicit paths), a full
+path or an alias is expected for each entry.
+
+A special specifier "same-as-spl" can be used at any position in the
+boot-order to direct U-Boot to insert the device the SPL was booted
+from there. Whether this is indeed inserted or silently ignored (if
+it is not supported on any given SoC/board or if the boot-device is
+not available to continue booting from) is implementation-defined.
+Note that if "same-as-spl" expands to an actual node for a given
+board, the corresponding node may appear multiple times in the
+boot-order (as there currently exists no mechanism to suppress
+duplicates from the list).
+
+Example
+-------
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, "/sdhci@fe330000";
+ };
+};
+
+u-boot,spl-boot-device property
+-------------------------------
+
+This property is a companion-property to the u-boot,spl-boot-order and
+will be injected automatically by the SPL stage to notify a later stage
+of where said later stage was booted from.
+
+You should not define this property yourself in the device-tree, as it
+may be overwritten without warning.
+
+firmware-loader property
+------------------------
+Multiple file system firmware loader nodes could be defined in device trees for
+multiple storage type and their default partition, then a property
+"firmware-loader" can be used to pass default firmware loader
+node(default storage type) to the firmware loader driver.
+
+Example
+-------
+/ {
+ chosen {
+ firmware-loader = &fs_loader0;
+ };
+
+ fs_loader0: fs-loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = <&mmc 1>;
+ };
+};
+
+u-boot,acpi-ssdt-order
+----------------------
+
+This provides the ordering to use when writing device data to the ACPI SSDT
+(Secondary System Descriptor Table). Each cell is a phandle pointer to a device
+node to add. The ACPI information is written in this order.
+
+If the ordering does not include all nodes, an error is generated.
+
+e820-entries
+------------
+
+This provides a way to add entries to the e820 table which tells the OS about
+the memory map. The property contains three sets of 64-bit values:
+
+ address - Start address of region
+ size - Size of region
+ flags - Flags (E820_...)
+
+Example:
+
+chosen {
+ e820-entries = /bits/ 64 <
+ IOMAP_P2SB_BAR IOMAP P2SB_SIZE E820_RESERVED
+ MCH_BASE_ADDRESS MCH_SIZE E820_RESERVED>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/fixed-factor-clock.txt b/roms/u-boot/doc/device-tree-bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 000000000..1bae8527e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-div: fixed divider.
+- clock-mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+ clock {
+ compatible = "fixed-factor-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/fsl,mpc83xx-clk.txt b/roms/u-boot/doc/device-tree-bindings/clock/fsl,mpc83xx-clk.txt
new file mode 100644
index 000000000..8313da850
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/fsl,mpc83xx-clk.txt
@@ -0,0 +1,23 @@
+MPC83xx system clock devices
+
+MPC83xx SoCs supply a variety of clocks to drive various components of a
+system.
+
+Required properties:
+- compatible: must be one of "fsl,mpc8308-clk",
+ "fsl,mpc8309-clk",
+ "fsl,mpc8313-clk",
+ "fsl,mpc8315-clk",
+ "fsl,mpc832x-clk",
+ "fsl,mpc8349-clk",
+ "fsl,mpc8360-clk",
+ "fsl,mpc8379-clk"
+ depending on which SoC is employed
+- #clock-cells: Must be 1
+
+Example:
+
+socclocks: clocks {
+ compatible = "fsl,mpc832x-clk";
+ #clock-cells = <1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/microchip,pic32-clock.txt b/roms/u-boot/doc/device-tree-bindings/clock/microchip,pic32-clock.txt
new file mode 100644
index 000000000..f185ce0ae
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/microchip,pic32-clock.txt
@@ -0,0 +1,33 @@
+* Microchip PIC32 Clock and Oscillator
+
+Microchip PIC32 clock tree consists of few oscillators, PLLs,
+multiplexers and few divider modules capable of supplying clocks
+to various controllers within SoC and also to off-chip.
+
+PIC32 clock controller output is defined by indices as defined
+in [0]
+
+[0] include/dt-bindings/clock/microchip,clock.h
+
+Required Properties:
+- compatible: should be "microchip,pic32mzda_clk"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+
+Example: Clock controller node:
+
+ clock: clk@1f801200 {
+ compatible = "microchip,pic32mzda-clk";
+ reg = <0x1f801200 0x1000>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+controller:
+
+ uart1: serial@1f822000 {
+ compatible = "microchip,pic32mzda-uart";
+ reg = <0xbf822000 0x50>;
+ interrupts = <112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock PB2CLK>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt b/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 000000000..5c07fcaed
--- /dev/null
+++ b/roms/u-boot/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/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3188-cru.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3188-cru.txt
new file mode 100644
index 000000000..0c2bf5eba
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3188-cru.txt
@@ -0,0 +1,61 @@
+* Rockchip RK3188/RK3066 Clock and Reset Unit
+
+The RK3188/RK3066 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or
+ "rockchip,rk3066a-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
+dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
+Similar macros exist for the reset sources in these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "xin27m" - 27mhz crystal input on rk3066 - optional,
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_cif0" - external camera clock - optional,
+ - "ext_rmii" - external RMII clock - optional,
+ - "ext_jtag" - externalJTAG clock - optional
+
+Example: Clock controller node:
+
+ cru: cru@20000000 {
+ compatible = "rockchip,rk3188-cru";
+ reg = <0x20000000 0x1000>;
+ rockchip,grf = <&grf>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@10124000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x10124000 0x400>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <1>;
+ clocks = <&cru SCLK_UART0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-cru.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-cru.txt
new file mode 100644
index 000000000..c9fbb7657
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-cru.txt
@@ -0,0 +1,61 @@
+* Rockchip RK3288 Clock and Reset Unit
+
+The RK3288 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3288-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_edp_24m" - external display port clock - optional,
+ - "ext_vip" - external VIP clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+
+Example: Clock controller node:
+
+ cru: cru@20000000 {
+ compatible = "rockchip,rk3188-cru";
+ reg = <0x20000000 0x1000>;
+ rockchip,grf = <&grf>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@10124000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x10124000 0x400>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <1>;
+ clocks = <&cru SCLK_UART0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-dmc.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-dmc.txt
new file mode 100644
index 000000000..2ca9db70a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3288-dmc.txt
@@ -0,0 +1,155 @@
+Rockchip Dynamic Memory Controller Driver
+Required properties:
+- compatible: "rockchip,rk3288-dmc", "syscon"
+- rockchip,cru: this driver should access cru regs, so need get cru here
+- rockchip,grf: this driver should access grf regs, so need get grf here
+- rockchip,pmu: this driver should access pmu regs, so need get pmu here
+- rockchip,sgrf: this driver should access sgrf regs, so need get sgrf here
+- rockchip,noc: this driver should access noc regs, so need get noc here
+- reg: dynamic ram protocol controller(PCTL) address and phy controller(PHYCTL) address
+- clock: must include clock specifiers corresponding to entries in the clock-names property.
+- clock-output-names: from common clock binding to override the default output clock name
+ Must contain
+ pclk_ddrupctl0: support clock for access protocol controller registers of channel 0
+ pclk_publ0: support clock for access phy controller registers of channel 0
+ pclk_ddrupctl1: support clock for access protocol controller registers of channel 1
+ pclk_publ1: support clock for access phy controller registers of channel 1
+ arm_clk: for get arm frequency
+-logic-supply: this driver should adjust VDD_LOGIC according to dmc frequency, so need get logic-supply here
+-timings:
+ Must contain
+ rockchip,odt-disable-freq: if ddr clock frequency low than odt-disable-freq,this driver should disable DDR ODT
+ rockchip,dll-disable-freq: if ddr clock frequency low than dll-disable-freq,this driver should disable DDR DLL
+ rockchip,sr-enable-freq: if ddr clock frequency high than sr-enable-freq,this driver should enable the automatic self refresh function
+ rockchip,pd-enable-freq: if ddr clock frequency high than pd-enable-freq,this driver should enable the automatic power down function
+ rockchip,auto-self-refresh-cnt: Self Refresh idle period. Memories are placed into Self-Refresh mode if the NIF is idle in Access state for auto-self-refresh-cnt * 32 * n_clk cycles.The automatic self refresh function is disabled when auto-self-refresh-cnt=0.
+ rockchip,auto-power-down-cnt: Power-down idle period. Memories are placed into power-down mode if the NIF is idle for auto-power-down-cnt n_clk cycles.The automatic power down function is disabled when auto-power-down-cnt=0.
+ rockchip,ddr-speed-bin: DDR3 type,AC timing parameters from the memory data-sheet
+ 0.DDR3_800D (5-5-5)
+ 1.DDR3_800E (6-6-6)
+ 2.DDR3_1066E (6-6-6)
+ 3.DDR3_1066F (7-7-7)
+ 4.DDR3_1066G (8-8-8)
+ 5.DDR3_1333F (7-7-7)
+ 6.DDR3_1333G (8-8-8)
+ 7.DDR3_1333H (9-9-9)
+ 8.DDR3_1333J (10-10-10)
+ 9.DDR3_1600G (8-8-8)
+ 10.DDR3_1600H (9-9-9)
+ 11.DDR3_1600J (10-10-10)
+ 12.DDR3_1600K (11-11-11)
+ 13.DDR3_1866J (10-10-10)
+ 14.DDR3_1866K (11-11-11)
+ 15.DDR3_1866L (12-12-12)
+ 16.DDR3_1866M (13-13-13)
+ 17.DDR3_2133K (11-11-11)
+ 18.DDR3_2133L (12-12-12)
+ 19.DDR3_2133M (13-13-13)
+ 20.DDR3_2133N (14-14-14)
+ 21.DDR3_DEFAULT
+ rockchip,trcd: tRCD,AC timing parameters from the memory data-sheet
+ rockchip,trp: tRP,AC timing parameters from the memory data-sheet
+-rockchip,num-channels: number of SDRAM channels (1 or 2)
+-rockchip,pctl-timing: parameters for the SDRAM setup, in this order:
+ togcnt1u
+ tinit
+ trsth
+ togcnt100n
+ trefi
+ tmrd
+ trfc
+ trp
+ trtw
+ tal
+ tcl
+ tcwl
+ tras
+ trc
+ trcd
+ trrd
+ trtp
+ twr
+ twtr
+ texsr
+ txp
+ txpdll
+ tzqcs
+ tzqcsi
+ tdqs
+ tcksre
+ tcksrx
+ tcke
+ tmod
+ trstl
+ tzqcl
+ tmrr
+ tckesr
+ tdpd
+-rockchip,phy-timing: PHY timing information in this order:
+ dtpr0
+ dtpr1
+ dtpr2
+ mr0..mr3
+-rockchip,sdram-channel: SDRAM channel information, each 8 bits. Both channels
+will be set up the same. The parameters are in this order:
+ rank
+ col
+ bk
+ bw
+ dbw
+ row_3_4
+ cs0_row
+ cs1_row
+- rockchip,sdram-params: SDRAM base parameters, in this order:
+ NOC timing - value for ddrtiming register
+ NOC activate - value for activate register
+ ddrconf - value for ddrconf register
+ DDR frequency in MHz
+ DRAM type (3=DDR3, 6=LPDDR3)
+ stride - stride value for soc_con2 register
+ odt - 1 to enable DDR ODT, 0 to disable
+
+Example:
+ dmc: dmc@ff610000 {
+ compatible = "rockchip,rk3288-dmc", "syscon";
+ rockchip,cru = <&cru>;
+ rockchip,grf = <&grf>;
+ rockchip,pmu = <&pmu>;
+ rockchip,sgrf = <&sgrf>;
+ rockchip,noc = <&noc>;
+ reg = <0xff610000 0x3fc
+ 0xff620000 0x294
+ 0xff630000 0x3fc
+ 0xff640000 0x294>;
+ clocks = <&cru PCLK_DDRUPCTL0>, <&cru PCLK_PUBL0>,
+ <&cru PCLK_DDRUPCTL1>, <&cru PCLK_PUBL1>,
+ <&cru ARMCLK>;
+ clock-names = "pclk_ddrupctl0", "pclk_publ0",
+ "pclk_ddrupctl1", "pclk_publ1",
+ "arm_clk";
+ };
+
+ &dmc {
+ logic-supply = <&vdd_logic>;
+ timings {
+ rockchip,odt-disable-freq = <333000000>;
+ rockchip,dll-disable-freq = <333000000>;
+ rockchip,sr-enable-freq = <333000000>;
+ rockchip,pd-enable-freq = <666000000>;
+ rockchip,auto-self-refresh-cnt = <0>;
+ rockchip,auto-power-down-cnt = <64>;
+ rockchip,ddr-speed-bin = <21>;
+ rockchip,trcd = <10>;
+ rockchip,trp = <10>;
+ };
+ rockchip,num-channels = <2>;
+ rockchip,pctl-timing = <0x29a 0x1f4 0xc8 0x42 0x4e 0x4 0xea 0xa
+ 0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
+ 0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
+ 0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
+ 0x5 0x0>;
+ rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
+ 0xa60 0x40 0x10 0x0>;
+ rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf>;
+ rockchip,sdram-params = <0x30B25564 0x627 3 666000000 3 9 1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt
new file mode 100644
index 000000000..8e7357d53
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt
@@ -0,0 +1,67 @@
+RK3368 dynamic memory controller driver
+=======================================
+
+The RK3368 DMC (dynamic memory controller) driver supports setup/initialisation
+during TPL using configuration data from the DTS (i.e. OF_PLATDATA), based on
+the following key configuration data:
+ (a) a target-frequency (i.e. operating point) for the memory operation
+ (b) a speed-bin (as defined in JESD-79) for the DDR3 used in hardware
+ (c) a memory-schedule (i.e. mapping from physical addresses to the address
+ pins of the memory bus)
+
+Required properties
+-------------------
+
+- compatible: "rockchip,rk3368-dmc"
+- reg
+ protocol controller (PCTL) address and PHY controller (DDRPHY) address
+- rockchip,ddr-speed-bin
+ the DDR3 device's speed-bin (as specified according to JESD-79)
+ DDR3_800D (5-5-5)
+ DDR3_800E (6-6-6)
+ DDR3_1066E (6-6-6)
+ DDR3_1066F (7-7-7)
+ DDR3_1066G (8-8-8)
+ DDR3_1333F (7-7-7)
+ DDR3_1333G (8-8-8)
+ DDR3_1333H (9-9-9)
+ DDR3_1333J (10-10-10)
+ DDR3_1600G (8-8-8)
+ DDR3_1600H (9-9-9)
+ DDR3_1600J (10-10-10)
+ DDR3_1600K (11-11-11)
+ DDR3_1866J (10-10-10)
+ DDR3_1866K (11-11-11)
+ DDR3_1866L (12-12-12)
+ DDR3_1866M (13-13-13)
+ DDR3_2133K (11-11-11)
+ DDR3_2133L (12-12-12)
+ DDR3_2133M (13-13-13)
+ DDR3_2133N (14-14-14)
+- rockchip,ddr-frequency:
+ target DDR clock frequency in Hz (not all frequencies may be supported,
+ as there's some cooperation from the clock-driver required)
+- rockchip,memory-schedule:
+ controls the decoding of physical addresses to DRAM addressing (i.e. how
+ the physical address maps onto the address pins/chip-select of the device)
+ DMC_MSCH_CBDR: column -> bank -> device -> row
+ DMC_MSCH_CBRD: column -> band -> row -> device
+ DMC_MSCH_CRBD: column -> row -> band -> device
+
+Example (for DDR3-1600K and 800MHz)
+-----------------------------------
+
+ #include <dt-bindings/memory/rk3368-dmc.h>
+
+ dmc: dmc@ff610000 {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,rk3368-dmc";
+ reg = <0 0xff610000 0 0x400
+ 0 0xff620000 0 0x400>;
+ };
+
+ &dmc {
+ rockchip,ddr-speed-bin = <DDR3_1600K>;
+ rockchip,ddr-frequency = <800000000>;
+ rockchip,memory-schedule = <DMC_MSCH_CBRD>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3399-dmc.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3399-dmc.txt
new file mode 100644
index 000000000..a15dc5d1f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip,rk3399-dmc.txt
@@ -0,0 +1,42 @@
+Rockchip Dynamic Memory Controller Driver
+Required properties:
+- compatible: "rockchip,rk3399-dmc", "syscon"
+- rockchip,cru: this driver should access cru regs, so need get cru here
+- rockchip,pmucru: this driver should access pmucru regs, so need get pmucru here
+- rockchip,pmugrf: this driver should access pmugrf regs, so need get pmugrf here
+- rockchip,pmusgrf: this driver should access pmusgrf regs, so need get pmusgrf here
+- rockchip,cic: this driver should access cic regs, so need get cic here
+- reg: dynamic ram protocol controller(PCTL) address, PHY Independent(PI) address, phy controller(PHYCTL) address and memory schedule(MSCH) address
+- clock: must include clock specifiers corresponding to entries in the clock-names property.
+ Must contain
+ dmc_clk: for ddr working frequency
+- rockchip,sdram-params: SDRAM parameters, including all the information by ddr driver:
+ Must contain
+ Genarate by vendor tool and adjust for U-Boot dtsi.
+
+Example:
+ dmc: dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,rk3399-dmc";
+ devfreq-events = <&dfi>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru SCLK_DDRCLK>;
+ clock-names = "dmc_clk";
+ reg = <0x0 0xffa80000 0x0 0x0800
+ 0x0 0xffa80800 0x0 0x1800
+ 0x0 0xffa82000 0x0 0x2000
+ 0x0 0xffa84000 0x0 0x1000
+ 0x0 0xffa88000 0x0 0x0800
+ 0x0 0xffa88800 0x0 0x1800
+ 0x0 0xffa8a000 0x0 0x2000
+ 0x0 0xffa8c000 0x0 0x1000>;
+ };
+
+ &dmc {
+ rockchip,sdram-params = <
+ 0x2
+ 0xa
+ 0x3
+ ...
+ >;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/rockchip.txt b/roms/u-boot/doc/device-tree-bindings/clock/rockchip.txt
new file mode 100644
index 000000000..22f6769e5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/rockchip.txt
@@ -0,0 +1,77 @@
+Device Tree Clock bindings for arch-rockchip
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+== Gate clocks ==
+
+These bindings are deprecated!
+Please use the soc specific CRU bindings instead.
+
+The gate registers form a continuos block which makes the dt node
+structure a matter of taste, as either all gates can be put into
+one gate clock spanning all registers or they can be divided into
+the 10 individual gates containing 16 clocks each.
+The code supports both approaches.
+
+Required properties:
+- compatible : "rockchip,rk2928-gate-clk"
+- reg : shall be the control register address(es) for the clock.
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names : the corresponding gate names that the clock controls
+- clocks : should contain the parent clock for each individual gate,
+ therefore the number of clocks elements should match the number of
+ clock-output-names
+
+Example using multiple gate clocks:
+
+ clk_gates0: gate-clk@200000d0 {
+ compatible = "rockchip,rk2928-gate-clk";
+ reg = <0x200000d0 0x4>;
+ clocks = <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>;
+
+ clock-output-names =
+ "gate_core_periph", "gate_cpu_gpll",
+ "gate_ddrphy", "gate_aclk_cpu",
+ "gate_hclk_cpu", "gate_pclk_cpu",
+ "gate_atclk_cpu", "gate_i2s0",
+ "gate_i2s0_frac", "gate_i2s1",
+ "gate_i2s1_frac", "gate_i2s2",
+ "gate_i2s2_frac", "gate_spdif",
+ "gate_spdif_frac", "gate_testclk";
+
+ #clock-cells = <1>;
+ };
+
+ clk_gates1: gate-clk@200000d4 {
+ compatible = "rockchip,rk2928-gate-clk";
+ reg = <0x200000d4 0x4>;
+ clocks = <&xin24m>, <&xin24m>,
+ <&xin24m>, <&dummy>,
+ <&dummy>, <&xin24m>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>;
+
+ clock-output-names =
+ "gate_timer0", "gate_timer1",
+ "gate_timer2", "gate_jtag",
+ "gate_aclk_lcdc1_src", "gate_otgphy0",
+ "gate_otgphy1", "gate_ddr_gpll",
+ "gate_uart0", "gate_frac_uart0",
+ "gate_uart1", "gate_frac_uart1",
+ "gate_uart2", "gate_frac_uart2",
+ "gate_uart3", "gate_frac_uart3";
+
+ #clock-cells = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/snps,hsdk-cgu.txt b/roms/u-boot/doc/device-tree-bindings/clock/snps,hsdk-cgu.txt
new file mode 100644
index 000000000..82fe1dd83
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/snps,hsdk-cgu.txt
@@ -0,0 +1,35 @@
+* Synopsys HSDK clock generation unit
+
+The Synopsys HSDK clock controller generates and supplies clock to various
+controllers and peripherals within the SoC.
+
+Required Properties:
+
+- compatible: should be "snps,hsdk-cgu-clock"
+- reg: the pair of physical base address and length of clock generation unit
+ memory mapped region and creg arc core divider memory mapped region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/snps,hsdk-cgu.h headers and can be
+used in device tree sources.
+
+Example: Clock controller node:
+
+ cgu_clk: cgu-clk@f0000000 {
+ compatible = "snps,hsdk-cgu-clock";
+ reg = <0xf0000000 0x1000>, <0xf00014B8 0x4>;
+ #clock-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+controller:
+
+ uart0: serial0@f0005000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xf0005000 0x1000>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cgu_clk CLK_SYS_UART_REF>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/st,stm32-rcc.txt b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32-rcc.txt
new file mode 100644
index 000000000..0532d815d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32-rcc.txt
@@ -0,0 +1,95 @@
+STMicroelectronics STM32 Reset and Clock Controller
+===================================================
+
+The RCC IP is both a reset and a clock controller.
+
+Please refer to clock-bindings.txt for common clock controller binding usage.
+Please also refer to reset.txt for common reset controller binding usage.
+
+Required properties:
+- compatible: Should be:
+ "st,stm32f42xx-rcc"
+ "st,stm32f469-rcc"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+- #clock-cells: 2, device nodes should specify the clock in their "clocks"
+ property, containing a phandle to the clock device node, an index selecting
+ between gated clocks and other clocks and an index specifying the clock to
+ use.
+
+Example:
+
+ rcc: rcc@40023800 {
+ #reset-cells = <1>;
+ #clock-cells = <2>
+ compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
+ reg = <0x40023800 0x400>;
+ };
+
+Specifying gated clocks
+=======================
+
+The primary index must be set to 0.
+
+The secondary index is the bit number within the RCC register bank, starting
+from the first RCC clock enable register (RCC_AHB1ENR, address offset 0x30).
+
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31).
+
+To simplify the usage and to share bit definition with the reset and clock
+drivers of the RCC IP, macros are available to generate the index in
+human-readble format.
+
+For STM32F4 series, the macro are available here:
+ - include/dt-bindings/mfd/stm32f4-rcc.h
+
+Example:
+
+ /* Gated clock, AHB1 bit 0 (GPIOA) */
+ ... {
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>
+ };
+
+ /* Gated clock, AHB2 bit 4 (CRYP) */
+ ... {
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)>
+ };
+
+Specifying other clocks
+=======================
+
+The primary index must be set to 1.
+
+The secondary index is bound with the following magic numbers:
+
+ 0 SYSTICK
+ 1 FCLK
+
+Example:
+
+ /* Misc clock, FCLK */
+ ... {
+ clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)>
+ };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+ crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+example:
+
+ timer2 {
+ resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/st,stm32h7-rcc.txt b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32h7-rcc.txt
new file mode 100644
index 000000000..9d4b5873d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32h7-rcc.txt
@@ -0,0 +1,152 @@
+STMicroelectronics STM32H7 Reset and Clock Controller
+=====================================================
+
+The RCC IP is both a reset and a clock controller.
+
+Please refer to clock-bindings.txt for common clock controller binding usage.
+Please also refer to reset.txt for common reset controller binding usage.
+
+Required properties:
+- compatible: Should be:
+ "st,stm32h743-rcc"
+
+- reg: should be register base and length as documented in the
+ datasheet
+
+- #reset-cells: 1, see below
+
+- #clock-cells : from common clock binding; shall be set to 1
+
+- clocks: External oscillator clock phandle
+ - high speed external clock signal (HSE)
+ - low speed external clock signal (LSE)
+ - external I2S clock (I2S_CKIN)
+
+- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
+ write protection (RTC clock).
+
+- pll x node: Allow to register a pll with specific parameters.
+ Please see PLL section below.
+
+Example:
+
+ rcc: rcc@58024400 {
+ #reset-cells = <1>;
+ #clock-cells = <2>
+ compatible = "st,stm32h743-rcc", "st,stm32-rcc";
+ reg = <0x58024400 0x400>;
+ clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
+
+ st,syscfg = <&pwrcfg>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vco1@58024430 {
+ #clock-cells = <0>;
+ compatible = "stm32,pll";
+ reg = <0>;
+ };
+
+ vco2@58024438 {
+ #clock-cells = <0>;
+ compatible = "stm32,pll";
+ reg = <1>;
+ st,clock-div = <2>;
+ st,clock-mult = <40>;
+ st,frac-status = <0>;
+ st,frac = <0>;
+ st,vcosel = <1>;
+ st,pllrge = <2>;
+ };
+ };
+
+
+STM32H7 PLL
+-----------
+
+The VCO of STM32 PLL could be reprensented like this:
+
+ Vref --------- --------
+ ---->| / DIVM |---->| x DIVN | ------> VCO
+ --------- --------
+ ^
+ |
+ -------
+ | FRACN |
+ -------
+
+When the PLL is configured in integer mode:
+- VCO = ( Vref / DIVM ) * DIVN
+
+When the PLL is configured in fractional mode:
+- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
+
+
+Required properties for pll node:
+- compatible: Should be:
+ "stm32,pll"
+
+- #clock-cells: from common clock binding; shall be set to 0
+- reg: Should be the pll number.
+
+Optional properties:
+- st,clock-div: DIVM division factor : <1..63>
+- st,clock-mult: DIVN multiplication factor : <4..512>
+
+- st,frac-status:
+ - 0 Pll is configured in integer mode
+ - 1 Pll is configure in fractional mode
+
+- st,frac: Fractional part of the multiplication factor : <0..8191>
+
+- st,vcosel: VCO selection
+ - 0: Wide VCO range:192 to 836 MHz
+ - 1: Medium VCO range:150 to 420 MHz
+
+- st,pllrge: PLL input frequency range
+ - 0: The PLL input (Vref / DIVM) clock range frequency is between 1 and 2 MHz
+ - 1: The PLL input (Vref / DIVM) clock range frequency is between 2 and 4 MHz
+ - 2: The PLL input (Vref / DIVM) clock range frequency is between 4 and 8 MHz
+ - 3: The PLL input (Vref / DIVM) clock range frequency is between 8 and 16 MHz
+
+
+The peripheral clock consumer should specify the desired clock by
+having the clock ID in its "clocks" phandle cell.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/stm32h7-clks.h header and can be used in device
+tree sources.
+
+Example:
+
+ timer5: timer@40000c00 {
+ compatible = "st,stm32-timer";
+ reg = <0x40000c00 0x400>;
+ interrupts = <50>;
+ clocks = <&rcc TIM5_CK>;
+
+ };
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+
+For example, for CRC reset:
+ crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
+
+All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
+header and can be used in device tree sources.
+
+example:
+
+ timer2 {
+ resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/st,stm32mp1.txt b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32mp1.txt
new file mode 100644
index 000000000..4d4136d2f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/st,stm32mp1.txt
@@ -0,0 +1,405 @@
+STMicroelectronics STM32MP1 clock tree initialization
+=====================================================
+
+The STM32MP1 clock tree initialization is based on device tree information
+for RCC IP node (st,stm32mp1-rcc) and on fixed-clock nodes.
+
+RCC IP = st,stm32mp1-rcc
+========================
+
+The RCC IP is both a reset and a clock controller but this documentation only
+describes the fields added for clock tree initialization which are not present
+in Linux binding for compatible "st,stm32mp1-rcc" defined in st,stm32mp1-rcc.txt
+file.
+
+This parent node may optionally have additional children nodes which define
+specific init values for RCC elements.
+
+The added properties for clock tree initialization are:
+
+Required properties:
+- st,clksrc : The clock sources configuration array in a platform specific
+ order.
+
+ For the STM32MP15x family there are 9 clock sources selector which are
+ configured in the following order:
+ MPU AXI MCU PLL12 PLL3 PLL4 RTC MCO1 MCO2
+
+ Clock source configuration values are defined by macros CLK_<NAME>_<SOURCE>
+ from dt-bindings/clock/stm32mp1-clksrc.h.
+
+ Example:
+ st,clksrc = <
+ CLK_MPU_PLL1P
+ CLK_AXI_PLL2P
+ CLK_MCU_PLL3P
+ CLK_PLL12_HSE
+ CLK_PLL3_HSE
+ CLK_PLL4_HSE
+ CLK_RTC_LSE
+ CLK_MCO1_DISABLED
+ CLK_MCO2_DISABLED
+ >;
+
+- st,clkdiv : The clock main dividers value specified in an array
+ in a platform specific order.
+
+ When used, it shall describe the whole clock dividers tree.
+
+ For the STM32MP15x family there are 11 dividers values expected.
+ They shall be configured in the following order:
+ MPU AXI MCU APB1 APB2 APB3 APB4 APB5 RTC MCO1 MCO2
+
+ The each divider value uses the DIV coding defined in RCC associated
+ register RCC_xxxDIVR. In most the case, it is:
+ 0x0: not divided
+ 0x1: division by 2
+ 0x2: division by 4
+ 0x3: division by 8
+ ...
+
+ Note that for RTC MCO1 MCO2, the coding is different:
+ 0x0: not divided
+ 0x1: division by 2
+ 0x2: division by 3
+ 0x3: division by 4
+ ...
+
+ Example:
+ st,clkdiv = <
+ 1 /*MPU*/
+ 0 /*AXI*/
+ 0 /*MCU*/
+ 1 /*APB1*/
+ 1 /*APB2*/
+ 1 /*APB3*/
+ 1 /*APB4*/
+ 2 /*APB5*/
+ 23 /*RTC*/
+ 0 /*MCO1*/
+ 0 /*MCO2*/
+ >;
+
+Optional Properties:
+- children for a PLL configuration with "st,stm32mp1-pll" compatible
+
+ each PLL children nodes for PLL1 to PLL4 (see ref manual for details)
+ are listed with associated reg 0 to 3.
+ PLLx is off when the associated node is absent or deactivated.
+
+ For PLL1, when the node is absent, the frequency of the OPP node is used
+ to compute the PLL setting (see compatible "operating-points-v2" in
+ opp/opp.txt for details).
+
+ Here are the available properties for each PLL node:
+ - compatible: should be "st,stm32mp1-pll"
+
+ - reg: index of the pll instance
+
+ - cfg: The parameters for PLL configuration in the following order:
+ DIVM DIVN DIVP DIVQ DIVR Output.
+
+ DIVx values are defined as in RCC spec:
+ 0x0: bypass (division by 1)
+ 0x1: division by 2
+ 0x2: division by 3
+ 0x3: division by 4
+ ...
+
+ Output contains a bitfield for each output value (1:ON/0:OFF)
+ BIT(0) => output P : DIVPEN
+ BIT(1) => output Q : DIVQEN
+ BIT(2) => output R : DIVREN
+ NB: macro PQR(p,q,r) can be used to build this value
+ with p,q,r = 0 or 1.
+
+ - frac : Fractional part of the multiplication factor
+ (optional, PLL is in integer mode when absent).
+
+ - csg : Clock Spreading Generator (optional) with parameters in the
+ following order: MOD_PER INC_STEP SSCG_MODE.
+
+ MOD_PER: Modulation Period Adjustment
+ INC_STEP: Modulation Depth Adjustment
+ SSCG_MODE: Spread spectrum clock generator mode, with associated
+ defined from stm32mp1-clksrc.h:
+ - SSCG_MODE_CENTER_SPREAD = 0
+ - SSCG_MODE_DOWN_SPREAD = 1
+
+ Example:
+ st,pll@0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
+ cfg = < 1 53 0 0 0 1 >;
+ frac = < 0x810 >;
+ };
+ st,pll@1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
+ cfg = < 1 43 1 0 0 PQR(0,1,1) >;
+ csg = < 10 20 1 >;
+ };
+ st,pll@2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
+ cfg = < 2 85 3 13 3 0 >;
+ csg = < 10 20 SSCG_MODE_CENTER_SPREAD >;
+ };
+ st,pll@3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
+ cfg = < 2 78 4 7 9 3 >;
+ };
+
+- st,pkcs : used to configure the peripherals kernel clock selection.
+
+ The property is a list of peripheral kernel clock source identifiers defined
+ by macros CLK_<KERNEL-CLOCK>_<PARENT-CLOCK> as defined by header file
+ dt-bindings/clock/stm32mp1-clksrc.h.
+
+ st,pkcs may not list all the kernel clocks and has no ordering requirements.
+
+ Example:
+ st,pkcs = <
+ CLK_STGEN_HSE
+ CLK_CKPER_HSI
+ CLK_USBPHY_PLL2P
+ CLK_DSI_PLL2Q
+ CLK_I2C46_HSI
+ CLK_UART1_HSI
+ CLK_UART24_HSI
+ >;
+
+other clocks = fixed-clock
+==========================
+
+The clock tree is also based on 5 fixed-clock in clocks node
+used to define the state of associated ST32MP1 oscillators:
+ - clk-lsi
+ - clk-lse
+ - clk-hsi
+ - clk-hse
+ - clk-csi
+
+At boot the clock tree initialization will
+ - enable oscillators present in device tree and not disabled
+ (node with status="disabled"),
+ - disable HSI oscillator if the node is absent (always activated by bootrom)
+ and not disabled (node with status="disabled").
+
+Optional properties :
+
+a) for external oscillator: "clk-lse", "clk-hse"
+
+ 4 optional fields are managed
+ - "st,bypass" configures the oscillator bypass mode (HSEBYP, LSEBYP)
+ - "st,digbypass" configures the bypass mode as full-swing digital
+ signal (DIGBYP)
+ - "st,css" activates the clock security system (HSECSSON, LSECSSON)
+ - "st,drive" (only for LSE) contains the value of the drive for the
+ oscillator (see LSEDRV_ defined in the file
+ dt-bindings/clock/stm32mp1-clksrc.h)
+
+ Example board file:
+ / {
+ clocks {
+ clk_hse: clk-hse {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <64000000>;
+ st,bypass;
+ };
+
+ clk_lse: clk-lse {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ st,css;
+ st,drive = <LSEDRV_LOWEST>;
+ };
+ };
+
+b) for internal oscillator: "clk-hsi"
+
+ Internally HSI clock is fixed to 64MHz for STM32MP157 SoC.
+ In device tree, clk-hsi is the clock after HSIDIV (clk_hsi in RCC
+ doc). So this clock frequency is used to compute the expected HSI_DIV
+ for the clock tree initialization.
+
+ Example with HSIDIV = /1:
+ / {
+ clocks {
+ clk_hsi: clk-hsi {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <64000000>;
+ };
+ };
+
+ Example with HSIDIV = /2
+ / {
+ clocks {
+ clk_hsi: clk-hsi {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32000000>;
+ };
+ };
+
+Example of clock tree initialization
+====================================
+
+/ {
+ clocks {
+ u-boot,dm-pre-reloc;
+ clk_hse: clk-hse {
+ u-boot,dm-pre-reloc;
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ st,digbypass;
+ };
+
+ clk_hsi: clk-hsi {
+ u-boot,dm-pre-reloc;
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <64000000>;
+ };
+
+ clk_lse: clk-lse {
+ u-boot,dm-pre-reloc;
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+
+ clk_lsi: clk-lsi {
+ u-boot,dm-pre-reloc;
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ };
+
+ clk_csi: clk-csi {
+ u-boot,dm-pre-reloc;
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <4000000>;
+ };
+ };
+
+ soc {
+
+ rcc: rcc@50000000 {
+ u-boot,dm-pre-reloc;
+ compatible = "st,stm32mp1-rcc", "syscon";
+ reg = <0x50000000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+
+ st,clksrc = <
+ CLK_MPU_PLL1P
+ CLK_AXI_PLL2P
+ CLK_MCU_PLL3P
+ CLK_PLL12_HSE
+ CLK_PLL3_HSE
+ CLK_PLL4_HSE
+ CLK_RTC_LSE
+ CLK_MCO1_DISABLED
+ CLK_MCO2_DISABLED
+ >;
+
+ st,clkdiv = <
+ 1 /*MPU*/
+ 0 /*AXI*/
+ 0 /*MCU*/
+ 1 /*APB1*/
+ 1 /*APB2*/
+ 1 /*APB3*/
+ 1 /*APB4*/
+ 2 /*APB5*/
+ 23 /*RTC*/
+ 0 /*MCO1*/
+ 0 /*MCO2*/
+ >;
+
+ st,pkcs = <
+ CLK_CKPER_HSE
+ CLK_FMC_ACLK
+ CLK_QSPI_ACLK
+ CLK_ETH_DISABLED
+ CLK_SDMMC12_PLL4P
+ CLK_DSI_DSIPLL
+ CLK_STGEN_HSE
+ CLK_USBPHY_HSE
+ CLK_SPI2S1_PLL3Q
+ CLK_SPI2S23_PLL3Q
+ CLK_SPI45_HSI
+ CLK_SPI6_HSI
+ CLK_I2C46_HSI
+ CLK_SDMMC3_PLL4P
+ CLK_USBO_USBPHY
+ CLK_ADC_CKPER
+ CLK_CEC_LSE
+ CLK_I2C12_HSI
+ CLK_I2C35_HSI
+ CLK_UART1_HSI
+ CLK_UART24_HSI
+ CLK_UART35_HSI
+ CLK_UART6_HSI
+ CLK_UART78_HSI
+ CLK_SPDIF_PLL4P
+ CLK_FDCAN_PLL4Q
+ CLK_SAI1_PLL3Q
+ CLK_SAI2_PLL3Q
+ CLK_SAI3_PLL3Q
+ CLK_SAI4_PLL3Q
+ CLK_RNG1_LSI
+ CLK_RNG2_LSI
+ CLK_LPTIM1_PCLK1
+ CLK_LPTIM23_PCLK3
+ CLK_LPTIM45_LSE
+ >;
+
+ /* VCO = 1300.0 MHz => P = 650 (CPU) */
+ pll1: st,pll@0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
+ cfg = < 2 80 0 0 0 PQR(1,0,0) >;
+ frac = < 0x800 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU),
+ R = 533 (DDR) */
+ pll2: st,pll@1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
+ cfg = < 2 65 1 0 0 PQR(1,1,1) >;
+ frac = < 0x1400 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
+ pll3: st,pll@2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
+ cfg = < 1 33 1 16 36 PQR(1,1,1) >;
+ frac = < 0x1a04 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
+ pll4: st,pll@3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
+ cfg = < 3 98 5 7 7 PQR(1,1,1) >;
+ u-boot,dm-pre-reloc;
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/ti,cdce9xx.txt b/roms/u-boot/doc/device-tree-bindings/clock/ti,cdce9xx.txt
new file mode 100644
index 000000000..0d01f2d5c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/ti,cdce9xx.txt
@@ -0,0 +1,49 @@
+Binding for TI CDCE913/925/937/949 programmable I2C clock synthesizers.
+
+Reference
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] http://www.ti.com/product/cdce913
+[3] http://www.ti.com/product/cdce925
+[4] http://www.ti.com/product/cdce937
+[5] http://www.ti.com/product/cdce949
+
+The driver provides clock sources for each output Y1 through Y5.
+
+Required properties:
+ - compatible: Shall be one of the following:
+ - "ti,cdce913": 1-PLL, 3 Outputs
+ - "ti,cdce925": 2-PLL, 5 Outputs
+ - "ti,cdce937": 3-PLL, 7 Outputs
+ - "ti,cdce949": 4-PLL, 9 Outputs
+ - reg: I2C device address.
+ - clocks: Points to a fixed parent clock that provides the input frequency.
+ - #clock-cells: From common clock bindings: Shall be 1.
+
+Optional properties:
+ - xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
+ board, or to compensate for external influences.
+
+For all PLL1, PLL2, ... an optional child node can be used to specify spread
+spectrum clocking parameters for a board.
+ - spread-spectrum: SSC mode as defined in the data sheet.
+ - spread-spectrum-center: Use "centered" mode instead of "max" mode. When
+ present, the clock runs at the requested frequency on average. Otherwise
+ the requested frequency is the maximum value of the SCC range.
+
+
+Example:
+
+ clockgen: cdce925pw@64 {
+ compatible = "cdce925";
+ reg = <0x64>;
+ clocks = <&xtal_27Mhz>;
+ #clock-cells = <1>;
+ xtal-load-pf = <5>;
+ /* PLL options to get SSC 1% centered */
+ PLL2 {
+ spread-spectrum = <4>;
+ spread-spectrum-center;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/clock/ti,sci-clk.txt b/roms/u-boot/doc/device-tree-bindings/clock/ti,sci-clk.txt
new file mode 100644
index 000000000..c6fe48200
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/clock/ti,sci-clk.txt
@@ -0,0 +1,53 @@
+Texas Instruments TI SCI Clock Controller
+=========================================
+
+All clocks on Texas Instruments' SoCs that contain a System Controller,
+are only controlled by this entity. Communication between a host processor
+running an OS and the System Controller happens through a protocol known
+as TI SCI[1]. This clock implementation plugs into the common clock
+framework and makes use of the TI SCI protocol on clock API requests.
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+Clock Controller Node
+=====================
+The clock controller node represents the clocks managed by the SYSFW. Because
+this relies on the TI SCI protocol to communicate with the SYSFW it must be a
+child of the sysfw node.
+
+Required Properties:
+--------------------
+- compatible: Must be "ti,k2g-sci-clk"
+- #clock-cells: Must be be 2. In clock consumers, this cell represents the
+ device ID and clock ID exposed by the SYSFW firmware.
+
+Example (AM65x):
+----------------
+ dmsc: dmsc {
+ compatible = "ti,k2g-sci";
+ ...
+ k3_clks: clocks {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+ };
+
+Clock Consumers
+===============
+Hardware blocks supplied by a clock should contain a "clocks" property that is
+a phandle pointing to the clock controller node along with an index representing
+the device id together with a clock ID to be passed to the SYSFW for device
+control.
+
+Required Properties:
+--------------------
+- clocks: phandle pointing to the corresponding clock node, an ID representing
+ the device, and an index representing a clock.
+
+Example (AM65x):
+----------------
+ uart2: serial@02800000 {
+ compatible = "ti,omap4-uart";
+ ...
+ clocks = <&k3_clks 0x0007 1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/config.txt b/roms/u-boot/doc/device-tree-bindings/config.txt
new file mode 100644
index 000000000..6cdc16da5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/config.txt
@@ -0,0 +1,54 @@
+The /config node (Configuration Options)
+----------------------------------------
+
+A number of run-time configuration options are provided in the /config node
+of the control device tree. You can access these using fdtdec_get_config_int(),
+fdtdec_get_config_bool() and fdtdec_get_config_string().
+
+Available options are:
+
+silent-console
+ If present and non-zero, the console is silenced by default on boot.
+
+no-keyboard
+ Tells U-Boot not to expect an attached keyboard with a VGA console
+
+u-boot,efi-partition-entries-offset
+ If present, this provides an offset (in bytes, from the start of a
+ device) that should be skipped over before the partition entries.
+ This is used by the EFI/GPT partition implementation when a device
+ is formatted.
+
+ This setting will override any values configured via Kconfig.
+
+u-boot,mmc-env-partition
+ if present, the environment shall be placed at the last
+ CONFIG_ENV_SIZE blocks of the partition on the
+ CONFIG_SYS_MMC_ENV_DEV.
+
+ if u-boot,mmc-env-offset* is present, this setting will take
+ precedence. In that case, only if the partition is not found,
+ mmc-env-offset* will be tried.
+
+u-boot,mmc-env-offset
+u-boot,mmc-env-offset-redundant
+ If present, the values of the 'u-boot,mmc-env-offset' and/or
+ of the u-boot,mmc-env-offset-redundant' properties overrides
+ CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND, respectively,
+ for SD/MMC devices.
+
+ Values are interpreted as the offset from the start of the
+ device, specified in bytes. It is assumed that the setting
+ will point at the beginning of a LBA and values that are not
+ LBA-aligned will be rounded up to the next LBA address.
+
+u-boot,spl-payload-offset
+ If present (and SPL is controlled by the device-tree), this allows
+ to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
+ from the device-tree.
+
+sysreset-gpio
+ If present (and supported by the specific board), indicates a
+ GPIO that can be set to trigger a system reset. It is assumed
+ that such a system reset will effect a complete platform reset,
+ being roughly equivalent to a power-on reset.
diff --git a/roms/u-boot/doc/device-tree-bindings/cpu/fsl,mpc83xx.txt b/roms/u-boot/doc/device-tree-bindings/cpu/fsl,mpc83xx.txt
new file mode 100644
index 000000000..ac563d906
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/cpu/fsl,mpc83xx.txt
@@ -0,0 +1,34 @@
+MPC83xx CPU devices
+
+MPC83xx SoCs contain a e300 core as their main processor.
+
+Required properties:
+- compatible: must be one of "fsl,mpc83xx",
+ "fsl,mpc8308",
+ "fsl,mpc8309",
+ "fsl,mpc8313",
+ "fsl,mpc8315",
+ "fsl,mpc832x",
+ "fsl,mpc8349",
+ "fsl,mpc8360",
+ "fsl,mpc8379"
+- clocks: has to have two entries, which must be the core clock at index 0 and
+ the CSB (Coherent System Bus) clock at index 1. Both are given by a suitable
+ "fsl,mpc83xx-clk" device
+
+Example:
+
+socclocks: clocks {
+ compatible = "fsl,mpc8315-clk";
+ #clock-cells = <1>;
+};
+
+cpus {
+ compatible = "cpu_bus";
+
+ PowerPC,8315@0 {
+ compatible = "fsl,mpc8315";
+ clocks = <&socclocks MPC83XX_CLK_CORE
+ &socclocks MPC83XX_CLK_CSB>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/cpu/nios2.txt b/roms/u-boot/doc/device-tree-bindings/cpu/nios2.txt
new file mode 100644
index 000000000..0ed2f44bc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/cpu/nios2.txt
@@ -0,0 +1,54 @@
+* Nios II Processor Binding
+
+This binding specifies what properties available in the device tree
+representation of a Nios II Processor Core.
+
+Users can use sopc2dts tool for generating device tree sources (dts) from a
+Qsys system. See more detail in: http://www.alterawiki.com/wiki/Sopc2dts
+
+Required properties:
+
+- compatible: Compatible property value should be "altr,nios2-1.0" or
+ "altr,nios2-1.1".
+- reg: Contains CPU index.
+- clock-frequency: Contains the clock frequency for CPU, in Hz.
+- dcache-line-size: Contains data cache line size.
+- icache-line-size: Contains instruction line size.
+- dcache-size: Contains data cache size.
+- icache-size: Contains instruction cache size.
+- altr,reset-addr: Specifies CPU reset address
+- altr,exception-addr: Specifies CPU exception address
+
+Optional properties:
+- altr,has-initda: Specifies CPU support initda instruction, should be 1.
+- altr,has-mmu: Specifies CPU support MMU support.
+- altr,has-mul: Specifies CPU hardware multipy support.
+- altr,has-div: Specifies CPU hardware divide support
+- altr,implementation: Nios II core implementation, this should be "fast";
+
+Example:
+
+cpu@0x0 {
+ device_type = "cpu";
+ compatible = "altr,nios2-1.0";
+ reg = <0>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ clock-frequency = <125000000>;
+ dcache-line-size = <32>;
+ icache-line-size = <32>;
+ dcache-size = <32768>;
+ icache-size = <32768>;
+ altr,implementation = "fast";
+ altr,pid-num-bits = <8>;
+ altr,tlb-num-ways = <16>;
+ altr,tlb-num-entries = <128>;
+ altr,tlb-ptr-sz = <7>;
+ altr,has-div = <1>;
+ altr,has-mul = <1>;
+ altr,reset-addr = <0xc2800000>;
+ altr,fast-tlb-miss-addr = <0xc7fff400>;
+ altr,exception-addr = <0xd0000020>;
+ altr,has-initda = <1>;
+ altr,has-mmu = <1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/device.txt b/roms/u-boot/doc/device-tree-bindings/device.txt
new file mode 100644
index 000000000..73ce2a3b5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/device.txt
@@ -0,0 +1,75 @@
+Devices
+=======
+
+Device bindings are described by their own individual binding files.
+
+U-Boot provides for some optional properties which are documented here. See
+also hid-over-i2c.txt which describes HID devices. See also
+Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
+the acpi,compatible property.
+
+ - acpi,has-power-resource : (boolean) true if this device has a power resource.
+ This causes an ACPI PowerResource to be written containing the properties
+ provided by this binding, to describe how to handle powering the device up
+ and down using GPIOs
+ - acpi,compatible : compatible string to report
+ - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk Operating
+ System) Device Name)
+ - acpi,hid : Contains the string to use as the HID (Hardware ID)
+ identifier _HID
+ - acpi,path : Specifies the full ACPI path for a device. This overrides the
+ normal path built from the driver-model hierarchy
+ - acpi,name : Provides the ACPI name for a device, which is a string consisting
+ of four alphanumeric character (upper case)
+ - acpi,uid : _UID value for device
+ - acpi,wake : Provides the GPE used to detect a request from a device to wake
+ from sleep
+ - linux,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
+ Linux will only load the driver if the device can be detected (e.g. on I2C
+ bus). Note that this is an out-of-tree Linux feature.
+
+
+Example
+-------
+
+elan_touchscreen: elan-touchscreen@10 {
+ compatible = "i2c-chip";
+ reg = <0x10>;
+ acpi,hid = "ELAN0001";
+ acpi,ddn = "ELAN Touchscreen";
+ interrupts-extended = <&acpi_gpe GPIO_21_IRQ IRQ_TYPE_EDGE_FALLING>;
+ linux,probed;
+};
+
+pcie-a0@14,0 {
+ reg = <0x0000a000 0 0 0 0>;
+ acpi,name = "RP01";
+ wifi: wifi {
+ compatible = "intel,generic-wifi";
+ acpi,ddn = "Intel WiFi";
+ acpi,name = "WF00";
+ acpi,wake = <GPE0_DW3_00>;
+ interrupts-extended = <&acpi_gpe 0x3c 0>;
+ };
+};
+
+p2sb: p2sb@d,0 {
+ u-boot,dm-pre-reloc;
+ reg = <0x02006810 0 0 0 0>;
+ compatible = "intel,apl-p2sb";
+ early-regs = <IOMAP_P2SB_BAR 0x100000>;
+ pci,no-autoconfig;
+
+ n {
+ compatible = "intel,apl-pinctrl";
+ u-boot,dm-pre-reloc;
+ intel,p2sb-port-id = <PID_GPIO_N>;
+ acpi,path = "\\_SB.GPO0";
+ gpio_n: gpio-n {
+ compatible = "intel,gpio";
+ u-boot,dm-pre-reloc;
+ gpio-controller;
+ #gpio-cells = <2>;
+ linux-name = "INT3452:00";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt b/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt
new file mode 100644
index 000000000..694d19591
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt
@@ -0,0 +1,54 @@
+* Exynos DWC_mobile_storage
+
+The Exynos provides DWC_mobile_storage interface which supports
+. Embedded Multimedia Cards (EMMC-version 4.5)
+. Secure Digital memory (SD mem-version 2.0)
+. Secure Digital I/O (SDIO-version 3.0)
+. Consumer Electronics Advanced Transport Architecture (CE-ATA-version 1.1)
+
+The Exynos DWC_mobile_storage provides four channels.
+SOC specific and Board specific properties are channel specific.
+
+Required SoC Specific Properties:
+
+- compatible: should be
+ - samsung,exynos-dwmmc: for exynos platforms
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- samsung,bus-width: The width of the bus used to interface the devices
+ supported by DWC_mobile_storage (SD-MMC/EMMC/SDIO).
+ . Typically the bus width is 4 or 8.
+- samsung,timing: The timing values to be written into the
+ Drv/sample clock selection register of corresponding channel.
+ . It is comprised of 3 values corresponding to the 3 fileds
+ 'SelClk_sample', 'SelClk_drv' and 'DIVRATIO' of CLKSEL register.
+ . SelClk_sample: Select sample clock among 8 shifted clocks.
+ . SelClk_drv: Select drv clock among 8 shifted clocks.
+ . DIVRATIO: Clock Divide ratio select.
+ . The above 3 values are used by the clock phase shifter.
+
+Example:
+
+mmc@12200000 {
+ samsung,bus-width = <8>;
+ samsung,timing = <1 3 3>;
+ samsung,removable = <1>;
+}
+In the above example,
+ . The bus width is 8
+ . Timing is comprised of 3 values as explained below
+ 1 - SelClk_sample
+ 3 - SelClk_drv
+ 3 - DIVRATIO
+ . The 'removable' flag indicates whether the the particilar device
+ cannot be removed (always present) or it is a removable device.
+ 1 - Indicates that the device is removable.
+ 0 - Indicates that the device cannot be removed.
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/emmc-reset.txt b/roms/u-boot/doc/device-tree-bindings/exynos/emmc-reset.txt
new file mode 100644
index 000000000..5e7ba26c2
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/emmc-reset.txt
@@ -0,0 +1,15 @@
+* Samsung eMMC reset
+
+Some exynos boards require special handling of nRESET_OUT line for eMMC memory
+to perform complete reboot.
+
+Required properties:
+- compatible: should be "samsung,emmc-reset"
+- reset-gpio: gpio chip for eMMC reset.
+
+Example:
+
+emmc-reset {
+ compatible = "samsung,emmc-reset";
+ reset-gpio = <&gpk1 2 0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt b/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt
new file mode 100644
index 000000000..b8086e82b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt
@@ -0,0 +1,22 @@
+Exynos ISP SPI Subsystem
+
+The device node for ISP SPI subsytem.
+Since Peripheral id in EXYNOS is decoded based on Interrupts, currently
+ISP SPI have no individual interrupts hence we add ad dummy interrupt node
+which will have a value beyond the maximum number of interrupts exynos5 can
+support.
+
+Required properties :
+ - compatible : Should be "samsung,exynos-spi" for spi.
+ - reg : Base adrress of the the subsystem.
+ - interrupts : A value which is beyond the maximum number of interrupts
+exynos5 can support.
+
+Example:
+spi@131a0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos-spi";
+ reg = <0x131a0000 0x30>;
+ interrupts = <0 129 0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/soc.txt b/roms/u-boot/doc/device-tree-bindings/exynos/soc.txt
new file mode 100644
index 000000000..9ba6f3b9f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/soc.txt
@@ -0,0 +1,21 @@
+Exynos SoC model
+
+The "cpu-model" property is a non-standard extension for the device tree root
+node. Since the cpu id of some Exynos variants does not correspond to product
+name, this property fills the gap.
+
+For almost all Exynos based boards in the kernel, the product name corresponds
+to the device tree file name. The same name is generated in U-Boot, so the new
+property allows doing it automatically.
+
+Required properties:
+ - cpu-model : Exynos product name
+
+Example:
+
+/ {
+ model = "Samsung/Google Peach Pi board based on Exynos5800";
+ cpu-model = "Exynos5800";
+
+ compatible = ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt b/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt
new file mode 100644
index 000000000..98d1798d0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt
@@ -0,0 +1,27 @@
+Exynos Sound Subsystem
+
+The device node for sound subsytem which contains codec and i2s block
+that is a part of Exynos5250
+
+Required properties :
+ - compatible : Should be "samsung,exynos-sound" for sound
+ - samsung,i2s-epll-clock-frequency : epll clock output frequency in Hz
+ - samsung,i2s-sampling-rate : sampling rate, default is 48000
+ - samsung,i2s-bits-per-sample : sample width, defalut is 16 bit
+ - samsung,i2s-channels : nummber of channels, default is 2
+ - samsung,i2s-lr-clk-framesize : lr clock frame size
+ - samsung,i2s-bit-clk-framesize : bit clock frame size
+ - samsung,codec-type : sound codec type
+
+Example:
+
+sound@12d60000 {
+ compatible = "samsung,exynos-sound"
+ samsung,i2s-epll-clock-frequency = <192000000>;
+ samsung,i2s-sampling-rate = <48000>;
+ samsung,i2s-bits-per-sample = <16>;
+ samsung,i2s-channels = <2>;
+ samsung,i2s-lr-clk-framesize = <256>;
+ samsung,i2s-bit-clk-framesize = <32>;
+ samsung,codec-type = "wm8994";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt b/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt
new file mode 100644
index 000000000..89d3bf05f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt
@@ -0,0 +1,44 @@
+Exynos Thermal management Unit
+
+Required properties:
+
+ - compatible : Should be "samsung,exynos-tmu" for TMU
+ - samsung,min-temp : Minimum temperature value (25 degree celsius)
+ - Current temperature of SoC should be more than this value.
+ - samsung,max-temp : Maximum temperature value (125 degree celsius)
+ - Current temperature of SoC should be less than this value.
+ - samsung,start-warning : Temperature at which TMU starts giving warning (degree celsius)
+ - samsung,start-tripping : Temperature at which TMU shuts down the system (degree celsius)
+ - samsung,hw-tripping : Temperature at which hardware tripping should happen
+ in case TMU fails to power off (degree celsius)
+ - samsung,efuse-min-value : SOC efuse min value (Constant 40)
+ - efuse-value should be more than this value.
+ - samsung,efuse-value : SOC actual efuse value (Literal value)
+ - This is the data trimming info.
+ - This value is used to calculate measuring error.
+ - samsung,efuse-max-value : SoC max efuse value (Constant 100)
+ - efuse-value should be less than this value.
+ - samsung,slope : Default value 274761730 (Constant 0x1060_8802).
+ - This is the default value for TMU_CONTROL register.
+ - It sets the gain of amplifier to the positive-tc generator block.
+ - It selects thermal tripping mode and enables thermal tripping.
+ - samsung,dc-value : Measured data calibration value (Constant 25)
+ - Used for tempearture calculation.
+ - This is 25 because temperature measured is always above 25 degrees.
+
+
+Example:
+
+tmu@10060000 {
+ compatible = "samsung,exynos-tmu"
+ samsung,min-temp = <25>;
+ samsung,max-temp = <125>;
+ samsung,start-warning = <95>;
+ samsung,start-tripping = <105>;
+ samsung,hw-tripping = <110>;
+ samsung,efuse-min-value = <40>;
+ samsung,efuse-value = <55>;
+ samsung,efuse-max-value = <100>;
+ samsung,slope = <274761730>;
+ samsung,dc-value = <25>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/firmware/linaro,optee-tz.txt b/roms/u-boot/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
new file mode 100644
index 000000000..d38834c67
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible property for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible : should contain "linaro,optee-tz"
+
+- method : The method of calling the OP-TEE Trusted OS. Permitted
+ values are:
+
+ "smc" : SMC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+
+ "hvc" : HVC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/firmware/nvidia,tegra186-bpmp.txt b/roms/u-boot/doc/device-tree-bindings/firmware/nvidia,tegra186-bpmp.txt
new file mode 100644
index 000000000..447252e88
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -0,0 +1,104 @@
+NVIDIA Tegra Boot and Power Management Processor (BPMP)
+
+The BPMP is a specific processor in Tegra chip, which is designed for
+booting process handling and offloading the power management, clock
+management, and reset control tasks from the CPU. The binding document
+defines the resources that would be used by the BPMP firmware driver,
+which can create the interprocessor communication (IPC) between the CPU
+and BPMP.
+
+Required properties:
+- name : Should be bpmp
+- compatible
+ Array of strings
+ One of:
+ - "nvidia,tegra186-bpmp"
+- mboxes : The phandle of mailbox controller and the mailbox specifier.
+- shmem : List of the phandle of the TX and RX shared memory area that
+ the IPC between CPU and BPMP is based on.
+- #clock-cells : Should be 1.
+- #power-domain-cells : Should be 1.
+- #reset-cells : Should be 1.
+
+This node is a mailbox consumer. See the following files for details of
+the mailbox subsystem, and the specifiers implemented by the relevant
+provider(s):
+
+- .../mailbox/mailbox.txt
+- .../mailbox/nvidia,tegra186-hsp.txt
+
+This node is a clock, power domain, and reset provider. See the following
+files for general documentation of those features, and the specifiers
+implemented by this node:
+
+- .../clock/clock-bindings.txt
+- <dt-bindings/clock/tegra186-clock.h>
+- ../power/power_domain.txt
+- <dt-bindings/power/tegra186-powergate.h>
+- .../reset/reset.txt
+- <dt-bindings/reset/tegra186-reset.h>
+
+The BPMP implements some services which must be represented by separate nodes.
+For example, it can provide access to certain I2C controllers, and the I2C
+bindings represent each I2C controller as a device tree node. Such nodes should
+be nested directly inside the main BPMP node.
+
+Software can determine whether a child node of the BPMP node represents a device
+by checking for a compatible property. Any node with a compatible property
+represents a device that can be instantiated. Nodes without a compatible
+property may be used to provide configuration information regarding the BPMP
+itself, although no such configuration nodes are currently defined by this
+binding.
+
+The BPMP firmware defines no single global name-/numbering-space for such
+services. Put another way, the numbering scheme for I2C buses is distinct from
+the numbering scheme for any other service the BPMP may provide (e.g. a future
+hypothetical SPI bus service). As such, child device nodes will have no reg
+property, and the BPMP node will have no #address-cells or #size-cells property.
+
+The shared memory bindings for BPMP
+-----------------------------------
+
+The shared memory area for the IPC TX and RX between CPU and BPMP are
+predefined and work on top of sysram, which is an SRAM inside the chip.
+
+See ".../sram/sram.txt" for the bindings.
+
+Example:
+
+hsp_top0: hsp@03c00000 {
+ ...
+ #mbox-cells = <2>;
+};
+
+sysram@30000000 {
+ compatible = "nvidia,tegra186-sysram", "mmio-sram";
+ reg = <0x0 0x30000000 0x0 0x50000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>;
+
+ cpu_bpmp_tx: bpmp_shmem@4e000 {
+ compatible = "nvidia,tegra186-bpmp-shmem";
+ reg = <0x0 0x4e000 0x0 0x1000>;
+ };
+
+ cpu_bpmp_rx: bpmp_shmem@4f000 {
+ compatible = "nvidia,tegra186-bpmp-shmem";
+ reg = <0x0 0x4f000 0x0 0x1000>;
+ };
+};
+
+bpmp {
+ compatible = "nvidia,tegra186-bpmp";
+ mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_BPMP>;
+ shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+
+ i2c {
+ compatible = "...";
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/firmware/ti,sci.txt b/roms/u-boot/doc/device-tree-bindings/firmware/ti,sci.txt
new file mode 100644
index 000000000..4d40d0dcb
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/firmware/ti,sci.txt
@@ -0,0 +1,76 @@
+Texas Instruments System Control Interface (TI-SCI) Message Protocol
+--------------------------------------------------------------------
+
+Texas Instrument's processors including those belonging to Keystone generation
+of processors have separate hardware entity which is now responsible for the
+management of the System on Chip (SoC) system. These include various system
+level functions as well.
+
+An example of such an SoC is K2G, which contains the system control hardware
+block called Power Management Micro Controller (PMMC). This hardware block is
+initialized early into boot process and provides services to Operating Systems
+on multiple processors including ones running Linux.
+
+See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+
+TI-SCI controller Device Node:
+=============================
+
+The TI-SCI node describes the Texas Instrument's System Controller entity node.
+This parent node may optionally have additional children nodes which describe
+specific functionality such as clocks, power domain, reset or additional
+functionality as may be required for the SoC. This hierarchy also describes the
+relationship between the TI-SCI parent node to the child node.
+
+Required properties:
+-------------------
+- compatible: should be "ti,k2g-sci"
+- mbox-names:
+ "rx" - Mailbox corresponding to receive path
+ "tx" - Mailbox corresponding to transmit path
+
+- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
+ property should contain a phandle to the mailbox controller device
+ node and an args specifier that will be the phandle to the intended
+ sub-mailbox child node to be used for communication.
+
+Optional Properties:
+-------------------
+- reg-names:
+ debug_messages - Map the Debug message region
+- reg: register space corresponding to the debug_messages
+- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,secure-host: If the host is defined as secure.
+
+Example:
+-------------
+ dmsc: dmsc {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ }
+
+
+TI-SCI Client Device Node:
+=========================
+
+Client nodes are maintained as children of the relevant TI-SCI device node.
+
+Example:
+-------------
+ dmsc: dmsc {
+ compatible = "ti,k2g-sci";
+ ...
+
+ my_clk_node: clk_node {
+ ...
+ ...
+ };
+
+ my_pd_node: pd_node {
+ ...
+ ...
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt b/roms/u-boot/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
new file mode 100644
index 000000000..da210bfc8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
@@ -0,0 +1,43 @@
+Altera SOCFPGA Arria10 FPGA Manager
+
+Required properties:
+- compatible : should contain "altr,socfpga-a10-fpga-mgr"
+- reg : base address and size for memory mapped io.
+ - The first index is for FPGA manager register access.
+ - The second index is for writing FPGA configuration data.
+- resets : Phandle and reset specifier for the device's reset.
+- clocks : Clocks used by the device.
+- altr,bitstream : Fit image file name for both FPGA peripheral bitstream,
+ FPGA core bitstream and full bitstream.
+
+ Full bitstream, consist of peripheral bitstream and core
+ bitstream.
+
+ FPGA peripheral bitstream is used to initialize FPGA IOs,
+ PLL, IO48 and DDR. This bitstream is required to get DDR up
+ running.
+
+ FPGA core bitstream contains FPGA design which is used to
+ program FPGA CRAM and ERAM.
+
+Example: Bundles both peripheral bitstream and core bitstream into FIT image
+ called fit_spl_fpga.itb. This FIT image can be created through running
+ this command: tools/mkimage
+ -E -p 400
+ -f board/altera/arria10-socdk/fit_spl_fpga.its
+ fit_spl_fpga.itb
+
+ For details of describing structure and contents of the FIT image,
+ please refer board/altera/arria10-socdk/fit_spl_fpga.its
+
+- Examples for booting with full release or booting with early IO release, then
+ follow by entering early user mode:
+
+ fpga_mgr: fpga-mgr@ffd03000 {
+ compatible = "altr,socfpga-a10-fpga-mgr";
+ reg = <0xffd03000 0x100
+ 0xffcfe400 0x20>;
+ clocks = <&l4_mp_clk>;
+ resets = <&rst FPGAMGR_RESET>;
+ altr,bitstream = "fit_spl_fpga.itb";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt b/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
new file mode 100644
index 000000000..36936f2eb
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt
@@ -0,0 +1,327 @@
+* Intel FSP-M configuration
+
+Several Intel platforms require the execution of the Intel FSP (Firmware
+Support Package) for initialization. The FSP consists of multiple parts, one
+of which is the FSP-M (Memory initialization phase).
+
+This binding applies to the FSP-M for the Intel Apollo Lake SoC.
+
+The FSP-M is available on Github [1].
+For detailed information on the FSP-M parameters see the documentation in
+FSP/ApolloLakeFspBinPkg/Docs [2].
+
+The properties of this binding are all optional. If no properties are set the
+values of the FSP-M are used.
+
+[1] https://github.com/IntelFsp/FSP
+[2] https://github.com/IntelFsp/FSP/tree/master/ApolloLakeFspBinPkg/Docs
+
+Optional properties:
+- fspm,training-delay: Time taken to train DDR memory if there is no cached MRC
+ data, in seconds. This is used to show a message if possible. For Chromebook
+ Coral this is typically 21 seconds. For an APL board with 1GB of RAM, it may
+ be only 6 seconds.
+- fspm,serial-debug-port-address: Debug Serial Port Base address
+- fspm,serial-debug-port-type: Debug Serial Port Type
+ 0: NONE
+ 1: I/O
+ 2: MMIO (default)
+- fspm,serial-debug-port-device: Serial Port Debug Device
+ 0: SOC UART0
+ 1: SOC UART1
+ 2: SOC UART2 (default)
+ 3: External Device
+- fspm,serial-debug-port-stride-size: Debug Serial Port Stride Size
+ 0: 1
+ 2: 4 (default)
+- fspm,mrc-fast-boot: Memory Fast Boot
+- fspm,igd: Integrated Graphics Device
+- fspm,igd-dvmt50-pre-alloc: DVMT Pre-Allocated
+ 0x02: 64 MB (default)
+ 0x03: 96 MB
+ 0x04: 128 MB
+ 0x05: 160 MB
+ 0x06: 192 MB
+ 0x07: 224 MB
+ 0x08: 256 MB
+ 0x09: 288 MB
+ 0x0A: 320 MB
+ 0x0B: 352 MB
+ 0x0C: 384 MB
+ 0x0D: 416 MB
+ 0x0E: 448 MB
+ 0x0F: 480 MB
+ 0x10: 512 MB
+- fspm,aperture-size: Aperture Size
+ 0x1: 128 MB (default)
+ 0x2: 256 MB
+ 0x3: 512 MB
+- fspm,gtt-size: GTT Size
+ 0x1: 2 MB
+ 0x2: 4 MB
+ 0x3: 8 MB (default)
+- fspm,primary-video-adaptor: Primary Display
+ 0x0: AUTO (default)
+ 0x2: IGD
+ 0x3: PCI
+- fspm,package: Package
+ 0x0: SODIMM (default)
+ 0x1: BGA
+ 0x2: BGA mirrored (LPDDR3 only)
+ 0x3: SODIMM/UDIMM with Rank 1 Mirrored (DDR3L)
+- fspm,profile: Profile
+ 0x01: WIO2_800_7_8_8
+ 0x02: WIO2_1066_9_10_10
+ 0x03: LPDDR3_1066_8_10_10
+ 0x04: LPDDR3_1333_10_12_12
+ 0x05: LPDDR3_1600_12_15_15
+ 0x06: LPDDR3_1866_14_17_17
+ 0x07: LPDDR3_2133_16_20_20
+ 0x08: LPDDR4_1066_10_10_10
+ 0x09: LPDDR4_1600_14_15_15
+ 0x0A: LPDDR4_2133_20_20_20
+ 0x0B: LPDDR4_2400_24_22_22
+ 0x0C: LPDDR4_2666_24_24_24
+ 0x0D: LPDDR4_2933_28_27_27
+ 0x0E: LPDDR4_3200_28_29_29
+ 0x0F: DDR3_1066_6_6_6
+ 0x10: DDR3_1066_7_7_7
+ 0x11: DDR3_1066_8_8_8
+ 0x12: DDR3_1333_7_7_7
+ 0x13: DDR3_1333_8_8_8
+ 0x14: DDR3_1333_9_9_9
+ 0x15: DDR3_1333_10_10_10
+ 0x16: DDR3_1600_8_8_8
+ 0x17: DDR3_1600_9_9_9
+ 0x18: DDR3_1600_10_10_10
+ 0x19: DDR3_1600_11_11_11 (default)
+ 0x1A: DDR3_1866_10_10_10
+ 0x1B: DDR3_1866_11_11_11
+ 0x1C: DDR3_1866_12_12_12
+ 0x1D: DDR3_1866_13_13_13
+ 0x1E: DDR3_2133_11_11_11
+ 0x1F: DDR3_2133_12_12_12
+ 0x20: DDR3_2133_13_13_13
+ 0x21: DDR3_2133_14_14_14
+ 0x22: DDR4_1333_10_10_10
+ 0x23: DDR4_1600_10_10_10
+ 0x24: DDR4_1600_11_11_11
+ 0x25: DDR4_1600_12_12_12
+ 0x26: DDR4_1866_12_12_12
+ 0x27: DDR4_1866_13_13_13
+ 0x28: DDR4_1866_14_14_14
+ 0x29: DDR4_2133_14_14_14
+ 0x2A: DDR4_2133_15_15_15
+ 0x2B: DDR4_2133_16_16_16
+ 0x2C: DDR4_2400_15_15_15
+ 0x2D: DDR4_2400_16_16_16
+ 0x2E: DDR4_2400_17_17_17
+ 0x2F: DDR4_2400_18_18_18
+- fspm,memory-down: Memory Down
+ 0x0: No (default)
+ 0x1: Yes
+ 0x2: 1MD+SODIMM (for DDR3L only) ACRD
+ 0x3: 1x32 LPDDR4
+- fspm,ddr3l-page-size: DDR3LPageSize
+ 0x1: 1KB (default)
+ 0x2: 2KB
+- fspm,ddr3-lasr: DDR3LASR
+- fspm,scrambler-support: ScramblerSupport
+- fspm,interleaved-mode: InterleavedMode
+- fspm,channel-hash-mask: ChannelHashMask
+- fspm,fspm,slice-hash-mask: SliceHashMask
+- fspm,channels-slices-enable: ChannelsSlices
+- fspm,min-ref-rate2x-enable: MinRefRate2x
+- fspm,dual-rank-support-enable: DualRankSupport
+- fspm,rmt-mode: RmtMode
+- fspm,memory-size-limit: MemorySizeLimit
+- fspm,low-memory-max-value: LowMemoryMaxValue
+- fspm,high-memory-max-value: HighMemoryMaxValue
+- fspm,disable-fast-boot: FastBoot
+- fspm,dimm0-spd-address: DIMM0 SPD Address
+- fspm,dimm1-spd-address: DIMM1 SPD Address
+- fspm,chX-rank-enable: Must be set to enable rank (X = 0-3)
+- fspm,chX-device-width: DRAM device width per DRAM channel (X = 0-3)
+ 0: x8
+ 1: x16
+ 2: x32
+ 3: x64
+- fspm,chX-dram-density: Must specify the DRAM device density (X = 0-3)
+ 0: 4Gb
+ 1: 6Gb
+ 2: 8Gb
+ 3: 12Gb
+ 4: 16Gb
+ 5: 2Gb
+- fspm,chX-option: Channel options (X = 0-3)
+- fspm,chX-odt-config: Channel Odt Config (X = 0-3)
+- fspm,chX-mode2-n: Force 2N Mode (X = 0-3)
+ 0x0: Auto
+ 0x1: Force 2N CMD Timing Mode
+- fspm,chX-odt-levels: Channel Odt Levels (X = 0-3)
+ 0: ODT Connected to SoC
+ 1: ODT held high
+- fspm,rmt-check-run: RmtCheckRun
+- fspm,rmt-margin-check-scale-high-threshold: RmtMarginCheckScaleHighThreshold
+- fspm,ch-bit-swizzling: Bit_swizzling
+- fspm,msg-level-mask: MsgLevelMask
+- fspm,pre-mem-gpio-table-pin-num: PreMem GPIO Pin Number for each table
+- fspm,pre-mem-gpio-table-ptr: PreMem GPIO Table Pointer
+- fspm,pre-mem-gpio-table-entry-num: PreMem GPIO Table Entry Number
+- fspm,enhance-port8xh-decoding: Enhance the port 8xh decoding
+- fspm,spd-write-enable: SPD Data Write
+- fspm,mrc-data-saving: MRC Training Data Saving
+- fspm,oem-loading-base: OEM File Loading Address
+- fspm,oem-file-name: OEM File Name to Load
+- fspm,mrc-boot-data-ptr:
+- fspm,emmc-trace-len: eMMC Trace Length
+ 0x0: Long
+ 0x1: Short
+- fspm,skip-cse-rbp: Skip CSE RBP to support zero sized IBB
+- fspm,npk-en: Npk Enable
+ 0: Disable
+ 1: Enable
+ 2: Debugger
+ 3: Auto (default)
+- fspm,fw-trace-en: FW Trace Enable
+- fspm,fw-trace-destination: FW Trace Destination
+ 1: NPK_TRACE_TO_MEMORY
+ 2: NPK_TRACE_TO_DCI
+ 3: NPK_TRACE_TO_BSSB
+ 4: NPK_TRACE_TO_PTI (default)
+- fspm,recover-dump: NPK Recovery Dump
+- fspm,msc0-wrap: Memory Region 0 Buffer WrapAround
+ 0: n0-warp
+ 1: n1-warp (default)
+- fspm,msc1-wrap: Memory Region 1 Buffer WrapAround
+ 0: n0-warp
+ 1: n1-warp (default)
+- fspm,msc0-size: Memory Region 0 Buffer Size
+ 0: 0MB (default)
+ 1: 1MB
+ 2: 8MB
+ 3: 64MB
+ 4: 128MB
+ 5: 256MB
+ 6: 512MB
+ 7: 1GB
+- fspm,msc1-size: Memory Region 1 Buffer Size
+ 0: 0MB (default)
+ 1: 1MB
+ 2: 8MB
+ 3: 64MB
+ 4: 128MB
+ 5: 256MB
+ 6: 512MB
+ 7: 1GB
+- fspm,pti-mode: PTI Mode
+ 0: 0ff
+ 1: x4 (default)
+ 2: x8
+ 3: x12
+ 4: x16
+- fspm,pti-training: PTI Training
+ 0: off (default)
+ 1-6: 1-6
+- fspm,pti-speed:
+ 0: full
+ 1: half
+ 2: quarter (default)
+- fspm,punit-mlvl: Punit Message Level
+ 0:
+ 1: (default)
+ 2-4: 2-4
+- fspm,pmc-mlvl: PMC Message Level
+ 0:
+ 1: (default)
+ 2-4: 2-4
+- fspm,sw-trace-en: SW Trace Enable
+- fspm,periodic-retraining-disable: Periodic Retraining Disable
+- fspm,enable-reset-system: Enable Reset System
+- fspm,enable-s3-heci2: Enable HECI2 in S3 resume path
+- fspm,variable-nvs-buffer-ptr:
+- fspm,start-timer-ticker-of-pfet-assert: PCIE SLOT Power Enable Assert Time - PFET
+- fspm,rt-en: Real Time Enabling
+- fspm,skip-pcie-power-sequence: Skip Pcie Power Sequence
+
+Example:
+
+&host_bridge {
+ fspm,package = <PACKAGE_BGA>;
+ fspm,profile = <PROFILE_LPDDR4_2400_24_22_22>;
+ fspm,memory-down = <MEMORY_DOWN_YES>;
+ fspm,scrambler-support = <1>;
+ fspm,interleaved-mode = <INTERLEAVED_MODE_ENABLE>;
+ fspm,channel-hash-mask = <0x36>;
+ fspm,slice-hash-mask = <0x9>;
+ fspm,low-memory-max-value = <2048>;
+ fspm,ch0-rank-enable = <1>;
+ fspm,ch0-device-width = <CHX_DEVICE_WIDTH_X16>;
+ fspm,ch0-dram-density = <CHX_DEVICE_DENSITY_8GB>;
+ fspm,ch0-option = <(CHX_OPTION_RANK_INTERLEAVING |
+ CHX_OPTION_BANK_ADDRESS_HASHING_ENABLE)>;
+ fspm,ch0-odt-config = <CHX_ODT_CONFIG_DDR4_CA_ODT>;
+ fspm,ch1-rank-enable = <1>;
+ fspm,ch1-device-width = <CHX_DEVICE_WIDTH_X16>;
+ fspm,ch1-dram-density = <CHX_DEVICE_DENSITY_8GB>;
+ fspm,ch1-option = <(CHX_OPTION_RANK_INTERLEAVING |
+ CHX_OPTION_BANK_ADDRESS_HASHING_ENABLE)>;
+ fspm,ch1-odt-config = <CHX_ODT_CONFIG_DDR4_CA_ODT>;
+ fspm,ch2-rank-enable = <1>;
+ fspm,ch2-device-width = <CHX_DEVICE_WIDTH_X16>;
+ fspm,ch2-dram-density = <CHX_DEVICE_DENSITY_8GB>;
+ fspm,ch2-option = <(CHX_OPTION_RANK_INTERLEAVING |
+ CHX_OPTION_BANK_ADDRESS_HASHING_ENABLE)>;
+ fspm,ch2-odt-config = <CHX_ODT_CONFIG_DDR4_CA_ODT>;
+ fspm,ch3-rank-enable = <1>;
+ fspm,ch3-device-width = <CHX_DEVICE_WIDTH_X16>;
+ fspm,ch3-dram-density = <CHX_DEVICE_DENSITY_8GB>;
+ fspm,ch3-option = <(CHX_OPTION_RANK_INTERLEAVING |
+ CHX_OPTION_BANK_ADDRESS_HASHING_ENABLE)>;
+ fspm,ch3-odt-config = <CHX_ODT_CONFIG_DDR4_CA_ODT>;
+ fspm,fspm,skip-cse-rbp = <1>;
+
+ fspm,ch-bit-swizzling = /bits/ 8 <
+ /* LP4_PHYS_CH0A */
+
+ /* DQA[0:7] pins of LPDDR4 module */
+ 6 7 5 4 3 1 0 2
+ /* DQA[8:15] pins of LPDDR4 module */
+ 12 10 11 13 14 8 9 15
+ /* DQB[0:7] pins of LPDDR4 module with offset of 16 */
+ 16 22 23 20 18 17 19 21
+ /* DQB[7:15] pins of LPDDR4 module with offset of 16 */
+ 30 28 29 25 24 26 27 31
+
+ /* LP4_PHYS_CH0B */
+ /* DQA[0:7] pins of LPDDR4 module */
+ 7 3 5 2 6 0 1 4
+ /* DQA[8:15] pins of LPDDR4 module */
+ 9 14 12 13 10 11 8 15
+ /* DQB[0:7] pins of LPDDR4 module with offset of 16 */
+ 20 22 23 16 19 17 18 21
+ /* DQB[7:15] pins of LPDDR4 module with offset of 16 */
+ 28 24 26 27 29 30 31 25
+
+ /* LP4_PHYS_CH1A */
+
+ /* DQA[0:7] pins of LPDDR4 module */
+ 2 1 6 7 5 4 3 0
+ /* DQA[8:15] pins of LPDDR4 module */
+ 11 10 8 9 12 15 13 14
+ /* DQB[0:7] pins of LPDDR4 module with offset of 16 */
+ 17 23 19 16 21 22 20 18
+ /* DQB[7:15] pins of LPDDR4 module with offset of 16 */
+ 31 29 26 25 28 27 24 30
+
+ /* LP4_PHYS_CH1B */
+
+ /* DQA[0:7] pins of LPDDR4 module */
+ 4 3 7 5 6 1 0 2
+ /* DQA[8:15] pins of LPDDR4 module */
+ 15 9 8 11 14 13 12 10
+ /* DQB[0:7] pins of LPDDR4 module with offset of 16 */
+ 20 23 22 21 18 19 16 17
+ /* DQB[7:15] pins of LPDDR4 module with offset of 16 */
+ 25 28 30 31 26 27 24 29>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt b/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
new file mode 100644
index 000000000..dc8e3251a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
@@ -0,0 +1,490 @@
+* Intel FSP-S configuration
+
+Several Intel platforms require the execution of the Intel FSP (Firmware
+Support Package) for initialization. The FSP consists of multiple parts, one
+of which is the FSP-S (Silicon initialization phase).
+
+This binding applies to the FSP-S for the Intel Apollo Lake SoC.
+
+The FSP-S is available on Github [1].
+For detailed information on the FSP-S parameters see the documentation in
+FSP/ApolloLakeFspBinPkg/Docs [2].
+
+The properties of this binding are all optional. If no properties are set the
+values of the FSP-S are used.
+
+[1] https://github.com/IntelFsp/FSP
+[2] https://github.com/IntelFsp/FSP/tree/master/ApolloLakeFspBinPkg/Docs
+
+Optional properties:
+- fsps,active-processor-cores: ActiveProcessorCores
+- fsps,disable-core1: Disable Core1
+- fsps,disable-core2: Disable Core2
+- fsps,disable-core2: Disable Core3
+- fsps,vmx-enable: VMX Enable
+- fsps,proc-trace-mem-size: Memory region allocation for Processor Trace
+ 0xFF: Disable (default)
+- fsps,proc-trace-enable: Enable Processor Trace
+- fsps,eist: Eist
+- fsps,boot-p-state: Boot PState
+ 0: HFM (default)
+ 1: LFM
+- fsps,enable-cx: CPU power states (C-states)
+- fsps,c1e: Enhanced C-states
+- fsps,bi-proc-hot: Bi-Directional PROCHOT#
+- fsps,pkg-c-state-limit: Max Pkg Cstate
+ 0: PkgC0C1
+ 1: PkgC2
+ 2: PkgC3 (default)
+ 3: PkgC6
+ 4: PkgC7
+ 5: PkgC7s
+ 6: PkgC8
+ 7: PkgC9
+ 8: PkgC10
+ 9: PkgCMax
+ 254: PkgCpuDefault
+ 255: PkgAuto
+- fsps,c-state-auto-demotion: C-State auto-demotion
+ 0: Disable C1 and C3 Auto-demotion (default)
+ 1: Enable C3/C6/C7 Auto-demotion to C1
+ 2: Enable C6/C7 Auto-demotion to C3
+ 3: Enable C6/C7 Auto-demotion to C1 and C3
+- fsps,c-state-un-demotion: C-State un-demotion
+ 0: Disable C1 and C3 Un-demotion (default)
+ 1: Enable C1 Un-demotion
+ 2: Enable C3 Un-demotion
+ 3: Enable C1 and C3 Un-demotion
+- fsps,max-core-c-state: Max Core C-State
+ 0: Unlimited
+ 1: C1
+ 2: C3
+ 3: C6
+ 4: C7
+ 5: C8
+ 6: C9
+ 7: C10
+ 8: CCx (default)
+- fsps,pkg-c-state-demotion: Package C-State Demotion
+- fsps,pkg-c-state-un-demotion: Package C-State Un-demotion
+- fsps,turbo-mode: Turbo Mode
+- fsps,hda-verb-table-entry-num: SC HDA Verb Table Entry Number
+ 0: (default)
+- fsps,hda-verb-table-ptr: SC HDA Verb Table Pointer
+ 0x00000000: (default)
+- fsps,p2sb-unhide: Enable/Disable P2SB device hidden
+- fsps,ipu-en: IPU Enable/Disable
+- fsps,ipu-acpi-mode: IMGU ACPI mode selection
+ 0: Auto
+ 1: IGFX Child device (default)
+ 2: ACPI device
+- fsps,force-wake: Enable ForceWake
+- fsps,gtt-mm-adr: GttMmAdr
+ 0xbf000000: (default)
+- fsps,gm-adr: GmAdr
+ 0xa0000000: (default)
+- fsps,pavp-lock: Enable PavpLock
+- fsps,graphics-freq-modify: Enable GraphicsFreqModify
+- fsps,graphics-freq-req: Enable GraphicsFreqReq
+- fsps,graphics-video-freq: Enable GraphicsVideoFreq
+- fsps,pm-lock: Enable PmLock
+- fsps,dop-clock-gating: Enable DopClockGating
+- fsps,unsolicited-attack-override: Enable UnsolicitedAttackOverride
+- fsps,wopcm-support: Enable WOPCMSupport
+- fsps,wopcm-size: Enable WOPCMSize
+- fsps,power-gating: Enable PowerGating
+- fsps,unit-level-clock-gating: Enable UnitLevelClockGating
+- fsps,fast-boot: Enable FastBoot
+- fsps,dyn-sr: Enable DynSR
+- fsps,sa-ipu-enable: Enable SaIpuEnable
+- fsps,pm-support: GT PM Support
+- fsps,enable-render-standby: RC6(Render Standby)
+- fsps,logo-size: BMP Logo Data Size
+- fsps,logo-ptr: BMP Logo Data Pointer
+- fsps,graphics-config-ptr: Graphics Configuration Data Pointer
+- fsps,pavp-enable: PAVP Enable
+- fsps,pavp-pr3: PAVP PR3
+- fsps,cd-clock: CdClock Frequency selection
+ 0: 144MHz
+ 1: 288MHz
+ 2: 384MHz
+ 3: 576MHz
+ 4: 624MHz (default)
+- fsps,pei-graphics-peim-init: Enable/Disable PeiGraphicsPeimInit
+- fsps,write-protection-enable: Write Protection Support
+- fsps,read-protection-enable: Read Protection Support
+- fsps,protected-range-limit: Protected Range Limitation
+ 0x0FFF: (default)
+- fsps,protected-range-base: Protected Range Base
+ 0x0000: (default)
+- fsps,gmm: Enable SC Gaussian Mixture Models
+- fsps,clk-gating-pgcb-clk-trunk: GMM Clock Gating - PGCB Clock Trunk
+- fsps,clk-gating-sb: GMM Clock Gating - Sideband
+- fsps,clk-gating-sb-clk-trunk: GMM Clock Gating - Sideband
+- fsps,clk-gating-sb-clk-partition: GMM Clock Gating - Sideband Clock
+ Partition
+- fsps,clk-gating-core: GMM Clock Gating - Core
+- fsps,clk-gating-dma: GMM Clock Gating - DMA
+- fsps,clk-gating-reg-access: GMM Clock Gating - Register Access
+- fsps,clk-gating-host: GMM Clock Gating - Host
+- fsps,clk-gating-partition: GMM Clock Gating - Partition
+- fsps,clk-gating-trunk: Clock Gating - Trunk
+- fsps,hda-enable: HD Audio Support
+- fsps,dsp-enable: HD Audio DSP Support
+- fsps,pme: Azalia wake-on-ring
+- fsps,hd-audio-io-buffer-ownership: HD-Audio I/O Buffer Ownership
+ 0: HD-Audio link owns all the I/O buffers (default)
+ 1: HD-Audio link owns 4 I/O buffers and I2S port owns 4 I/O buffers
+ 3: I2S port owns all the I/O buffers
+- fsps,hd-audio-io-buffer-voltage: HD-Audio I/O Buffer Voltage
+ 0: 3.3V (default)
+ 1: 1.8V
+- fsps,hd-audio-vc-type: HD-Audio Virtual Channel Type
+ 0: VC0 (default)
+ 1: VC1
+- fsps,hd-audio-link-frequency: HD-Audio Link Frequency
+ 0: 6MHz (default)
+ 1: 12MHz
+ 2: 24MHz
+ 3: 48MHz
+ 4: 96MHz
+ 5: Invalid
+- fsps,hd-audio-i-disp-link-frequency: HD-Audio iDisp-Link Frequency
+ 0: 6MHz (default)
+ 1: 12MHz
+ 2: 24MHz
+ 3: 48MHz
+ 4: 96MHz
+ 5: Invalid
+- fsps,hd-audio-i-disp-link-tmode: HD-Audio iDisp-Link T-Mode
+ 0: 2T (default)
+ 1: 1T
+- fsps,dsp-endpoint-dmic: HD-Audio Disp DMIC
+ 0: disable,
+ 1: 2ch array (default)
+ 2: 4ch array
+- fsps,dsp-endpoint-bluetooth: HD-Audio Bluetooth
+- fsps,dsp-endpoint-i2s-skp: HD-Audio I2S SHK
+- fsps,dsp-endpoint-i2s-hp: HD-Audio I2S HP
+- fsps,audio-ctl-pwr-gate: HD-Audio Controller Power Gating (deprecated)
+- fsps,audio-dsp-pwr-gate: HD-Audio ADSP Power Gating (deprecated)
+- fsps,mmt: HD-Audio CSME Memory Transfers
+ 0: VC0 (default)
+ 1: VC2
+- fsps,hmt: HD-Audio Host Memory Transfers
+ 0: VC0 (default)
+ 1: VC2
+- fsps,hd-audio-pwr-gate: HD-Audio Power Gating
+- fsps,hd-audio-clk-gate: HD-Audio Clock Gating
+- fsps,dsp-feature-mask: Bitmask of DSP Feature
+ 0x01: WoV
+ 0x02: BT Sideband
+ 0x04: Codec VAD
+ 0x20: BT Intel HFP
+ 0x40: BT Intel A2DP
+ 0x80: DSP based speech pre-processing disabled
+- fsps,dsp-pp-module-mask: Bitmask of supported DSP Post-Processing Modules
+ 0x01: WoV
+ 0x02: BT Sideband
+ 0x04: Codec VAD
+ 0x20: BT Intel HFP
+ 0x40: BT Intel A2DP
+ 0x80: DSP based speech pre-processing disabled
+- fsps,bios-cfg-lock-down: HD-Audio BIOS Configuration Lock Down
+- fsps,hpet: Enable High Precision Timer
+- fsps,hpet-bdf-valid: Hpet Valid BDF Value
+- fsps,hpet-bus-number: Bus Number of Hpet
+ 0xFA: (default)
+- fsps,hpet-device-number: Device Number of Hpet
+ 0x1F: (default)
+- fsps,hpet-function-number: Function Number of Hpet
+ 0x00: (default)
+- fsps,io-apic-bdf-valid: IoApic Valid BDF Value
+- fsps,io-apic-bus-number: Bus Number of IoApic
+ 0xFA: (default)
+- fsps,io-apic-device-number: Device Number of IoApic
+ 0x0F: (default)
+- fsps,io-apic-function-number: Function Number of IoApic
+ 0x00: (default)
+- fsps,io-apic-entry24-119: IOAPIC Entry 24-119
+- fsps,io-apic-id: IO APIC ID
+ 0x01: (default)
+- fsps,io-apic-range-select: IoApic Range
+ 0x00: (default)
+- fsps,ish-enable: ISH Controller
+- fsps,bios-interface: BIOS Interface Lock Down
+- fsps,bios-lock: Bios LockDown Enable
+- fsps,spi-eiss: SPI EISS Status
+- fsps,bios-lock-sw-smi-number: BiosLock SWSMI Number
+ 0xA9: (default)
+- fsps,lpss-s0ix-enable: LPSS IOSF PMCTL S0ix Enable
+- fsps,i2c-clk-gate-cfg: LPSS I2C Clock Gating Configuration
+- fsps,hsuart-clk-gate-cfg: LPSS HSUART Clock Gating Configuration
+- fsps,spi-clk-gate-cfg: LPSS SPI Clock Gating Configuration
+- fsps,i2cX-enable: 2C Device X
+ 0: Disabled
+ 1: PCI Mode (default)
+ 2: ACPI Mode
+- fsps,hsuartX-enable: UART Device X
+ 0: Disabled
+ 1: PCI Mode (default)
+ 2: ACPI Mode
+- fsps,spiX-enable: SPI UART Device X
+ 0: Disabled
+ 1: PCI Mode (default)
+ 2: ACPI Mode
+- fsps,os-dbg-enable: OS Debug Feature
+- fsps,dci-en: DCI Feature
+- fsps,uart2-kernel-debug-base-address: UART Debug Base Address
+ 0x00000000: (default)
+- fsps,pcie-clock-gating-disabled: Enable PCIE Clock Gating
+- fsps,pcie-root-port8xh-decode: Enable PCIE Root Port 8xh Decode
+- fsps,pcie8xh-decode-port-index: PCIE 8xh Decode Port Index
+ 0x00: (default)
+- fsps,pcie-root-port-peer-memory-write-enable: Enable PCIE Root Port Peer
+ Memory Write
+- fsps,pcie-aspm-sw-smi-number: PCIE SWSMI Number
+ 0xAA: (default)
+- fsps,pcie-root-port-en: PCI Express Root Port
+- fsps,pcie-rp-hide: Hide PCIE Root Port Configuration Space
+- fsps,pcie-rp-slot-implemented: PCIE Root Port Slot Implement
+- fsps,pcie-rp-hot-plug: Hot Plug
+- fsps,pcie-rp-pm-sci: PCIE PM SCI
+- fsps,pcie-rp-ext-sync: PCIE Root Port Extended Sync
+- fsps,pcie-rp-transmitter-half-swing: Transmitter Half Swing
+- fsps,pcie-rp-acs: ACS
+- fsps,pcie-rp-clk-req-supported: Clock Request Support
+- fsps,pcie-rp-clk-req-number: Configure CLKREQ Number
+- fsps,pcie-rp-clk-req-detect: CLKREQ# Detection
+- fsps,advanced-error-reportingt: Advanced Error Reporting
+- fsps,pme-interrupt: PME Interrupt
+- fsps,unsupported-request-report: URR
+- fsps,fatal-error-report: FER
+- fsps,no-fatal-error-report: NFER
+- fsps,correctable-error-report: CER
+- fsps,system-error-on-fatal-error: SEFE
+- fsps,system-error-on-non-fatal-error: SENFE
+- fsps,system-error-on-correctable-error: SECE
+- fsps,pcie-rp-speed: PCIe Speed
+- fsps,physical-slot-number: Physical Slot Number
+ 0: Auto (default)
+ 1: Gen1
+ 2: Gen2
+ 3: Gen3
+- fsps,pcie-rp-completion-timeout: CTO
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05 (default)
+- fsps,enable-ptm: PTM Support
+- fsps,pcie-rp-aspm: ASPM
+- fsps,pcie-rp-l1-substates: L1 Substates
+- fsps,pcie-rp-ltr-enable: PCH PCIe LTR
+- fsps,pcie-rp-ltr-config-lock: PCIE LTR Lock
+- fsps,pme-b0-s5-di: PME_B0_S5 Disable bit
+- fsps,pci-clock-run: PCI Clock Run
+- fsps,timer8254-clk-setting: Enable/Disable Timer 8254 Clock Setting
+- fsps,enable-sata: Chipset SATA
+- fsps,sata-mode: SATA Mode Selection
+ 0: AHCI (default)
+ 1: RAID
+- fsps,sata-salp-support: Aggressive LPM Support
+- fsps,sata-pwr-opt-enable: SATA Power Optimization
+- fsps,e-sata-speed-limit: eSATA Speed Limit
+- fsps,speed-limit: SATA Speed Limit
+ 0x1: 1.5Gb/s(Gen 1)
+ 0x2: 3Gb/s(Gen 2)
+ 0x3: 6Gb/s(Gen 3)
+- fsps,sata-ports-enable: SATA Port
+- fsps,sata-ports-dev-slp: SATA Port DevSlp
+- fsps,sata-ports-hot-plug: SATA Port HotPlug
+- fsps,sata-ports-interlock-sw: Mechanical Presence Switch
+- fsps,sata-ports-external: External SATA Ports
+- fsps,sata-ports-spin-up: Spin Up Device
+- fsps,sata-ports-solid-state-drive: SATA Solid State
+ 0: Hard Disk Drive (default)
+ 1: Solid State Drive
+- fsps,sata-ports-enable-dito-config: DITO Configuration
+- fsps,sata-ports-dm-val: DM Value
+ 0x0F: Maximum (default)
+- fsps,sata-ports-dito-val: DITO Value
+ 0x0271 (default)
+- fsps,sub-system-vendor-id: Subsystem Vendor ID
+ 0x8086: (default)
+- fsps,sub-system-id: Subsystem ID
+ 0x7270: (default)
+- fsps,crid-setting: CRIDSettings
+ 0: Disable (default)
+ 1: CRID_1
+ 2: CRID_2
+ 3: CRID_3
+- fsps,reset-select: ResetSelect
+ 0x6: warm reset (default)
+ 0xE: cold reset
+- fsps,sdcard-enabled: SD Card Support (D27:F0)
+- fsps,emmc-enabled: SeMMC Support (D28:F0)
+- fsps,emmc-host-max-speed: eMMC Max Speed
+ 0: HS400(default)
+ 1: HS200
+ 2: DDR50
+- fsps,ufs-enabled: UFS Support (D29:F0)
+- fsps,sdio-enabled: SDIO Support (D30:F0)
+- fsps,gpp-lock: GPP Lock Feature
+- fsps,sirq-enable: Serial IRQ
+- fsps,sirq-mode: Serial IRQ Mode
+ 0: Quiet mode (default)
+ 1: Continuous mode
+- fsps,start-frame-pulse: Start Frame Pulse Width
+ 0: ScSfpw4Clk (default)
+ 1: ScSfpw6Clk
+ 2: ScSfpw8Clk
+- fsps,smbus-enable: SMBus
+- fsps,arp-enable: SMBus ARP Support
+- fsps,num-rsvd-smbus-addresses: SMBus Table Elements
+ 0x0080: (default)
+- fsps,rsvd-smbus-address-table: Reserved SMBus Address Table
+ 0x00: (default)
+- fsps,disable-compliance-mode: XHCI Disable Compliance Mode
+- fsps,usb-per-port-ctl: USB Per-Port Control
+- fsps,usb30-mode: xHCI Mode
+ 0: Disable
+ 1: Enable
+ 2: Auto (default)
+- fsps,port-usb20-enable: Enable USB2 ports
+- fsps,port-usb20-over-current-pin: USB20 Over Current Pin
+- fsps,usb-otg: XDCI Support
+ 0: Disable
+ 1: PCI_Mode (default)
+ 2: ACPI_mode
+- fsps,hsic-support-enable: Enable XHCI HSIC Support
+- fsps,port-usb30-enable: Enable USB3 ports
+- fsps,port-usb30-over-current-pin: USB30 Over Current Pin
+- fsps,ssic-port-enable: Enable XHCI SSIC Support
+- fsps,dlane-pwr-gating: SSIC Dlane PowerGating
+- fsps,vtd-enable: VT-d
+- fsps,lock-down-global-smi: SMI Lock bit
+- fsps,reset-wait-timer: HDAudio Delay Timer
+ 0x012C: (default)
+- fsps,rtc-lock: RTC Lock Bits
+- fsps,sata-test-mode: SATA Test Mode Selection
+- fsps,ssic-rate: XHCI SSIC RATE
+ 1: A Series (default)
+ 2: B Series
+- fsps,dynamic-power-gating: SMBus Dynamic Power Gating
+- fsps,pcie-rp-ltr-max-snoop-latency: Max Snoop Latency
+ 0x0000: (default)
+- fsps,pcie-rp-snoop-latency-override-mode: Snoop Latency Override
+ 0: Disable
+ 1: Enable
+ 2: Auto (default)
+- fsps,pcie-rp-snoop-latency-override-value: Snoop Latency Value
+ 0x003C (default)
+- fsps,pcie-rp-snoop-latency-override-multiplier: Snoop Latency Multiplier
+ 0: 1ns
+ 1: 32ns
+ 2: 1024ns (default)
+ 3: 32768ns
+ 4: 1048576ns
+ 5: 33554432ns
+- fsps,skip-mp-init: Skip Multi-Processor Initialization
+- fsps,dci-auto-detect: DCI Auto Detect
+- fsps,pcie-rp-ltr-max-non-snoop-latency: Max Non-Snoop Latency
+ 0x0000: (default)
+- fsps,pcie-rp-non-snoop-latency-override-mode: Non Snoop Latency Override
+- fsps,tco-timer-halt-lock: Halt and Lock TCO Timer
+- fsps,pwr-btn-override-period: Power Button Override Period
+ 000: 4s (default)
+ 001: 6s
+ 010: 8s
+ 011: 10s
+ 100: 12s
+ 101: 14s
+- fsps,pcie-rp-non-snoop-latency-override-value:
+ 0x003C: (default)
+- fsps,pcie-rp-non-snoop-latency-override-multiplier: Non Snoop Latency Value
+ 0: 1ns
+ 1: 32ns
+ 2: 1024ns (default)
+ 3: 32768ns
+ 4: 1048576ns
+ 5: 33554432ns
+- fsps,pcie-rp-slot-power-limit-scale: PCIE Root Port Slot Power Limit Scale
+ 0x00: (default)
+- fsps,pcie-rp-slot-power-limit-value:
+ 0x00: (default)
+- fsps,disable-native-power-button: Power Button Native Mode Disable
+- fsps,power-butter-debounce-mode: Power Button Debounce Mode
+- fsps,sdio-tx-cmd-cntl: SDIO_TX_CMD_DLL_CNTL
+ 0x505: (default)
+- fsps,sdio-tx-data-cntl1: SDIO_TX_DATA_DLL_CNTL1
+ 0xE: (default)
+- fsps,sdio-tx-data-cntl2: SDIO_TX_DATA_DLL_CNTL2
+ 0x22272828: (default)
+- fsps,sdio-rx-cmd-data-cntl1: SDIO_RX_CMD_DATA_DLL_CNTL1
+ 0x16161616: (default)
+- fsps,sdio-rx-cmd-data-cntl2: SDIO_RX_CMD_DATA_DLL_CNTL2
+ 0x10000: (default)
+- fsps,sdcard-tx-cmd-cntl: SDCARD_TX_CMD_DLL_CNTL
+ 0x505 (default)
+- fsps,sdcard-tx-data-cntl1: SDCARD_TX_DATA_DLL_CNTL1
+ 0xA13: (default)
+- fsps,sdcard-tx-data-cntl2: SDCARD_TX_DATA_DLL_CNTL2
+ 0x24242828: (default)
+- fsps,sdcard-rx-cmd-data-cntl1: SDCARD_RX_CMD_DATA_DLL_CNTL1
+ 0x73A3637 (default)
+- fsps,sdcard-rx-strobe-cntl: SDCARD_RX_STROBE_DLL_CNTL
+ 0x0: (default)
+- fsps,sdcard-rx-cmd-data-cntl2: SDCARD_RX_CMD_DATA_DLL_CNTL2
+ 0x10000: (default)
+- fsps,emmc-tx-cmd-cntl: EMMC_TX_CMD_DLL_CNTL
+ 0x505: (default)
+- fsps,emmc-tx-data-cntl1: EMMC_TX_DATA_DLL_CNTL1
+ 0xC11: (default)
+- fsps,emmc-tx-data-cntl2: EMMC_TX_DATA_DLL_CNTL2
+ 0x1C2A2927: (default)
+- fsps,emmc-rx-cmd-data-cntl1: EMMC_RX_CMD_DATA_DLL_CNTL1
+ 0x000D162F: (default)
+- fsps,emmc-rx-strobe-cntl: EMMC_RX_STROBE_DLL_CNTL
+ 0x0a0a: (default)
+- fsps,emmc-rx-cmd-data-cntl2: EMMC_RX_CMD_DATA_DLL_CNTL2
+ 0x1003b: (default)
+- fsps,emmc-master-sw-cntl: EMMC_MASTER_DLL_CNTL
+ 0x001: (default)
+- fsps,pcie-rp-selectable-deemphasis: PCIe Selectable De-emphasis
+ 1: -3.5 dB (default)
+ 0: -6 dB
+- fsps,monitor-mwait-enable: Monitor Mwait Enable
+- fsps,hd-audio-dsp-uaa-compliance: Universal Audio Architecture
+ compliance for DSP enabled system
+- fsps,ipc: IRQ Interrupt Polarity Control
+- fsps,sata-ports-disable-dynamic-pg: Disable ModPHY dynamic power gate
+- fsps,init-s3-cpu: Init CPU during S3 resume
+- fsps,skip-punit-init: Skip P-unit Initialization
+- fsps,port-usb20-per-port-tx-pe-half: PerPort Half Bit Pre-emphasis
+- fsps,port-usb20-per-port-pe-txi-set: PerPort HS Pre-emphasis Bias
+- fsps,port-usb20-per-port-txi-set: PerPort HS Transmitter Bias
+- fsps,port-usb20-hs-skew-sel: Select the skew direction for HS transition
+- fsps,port-usb20-i-usb-tx-emphasis-en: PerPort HS Transmitter Emphasis
+- fsps,port-usb20-per-port-rxi-set: PerPort HS Receiver Bias
+- fsps,port-usb20-hs-npre-drv-sel: Delay/skew's strength control for HS driver
+- fsps,os-selection: OS Selection
+ 0: Windows
+ 1: Android
+ 3: Linux
+- fsps,dptf-enabled: DPTF
+- fsps,pwm-enabled: PWM Enabled
+
+Example:
+
+&fsp_s {
+ u-boot,dm-pre-proper;
+
+ fsps,ish-enable = <0>;
+ fsps,enable-sata = <0>;
+ fsps,pcie-root-port-en = [00 00 00 00 00 01];
+ fsps,pcie-rp-hot-plug = [00 00 00 00 00 01];
+ fsps,i2c6-enable = <I2CX_ENABLE_DISABLED>;
+ fsps,i2c7-enable = <I2CX_ENABLE_DISABLED>;
+ fsps,hsuart3-enable = <HSUARTX_ENABLE_DISABLED>;
+ fsps,spi1-enable = <SPIX_ENABLE_DISABLED>;
+ fsps,spi2-enable = <SPIX_ENABLE_DISABLED>;
+ fsps,sdio-enabled = <0>;
+ ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt
new file mode 100644
index 000000000..cf71eb282
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt
@@ -0,0 +1,28 @@
+Altera GPIO controller bindings
+
+Required properties:
+- compatible:
+ - "altr,pio-1.0"
+- reg: Physical base address and length of the controller's registers.
+
+Optional properties:
+- altr,gpio-bank-width: Width of the GPIO bank. This defines how many pins the
+ GPIO device has. Ranges between 1-32. Optional and defaults to 32 if not
+ specified.
+- gpio-bank-name: bank name attached to this device.
+
+Example:
+
+user_led_pio_8out: gpio@0x4cc0 {
+ compatible = "altr,pio-1.0";
+ reg = <0x00004cc0 0x00000010>;
+ resetvalue = <255>;
+ altr,gpio-bank-width = <8>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-bank-name = "led";
+};
+
+In this example, the gpio can be accessed as led[0..7] using gpio command of
+u-boot.
+==> gpio clear led0
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt
new file mode 100644
index 000000000..21e0610b3
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt
@@ -0,0 +1,5 @@
+* Broadcom BCM283x GPIO controller
+
+Required properties:
+- compatible: must be "brcm,bcm2835-gpio"
+- reg: exactly one register range with length 0xb4
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt b/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
new file mode 100644
index 000000000..52d8bb0a5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
@@ -0,0 +1,22 @@
+MPC83xx SPISEL_BOOT gpio controller
+
+Provide access to MPC83xx SPISEL_BOOT signal as a gpio to allow it to be
+easily bound as a SPI controller chip select.
+
+The SPISEL_BOOT signal is always an output.
+
+Required properties:
+
+- compatible: must be "fsl,mpc83xx-spisel-boot" or "fsl,mpc8309-spisel-boot".
+- reg: must point to the SPI_CS register in the SoC register map.
+- ngpios: number of gpios provided by driver, normally 1.
+
+Example:
+
+ spisel_boot: spisel_boot@14c {
+ compatible = "fsl,mpc8309-spisel-boot";
+ reg = <0x14c 0x04>;
+ #gpio-cells = <2>;
+ device_type = "gpio";
+ ngpios = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt
new file mode 100644
index 000000000..70a2c7f0d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt
@@ -0,0 +1,23 @@
+Qualcomm Snapdragon GPIO controller
+
+Required properties:
+- compatible : "qcom,msm8916-pinctrl", "qcom,apq8016-pinctrl" or
+ "qcom,ipq4019-pinctrl"
+- reg : Physical base address and length of the controller's registers.
+ This controller is called "Top Level Mode Multiplexing" in
+ Qualcomm documentation.
+- #gpio-cells : Should be one (pin number).
+- gpio-controller : Marks the device node as a GPIO controller.
+- gpio-count: Number of GPIO pins.
+- gpio-bank-name: (optional) name of gpio bank. As default "soc" is used.
+
+Example:
+
+soc_gpios: pinctrl@1000000 {
+ compatible = "qcom,msm8916-pinctrl";
+ reg = <0x1000000 0x300000>;
+ gpio-controller;
+ gpio-count = <122>;
+ gpio-bank-name="soc";
+ #gpio-cells = <1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000000000..ada4e2973
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per line, which can't be read
+back. We can't actually know at initialization time whether a line is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up line direction is
+thus to do it explicitly.
+
+Required Properties:
+
+ - compatible: should be one of the following.
+ - "maxim,max7328": For the Maxim MAX7378
+ - "maxim,max7329": For the Maxim MAX7329
+ - "nxp,pca8574": For the NXP PCA8574
+ - "nxp,pca8575": For the NXP PCA8575
+ - "nxp,pca9670": For the NXP PCA9670
+ - "nxp,pca9671": For the NXP PCA9671
+ - "nxp,pca9672": For the NXP PCA9672
+ - "nxp,pca9673": For the NXP PCA9673
+ - "nxp,pca9674": For the NXP PCA9674
+ - "nxp,pca9675": For the NXP PCA9675
+ - "nxp,pcf8574": For the NXP PCF8574
+ - "nxp,pcf8574a": For the NXP PCF8574A
+ - "nxp,pcf8575": For the NXP PCF8575
+ - "ti,tca9554": For the TI TCA9554
+
+ - reg: I2C slave address.
+
+ - gpio-controller: Marks the device node as a gpio controller.
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+ cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
+ GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+ - lines-initial-states: Bitmask that specifies the initial state of each
+ line. When a bit is set to zero, the corresponding line will be initialized to
+ the input (pulled-up) state. When the bit is set to one, the line will be
+ initialized the low-level output state. If the property is not specified
+ all lines will be initialized to the input state.
+
+ The I/O expander can detect input state changes, and thus optionally act as
+ an interrupt controller. When the expander interrupt line is connected all the
+ following properties must be set. For more information please see the
+ interrupt controller device tree bindings documentation available at
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+ - interrupt-controller: Identifies the node as an interrupt controller.
+ - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
+ - interrupt-parent: phandle of the parent interrupt controller.
+ - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+ pcf8575: gpio@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ interrupt-parent = <&irqpin2>;
+ interrupts = <3 0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt
new file mode 100644
index 000000000..5375625e8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt
@@ -0,0 +1,41 @@
+Samsung Exynos4 GPIO Controller
+
+Required properties:
+- compatible: Compatible property value should be "samsung,exynos4-gpio>".
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
+ should be the following with values derived from the SoC user manual.
+ <[phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [mux function]
+ [flags and pull up/down]
+ [drive strength]>
+
+ Values for gpio specifier:
+ - Pin number: is a value between 0 to 7.
+ - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
+ 1 - Pull Down Enabled.
+ 3 - Pull Up Enabled.
+ Bit 16 (0x00010000) - Input is active low.
+ - Drive Strength: 0 - 1x,
+ 1 - 3x,
+ 2 - 2x,
+ 3 - 4x
+
+- gpio-controller: Specifies that the node is a gpio controller.
+- #address-cells: should be 1.
+- #size-cells: should be 1.
+
+Example:
+
+ gpa0: gpio-controller@11400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400000 0x20>;
+ #gpio-cells = <4>;
+ gpio-controller;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt
new file mode 100644
index 000000000..1481ed607
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt
@@ -0,0 +1,324 @@
+Specifying GPIO information for devices
+============================================
+
+1) gpios property
+-----------------
+
+GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
+of this GPIO for the device. While a non-existent <name> is considered valid
+for compatibility reasons (resolving to the "gpios" property), it is not allowed
+for new bindings. Also, GPIO properties named "[<name>-]gpio" are valid and old
+bindings use it, but are only supported for compatibility reasons and should not
+be used for newer bindings since it has been deprecated.
+
+GPIO properties can contain one or more GPIO phandles, but only in exceptional
+cases should they contain more than one. If your device uses several GPIOs with
+distinct functions, reference each of them under its own property, giving it a
+meaningful name. The only case where an array of GPIOs is accepted is when
+several GPIOs serve the same function (e.g. a parallel data line).
+
+The exact purpose of each gpios property must be documented in the device tree
+binding of the device.
+
+The following example could be used to describe GPIO pins used as device enable
+and bit-banged data signals:
+
+ gpio1: gpio1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ [...]
+
+ data-gpios = <&gpio1 12 0>,
+ <&gpio1 13 0>,
+ <&gpio1 14 0>,
+ <&gpio1 15 0>;
+
+In the above example, &gpio1 uses 2 cells to specify a gpio. The first cell is
+a local offset to the GPIO line and the second cell represent consumer flags,
+such as if the consumer desire the line to be active low (inverted) or open
+drain. This is the recommended practice.
+
+The exact meaning of each specifier cell is controller specific, and must be
+documented in the device tree binding for the device, but it is strongly
+recommended to use the two-cell approach.
+
+Most controllers are specifying a generic flag bitfield in the last cell, so
+for these, use the macros defined in
+include/dt-bindings/gpio/gpio.h whenever possible:
+
+Example of a node using GPIOs:
+
+ node {
+ enable-gpios = <&qe_pio_e 18 GPIO_ACTIVE_HIGH>;
+ };
+
+GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes
+GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+
+Optional standard bitfield specifiers for the last cell:
+
+- Bit 0: 0 means active high, 1 means active low
+- Bit 1: 0 mean push-pull wiring, see:
+ https://en.wikipedia.org/wiki/Push-pull_output
+ 1 means single-ended wiring, see:
+ https://en.wikipedia.org/wiki/Single-ended_triode
+- Bit 2: 0 means open-source, 1 means open drain, see:
+ https://en.wikipedia.org/wiki/Open_collector
+- Bit 3: 0 means the output should be maintained during sleep/low-power mode
+ 1 means the output state can be lost during sleep/low-power mode
+- Bit 4: 0 means no pull-up resistor should be enabled
+ 1 means a pull-up resistor should be enabled
+ This setting only applies to hardware with a simple on/off
+ control for pull-up configuration. If the hardware has more
+ elaborate pull-up configuration, it should be represented
+ using a pin control binding.
+- Bit 5: 0 means no pull-down resistor should be enabled
+ 1 means a pull-down resistor should be enabled
+ This setting only applies to hardware with a simple on/off
+ control for pull-down configuration. If the hardware has more
+ elaborate pull-down configuration, it should be represented
+ using a pin control binding.
+
+1.1) GPIO specifier best practices
+----------------------------------
+
+A gpio-specifier should contain a flag indicating the GPIO polarity; active-
+high or active-low. If it does, the following best practices should be
+followed:
+
+The gpio-specifier's polarity flag should represent the physical level at the
+GPIO controller that achieves (or represents, for inputs) a logically asserted
+value at the device. The exact definition of logically asserted should be
+defined by the binding for the device. If the board inverts the signal between
+the GPIO controller and the device, then the gpio-specifier will represent the
+opposite physical level than the signal at the device's pin.
+
+When the device's signal polarity is configurable, the binding for the
+device must either:
+
+a) Define a single static polarity for the signal, with the expectation that
+any software using that binding would statically program the device to use
+that signal polarity.
+
+The static choice of polarity may be either:
+
+a1) (Preferred) Dictated by a binding-specific DT property.
+
+or:
+
+a2) Defined statically by the DT binding itself.
+
+In particular, the polarity cannot be derived from the gpio-specifier, since
+that would prevent the DT from separately representing the two orthogonal
+concepts of configurable signal polarity in the device, and possible board-
+level signal inversion.
+
+or:
+
+b) Pick a single option for device signal polarity, and document this choice
+in the binding. The gpio-specifier should represent the polarity of the signal
+(at the GPIO controller) assuming that the device is configured for this
+particular signal polarity choice. If software chooses to program the device
+to generate or receive a signal of the opposite polarity, software will be
+responsible for correctly interpreting (inverting) the GPIO signal at the GPIO
+controller.
+
+2) gpio-controller nodes
+------------------------
+
+Every GPIO controller node must contain both an empty "gpio-controller"
+property, and a #gpio-cells integer property, which indicates the number of
+cells in a gpio-specifier.
+
+Some system-on-chips (SoCs) use the concept of GPIO banks. A GPIO bank is an
+instance of a hardware IP core on a silicon die, usually exposed to the
+programmer as a coherent range of I/O addresses. Usually each such bank is
+exposed in the device tree as an individual gpio-controller node, reflecting
+the fact that the hardware was synthesized by reusing the same IP block a
+few times over.
+
+Optionally, a GPIO controller may have a "ngpios" property. This property
+indicates the number of in-use slots of available slots for GPIOs. The
+typical example is something like this: the hardware register is 32 bits
+wide, but only 18 of the bits have a physical counterpart. The driver is
+generally written so that all 32 bits can be used, but the IP block is reused
+in a lot of designs, some using all 32 bits, some using 18 and some using
+12. In this case, setting "ngpios = <18>;" informs the driver that only the
+first 18 GPIOs, at local offset 0 .. 17, are in use.
+
+If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1, an
+additional set of tuples is needed to specify which GPIOs are unusable, with
+the gpio-reserved-ranges binding. This property indicates the start and size
+of the GPIOs that can't be used.
+
+Optionally, a GPIO controller may have a "gpio-line-names" property. This is
+an array of strings defining the names of the GPIO lines going out of the
+GPIO controller. This name should be the most meaningful producer name
+for the system, such as a rail name indicating the usage. Package names
+such as pin name are discouraged: such lines have opaque names (since they
+are by definition generic purpose) and such names are usually not very
+helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are
+reasonable line names as they describe what the line is used for. "GPIO0"
+is not a good name to give to a GPIO line. Placeholders are discouraged:
+rather use the "" (blank string) if the use of the GPIO line is undefined
+in your design. The names are assigned starting from line offset 0 from
+left to right from the passed array. An incomplete array (where the number
+of passed named are less than ngpios) will still be used up until the last
+provided valid line index.
+
+Example:
+
+gpio-controller@00000000 {
+ compatible = "foo";
+ reg = <0x00000000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <18>;
+ gpio-reserved-ranges = <0 4>, <12 2>;
+ gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R",
+ "LED G", "LED B", "Col A", "Col B", "Col C", "Col D",
+ "Row A", "Row B", "Row C", "Row D", "NMI button",
+ "poweroff", "reset";
+}
+
+The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
+providing automatic GPIO request and configuration as part of the
+gpio-controller's driver probe function.
+
+Each GPIO hog definition is represented as a child node of the GPIO controller.
+Required properties:
+- gpio-hog: A property specifying that this child node represents a GPIO hog.
+- gpios: Store the GPIO information (id, flags, ...) for each GPIO to
+ affect. Shall contain an integer multiple of the number of cells
+ specified in its parent node (GPIO controller node).
+Only one of the following properties scanned in the order shown below.
+This means that when multiple properties are present they will be searched
+in the order presented below and the first match is taken as the intended
+configuration.
+- input: A property specifying to set the GPIO direction as input.
+- output-low A property specifying to set the GPIO direction as output with
+ the value low.
+- output-high A property specifying to set the GPIO direction as output with
+ the value high.
+
+Optional properties:
+- line-name: The GPIO label name. If not present the node name is used.
+
+Example of two SOC GPIO banks defined as gpio-controller nodes:
+
+ qe_pio_a: gpio-controller@1400 {
+ compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
+ reg = <0x1400 0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ qe_pio_e: gpio-controller@1460 {
+ compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+2.1) gpio- and pin-controller interaction
+-----------------------------------------
+
+Some or all of the GPIOs provided by a GPIO controller may be routed to pins
+on the package via a pin controller. This allows muxing those pins between
+GPIO and other functions. It is a fairly common practice among silicon
+engineers.
+
+2.2) Ordinary (numerical) GPIO ranges
+-------------------------------------
+
+It is useful to represent which GPIOs correspond to which pins on which pin
+controllers. The gpio-ranges property described below represents this with
+a discrete set of ranges mapping pins from the pin controller local number space
+to pins in the GPIO controller local number space.
+
+The format is: <[pin controller phandle], [GPIO controller offset],
+ [pin controller offset], [number of pins]>;
+
+The GPIO controller offset pertains to the GPIO controller node containing the
+range definition.
+
+The pin controller node referenced by the phandle must conform to the bindings
+described in pinctrl/pinctrl-bindings.txt.
+
+Each offset runs from 0 to N. It is perfectly fine to pile any number of
+ranges with just one pin-to-GPIO line mapping if the ranges are concocted, but
+in practice these ranges are often lumped in discrete sets.
+
+Example:
+
+ gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>;
+
+This means:
+- pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and
+- pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29
+
+
+Verbose example:
+
+ qe_pio_e: gpio-controller@1460 {
+ #gpio-cells = <2>;
+ compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
+ };
+
+Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
+pinctrl1's pins 20..29, and GPIOs 10..29 routed to pin controller pinctrl2's
+pins 50..69.
+
+
+2.3) GPIO ranges from named pin groups
+--------------------------------------
+
+It is also possible to use pin groups for gpio ranges when pin groups are the
+easiest and most convenient mapping.
+
+Both both <pinctrl-base> and <count> must set to 0 when using named pin groups
+names.
+
+The property gpio-ranges-group-names must contain exactly one string for each
+range.
+
+Elements of gpio-ranges-group-names must contain the name of a pin group
+defined in the respective pin controller. The number of pins/GPIO lines in the
+range is the number of pins in that pin group. The number of pins of that
+group is defined int the implementation and not in the device tree.
+
+If numerical and named pin groups are mixed, the string corresponding to a
+numerical pin range in gpio-ranges-group-names must be empty.
+
+Example:
+
+ gpio_pio_i: gpio-controller@14b0 {
+ #gpio-cells = <2>;
+ compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+ reg = <0x1480 0x18>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl1 0 20 10>,
+ <&pinctrl2 10 0 0>,
+ <&pinctrl1 15 0 10>,
+ <&pinctrl2 25 0 0>;
+ gpio-ranges-group-names = "",
+ "foo",
+ "",
+ "bar";
+ };
+
+Here, three GPIO ranges are defined referring to two pin controllers.
+
+pinctrl1 GPIO ranges are defined using pin numbers whereas the GPIO ranges
+in pinctrl2 are defined using the pin groups named "foo" and "bar".
+
+Previous versions of this binding required all pin controller nodes that
+were referenced by any gpio-ranges property to contain a property named
+#gpio-range-cells with value <3>. This requirement is now deprecated.
+However, that property may still exist in older device trees for
+compatibility reasons, and would still be required even in new device
+trees that need to be compatible with older software.
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
new file mode 100644
index 000000000..8422ff63a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
@@ -0,0 +1,55 @@
+Intel Apollo Lake GPIO controller
+
+The Apollo Lake (APL) GPIO controller is used to control GPIO functions of
+the pins.
+
+Required properties:
+- compatible: "intel,apl-gpio"
+- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
+ nodes should be the following with values derived from the SoC user manual.
+ <[phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [flags]>
+
+ Values for gpio specifier:
+ - Pin number: is a GPIO pin number between 0 and 244
+ - Flags: GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW
+
+- gpio-controller: Specifies that the node is a gpio controller.
+
+Example:
+
+...
+{
+ p2sb: p2sb@d,0 {
+ reg = <0x02006810 0 0 0 0>;
+ compatible = "intel,p2sb";
+ early-regs = <IOMAP_P2SB_BAR 0x100000>;
+
+ north {
+ compatible = "intel,apl-pinctrl";
+ intel,p2sb-port-id = <PID_GPIO_N>;
+ gpio_n: gpio-n {
+ compatible = "intel,gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+
+ i2c_2: i2c2@16,2 {
+ compatible = "intel,apl-i2c", "snps,designware-i2c-pci";
+ reg = <0x0200b210 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ tpm@50 {
+ reg = <0x50>;
+ compatible = "google,cr50";
+ u-boot,i2c-offset-len = <0>;
+ ready-gpios = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+};
+...
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt
new file mode 100644
index 000000000..a644381e0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt
@@ -0,0 +1,208 @@
+Intel x86 PINCTRL/GPIO controller
+
+Pin-muxing on broadwell devices can be described with a node for the PINCTRL
+master node and a set of child nodes for each required pin state on the SoC.
+These pin states use phandles and are referred to but a configuration section
+which lists all pins in the device.
+
+The PINCTRL master node requires the following properties:
+- compatible : "intel,x86-broadwell-pinctrl"
+
+Pin state nodes must be sub-nodes of the pinctrl master node. The must have
+a phandle. They can contain the following optional properties:
+- mode-gpio - forces the pin into GPIO mode
+- output-value - sets the default output value of the GPIO, 0 (low, default)
+ or 1 (high)
+- direction - sets the direction of the gpio, either PIN_INPUT (default)
+ or PIN_OUTPUT
+- invert - the input pin is inverted
+- trigger - sets the trigger type, either TRIGGER_EDGE (default) or
+ TRIGGER_LEVEL
+- sense-disable - the input state sense is disabled
+- owner 0 sets the owner of the pin, either OWNER_ACPI (default) or
+ ONWER_GPIO
+- route - sets whether the pin is routed, either PIRQ_APIC_MASK or
+ PIRQ_APIC_ROUTE
+- irq-enable - the interrupt is enabled
+- reset-rsmrst - the pin will only be reset by RSMRST
+- pirq-apic - the pin will be routed to the IOxAPIC
+
+The first pin state will be the default, so pins without a configuration will
+use that.
+
+The pin configuration node is also a sub-node of the pinctrl master node, but
+does not have a phandle. It has a single property:
+
+- config - configuration to use for each pin. Each entry has of 3 cells:
+ - GPIO number (0..94)
+ - phandle of configuration (above)
+ - interrupt number (0..15)
+
+ There should be one entry for each pin (i.e. 95 entries).
+ But missing pins will receive the default configuration.
+
+Example:
+
+pch_pinctrl {
+ compatible = "intel,x86-broadwell-pinctrl";
+
+ /* Put this first: it is the default */
+ gpio_unused: gpio-unused {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ owner = <OWNER_GPIO>;
+ sense-disable;
+ };
+
+ gpio_acpi_sci: acpi-sci {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ invert;
+ route = <ROUTE_SCI>;
+ };
+
+ gpio_acpi_smi: acpi-smi {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ invert;
+ route = <ROUTE_SMI>;
+ };
+
+ gpio_input: gpio-input {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ owner = <OWNER_GPIO>;
+ };
+
+ gpio_input_invert: gpio-input-invert {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ owner = <OWNER_GPIO>;
+ invert;
+ };
+
+ gpio_native: gpio-native {
+ };
+
+ gpio_out_high: gpio-out-high {
+ mode-gpio;
+ direction = <PIN_OUTPUT>;
+ output-value = <1>;
+ owner = <OWNER_GPIO>;
+ sense-disable;
+ };
+
+ gpio_out_low: gpio-out-low {
+ mode-gpio;
+ direction = <PIN_OUTPUT>;
+ output-value = <0>;
+ owner = <OWNER_GPIO>;
+ sense-disable;
+ };
+
+ gpio_pirq: gpio-pirq {
+ mode-gpio;
+ direction = <PIN_INPUT>;
+ owner = <OWNER_GPIO>;
+ pirq-apic = <PIRQ_APIC_ROUTE>;
+ };
+
+ soc_gpio@0 {
+ config =
+ <0 &gpio_unused 0>, /* unused */
+ <1 &gpio_unused 0>, /* unused */
+ <2 &gpio_unused 0>, /* unused */
+ <3 &gpio_unused 0>, /* unused */
+ <4 &gpio_native 0>, /* native: i2c0_sda_gpio4 */
+ <5 &gpio_native 0>, /* native: i2c0_scl_gpio5 */
+ <6 &gpio_native 0>, /* native: i2c1_sda_gpio6 */
+ <7 &gpio_native 0>, /* native: i2c1_scl_gpio7 */
+ <8 &gpio_acpi_sci 0>, /* pch_lte_wake_l */
+ <9 &gpio_input_invert 0>,/* trackpad_int_l (wake) */
+ <10 &gpio_acpi_sci 0>, /* pch_wlan_wake_l */
+ <11 &gpio_unused 0>, /* unused */
+ <12 &gpio_unused 0>, /* unused */
+ <13 &gpio_pirq 3>, /* trackpad_int_l (pirql) */
+ <14 &gpio_pirq 4>, /* touch_int_l (pirqm) */
+ <15 &gpio_unused 0>, /* unused (strap) */
+ <16 &gpio_input 0>, /* pch_wp */
+ <17 &gpio_unused 0>, /* unused */
+ <18 &gpio_unused 0>, /* unused */
+ <19 &gpio_unused 0>, /* unused */
+ <20 &gpio_native 0>, /* pcie_wlan_clkreq_l */
+ <21 &gpio_out_high 0>, /* pp3300_ssd_en */
+ <22 &gpio_unused 0>, /* unused */
+ <23 &gpio_out_low 0>, /* pp3300_autobahn_en */
+ <24 &gpio_unused 0>, /* unused */
+ <25 &gpio_input 0>, /* ec_in_rw */
+ <26 &gpio_unused 0>, /* unused */
+ <27 &gpio_acpi_sci 0>, /* pch_wake_l */
+ <28 &gpio_unused 0>, /* unused */
+ <29 &gpio_unused 0>, /* unused */
+ <30 &gpio_native 0>, /* native: pch_suswarn_l */
+ <31 &gpio_native 0>, /* native: acok_buf */
+ <32 &gpio_native 0>, /* native: lpc_clkrun_l */
+ <33 &gpio_native 0>, /* native: ssd_devslp */
+ <34 &gpio_acpi_smi 0>, /* ec_smi_l */
+ <35 &gpio_acpi_smi 0>, /* pch_nmi_dbg_l (route in nmi_en) */
+ <36 &gpio_acpi_sci 0>, /* ec_sci_l */
+ <37 &gpio_unused 0>, /* unused */
+ <38 &gpio_unused 0>, /* unused */
+ <39 &gpio_unused 0>, /* unused */
+ <40 &gpio_native 0>, /* native: pch_usb1_oc_l */
+ <41 &gpio_native 0>, /* native: pch_usb2_oc_l */
+ <42 &gpio_unused 0>, /* wlan_disable_l */
+ <43 &gpio_out_high 0>, /* pp1800_codec_en */
+ <44 &gpio_unused 0>, /* unused */
+ <45 &gpio_acpi_sci 0>, /* dsp_int - codec wake */
+ <46 &gpio_pirq 6>, /* hotword_det_l_3v3 (pirqo) - codec irq */
+ <47 &gpio_out_low 0>, /* ssd_reset_l */
+ <48 &gpio_unused 0>, /* unused */
+ <49 &gpio_unused 0>, /* unused */
+ <50 &gpio_unused 0>, /* unused */
+ <51 &gpio_unused 0>, /* unused */
+ <52 &gpio_input 0>, /* sim_det */
+ <53 &gpio_unused 0>, /* unused */
+ <54 &gpio_unused 0>, /* unused */
+ <55 &gpio_unused 0>, /* unused */
+ <56 &gpio_unused 0>, /* unused */
+ <57 &gpio_out_high 0>, /* codec_reset_l */
+ <58 &gpio_unused 0>, /* unused */
+ <59 &gpio_out_high 0>, /* lte_disable_l */
+ <60 &gpio_unused 0>, /* unused */
+ <61 &gpio_native 0>, /* native: pch_sus_stat */
+ <62 &gpio_native 0>, /* native: pch_susclk */
+ <63 &gpio_native 0>, /* native: pch_slp_s5_l */
+ <64 &gpio_unused 0>, /* unused */
+ <65 &gpio_input 0>, /* ram_id3 */
+ <66 &gpio_input 0>, /* ram_id3_old (strap) */
+ <67 &gpio_input 0>, /* ram_id0 */
+ <68 &gpio_input 0>, /* ram_id1 */
+ <69 &gpio_input 0>, /* ram_id2 */
+ <70 &gpio_unused 0>, /* unused */
+ <71 &gpio_native 0>, /* native: modphy_en */
+ <72 &gpio_unused 0>, /* unused */
+ <73 &gpio_unused 0>, /* unused */
+ <74 &gpio_unused 0>, /* unused */
+ <75 &gpio_unused 0>, /* unused */
+ <76 &gpio_unused 0>, /* unused */
+ <77 &gpio_unused 0>, /* unused */
+ <78 &gpio_unused 0>, /* unused */
+ <79 &gpio_unused 0>, /* unused */
+ <80 &gpio_unused 0>, /* unused */
+ <81 &gpio_unused 0>, /* unused */
+ <82 &gpio_native 0>, /* native: ec_rcin_l */
+ <83 &gpio_native 0>, /* gspi0_cs */
+ <84 &gpio_native 0>, /* gspi0_clk */
+ <85 &gpio_native 0>, /* gspi0_miso */
+ <86 &gpio_native 0>, /* gspi0_mosi (strap) */
+ <87 &gpio_unused 0>, /* unused */
+ <88 &gpio_unused 0>, /* unused */
+ <89 &gpio_out_high 0>, /* pp3300_sd_en */
+ <90 &gpio_unused 0>, /* unused */
+ <91 &gpio_unused 0>, /* unused */
+ <92 &gpio_unused 0>, /* unused */
+ <93 &gpio_unused 0>, /* unused */
+ <94 &gpio_unused 0 >; /* unused */
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
new file mode 100644
index 000000000..8c3a84caf
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
@@ -0,0 +1,33 @@
+Intel x86 PINCTRL/GPIO controller
+
+Pin-muxing on x86 can be described with a node for the PINCTRL master
+node and a set of child nodes for each pin on the SoC.
+
+The PINCTRL master node requires the following properties:
+- compatible : "intel,x86-pinctrl"
+
+Pin nodes must be children of the pinctrl master node and can
+contain the following properties:
+- pad-offset - (required) offset in the IOBASE for the pin to configure
+- gpio-offset - (required only when 'mode-gpio' is set) 2 cells
+ - offset in the GPIOBASE for the pin to configure
+ - the bit shift in this register (4 = bit 4)
+- mode-gpio - (optional) standalone property to force the pin into GPIO mode
+- mode-func - (optional) function number to assign to the pin. If
+ 'mode-gpio' is set, this property will be ignored.
+in case of 'mode-gpio' property set:
+- output-value - (optional) this set the default output value of the GPIO
+- direction - (optional) this set the direction of the gpio
+- pull-strength - (optional) this set the pull strength of the pin
+- pull-assign - (optional) this set the pull assignement (up/down) of the pin
+- invert - (optional) this input pin is inverted
+
+Example:
+
+pin_usb_host_en0@0 {
+ gpio-offset = <0x80 8>;
+ pad-offset = <0x260>;
+ mode-gpio;
+ output-value = <1>;
+ direction = <PIN_OUTPUT>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt
new file mode 100644
index 000000000..3d344d64a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt
@@ -0,0 +1,45 @@
+Microsemi Corporation (MSCC) Serial GPIO driver
+
+The MSCC serial GPIO extends the number or GPIO's on the system by
+means of 4 dedicated pins: one input, one output, one clock and one
+strobe pin. By attaching a number of (external) shift registers, the
+effective GPIO count can be extended by up to 128 GPIO's per
+controller.
+
+Required properties:
+- compatible : "mscc,luton-sgpio" or "mscc,ocelot-sgpio"
+- clock: Reference clock used to generate clock divider setting. See
+ mscc,sgpio-frequency property.
+- reg : Physical base address and length of the controller's registers.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
+- gpio-ranges: Standard gpio range(s): phandle, gpio base, pinctrl base
+ and count.
+
+Optional properties:
+- ngpios: See gpio.txt
+- mscc,sgpio-frequency: The frequency at which the serial bitstream is
+ generated and sampled. Default: 12500000 (Hz).
+- mscc,sgpio-ports: A bitmask (32 bits) of which ports are enabled in
+ the serialized gpio stream. One 'port' will transport from 1 to 4
+ gpio bits. Default: 0xFFFFFFFF.
+
+Typically the pinctrl-0 and pinctrl-names properties will also be
+present to enable the use of the SIO CLK, LD, DI and DO for some
+regular GPIO pins.
+
+Example:
+
+sgpio: gpio@10700f8 {
+ compatible = "mscc,ocelot-sgpio";
+ pinctrl-0 = <&sgpio_pins>;
+ pinctrl-names = "default";
+ reg = <0x10700f8 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&sgpio 0 0 64>;
+ mscc,sgpio-frequency = <12500>;
+ mscc,sgpio-ports = <0x000FFFFF>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt
new file mode 100644
index 000000000..c82a2e221
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt
@@ -0,0 +1,161 @@
+NVIDIA Tegra186 GPIO controllers
+
+Tegra186 contains two GPIO controllers; a main controller and an "AON"
+controller. This binding document applies to both controllers. The register
+layouts for the controllers share many similarities, but also some significant
+differences. Hence, this document describes closely related but different
+bindings and compatible values.
+
+The Tegra186 GPIO controller allows software to set the IO direction of, and
+read/write the value of, numerous GPIO signals. Routing of GPIO signals to
+package balls is under the control of a separate pin controller HW block. Two
+major sets of registers exist:
+
+a) Security registers, which allow configuration of allowed access to the GPIO
+register set. These registers exist in a single contiguous block of physical
+address space. The size of this block, and the security features available,
+varies between the different GPIO controllers.
+
+Access to this set of registers is not necessary in all circumstances. Code
+that wishes to configure access to the GPIO registers needs access to these
+registers to do so. Code which simply wishes to read or write GPIO data does not
+need access to these registers.
+
+b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
+controllers, these registers are exposed via multiple "physical aliases" in
+address space, each of which access the same underlying state. See the hardware
+documentation for rationale. Any particular GPIO client is expected to access
+just one of these physical aliases.
+
+Tegra HW documentation describes a unified naming convention for all GPIOs
+implemented by the SoC. Each GPIO is assigned to a port, and a port may control
+a number of GPIOs. Thus, each GPIO is named according to an alphabetical port
+name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6,
+or GPIO_PCC3.
+
+The number of ports implemented by each GPIO controller varies. The number of
+implemented GPIOs within each port varies. GPIO registers within a controller
+are grouped and laid out according to the port they affect.
+
+The mapping from port name to the GPIO controller that implements that port, and
+the mapping from port name to register offset within a controller, are both
+extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h>
+describes the port-level mapping. In that file, the naming convention for ports
+matches the HW documentation. The values chosen for the names are alphabetically
+sorted within a particular controller. Drivers need to map between the DT GPIO
+IDs and HW register offsets using a lookup table.
+
+Each GPIO controller can generate a number of interrupt signals. Each signal
+represents the aggregate status for all GPIOs within a set of ports. Thus, the
+number of interrupt signals generated by a controller varies as a rough function
+of the number of ports it implements. Note that the HW documentation refers to
+both the overall controller HW module and the sets-of-ports as "controllers".
+
+Each GPIO controller in fact generates multiple interrupts signals for each set
+of ports. Each GPIO may be configured to feed into a specific one of the
+interrupt signals generated by a set-of-ports. The intent is for each generated
+signal to be routed to a different CPU, thus allowing different CPUs to each
+handle subsets of the interrupts within a port. The status of each of these
+per-port-set signals is reported via a separate register. Thus, a driver needs
+to know which status register to observe. This binding currently defines no
+configuration mechanism for this. By default, drivers should use register
+GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
+define a property to configure this.
+
+Required properties:
+- compatible
+ Array of strings.
+ One of:
+ - "nvidia,tegra186-gpio".
+ - "nvidia,tegra186-gpio-aon".
+- reg-names
+ Array of strings.
+ Contains a list of names for the register spaces described by the reg
+ property. May contain the following entries, in any order:
+ - "gpio": Mandatory. GPIO control registers. This may cover either:
+ a) The single physical alias that this OS should use.
+ b) All physical aliases that exist in the controller. This is
+ appropriate when the OS is responsible for managing assignment of
+ the physical aliases.
+ - "security": Optional. Security configuration registers.
+ Users of this binding MUST look up entries in the reg property by name,
+ using this reg-names property to do so.
+- reg
+ Array of (physical base address, length) tuples.
+ Must contain one entry per entry in the reg-names property, in a matching
+ order.
+- interrupts
+ Array of interrupt specifiers.
+ The interrupt outputs from the HW block, one per set of ports, in the
+ order the HW manual describes them. The number of entries required varies
+ depending on compatible value:
+ - "nvidia,tegra186-gpio": 6 entries.
+ - "nvidia,tegra186-gpio-aon": 1 entry.
+- gpio-controller
+ Boolean.
+ Marks the device node as a GPIO controller/provider.
+- #gpio-cells
+ Single-cell integer.
+ Must be <2>.
+ Indicates how many cells are used in a consumer's GPIO specifier.
+ In the specifier:
+ - The first cell is the pin number.
+ See <dt-bindings/gpio/tegra186-gpio.h>.
+ - The second cell contains flags:
+ - Bit 0 specifies polarity
+ - 0: Active-high (normal).
+ - 1: Active-low (inverted).
+- interrupt-controller
+ Boolean.
+ Marks the device node as an interrupt controller/provider.
+- #interrupt-cells
+ Single-cell integer.
+ Must be <2>.
+ Indicates how many cells are used in a consumer's interrupt specifier.
+ In the specifier:
+ - The first cell is the GPIO number.
+ See <dt-bindings/gpio/tegra186-gpio.h>.
+ - The second cell is contains flags:
+ - Bits [3:0] indicate trigger type and level:
+ - 1: Low-to-high edge triggered.
+ - 2: High-to-low edge triggered.
+ - 4: Active high level-sensitive.
+ - 8: Active low level-sensitive.
+ Valid combinations are 1, 2, 3, 4, 8.
+
+Example:
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+gpio@2200000 {
+ compatible = "nvidia,tegra186-gpio";
+ reg-names = "security", "gpio";
+ reg =
+ <0x0 0x2200000 0x0 0x10000>,
+ <0x0 0x2210000 0x0 0x10000>;
+ interrupts =
+ <0 47 IRQ_TYPE_LEVEL_HIGH>,
+ <0 50 IRQ_TYPE_LEVEL_HIGH>,
+ <0 53 IRQ_TYPE_LEVEL_HIGH>,
+ <0 56 IRQ_TYPE_LEVEL_HIGH>,
+ <0 59 IRQ_TYPE_LEVEL_HIGH>,
+ <0 180 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
+
+gpio@c2f0000 {
+ compatible = "nvidia,tegra186-gpio-aon";
+ reg-names = "security", "gpio";
+ reg =
+ <0x0 0xc2f0000 0x0 0x1000>,
+ <0x0 0xc2f1000 0x0 0x1000>;
+ interrupts =
+ <0 60 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt
new file mode 100644
index 000000000..023c9526e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt
@@ -0,0 +1,40 @@
+NVIDIA Tegra GPIO controller
+
+Required properties:
+- compatible : "nvidia,tegra<chip>-gpio"
+- reg : Physical base address and length of the controller's registers.
+- interrupts : The interrupt outputs from the controller. For Tegra20,
+ there should be 7 interrupts specified, and for Tegra30, there should
+ be 8 interrupts specified.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 2.
+ The first cell is the GPIO number.
+ The second cell is used to specify flags:
+ bits[3:0] trigger type and level flags:
+ 1 = low-to-high edge triggered.
+ 2 = high-to-low edge triggered.
+ 4 = active high level-sensitive.
+ 8 = active low level-sensitive.
+ Valid combinations are 1, 2, 3, 4, 8.
+- interrupt-controller : Marks the device node as an interrupt controller.
+
+Example:
+
+gpio: gpio@6000d000 {
+ compatible = "nvidia,tegra20-gpio";
+ reg = < 0x6000d000 0x1000 >;
+ interrupts = < 0 32 0x04
+ 0 33 0x04
+ 0 34 0x04
+ 0 35 0x04
+ 0 55 0x04
+ 0 87 0x04
+ 0 89 0x04 >;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt
new file mode 100644
index 000000000..58185b833
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt
@@ -0,0 +1,48 @@
+Driver for part of pm8916 PMIC - gpio and power/reset keys
+
+This device should be child of SPMI pmic.
+
+1) GPIO driver
+
+Required properties:
+- compatible: "qcom,pm8916-gpio"
+- reg: peripheral ID, size of register block
+- gpio-controller
+- gpio-count: number of GPIOs
+- #gpio-cells: 2
+
+Optional properties:
+- gpio-bank-name: name of bank (as default "pm8916" is used)
+
+Example:
+
+pmic_gpios: gpios@c000 {
+ compatible = "qcom,pm8916-gpio";
+ reg = <0xc000 0x400>;
+ gpio-controller;
+ gpio-count = <4>;
+ #gpio-cells = <2>;
+ gpio-bank-name="pmic";
+};
+
+
+2) Power/Reset key driver
+
+Required properties:
+- compatible: "qcom,pm8916-pwrkey"
+- reg: peripheral ID, size of register block
+- gpio-controller
+- #gpio-cells: 2
+
+Optional properties:
+- gpio-bank-name: name of bank (as default "pm8916_key" is used)
+
+
+Example:
+
+pmic_pon: pon@800 {
+ compatible = "qcom,pm8916-pwrkey";
+ reg = <0x800 0x96>;
+ #gpio-cells = <2>;
+ gpio-controller;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt
new file mode 100644
index 000000000..46ceb65c5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt
@@ -0,0 +1,43 @@
+GPIO via CREG (control registers) driver
+
+31 9 7 5 0 < bit number
+| | | | |
+[ not used | gpio-1 | gpio-0 | <-shift-> ] < 32 bit register
+ ^ ^
+ | |
+ write 0x2 == set output to "1" (activate)
+ write 0x3 == set output to "0" (deactivate)
+
+Required properties:
+- compatible : "snps,creg-gpio"
+- reg : Exactly one register range with length 0x4.
+- #gpio-cells : Should be one - the pin number.
+- gpio-controller : Marks the device node as a GPIO controller.
+- gpio-count: Number of GPIO pins.
+- gpio-bit-per-line: Number of bits per gpio line (see picture).
+- gpio-first-shift: Shift (in bits) of the first GPIO field in register
+ (see picture).
+- gpio-activate-val: Value should be set in corresponding field to set
+ output to "1" (see picture). Applied to all GPIO ports.
+- gpio-deactivate-val: Value should be set in corresponding field to set
+ output to "0" (see picture). Applied to all GPIO ports.
+
+Optional properties:
+- gpio-bank-name: name of bank (as default driver name is used is used)
+- gpio-default-val: array of default output values (must me 0 or 1)
+
+Example (see picture):
+
+gpio: gpio@f00014b0 {
+ compatible = "snps,creg-gpio";
+ reg = <0xf00014b0 0x4>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-bank-name = "hsdk-spi-cs";
+ gpio-count = <2>;
+ gpio-first-shift = <5>;
+ gpio-bit-per-line = <2>;
+ gpio-activate-val = <2>;
+ gpio-deactivate-val = <3>;
+ gpio-default-val = <1 1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/gpu/nvidia,tegra20-host1x.txt b/roms/u-boot/doc/device-tree-bindings/gpu/nvidia,tegra20-host1x.txt
new file mode 100644
index 000000000..b48f4ef31
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/gpu/nvidia,tegra20-host1x.txt
@@ -0,0 +1,372 @@
+NVIDIA Tegra host1x
+
+Required properties:
+- compatible: "nvidia,tegra<chip>-host1x"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- #address-cells: The number of cells used to represent physical base addresses
+ in the host1x address space. Should be 1.
+- #size-cells: The number of cells used to represent the size of an address
+ range in the host1x address space. Should be 1.
+- ranges: The mapping of the host1x address space to the CPU address space.
+- clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - host1x
+
+The host1x top-level node defines a number of children, each representing one
+of the following host1x client modules:
+
+- mpe: video encoder
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-mpe"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - mpe
+
+- vi: video input
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-vi"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - vi
+
+- epp: encoder pre-processor
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-epp"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - epp
+
+- isp: image signal processor
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-isp"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - isp
+
+- gr2d: 2D graphics engine
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-gr2d"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - 2d
+
+- gr3d: 3D graphics engine
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-gr3d"
+ - reg: Physical base address and length of the controller's registers.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ (This property may be omitted if the only clock in the list is "3d")
+ - 3d
+ This MUST be the first entry.
+ - 3d2 (Only required on SoCs with two 3D clocks)
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - 3d
+ - 3d2 (Only required on SoCs with two 3D clocks)
+
+- dc: display controller
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-dc"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - dc
+ This MUST be the first entry.
+ - parent
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - dc
+ - nvidia,head: The number of the display controller head. This is used to
+ setup the various types of output to receive video data from the given
+ head.
+
+ Each display controller node has a child node, named "rgb", that represents
+ the RGB output associated with the controller. It can take the following
+ optional properties:
+ - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+ - nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
+
+- hdmi: High Definition Multimedia Interface
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-hdmi"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - hdmi-supply: supply for the +5V HDMI connector pin
+ - vdd-supply: regulator for supply voltage
+ - pll-supply: regulator for PLL
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - hdmi
+ This MUST be the first entry.
+ - parent
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - hdmi
+
+ Optional properties:
+ - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+ - nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
+
+- tvo: TV encoder output
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-tvo"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain one entry, for the module clock.
+ See ../clocks/clock-bindings.txt for details.
+
+- dsi: display serial interface
+
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-dsi"
+ - reg: Physical base address and length of the controller's registers.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - dsi
+ This MUST be the first entry.
+ - lp
+ - parent
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - dsi
+ - avdd-dsi-supply: phandle of a supply that powers the DSI controller
+ - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying
+ which pads are used by this DSI output and need to be calibrated. See also
+ ../mipi/nvidia,tegra114-mipi.txt.
+
+ Optional properties:
+ - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+ - nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
+
+- sor: serial output resource
+
+ Required properties:
+ - compatible: "nvidia,tegra124-sor"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - sor: clock input for the SOR hardware
+ - parent: input for the pixel clock
+ - dp: reference clock for the SOR clock
+ - safe: safe reference for the SOR clock during power up
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - sor
+
+ Optional properties:
+ - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+ - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+ - nvidia,edid: supplies a binary EDID blob
+ - nvidia,panel: phandle of a display panel
+
+ Optional properties when driving an eDP output:
+ - nvidia,dpaux: phandle to a DispayPort AUX interface
+
+- dpaux: DisplayPort AUX interface
+ - compatible: "nvidia,tegra124-dpaux"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - dpaux: clock input for the DPAUX hardware
+ - parent: reference clock
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - dpaux
+ - vdd-supply: phandle of a supply that powers the DisplayPort link
+
+Example:
+
+/ {
+ ...
+
+ host1x {
+ compatible = "nvidia,tegra20-host1x", "simple-bus";
+ reg = <0x50000000 0x00024000>;
+ interrupts = <0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04>; /* mpcore general */
+ clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
+ resets = <&tegra_car 28>;
+ reset-names = "host1x";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x54000000 0x54000000 0x04000000>;
+
+ mpe {
+ compatible = "nvidia,tegra20-mpe";
+ reg = <0x54040000 0x00040000>;
+ interrupts = <0 68 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_MPE>;
+ resets = <&tegra_car 60>;
+ reset-names = "mpe";
+ };
+
+ vi {
+ compatible = "nvidia,tegra20-vi";
+ reg = <0x54080000 0x00040000>;
+ interrupts = <0 69 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_VI>;
+ resets = <&tegra_car 100>;
+ reset-names = "vi";
+ };
+
+ epp {
+ compatible = "nvidia,tegra20-epp";
+ reg = <0x540c0000 0x00040000>;
+ interrupts = <0 70 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_EPP>;
+ resets = <&tegra_car 19>;
+ reset-names = "epp";
+ };
+
+ isp {
+ compatible = "nvidia,tegra20-isp";
+ reg = <0x54100000 0x00040000>;
+ interrupts = <0 71 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_ISP>;
+ resets = <&tegra_car 23>;
+ reset-names = "isp";
+ };
+
+ gr2d {
+ compatible = "nvidia,tegra20-gr2d";
+ reg = <0x54140000 0x00040000>;
+ interrupts = <0 72 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_GR2D>;
+ resets = <&tegra_car 21>;
+ reset-names = "2d";
+ };
+
+ gr3d {
+ compatible = "nvidia,tegra20-gr3d";
+ reg = <0x54180000 0x00040000>;
+ clocks = <&tegra_car TEGRA20_CLK_GR3D>;
+ resets = <&tegra_car 24>;
+ reset-names = "3d";
+ };
+
+ dc@54200000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54200000 0x00040000>;
+ interrupts = <0 73 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_DISP1>,
+ <&tegra_car TEGRA20_CLK_PLL_P>;
+ clock-names = "dc", "parent";
+ resets = <&tegra_car 27>;
+ reset-names = "dc";
+
+ rgb {
+ status = "disabled";
+ };
+ };
+
+ dc@54240000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54240000 0x00040000>;
+ interrupts = <0 74 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_DISP2>,
+ <&tegra_car TEGRA20_CLK_PLL_P>;
+ clock-names = "dc", "parent";
+ resets = <&tegra_car 26>;
+ reset-names = "dc";
+
+ rgb {
+ status = "disabled";
+ };
+ };
+
+ hdmi {
+ compatible = "nvidia,tegra20-hdmi";
+ reg = <0x54280000 0x00040000>;
+ interrupts = <0 75 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_HDMI>,
+ <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+ clock-names = "hdmi", "parent";
+ resets = <&tegra_car 51>;
+ reset-names = "hdmi";
+ status = "disabled";
+ };
+
+ tvo {
+ compatible = "nvidia,tegra20-tvo";
+ reg = <0x542c0000 0x00040000>;
+ interrupts = <0 76 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_TVO>;
+ status = "disabled";
+ };
+
+ dsi {
+ compatible = "nvidia,tegra20-dsi";
+ reg = <0x54300000 0x00040000>;
+ clocks = <&tegra_car TEGRA20_CLK_DSI>,
+ <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+ clock-names = "dsi", "parent";
+ resets = <&tegra_car 48>;
+ reset-names = "dsi";
+ status = "disabled";
+ };
+ };
+
+ ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/generic-acpi.txt b/roms/u-boot/doc/device-tree-bindings/i2c/generic-acpi.txt
new file mode 100644
index 000000000..3510a71b5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/generic-acpi.txt
@@ -0,0 +1,42 @@
+I2C generic device
+==================
+
+This is used only to generate ACPI tables for an I2C device.
+
+Required properties :
+
+ - compatible : "i2c-chip";
+ - reg : I2C chip address
+ - acpi,hid : HID name for the device
+
+Optional properies in addition to device.txt:
+
+ - reset-gpios : GPIO used to assert reset to the device
+ - irq-gpios : GPIO used for interrupt (if Interrupt is not used)
+ - stop-gpios : GPIO used to stop the device
+ - interrupts-extended : Interrupt to use for the device
+ - reset-delay-ms : Delay after de-asserting reset, in ms
+ - reset-off-delay-ms : Delay after asserting reset (during power off)
+ - enable-delay-ms : Delay after asserting enable
+ - enable-off-delay-ms : Delay after de-asserting enable (during power off)
+ - stop-delay-ms : Delay after de-aserting stop
+ - stop-off-delay-ms : Delay after asserting stop (during power off)
+ - hid-descr-addr : HID register offset (for Human Interface Devices)
+
+Example
+-------
+
+ elan-touchscreen@10 {
+ compatible = "i2c-chip";
+ reg = <0x10>;
+ acpi,hid = "ELAN0001";
+ acpi,ddn = "ELAN Touchscreen";
+ interrupts-extended = <&acpi_gpe GPIO_21_IRQ
+ IRQ_TYPE_EDGE_FALLING>;
+ linux,probed;
+ reset-gpios = <&gpio_n GPIO_36 GPIO_ACTIVE_HIGH>;
+ reset-delay-ms = <20>;
+ enable-gpios = <&gpio_n GPIO_152 GPIO_ACTIVE_HIGH>;
+ enable-delay-ms = <1>;
+ acpi,has-power-resource;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-at91.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-at91.txt
new file mode 100644
index 000000000..2065b7341
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-at91.txt
@@ -0,0 +1,26 @@
+I2C for Atmel platforms
+
+Required properties :
+- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
+ "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c",
+ "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c".
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #address-cells = <1>;
+- #size-cells = <0>;
+- clocks: phandles to input clocks.
+
+Optional properties:
+- clock-frequency: Desired I2C bus frequency in Hz, default value is 100000.
+- Child nodes conforming to i2c bus binding.
+
+Examples :
+
+i2c0: i2c@f8028000 {
+ compatible = "atmel,sama5d2-i2c";
+ reg = <0xf8028000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&twi0_clk>;
+ clock-frequency = <100000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cdns.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cdns.txt
new file mode 100644
index 000000000..202e0b762
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cdns.txt
@@ -0,0 +1,20 @@
+Cadence I2C controller Device Tree Bindings
+-------------------------------------------
+
+Required properties:
+- compatible : Should be "cdns,i2c-r1p10" or "xlnx,zynq-spi-r1p10".
+- reg : Physical base address and size of I2C registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clocks : Clock phandles (see clock bindings for details).
+
+Example:
+ i2c0: i2c@e0004000 {
+ compatible = "cdns,i2c-r1p10";
+ reg = <0xe0004000 0x1000>;
+ clocks = <&clkc 38>;
+ interrupts = <0 25 4>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cortina.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cortina.txt
new file mode 100644
index 000000000..59d523582
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-cortina.txt
@@ -0,0 +1,18 @@
+* I2C for Cortina platforms
+
+Required properties :
+- compatible : Must be "cortina,ca-i2c"
+- reg : Offset and length of the register set for the device
+
+Recommended properties :
+- clock-frequency : desired I2C bus clock frequency in Hz. If not specified,
+ default value is 100000. Possible values are 100000,
+ 400000 and 1000000.
+
+Examples :
+
+ i2c: i2c@f4329120 {
+ compatible = "cortina,ca-i2c";
+ reg = <0x0 0xf4329120 0x28>;
+ clock-frequency = <400000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-designware.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-designware.txt
new file mode 100644
index 000000000..be766be81
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-designware.txt
@@ -0,0 +1,73 @@
+* Synopsys DesignWare I2C
+
+Required properties :
+
+ - compatible : should be "snps,designware-i2c"
+ or "mscc,ocelot-i2c" with "snps,designware-i2c" for fallback
+ - reg : Offset and length of the register set for the device
+ - interrupts : <IRQ> where IRQ is the interrupt number.
+ - clocks : phandles for the clocks, see the description of clock-names below.
+ The phandle for the "ic_clk" clock is required. The phandle for the "pclk"
+ clock is optional. If a single clock is specified but no clock-name, it is
+ the "ic_clk" clock. If both clocks are listed, the "ic_clk" must be first.
+
+Recommended properties :
+
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties :
+
+ - clock-names : Contains the names of the clocks:
+ "ic_clk", for the core clock used to generate the external I2C clock.
+ "pclk", the interface clock, required for register access.
+
+ - reg : for "mscc,ocelot-i2c", a second register set to configure the SDA hold
+ time, named ICPU_CFG:TWI_DELAY in the datasheet.
+
+ - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
+ This option is only supported in hardware blocks version 1.11a or newer and
+ on Microsemi SoCs ("mscc,ocelot-i2c" compatible).
+
+ - i2c-scl-falling-time-ns : should contain the SCL falling time in nanoseconds.
+ This value which is by default 300ns is used to compute the tLOW period.
+
+ - i2c-sda-falling-time-ns : should contain the SDA falling time in nanoseconds.
+ This value which is by default 300ns is used to compute the tHIGH period.
+
+Examples :
+
+ i2c@f0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xf0000 0x1000>;
+ interrupts = <11>;
+ clock-frequency = <400000>;
+ };
+
+ i2c@1120000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0x1120000 0x1000>;
+ interrupt-parent = <&ictl>;
+ interrupts = <12 1>;
+ clock-frequency = <400000>;
+ i2c-sda-hold-time-ns = <300>;
+ i2c-sda-falling-time-ns = <300>;
+ i2c-scl-falling-time-ns = <300>;
+ };x
+
+ i2c@1120000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2000 0x100>;
+ clock-frequency = <400000>;
+ clocks = <&i2cclk>;
+ interrupts = <0>;
+
+ eeprom@64 {
+ compatible = "linux,slave-24c02";
+ reg = <0x40000064>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-gpio.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-gpio.txt
new file mode 100644
index 000000000..b06b82993
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-gpio.txt
@@ -0,0 +1,41 @@
+I2C gpio device binding
+=======================
+
+Driver:
+- drivers/i2c/i2c-gpio.c
+
+Software i2c device-tree node properties:
+Required:
+* #address-cells = <1>;
+* #size-cells = <0>;
+* compatible = "i2c-gpio";
+* gpios = <sda ...>, <scl ...>;
+
+Optional:
+* i2c-gpio,delay-us = <5>;
+ The resulting transfer speed can be adjusted by setting the delay[us]
+ between gpio-toggle operations. Speed [Hz] = 1000000 / 4 * udelay[us],
+ It not defined, then default is 5us (~50KHz).
+* i2c-gpio,deblock
+ Run deblocking sequence when the driver gets probed.
+* i2c-gpio,scl-output-only;
+ Set if SCL is an output only
+
+Example:
+
+i2c-gpio@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "i2c-gpio";
+ gpios = <&gpd1 0 GPIO_ACTIVE_HIGH>, /* SDA */
+ <&gpd1 1 GPIO_ACTIVE_HIGH>; /* CLK */
+
+ i2c-gpio,delay-us = <5>;
+
+ some_device@5 {
+ compatible = "some_device";
+ reg = <0x5>;
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-mux.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-mux.txt
new file mode 100644
index 000000000..af84cce5c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-mux.txt
@@ -0,0 +1,60 @@
+Common i2c bus multiplexer/switch properties.
+
+An i2c bus multiplexer/switch will have several child busses that are
+numbered uniquely in a device dependent manner. The nodes for an i2c bus
+multiplexer/switch will have one child node for each child
+bus.
+
+Required properties:
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Required properties for child nodes:
+- #address-cells = <1>;
+- #size-cells = <0>;
+- reg : The sub-bus number.
+
+Optional properties for child nodes:
+- Other properties specific to the multiplexer/switch hardware.
+- Child nodes conforming to i2c bus binding
+
+
+Example :
+
+ /*
+ An NXP pca9548 8 channel I2C multiplexer at address 0x70
+ with two NXP pca8574 GPIO expanders attached, one each to
+ ports 3 and 4.
+ */
+
+ mux@70 {
+ compatible = "nxp,pca9548";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ gpio1: gpio@38 {
+ compatible = "nxp,pca8574";
+ reg = <0x38>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+ };
+ i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ gpio2: gpio@38 {
+ compatible = "nxp,pca8574";
+ reg = <0x38>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c-stm32.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-stm32.txt
new file mode 100644
index 000000000..df03743ac
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,30 @@
+* I2C controller embedded in STMicroelectronis STM32 platforms
+
+Required properties :
+- compatible : Must be "st,stm32f7-i2c"
+- reg : Offset and length of the register set for the device
+- resets: Must contain the phandle to the reset controller
+- clocks: Must contain the input clock of the I2C instance
+- A pinctrl state named "default" must be defined to set pins in mode of
+ operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal, Fast and Fast+
+ modes are implemented, possible values are 100000, 400000 and 1000000.
+
+Example :
+
+ i2c1: i2c@40005400 {
+ compatible = "st,stm32f7-i2c";
+ reg = <0x40005400 0x400>;
+ resets = <&rcc 181>;
+ clocks = <&clk_pclk1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/i2c.txt b/roms/u-boot/doc/device-tree-bindings/i2c/i2c.txt
new file mode 100644
index 000000000..9698e4899
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/i2c.txt
@@ -0,0 +1,46 @@
+U-Boot I2C
+----------
+
+U-Boot's I2C model has the concept of an offset within a chip (I2C target
+device). The offset can be up to 4 bytes long, but is normally 1 byte,
+meaning that offsets from 0 to 255 are supported by the chip. This often
+corresponds to register numbers.
+
+Apart from the controller-specific I2C bindings, U-Boot supports a special
+property which allows the chip offset length to be selected.
+
+Optional properties:
+- u-boot,i2c-offset-len - length of chip offset in bytes. If omitted the
+ default value of 1 is used.
+- u-boot,i2c-transaction-bytes - the length of single I2C transaction on
+ the bus. Some devices require more than single byte transmission
+ (e.g. mc34708 mfd). This information is necessary to correctly
+ initialize (put into idle state) I2C bus after soft reset.
+- gpios = <sda ...>, <scl ...>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c_xfer>;
+ pinctrl-1 = <&i2c_gpio>;
+ Pin description for I2C bus software deblocking.
+
+
+Example
+-------
+
+i2c4: i2c@12ca0000 {
+ cros-ec@1e {
+ reg = <0x1e>;
+ compatible = "google,cros-ec";
+ i2c-max-frequency = <100000>;
+ u-boot,i2c-offset-len = <0>;
+ u-boot,i2c-transaction-bytes = <3>;
+ ec-interrupt = <&gpx1 6 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c1_xfer>;
+ pinctrl-1 = <&i2c1_gpio>;
+ gpios = <&gpio1 26 GPIO_ACTIVE_LOW>, /* SDA */
+ <&gpio1 27 GPIO_ACTIVE_LOW>; /* SCL */
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/roms/u-boot/doc/device-tree-bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
new file mode 100644
index 000000000..ab240e10d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
@@ -0,0 +1,42 @@
+NVIDIA Tegra186 BPMP I2C controller
+
+In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
+devices, such as the I2C controller for the power management I2C bus. Software
+running on other CPUs must perform IPC to the BPMP in order to execute
+transactions on that I2C bus. This binding describes an I2C bus that is
+accessed in such a fashion.
+
+The BPMP I2C node must be located directly inside the main BPMP node. See
+../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
+
+This node represents an I2C controller. See ../i2c/i2c.txt for details of the
+core I2C binding.
+
+Required properties:
+- compatible:
+ Array of strings.
+ One of:
+ - "nvidia,tegra186-bpmp-i2c".
+- #address-cells: Address cells for I2C device address.
+ Single-cell integer.
+ Must be <1>.
+- #size-cells:
+ Single-cell integer.
+ Must be <0>.
+- nvidia,bpmp-bus-id:
+ Single-cell integer.
+ Indicates the I2C bus number this DT node represent, as defined by the
+ BPMP firmware.
+
+Example:
+
+bpmp {
+ ...
+
+ i2c {
+ compatible = "nvidia,tegra186-bpmp-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nvidia,bpmp-bus-id = <5>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/nx_i2c.txt b/roms/u-boot/doc/device-tree-bindings/i2c/nx_i2c.txt
new file mode 100644
index 000000000..9f3abe78e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/nx_i2c.txt
@@ -0,0 +1,28 @@
+I2C controller embedded in Nexell's/Samsung's SoC S5P4418 and S5P6818
+
+Driver:
+- drivers/i2c/nx_i2c.c
+
+Required properties:
+- #address-cells = <1>;
+- #size-cells = <0>;
+- compatible = "nexell,s5pxx18-i2c";
+- reg = <i2c_base 0x100>;
+ Where i2c_base has to be the base address of the i2c-register set.
+ I2C0: 0xc00a4000
+ I2C1: 0xc00a5000
+ I2C2: 0xc00a6000
+
+Optional properties:
+- clock-frequency: Desired I2C bus frequency in Hz, default value is 100000.
+- i2c-sda-delay-ns (S5P6818 only): SDA delay in ns, default value is 0.
+- Child nodes conforming to i2c bus binding.
+
+Example:
+ i2c0:i2c@c00a4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nexell,s5pxx18-i2c";
+ reg = <0xc00a4000 0x100>;
+ clock-frequency = <400000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/octeon-i2c.txt b/roms/u-boot/doc/device-tree-bindings/i2c/octeon-i2c.txt
new file mode 100644
index 000000000..9c1908ec2
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/i2c/octeon-i2c.txt
@@ -0,0 +1,24 @@
+* I2C controller embedded in Marvell Octeon platforms
+
+Required properties :
+- compatible : Must be "cavium,octeon-7890-twsi" or a compatible string
+- reg : Offset and length of the register set for the device
+- clocks: Must contain the input clock of the I2C instance
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal, Fast and Fast+
+ modes are implemented, possible values are 100000, 400000 and 1000000.
+
+Example :
+
+ i2c0: i2c@1180000001000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cavium,octeon-7890-twsi";
+ reg = <0x11800 0x00001000 0x0 0x200>;
+ clock-frequency = <100000>;
+ clocks = <&sclk>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt b/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt
new file mode 100644
index 000000000..72649dffa
--- /dev/null
+++ b/roms/u-boot/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/roms/u-boot/doc/device-tree-bindings/input/adc-keys.txt b/roms/u-boot/doc/device-tree-bindings/input/adc-keys.txt
new file mode 100644
index 000000000..6c8be6a9a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/input/adc-keys.txt
@@ -0,0 +1,67 @@
+ADC attached resistor ladder buttons
+------------------------------------
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-microvolt: Voltage above or equal to which all the keys are
+ considered up.
+
+Optional properties:
+ - poll-interval: Poll interval time in milliseconds
+ - autorepeat: Boolean, Enable auto repeat feature of Linux input
+ subsystem.
+
+Each button (key) is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+ - label: Descriptive name of the key.
+ - linux,code: Keycode to emit.
+ - press-threshold-microvolt: voltage above or equal to which this key is
+ considered pressed.
+
+No two values of press-threshold-microvolt may be the same.
+All values of press-threshold-microvolt must be less than
+keyup-threshold-microvolt.
+
+Example:
+
+#include <dt-bindings/input/input.h>
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&lradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <2000000>;
+
+ button-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ press-threshold-microvolt = <1500000>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ press-threshold-microvolt = <1000000>;
+ };
+
+ button-enter {
+ label = "Enter";
+ linux,code = <KEY_ENTER>;
+ press-threshold-microvolt = <500000>;
+ };
+ };
+
++--------------------------------+------------------------+
+| 2.000.000 <= value | no key pressed |
++--------------------------------+------------------------+
+| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
++--------------------------------+------------------------+
+| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed |
++--------------------------------+------------------------+
+| 500.000 <= value < 1.000.000 | KEY_ENTER pressed |
++--------------------------------+------------------------+
+| value < 500.000 | no key pressed |
++--------------------------------+------------------------+
diff --git a/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt b/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000000000..0f6355ce3
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/input/hid-over-i2c.txt b/roms/u-boot/doc/device-tree-bindings/input/hid-over-i2c.txt
new file mode 100644
index 000000000..c76bafaf9
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/input/hid-over-i2c.txt
@@ -0,0 +1,44 @@
+* HID over I2C Device-Tree bindings
+
+HID over I2C provides support for various Human Interface Devices over the
+I2C bus. These devices can be for example touchpads, keyboards, touch screens
+or sensors.
+
+The specification has been written by Microsoft and is currently available here:
+http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
+
+If this binding is used, the kernel module i2c-hid will handle the communication
+with the device and the generic hid core layer will handle the protocol.
+
+Required properties:
+- compatible: must be "hid-over-i2c"
+- reg: i2c slave address
+- hid-descr-addr: HID descriptor address
+- interrupts: interrupt line
+
+Additional optional properties:
+
+Some devices may support additional optional properties to help with, e.g.,
+power sequencing. The following properties can be supported by one or more
+device-specific compatible properties, which should be used in addition to the
+"hid-over-i2c" string.
+
+- compatible:
+ * "wacom,w9013" (Wacom W9013 digitizer). Supports:
+ - vdd-supply (3.3V)
+ - vddl-supply (1.8V)
+ - post-power-on-delay-ms
+
+- vdd-supply: phandle of the regulator that provides the supply voltage.
+- post-power-on-delay-ms: time required by the device after enabling its regulators
+ or powering it on, before it is ready for communication.
+
+Example:
+
+ i2c-hid-dev@2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+ hid-descr-addr = <0x0020>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <3 2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/input/i8042.txt b/roms/u-boot/doc/device-tree-bindings/input/i8042.txt
new file mode 100644
index 000000000..cd079c274
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/input/i8042.txt
@@ -0,0 +1,10 @@
+i8042 Keyboard
+
+The Intel i8042 is a keyboard controller used on many x86 PCs.
+
+Required properties:
+- compatible: "intel,i8042-keyboard"
+
+Optional properties:
+- intel,duplicate-por: Indicates that a keyboard reset may result in a
+ duplicate POR byte, which should be ignored.
diff --git a/roms/u-boot/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt b/roms/u-boot/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
new file mode 100644
index 000000000..2fe02d8a2
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
@@ -0,0 +1,30 @@
+* Intel Advanced Configuration and Power Interface General Purpose Events
+
+This describes an interrupt controller which provides access to GPEs supported
+by the SoC.
+
+Required properties:
+
+- compatible : "intel,acpi-gpe"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : The number of cells to define the interrupts. Must be 2:
+ cell 0: interrupt number (normally >=32 since GPEs below that are reserved)
+ cell 1: 0 (flags, but none are currently defined)
+- reg : The register bank for the controller (set this to the ACPI base).
+
+Example:
+
+ general-purpose-events {
+ reg = <IOMAP_ACPI_BASE IOMAP_ACPI_SIZE>;
+ compatible = "intel,acpi-gpe";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ...
+ tpm@50 {
+ reg = <0x50>;
+ compatible = "google,cr50";
+ ready-gpios = <&gpio_n 0x1c GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&acpi_gpe 0x3c 0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/interrupt-controller/interrupts.txt b/roms/u-boot/doc/device-tree-bindings/interrupt-controller/interrupts.txt
new file mode 100644
index 000000000..38a399a6b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/interrupt-controller/interrupts.txt
@@ -0,0 +1,131 @@
+Specifying interrupt information for devices
+============================================
+
+1) Interrupt client nodes
+-------------------------
+
+Nodes that describe devices which generate interrupts must contain an
+"interrupts" property, an "interrupts-extended" property, or both. If both are
+present, the latter should take precedence; the former may be provided simply
+for compatibility with software that does not recognize the latter. These
+properties contain a list of interrupt specifiers, one per output interrupt. The
+format of the interrupt specifier is determined by the interrupt controller to
+which the interrupts are routed; see section 2 below for details.
+
+ Example:
+ interrupt-parent = <&intc1>;
+ interrupts = <5 0>, <6 0>;
+
+The "interrupt-parent" property is used to specify the controller to which
+interrupts are routed and contains a single phandle referring to the interrupt
+controller node. This property is inherited, so it may be specified in an
+interrupt client node or in any of its parent nodes. Interrupts listed in the
+"interrupts" property are always in reference to the node's interrupt parent.
+
+The "interrupts-extended" property is a special form; useful when a node needs
+to reference multiple interrupt parents or a different interrupt parent than
+the inherited one. Each entry in this property contains both the parent phandle
+and the interrupt specifier.
+
+ Example:
+ interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;
+
+(NOTE: only this 'special form' is supported in U-Boot)
+
+
+2) Interrupt controller nodes
+-----------------------------
+
+A device is marked as an interrupt controller with the "interrupt-controller"
+property. This is a empty, boolean property. An additional "#interrupt-cells"
+property defines the number of cells needed to specify a single interrupt.
+
+It is the responsibility of the interrupt controller's binding to define the
+length and format of the interrupt specifier. The following two variants are
+commonly used:
+
+ a) one cell
+ -----------
+ The #interrupt-cells property is set to 1 and the single cell defines the
+ index of the interrupt within the controller.
+
+ Example:
+
+ vic: intc@10140000 {
+ compatible = "arm,versatile-vic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x10140000 0x1000>;
+ };
+
+ sic: intc@10003000 {
+ compatible = "arm,versatile-sic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x10003000 0x1000>;
+ interrupt-parent = <&vic>;
+ interrupts = <31>; /* Cascaded to vic */
+ };
+
+ b) two cells
+ ------------
+ The #interrupt-cells property is set to 2 and the first cell defines the
+ index of the interrupt within the controller, while the second cell is used
+ to specify any of the following flags:
+ - bits[3:0] trigger type and level flags
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive
+
+ Example:
+
+ i2c@7000c000 {
+ gpioext: gpio-adnp@41 {
+ compatible = "ad,gpio-adnp";
+ reg = <0x41>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <160 1>;
+
+ gpio-controller;
+ #gpio-cells = <1>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ nr-gpios = <64>;
+ };
+
+ sx8634@2b {
+ compatible = "smtc,sx8634";
+ reg = <0x2b>;
+
+ interrupt-parent = <&gpioext>;
+ interrupts = <3 0x8>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ threshold = <0x40>;
+ sensitivity = <7>;
+ };
+ };
+
+
+Example of special form (supported by U-Boot):
+
+ acpi_gpe: general-purpose-events {
+ reg = <IOMAP_ACPI_BASE IOMAP_ACPI_SIZE>;
+ compatible = "intel,acpi-gpe";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ tpm@50 {
+ reg = <0x50>;
+ compatible = "google,cr50";
+ u-boot,i2c-offset-len = <0>;
+ ready-gpio = <&gpio_n 28 GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&acpi_gpe 0x3c 0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/leds/common.txt b/roms/u-boot/doc/device-tree-bindings/leds/common.txt
new file mode 100644
index 000000000..2d88816dd
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/leds/common.txt
@@ -0,0 +1,23 @@
+Common leds properties.
+
+Optional properties for child nodes:
+- label : The label for this LED. If omitted, the label is
+ taken from the node name (excluding the unit address).
+
+- linux,default-trigger : This parameter, if present, is a
+ string defining the trigger assigned to the LED. Current triggers are:
+ "backlight" - LED will act as a back-light, controlled by the framebuffer
+ system
+ "default-on" - LED will turn on (but for leds-gpio see "default-state"
+ property in Documentation/devicetree/bindings/gpio/led.txt)
+ "heartbeat" - LED "double" flashes at a load average based rate
+ "ide-disk" - LED indicates disk activity
+ "timer" - LED flashes at a fixed, configurable rate
+
+Examples:
+
+system-status {
+ label = "Status";
+ linux,default-trigger = "heartbeat";
+ ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6328.txt b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6328.txt
new file mode 100644
index 000000000..7f5597b73
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6328.txt
@@ -0,0 +1,106 @@
+LEDs connected to Broadcom BCM6328 controller
+
+This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
+In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
+However, on some devices there are Serial LEDs (LEDs connected to a 74x164
+controller), which can either be controlled by software (exporting the 74x164
+as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
+by hardware using this driver.
+Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
+exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
+controlled, so the only chance to keep them working is by using this driver.
+
+Required properties:
+ - compatible : should be "brcm,bcm6328-leds".
+ - #address-cells : must be 1.
+ - #size-cells : must be 0.
+ - reg : BCM6328 LED controller address and size.
+
+Optional properties:
+ - brcm,serial-leds : Boolean, enables Serial LEDs.
+ Default : false
+ - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing.
+ Default : false
+ - brcm,serial-clk-low : Boolean, makes clock signal active low.
+ Default : false
+ - brcm,serial-dat-low : Boolean, makes data signal active low.
+ Default : false
+ - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction.
+ Default : false
+
+Each LED is represented as a sub-node of the brcm,bcm6328-leds device.
+
+LED sub-node required properties:
+ - reg : LED pin number (only LEDs 0 to 23 are valid).
+
+LED sub-node optional properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - active-low : Boolean, makes LED active low.
+ Default : false
+
+Examples:
+Scenario 1 : BCM6328 with 4 GPIO LEDs
+ leds0: led-controller@10000800 {
+ compatible = "brcm,bcm6328-leds";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10000800 0x24>;
+
+ alarm_red@2 {
+ reg = <2>;
+ active-low;
+ label = "red:alarm";
+ };
+ inet_green@3 {
+ reg = <3>;
+ active-low;
+ label = "green:inet";
+ };
+ power_green@4 {
+ reg = <4>;
+ active-low;
+ label = "green:power";
+ };
+ };
+
+Scenario 2 : BCM63268 with Serial LEDs
+ leds0: led-controller@10001900 {
+ compatible = "brcm,bcm6328-leds";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10001900 0x24>;
+ brcm,serial-leds;
+ brcm,serial-dat-low;
+ brcm,serial-shift-inv;
+
+ inet_red@2 {
+ reg = <2>;
+ active-low;
+ label = "red:inet";
+ };
+ dsl_green@3 {
+ reg = <3>;
+ active-low;
+ label = "green:dsl";
+ };
+ usb_green@4 {
+ reg = <4>;
+ active-low;
+ label = "green:usb";
+ };
+ wps_green@7 {
+ reg = <7>;
+ active-low;
+ label = "green:wps";
+ };
+ inet_green@8 {
+ reg = <8>;
+ active-low;
+ label = "green:inet";
+ };
+ power_green@20 {
+ reg = <20>;
+ active-low;
+ label = "green:power";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6358.txt b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6358.txt
new file mode 100644
index 000000000..e394d9ebb
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6358.txt
@@ -0,0 +1,141 @@
+LEDs connected to Broadcom BCM6358 controller
+
+This controller is present on BCM6358 and BCM6368.
+In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller),
+which can either be controlled by software (exporting the 74x164 as spi-gpio.
+See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
+by hardware using this driver.
+
+Required properties:
+ - compatible : should be "brcm,bcm6358-leds".
+ - #address-cells : must be 1.
+ - #size-cells : must be 0.
+ - reg : BCM6358 LED controller address and size.
+
+Optional properties:
+ - brcm,clk-div : SCK signal divider. Possible values are 1, 2, 4 and 8.
+ Default : 1
+ - brcm,clk-dat-low : Boolean, makes clock and data signals active low.
+ Default : false
+
+Each LED is represented as a sub-node of the brcm,bcm6358-leds device.
+
+LED sub-node required properties:
+ - reg : LED pin number (only LEDs 0 to 31 are valid).
+
+LED sub-node optional properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - active-low : Boolean, makes LED active low.
+ Default : false
+
+Examples:
+Scenario 1 : BCM6358
+ leds0: led-controller@fffe00d0 {
+ compatible = "brcm,bcm6358-leds";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfffe00d0 0x8>;
+
+ alarm_white {
+ reg = <0>;
+ active-low;
+ label = "white:alarm";
+ };
+ tv_white {
+ reg = <2>;
+ active-low;
+ label = "white:tv";
+ };
+ tel_white {
+ reg = <3>;
+ active-low;
+ label = "white:tel";
+ };
+ adsl_white {
+ reg = <4>;
+ active-low;
+ label = "white:adsl";
+ };
+ };
+
+Scenario 2 : BCM6368
+ leds0: led-controller@100000d0 {
+ compatible = "brcm,bcm6358-leds";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x100000d0 0x8>;
+ brcm,pol-low;
+ brcm,clk-div = <4>;
+
+ power_red {
+ reg = <0>;
+ active-low;
+ label = "red:power";
+ };
+ power_green {
+ reg = <1>;
+ active-low;
+ label = "green:power";
+ default-state = "on";
+ };
+ power_blue {
+ reg = <2>;
+ label = "blue:power";
+ };
+ broadband_red {
+ reg = <3>;
+ active-low;
+ label = "red:broadband";
+ };
+ broadband_green {
+ reg = <4>;
+ label = "green:broadband";
+ };
+ broadband_blue {
+ reg = <5>;
+ active-low;
+ label = "blue:broadband";
+ };
+ wireless_red {
+ reg = <6>;
+ active-low;
+ label = "red:wireless";
+ };
+ wireless_green {
+ reg = <7>;
+ active-low;
+ label = "green:wireless";
+ };
+ wireless_blue {
+ reg = <8>;
+ label = "blue:wireless";
+ };
+ phone_red {
+ reg = <9>;
+ active-low;
+ label = "red:phone";
+ };
+ phone_green {
+ reg = <10>;
+ active-low;
+ label = "green:phone";
+ };
+ phone_blue {
+ reg = <11>;
+ label = "blue:phone";
+ };
+ upgrading_red {
+ reg = <12>;
+ active-low;
+ label = "red:upgrading";
+ };
+ upgrading_green {
+ reg = <13>;
+ active-low;
+ label = "green:upgrading";
+ };
+ upgrading_blue {
+ reg = <14>;
+ label = "blue:upgrading";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6858.txt b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6858.txt
new file mode 100644
index 000000000..ea2fe2370
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/leds/leds-bcm6858.txt
@@ -0,0 +1,51 @@
+LEDs connected to Broadcom BCM6858 controller
+
+This controller is present on BCM6858, BCM6328, BCM6362 and BCM63268.
+In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
+
+Required properties:
+ - compatible : should be "brcm,bcm6858-leds".
+ - #address-cells : must be 1.
+ - #size-cells : must be 0.
+ - reg : BCM6858 LED controller address and size.
+
+Optional properties:
+ - brcm,serial-led-msb-first : Boolean, msb data come out first on serial data pin
+ Default : false
+ - brcm,serial-led-en-pol : Boolean, serial led polarity (true => active high)
+ Default : false
+ - brcm,serial-led-clk-pol : Boolean, serial clock polarity (true => active high)
+ Default : false
+ - brcm,serial-led-data-ppol : Boolean, serial data polarity (true => active high)
+ Default : false
+ - brcm,serial-shift-inv : Boolean, led test mode
+ Default : false
+
+Each LED is represented as a sub-node of the brcm,bcm6858-leds device.
+
+LED sub-node required properties:
+ - reg : LED pin number (only LEDs 0 to 32 are valid).
+
+LED sub-node optional properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - active-low : Boolean, makes LED active low.
+ Default : false
+
+Examples:
+BCM6328 with 2 GPIO LEDs
+ leds0: led-controller@ff800800 {
+ compatible = "brcm,bcm6858-leds";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0xff800800 0x0 0xe4>;
+
+ led@2 {
+ reg = <2>;
+ label = "green:inet";
+ };
+
+ led@5 {
+ reg = <5>;
+ label = "red:alarm";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/leds/leds-gpio.txt b/roms/u-boot/doc/device-tree-bindings/leds/leds-gpio.txt
new file mode 100644
index 000000000..df1b3080f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/leds/leds-gpio.txt
@@ -0,0 +1,52 @@
+LEDs connected to GPIO lines
+
+Required properties:
+- compatible : should be "gpio-leds".
+
+Each LED is represented as a sub-node of the gpio-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- gpios : Should specify the LED's GPIO, see "gpios property" in
+ Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
+ indicated using flags in the GPIO specifier.
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
+
+Examples:
+
+leds {
+ compatible = "gpio-leds";
+ hdd {
+ label = "IDE Activity";
+ gpios = <&mcu_pio 0 1>; /* Active low */
+ linux,default-trigger = "ide-disk";
+ };
+
+ fault {
+ gpios = <&mcu_pio 1 0>;
+ /* Keep LED on if BIOS detected hardware fault */
+ default-state = "keep";
+ };
+};
+
+run-control {
+ compatible = "gpio-leds";
+ red {
+ gpios = <&mpc8572 6 0>;
+ default-state = "off";
+ };
+ green {
+ gpios = <&mpc8572 7 0>;
+ default-state = "on";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt b/roms/u-boot/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
new file mode 100644
index 000000000..f3add0d4e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
@@ -0,0 +1,40 @@
+Texas Instruments' K3 Secure Proxy
+===================================
+
+The Texas Instruments' K3 Secure Proxy is a mailbox controller that has
+configurable threads maintained by System power processor. Each thread
+has different address space that can be used to send or receive messages.
+
+Secure Proxy Device Node:
+===========================
+Required properties:
+--------------------
+- compatible: Shall be: "ti,am654-secure-proxy"
+- reg-names data - Map the data region
+ scfg - Map the secure configuration region
+ rt - Map the Realtime region.
+- reg: Contains the register map per reg-names.
+- #mbox-cells Shall be 1. Contains the thread ID.
+
+Example:
+--------
+
+secproxy: secproxy@285b0000 {
+ compatible = "ti,am654-secure-proxy";
+ reg = <0x2a380000 0x80000>,
+ <0x2a400000 0x80000>,
+ <0x2a480000 0x80000>;
+ reg-names = "rt", "scfg", "data";
+ #mbox-cells = <1>;
+};
+
+client:
+
+systemcontroller: systemcontroller {
+ [...]
+ # RX thread ID is 4.
+ # TX thread ID is 5.
+ mboxes= <&secproxy 4>,
+ <&secproxy 5>;
+ [...]
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/mailbox/mailbox.txt b/roms/u-boot/doc/device-tree-bindings/mailbox/mailbox.txt
new file mode 100644
index 000000000..be05b9746
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mailbox/mailbox.txt
@@ -0,0 +1,32 @@
+* Generic Mailbox Controller and client driver bindings
+
+Generic binding to provide a way for Mailbox controller drivers to
+assign appropriate mailbox channel to client drivers.
+
+* Mailbox Controller
+
+Required property:
+- #mbox-cells: Must be at least 1. Number of cells in a mailbox
+ specifier.
+
+Example:
+ mailbox: mailbox {
+ ...
+ #mbox-cells = <1>;
+ };
+
+
+* Mailbox Client
+
+Required property:
+- mboxes: List of phandle and mailbox channel specifiers.
+
+Optional property:
+- mbox-names: List of identifier strings for each mailbox channel.
+
+Example:
+ pwr_cntrl: power {
+ ...
+ mbox-names = "pwr-ctrl", "rpc";
+ mboxes = <&mailbox 0 &mailbox 1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/mailbox/nvidia,tegra186-hsp.txt b/roms/u-boot/doc/device-tree-bindings/mailbox/nvidia,tegra186-hsp.txt
new file mode 100644
index 000000000..a91523806
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mailbox/nvidia,tegra186-hsp.txt
@@ -0,0 +1,52 @@
+NVIDIA Tegra Hardware Synchronization Primitives (HSP)
+
+The HSP modules are used for the processors to share resources and communicate
+together. It provides a set of hardware synchronization primitives for
+interprocessor communication. So the interprocessor communication (IPC)
+protocols can use hardware synchronization primitives, when operating between
+two processors not in an SMP relationship.
+
+The features that HSP supported are shared mailboxes, shared semaphores,
+arbitrated semaphores and doorbells.
+
+Required properties:
+- name : Should be hsp
+- compatible
+ Array of strings.
+ one of:
+ - "nvidia,tegra186-hsp"
+- reg : Offset and length of the register set for the device.
+- interrupt-names
+ Array of strings.
+ Contains a list of names for the interrupts described by the interrupt
+ property. May contain the following entries, in any order:
+ - "doorbell"
+ Users of this binding MUST look up entries in the interrupt property
+ by name, using this interrupt-names property to do so.
+- interrupts
+ Array of interrupt specifiers.
+ Must contain one entry per entry in the interrupt-names property,
+ in a matching order.
+- #mbox-cells : Should be 2.
+
+The mbox specifier of the "mboxes" property in the client node should
+contain two data. The first one should be the HSP type and the second
+one should be the ID that the client is going to use. Those information
+can be found in the following file.
+
+- <dt-bindings/mailbox/tegra186-hsp.h>.
+
+Example:
+
+hsp_top0: hsp@3c00000 {
+ compatible = "nvidia,tegra186-hsp";
+ reg = <0x0 0x03c00000 0x0 0xa0000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "doorbell";
+ #mbox-cells = <2>;
+};
+
+client {
+ ...
+ mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_XXX>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/memory-controller/k3-j721e-ddrss.txt b/roms/u-boot/doc/device-tree-bindings/memory-controller/k3-j721e-ddrss.txt
new file mode 100644
index 000000000..c4cf26eaa
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/memory-controller/k3-j721e-ddrss.txt
@@ -0,0 +1,2242 @@
+Texas Instruments' K3 J721E DDRSS
+==================================
+The J721E DDR subsystem comprises DDR controller, DDR PHY and wrapper
+logic to integrate these blocks in the device. The DDR subsystem is
+used to provide an interface to external SDRAM devices which can be
+utilized for storing program or data.
+
+DDRSS device node:
+==================
+Required properties:
+--------------------
+- compatible: Shall be: "ti,j721e-ddrss" for j721e, j7200
+ "ti,am64-ddrss" for am642
+- reg-names cfg - Map the controller configuration region
+ ctrl_mmr_lp4 - Map LP4 register region in ctrl mmr
+- reg: Contains the register map per reg-names.
+- power-domains: Should contain two entries:
+ - an entry to TISCI DDR CFG device
+ - an entry to TISCI DDR DATA.
+ This property is as per the binding,
+ doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+- clocks: Should contain two entries.
+ - An entry to DDRSS clock
+ - An rntry to SoC bypass clock
+ Should be defined as per the appropriate clock bindings
+ consumer usage in
+ doc/device-tree-bindings/clock/ti,sci-clk.txt
+- ti,ddr-freq1: First frequency set point
+- ti,ddr-freq2: Second frequency set point
+- ti,ddr-fhs-cnt: Number of times to communicate to DDR for frequency handshake.
+- ti,ctl-data: An array containing the controller settings.
+- ti,pi-data: An array containing the phy independent block settings
+- ti,phy-data: An array containing the ddr phy settings.
+
+Example (J721E):
+================
+
+memorycontroller: memorycontroller@0298e000 {
+ compatible = "ti,j721e-ddrss";
+ reg = <0x0 0x02990000 0x0 0x4000>,
+ <0x0 0x0114000 0x0 0x100>;
+ reg-names = "cfg", "ctrl_mmr_lp4";
+ power-domains = <&k3_pds 47 TI_SCI_PD_SHARED>,
+ <&k3_pds 90 TI_SCI_PD_SHARED>;
+ clocks = <&k3_clks 47 2>, <&k3_clks 30 9>;
+ ti,ddr-freq1 = <DDRSS_PLL_FREQUENCY_1>;
+ ti,ddr-freq2 = <DDRSS_PLL_FREQUENCY_2>;
+ ti,ddr-fhs-cnt = <DDRSS_PLL_FHS_CNT>;
+
+ u-boot,dm-spl;
+
+ ti,ctl-data = <
+ DDRSS_CTL_00_DATA
+ DDRSS_CTL_01_DATA
+ DDRSS_CTL_02_DATA
+ DDRSS_CTL_03_DATA
+ DDRSS_CTL_04_DATA
+ DDRSS_CTL_05_DATA
+ DDRSS_CTL_06_DATA
+ DDRSS_CTL_07_DATA
+ DDRSS_CTL_08_DATA
+ DDRSS_CTL_09_DATA
+ DDRSS_CTL_10_DATA
+ DDRSS_CTL_11_DATA
+ DDRSS_CTL_12_DATA
+ DDRSS_CTL_13_DATA
+ DDRSS_CTL_14_DATA
+ DDRSS_CTL_15_DATA
+ DDRSS_CTL_16_DATA
+ DDRSS_CTL_17_DATA
+ DDRSS_CTL_18_DATA
+ DDRSS_CTL_19_DATA
+ DDRSS_CTL_20_DATA
+ DDRSS_CTL_21_DATA
+ DDRSS_CTL_22_DATA
+ DDRSS_CTL_23_DATA
+ DDRSS_CTL_24_DATA
+ DDRSS_CTL_25_DATA
+ DDRSS_CTL_26_DATA
+ DDRSS_CTL_27_DATA
+ DDRSS_CTL_28_DATA
+ DDRSS_CTL_29_DATA
+ DDRSS_CTL_30_DATA
+ DDRSS_CTL_31_DATA
+ DDRSS_CTL_32_DATA
+ DDRSS_CTL_33_DATA
+ DDRSS_CTL_34_DATA
+ DDRSS_CTL_35_DATA
+ DDRSS_CTL_36_DATA
+ DDRSS_CTL_37_DATA
+ DDRSS_CTL_38_DATA
+ DDRSS_CTL_39_DATA
+ DDRSS_CTL_40_DATA
+ DDRSS_CTL_41_DATA
+ DDRSS_CTL_42_DATA
+ DDRSS_CTL_43_DATA
+ DDRSS_CTL_44_DATA
+ DDRSS_CTL_45_DATA
+ DDRSS_CTL_46_DATA
+ DDRSS_CTL_47_DATA
+ DDRSS_CTL_48_DATA
+ DDRSS_CTL_49_DATA
+ DDRSS_CTL_50_DATA
+ DDRSS_CTL_51_DATA
+ DDRSS_CTL_52_DATA
+ DDRSS_CTL_53_DATA
+ DDRSS_CTL_54_DATA
+ DDRSS_CTL_55_DATA
+ DDRSS_CTL_56_DATA
+ DDRSS_CTL_57_DATA
+ DDRSS_CTL_58_DATA
+ DDRSS_CTL_59_DATA
+ DDRSS_CTL_60_DATA
+ DDRSS_CTL_61_DATA
+ DDRSS_CTL_62_DATA
+ DDRSS_CTL_63_DATA
+ DDRSS_CTL_64_DATA
+ DDRSS_CTL_65_DATA
+ DDRSS_CTL_66_DATA
+ DDRSS_CTL_67_DATA
+ DDRSS_CTL_68_DATA
+ DDRSS_CTL_69_DATA
+ DDRSS_CTL_70_DATA
+ DDRSS_CTL_71_DATA
+ DDRSS_CTL_72_DATA
+ DDRSS_CTL_73_DATA
+ DDRSS_CTL_74_DATA
+ DDRSS_CTL_75_DATA
+ DDRSS_CTL_76_DATA
+ DDRSS_CTL_77_DATA
+ DDRSS_CTL_78_DATA
+ DDRSS_CTL_79_DATA
+ DDRSS_CTL_80_DATA
+ DDRSS_CTL_81_DATA
+ DDRSS_CTL_82_DATA
+ DDRSS_CTL_83_DATA
+ DDRSS_CTL_84_DATA
+ DDRSS_CTL_85_DATA
+ DDRSS_CTL_86_DATA
+ DDRSS_CTL_87_DATA
+ DDRSS_CTL_88_DATA
+ DDRSS_CTL_89_DATA
+ DDRSS_CTL_90_DATA
+ DDRSS_CTL_91_DATA
+ DDRSS_CTL_92_DATA
+ DDRSS_CTL_93_DATA
+ DDRSS_CTL_94_DATA
+ DDRSS_CTL_95_DATA
+ DDRSS_CTL_96_DATA
+ DDRSS_CTL_97_DATA
+ DDRSS_CTL_98_DATA
+ DDRSS_CTL_99_DATA
+ DDRSS_CTL_100_DATA
+ DDRSS_CTL_101_DATA
+ DDRSS_CTL_102_DATA
+ DDRSS_CTL_103_DATA
+ DDRSS_CTL_104_DATA
+ DDRSS_CTL_105_DATA
+ DDRSS_CTL_106_DATA
+ DDRSS_CTL_107_DATA
+ DDRSS_CTL_108_DATA
+ DDRSS_CTL_109_DATA
+ DDRSS_CTL_110_DATA
+ DDRSS_CTL_111_DATA
+ DDRSS_CTL_112_DATA
+ DDRSS_CTL_113_DATA
+ DDRSS_CTL_114_DATA
+ DDRSS_CTL_115_DATA
+ DDRSS_CTL_116_DATA
+ DDRSS_CTL_117_DATA
+ DDRSS_CTL_118_DATA
+ DDRSS_CTL_119_DATA
+ DDRSS_CTL_120_DATA
+ DDRSS_CTL_121_DATA
+ DDRSS_CTL_122_DATA
+ DDRSS_CTL_123_DATA
+ DDRSS_CTL_124_DATA
+ DDRSS_CTL_125_DATA
+ DDRSS_CTL_126_DATA
+ DDRSS_CTL_127_DATA
+ DDRSS_CTL_128_DATA
+ DDRSS_CTL_129_DATA
+ DDRSS_CTL_130_DATA
+ DDRSS_CTL_131_DATA
+ DDRSS_CTL_132_DATA
+ DDRSS_CTL_133_DATA
+ DDRSS_CTL_134_DATA
+ DDRSS_CTL_135_DATA
+ DDRSS_CTL_136_DATA
+ DDRSS_CTL_137_DATA
+ DDRSS_CTL_138_DATA
+ DDRSS_CTL_139_DATA
+ DDRSS_CTL_140_DATA
+ DDRSS_CTL_141_DATA
+ DDRSS_CTL_142_DATA
+ DDRSS_CTL_143_DATA
+ DDRSS_CTL_144_DATA
+ DDRSS_CTL_145_DATA
+ DDRSS_CTL_146_DATA
+ DDRSS_CTL_147_DATA
+ DDRSS_CTL_148_DATA
+ DDRSS_CTL_149_DATA
+ DDRSS_CTL_150_DATA
+ DDRSS_CTL_151_DATA
+ DDRSS_CTL_152_DATA
+ DDRSS_CTL_153_DATA
+ DDRSS_CTL_154_DATA
+ DDRSS_CTL_155_DATA
+ DDRSS_CTL_156_DATA
+ DDRSS_CTL_157_DATA
+ DDRSS_CTL_158_DATA
+ DDRSS_CTL_159_DATA
+ DDRSS_CTL_160_DATA
+ DDRSS_CTL_161_DATA
+ DDRSS_CTL_162_DATA
+ DDRSS_CTL_163_DATA
+ DDRSS_CTL_164_DATA
+ DDRSS_CTL_165_DATA
+ DDRSS_CTL_166_DATA
+ DDRSS_CTL_167_DATA
+ DDRSS_CTL_168_DATA
+ DDRSS_CTL_169_DATA
+ DDRSS_CTL_170_DATA
+ DDRSS_CTL_171_DATA
+ DDRSS_CTL_172_DATA
+ DDRSS_CTL_173_DATA
+ DDRSS_CTL_174_DATA
+ DDRSS_CTL_175_DATA
+ DDRSS_CTL_176_DATA
+ DDRSS_CTL_177_DATA
+ DDRSS_CTL_178_DATA
+ DDRSS_CTL_179_DATA
+ DDRSS_CTL_180_DATA
+ DDRSS_CTL_181_DATA
+ DDRSS_CTL_182_DATA
+ DDRSS_CTL_183_DATA
+ DDRSS_CTL_184_DATA
+ DDRSS_CTL_185_DATA
+ DDRSS_CTL_186_DATA
+ DDRSS_CTL_187_DATA
+ DDRSS_CTL_188_DATA
+ DDRSS_CTL_189_DATA
+ DDRSS_CTL_190_DATA
+ DDRSS_CTL_191_DATA
+ DDRSS_CTL_192_DATA
+ DDRSS_CTL_193_DATA
+ DDRSS_CTL_194_DATA
+ DDRSS_CTL_195_DATA
+ DDRSS_CTL_196_DATA
+ DDRSS_CTL_197_DATA
+ DDRSS_CTL_198_DATA
+ DDRSS_CTL_199_DATA
+ DDRSS_CTL_200_DATA
+ DDRSS_CTL_201_DATA
+ DDRSS_CTL_202_DATA
+ DDRSS_CTL_203_DATA
+ DDRSS_CTL_204_DATA
+ DDRSS_CTL_205_DATA
+ DDRSS_CTL_206_DATA
+ DDRSS_CTL_207_DATA
+ DDRSS_CTL_208_DATA
+ DDRSS_CTL_209_DATA
+ DDRSS_CTL_210_DATA
+ DDRSS_CTL_211_DATA
+ DDRSS_CTL_212_DATA
+ DDRSS_CTL_213_DATA
+ DDRSS_CTL_214_DATA
+ DDRSS_CTL_215_DATA
+ DDRSS_CTL_216_DATA
+ DDRSS_CTL_217_DATA
+ DDRSS_CTL_218_DATA
+ DDRSS_CTL_219_DATA
+ DDRSS_CTL_220_DATA
+ DDRSS_CTL_221_DATA
+ DDRSS_CTL_222_DATA
+ DDRSS_CTL_223_DATA
+ DDRSS_CTL_224_DATA
+ DDRSS_CTL_225_DATA
+ DDRSS_CTL_226_DATA
+ DDRSS_CTL_227_DATA
+ DDRSS_CTL_228_DATA
+ DDRSS_CTL_229_DATA
+ DDRSS_CTL_230_DATA
+ DDRSS_CTL_231_DATA
+ DDRSS_CTL_232_DATA
+ DDRSS_CTL_233_DATA
+ DDRSS_CTL_234_DATA
+ DDRSS_CTL_235_DATA
+ DDRSS_CTL_236_DATA
+ DDRSS_CTL_237_DATA
+ DDRSS_CTL_238_DATA
+ DDRSS_CTL_239_DATA
+ DDRSS_CTL_240_DATA
+ DDRSS_CTL_241_DATA
+ DDRSS_CTL_242_DATA
+ DDRSS_CTL_243_DATA
+ DDRSS_CTL_244_DATA
+ DDRSS_CTL_245_DATA
+ DDRSS_CTL_246_DATA
+ DDRSS_CTL_247_DATA
+ DDRSS_CTL_248_DATA
+ DDRSS_CTL_249_DATA
+ DDRSS_CTL_250_DATA
+ DDRSS_CTL_251_DATA
+ DDRSS_CTL_252_DATA
+ DDRSS_CTL_253_DATA
+ DDRSS_CTL_254_DATA
+ DDRSS_CTL_255_DATA
+ DDRSS_CTL_256_DATA
+ DDRSS_CTL_257_DATA
+ DDRSS_CTL_258_DATA
+ DDRSS_CTL_259_DATA
+ DDRSS_CTL_260_DATA
+ DDRSS_CTL_261_DATA
+ DDRSS_CTL_262_DATA
+ DDRSS_CTL_263_DATA
+ DDRSS_CTL_264_DATA
+ DDRSS_CTL_265_DATA
+ DDRSS_CTL_266_DATA
+ DDRSS_CTL_267_DATA
+ DDRSS_CTL_268_DATA
+ DDRSS_CTL_269_DATA
+ DDRSS_CTL_270_DATA
+ DDRSS_CTL_271_DATA
+ DDRSS_CTL_272_DATA
+ DDRSS_CTL_273_DATA
+ DDRSS_CTL_274_DATA
+ DDRSS_CTL_275_DATA
+ DDRSS_CTL_276_DATA
+ DDRSS_CTL_277_DATA
+ DDRSS_CTL_278_DATA
+ DDRSS_CTL_279_DATA
+ DDRSS_CTL_280_DATA
+ DDRSS_CTL_281_DATA
+ DDRSS_CTL_282_DATA
+ DDRSS_CTL_283_DATA
+ DDRSS_CTL_284_DATA
+ DDRSS_CTL_285_DATA
+ DDRSS_CTL_286_DATA
+ DDRSS_CTL_287_DATA
+ DDRSS_CTL_288_DATA
+ DDRSS_CTL_289_DATA
+ DDRSS_CTL_290_DATA
+ DDRSS_CTL_291_DATA
+ DDRSS_CTL_292_DATA
+ DDRSS_CTL_293_DATA
+ DDRSS_CTL_294_DATA
+ DDRSS_CTL_295_DATA
+ DDRSS_CTL_296_DATA
+ DDRSS_CTL_297_DATA
+ DDRSS_CTL_298_DATA
+ DDRSS_CTL_299_DATA
+ DDRSS_CTL_300_DATA
+ DDRSS_CTL_301_DATA
+ DDRSS_CTL_302_DATA
+ DDRSS_CTL_303_DATA
+ DDRSS_CTL_304_DATA
+ DDRSS_CTL_305_DATA
+ DDRSS_CTL_306_DATA
+ DDRSS_CTL_307_DATA
+ DDRSS_CTL_308_DATA
+ DDRSS_CTL_309_DATA
+ DDRSS_CTL_310_DATA
+ DDRSS_CTL_311_DATA
+ DDRSS_CTL_312_DATA
+ DDRSS_CTL_313_DATA
+ DDRSS_CTL_314_DATA
+ DDRSS_CTL_315_DATA
+ DDRSS_CTL_316_DATA
+ DDRSS_CTL_317_DATA
+ DDRSS_CTL_318_DATA
+ DDRSS_CTL_319_DATA
+ DDRSS_CTL_320_DATA
+ DDRSS_CTL_321_DATA
+ DDRSS_CTL_322_DATA
+ DDRSS_CTL_323_DATA
+ DDRSS_CTL_324_DATA
+ DDRSS_CTL_325_DATA
+ DDRSS_CTL_326_DATA
+ DDRSS_CTL_327_DATA
+ DDRSS_CTL_328_DATA
+ DDRSS_CTL_329_DATA
+ DDRSS_CTL_330_DATA
+ DDRSS_CTL_331_DATA
+ DDRSS_CTL_332_DATA
+ DDRSS_CTL_333_DATA
+ DDRSS_CTL_334_DATA
+ DDRSS_CTL_335_DATA
+ DDRSS_CTL_336_DATA
+ DDRSS_CTL_337_DATA
+ DDRSS_CTL_338_DATA
+ DDRSS_CTL_339_DATA
+ DDRSS_CTL_340_DATA
+ DDRSS_CTL_341_DATA
+ DDRSS_CTL_342_DATA
+ DDRSS_CTL_343_DATA
+ DDRSS_CTL_344_DATA
+ DDRSS_CTL_345_DATA
+ DDRSS_CTL_346_DATA
+ DDRSS_CTL_347_DATA
+ DDRSS_CTL_348_DATA
+ DDRSS_CTL_349_DATA
+ DDRSS_CTL_350_DATA
+ DDRSS_CTL_351_DATA
+ DDRSS_CTL_352_DATA
+ DDRSS_CTL_353_DATA
+ DDRSS_CTL_354_DATA
+ DDRSS_CTL_355_DATA
+ DDRSS_CTL_356_DATA
+ DDRSS_CTL_357_DATA
+ DDRSS_CTL_358_DATA
+ DDRSS_CTL_359_DATA
+ DDRSS_CTL_360_DATA
+ DDRSS_CTL_361_DATA
+ DDRSS_CTL_362_DATA
+ DDRSS_CTL_363_DATA
+ DDRSS_CTL_364_DATA
+ DDRSS_CTL_365_DATA
+ DDRSS_CTL_366_DATA
+ DDRSS_CTL_367_DATA
+ DDRSS_CTL_368_DATA
+ DDRSS_CTL_369_DATA
+ DDRSS_CTL_370_DATA
+ DDRSS_CTL_371_DATA
+ DDRSS_CTL_372_DATA
+ DDRSS_CTL_373_DATA
+ DDRSS_CTL_374_DATA
+ DDRSS_CTL_375_DATA
+ DDRSS_CTL_376_DATA
+ DDRSS_CTL_377_DATA
+ DDRSS_CTL_378_DATA
+ DDRSS_CTL_379_DATA
+ DDRSS_CTL_380_DATA
+ DDRSS_CTL_381_DATA
+ DDRSS_CTL_382_DATA
+ DDRSS_CTL_383_DATA
+ DDRSS_CTL_384_DATA
+ DDRSS_CTL_385_DATA
+ DDRSS_CTL_386_DATA
+ DDRSS_CTL_387_DATA
+ DDRSS_CTL_388_DATA
+ DDRSS_CTL_389_DATA
+ DDRSS_CTL_390_DATA
+ DDRSS_CTL_391_DATA
+ DDRSS_CTL_392_DATA
+ DDRSS_CTL_393_DATA
+ DDRSS_CTL_394_DATA
+ DDRSS_CTL_395_DATA
+ DDRSS_CTL_396_DATA
+ DDRSS_CTL_397_DATA
+ DDRSS_CTL_398_DATA
+ DDRSS_CTL_399_DATA
+ DDRSS_CTL_400_DATA
+ DDRSS_CTL_401_DATA
+ DDRSS_CTL_402_DATA
+ DDRSS_CTL_403_DATA
+ DDRSS_CTL_404_DATA
+ DDRSS_CTL_405_DATA
+ DDRSS_CTL_406_DATA
+ DDRSS_CTL_407_DATA
+ DDRSS_CTL_408_DATA
+ DDRSS_CTL_409_DATA
+ DDRSS_CTL_410_DATA
+ DDRSS_CTL_411_DATA
+ DDRSS_CTL_412_DATA
+ DDRSS_CTL_413_DATA
+ DDRSS_CTL_414_DATA
+ DDRSS_CTL_415_DATA
+ DDRSS_CTL_416_DATA
+ DDRSS_CTL_417_DATA
+ DDRSS_CTL_418_DATA
+ DDRSS_CTL_419_DATA
+ DDRSS_CTL_420_DATA
+ DDRSS_CTL_421_DATA
+ DDRSS_CTL_422_DATA
+ DDRSS_CTL_423_DATA
+ DDRSS_CTL_424_DATA
+ DDRSS_CTL_425_DATA
+ DDRSS_CTL_426_DATA
+ DDRSS_CTL_427_DATA
+ DDRSS_CTL_428_DATA
+ DDRSS_CTL_429_DATA
+ DDRSS_CTL_430_DATA
+ DDRSS_CTL_431_DATA
+ DDRSS_CTL_432_DATA
+ DDRSS_CTL_433_DATA
+ DDRSS_CTL_434_DATA
+ DDRSS_CTL_435_DATA
+ DDRSS_CTL_436_DATA
+ DDRSS_CTL_437_DATA
+ DDRSS_CTL_438_DATA
+ DDRSS_CTL_439_DATA
+ DDRSS_CTL_440_DATA
+ DDRSS_CTL_441_DATA
+ DDRSS_CTL_442_DATA
+ DDRSS_CTL_443_DATA
+ DDRSS_CTL_444_DATA
+ DDRSS_CTL_445_DATA
+ DDRSS_CTL_446_DATA
+ DDRSS_CTL_447_DATA
+ DDRSS_CTL_448_DATA
+ DDRSS_CTL_449_DATA
+ DDRSS_CTL_450_DATA
+ DDRSS_CTL_451_DATA
+ DDRSS_CTL_452_DATA
+ DDRSS_CTL_453_DATA
+ DDRSS_CTL_454_DATA
+ DDRSS_CTL_455_DATA
+ DDRSS_CTL_456_DATA
+ DDRSS_CTL_457_DATA
+ DDRSS_CTL_458_DATA
+ >;
+
+ ti,pi-data = <
+ DDRSS_PI_00_DATA
+ DDRSS_PI_01_DATA
+ DDRSS_PI_02_DATA
+ DDRSS_PI_03_DATA
+ DDRSS_PI_04_DATA
+ DDRSS_PI_05_DATA
+ DDRSS_PI_06_DATA
+ DDRSS_PI_07_DATA
+ DDRSS_PI_08_DATA
+ DDRSS_PI_09_DATA
+ DDRSS_PI_10_DATA
+ DDRSS_PI_11_DATA
+ DDRSS_PI_12_DATA
+ DDRSS_PI_13_DATA
+ DDRSS_PI_14_DATA
+ DDRSS_PI_15_DATA
+ DDRSS_PI_16_DATA
+ DDRSS_PI_17_DATA
+ DDRSS_PI_18_DATA
+ DDRSS_PI_19_DATA
+ DDRSS_PI_20_DATA
+ DDRSS_PI_21_DATA
+ DDRSS_PI_22_DATA
+ DDRSS_PI_23_DATA
+ DDRSS_PI_24_DATA
+ DDRSS_PI_25_DATA
+ DDRSS_PI_26_DATA
+ DDRSS_PI_27_DATA
+ DDRSS_PI_28_DATA
+ DDRSS_PI_29_DATA
+ DDRSS_PI_30_DATA
+ DDRSS_PI_31_DATA
+ DDRSS_PI_32_DATA
+ DDRSS_PI_33_DATA
+ DDRSS_PI_34_DATA
+ DDRSS_PI_35_DATA
+ DDRSS_PI_36_DATA
+ DDRSS_PI_37_DATA
+ DDRSS_PI_38_DATA
+ DDRSS_PI_39_DATA
+ DDRSS_PI_40_DATA
+ DDRSS_PI_41_DATA
+ DDRSS_PI_42_DATA
+ DDRSS_PI_43_DATA
+ DDRSS_PI_44_DATA
+ DDRSS_PI_45_DATA
+ DDRSS_PI_46_DATA
+ DDRSS_PI_47_DATA
+ DDRSS_PI_48_DATA
+ DDRSS_PI_49_DATA
+ DDRSS_PI_50_DATA
+ DDRSS_PI_51_DATA
+ DDRSS_PI_52_DATA
+ DDRSS_PI_53_DATA
+ DDRSS_PI_54_DATA
+ DDRSS_PI_55_DATA
+ DDRSS_PI_56_DATA
+ DDRSS_PI_57_DATA
+ DDRSS_PI_58_DATA
+ DDRSS_PI_59_DATA
+ DDRSS_PI_60_DATA
+ DDRSS_PI_61_DATA
+ DDRSS_PI_62_DATA
+ DDRSS_PI_63_DATA
+ DDRSS_PI_64_DATA
+ DDRSS_PI_65_DATA
+ DDRSS_PI_66_DATA
+ DDRSS_PI_67_DATA
+ DDRSS_PI_68_DATA
+ DDRSS_PI_69_DATA
+ DDRSS_PI_70_DATA
+ DDRSS_PI_71_DATA
+ DDRSS_PI_72_DATA
+ DDRSS_PI_73_DATA
+ DDRSS_PI_74_DATA
+ DDRSS_PI_75_DATA
+ DDRSS_PI_76_DATA
+ DDRSS_PI_77_DATA
+ DDRSS_PI_78_DATA
+ DDRSS_PI_79_DATA
+ DDRSS_PI_80_DATA
+ DDRSS_PI_81_DATA
+ DDRSS_PI_82_DATA
+ DDRSS_PI_83_DATA
+ DDRSS_PI_84_DATA
+ DDRSS_PI_85_DATA
+ DDRSS_PI_86_DATA
+ DDRSS_PI_87_DATA
+ DDRSS_PI_88_DATA
+ DDRSS_PI_89_DATA
+ DDRSS_PI_90_DATA
+ DDRSS_PI_91_DATA
+ DDRSS_PI_92_DATA
+ DDRSS_PI_93_DATA
+ DDRSS_PI_94_DATA
+ DDRSS_PI_95_DATA
+ DDRSS_PI_96_DATA
+ DDRSS_PI_97_DATA
+ DDRSS_PI_98_DATA
+ DDRSS_PI_99_DATA
+ DDRSS_PI_100_DATA
+ DDRSS_PI_101_DATA
+ DDRSS_PI_102_DATA
+ DDRSS_PI_103_DATA
+ DDRSS_PI_104_DATA
+ DDRSS_PI_105_DATA
+ DDRSS_PI_106_DATA
+ DDRSS_PI_107_DATA
+ DDRSS_PI_108_DATA
+ DDRSS_PI_109_DATA
+ DDRSS_PI_110_DATA
+ DDRSS_PI_111_DATA
+ DDRSS_PI_112_DATA
+ DDRSS_PI_113_DATA
+ DDRSS_PI_114_DATA
+ DDRSS_PI_115_DATA
+ DDRSS_PI_116_DATA
+ DDRSS_PI_117_DATA
+ DDRSS_PI_118_DATA
+ DDRSS_PI_119_DATA
+ DDRSS_PI_120_DATA
+ DDRSS_PI_121_DATA
+ DDRSS_PI_122_DATA
+ DDRSS_PI_123_DATA
+ DDRSS_PI_124_DATA
+ DDRSS_PI_125_DATA
+ DDRSS_PI_126_DATA
+ DDRSS_PI_127_DATA
+ DDRSS_PI_128_DATA
+ DDRSS_PI_129_DATA
+ DDRSS_PI_130_DATA
+ DDRSS_PI_131_DATA
+ DDRSS_PI_132_DATA
+ DDRSS_PI_133_DATA
+ DDRSS_PI_134_DATA
+ DDRSS_PI_135_DATA
+ DDRSS_PI_136_DATA
+ DDRSS_PI_137_DATA
+ DDRSS_PI_138_DATA
+ DDRSS_PI_139_DATA
+ DDRSS_PI_140_DATA
+ DDRSS_PI_141_DATA
+ DDRSS_PI_142_DATA
+ DDRSS_PI_143_DATA
+ DDRSS_PI_144_DATA
+ DDRSS_PI_145_DATA
+ DDRSS_PI_146_DATA
+ DDRSS_PI_147_DATA
+ DDRSS_PI_148_DATA
+ DDRSS_PI_149_DATA
+ DDRSS_PI_150_DATA
+ DDRSS_PI_151_DATA
+ DDRSS_PI_152_DATA
+ DDRSS_PI_153_DATA
+ DDRSS_PI_154_DATA
+ DDRSS_PI_155_DATA
+ DDRSS_PI_156_DATA
+ DDRSS_PI_157_DATA
+ DDRSS_PI_158_DATA
+ DDRSS_PI_159_DATA
+ DDRSS_PI_160_DATA
+ DDRSS_PI_161_DATA
+ DDRSS_PI_162_DATA
+ DDRSS_PI_163_DATA
+ DDRSS_PI_164_DATA
+ DDRSS_PI_165_DATA
+ DDRSS_PI_166_DATA
+ DDRSS_PI_167_DATA
+ DDRSS_PI_168_DATA
+ DDRSS_PI_169_DATA
+ DDRSS_PI_170_DATA
+ DDRSS_PI_171_DATA
+ DDRSS_PI_172_DATA
+ DDRSS_PI_173_DATA
+ DDRSS_PI_174_DATA
+ DDRSS_PI_175_DATA
+ DDRSS_PI_176_DATA
+ DDRSS_PI_177_DATA
+ DDRSS_PI_178_DATA
+ DDRSS_PI_179_DATA
+ DDRSS_PI_180_DATA
+ DDRSS_PI_181_DATA
+ DDRSS_PI_182_DATA
+ DDRSS_PI_183_DATA
+ DDRSS_PI_184_DATA
+ DDRSS_PI_185_DATA
+ DDRSS_PI_186_DATA
+ DDRSS_PI_187_DATA
+ DDRSS_PI_188_DATA
+ DDRSS_PI_189_DATA
+ DDRSS_PI_190_DATA
+ DDRSS_PI_191_DATA
+ DDRSS_PI_192_DATA
+ DDRSS_PI_193_DATA
+ DDRSS_PI_194_DATA
+ DDRSS_PI_195_DATA
+ DDRSS_PI_196_DATA
+ DDRSS_PI_197_DATA
+ DDRSS_PI_198_DATA
+ DDRSS_PI_199_DATA
+ DDRSS_PI_200_DATA
+ DDRSS_PI_201_DATA
+ DDRSS_PI_202_DATA
+ DDRSS_PI_203_DATA
+ DDRSS_PI_204_DATA
+ DDRSS_PI_205_DATA
+ DDRSS_PI_206_DATA
+ DDRSS_PI_207_DATA
+ DDRSS_PI_208_DATA
+ DDRSS_PI_209_DATA
+ DDRSS_PI_210_DATA
+ DDRSS_PI_211_DATA
+ DDRSS_PI_212_DATA
+ DDRSS_PI_213_DATA
+ DDRSS_PI_214_DATA
+ DDRSS_PI_215_DATA
+ DDRSS_PI_216_DATA
+ DDRSS_PI_217_DATA
+ DDRSS_PI_218_DATA
+ DDRSS_PI_219_DATA
+ DDRSS_PI_220_DATA
+ DDRSS_PI_221_DATA
+ DDRSS_PI_222_DATA
+ DDRSS_PI_223_DATA
+ DDRSS_PI_224_DATA
+ DDRSS_PI_225_DATA
+ DDRSS_PI_226_DATA
+ DDRSS_PI_227_DATA
+ DDRSS_PI_228_DATA
+ DDRSS_PI_229_DATA
+ DDRSS_PI_230_DATA
+ DDRSS_PI_231_DATA
+ DDRSS_PI_232_DATA
+ DDRSS_PI_233_DATA
+ DDRSS_PI_234_DATA
+ DDRSS_PI_235_DATA
+ DDRSS_PI_236_DATA
+ DDRSS_PI_237_DATA
+ DDRSS_PI_238_DATA
+ DDRSS_PI_239_DATA
+ DDRSS_PI_240_DATA
+ DDRSS_PI_241_DATA
+ DDRSS_PI_242_DATA
+ DDRSS_PI_243_DATA
+ DDRSS_PI_244_DATA
+ DDRSS_PI_245_DATA
+ DDRSS_PI_246_DATA
+ DDRSS_PI_247_DATA
+ DDRSS_PI_248_DATA
+ DDRSS_PI_249_DATA
+ DDRSS_PI_250_DATA
+ DDRSS_PI_251_DATA
+ DDRSS_PI_252_DATA
+ DDRSS_PI_253_DATA
+ DDRSS_PI_254_DATA
+ DDRSS_PI_255_DATA
+ DDRSS_PI_256_DATA
+ DDRSS_PI_257_DATA
+ DDRSS_PI_258_DATA
+ DDRSS_PI_259_DATA
+ DDRSS_PI_260_DATA
+ DDRSS_PI_261_DATA
+ DDRSS_PI_262_DATA
+ DDRSS_PI_263_DATA
+ DDRSS_PI_264_DATA
+ DDRSS_PI_265_DATA
+ DDRSS_PI_266_DATA
+ DDRSS_PI_267_DATA
+ DDRSS_PI_268_DATA
+ DDRSS_PI_269_DATA
+ DDRSS_PI_270_DATA
+ DDRSS_PI_271_DATA
+ DDRSS_PI_272_DATA
+ DDRSS_PI_273_DATA
+ DDRSS_PI_274_DATA
+ DDRSS_PI_275_DATA
+ DDRSS_PI_276_DATA
+ DDRSS_PI_277_DATA
+ DDRSS_PI_278_DATA
+ DDRSS_PI_279_DATA
+ DDRSS_PI_280_DATA
+ DDRSS_PI_281_DATA
+ DDRSS_PI_282_DATA
+ DDRSS_PI_283_DATA
+ DDRSS_PI_284_DATA
+ DDRSS_PI_285_DATA
+ DDRSS_PI_286_DATA
+ DDRSS_PI_287_DATA
+ DDRSS_PI_288_DATA
+ DDRSS_PI_289_DATA
+ DDRSS_PI_290_DATA
+ DDRSS_PI_291_DATA
+ DDRSS_PI_292_DATA
+ DDRSS_PI_293_DATA
+ DDRSS_PI_294_DATA
+ DDRSS_PI_295_DATA
+ DDRSS_PI_296_DATA
+ DDRSS_PI_297_DATA
+ DDRSS_PI_298_DATA
+ DDRSS_PI_299_DATA
+ >;
+
+ ti,phy-data = <
+ DDRSS_PHY_00_DATA
+ DDRSS_PHY_01_DATA
+ DDRSS_PHY_02_DATA
+ DDRSS_PHY_03_DATA
+ DDRSS_PHY_04_DATA
+ DDRSS_PHY_05_DATA
+ DDRSS_PHY_06_DATA
+ DDRSS_PHY_07_DATA
+ DDRSS_PHY_08_DATA
+ DDRSS_PHY_09_DATA
+ DDRSS_PHY_10_DATA
+ DDRSS_PHY_11_DATA
+ DDRSS_PHY_12_DATA
+ DDRSS_PHY_13_DATA
+ DDRSS_PHY_14_DATA
+ DDRSS_PHY_15_DATA
+ DDRSS_PHY_16_DATA
+ DDRSS_PHY_17_DATA
+ DDRSS_PHY_18_DATA
+ DDRSS_PHY_19_DATA
+ DDRSS_PHY_20_DATA
+ DDRSS_PHY_21_DATA
+ DDRSS_PHY_22_DATA
+ DDRSS_PHY_23_DATA
+ DDRSS_PHY_24_DATA
+ DDRSS_PHY_25_DATA
+ DDRSS_PHY_26_DATA
+ DDRSS_PHY_27_DATA
+ DDRSS_PHY_28_DATA
+ DDRSS_PHY_29_DATA
+ DDRSS_PHY_30_DATA
+ DDRSS_PHY_31_DATA
+ DDRSS_PHY_32_DATA
+ DDRSS_PHY_33_DATA
+ DDRSS_PHY_34_DATA
+ DDRSS_PHY_35_DATA
+ DDRSS_PHY_36_DATA
+ DDRSS_PHY_37_DATA
+ DDRSS_PHY_38_DATA
+ DDRSS_PHY_39_DATA
+ DDRSS_PHY_40_DATA
+ DDRSS_PHY_41_DATA
+ DDRSS_PHY_42_DATA
+ DDRSS_PHY_43_DATA
+ DDRSS_PHY_44_DATA
+ DDRSS_PHY_45_DATA
+ DDRSS_PHY_46_DATA
+ DDRSS_PHY_47_DATA
+ DDRSS_PHY_48_DATA
+ DDRSS_PHY_49_DATA
+ DDRSS_PHY_50_DATA
+ DDRSS_PHY_51_DATA
+ DDRSS_PHY_52_DATA
+ DDRSS_PHY_53_DATA
+ DDRSS_PHY_54_DATA
+ DDRSS_PHY_55_DATA
+ DDRSS_PHY_56_DATA
+ DDRSS_PHY_57_DATA
+ DDRSS_PHY_58_DATA
+ DDRSS_PHY_59_DATA
+ DDRSS_PHY_60_DATA
+ DDRSS_PHY_61_DATA
+ DDRSS_PHY_62_DATA
+ DDRSS_PHY_63_DATA
+ DDRSS_PHY_64_DATA
+ DDRSS_PHY_65_DATA
+ DDRSS_PHY_66_DATA
+ DDRSS_PHY_67_DATA
+ DDRSS_PHY_68_DATA
+ DDRSS_PHY_69_DATA
+ DDRSS_PHY_70_DATA
+ DDRSS_PHY_71_DATA
+ DDRSS_PHY_72_DATA
+ DDRSS_PHY_73_DATA
+ DDRSS_PHY_74_DATA
+ DDRSS_PHY_75_DATA
+ DDRSS_PHY_76_DATA
+ DDRSS_PHY_77_DATA
+ DDRSS_PHY_78_DATA
+ DDRSS_PHY_79_DATA
+ DDRSS_PHY_80_DATA
+ DDRSS_PHY_81_DATA
+ DDRSS_PHY_82_DATA
+ DDRSS_PHY_83_DATA
+ DDRSS_PHY_84_DATA
+ DDRSS_PHY_85_DATA
+ DDRSS_PHY_86_DATA
+ DDRSS_PHY_87_DATA
+ DDRSS_PHY_88_DATA
+ DDRSS_PHY_89_DATA
+ DDRSS_PHY_90_DATA
+ DDRSS_PHY_91_DATA
+ DDRSS_PHY_92_DATA
+ DDRSS_PHY_93_DATA
+ DDRSS_PHY_94_DATA
+ DDRSS_PHY_95_DATA
+ DDRSS_PHY_96_DATA
+ DDRSS_PHY_97_DATA
+ DDRSS_PHY_98_DATA
+ DDRSS_PHY_99_DATA
+ DDRSS_PHY_100_DATA
+ DDRSS_PHY_101_DATA
+ DDRSS_PHY_102_DATA
+ DDRSS_PHY_103_DATA
+ DDRSS_PHY_104_DATA
+ DDRSS_PHY_105_DATA
+ DDRSS_PHY_106_DATA
+ DDRSS_PHY_107_DATA
+ DDRSS_PHY_108_DATA
+ DDRSS_PHY_109_DATA
+ DDRSS_PHY_110_DATA
+ DDRSS_PHY_111_DATA
+ DDRSS_PHY_112_DATA
+ DDRSS_PHY_113_DATA
+ DDRSS_PHY_114_DATA
+ DDRSS_PHY_115_DATA
+ DDRSS_PHY_116_DATA
+ DDRSS_PHY_117_DATA
+ DDRSS_PHY_118_DATA
+ DDRSS_PHY_119_DATA
+ DDRSS_PHY_120_DATA
+ DDRSS_PHY_121_DATA
+ DDRSS_PHY_122_DATA
+ DDRSS_PHY_123_DATA
+ DDRSS_PHY_124_DATA
+ DDRSS_PHY_125_DATA
+ DDRSS_PHY_126_DATA
+ DDRSS_PHY_127_DATA
+ DDRSS_PHY_128_DATA
+ DDRSS_PHY_129_DATA
+ DDRSS_PHY_130_DATA
+ DDRSS_PHY_131_DATA
+ DDRSS_PHY_132_DATA
+ DDRSS_PHY_133_DATA
+ DDRSS_PHY_134_DATA
+ DDRSS_PHY_135_DATA
+ DDRSS_PHY_136_DATA
+ DDRSS_PHY_137_DATA
+ DDRSS_PHY_138_DATA
+ DDRSS_PHY_139_DATA
+ DDRSS_PHY_140_DATA
+ DDRSS_PHY_141_DATA
+ DDRSS_PHY_142_DATA
+ DDRSS_PHY_143_DATA
+ DDRSS_PHY_144_DATA
+ DDRSS_PHY_145_DATA
+ DDRSS_PHY_146_DATA
+ DDRSS_PHY_147_DATA
+ DDRSS_PHY_148_DATA
+ DDRSS_PHY_149_DATA
+ DDRSS_PHY_150_DATA
+ DDRSS_PHY_151_DATA
+ DDRSS_PHY_152_DATA
+ DDRSS_PHY_153_DATA
+ DDRSS_PHY_154_DATA
+ DDRSS_PHY_155_DATA
+ DDRSS_PHY_156_DATA
+ DDRSS_PHY_157_DATA
+ DDRSS_PHY_158_DATA
+ DDRSS_PHY_159_DATA
+ DDRSS_PHY_160_DATA
+ DDRSS_PHY_161_DATA
+ DDRSS_PHY_162_DATA
+ DDRSS_PHY_163_DATA
+ DDRSS_PHY_164_DATA
+ DDRSS_PHY_165_DATA
+ DDRSS_PHY_166_DATA
+ DDRSS_PHY_167_DATA
+ DDRSS_PHY_168_DATA
+ DDRSS_PHY_169_DATA
+ DDRSS_PHY_170_DATA
+ DDRSS_PHY_171_DATA
+ DDRSS_PHY_172_DATA
+ DDRSS_PHY_173_DATA
+ DDRSS_PHY_174_DATA
+ DDRSS_PHY_175_DATA
+ DDRSS_PHY_176_DATA
+ DDRSS_PHY_177_DATA
+ DDRSS_PHY_178_DATA
+ DDRSS_PHY_179_DATA
+ DDRSS_PHY_180_DATA
+ DDRSS_PHY_181_DATA
+ DDRSS_PHY_182_DATA
+ DDRSS_PHY_183_DATA
+ DDRSS_PHY_184_DATA
+ DDRSS_PHY_185_DATA
+ DDRSS_PHY_186_DATA
+ DDRSS_PHY_187_DATA
+ DDRSS_PHY_188_DATA
+ DDRSS_PHY_189_DATA
+ DDRSS_PHY_190_DATA
+ DDRSS_PHY_191_DATA
+ DDRSS_PHY_192_DATA
+ DDRSS_PHY_193_DATA
+ DDRSS_PHY_194_DATA
+ DDRSS_PHY_195_DATA
+ DDRSS_PHY_196_DATA
+ DDRSS_PHY_197_DATA
+ DDRSS_PHY_198_DATA
+ DDRSS_PHY_199_DATA
+ DDRSS_PHY_200_DATA
+ DDRSS_PHY_201_DATA
+ DDRSS_PHY_202_DATA
+ DDRSS_PHY_203_DATA
+ DDRSS_PHY_204_DATA
+ DDRSS_PHY_205_DATA
+ DDRSS_PHY_206_DATA
+ DDRSS_PHY_207_DATA
+ DDRSS_PHY_208_DATA
+ DDRSS_PHY_209_DATA
+ DDRSS_PHY_210_DATA
+ DDRSS_PHY_211_DATA
+ DDRSS_PHY_212_DATA
+ DDRSS_PHY_213_DATA
+ DDRSS_PHY_214_DATA
+ DDRSS_PHY_215_DATA
+ DDRSS_PHY_216_DATA
+ DDRSS_PHY_217_DATA
+ DDRSS_PHY_218_DATA
+ DDRSS_PHY_219_DATA
+ DDRSS_PHY_220_DATA
+ DDRSS_PHY_221_DATA
+ DDRSS_PHY_222_DATA
+ DDRSS_PHY_223_DATA
+ DDRSS_PHY_224_DATA
+ DDRSS_PHY_225_DATA
+ DDRSS_PHY_226_DATA
+ DDRSS_PHY_227_DATA
+ DDRSS_PHY_228_DATA
+ DDRSS_PHY_229_DATA
+ DDRSS_PHY_230_DATA
+ DDRSS_PHY_231_DATA
+ DDRSS_PHY_232_DATA
+ DDRSS_PHY_233_DATA
+ DDRSS_PHY_234_DATA
+ DDRSS_PHY_235_DATA
+ DDRSS_PHY_236_DATA
+ DDRSS_PHY_237_DATA
+ DDRSS_PHY_238_DATA
+ DDRSS_PHY_239_DATA
+ DDRSS_PHY_240_DATA
+ DDRSS_PHY_241_DATA
+ DDRSS_PHY_242_DATA
+ DDRSS_PHY_243_DATA
+ DDRSS_PHY_244_DATA
+ DDRSS_PHY_245_DATA
+ DDRSS_PHY_246_DATA
+ DDRSS_PHY_247_DATA
+ DDRSS_PHY_248_DATA
+ DDRSS_PHY_249_DATA
+ DDRSS_PHY_250_DATA
+ DDRSS_PHY_251_DATA
+ DDRSS_PHY_252_DATA
+ DDRSS_PHY_253_DATA
+ DDRSS_PHY_254_DATA
+ DDRSS_PHY_255_DATA
+ DDRSS_PHY_256_DATA
+ DDRSS_PHY_257_DATA
+ DDRSS_PHY_258_DATA
+ DDRSS_PHY_259_DATA
+ DDRSS_PHY_260_DATA
+ DDRSS_PHY_261_DATA
+ DDRSS_PHY_262_DATA
+ DDRSS_PHY_263_DATA
+ DDRSS_PHY_264_DATA
+ DDRSS_PHY_265_DATA
+ DDRSS_PHY_266_DATA
+ DDRSS_PHY_267_DATA
+ DDRSS_PHY_268_DATA
+ DDRSS_PHY_269_DATA
+ DDRSS_PHY_270_DATA
+ DDRSS_PHY_271_DATA
+ DDRSS_PHY_272_DATA
+ DDRSS_PHY_273_DATA
+ DDRSS_PHY_274_DATA
+ DDRSS_PHY_275_DATA
+ DDRSS_PHY_276_DATA
+ DDRSS_PHY_277_DATA
+ DDRSS_PHY_278_DATA
+ DDRSS_PHY_279_DATA
+ DDRSS_PHY_280_DATA
+ DDRSS_PHY_281_DATA
+ DDRSS_PHY_282_DATA
+ DDRSS_PHY_283_DATA
+ DDRSS_PHY_284_DATA
+ DDRSS_PHY_285_DATA
+ DDRSS_PHY_286_DATA
+ DDRSS_PHY_287_DATA
+ DDRSS_PHY_288_DATA
+ DDRSS_PHY_289_DATA
+ DDRSS_PHY_290_DATA
+ DDRSS_PHY_291_DATA
+ DDRSS_PHY_292_DATA
+ DDRSS_PHY_293_DATA
+ DDRSS_PHY_294_DATA
+ DDRSS_PHY_295_DATA
+ DDRSS_PHY_296_DATA
+ DDRSS_PHY_297_DATA
+ DDRSS_PHY_298_DATA
+ DDRSS_PHY_299_DATA
+ DDRSS_PHY_300_DATA
+ DDRSS_PHY_301_DATA
+ DDRSS_PHY_302_DATA
+ DDRSS_PHY_303_DATA
+ DDRSS_PHY_304_DATA
+ DDRSS_PHY_305_DATA
+ DDRSS_PHY_306_DATA
+ DDRSS_PHY_307_DATA
+ DDRSS_PHY_308_DATA
+ DDRSS_PHY_309_DATA
+ DDRSS_PHY_310_DATA
+ DDRSS_PHY_311_DATA
+ DDRSS_PHY_312_DATA
+ DDRSS_PHY_313_DATA
+ DDRSS_PHY_314_DATA
+ DDRSS_PHY_315_DATA
+ DDRSS_PHY_316_DATA
+ DDRSS_PHY_317_DATA
+ DDRSS_PHY_318_DATA
+ DDRSS_PHY_319_DATA
+ DDRSS_PHY_320_DATA
+ DDRSS_PHY_321_DATA
+ DDRSS_PHY_322_DATA
+ DDRSS_PHY_323_DATA
+ DDRSS_PHY_324_DATA
+ DDRSS_PHY_325_DATA
+ DDRSS_PHY_326_DATA
+ DDRSS_PHY_327_DATA
+ DDRSS_PHY_328_DATA
+ DDRSS_PHY_329_DATA
+ DDRSS_PHY_330_DATA
+ DDRSS_PHY_331_DATA
+ DDRSS_PHY_332_DATA
+ DDRSS_PHY_333_DATA
+ DDRSS_PHY_334_DATA
+ DDRSS_PHY_335_DATA
+ DDRSS_PHY_336_DATA
+ DDRSS_PHY_337_DATA
+ DDRSS_PHY_338_DATA
+ DDRSS_PHY_339_DATA
+ DDRSS_PHY_340_DATA
+ DDRSS_PHY_341_DATA
+ DDRSS_PHY_342_DATA
+ DDRSS_PHY_343_DATA
+ DDRSS_PHY_344_DATA
+ DDRSS_PHY_345_DATA
+ DDRSS_PHY_346_DATA
+ DDRSS_PHY_347_DATA
+ DDRSS_PHY_348_DATA
+ DDRSS_PHY_349_DATA
+ DDRSS_PHY_350_DATA
+ DDRSS_PHY_351_DATA
+ DDRSS_PHY_352_DATA
+ DDRSS_PHY_353_DATA
+ DDRSS_PHY_354_DATA
+ DDRSS_PHY_355_DATA
+ DDRSS_PHY_356_DATA
+ DDRSS_PHY_357_DATA
+ DDRSS_PHY_358_DATA
+ DDRSS_PHY_359_DATA
+ DDRSS_PHY_360_DATA
+ DDRSS_PHY_361_DATA
+ DDRSS_PHY_362_DATA
+ DDRSS_PHY_363_DATA
+ DDRSS_PHY_364_DATA
+ DDRSS_PHY_365_DATA
+ DDRSS_PHY_366_DATA
+ DDRSS_PHY_367_DATA
+ DDRSS_PHY_368_DATA
+ DDRSS_PHY_369_DATA
+ DDRSS_PHY_370_DATA
+ DDRSS_PHY_371_DATA
+ DDRSS_PHY_372_DATA
+ DDRSS_PHY_373_DATA
+ DDRSS_PHY_374_DATA
+ DDRSS_PHY_375_DATA
+ DDRSS_PHY_376_DATA
+ DDRSS_PHY_377_DATA
+ DDRSS_PHY_378_DATA
+ DDRSS_PHY_379_DATA
+ DDRSS_PHY_380_DATA
+ DDRSS_PHY_381_DATA
+ DDRSS_PHY_382_DATA
+ DDRSS_PHY_383_DATA
+ DDRSS_PHY_384_DATA
+ DDRSS_PHY_385_DATA
+ DDRSS_PHY_386_DATA
+ DDRSS_PHY_387_DATA
+ DDRSS_PHY_388_DATA
+ DDRSS_PHY_389_DATA
+ DDRSS_PHY_390_DATA
+ DDRSS_PHY_391_DATA
+ DDRSS_PHY_392_DATA
+ DDRSS_PHY_393_DATA
+ DDRSS_PHY_394_DATA
+ DDRSS_PHY_395_DATA
+ DDRSS_PHY_396_DATA
+ DDRSS_PHY_397_DATA
+ DDRSS_PHY_398_DATA
+ DDRSS_PHY_399_DATA
+ DDRSS_PHY_400_DATA
+ DDRSS_PHY_401_DATA
+ DDRSS_PHY_402_DATA
+ DDRSS_PHY_403_DATA
+ DDRSS_PHY_404_DATA
+ DDRSS_PHY_405_DATA
+ DDRSS_PHY_406_DATA
+ DDRSS_PHY_407_DATA
+ DDRSS_PHY_408_DATA
+ DDRSS_PHY_409_DATA
+ DDRSS_PHY_410_DATA
+ DDRSS_PHY_411_DATA
+ DDRSS_PHY_412_DATA
+ DDRSS_PHY_413_DATA
+ DDRSS_PHY_414_DATA
+ DDRSS_PHY_415_DATA
+ DDRSS_PHY_416_DATA
+ DDRSS_PHY_417_DATA
+ DDRSS_PHY_418_DATA
+ DDRSS_PHY_419_DATA
+ DDRSS_PHY_420_DATA
+ DDRSS_PHY_421_DATA
+ DDRSS_PHY_422_DATA
+ DDRSS_PHY_423_DATA
+ DDRSS_PHY_424_DATA
+ DDRSS_PHY_425_DATA
+ DDRSS_PHY_426_DATA
+ DDRSS_PHY_427_DATA
+ DDRSS_PHY_428_DATA
+ DDRSS_PHY_429_DATA
+ DDRSS_PHY_430_DATA
+ DDRSS_PHY_431_DATA
+ DDRSS_PHY_432_DATA
+ DDRSS_PHY_433_DATA
+ DDRSS_PHY_434_DATA
+ DDRSS_PHY_435_DATA
+ DDRSS_PHY_436_DATA
+ DDRSS_PHY_437_DATA
+ DDRSS_PHY_438_DATA
+ DDRSS_PHY_439_DATA
+ DDRSS_PHY_440_DATA
+ DDRSS_PHY_441_DATA
+ DDRSS_PHY_442_DATA
+ DDRSS_PHY_443_DATA
+ DDRSS_PHY_444_DATA
+ DDRSS_PHY_445_DATA
+ DDRSS_PHY_446_DATA
+ DDRSS_PHY_447_DATA
+ DDRSS_PHY_448_DATA
+ DDRSS_PHY_449_DATA
+ DDRSS_PHY_450_DATA
+ DDRSS_PHY_451_DATA
+ DDRSS_PHY_452_DATA
+ DDRSS_PHY_453_DATA
+ DDRSS_PHY_454_DATA
+ DDRSS_PHY_455_DATA
+ DDRSS_PHY_456_DATA
+ DDRSS_PHY_457_DATA
+ DDRSS_PHY_458_DATA
+ DDRSS_PHY_459_DATA
+ DDRSS_PHY_460_DATA
+ DDRSS_PHY_461_DATA
+ DDRSS_PHY_462_DATA
+ DDRSS_PHY_463_DATA
+ DDRSS_PHY_464_DATA
+ DDRSS_PHY_465_DATA
+ DDRSS_PHY_466_DATA
+ DDRSS_PHY_467_DATA
+ DDRSS_PHY_468_DATA
+ DDRSS_PHY_469_DATA
+ DDRSS_PHY_470_DATA
+ DDRSS_PHY_471_DATA
+ DDRSS_PHY_472_DATA
+ DDRSS_PHY_473_DATA
+ DDRSS_PHY_474_DATA
+ DDRSS_PHY_475_DATA
+ DDRSS_PHY_476_DATA
+ DDRSS_PHY_477_DATA
+ DDRSS_PHY_478_DATA
+ DDRSS_PHY_479_DATA
+ DDRSS_PHY_480_DATA
+ DDRSS_PHY_481_DATA
+ DDRSS_PHY_482_DATA
+ DDRSS_PHY_483_DATA
+ DDRSS_PHY_484_DATA
+ DDRSS_PHY_485_DATA
+ DDRSS_PHY_486_DATA
+ DDRSS_PHY_487_DATA
+ DDRSS_PHY_488_DATA
+ DDRSS_PHY_489_DATA
+ DDRSS_PHY_490_DATA
+ DDRSS_PHY_491_DATA
+ DDRSS_PHY_492_DATA
+ DDRSS_PHY_493_DATA
+ DDRSS_PHY_494_DATA
+ DDRSS_PHY_495_DATA
+ DDRSS_PHY_496_DATA
+ DDRSS_PHY_497_DATA
+ DDRSS_PHY_498_DATA
+ DDRSS_PHY_499_DATA
+ DDRSS_PHY_500_DATA
+ DDRSS_PHY_501_DATA
+ DDRSS_PHY_502_DATA
+ DDRSS_PHY_503_DATA
+ DDRSS_PHY_504_DATA
+ DDRSS_PHY_505_DATA
+ DDRSS_PHY_506_DATA
+ DDRSS_PHY_507_DATA
+ DDRSS_PHY_508_DATA
+ DDRSS_PHY_509_DATA
+ DDRSS_PHY_510_DATA
+ DDRSS_PHY_511_DATA
+ DDRSS_PHY_512_DATA
+ DDRSS_PHY_513_DATA
+ DDRSS_PHY_514_DATA
+ DDRSS_PHY_515_DATA
+ DDRSS_PHY_516_DATA
+ DDRSS_PHY_517_DATA
+ DDRSS_PHY_518_DATA
+ DDRSS_PHY_519_DATA
+ DDRSS_PHY_520_DATA
+ DDRSS_PHY_521_DATA
+ DDRSS_PHY_522_DATA
+ DDRSS_PHY_523_DATA
+ DDRSS_PHY_524_DATA
+ DDRSS_PHY_525_DATA
+ DDRSS_PHY_526_DATA
+ DDRSS_PHY_527_DATA
+ DDRSS_PHY_528_DATA
+ DDRSS_PHY_529_DATA
+ DDRSS_PHY_530_DATA
+ DDRSS_PHY_531_DATA
+ DDRSS_PHY_532_DATA
+ DDRSS_PHY_533_DATA
+ DDRSS_PHY_534_DATA
+ DDRSS_PHY_535_DATA
+ DDRSS_PHY_536_DATA
+ DDRSS_PHY_537_DATA
+ DDRSS_PHY_538_DATA
+ DDRSS_PHY_539_DATA
+ DDRSS_PHY_540_DATA
+ DDRSS_PHY_541_DATA
+ DDRSS_PHY_542_DATA
+ DDRSS_PHY_543_DATA
+ DDRSS_PHY_544_DATA
+ DDRSS_PHY_545_DATA
+ DDRSS_PHY_546_DATA
+ DDRSS_PHY_547_DATA
+ DDRSS_PHY_548_DATA
+ DDRSS_PHY_549_DATA
+ DDRSS_PHY_550_DATA
+ DDRSS_PHY_551_DATA
+ DDRSS_PHY_552_DATA
+ DDRSS_PHY_553_DATA
+ DDRSS_PHY_554_DATA
+ DDRSS_PHY_555_DATA
+ DDRSS_PHY_556_DATA
+ DDRSS_PHY_557_DATA
+ DDRSS_PHY_558_DATA
+ DDRSS_PHY_559_DATA
+ DDRSS_PHY_560_DATA
+ DDRSS_PHY_561_DATA
+ DDRSS_PHY_562_DATA
+ DDRSS_PHY_563_DATA
+ DDRSS_PHY_564_DATA
+ DDRSS_PHY_565_DATA
+ DDRSS_PHY_566_DATA
+ DDRSS_PHY_567_DATA
+ DDRSS_PHY_568_DATA
+ DDRSS_PHY_569_DATA
+ DDRSS_PHY_570_DATA
+ DDRSS_PHY_571_DATA
+ DDRSS_PHY_572_DATA
+ DDRSS_PHY_573_DATA
+ DDRSS_PHY_574_DATA
+ DDRSS_PHY_575_DATA
+ DDRSS_PHY_576_DATA
+ DDRSS_PHY_577_DATA
+ DDRSS_PHY_578_DATA
+ DDRSS_PHY_579_DATA
+ DDRSS_PHY_580_DATA
+ DDRSS_PHY_581_DATA
+ DDRSS_PHY_582_DATA
+ DDRSS_PHY_583_DATA
+ DDRSS_PHY_584_DATA
+ DDRSS_PHY_585_DATA
+ DDRSS_PHY_586_DATA
+ DDRSS_PHY_587_DATA
+ DDRSS_PHY_588_DATA
+ DDRSS_PHY_589_DATA
+ DDRSS_PHY_590_DATA
+ DDRSS_PHY_591_DATA
+ DDRSS_PHY_592_DATA
+ DDRSS_PHY_593_DATA
+ DDRSS_PHY_594_DATA
+ DDRSS_PHY_595_DATA
+ DDRSS_PHY_596_DATA
+ DDRSS_PHY_597_DATA
+ DDRSS_PHY_598_DATA
+ DDRSS_PHY_599_DATA
+ DDRSS_PHY_600_DATA
+ DDRSS_PHY_601_DATA
+ DDRSS_PHY_602_DATA
+ DDRSS_PHY_603_DATA
+ DDRSS_PHY_604_DATA
+ DDRSS_PHY_605_DATA
+ DDRSS_PHY_606_DATA
+ DDRSS_PHY_607_DATA
+ DDRSS_PHY_608_DATA
+ DDRSS_PHY_609_DATA
+ DDRSS_PHY_610_DATA
+ DDRSS_PHY_611_DATA
+ DDRSS_PHY_612_DATA
+ DDRSS_PHY_613_DATA
+ DDRSS_PHY_614_DATA
+ DDRSS_PHY_615_DATA
+ DDRSS_PHY_616_DATA
+ DDRSS_PHY_617_DATA
+ DDRSS_PHY_618_DATA
+ DDRSS_PHY_619_DATA
+ DDRSS_PHY_620_DATA
+ DDRSS_PHY_621_DATA
+ DDRSS_PHY_622_DATA
+ DDRSS_PHY_623_DATA
+ DDRSS_PHY_624_DATA
+ DDRSS_PHY_625_DATA
+ DDRSS_PHY_626_DATA
+ DDRSS_PHY_627_DATA
+ DDRSS_PHY_628_DATA
+ DDRSS_PHY_629_DATA
+ DDRSS_PHY_630_DATA
+ DDRSS_PHY_631_DATA
+ DDRSS_PHY_632_DATA
+ DDRSS_PHY_633_DATA
+ DDRSS_PHY_634_DATA
+ DDRSS_PHY_635_DATA
+ DDRSS_PHY_636_DATA
+ DDRSS_PHY_637_DATA
+ DDRSS_PHY_638_DATA
+ DDRSS_PHY_639_DATA
+ DDRSS_PHY_640_DATA
+ DDRSS_PHY_641_DATA
+ DDRSS_PHY_642_DATA
+ DDRSS_PHY_643_DATA
+ DDRSS_PHY_644_DATA
+ DDRSS_PHY_645_DATA
+ DDRSS_PHY_646_DATA
+ DDRSS_PHY_647_DATA
+ DDRSS_PHY_648_DATA
+ DDRSS_PHY_649_DATA
+ DDRSS_PHY_650_DATA
+ DDRSS_PHY_651_DATA
+ DDRSS_PHY_652_DATA
+ DDRSS_PHY_653_DATA
+ DDRSS_PHY_654_DATA
+ DDRSS_PHY_655_DATA
+ DDRSS_PHY_656_DATA
+ DDRSS_PHY_657_DATA
+ DDRSS_PHY_658_DATA
+ DDRSS_PHY_659_DATA
+ DDRSS_PHY_660_DATA
+ DDRSS_PHY_661_DATA
+ DDRSS_PHY_662_DATA
+ DDRSS_PHY_663_DATA
+ DDRSS_PHY_664_DATA
+ DDRSS_PHY_665_DATA
+ DDRSS_PHY_666_DATA
+ DDRSS_PHY_667_DATA
+ DDRSS_PHY_668_DATA
+ DDRSS_PHY_669_DATA
+ DDRSS_PHY_670_DATA
+ DDRSS_PHY_671_DATA
+ DDRSS_PHY_672_DATA
+ DDRSS_PHY_673_DATA
+ DDRSS_PHY_674_DATA
+ DDRSS_PHY_675_DATA
+ DDRSS_PHY_676_DATA
+ DDRSS_PHY_677_DATA
+ DDRSS_PHY_678_DATA
+ DDRSS_PHY_679_DATA
+ DDRSS_PHY_680_DATA
+ DDRSS_PHY_681_DATA
+ DDRSS_PHY_682_DATA
+ DDRSS_PHY_683_DATA
+ DDRSS_PHY_684_DATA
+ DDRSS_PHY_685_DATA
+ DDRSS_PHY_686_DATA
+ DDRSS_PHY_687_DATA
+ DDRSS_PHY_688_DATA
+ DDRSS_PHY_689_DATA
+ DDRSS_PHY_690_DATA
+ DDRSS_PHY_691_DATA
+ DDRSS_PHY_692_DATA
+ DDRSS_PHY_693_DATA
+ DDRSS_PHY_694_DATA
+ DDRSS_PHY_695_DATA
+ DDRSS_PHY_696_DATA
+ DDRSS_PHY_697_DATA
+ DDRSS_PHY_698_DATA
+ DDRSS_PHY_699_DATA
+ DDRSS_PHY_700_DATA
+ DDRSS_PHY_701_DATA
+ DDRSS_PHY_702_DATA
+ DDRSS_PHY_703_DATA
+ DDRSS_PHY_704_DATA
+ DDRSS_PHY_705_DATA
+ DDRSS_PHY_706_DATA
+ DDRSS_PHY_707_DATA
+ DDRSS_PHY_708_DATA
+ DDRSS_PHY_709_DATA
+ DDRSS_PHY_710_DATA
+ DDRSS_PHY_711_DATA
+ DDRSS_PHY_712_DATA
+ DDRSS_PHY_713_DATA
+ DDRSS_PHY_714_DATA
+ DDRSS_PHY_715_DATA
+ DDRSS_PHY_716_DATA
+ DDRSS_PHY_717_DATA
+ DDRSS_PHY_718_DATA
+ DDRSS_PHY_719_DATA
+ DDRSS_PHY_720_DATA
+ DDRSS_PHY_721_DATA
+ DDRSS_PHY_722_DATA
+ DDRSS_PHY_723_DATA
+ DDRSS_PHY_724_DATA
+ DDRSS_PHY_725_DATA
+ DDRSS_PHY_726_DATA
+ DDRSS_PHY_727_DATA
+ DDRSS_PHY_728_DATA
+ DDRSS_PHY_729_DATA
+ DDRSS_PHY_730_DATA
+ DDRSS_PHY_731_DATA
+ DDRSS_PHY_732_DATA
+ DDRSS_PHY_733_DATA
+ DDRSS_PHY_734_DATA
+ DDRSS_PHY_735_DATA
+ DDRSS_PHY_736_DATA
+ DDRSS_PHY_737_DATA
+ DDRSS_PHY_738_DATA
+ DDRSS_PHY_739_DATA
+ DDRSS_PHY_740_DATA
+ DDRSS_PHY_741_DATA
+ DDRSS_PHY_742_DATA
+ DDRSS_PHY_743_DATA
+ DDRSS_PHY_744_DATA
+ DDRSS_PHY_745_DATA
+ DDRSS_PHY_746_DATA
+ DDRSS_PHY_747_DATA
+ DDRSS_PHY_748_DATA
+ DDRSS_PHY_749_DATA
+ DDRSS_PHY_750_DATA
+ DDRSS_PHY_751_DATA
+ DDRSS_PHY_752_DATA
+ DDRSS_PHY_753_DATA
+ DDRSS_PHY_754_DATA
+ DDRSS_PHY_755_DATA
+ DDRSS_PHY_756_DATA
+ DDRSS_PHY_757_DATA
+ DDRSS_PHY_758_DATA
+ DDRSS_PHY_759_DATA
+ DDRSS_PHY_760_DATA
+ DDRSS_PHY_761_DATA
+ DDRSS_PHY_762_DATA
+ DDRSS_PHY_763_DATA
+ DDRSS_PHY_764_DATA
+ DDRSS_PHY_765_DATA
+ DDRSS_PHY_766_DATA
+ DDRSS_PHY_767_DATA
+ DDRSS_PHY_768_DATA
+ DDRSS_PHY_769_DATA
+ DDRSS_PHY_770_DATA
+ DDRSS_PHY_771_DATA
+ DDRSS_PHY_772_DATA
+ DDRSS_PHY_773_DATA
+ DDRSS_PHY_774_DATA
+ DDRSS_PHY_775_DATA
+ DDRSS_PHY_776_DATA
+ DDRSS_PHY_777_DATA
+ DDRSS_PHY_778_DATA
+ DDRSS_PHY_779_DATA
+ DDRSS_PHY_780_DATA
+ DDRSS_PHY_781_DATA
+ DDRSS_PHY_782_DATA
+ DDRSS_PHY_783_DATA
+ DDRSS_PHY_784_DATA
+ DDRSS_PHY_785_DATA
+ DDRSS_PHY_786_DATA
+ DDRSS_PHY_787_DATA
+ DDRSS_PHY_788_DATA
+ DDRSS_PHY_789_DATA
+ DDRSS_PHY_790_DATA
+ DDRSS_PHY_791_DATA
+ DDRSS_PHY_792_DATA
+ DDRSS_PHY_793_DATA
+ DDRSS_PHY_794_DATA
+ DDRSS_PHY_795_DATA
+ DDRSS_PHY_796_DATA
+ DDRSS_PHY_797_DATA
+ DDRSS_PHY_798_DATA
+ DDRSS_PHY_799_DATA
+ DDRSS_PHY_800_DATA
+ DDRSS_PHY_801_DATA
+ DDRSS_PHY_802_DATA
+ DDRSS_PHY_803_DATA
+ DDRSS_PHY_804_DATA
+ DDRSS_PHY_805_DATA
+ DDRSS_PHY_806_DATA
+ DDRSS_PHY_807_DATA
+ DDRSS_PHY_808_DATA
+ DDRSS_PHY_809_DATA
+ DDRSS_PHY_810_DATA
+ DDRSS_PHY_811_DATA
+ DDRSS_PHY_812_DATA
+ DDRSS_PHY_813_DATA
+ DDRSS_PHY_814_DATA
+ DDRSS_PHY_815_DATA
+ DDRSS_PHY_816_DATA
+ DDRSS_PHY_817_DATA
+ DDRSS_PHY_818_DATA
+ DDRSS_PHY_819_DATA
+ DDRSS_PHY_820_DATA
+ DDRSS_PHY_821_DATA
+ DDRSS_PHY_822_DATA
+ DDRSS_PHY_823_DATA
+ DDRSS_PHY_824_DATA
+ DDRSS_PHY_825_DATA
+ DDRSS_PHY_826_DATA
+ DDRSS_PHY_827_DATA
+ DDRSS_PHY_828_DATA
+ DDRSS_PHY_829_DATA
+ DDRSS_PHY_830_DATA
+ DDRSS_PHY_831_DATA
+ DDRSS_PHY_832_DATA
+ DDRSS_PHY_833_DATA
+ DDRSS_PHY_834_DATA
+ DDRSS_PHY_835_DATA
+ DDRSS_PHY_836_DATA
+ DDRSS_PHY_837_DATA
+ DDRSS_PHY_838_DATA
+ DDRSS_PHY_839_DATA
+ DDRSS_PHY_840_DATA
+ DDRSS_PHY_841_DATA
+ DDRSS_PHY_842_DATA
+ DDRSS_PHY_843_DATA
+ DDRSS_PHY_844_DATA
+ DDRSS_PHY_845_DATA
+ DDRSS_PHY_846_DATA
+ DDRSS_PHY_847_DATA
+ DDRSS_PHY_848_DATA
+ DDRSS_PHY_849_DATA
+ DDRSS_PHY_850_DATA
+ DDRSS_PHY_851_DATA
+ DDRSS_PHY_852_DATA
+ DDRSS_PHY_853_DATA
+ DDRSS_PHY_854_DATA
+ DDRSS_PHY_855_DATA
+ DDRSS_PHY_856_DATA
+ DDRSS_PHY_857_DATA
+ DDRSS_PHY_858_DATA
+ DDRSS_PHY_859_DATA
+ DDRSS_PHY_860_DATA
+ DDRSS_PHY_861_DATA
+ DDRSS_PHY_862_DATA
+ DDRSS_PHY_863_DATA
+ DDRSS_PHY_864_DATA
+ DDRSS_PHY_865_DATA
+ DDRSS_PHY_866_DATA
+ DDRSS_PHY_867_DATA
+ DDRSS_PHY_868_DATA
+ DDRSS_PHY_869_DATA
+ DDRSS_PHY_870_DATA
+ DDRSS_PHY_871_DATA
+ DDRSS_PHY_872_DATA
+ DDRSS_PHY_873_DATA
+ DDRSS_PHY_874_DATA
+ DDRSS_PHY_875_DATA
+ DDRSS_PHY_876_DATA
+ DDRSS_PHY_877_DATA
+ DDRSS_PHY_878_DATA
+ DDRSS_PHY_879_DATA
+ DDRSS_PHY_880_DATA
+ DDRSS_PHY_881_DATA
+ DDRSS_PHY_882_DATA
+ DDRSS_PHY_883_DATA
+ DDRSS_PHY_884_DATA
+ DDRSS_PHY_885_DATA
+ DDRSS_PHY_886_DATA
+ DDRSS_PHY_887_DATA
+ DDRSS_PHY_888_DATA
+ DDRSS_PHY_889_DATA
+ DDRSS_PHY_890_DATA
+ DDRSS_PHY_891_DATA
+ DDRSS_PHY_892_DATA
+ DDRSS_PHY_893_DATA
+ DDRSS_PHY_894_DATA
+ DDRSS_PHY_895_DATA
+ DDRSS_PHY_896_DATA
+ DDRSS_PHY_897_DATA
+ DDRSS_PHY_898_DATA
+ DDRSS_PHY_899_DATA
+ DDRSS_PHY_900_DATA
+ DDRSS_PHY_901_DATA
+ DDRSS_PHY_902_DATA
+ DDRSS_PHY_903_DATA
+ DDRSS_PHY_904_DATA
+ DDRSS_PHY_905_DATA
+ DDRSS_PHY_906_DATA
+ DDRSS_PHY_907_DATA
+ DDRSS_PHY_908_DATA
+ DDRSS_PHY_909_DATA
+ DDRSS_PHY_910_DATA
+ DDRSS_PHY_911_DATA
+ DDRSS_PHY_912_DATA
+ DDRSS_PHY_913_DATA
+ DDRSS_PHY_914_DATA
+ DDRSS_PHY_915_DATA
+ DDRSS_PHY_916_DATA
+ DDRSS_PHY_917_DATA
+ DDRSS_PHY_918_DATA
+ DDRSS_PHY_919_DATA
+ DDRSS_PHY_920_DATA
+ DDRSS_PHY_921_DATA
+ DDRSS_PHY_922_DATA
+ DDRSS_PHY_923_DATA
+ DDRSS_PHY_924_DATA
+ DDRSS_PHY_925_DATA
+ DDRSS_PHY_926_DATA
+ DDRSS_PHY_927_DATA
+ DDRSS_PHY_928_DATA
+ DDRSS_PHY_929_DATA
+ DDRSS_PHY_930_DATA
+ DDRSS_PHY_931_DATA
+ DDRSS_PHY_932_DATA
+ DDRSS_PHY_933_DATA
+ DDRSS_PHY_934_DATA
+ DDRSS_PHY_935_DATA
+ DDRSS_PHY_936_DATA
+ DDRSS_PHY_937_DATA
+ DDRSS_PHY_938_DATA
+ DDRSS_PHY_939_DATA
+ DDRSS_PHY_940_DATA
+ DDRSS_PHY_941_DATA
+ DDRSS_PHY_942_DATA
+ DDRSS_PHY_943_DATA
+ DDRSS_PHY_944_DATA
+ DDRSS_PHY_945_DATA
+ DDRSS_PHY_946_DATA
+ DDRSS_PHY_947_DATA
+ DDRSS_PHY_948_DATA
+ DDRSS_PHY_949_DATA
+ DDRSS_PHY_950_DATA
+ DDRSS_PHY_951_DATA
+ DDRSS_PHY_952_DATA
+ DDRSS_PHY_953_DATA
+ DDRSS_PHY_954_DATA
+ DDRSS_PHY_955_DATA
+ DDRSS_PHY_956_DATA
+ DDRSS_PHY_957_DATA
+ DDRSS_PHY_958_DATA
+ DDRSS_PHY_959_DATA
+ DDRSS_PHY_960_DATA
+ DDRSS_PHY_961_DATA
+ DDRSS_PHY_962_DATA
+ DDRSS_PHY_963_DATA
+ DDRSS_PHY_964_DATA
+ DDRSS_PHY_965_DATA
+ DDRSS_PHY_966_DATA
+ DDRSS_PHY_967_DATA
+ DDRSS_PHY_968_DATA
+ DDRSS_PHY_969_DATA
+ DDRSS_PHY_970_DATA
+ DDRSS_PHY_971_DATA
+ DDRSS_PHY_972_DATA
+ DDRSS_PHY_973_DATA
+ DDRSS_PHY_974_DATA
+ DDRSS_PHY_975_DATA
+ DDRSS_PHY_976_DATA
+ DDRSS_PHY_977_DATA
+ DDRSS_PHY_978_DATA
+ DDRSS_PHY_979_DATA
+ DDRSS_PHY_980_DATA
+ DDRSS_PHY_981_DATA
+ DDRSS_PHY_982_DATA
+ DDRSS_PHY_983_DATA
+ DDRSS_PHY_984_DATA
+ DDRSS_PHY_985_DATA
+ DDRSS_PHY_986_DATA
+ DDRSS_PHY_987_DATA
+ DDRSS_PHY_988_DATA
+ DDRSS_PHY_989_DATA
+ DDRSS_PHY_990_DATA
+ DDRSS_PHY_991_DATA
+ DDRSS_PHY_992_DATA
+ DDRSS_PHY_993_DATA
+ DDRSS_PHY_994_DATA
+ DDRSS_PHY_995_DATA
+ DDRSS_PHY_996_DATA
+ DDRSS_PHY_997_DATA
+ DDRSS_PHY_998_DATA
+ DDRSS_PHY_999_DATA
+ DDRSS_PHY_1000_DATA
+ DDRSS_PHY_1001_DATA
+ DDRSS_PHY_1002_DATA
+ DDRSS_PHY_1003_DATA
+ DDRSS_PHY_1004_DATA
+ DDRSS_PHY_1005_DATA
+ DDRSS_PHY_1006_DATA
+ DDRSS_PHY_1007_DATA
+ DDRSS_PHY_1008_DATA
+ DDRSS_PHY_1009_DATA
+ DDRSS_PHY_1010_DATA
+ DDRSS_PHY_1011_DATA
+ DDRSS_PHY_1012_DATA
+ DDRSS_PHY_1013_DATA
+ DDRSS_PHY_1014_DATA
+ DDRSS_PHY_1015_DATA
+ DDRSS_PHY_1016_DATA
+ DDRSS_PHY_1017_DATA
+ DDRSS_PHY_1018_DATA
+ DDRSS_PHY_1019_DATA
+ DDRSS_PHY_1020_DATA
+ DDRSS_PHY_1021_DATA
+ DDRSS_PHY_1022_DATA
+ DDRSS_PHY_1023_DATA
+ DDRSS_PHY_1024_DATA
+ DDRSS_PHY_1025_DATA
+ DDRSS_PHY_1026_DATA
+ DDRSS_PHY_1027_DATA
+ DDRSS_PHY_1028_DATA
+ DDRSS_PHY_1029_DATA
+ DDRSS_PHY_1030_DATA
+ DDRSS_PHY_1031_DATA
+ DDRSS_PHY_1032_DATA
+ DDRSS_PHY_1033_DATA
+ DDRSS_PHY_1034_DATA
+ DDRSS_PHY_1035_DATA
+ DDRSS_PHY_1036_DATA
+ DDRSS_PHY_1037_DATA
+ DDRSS_PHY_1038_DATA
+ DDRSS_PHY_1039_DATA
+ DDRSS_PHY_1040_DATA
+ DDRSS_PHY_1041_DATA
+ DDRSS_PHY_1042_DATA
+ DDRSS_PHY_1043_DATA
+ DDRSS_PHY_1044_DATA
+ DDRSS_PHY_1045_DATA
+ DDRSS_PHY_1046_DATA
+ DDRSS_PHY_1047_DATA
+ DDRSS_PHY_1048_DATA
+ DDRSS_PHY_1049_DATA
+ DDRSS_PHY_1050_DATA
+ DDRSS_PHY_1051_DATA
+ DDRSS_PHY_1052_DATA
+ DDRSS_PHY_1053_DATA
+ DDRSS_PHY_1054_DATA
+ DDRSS_PHY_1055_DATA
+ DDRSS_PHY_1056_DATA
+ DDRSS_PHY_1057_DATA
+ DDRSS_PHY_1058_DATA
+ DDRSS_PHY_1059_DATA
+ DDRSS_PHY_1060_DATA
+ DDRSS_PHY_1061_DATA
+ DDRSS_PHY_1062_DATA
+ DDRSS_PHY_1063_DATA
+ DDRSS_PHY_1064_DATA
+ DDRSS_PHY_1065_DATA
+ DDRSS_PHY_1066_DATA
+ DDRSS_PHY_1067_DATA
+ DDRSS_PHY_1068_DATA
+ DDRSS_PHY_1069_DATA
+ DDRSS_PHY_1070_DATA
+ DDRSS_PHY_1071_DATA
+ DDRSS_PHY_1072_DATA
+ DDRSS_PHY_1073_DATA
+ DDRSS_PHY_1074_DATA
+ DDRSS_PHY_1075_DATA
+ DDRSS_PHY_1076_DATA
+ DDRSS_PHY_1077_DATA
+ DDRSS_PHY_1078_DATA
+ DDRSS_PHY_1079_DATA
+ DDRSS_PHY_1080_DATA
+ DDRSS_PHY_1081_DATA
+ DDRSS_PHY_1082_DATA
+ DDRSS_PHY_1083_DATA
+ DDRSS_PHY_1084_DATA
+ DDRSS_PHY_1085_DATA
+ DDRSS_PHY_1086_DATA
+ DDRSS_PHY_1087_DATA
+ DDRSS_PHY_1088_DATA
+ DDRSS_PHY_1089_DATA
+ DDRSS_PHY_1090_DATA
+ DDRSS_PHY_1091_DATA
+ DDRSS_PHY_1092_DATA
+ DDRSS_PHY_1093_DATA
+ DDRSS_PHY_1094_DATA
+ DDRSS_PHY_1095_DATA
+ DDRSS_PHY_1096_DATA
+ DDRSS_PHY_1097_DATA
+ DDRSS_PHY_1098_DATA
+ DDRSS_PHY_1099_DATA
+ DDRSS_PHY_1100_DATA
+ DDRSS_PHY_1101_DATA
+ DDRSS_PHY_1102_DATA
+ DDRSS_PHY_1103_DATA
+ DDRSS_PHY_1104_DATA
+ DDRSS_PHY_1105_DATA
+ DDRSS_PHY_1106_DATA
+ DDRSS_PHY_1107_DATA
+ DDRSS_PHY_1108_DATA
+ DDRSS_PHY_1109_DATA
+ DDRSS_PHY_1110_DATA
+ DDRSS_PHY_1111_DATA
+ DDRSS_PHY_1112_DATA
+ DDRSS_PHY_1113_DATA
+ DDRSS_PHY_1114_DATA
+ DDRSS_PHY_1115_DATA
+ DDRSS_PHY_1116_DATA
+ DDRSS_PHY_1117_DATA
+ DDRSS_PHY_1118_DATA
+ DDRSS_PHY_1119_DATA
+ DDRSS_PHY_1120_DATA
+ DDRSS_PHY_1121_DATA
+ DDRSS_PHY_1122_DATA
+ DDRSS_PHY_1123_DATA
+ DDRSS_PHY_1124_DATA
+ DDRSS_PHY_1125_DATA
+ DDRSS_PHY_1126_DATA
+ DDRSS_PHY_1127_DATA
+ DDRSS_PHY_1128_DATA
+ DDRSS_PHY_1129_DATA
+ DDRSS_PHY_1130_DATA
+ DDRSS_PHY_1131_DATA
+ DDRSS_PHY_1132_DATA
+ DDRSS_PHY_1133_DATA
+ DDRSS_PHY_1134_DATA
+ DDRSS_PHY_1135_DATA
+ DDRSS_PHY_1136_DATA
+ DDRSS_PHY_1137_DATA
+ DDRSS_PHY_1138_DATA
+ DDRSS_PHY_1139_DATA
+ DDRSS_PHY_1140_DATA
+ DDRSS_PHY_1141_DATA
+ DDRSS_PHY_1142_DATA
+ DDRSS_PHY_1143_DATA
+ DDRSS_PHY_1144_DATA
+ DDRSS_PHY_1145_DATA
+ DDRSS_PHY_1146_DATA
+ DDRSS_PHY_1147_DATA
+ DDRSS_PHY_1148_DATA
+ DDRSS_PHY_1149_DATA
+ DDRSS_PHY_1150_DATA
+ DDRSS_PHY_1151_DATA
+ DDRSS_PHY_1152_DATA
+ DDRSS_PHY_1153_DATA
+ DDRSS_PHY_1154_DATA
+ DDRSS_PHY_1155_DATA
+ DDRSS_PHY_1156_DATA
+ DDRSS_PHY_1157_DATA
+ DDRSS_PHY_1158_DATA
+ DDRSS_PHY_1159_DATA
+ DDRSS_PHY_1160_DATA
+ DDRSS_PHY_1161_DATA
+ DDRSS_PHY_1162_DATA
+ DDRSS_PHY_1163_DATA
+ DDRSS_PHY_1164_DATA
+ DDRSS_PHY_1165_DATA
+ DDRSS_PHY_1166_DATA
+ DDRSS_PHY_1167_DATA
+ DDRSS_PHY_1168_DATA
+ DDRSS_PHY_1169_DATA
+ DDRSS_PHY_1170_DATA
+ DDRSS_PHY_1171_DATA
+ DDRSS_PHY_1172_DATA
+ DDRSS_PHY_1173_DATA
+ DDRSS_PHY_1174_DATA
+ DDRSS_PHY_1175_DATA
+ DDRSS_PHY_1176_DATA
+ DDRSS_PHY_1177_DATA
+ DDRSS_PHY_1178_DATA
+ DDRSS_PHY_1179_DATA
+ DDRSS_PHY_1180_DATA
+ DDRSS_PHY_1181_DATA
+ DDRSS_PHY_1182_DATA
+ DDRSS_PHY_1183_DATA
+ DDRSS_PHY_1184_DATA
+ DDRSS_PHY_1185_DATA
+ DDRSS_PHY_1186_DATA
+ DDRSS_PHY_1187_DATA
+ DDRSS_PHY_1188_DATA
+ DDRSS_PHY_1189_DATA
+ DDRSS_PHY_1190_DATA
+ DDRSS_PHY_1191_DATA
+ DDRSS_PHY_1192_DATA
+ DDRSS_PHY_1193_DATA
+ DDRSS_PHY_1194_DATA
+ DDRSS_PHY_1195_DATA
+ DDRSS_PHY_1196_DATA
+ DDRSS_PHY_1197_DATA
+ DDRSS_PHY_1198_DATA
+ DDRSS_PHY_1199_DATA
+ DDRSS_PHY_1200_DATA
+ DDRSS_PHY_1201_DATA
+ DDRSS_PHY_1202_DATA
+ DDRSS_PHY_1203_DATA
+ DDRSS_PHY_1204_DATA
+ DDRSS_PHY_1205_DATA
+ DDRSS_PHY_1206_DATA
+ DDRSS_PHY_1207_DATA
+ DDRSS_PHY_1208_DATA
+ DDRSS_PHY_1209_DATA
+ DDRSS_PHY_1210_DATA
+ DDRSS_PHY_1211_DATA
+ DDRSS_PHY_1212_DATA
+ DDRSS_PHY_1213_DATA
+ DDRSS_PHY_1214_DATA
+ DDRSS_PHY_1215_DATA
+ DDRSS_PHY_1216_DATA
+ DDRSS_PHY_1217_DATA
+ DDRSS_PHY_1218_DATA
+ DDRSS_PHY_1219_DATA
+ DDRSS_PHY_1220_DATA
+ DDRSS_PHY_1221_DATA
+ DDRSS_PHY_1222_DATA
+ DDRSS_PHY_1223_DATA
+ DDRSS_PHY_1224_DATA
+ DDRSS_PHY_1225_DATA
+ DDRSS_PHY_1226_DATA
+ DDRSS_PHY_1227_DATA
+ DDRSS_PHY_1228_DATA
+ DDRSS_PHY_1229_DATA
+ DDRSS_PHY_1230_DATA
+ DDRSS_PHY_1231_DATA
+ DDRSS_PHY_1232_DATA
+ DDRSS_PHY_1233_DATA
+ DDRSS_PHY_1234_DATA
+ DDRSS_PHY_1235_DATA
+ DDRSS_PHY_1236_DATA
+ DDRSS_PHY_1237_DATA
+ DDRSS_PHY_1238_DATA
+ DDRSS_PHY_1239_DATA
+ DDRSS_PHY_1240_DATA
+ DDRSS_PHY_1241_DATA
+ DDRSS_PHY_1242_DATA
+ DDRSS_PHY_1243_DATA
+ DDRSS_PHY_1244_DATA
+ DDRSS_PHY_1245_DATA
+ DDRSS_PHY_1246_DATA
+ DDRSS_PHY_1247_DATA
+ DDRSS_PHY_1248_DATA
+ DDRSS_PHY_1249_DATA
+ DDRSS_PHY_1250_DATA
+ DDRSS_PHY_1251_DATA
+ DDRSS_PHY_1252_DATA
+ DDRSS_PHY_1253_DATA
+ DDRSS_PHY_1254_DATA
+ DDRSS_PHY_1255_DATA
+ DDRSS_PHY_1256_DATA
+ DDRSS_PHY_1257_DATA
+ DDRSS_PHY_1258_DATA
+ DDRSS_PHY_1259_DATA
+ DDRSS_PHY_1260_DATA
+ DDRSS_PHY_1261_DATA
+ DDRSS_PHY_1262_DATA
+ DDRSS_PHY_1263_DATA
+ DDRSS_PHY_1264_DATA
+ DDRSS_PHY_1265_DATA
+ DDRSS_PHY_1266_DATA
+ DDRSS_PHY_1267_DATA
+ DDRSS_PHY_1268_DATA
+ DDRSS_PHY_1269_DATA
+ DDRSS_PHY_1270_DATA
+ DDRSS_PHY_1271_DATA
+ DDRSS_PHY_1272_DATA
+ DDRSS_PHY_1273_DATA
+ DDRSS_PHY_1274_DATA
+ DDRSS_PHY_1275_DATA
+ DDRSS_PHY_1276_DATA
+ DDRSS_PHY_1277_DATA
+ DDRSS_PHY_1278_DATA
+ DDRSS_PHY_1279_DATA
+ DDRSS_PHY_1280_DATA
+ DDRSS_PHY_1281_DATA
+ DDRSS_PHY_1282_DATA
+ DDRSS_PHY_1283_DATA
+ DDRSS_PHY_1284_DATA
+ DDRSS_PHY_1285_DATA
+ DDRSS_PHY_1286_DATA
+ DDRSS_PHY_1287_DATA
+ DDRSS_PHY_1288_DATA
+ DDRSS_PHY_1289_DATA
+ DDRSS_PHY_1290_DATA
+ DDRSS_PHY_1291_DATA
+ DDRSS_PHY_1292_DATA
+ DDRSS_PHY_1293_DATA
+ DDRSS_PHY_1294_DATA
+ DDRSS_PHY_1295_DATA
+ DDRSS_PHY_1296_DATA
+ DDRSS_PHY_1297_DATA
+ DDRSS_PHY_1298_DATA
+ DDRSS_PHY_1299_DATA
+ DDRSS_PHY_1300_DATA
+ DDRSS_PHY_1301_DATA
+ DDRSS_PHY_1302_DATA
+ DDRSS_PHY_1303_DATA
+ DDRSS_PHY_1304_DATA
+ DDRSS_PHY_1305_DATA
+ DDRSS_PHY_1306_DATA
+ DDRSS_PHY_1307_DATA
+ DDRSS_PHY_1308_DATA
+ DDRSS_PHY_1309_DATA
+ DDRSS_PHY_1310_DATA
+ DDRSS_PHY_1311_DATA
+ DDRSS_PHY_1312_DATA
+ DDRSS_PHY_1313_DATA
+ DDRSS_PHY_1314_DATA
+ DDRSS_PHY_1315_DATA
+ DDRSS_PHY_1316_DATA
+ DDRSS_PHY_1317_DATA
+ DDRSS_PHY_1318_DATA
+ DDRSS_PHY_1319_DATA
+ DDRSS_PHY_1320_DATA
+ DDRSS_PHY_1321_DATA
+ DDRSS_PHY_1322_DATA
+ DDRSS_PHY_1323_DATA
+ DDRSS_PHY_1324_DATA
+ DDRSS_PHY_1325_DATA
+ DDRSS_PHY_1326_DATA
+ DDRSS_PHY_1327_DATA
+ DDRSS_PHY_1328_DATA
+ DDRSS_PHY_1329_DATA
+ DDRSS_PHY_1330_DATA
+ DDRSS_PHY_1331_DATA
+ DDRSS_PHY_1332_DATA
+ DDRSS_PHY_1333_DATA
+ DDRSS_PHY_1334_DATA
+ DDRSS_PHY_1335_DATA
+ DDRSS_PHY_1336_DATA
+ DDRSS_PHY_1337_DATA
+ DDRSS_PHY_1338_DATA
+ DDRSS_PHY_1339_DATA
+ DDRSS_PHY_1340_DATA
+ DDRSS_PHY_1341_DATA
+ DDRSS_PHY_1342_DATA
+ DDRSS_PHY_1343_DATA
+ DDRSS_PHY_1344_DATA
+ DDRSS_PHY_1345_DATA
+ DDRSS_PHY_1346_DATA
+ DDRSS_PHY_1347_DATA
+ DDRSS_PHY_1348_DATA
+ DDRSS_PHY_1349_DATA
+ DDRSS_PHY_1350_DATA
+ DDRSS_PHY_1351_DATA
+ DDRSS_PHY_1352_DATA
+ DDRSS_PHY_1353_DATA
+ DDRSS_PHY_1354_DATA
+ DDRSS_PHY_1355_DATA
+ DDRSS_PHY_1356_DATA
+ DDRSS_PHY_1357_DATA
+ DDRSS_PHY_1358_DATA
+ DDRSS_PHY_1359_DATA
+ DDRSS_PHY_1360_DATA
+ DDRSS_PHY_1361_DATA
+ DDRSS_PHY_1362_DATA
+ DDRSS_PHY_1363_DATA
+ DDRSS_PHY_1364_DATA
+ DDRSS_PHY_1365_DATA
+ DDRSS_PHY_1366_DATA
+ DDRSS_PHY_1367_DATA
+ DDRSS_PHY_1368_DATA
+ DDRSS_PHY_1369_DATA
+ DDRSS_PHY_1370_DATA
+ DDRSS_PHY_1371_DATA
+ DDRSS_PHY_1372_DATA
+ DDRSS_PHY_1373_DATA
+ DDRSS_PHY_1374_DATA
+ DDRSS_PHY_1375_DATA
+ DDRSS_PHY_1376_DATA
+ DDRSS_PHY_1377_DATA
+ DDRSS_PHY_1378_DATA
+ DDRSS_PHY_1379_DATA
+ DDRSS_PHY_1380_DATA
+ DDRSS_PHY_1381_DATA
+ DDRSS_PHY_1382_DATA
+ DDRSS_PHY_1383_DATA
+ DDRSS_PHY_1384_DATA
+ DDRSS_PHY_1385_DATA
+ DDRSS_PHY_1386_DATA
+ DDRSS_PHY_1387_DATA
+ DDRSS_PHY_1388_DATA
+ DDRSS_PHY_1389_DATA
+ DDRSS_PHY_1390_DATA
+ DDRSS_PHY_1391_DATA
+ DDRSS_PHY_1392_DATA
+ DDRSS_PHY_1393_DATA
+ DDRSS_PHY_1394_DATA
+ DDRSS_PHY_1395_DATA
+ DDRSS_PHY_1396_DATA
+ DDRSS_PHY_1397_DATA
+ DDRSS_PHY_1398_DATA
+ DDRSS_PHY_1399_DATA
+ DDRSS_PHY_1400_DATA
+ DDRSS_PHY_1401_DATA
+ DDRSS_PHY_1402_DATA
+ DDRSS_PHY_1403_DATA
+ DDRSS_PHY_1404_DATA
+ DDRSS_PHY_1405_DATA
+ DDRSS_PHY_1406_DATA
+ DDRSS_PHY_1407_DATA
+ DDRSS_PHY_1408_DATA
+ DDRSS_PHY_1409_DATA
+ DDRSS_PHY_1410_DATA
+ DDRSS_PHY_1411_DATA
+ DDRSS_PHY_1412_DATA
+ DDRSS_PHY_1413_DATA
+ DDRSS_PHY_1414_DATA
+ DDRSS_PHY_1415_DATA
+ DDRSS_PHY_1416_DATA
+ DDRSS_PHY_1417_DATA
+ DDRSS_PHY_1418_DATA
+ DDRSS_PHY_1419_DATA
+ DDRSS_PHY_1420_DATA
+ DDRSS_PHY_1421_DATA
+ DDRSS_PHY_1422_DATA
+ >;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt b/roms/u-boot/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt
new file mode 100644
index 000000000..4ed731c52
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt
@@ -0,0 +1,46 @@
+Texas Instruments' K3 AM654 DDRSS
+=================================
+
+K3 based AM654 devices has DDR memory subsystem that comprises
+Synopys DDR controller, Synopsis DDR phy and wrapper logic to
+integrate these blocks into the device. This DDR subsystem
+provides an interface to external SDRAM devices. This DDRSS driver
+adds support for the initialization of the external SDRAM devices by
+configuring the DDRSS registers and using the buitin PHY
+initialization routines.
+
+DDRSS device node:
+==================
+Required properties:
+--------------------
+- compatible: Shall be: "ti,am654-ddrss"
+- reg-names ss - Map the sub system wrapper logic region
+ ctl - Map the controller region
+ phy - Map the PHY region
+- reg: Contains the register map per reg-names.
+- power-domains: Should contain a phandle to a PM domain provider node
+ and an args specifier containing the DDRSS device id
+ value. This property is as per the binding,
+ doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+- clocks: Must contain an entry for enabling DDR clock. Should
+ be defined as per the appropriate clock bindings consumer
+ usage in doc/device-tree-bindings/clock/ti,sci-clk.txt
+
+
+Optional Properties:
+--------------------
+- clock-frequency: Frequency at which DDR pll should be locked.
+ If not provided, default frequency will be used.
+
+Example (AM65x):
+================
+ memory-controller: memory-controller@298e000 {
+ compatible = "ti,am654-ddrss";
+ reg = <0x0298e000 0x200>,
+ <0x02980000 0x4000>,
+ <0x02988000 0x2000>;
+ reg-names = "ss", "ctl", "phy";
+ clocks = <&k3_clks 20 0>;
+ power-domains = <&k3_pds 20>;
+ u-boot,dm-spl;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt b/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt
new file mode 100644
index 000000000..99f76d515
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt
@@ -0,0 +1,58 @@
+ST, stm32 flexible memory controller Drive
+Required properties:
+- compatible : "st,stm32-fmc"
+- reg : fmc controller base address
+- clocks : fmc controller clock
+u-boot,dm-pre-reloc: flag to initialize memory before relocation.
+
+on-board sdram memory attributes:
+- st,sdram-control : parameters for sdram configuration, in this order:
+ number of columns
+ number of rows
+ memory width
+ number of intenal banks in memory
+ cas latency
+ read burst enable or disable
+ read pipe delay
+
+- st,sdram-timing: timings for sdram, in this order:
+ tmrd
+ txsr
+ tras
+ trc
+ trp
+ trcd
+
+There is device tree include file at :
+include/dt-bindings/memory/stm32-sdram.h to define sdram control and timing
+parameters as MACROS.
+
+Example:
+ fmc: fmc@A0000000 {
+ compatible = "st,stm32-fmc";
+ reg = <0xA0000000 0x1000>;
+ clocks = <&rcc 0 64>;
+ u-boot,dm-pre-reloc;
+ };
+
+ &fmc {
+ pinctrl-0 = <&fmc_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /* sdram memory configuration from sdram datasheet */
+ bank1: bank@0 {
+ st,sdram-control = /bits/ 8 <NO_COL_8 NO_ROW_12 MWIDTH_16 BANKS_2
+ CAS_3 RD_BURST_EN RD_PIPE_DL_0>;
+ st,sdram-timing = /bits/ 8 <TMRD_1 TXSR_60 TRAS_42 TRC_60 TRP_18
+ TRCD_18>;
+ };
+
+ /* sdram memory configuration from sdram datasheet */
+ bank2: bank@1 {
+ st,sdram-control = /bits/ 8 <NO_COL_8 NO_ROW_12 MWIDTH_16 BANKS_2
+ CAS_3 RD_BURST_EN RD_PIPE_DL_0>;
+ st,sdram-timing = /bits/ 8 <TMRD_1 TXSR_60 TRAS_42 TRC_60 TRP_18
+ TRCD_18>;
+ };
+ }
diff --git a/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt b/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
new file mode 100644
index 000000000..ac6a7df43
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
@@ -0,0 +1,301 @@
+ST,stm32mp1 DDR3/LPDDR2/LPDDR3 Controller (DDRCTRL and DDRPHYC)
+
+--------------------
+Required properties:
+--------------------
+- compatible : Should be "st,stm32mp1-ddr"
+- reg : controleur (DDRCTRL) and phy (DDRPHYC) base address
+- clocks : controller clocks handle
+- clock-names : associated controller clock names
+ the "ddrphyc" clock is used to check the DDR frequency
+ at phy level according the expected value in "mem-speed" field
+
+the next attributes are DDR parameters, they are generated by DDR tools
+included in STM32 Cube tool
+
+info attributes:
+----------------
+- st,mem-name : name for DDR configuration, simple string for information
+- st,mem-speed : DDR expected speed for the setting in kHz
+- st,mem-size : DDR mem size in byte
+
+
+controlleur attributes:
+-----------------------
+- st,ctl-reg : controleur values depending of the DDR type
+ (DDR3/LPDDR2/LPDDR3)
+ for STM32MP15x: 25 values are requested in this order
+ MSTR
+ MRCTRL0
+ MRCTRL1
+ DERATEEN
+ DERATEINT
+ PWRCTL
+ PWRTMG
+ HWLPCTL
+ RFSHCTL0
+ RFSHCTL3
+ CRCPARCTL0
+ ZQCTL0
+ DFITMG0
+ DFITMG1
+ DFILPCFG0
+ DFIUPD0
+ DFIUPD1
+ DFIUPD2
+ DFIPHYMSTR
+ ODTMAP
+ DBG0
+ DBG1
+ DBGCMD
+ POISONCFG
+ PCCFG
+
+- st,ctl-timing : controleur values depending of frequency and timing parameter
+ of DDR
+ for STM32MP15x: 12 values are requested in this order
+ RFSHTMG
+ DRAMTMG0
+ DRAMTMG1
+ DRAMTMG2
+ DRAMTMG3
+ DRAMTMG4
+ DRAMTMG5
+ DRAMTMG6
+ DRAMTMG7
+ DRAMTMG8
+ DRAMTMG14
+ ODTCFG
+
+- st,ctl-map : controleur values depending of address mapping
+ for STM32MP15x: 9 values are requested in this order
+ ADDRMAP1
+ ADDRMAP2
+ ADDRMAP3
+ ADDRMAP4
+ ADDRMAP5
+ ADDRMAP6
+ ADDRMAP9
+ ADDRMAP10
+ ADDRMAP11
+
+- st,ctl-perf : controleur values depending of performance and scheduling
+ for STM32MP15x: 17 values are requested in this order
+ SCHED
+ SCHED1
+ PERFHPR1
+ PERFLPR1
+ PERFWR1
+ PCFGR_0
+ PCFGW_0
+ PCFGQOS0_0
+ PCFGQOS1_0
+ PCFGWQOS0_0
+ PCFGWQOS1_0
+ PCFGR_1
+ PCFGW_1
+ PCFGQOS0_1
+ PCFGQOS1_1
+ PCFGWQOS0_1
+ PCFGWQOS1_1
+
+phyc attributes:
+----------------
+- st,phy-reg : phy values depending of the DDR type (DDR3/LPDDR2/LPDDR3)
+ for STM32MP15x: 11 values are requested in this order
+ PGCR
+ ACIOCR
+ DXCCR
+ DSGCR
+ DCR
+ ODTCR
+ ZQ0CR1
+ DX0GCR
+ DX1GCR
+ DX2GCR
+ DX3GCR
+
+- st,phy-timing : phy values depending of frequency and timing parameter of DDR
+ for STM32MP15x: 10 values are requested in this order
+ PTR0
+ PTR1
+ PTR2
+ DTPR0
+ DTPR1
+ DTPR2
+ MR0
+ MR1
+ MR2
+ MR3
+
+- st,phy-cal : phy cal depending of calibration or tuning of DDR
+ This parameter is optional; when it is absent the built-in PHY
+ calibration is done.
+ for STM32MP15x: 12 values are requested in this order
+ DX0DLLCR
+ DX0DQTR
+ DX0DQSTR
+ DX1DLLCR
+ DX1DQTR
+ DX1DQSTR
+ DX2DLLCR
+ DX2DQTR
+ DX2DQSTR
+ DX3DLLCR
+ DX3DQTR
+ DX3DQSTR
+
+Example:
+
+/ {
+ soc {
+ u-boot,dm-spl;
+
+ ddr: ddr@0x5A003000{
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+
+ compatible = "st,stm32mp1-ddr";
+
+ reg = <0x5A003000 0x550
+ 0x5A004000 0x234>;
+
+ clocks = <&rcc_clk AXIDCG>,
+ <&rcc_clk DDRC1>,
+ <&rcc_clk DDRC2>,
+ <&rcc_clk DDRPHYC>,
+ <&rcc_clk DDRCAPB>,
+ <&rcc_clk DDRPHYCAPB>;
+
+ clock-names = "axidcg",
+ "ddrc1",
+ "ddrc2",
+ "ddrphyc",
+ "ddrcapb",
+ "ddrphycapb";
+
+ st,mem-name = "DDR3 2x4Gb 533MHz";
+ st,mem-speed = <533000>;
+ st,mem-size = <0x40000000>;
+
+ st,ctl-reg = <
+ 0x00040401 /*MSTR*/
+ 0x00000010 /*MRCTRL0*/
+ 0x00000000 /*MRCTRL1*/
+ 0x00000000 /*DERATEEN*/
+ 0x00800000 /*DERATEINT*/
+ 0x00000000 /*PWRCTL*/
+ 0x00400010 /*PWRTMG*/
+ 0x00000000 /*HWLPCTL*/
+ 0x00210000 /*RFSHCTL0*/
+ 0x00000000 /*RFSHCTL3*/
+ 0x00000000 /*CRCPARCTL0*/
+ 0xC2000040 /*ZQCTL0*/
+ 0x02050105 /*DFITMG0*/
+ 0x00000202 /*DFITMG1*/
+ 0x07000000 /*DFILPCFG0*/
+ 0xC0400003 /*DFIUPD0*/
+ 0x00000000 /*DFIUPD1*/
+ 0x00000000 /*DFIUPD2*/
+ 0x00000000 /*DFIPHYMSTR*/
+ 0x00000001 /*ODTMAP*/
+ 0x00000000 /*DBG0*/
+ 0x00000000 /*DBG1*/
+ 0x00000000 /*DBGCMD*/
+ 0x00000000 /*POISONCFG*/
+ 0x00000010 /*PCCFG*/
+ >;
+
+ st,ctl-timing = <
+ 0x0080008A /*RFSHTMG*/
+ 0x121B2414 /*DRAMTMG0*/
+ 0x000D041B /*DRAMTMG1*/
+ 0x0607080E /*DRAMTMG2*/
+ 0x0050400C /*DRAMTMG3*/
+ 0x07040407 /*DRAMTMG4*/
+ 0x06060303 /*DRAMTMG5*/
+ 0x02020002 /*DRAMTMG6*/
+ 0x00000202 /*DRAMTMG7*/
+ 0x00001005 /*DRAMTMG8*/
+ 0x000D041B /*DRAMTMG1*/4
+ 0x06000600 /*ODTCFG*/
+ >;
+
+ st,ctl-map = <
+ 0x00080808 /*ADDRMAP1*/
+ 0x00000000 /*ADDRMAP2*/
+ 0x00000000 /*ADDRMAP3*/
+ 0x00001F1F /*ADDRMAP4*/
+ 0x07070707 /*ADDRMAP5*/
+ 0x0F070707 /*ADDRMAP6*/
+ 0x00000000 /*ADDRMAP9*/
+ 0x00000000 /*ADDRMAP10*/
+ 0x00000000 /*ADDRMAP11*/
+ >;
+
+ st,ctl-perf = <
+ 0x00001201 /*SCHED*/
+ 0x00001201 /*SCHED*/1
+ 0x01000001 /*PERFHPR1*/
+ 0x08000200 /*PERFLPR1*/
+ 0x08000400 /*PERFWR1*/
+ 0x00010000 /*PCFGR_0*/
+ 0x00000000 /*PCFGW_0*/
+ 0x02100B03 /*PCFGQOS0_0*/
+ 0x00800100 /*PCFGQOS1_0*/
+ 0x01100B03 /*PCFGWQOS0_0*/
+ 0x01000200 /*PCFGWQOS1_0*/
+ 0x00010000 /*PCFGR_1*/
+ 0x00000000 /*PCFGW_1*/
+ 0x02100B03 /*PCFGQOS0_1*/
+ 0x00800000 /*PCFGQOS1_1*/
+ 0x01100B03 /*PCFGWQOS0_1*/
+ 0x01000200 /*PCFGWQOS1_1*/
+ >;
+
+ st,phy-reg = <
+ 0x01442E02 /*PGCR*/
+ 0x10400812 /*ACIOCR*/
+ 0x00000C40 /*DXCCR*/
+ 0xF200001F /*DSGCR*/
+ 0x0000000B /*DCR*/
+ 0x00010000 /*ODTCR*/
+ 0x0000007B /*ZQ0CR1*/
+ 0x0000CE81 /*DX0GCR*/
+ 0x0000CE81 /*DX1GCR*/
+ 0x0000CE81 /*DX2GCR*/
+ 0x0000CE81 /*DX3GCR*/
+ >;
+
+ st,phy-timing = <
+ 0x0022A41B /*PTR0*/
+ 0x047C0740 /*PTR1*/
+ 0x042D9C80 /*PTR2*/
+ 0x369477D0 /*DTPR0*/
+ 0x098A00D8 /*DTPR1*/
+ 0x10023600 /*DTPR2*/
+ 0x00000830 /*MR0*/
+ 0x00000000 /*MR1*/
+ 0x00000208 /*MR2*/
+ 0x00000000 /*MR3*/
+ >;
+
+ st,phy-cal = <
+ 0x40000000 /*DX0DLLCR*/
+ 0xFFFFFFFF /*DX0DQTR*/
+ 0x3DB02000 /*DX0DQSTR*/
+ 0x40000000 /*DX1DLLCR*/
+ 0xFFFFFFFF /*DX1DQTR*/
+ 0x3DB02000 /*DX1DQSTR*/
+ 0x40000000 /*DX2DLLCR*/
+ 0xFFFFFFFF /*DX2DQTR*/
+ 0x3DB02000 /*DX2DQSTR*/
+ 0x40000000 /*DX3DLLCR*/
+ 0xFFFFFFFF /*DX3DQTR*/
+ 0x3DB02000 /*DX3DQSTR*/
+ >;
+
+ status = "okay";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/memory/memory.txt b/roms/u-boot/doc/device-tree-bindings/memory/memory.txt
new file mode 100644
index 000000000..321894e01
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/memory/memory.txt
@@ -0,0 +1,67 @@
+* Memory binding
+
+The memory binding for U-Boot is as in the ePAPR with the following additions:
+
+Optional subnodes can be used defining the memory layout for different board
+ID masks. To match a set of board ids, a board-id node may define match-mask
+and match-value ints to define a mask to apply to the board id, and the value
+that the result should have for the match to be considered valid. The mask
+defaults to -1, meaning that the value must fully match the board id.
+
+If subnodes are present, then the /memory node must define these properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+Each subnode must define
+
+ reg - board ID or mask for this subnode
+ memory-banks - list of memory banks in the same format as normal
+
+Each subnode may optionally define:
+
+ match-mask - A mask to apply to the board id. This must be accompanied by
+ match-value.
+ match-value - The required resulting value of the board id mask for the given
+ node to be considered a match.
+ auto-size - Indicates that the value given for a bank is the maximum size,
+ each bank is probed to determine its actual size, which may be
+ smaller
+
+
+The board id determination is up to the vendor and is not defined by this
+binding.
+
+Example:
+
+memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x20000000 0x20000000
+ 0x40000000 0x20000000
+ 0x60000000 0x20000000
+ 0x80000000 0x20000000>;
+ auto-size;
+ board-id@0 {
+ match-value = <17>;
+ reg = <0x20000000 0x20000000
+ 0x40000000 0x20000000>;
+ };
+ board-id@1 {
+ match-mask = <2>;
+ match-value = <2>;
+ reg = <0x20000000 0x20000000
+ 0x40000000 0x20000000
+ 0x60000000 0x20000000
+ 0x80000000 0x20000000
+ 0xa0000000 0x20000000
+ 0xc0000000 0x20000000
+ 0xe0000000 0x20000000>;
+ };
+};
+
+
+This shows a system with the following properties:
+* Default of 2GB of memory, auto-sized, so could be smaller
+* 3.5GB of memory (with no auto-size) if (board id & 2) is 2
+* 1GB of memory (with no auto-size) if board id is 17.
diff --git a/roms/u-boot/doc/device-tree-bindings/mfd/kendryte,k210-sysctl.txt b/roms/u-boot/doc/device-tree-bindings/mfd/kendryte,k210-sysctl.txt
new file mode 100644
index 000000000..5b24abcb6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mfd/kendryte,k210-sysctl.txt
@@ -0,0 +1,33 @@
+Kendryte K210 Sysctl
+
+This binding describes the K210 sysctl device, which contains many miscellaneous
+registers controlling system functionality. This node is a register map and can
+be reference by other bindings which need a phandle to the K210 sysctl regmap.
+
+Required properties:
+- compatible: should be
+ "kendryte,k210-sysctl", "syscon", "simple-mfd"
+- reg: address and length of the sysctl registers
+- reg-io-width: must be <4>
+
+Clock sub-node
+
+This node is a binding for the clock tree driver
+
+Required properties:
+- compatible: should be "kendryte,k210-clk"
+- clocks: phandle to the "in0" external oscillator
+- #clock-cells: must be <1>
+
+Example:
+sysctl: syscon@50440000 {
+ compatible = "kendryte,k210-sysctl", "syscon", "simple-mfd";
+ reg = <0x50440000 0x100>;
+ reg-io-width = <4>;
+
+ sysclk: clock-controller {
+ compatible = "kendryte,k210-clk";
+ clocks = <&in0>;
+ #clock-cells = <1>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/altera_sysid.txt b/roms/u-boot/doc/device-tree-bindings/misc/altera_sysid.txt
new file mode 100644
index 000000000..54462eb5e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/altera_sysid.txt
@@ -0,0 +1,4 @@
+Altera sysid
+
+Required properties:
+- compatible : should be "altr,sysid-1.0"
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/bootcounter.txt b/roms/u-boot/doc/device-tree-bindings/misc/bootcounter.txt
new file mode 100644
index 000000000..d32fbc37b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/bootcounter.txt
@@ -0,0 +1,21 @@
+U-Boot bootcounter Devicetree Binding
+=====================================
+
+The device tree node describes the U-Boot bootcounter
+memory based device binding.
+
+Required properties :
+
+- compatible : "u-boot,bootcount";
+- single-word : set this, if you have only one word space
+ for storing the bootcounter.
+
+Example
+-------
+
+MPC83xx based board:
+
+bootcount@0x13ff8 {
+ compatible = "u-boot,bootcount";
+ reg = <0x13ff8 0x08>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt b/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt
new file mode 100644
index 000000000..07ea7cdea
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt
@@ -0,0 +1,38 @@
+Chrome OS CROS_EC Binding
+======================
+
+The device tree node which describes the operation of the CROS_EC interface
+is as follows:
+
+Required properties :
+- compatible = "google,cros-ec"
+
+Optional properties :
+- spi-max-frequency : Sets the maximum frequency (in Hz) for SPI bus
+ operation
+- i2c-max-frequency : Sets the maximum frequency (in Hz) for I2C bus
+ operation
+- ec-interrupt : Selects the EC interrupt, defined as a GPIO according
+ to the platform
+- optimise-flash-write : Boolean property - if present then flash blocks
+ containing all 0xff will not be written, since we assume that the EC
+ uses that pattern for erased blocks
+
+The CROS_EC node should appear as a subnode of the interrupt that connects it
+to the EC (e.g. i2c, spi, lpc). The reg property (as usual) will indicate
+the unit address on that bus.
+
+
+Example
+=======
+
+ spi@131b0000 {
+ cros-ec@0 {
+ reg = <0>;
+ compatible = "google,cros-ec";
+ spi-max-frequency = <5000000>;
+ ec-interrupt = <&gpio 174 1>;
+ optimise-flash-write;
+ status = "disabled";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/esm-k3.txt b/roms/u-boot/doc/device-tree-bindings/misc/esm-k3.txt
new file mode 100644
index 000000000..01c8b6b29
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/esm-k3.txt
@@ -0,0 +1,25 @@
+Texas Instruments K3 ESM Binding
+======================
+
+ESM (Error Signaling Module) is an IP block on TI K3 devices that allows
+handling of safety events somewhat similar to what interrupt controller
+would do. The safety signals have their separate paths within the SoC,
+and they are handled by the ESM, which routes them to the proper
+destination, which can be system reset, interrupt controller, etc. In
+the simplest configuration the signals are just routed to reset the
+SoC.
+
+Required properties :
+- compatible : "ti,j721e-esm"
+- ti,esm-pins : integer array of esm events IDs to route to external event
+ pin which can be used to reset the SoC. The array can
+ have arbitrary amount of event IDs listed on it.
+
+Example
+=======
+
+ main_esm: esm@700000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x700000 0x0 0x1000>;
+ ti,esm-pins = <344>, <345>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/esm-pmic.txt b/roms/u-boot/doc/device-tree-bindings/misc/esm-pmic.txt
new file mode 100644
index 000000000..a60ad7467
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/esm-pmic.txt
@@ -0,0 +1,19 @@
+PMIC ESM Binding
+======================
+
+Certain Power Management ICs contain safety handling logic within them,
+allowing automatic reset of the board in case a safety error is signaled.
+For this purpose, ESM (Error Signal Monitor) is implemented within
+the PMIC running its own state machine.
+
+Required properties :
+- compatible : "ti,tps659413-esm"
+
+Example
+=======
+
+&tps659413a {
+ esm: esm {
+ compatible = "ti,tps659413-esm";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/fs_loader.txt b/roms/u-boot/doc/device-tree-bindings/misc/fs_loader.txt
new file mode 100644
index 000000000..884fbf47c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/fs_loader.txt
@@ -0,0 +1,48 @@
+* File system firmware loader
+
+Required properties:
+--------------------
+
+- compatible: should contain "u-boot,fs-loader"
+- phandlepart: which block storage device and partition the image loading from,
+ this property is required for mmc, usb and sata. This is unsigned
+ 32-bit array. For example phandlepart=<&mmc_0 1>, meaning use
+ that MMC0 node pointer, partition 1.
+- mdtpart: which partition of ubi the image loading from, this property is
+ required for ubi and mounting.
+- ubivol: which volume of ubi the image loading from, this property is required
+ for ubi and mounting.
+
+Example of storage device and partition search set for mmc, usb, sata and
+ubi in device tree source as shown in below:
+
+ Example of storage type and device partition search set for mmc, usb,
+ sata and ubi as shown in below:
+ Example for mmc:
+ fs_loader0: fs-loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = <&mmc_0 1>;
+ };
+
+ Example for usb:
+ fs_loader1: fs-loader@1 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = <&usb0 1>;
+ };
+
+ Example for sata:
+ fs_loader2: fs-loader@2 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = <&sata0 1>;
+ };
+
+ Example for ubi:
+ fs_loader3: fs-loader@3 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ mtdpart = "UBI",
+ ubivol = "ubi0";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt b/roms/u-boot/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
new file mode 100644
index 000000000..929ae88c5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
@@ -0,0 +1,155 @@
+Intel Bay Trail FSP UPD Binding
+===============================
+
+The device tree node which describes the overriding of the Intel Bay Trail FSP
+UPD data for configuring the SoC.
+
+All properties can be found within the `upd-region` struct in
+arch/x86/include/asm/arch-baytrail/fsp/fsp_vpd.h, under the same names, and in
+Intel's FSP Binary Configuration Tool for Bay Trail. This list of properties
+is matched up to Intel's E3800 FSPv4 release.
+
+# Boolean properties:
+
+- fsp,enable-sdio
+- fsp,enable-sdcard
+- fsp,enable-hsuart0
+- fsp,enable-hsuart1
+- fsp,enable-spi
+- fsp,enable-sata
+- fsp,enable-azalia
+- fsp,enable-xhci
+- fsp,enable-dma0
+- fsp,enable-dma1
+- fsp,enable-i2-c0
+- fsp,enable-i2-c1
+- fsp,enable-i2-c2
+- fsp,enable-i2-c3
+- fsp,enable-i2-c4
+- fsp,enable-i2-c5
+- fsp,enable-i2-c6
+- fsp,enable-pwm0
+- fsp,enable-pwm1
+- fsp,enable-hsi
+- fsp,mrc-debug-msg
+- fsp,isp-enable
+- fsp,igd-render-standby
+- fsp,txe-uma-enable
+- fsp,emmc45-ddr50-enabled
+- fsp,emmc45-hs200-enabled
+- fsp,enable-igd
+- fsp,enable-memory-down
+
+If you set "fsp,enable-memory-down" you are strongly encouraged to provide an
+"fsp,memory-down-params{};" to specify how your memory is configured. If you
+do not set "fsp,enable-memory-down", then the DIMM SPD information will be
+discovered by the FSP and used to setup main memory.
+
+
+# Integer properties:
+
+- fsp,mrc-init-tseg-size
+- fsp,mrc-init-mmio-size
+- fsp,mrc-init-spd-addr1
+- fsp,mrc-init-spd-addr2
+- fsp,emmc-boot-mode
+- fsp,sata-mode
+- fsp,lpe-mode
+- fsp,lpss-sio-mode
+- fsp,igd-dvmt50-pre-alloc
+- fsp,aperture-size
+- fsp,gtt-size
+- fsp,scc-mode
+- fsp,os-selection
+- fsp,emmc45-retune-timer-value
+
+- fsp,memory-down-params {
+
+ # Boolean properties:
+
+ - fsp,dimm-0-enable
+ - fsp,dimm-1-enable
+
+ # Integer properties:
+
+ - fsp,dram-speed
+ - fsp,dram-type
+ - fsp,dimm-width
+ - fsp,dimm-density
+ - fsp,dimm-bus-width
+ - fsp,dimm-sides
+ - fsp,dimm-tcl
+ - fsp,dimm-trpt-rcd
+ - fsp,dimm-twr
+ - fsp,dimm-twtr
+ - fsp,dimm-trrd
+ - fsp,dimm-trtp
+ - fsp,dimm-tfaw
+};
+
+For all integer properties, available options are listed in fsp_configs.h in
+arch/x86/include/asm/arch-baytrail/fsp directory (eg: MRC_INIT_TSEG_SIZE_1MB).
+
+
+Example (from MinnowMax Dual Core):
+-----------------------------------
+
+/ {
+ ...
+
+ fsp {
+ compatible = "intel,baytrail-fsp";
+ fsp,mrc-init-tseg-size = <MRC_INIT_TSEG_SIZE_1MB>;
+ fsp,mrc-init-mmio-size = <MRC_INIT_MMIO_SIZE_2048MB>;
+ fsp,mrc-init-spd-addr1 = <0xa0>;
+ fsp,mrc-init-spd-addr2 = <0xa2>;
+ fsp,emmc-boot-mode = <EMMC_BOOT_MODE_AUTO>;
+ fsp,enable-sdio;
+ fsp,enable-sdcard;
+ fsp,enable-hsuart1;
+ fsp,enable-spi;
+ fsp,enable-sata;
+ fsp,sata-mode = <SATA_MODE_AHCI>;
+ fsp,lpe-mode = <LPE_MODE_PCI>;
+ fsp,lpss-sio-mode = <LPSS_SIO_MODE_PCI>;
+ fsp,enable-dma0;
+ fsp,enable-dma1;
+ fsp,enable-i2c0;
+ fsp,enable-i2c1;
+ fsp,enable-i2c2;
+ fsp,enable-i2c3;
+ fsp,enable-i2c4;
+ fsp,enable-i2c5;
+ fsp,enable-i2c6;
+ fsp,enable-pwm0;
+ fsp,enable-pwm1;
+ fsp,igd-dvmt50-pre-alloc = <IGD_DVMT50_PRE_ALLOC_64MB>;
+ fsp,aperture-size = <APERTURE_SIZE_256MB>;
+ fsp,gtt-size = <GTT_SIZE_2MB>;
+ fsp,scc-mode = <SCC_MODE_PCI>;
+ fsp,os-selection = <OS_SELECTION_LINUX>;
+ fsp,emmc45-ddr50-enabled;
+ fsp,emmc45-retune-timer-value = <8>;
+ fsp,enable-igd;
+ fsp,enable-memory-down;
+ fsp,memory-down-params {
+ compatible = "intel,baytrail-fsp-mdp";
+ fsp,dram-speed = <DRAM_SPEED_1066MTS>;
+ fsp,dram-type = <DRAM_TYPE_DDR3L>;
+ fsp,dimm-0-enable;
+ fsp,dimm-width = <DIMM_WIDTH_X16>;
+ fsp,dimm-density = <DIMM_DENSITY_4GBIT>;
+ fsp,dimm-bus-width = <DIMM_BUS_WIDTH_64BITS>;
+ fsp,dimm-sides = <DIMM_SIDES_1RANKS>;
+ fsp,dimm-tcl = <0xb>;
+ fsp,dimm-trpt-rcd = <0xb>;
+ fsp,dimm-twr = <0xc>;
+ fsp,dimm-twtr = <6>;
+ fsp,dimm-trrd = <6>;
+ fsp,dimm-trtp = <6>;
+ fsp,dimm-tfaw = <0x14>;
+ };
+ };
+
+ ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/intel,irq-router.txt b/roms/u-boot/doc/device-tree-bindings/misc/intel,irq-router.txt
new file mode 100644
index 000000000..09e97b430
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/intel,irq-router.txt
@@ -0,0 +1,61 @@
+Intel Interrupt Router Device Binding
+=====================================
+
+The device tree node which describes the operation of the Intel Interrupt Router
+device is as follows:
+
+Required properties :
+- reg : Specifies the interrupt router's PCI configuration space address as
+ defined by the Open Firmware spec.
+- compatible = "intel,irq-router"
+- intel,pirq-config : Specifies the IRQ routing register programming mechanism.
+ Valid values are:
+ "pci": IRQ routing is controlled by PCI configuration registers
+ "ibase": IRQ routing is in the memory-mapped IBASE register block
+- intel,ibase-offset : IBASE register offset in the interrupt router's PCI
+ configuration space, required only if intel,pirq-config = "ibase".
+- intel,actl-8bit : If ACTL (ACPI control) register width is 8-bit, this must
+ be specified. The 8-bit ACTL register is seen on ICH series chipset, like
+ ICH9/Panther Point/etc. On Atom chipset it is a 32-bit register.
+- intel,actl-addr : ACTL (ACPI control) register offset. ACTL can be either
+ in the interrupt router's PCI configuration space, or IBASE.
+- intel,pirq-link : Specifies the PIRQ link information with two cells. The
+ first cell is the register offset that controls the first PIRQ link routing.
+ The second cell is the total number of PIRQ links the router supports.
+- intel,pirq-regmap : Specifies PIRQ routing register offset of all PIRQ links,
+ encoded as 2 cells a group for each link. The first cell is the PIRQ link
+ number (0 for PIRQA, 1 for PIRQB, etc). The second cell is the PIRQ routing
+ register offset from the interrupt router's base address. If this property
+ is omitted, it indicates a consecutive register offset from the first PIRQ
+ link, as specified by the first cell of intel,pirq-link.
+- intel,pirq-mask : Specifies the IRQ mask representing the 16 IRQs in the
+ 8259 PIC. Bit N is 1 means IRQ N is available to be routed.
+- intel,pirq-routing : Specifies all PCI devices' IRQ routing information,
+ encoded as 3 cells a group for a device. The first cell is the device's PCI
+ bus number, device number and function number encoding with PCI_BDF() macro.
+ The second cell is the PCI interrupt pin used by this device. The last cell
+ is which PIRQ line the PCI interrupt pin is routed to.
+
+
+Example
+-------
+
+#include <dt-bindings/interrupt-router/intel-irq.h>
+
+ irq-router@1f,0 {
+ reg = <0x0000f800 0 0 0 0>;
+ compatible = "intel,irq-router";
+ intel,pirq-config = "pci";
+ intel,pirq-link = <0x60 8>;
+ intel,pirq-mask = <0xdef8>;
+ intel,pirq-routing = <
+ PCI_BDF(0, 2, 0) INTA PIRQA
+ PCI_BDF(0, 3, 0) INTA PIRQB
+ PCI_BDF(0, 8, 0) INTA PIRQC
+ PCI_BDF(0, 8, 1) INTB PIRQD
+ PCI_BDF(1, 6, 0) INTA PIRQE
+ PCI_BDF(1, 6, 1) INTB PIRQF
+ PCI_BDF(1, 6, 2) INTC PIRQG
+ PCI_BDF(1, 6, 3) INTD PIRQH
+ >;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/intel-lpc.txt b/roms/u-boot/doc/device-tree-bindings/misc/intel-lpc.txt
new file mode 100644
index 000000000..ba6ca9dbc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/intel-lpc.txt
@@ -0,0 +1,64 @@
+Intel LPC Device Binding
+========================
+
+The device tree node which describes the operation of the Intel Low Pin
+Count device is as follows:
+
+Required properties :
+- compatible = "intel,lpc"
+- intel,alt-gp-smi-enable : Enable SMI sources. This cell is written to the
+ ALT_GP_SMI_EN register
+- intel,gen-dec : Specifies the values for the gen-dec registers. Up to four
+ cell pairs can be provided - the first of each pair is the base address and
+ the second is the size. These are written into the GENx_DEC registers of
+ the LPC device
+- intel,gpi-routing : Specifies the GPI routing. There are 16 cells, valid
+ values are:
+ 0 No effect (default)
+ 1 SMI# (if corresponding ALT_GPI_SMI_EN bit is also set)
+ 2 SCI (if corresponding GPIO_EN bit is also set)
+- intel,pirq-routing : Speciffies the routing IRQ number for each of PIRQA-H,
+ one cell for each.
+ 0x00 - 0000 = Reserved
+ 0x01 - 0001 = Reserved
+ 0x02 - 0010 = Reserved
+ 0x03 - 0011 = IRQ3
+ 0x04 - 0100 = IRQ4
+ 0x05 - 0101 = IRQ5
+ 0x06 - 0110 = IRQ6
+ 0x07 - 0111 = IRQ7
+ 0x08 - 1000 = Reserved
+ 0x09 - 1001 = IRQ9
+ 0x0A - 1010 = IRQ10
+ 0x0B - 1011 = IRQ11
+ 0x0C - 1100 = IRQ12
+ 0x0D - 1101 = Reserved
+ 0x0E - 1110 = IRQ14
+ 0x0F - 1111 = IRQ15
+ PIRQ[n]_ROUT[7] - PIRQ Routing Control
+ 0x80 - The PIRQ is not routed.
+
+
+Example
+-------
+
+lpc {
+ compatible = "intel,lpc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ intel,gen-dec = <0x800 0xfc 0x900 0xfc>;
+
+ intel,pirq-routing = <0x8b 0x8a 0x8b 0x8b
+ 0x80 0x80 0x80 0x80>;
+ /*
+ * GPI routing
+ * 0 No effect (default)
+ * 1 SMI# (if corresponding ALT_GPI_SMI_EN bit is
+ * also set)
+ * 2 SCI (if corresponding GPIO_EN bit is also set)
+ */
+ intel,gpi-routing = <0 0 0 0 0 0 0 2
+ 1 0 0 0 0 0 0 0>;
+ /* Enable EC SMI source */
+ intel,alt-gp-smi-enable = <0x0100>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/misc/fsl,mpc83xx-serdes.txt b/roms/u-boot/doc/device-tree-bindings/misc/misc/fsl,mpc83xx-serdes.txt
new file mode 100644
index 000000000..64a9b5b15
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/misc/fsl,mpc83xx-serdes.txt
@@ -0,0 +1,24 @@
+MPC83xx SerDes controller devices
+
+MPC83xx SoCs contain a built-in SerDes controller that determines which
+protocols (SATA, PCI Express, SGMII, ...) are used on the system's serdes lines
+and how the lines are configured.
+
+Required properties:
+- compatible: must be "fsl,mpc83xx-serdes"
+- reg: must point to the serdes controller's register map
+- proto: selects for which protocol the serdes lines are configured. One of
+ "sata", "pex", "pex-x2", "sgmii"
+- serdes-clk: determines the frequency the serdes lines are configured for. One
+ of 100, 125, 150.
+- vdd: determines whether 1.0V core VDD is used or not
+
+Example:
+
+SERDES: serdes@e3000 {
+ reg = <0xe3000 0x200>;
+ compatible = "fsl,mpc83xx-serdes";
+ proto = "pex";
+ serdes-clk = <100>;
+ vdd;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,io-endpoint.txt b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,io-endpoint.txt
new file mode 100644
index 000000000..db2ff8ca1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,io-endpoint.txt
@@ -0,0 +1,20 @@
+gdsys IO endpoint of IHS FPGA devices
+
+The IO endpoint of IHS FPGA devices is a packet-based transmission interface
+that allows interconnected gdsys devices to send and receive data over the
+FPGA's main ethernet connection.
+
+Required properties:
+- compatible: must be "gdsys,io-endpoint"
+- reg: describes the address and length of the endpoint's register map (within
+ the FPGA's register space)
+
+Example:
+
+fpga0_ep0 {
+ compatible = "gdsys,io-endpoint";
+ reg = <0x020 0x10
+ 0x320 0x10
+ 0x340 0x10
+ 0x360 0x10>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocon_fpga.txt b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocon_fpga.txt
new file mode 100644
index 000000000..acd466fdc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocon_fpga.txt
@@ -0,0 +1,19 @@
+gdsys IHS FPGA for CON devices
+
+The gdsys IHS FPGA is the main FPGA on gdsys CON devices. This driver provides
+support for enabling and starting the FPGA, as well as verifying working bus
+communication.
+
+Required properties:
+- compatible: must be "gdsys,iocon_fpga"
+- reset-gpios: List of GPIOs controlling the FPGA's reset
+- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
+ done
+
+Example:
+
+FPGA0 {
+ compatible = "gdsys,iocon_fpga";
+ reset-gpios = <&PPCPCA 26 0>;
+ done-gpios = <&GPIO_VB0 19 0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocpu_fpga.txt b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocpu_fpga.txt
new file mode 100644
index 000000000..819db22bf
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,iocpu_fpga.txt
@@ -0,0 +1,19 @@
+gdsys IHS FPGA for CPU devices
+
+The gdsys IHS FPGA is the main FPGA on gdsys CPU devices. This driver provides
+support for enabling and starting the FPGA, as well as verifying working bus
+communication.
+
+Required properties:
+- compatible: must be "gdsys,iocpu_fpga"
+- reset-gpios: List of GPIOs controlling the FPGA's reset
+- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
+ done
+
+Example:
+
+FPGA0 {
+ compatible = "gdsys,iocpu_fpga";
+ reset-gpios = <&PPCPCA 26 0>;
+ done-gpios = <&GPIO_VB0 19 0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,soc.txt b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,soc.txt
new file mode 100644
index 000000000..278e935b1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/misc/misc/gdsys,soc.txt
@@ -0,0 +1,16 @@
+gdsys soc bus driver
+
+This driver provides a simple interface for the busses associated with gdsys
+IHS FPGAs. The bus itself contains devices whose register maps are contained
+within the FPGA's register space.
+
+Required properties:
+- fpga: A phandle to the controlling IHS FPGA
+
+Example:
+
+FPGA0BUS: fpga0bus {
+ compatible = "gdsys,soc";
+ ranges = <0x0 0xe0600000 0x00004000>;
+ fpga = <&FPGA0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/mmc/msm_sdhci.txt b/roms/u-boot/doc/device-tree-bindings/mmc/msm_sdhci.txt
new file mode 100644
index 000000000..08a290c66
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mmc/msm_sdhci.txt
@@ -0,0 +1,25 @@
+Qualcomm Snapdragon SDHCI controller
+
+Required properties:
+- compatible : "qcom,sdhci-msm-v4"
+- reg: Base address and length of registers:
+ - Host controller registers (SDHCI)
+ - SD Core registers
+- clock: interface clock (must accept SD bus clock as a frequency)
+
+Optional properties:
+- index: If there is more than one controller - controller index (required
+ by generic SDHCI code).
+- bus_width: Width of SD/eMMC bus (default 4)
+- clock-frequency: Frequency of SD/eMMC bus (default 400 kHz)
+
+Example:
+
+sdhci@07864000 {
+ compatible = "qcom,sdhci-msm-v4";
+ reg = <0x7864900 0x11c 0x7864000 0x800>;
+ index = <0x1>;
+ bus-width = <0x4>;
+ clock = <&clkc 1>;
+ clock-frequency = <200000000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/mmc/snps,dw-mmc.txt b/roms/u-boot/doc/device-tree-bindings/mmc/snps,dw-mmc.txt
new file mode 100644
index 000000000..69faefa95
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mmc/snps,dw-mmc.txt
@@ -0,0 +1,33 @@
+Synopsys Designware Mobile Storage Host Controller extensions
+used in Synopsys ARC devboards
+
+Required Properties:
+
+* compatible: should be - "snps,dw-mshc".
+* bus-width: number of data lines connected to the controller.
+* clocks: from common clock binding: handle to biu and ciu clocks for the
+ bus interface unit clock and the card interface unit clock.
+* clock-names: from common clock binding: Shall be "biu" and "ciu".
+
+Optional properties:
+
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
+ specified, the default value of the fifo size is determined from the
+ controller registers.
+* fifo-mode: Don't use DMA.
+* max-frequency: Maximum operating clock frequency, driver uses 'ciu' clock
+ frequency if it is not set.
+
+Example:
+
+mmc0@f000a000 {
+ compatible = "snps,dw-mshc";
+ reg = <0xf000a000 0x400>;
+
+ bus-width = <4>;
+ fifo-depth = <256>;
+ clocks = <&mmcclk_biu>, <&mmcclk_ciu>;
+ clock-names = "biu", "ciu";
+ max-frequency = <25000000>;
+};
+
diff --git a/roms/u-boot/doc/device-tree-bindings/mtd/altera_qspi.txt b/roms/u-boot/doc/device-tree-bindings/mtd/altera_qspi.txt
new file mode 100644
index 000000000..3361ac92a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mtd/altera_qspi.txt
@@ -0,0 +1,35 @@
+Altera QUADSPI driver
+
+Required properties:
+- compatible: Should be "altr,quadspi-1.0"
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ "avl_csr": Should contain the register configuration base address
+ "avl_mem": Should contain the data base address
+- #address-cells: Must be <1>.
+- #size-cells: Must be <0>.
+- flash device tree subnode, there must be a node with the following fields:
+ - compatible: Should contain the flash name:
+ 1. EPCS: epcs16, epcs64, epcs128
+ 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024
+ 3. EPCQ-L: epcql256, epcql512, epcql1024
+ - #address-cells: please refer to /mtd/partition.txt
+ - #size-cells: please refer to /mtd/partition.txt
+ For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+ quadspi_controller_0: quadspi@0x180014a0 {
+ compatible = "altr,quadspi-1.0";
+ reg = <0x180014a0 0x00000020>,
+ <0x14000000 0x04000000>;
+ reg-names = "avl_csr", "avl_mem";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ flash0: epcq512@0 {
+ compatible = "altr,epcq512";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/mtd/mtd-physmap.txt b/roms/u-boot/doc/device-tree-bindings/mtd/mtd-physmap.txt
new file mode 100644
index 000000000..4b8c48943
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mtd/mtd-physmap.txt
@@ -0,0 +1,88 @@
+CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
+
+Flash chips (Memory Technology Devices) are often used for solid state
+file systems on embedded devices.
+
+ - compatible : should contain the specific model of mtd chip(s)
+ used, if known, followed by either "cfi-flash", "jedec-flash",
+ "mtd-ram" or "mtd-rom".
+ - reg : Address range(s) of the mtd chip(s)
+ It's possible to (optionally) define multiple "reg" tuples so that
+ non-identical chips can be described in one node.
+ - bank-width : Width (in bytes) of the bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single mtd chip. If
+ omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the device has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+ - no-unaligned-direct-access: boolean to disable the default direct
+ mapping of the flash.
+ On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause
+ problems with JFFS2 usage, as the local bus (LPB) doesn't support
+ unaligned accesses as implemented in the JFFS2 code via memcpy().
+ By defining "no-unaligned-direct-access", the flash will not be
+ exposed directly to the MTD users (e.g. JFFS2) any more.
+ - linux,mtd-name: allow to specify the mtd name for retro capability with
+ physmap-flash drivers as boot loader pass the mtd partition via the old
+ device name physmap-flash.
+ - use-advanced-sector-protection: boolean to enable support for the
+ advanced sector protection (Spansion: PPB - Persistent Protection
+ Bits) locking.
+
+For JEDEC compatible devices, the following additional properties
+are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+For ROM compatible devices (and ROM fallback from cfi-flash), the following
+additional (optional) property is defined:
+
+ - erase-size : The chip's physical erase block size in bytes.
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+ flash@ff000000 {
+ compatible = "amd,am29lv128ml", "cfi-flash";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ device-width = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ label = "fs";
+ reg = <0 f80000>;
+ };
+ firmware@f80000 {
+ label ="firmware";
+ reg = <f80000 80000>;
+ read-only;
+ };
+ };
+
+Here an example with multiple "reg" tuples:
+
+ flash@f0000000,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "intel,pc48f4400p0vb", "cfi-flash";
+ reg = <0 0x00000000 0x02000000
+ 0 0x02000000 0x02000000>;
+ bank-width = <2>;
+ partition@0 {
+ label = "test-part1";
+ reg = <0 0x04000000>;
+ };
+ };
+
+An example using SRAM:
+
+ sram@2,0 {
+ compatible = "samsung,k6f1616u6a", "mtd-ram";
+ reg = <2 0 0x00200000>;
+ bank-width = <2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/mtd/spi-nand.txt b/roms/u-boot/doc/device-tree-bindings/mtd/spi-nand.txt
new file mode 100644
index 000000000..8b51f3b6d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mtd/spi-nand.txt
@@ -0,0 +1,5 @@
+SPI NAND flash
+
+Required properties:
+- compatible: should be "spi-nand"
+- reg: should encode the chip-select line used to access the NAND chip
diff --git a/roms/u-boot/doc/device-tree-bindings/mtd/spi/spi-flash.txt b/roms/u-boot/doc/device-tree-bindings/mtd/spi/spi-flash.txt
new file mode 100644
index 000000000..332789026
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mtd/spi/spi-flash.txt
@@ -0,0 +1,25 @@
+* MTD SPI driver for serial flash chips
+
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+- compatible : Should be the manufacturer and the name of the chip. Bear in
+ mind that the DT binding is not U-Boot-only, but in case of
+ U-Boot, see spi_flash_params_table table in
+ drivers/mtd/spi/spi_flash_ids.c for the list of supported chips.
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+
+Optional properties:
+ - memory-map : Address and size of the flash, if memory mapped. This may
+ apply to Intel chipsets, which tend to memory-map flash.
+
+Example:
+
+ flash: m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,m25p80";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt b/roms/u-boot/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
new file mode 100644
index 000000000..ad2bef826
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
@@ -0,0 +1,61 @@
+STMicroelectronics Flexible Memory Controller 2 (FMC2)
+NAND Interface
+
+Required properties:
+- compatible: Should be one of:
+ * st,stm32mp15-fmc2
+- reg: NAND flash controller memory areas.
+ First region contains the register location.
+ Regions 2 to 4 respectively contain the data, command,
+ and address space for CS0.
+ Regions 5 to 7 contain the same areas for CS1.
+- interrupts: The interrupt number
+- pinctrl-0: Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
+- clocks: The clock needed by the NAND flash controller
+
+Optional properties:
+- resets: Reference to a reset controller asserting the FMC controller
+- dmas: DMA specifiers (see: dma/stm32-mdma.txt)
+- dma-names: Must be "tx", "rx" and "ecc"
+
+* NAND device bindings:
+
+Required properties:
+- reg: describes the CS lines assigned to the NAND device.
+
+Optional properties:
+- nand-on-flash-bbt: see nand.txt
+- nand-ecc-strength: see nand.txt
+- nand-ecc-step-size: see nand.txt
+
+The following ECC strength and step size are currently supported:
+ - nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Hamming)
+ - nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
+ - nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8) (default)
+
+Example:
+
+ fmc: nand-controller@58002000 {
+ compatible = "st,stm32mp15-fmc2";
+ reg = <0x58002000 0x1000>,
+ <0x80000000 0x1000>,
+ <0x88010000 0x1000>,
+ <0x88020000 0x1000>,
+ <0x81000000 0x1000>,
+ <0x89010000 0x1000>,
+ <0x89020000 0x1000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc FMC_K>;
+ resets = <&rcc FMC_R>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fmc_pins_a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-on-flash-bbt;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt b/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt
new file mode 100644
index 000000000..86ae4082d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt
@@ -0,0 +1,53 @@
+NAND Flash
+----------
+
+(there isn't yet a generic binding in Linux, so this describes what is in
+U-Boot. There should not be Linux-specific or U-Boot specific binding, just
+a binding that describes this hardware. But agreeing a binding in Linux in
+the absence of a driver may be beyond my powers.)
+
+The device node for a NAND flash device is as follows:
+
+Required properties :
+ - compatible : Should be "manufacturer,device", "nand-flash"
+
+This node should sit inside its controller.
+
+
+Nvidia NAND Controller
+----------------------
+
+The device node for a NAND flash controller is as follows:
+
+Optional properties:
+
+nvidia,wp-gpios : GPIO of write-protect line, three cells in the format:
+ phandle, parameter, flags
+nvidia,nand-width : bus width of the NAND device in bits
+
+ - nvidia,nand-timing : Timing parameters for the NAND. Each is in ns.
+ Order is: MAX_TRP_TREA, TWB, Max(tCS, tCH, tALS, tALH),
+ TWHR, Max(tCS, tCH, tALS, tALH), TWH, TWP, TRH, TADL
+
+ MAX_TRP_TREA is:
+ non-EDO mode: Max(tRP, tREA) + 6ns
+ EDO mode: tRP timing
+
+The 'reg' property should provide the chip select used by the flash chip.
+
+
+Example
+-------
+
+nand-controller@0x70008000 {
+ compatible = "nvidia,tegra20-nand";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nvidia,wp-gpios = <&gpio 59 0>; /* PH3 */
+ nvidia,nand-width = <8>;
+ nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+ nand@0 {
+ reg = <0>;
+ compatible = "hynix,hy27uf4g2b", "nand-flash";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000000000..10640b17c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,19 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-a10-emac" (Deprecated:
+ "allwinner,sun4i-emac")
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: see ethernet.txt file in the same directory.
+- clocks: A phandle to the reference clock for this device
+
+Example:
+
+emac: ethernet@01c0b000 {
+ compatible = "allwinner,sun4i-a10-emac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ clocks = <&ahb_gates 17>;
+ phy = <&phy0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 000000000..4ec564137
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,27 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "allwinner,sun4i-a10-mdio"
+ (Deprecated: "allwinner,sun4i-mdio").
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Example at the SoC level:
+mdio@01c0b080 {
+ compatible = "allwinner,sun4i-a10-mdio";
+ reg = <0x01c0b080 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+And at the board level:
+
+mdio@01c0b080 {
+ phy-supply = <&reg_emac_3v3>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
new file mode 100644
index 000000000..ea4d75238
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
@@ -0,0 +1,27 @@
+* Allwinner GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+ - compatible: Should be "allwinner,sun7i-a20-gmac"
+ - clocks: Should contain the GMAC main clock, and tx clock
+ The tx clock type should be "allwinner,sun7i-a20-gmac-clk"
+ - clock-names: Should contain the clock names "stmmaceth",
+ and "allwinner_gmac_tx"
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Examples:
+
+ gmac: ethernet@01c50000 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c50000 0x10000>,
+ <0x01c20164 0x4>;
+ interrupts = <0 85 1>;
+ interrupt-names = "macirq";
+ clocks = <&ahb_gates 49>, <&gmac_tx>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ phy-mode = "mii";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/net/altera_tse.txt b/roms/u-boot/doc/device-tree-bindings/net/altera_tse.txt
new file mode 100644
index 000000000..cb190df65
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/altera_tse.txt
@@ -0,0 +1,112 @@
+* Altera Triple-Speed Ethernet MAC driver (TSE)
+
+Required properties:
+- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should
+ be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE.
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ "control_port": MAC configuration space region
+ "tx_csr": xDMA Tx dispatcher control and status space region
+ "tx_desc": MSGDMA Tx dispatcher descriptor space region
+ "rx_csr" : xDMA Rx dispatcher control and status space region
+ "rx_desc": MSGDMA Rx dispatcher descriptor space region
+ "rx_resp": MSGDMA Rx dispatcher response space region
+ "s1": SGDMA descriptor memory
+- interrupts: Should contain the TSE interrupts and it's mode.
+- interrupt-names: Should contain the interrupt names
+ "rx_irq": xDMA Rx dispatcher interrupt
+ "tx_irq": xDMA Tx dispatcher interrupt
+- rx-fifo-depth: MAC receive FIFO buffer depth in bytes
+- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes
+- phy-mode: See ethernet.txt in the same directory.
+- phy-handle: See ethernet.txt in the same directory.
+- phy-addr: See ethernet.txt in the same directory. A configuration should
+ include phy-handle or phy-addr.
+- altr,has-supplementary-unicast:
+ If present, TSE supports additional unicast addresses.
+ Otherwise additional unicast addresses are not supported.
+- altr,has-hash-multicast-filter:
+ If present, TSE supports a hash based multicast filter.
+ Otherwise, hash-based multicast filtering is not supported.
+
+- mdio device tree subnode: When the TSE has a phy connected to its local
+ mdio, there must be device tree subnode with the following
+ required properties:
+
+ - compatible: Must be "altr,tse-mdio".
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+
+ For each phy on the mdio bus, there must be a node with the following
+ fields:
+
+ - reg: phy id used to communicate to phy.
+ - device_type: Must be "ethernet-phy".
+
+Optional properties:
+- local-mac-address: See ethernet.txt in the same directory.
+- max-frame-size: See ethernet.txt in the same directory.
+
+Example:
+
+ tse_sub_0_eth_tse_0: ethernet@0x1,00000000 {
+ compatible = "altr,tse-msgdma-1.0";
+ reg = <0x00000001 0x00000000 0x00000400>,
+ <0x00000001 0x00000460 0x00000020>,
+ <0x00000001 0x00000480 0x00000020>,
+ <0x00000001 0x000004A0 0x00000008>,
+ <0x00000001 0x00000400 0x00000020>,
+ <0x00000001 0x00000420 0x00000020>;
+ reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
+ interrupt-parent = <&hps_0_arm_gic_0>;
+ interrupts = <0 41 4>, <0 40 4>;
+ interrupt-names = "rx_irq", "tx_irq";
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ address-bits = <48>;
+ max-frame-size = <1500>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ phy-mode = "gmii";
+ altr,has-supplementary-unicast;
+ altr,has-hash-multicast-filter;
+ phy-handle = <&phy0>;
+ mdio {
+ compatible = "altr,tse-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ device_type = "ethernet-phy";
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ device_type = "ethernet-phy";
+ };
+
+ };
+ };
+
+ tse_sub_1_eth_tse_0: ethernet@0x1,00001000 {
+ compatible = "altr,tse-msgdma-1.0";
+ reg = <0x00000001 0x00001000 0x00000400>,
+ <0x00000001 0x00001460 0x00000020>,
+ <0x00000001 0x00001480 0x00000020>,
+ <0x00000001 0x000014A0 0x00000008>,
+ <0x00000001 0x00001400 0x00000020>,
+ <0x00000001 0x00001420 0x00000020>;
+ reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
+ interrupt-parent = <&hps_0_arm_gic_0>;
+ interrupts = <0 43 4>, <0 42 4>;
+ interrupt-names = "rx_irq", "tx_irq";
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ address-bits = <48>;
+ max-frame-size = <1500>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ phy-mode = "gmii";
+ altr,has-supplementary-unicast;
+ altr,has-hash-multicast-filter;
+ phy-handle = <&phy1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/net/aquantia-phy.txt b/roms/u-boot/doc/device-tree-bindings/net/aquantia-phy.txt
new file mode 100644
index 000000000..89ce61e05
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/aquantia-phy.txt
@@ -0,0 +1,25 @@
+PHY nodes for Aquantia devices.
+
+This text describes properties that are applicable to Aquantia PHY nodes in
+addition to the bindings in phy.txt.
+
+Aquantia PHYs allow some flexibility in the way they are wired in a system,
+they allow MDI pins to be reversed, LEDs linked up in different weays, have an
+I2C slave interface that can be used for debug. Normally the configuration
+corresponding to these is driven by the PHY firmware with the downside that
+a custom firmware is needed for each integration of a PHY.
+Several optional bindings are defined that allow these configuration points to
+be driven by the PHY driver and reduce dependency on specific FW versions.
+
+Optional properties:
+mdi-reversal: 0 or 1 indicating that reversal must be disabled/enabled.
+ Firmware default is used if the property is missing.
+smb-addr: I2C/SMBus address to use, firmware default is used if the property
+ is missing.
+
+Example node:
+phy@00 {
+ reg = <0x00>;
+ mdi-reversal = <1>;
+ smb-addr = <0x25>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/ethernet.txt b/roms/u-boot/doc/device-tree-bindings/net/ethernet.txt
new file mode 100644
index 000000000..cfc376bc9
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/ethernet.txt
@@ -0,0 +1,66 @@
+The following properties are common to the Ethernet controllers:
+
+NOTE: All 'phy*' properties documented below are Ethernet specific. For the
+generic PHY 'phys' property, see
+Documentation/devicetree/bindings/phy/phy-bindings.txt.
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+ assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last used by
+ the boot program; should be used in cases where the MAC address assigned to
+ the device by the boot program is different from the "local-mac-address"
+ property;
+- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
+- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
+- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
+ the maximum frame size (there's contradiction in the Devicetree
+ Specification).
+- phy-mode: string, operation mode of the PHY interface. This is now a de-facto
+ standard property; supported values are:
+ * "internal"
+ * "mii"
+ * "gmii"
+ * "sgmii"
+ * "qsgmii"
+ * "tbi"
+ * "rev-mii"
+ * "rmii"
+ * "rgmii" (RX and TX delays are added by the MAC when required)
+ * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the
+ MAC should not add the RX or TX delays in this case)
+ * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
+ should not add an RX delay in this case)
+ * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
+ should not add an TX delay in this case)
+ * "rtbi"
+ * "smii"
+ * "xgmii"
+ * "trgmii"
+ * "2000base-x",
+ * "2500base-x",
+ * "rxaui"
+ * "xaui"
+ * "10gbase-kr" (10GBASE-KR, XFI, SFI)
+- phy-connection-type: the same as "phy-mode" property but described in the
+ Devicetree Specification;
+- phy-handle: phandle, specifies a reference to a node representing a PHY
+ device; this property is described in the Devicetree Specification and so
+ preferred;
+- phy: the same as "phy-handle" property, not recommended for new bindings.
+- phy-device: the same as "phy-handle" property, not recommended for new
+ bindings.
+- rx-fifo-depth: the size of the controller's receive fifo in bytes. This
+ is used for components that can have configurable receive fifo sizes,
+ and is useful for determining certain configuration settings such as
+ flow control thresholds.
+- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
+ is used for components that can have configurable fifo sizes.
+- managed: string, specifies the PHY management type. Supported values are:
+ "auto", "in-band-status". "auto" is the default, it usess MDIO for
+ management if fixed-link is not specified.
+
+Child nodes of the Ethernet controller are typically the individual PHY devices
+connected via the MDIO bus (sometimes the MDIO bus controller is separate).
+They are described in the phy.txt file in this same directory.
+For non-MDIO PHY management see fixed-link.txt.
diff --git a/roms/u-boot/doc/device-tree-bindings/net/fixed-link.txt b/roms/u-boot/doc/device-tree-bindings/net/fixed-link.txt
new file mode 100644
index 000000000..5efeeb6fc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/fixed-link.txt
@@ -0,0 +1,54 @@
+Fixed link Device Tree binding
+------------------------------
+
+Some Ethernet MACs have a "fixed link", and are not connected to a
+normal MDIO-managed PHY device. For those situations, a Device Tree
+binding allows to describe a "fixed link".
+
+Note there are two ways to describe a fixed PHY attached to an
+Ethernet device:
+
+- The new DT binding, where 'fixed-link' is a sub-node of the Ethernet
+ MAC device node, with the following properties:
+
+ * 'speed' (integer, mandatory), to indicate the link speed. Accepted
+ values are 10, 100 and 1000
+ * 'full-duplex' (boolean, optional), to indicate that full duplex is
+ used. When absent, half duplex is assumed.
+ * 'pause' (boolean, optional), to indicate that pause should be
+ enabled.
+ * 'asym-pause' (boolean, optional), to indicate that asym_pause should
+ be enabled.
+
+- The old DT binding, where 'fixed-link' is a property with 5 cells
+ encoding various information about the fixed PHY, in the form of
+ <phy_id, full-duplex, speed, pause, asym-pause>.
+
+ * 'phy_id', emulated PHY ID, choose any but unique to the all specified
+ fixed-links. Note U-Boot deliberately ignores the 'phy_id' and
+ unconditionally uses PHY_FIXED_ID.
+ * 'full-duplex', 0 for half duplex or 1 for full duplex
+ * 'speed', link speed in Mbits/sec, accepts only 10, 100 and 1000
+ * 'pause', 0 for no pause, 1 for pause
+ * 'asym-pause', 0 for no asymmetric pause, 1 for asymmetric pause
+
+Examples:
+
+The new binding:
+
+ethernet@0 {
+ ...
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ ...
+};
+
+The old binding:
+
+ethernet@0 {
+ ...
+ fixed-link = <0 1 1000 0 0>;
+ ...
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-dma-fec.txt b/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-dma-fec.txt
new file mode 100644
index 000000000..e237825ba
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-dma-fec.txt
@@ -0,0 +1,35 @@
+* Freescale ColdFire DMA-FEC ethernet controller
+
+Required properties:
+- compatible: should be "fsl,mcf-dma-fec"
+- reg: address and length of the register set for the device.
+- rx-task: dma channel
+- tx-task: dma channel
+- rx-priority: dma channel
+- tx-priority: dma channel
+- rx-init: dma channel
+- tx-init: dma channel
+
+Optional properties:
+- mii-base: index of FEC reg area, 0 for FEC0, 1 for FEC1
+- max-speed: max speedm Mbits/sec
+- phy-addr: phy address
+- timeout-loop: integer value for driver loops time out
+
+
+Example:
+
+fec0: ethernet@9000 {
+ compatible = "fsl,mcf-dma-fec";
+ reg = <0x9000 0x800>;
+ mii-base = <0>;
+ phy-addr = <0>;
+ timeout-loop = <5000>;
+ rx-task = <0>;
+ tx-task = <1>;
+ rx-piority = <6>;
+ tx-piority = <7>;
+ rx-init = <16>;
+ tx-init = <17>;
+ status = "disabled";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-fec.txt b/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-fec.txt
new file mode 100644
index 000000000..39bbaa52f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/fsl,mcf-fec.txt
@@ -0,0 +1,22 @@
+* Freescale ColdFire FEC ethernet controller
+
+Required properties:
+- compatible: should be "fsl,mcf-fec"
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- mii-base: index of FEC reg area, 0 for FEC0, 1 for FEC1
+- max-speed: max speedm Mbits/sec
+- phy-addr: phy address
+- timeout-loop: integer value for driver loops time out
+
+
+Example:
+
+fec0: ethernet@fc030000 {
+ compatible = "fsl,mcf-fec";
+ reg = <0xfc030000 0x400>;
+ mii-base = <0>;
+ phy-addr = <0>;
+ timeout-loop = <5000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/fsl-tsec-phy.txt b/roms/u-boot/doc/device-tree-bindings/net/fsl-tsec-phy.txt
new file mode 100644
index 000000000..f68980352
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/fsl-tsec-phy.txt
@@ -0,0 +1,81 @@
+* TSEC-compatible ethernet nodes
+
+Properties:
+
+ - compatible : Should be "fsl,etsec2" or "gianfar"
+ - reg : Offset and length of the register set for the device. If this is
+ missing, a subnode with a name prefix "queue-group" must be provided to
+ provide the <reg> property.
+ - phy-handle : See ethernet.txt file in the same directory.
+ - phy-connection-type : See ethernet.txt file in the same directory. This
+ property is only really needed if the connection is of type "rgmii-id",
+ "rgmii-rxid" and "rgmii-txid" as all other connection types are detected
+ by hardware.
+ - ranges : an <empty> value if subnode "queue-group" is present, specifying
+ that no address translation is required between them TSEC parent node and
+ the child "queue-group" node.
+
+Example:
+ ethernet@24000 {
+ compatible = "fsl,etsec2";
+ reg = <0x24000 0x1000>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "sgmii";
+ };
+
+An alternate description with "queue-group" subnode example:
+ ethernet@24000 {
+ compatible = "fsl,etsec2";
+ phy-handle = <&phy0>;
+ phy-connection-type = "sgmii";
+ ranges;
+
+ queue-group {
+ reg = <0x24000 0x1000>;
+ };
+ };
+
+Child nodes of the TSEC controller are typically the individual PHY devices
+connected via the MDIO bus (sometimes the MDIO bus controller is separate).
+
+* MDIO IO device
+
+The MDIO is a bus to which the PHY devices are connected. For each
+device that exists on this bus, a PHY node should be created.
+
+Required properties:
+ - compatible : Should define the compatible device type for the
+ mdio. Currently supported string/device is "fsl,etsec2-mdio".
+ - reg : Offset and length of the register set for the device
+
+Example:
+
+ mdio@24520 {
+ compatible = "fsl,etsec2-mdio";
+ reg = <0x24520 0x20>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+* TBI Internal MDIO bus
+
+As of this writing, every tsec is associated with an internal TBI PHY.
+This PHY is accessed through the local MDIO bus. These buses are defined
+similarly to the mdio buses. The TBI PHYs underneath them are similar to
+normal PHYs, but the reg property is considered instructive, rather than
+descriptive. The reg property should be chosen so it doesn't interfere
+with other PHYs on the bus. The TBI PHYs are referred to by a "tbi-handle"
+property under the tsec node, which has a similar meaning of "phy-handle".
+
+Example:
+ ethernet@24000 {
+ phy-handle = <&tbi1>;
+ };
+
+ mdio@24520 {
+ tbi1: tbi-phy@1f {
+ reg = <0x1f>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/net/marvell-mdio.txt b/roms/u-boot/doc/device-tree-bindings/net/marvell-mdio.txt
new file mode 100644
index 000000000..e2038e214
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/marvell-mdio.txt
@@ -0,0 +1,15 @@
+* Marvell MDIO Ethernet Controller interface
+
+The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k
+have an identical unit that provides an interface with the MDIO bus.
+This driver handles this MDIO interface.
+
+Mandatory properties:
+SoC specific:
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+ - compatible: Should be "marvell,orion-mdio" (for SMI)
+ "marvell,xmdio" (for XSMI)
+ - reg: Base address and size SMI/XMSI bus.
+
+Please refer to "mdio.txt" for generic MDIO bus bindings.
diff --git a/roms/u-boot/doc/device-tree-bindings/net/mdio-mux-reg.txt b/roms/u-boot/doc/device-tree-bindings/net/mdio-mux-reg.txt
new file mode 100644
index 000000000..0ac34dc42
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/mdio-mux-reg.txt
@@ -0,0 +1,82 @@
+Device tree structures used by register based MDIO muxes is described here.
+This binding is based on reg-mux.txt binding in Linux and is currently used by
+mdio-mux-i2creg driver in U-Boot.
+
+Required properties:
+#mux-control-cells = <1> indicates how many registers are used for mux
+ selection. mux-reg-mask property described below must
+ include this number of pairs.
+mux-reg-masks = <reg mask> describes pairs of register offset and register mask.
+ Register bits enabled in mask are set to the selection
+ value defined in reg property of child MDIOs to control
+ selection.
+Properties described in mdio-mux.txt also apply.
+
+Example structure, used on Freescale LS1028A QDS board:
+
+&i2c0 {
+ status = "okay";
+ u-boot,dm-pre-reloc;
+
+ fpga@66 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "simple-mfd";
+ reg = <0x66>;
+
+ mux-mdio@54 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "mdio-mux-i2creg";
+ reg = <0x54>;
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x54 0xf0>;
+ mdio-parent-bus = <&mdio0>;
+
+ /* on-board MDIO with a single RGMII PHY */
+ mdio@00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x00>;
+
+ /* on-board 1G RGMII PHY */
+ qds_phy0: phy@5 {
+ reg = <5>;
+ };
+ };
+ /* card slot 1 */
+ mdio@40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x40>;
+ /* VSC8234 1G SGMII card */
+ sgmii_port0: phy@1c {
+ reg = <0x1c>;
+ };
+ };
+ /* card slot 2 */
+ mdio@50 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x50>;
+ };
+ /* card slot 3 */
+ mdio@60 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x60>;
+ };
+ /* card slot 4 */
+ mdio@70 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ };
+ };
+ };
+};
+
+/* Parent MDIO, defined in SoC .dtsi file, just enabled here */
+&mdio0 {
+ status = "okay";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/mdio-mux.txt b/roms/u-boot/doc/device-tree-bindings/net/mdio-mux.txt
new file mode 100644
index 000000000..eaa31efda
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/mdio-mux.txt
@@ -0,0 +1,138 @@
+The expected structure of an MDIO MUX device tree node is described here. This
+is heavily based on current Linux specification.
+One notable difference to Linux is that mdio-parent-bus is currently required
+by U-Boot, not optional as is in Linux. Current U-Boot MDIO MUX udevice class
+implementation does not have specific support for MDIOs with an integrated MUX,
+the property should be made optional if such support is added.
+
+The MDIO buses downstream of the MUX should be described in the device tree as
+child nodes as indicated below.
+
+Required properties:
+mdio-parent-bus = a phandle to the MDIO bus used to perform actual I/O. This is
+ typically a real MDIO device, unless there are cascaded MUXes.
+#address-cells = <1>, each MDIO group is identified by one 32b value.
+#size-cells = <0>
+
+Other properties:
+The properties described here are sufficient for MDIO MUX DM class code, but
+MUX drivers may define additional properties, either required or optional.
+
+Required properties in child nodes:
+reg = value to be configured on the MUX to select the respective downstream
+ MDIO.
+
+Child nodes should normally contain PHY nodes, referenced by phandle from
+ethernet nodes of the eth interfaces using these PHYs.
+
+Example structure, extracted from Linux bindings document:
+
+ /* The parent MDIO bus. */
+ smi1: mdio@1180000001900 {
+ compatible = "cavium,octeon-3860-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x11800 0x00001900 0x0 0x40>;
+ };
+ /*
+ * An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
+ * pair of GPIO lines. Child busses 2 and 3 populated with 4
+ * PHYs each.
+ */
+ mdio-mux {
+ compatible = "mdio-mux-gpio";
+ gpios = <&gpio1 3 0>, <&gpio1 4 0>;
+ mdio-parent-bus = <&smi1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy11: ethernet-phy@1 {
+ reg = <1>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy12: ethernet-phy@2 {
+ reg = <2>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy13: ethernet-phy@3 {
+ reg = <3>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ phy14: ethernet-phy@4 {
+ reg = <4>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <10 8>; /* Pin 10, active low */
+ };
+ };
+ mdio@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy21: ethernet-phy@1 {
+ reg = <1>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <12 8>; /* Pin 12, active low */
+ };
+ phy22: ethernet-phy@2 {
+ reg = <2>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <12 8>; /* Pin 12, active low */
+ };
+ phy23: ethernet-phy@3 {
+ reg = <3>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <12 8>; /* Pin 12, active low */
+ };
+ phy24: ethernet-phy@4 {
+ reg = <4>;
+ compatible = "marvell,88e1149r";
+ marvell,reg-init = <3 0x10 0 0x5777>,
+ <3 0x11 0 0x00aa>,
+ <3 0x12 0 0x4105>,
+ <3 0x13 0 0x0a60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <12 8>; /* Pin 12, active low */
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/net/mdio.txt b/roms/u-boot/doc/device-tree-bindings/net/mdio.txt
new file mode 100644
index 000000000..159532505
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/mdio.txt
@@ -0,0 +1,36 @@
+Common MDIO bus properties.
+
+These are generic properties that can apply to any MDIO bus.
+
+Optional properties:
+ - device-name - If present it is used to name the device and MDIO bus.
+ The name must be unique and must not contain spaces.
+
+A list of child nodes, one per device on the bus is expected. These could be
+PHYs, switches or similar devices and child nodes should follow the specific
+binding for the device type.
+
+Example :
+This example shows the structure used for the external MDIO bus on NXP LS1028A
+RDB board. Note that this MDIO device is an integrated PCI function and
+requires no compatible property for probing.
+
+/* definition in SoC dtsi file */
+ pcie@1f0000000 {
+
+ mdio0: pci@0,3 {
+ #address-cells=<0>;
+ #size-cells=<1>;
+ reg = <0x000300 0 0 0 0>;
+ status = "disabled";
+ device-name = "emdio";
+ };
+ };
+/* definition of PHYs in RDB dts file */
+&mdio0 {
+ status = "okay";
+ rdb_phy0: phy@2 {
+ reg = <2>;
+ };
+};
+
diff --git a/roms/u-boot/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt b/roms/u-boot/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
new file mode 100644
index 000000000..ec97504a3
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
@@ -0,0 +1,17 @@
+* MediaTek Frame Engine Ethernet controller
+
+Required properties:
+- compatible: should be "mediatek,mt7628-eth"
+- reg: address and length of the register set for the frame
+ engine ethernet controller and the internal switch.
+- syscon: phandle to the system controller
+
+Example:
+
+eth@10100000 {
+ compatible = "mediatek,mt7628-eth";
+ reg = <0x10100000 0x10000
+ 0x10110000 0x8000>;
+
+ syscon = <&sysc>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/micrel-ksz90x1.txt b/roms/u-boot/doc/device-tree-bindings/net/micrel-ksz90x1.txt
new file mode 100644
index 000000000..a214d35fc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/micrel-ksz90x1.txt
@@ -0,0 +1,192 @@
+Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
+
+Some boards require special tuning values, particularly when it comes to
+clock delays. You can specify clock delay values by adding
+micrel-specific properties to an Ethernet OF device node.
+
+Note that these settings are applied after any phy-specific fixup from
+phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
+and therefore may overwrite them.
+
+KSZ9021:
+
+ All skew control options are specified in picoseconds. The minimum
+ value is 0, the maximum value is 1800, and it is incremented by 120ps
+ steps.
+
+ The KSZ9021 hardware supports a range of skew values from negative to
+ positive, where the specific range is property dependent. All values
+ specified in the devicetree are offset by the minimum value so they
+ can be represented as positive integers in the devicetree since it's
+ difficult to represent a negative number in the devictree.
+
+ The following 4-bit values table applies to all the skew properties:
+
+ Pad Skew Value Delay (ps) Devicetree Value
+ ------------------------------------------------------
+ 0000 -840ps 0
+ 0001 -720ps 120
+ 0010 -600ps 240
+ 0011 -480ps 360
+ 0100 -360ps 480
+ 0101 -240ps 600
+ 0110 -120ps 720
+ 0111 0ps 840
+ 1000 120ps 960
+ 1001 240ps 1080
+ 1010 360ps 1200
+ 1011 480ps 1320
+ 1100 600ps 1440
+ 1101 720ps 1560
+ 1110 840ps 1680
+ 1111 960ps 1800
+
+ Optional properties:
+
+ - rxc-skew-ps : Skew control of RXC pad
+ - rxdv-skew-ps : Skew control of RX CTL pad
+ - txc-skew-ps : Skew control of TXC pad
+ - txen-skew-ps : Skew control of TX CTL pad
+ - rxd0-skew-ps : Skew control of RX data 0 pad
+ - rxd1-skew-ps : Skew control of RX data 1 pad
+ - rxd2-skew-ps : Skew control of RX data 2 pad
+ - rxd3-skew-ps : Skew control of RX data 3 pad
+ - txd0-skew-ps : Skew control of TX data 0 pad
+ - txd1-skew-ps : Skew control of TX data 1 pad
+ - txd2-skew-ps : Skew control of TX data 2 pad
+ - txd3-skew-ps : Skew control of TX data 3 pad
+
+KSZ9031:
+
+ All skew control options are specified in picoseconds. The minimum
+ value is 0, and the maximum is property-dependent. The increment
+ step is 60ps.
+
+ The KSZ9031 hardware supports a range of skew values from negative to
+ positive, where the specific range is property dependent. All values
+ specified in the devicetree are offset by the minimum value so they
+ can be represented as positive integers in the devicetree since it's
+ difficult to represent a negative number in the devictree.
+
+ The following 5-bit values table apply to rxc-skew-ps and txc-skew-ps.
+
+ Pad Skew Value Delay (ps) Devicetree Value
+ ------------------------------------------------------
+ 0_0000 -900ps 0
+ 0_0001 -840ps 60
+ 0_0010 -780ps 120
+ 0_0011 -720ps 180
+ 0_0100 -660ps 240
+ 0_0101 -600ps 300
+ 0_0110 -540ps 360
+ 0_0111 -480ps 420
+ 0_1000 -420ps 480
+ 0_1001 -360ps 540
+ 0_1010 -300ps 600
+ 0_1011 -240ps 660
+ 0_1100 -180ps 720
+ 0_1101 -120ps 780
+ 0_1110 -60ps 840
+ 0_1111 0ps 900
+ 1_0000 60ps 960
+ 1_0001 120ps 1020
+ 1_0010 180ps 1080
+ 1_0011 240ps 1140
+ 1_0100 300ps 1200
+ 1_0101 360ps 1260
+ 1_0110 420ps 1320
+ 1_0111 480ps 1380
+ 1_1000 540ps 1440
+ 1_1001 600ps 1500
+ 1_1010 660ps 1560
+ 1_1011 720ps 1620
+ 1_1100 780ps 1680
+ 1_1101 840ps 1740
+ 1_1110 900ps 1800
+ 1_1111 960ps 1860
+
+ The following 4-bit values table apply to the txdX-skew-ps, rxdX-skew-ps
+ data pads, and the rxdv-skew-ps, txen-skew-ps control pads.
+
+ Pad Skew Value Delay (ps) Devicetree Value
+ ------------------------------------------------------
+ 0000 -420ps 0
+ 0001 -360ps 60
+ 0010 -300ps 120
+ 0011 -240ps 180
+ 0100 -180ps 240
+ 0101 -120ps 300
+ 0110 -60ps 360
+ 0111 0ps 420
+ 1000 60ps 480
+ 1001 120ps 540
+ 1010 180ps 600
+ 1011 240ps 660
+ 1100 300ps 720
+ 1101 360ps 780
+ 1110 420ps 840
+ 1111 480ps 900
+
+ Optional properties:
+
+ Maximum value of 1860:
+
+ - rxc-skew-ps : Skew control of RX clock pad
+ - txc-skew-ps : Skew control of TX clock pad
+
+ Maximum value of 900:
+
+ - rxdv-skew-ps : Skew control of RX CTL pad
+ - txen-skew-ps : Skew control of TX CTL pad
+ - rxd0-skew-ps : Skew control of RX data 0 pad
+ - rxd1-skew-ps : Skew control of RX data 1 pad
+ - rxd2-skew-ps : Skew control of RX data 2 pad
+ - rxd3-skew-ps : Skew control of RX data 3 pad
+ - txd0-skew-ps : Skew control of TX data 0 pad
+ - txd1-skew-ps : Skew control of TX data 1 pad
+ - txd2-skew-ps : Skew control of TX data 2 pad
+ - txd3-skew-ps : Skew control of TX data 3 pad
+
+Examples:
+
+ /* Attach to an Ethernet device with autodetected PHY */
+ &enet {
+ rxc-skew-ps = <1800>;
+ rxdv-skew-ps = <0>;
+ txc-skew-ps = <1800>;
+ txen-skew-ps = <0>;
+ status = "okay";
+ };
+
+ /* Attach to an explicitly-specified PHY */
+ mdio {
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1800>;
+ rxdv-skew-ps = <0>;
+ txc-skew-ps = <1800>;
+ txen-skew-ps = <0>;
+ reg = <0>;
+ };
+ };
+ ethernet@70000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+
+References
+
+ Micrel ksz9021rl/rn Data Sheet, Revision 1.2. Dated 2/13/2014.
+ http://www.micrel.com/_PDF/Ethernet/datasheets/ksz9021rl-rn_ds.pdf
+
+ Micrel ksz9031rnx Data Sheet, Revision 2.1. Dated 11/20/2014.
+ http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf
+
+Notes:
+
+ Note that a previous version of the Micrel ksz9021rl/rn Data Sheet
+ was missing extended register 106 (transmit data pad skews), and
+ incorrectly specified the ps per step as 200ps/step instead of
+ 120ps/step. The latest update to this document reflects the latest
+ revision of the Micrel specification even though usage in the kernel
+ still reflects that incorrect document.
diff --git a/roms/u-boot/doc/device-tree-bindings/net/phy.txt b/roms/u-boot/doc/device-tree-bindings/net/phy.txt
new file mode 100644
index 000000000..6599c667b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/phy.txt
@@ -0,0 +1,24 @@
+PHY nodes
+
+If the device tree is used to describe networking interfaces, U-Boot expects a
+node for each PHY. Parent node for such a PHY node is expected to correspond to
+a MDIO bus and the bus is used to access the PHY.
+
+Required properties:
+
+ - reg : The ID number for the phy, usually a small integer
+
+Example:
+
+ethernet-phy@0 {
+ compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22";
+ interrupt-parent = <&PIC>;
+ interrupts = <35 IRQ_TYPE_EDGE_RISING>;
+ reg = <0>;
+
+ resets = <&rst 8>;
+ reset-names = "phy";
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <2000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/phy/atheros.txt b/roms/u-boot/doc/device-tree-bindings/net/phy/atheros.txt
new file mode 100644
index 000000000..a72c6b050
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/phy/atheros.txt
@@ -0,0 +1,35 @@
+* Qualcomm Atheros PHY Device Tree binding
+
+Required properties:
+- reg: PHY address
+
+Optional properties:
+- qca,clk-out-frequency: Clock frequency of the CLK_25M pin in Hz.
+ Either 25000000, 50000000, 62500000 or 125000000.
+- qca,clk-out-strength: Clock output buffer driver strength.
+ Supported values are defined in dt-bindings/net/qca-ar803x.h
+- qca,keep-pll-enabled: Keep the PLL running if no link is present.
+ Don't go into hibernation mode.
+ Only supported on the AR8031/AR8033.
+- vddio-supply: RGMII I/O voltage regulator
+ Only supported on the AR8031/AR8033.
+
+Optional subnodes:
+- vddio-regulator: Initial data for the VDDIO regulator, as covered
+ doc/device-tree-bindings/regulator/regulator.txt
+
+Example:
+ #include <dt-bindings/net/qca-ar803x.h>
+
+ ethernet-phy@0 {
+ reg = <0>;
+ qca,clk-out-frequency = <125000000>;
+ qca,keep-pll-enabled;
+
+ vddio-supply = <&vddio>;
+
+ vddio: vddio-regulator {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt b/roms/u-boot/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt
new file mode 100644
index 000000000..d93f71ce8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt
@@ -0,0 +1,166 @@
+* Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC)
+
+This binding supports the Synopsys Designware Ethernet QoS (Quality Of Service)
+IP block. The IP supports multiple options for bus type, clocking and reset
+structure, and feature list. Consequently, a number of properties and list
+entries in properties are marked as optional, or only required in specific HW
+configurations.
+
+Required properties:
+- compatible: One of:
+ - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10"
+ Represents the IP core when integrated into the Axis ARTPEC-6 SoC.
+ - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10"
+ Represents the IP core when integrated into the NVIDIA Tegra186 SoC.
+ - "snps,dwc-qos-ethernet-4.10"
+ This combination is deprecated. It should be treated as equivalent to
+ "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10". It is supported to be
+ compatible with earlier revisions of this binding.
+- reg: Address and length of the register set for the device
+- clocks: Phandle and clock specifiers for each entry in clock-names, in the
+ same order. See ../clock/clock-bindings.txt.
+- clock-names: May contain any/all of the following depending on the IP
+ configuration, in any order:
+ - "tx"
+ The EQOS transmit path clock. The HW signal name is clk_tx_i.
+ In some configurations (e.g. GMII/RGMII), this clock also drives the PHY TX
+ path. In other configurations, other clocks (such as tx_125, rmii) may
+ drive the PHY TX path.
+ - "rx"
+ The EQOS receive path clock. The HW signal name is clk_rx_i.
+ In some configurations (e.g. GMII/RGMII), this clock is derived from the
+ PHY's RX clock output. In other configurations, other clocks (such as
+ rx_125, rmii) may drive the EQOS RX path.
+ In cases where the PHY clock is directly fed into the EQOS receive path
+ without intervening logic, the DT need not represent this clock, since it
+ is assumed to be fully under the control of the PHY device/driver. In
+ cases where SoC integration adds additional logic to this path, such as a
+ SW-controlled clock gate, this clock should be represented in DT.
+ - "slave_bus"
+ The CPU/slave-bus (CSR) interface clock. This applies to any bus type;
+ APB, AHB, AXI, etc. The HW signal name is hclk_i (AHB) or clk_csr_i (other
+ buses).
+ - "master_bus"
+ The master bus interface clock. Only required in configurations that use a
+ separate clock for the master and slave bus interfaces. The HW signal name
+ is hclk_i (AHB) or aclk_i (AXI).
+ - "ptp_ref"
+ The PTP reference clock. The HW signal name is clk_ptp_ref_i.
+ - "phy_ref_clk"
+ This clock is deprecated and should not be used by new compatible values.
+ It is equivalent to "tx".
+ - "apb_pclk"
+ This clock is deprecated and should not be used by new compatible values.
+ It is equivalent to "slave_bus".
+
+ Note: Support for additional IP configurations may require adding the
+ following clocks to this list in the future: clk_rx_125_i, clk_tx_125_i,
+ clk_pmarx_0_i, clk_pmarx1_i, clk_rmii_i, clk_revmii_rx_i, clk_revmii_tx_i.
+ Configurations exist where multiple similar clocks are used at once, e.g. all
+ of clk_rx_125_i, clk_pmarx_0_i, clk_pmarx1_i. For this reason it is best to
+ extend the binding with a separate clock-names entry for each of those RX
+ clocks, rather than repurposing the existing "rx" clock-names entry as a
+ generic/logical clock in a similar fashion to "master_bus" and "slave_bus".
+ This will allow easy support for configurations that support multiple PHY
+ interfaces using a mux, and hence need to have explicit control over
+ specific RX clocks.
+
+ The following compatible values require the following set of clocks:
+ - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10":
+ - "slave_bus"
+ - "master_bus"
+ - "rx"
+ - "tx"
+ - "ptp_ref"
+ - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10":
+ - "slave_bus"
+ - "master_bus"
+ - "tx"
+ - "ptp_ref"
+ - "snps,dwc-qos-ethernet-4.10" (deprecated):
+ - "phy_ref_clk"
+ - "apb_clk"
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the core's combined interrupt signal
+- phy-mode: See ethernet.txt file in the same directory
+- resets: Phandle and reset specifiers for each entry in reset-names, in the
+ same order. See ../reset/reset.txt.
+- reset-names: May contain any/all of the following depending on the IP
+ configuration, in any order:
+ - "eqos". The reset to the entire module. The HW signal name is hreset_n
+ (AHB) or aresetn_i (AXI).
+
+ The following compatible values require the following set of resets:
+ (the reset properties may be omitted if empty)
+ - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10":
+ - "eqos".
+ - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10":
+ - None.
+ - "snps,dwc-qos-ethernet-4.10" (deprecated):
+ - None.
+
+Optional properties:
+- dma-coherent: Present if dma operations are coherent
+- mac-address: See ethernet.txt in the same directory
+- local-mac-address: See ethernet.txt in the same directory
+- phy-reset-gpios: Phandle and specifier for any GPIO used to reset the PHY.
+ See ../gpio/gpio.txt.
+- snps,en-lpi: If present it enables use of the AXI low-power interface
+- snps,write-requests: Number of write requests that the AXI port can issue.
+ It depends on the SoC configuration.
+- snps,read-requests: Number of read requests that the AXI port can issue.
+ It depends on the SoC configuration.
+- snps,burst-map: Bitmap of allowed AXI burst lengts, with the LSB
+ representing 4, then 8 etc.
+- snps,txpbl: DMA Programmable burst length for the TX DMA
+- snps,rxpbl: DMA Programmable burst length for the RX DMA
+- snps,en-tx-lpi-clockgating: Enable gating of the MAC TX clock during
+ TX low-power mode.
+- phy-handle: See ethernet.txt file in the same directory
+- mdio device tree subnode: When the GMAC has a phy connected to its local
+ mdio, there must be device tree subnode with the following
+ required properties:
+ - compatible: Must be "snps,dwc-qos-ethernet-mdio".
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+
+ For each phy on the mdio bus, there must be a node with the following
+ fields:
+
+ - reg: phy id used to communicate to phy.
+ - device_type: Must be "ethernet-phy".
+ - fixed-mode device tree subnode: see fixed-link.txt in the same directory
+
+Examples:
+ethernet2@40010000 {
+ clock-names = "phy_ref_clk", "apb_pclk";
+ clocks = <&clkc 17>, <&clkc 15>;
+ compatible = "snps,dwc-qos-ethernet-4.10";
+ interrupt-parent = <&intc>;
+ interrupts = <0x0 0x1e 0x4>;
+ reg = <0x40010000 0x4000>;
+ phy-handle = <&phy2>;
+ phy-mode = "gmii";
+ phy-reset-gpios = <&gpioctlr 43 GPIO_ACTIVE_LOW>;
+
+ snps,en-tx-lpi-clockgating;
+ snps,en-lpi;
+ snps,write-requests = <2>;
+ snps,read-requests = <16>;
+ snps,burst-map = <0x7>;
+ snps,txpbl = <8>;
+ snps,rxpbl = <2>;
+
+ dma-coherent;
+
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ phy2: phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ device_type = "ethernet-phy";
+ reg = <0x1>;
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/net/stmmac.txt b/roms/u-boot/doc/device-tree-bindings/net/stmmac.txt
new file mode 100644
index 000000000..5f025174c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/net/stmmac.txt
@@ -0,0 +1,63 @@
+* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
+
+Required properties:
+- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac"
+ For backwards compatibility: "st,spear600-gmac" is also supported.
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the STMMAC interrupts
+- interrupt-names: Should contain the interrupt names "macirq"
+ "eth_wake_irq" if this interrupt is supported in the "interrupts"
+ property
+- phy-mode: See ethernet.txt file in the same directory.
+- snps,reset-gpio gpio number for phy reset.
+- snps,reset-active-low boolean flag to indicate if phy reset is active low.
+- snps,reset-delays-us is triplet of delays
+ The 1st cell is reset pre-delay in micro seconds.
+ The 2nd cell is reset pulse in micro seconds.
+ The 3rd cell is reset post-delay in micro seconds.
+- snps,pbl Programmable Burst Length
+- snps,fixed-burst Program the DMA to use the fixed burst mode
+- snps,mixed-burst Program the DMA to use the mixed burst mode
+- snps,force_thresh_dma_mode Force DMA to use the threshold mode for
+ both tx and rx
+- snps,force_sf_dma_mode Force DMA to use the Store and Forward
+ mode for both tx and rx. This flag is
+ ignored if force_thresh_dma_mode is set.
+- snps,multicast-filter-bins: Number of multicast filter hash bins
+ supported by this device instance
+- snps,perfect-filter-entries: Number of perfect filter entries supported
+ by this device instance
+
+Optional properties:
+- resets: Should contain a phandle to the STMMAC reset signal, if any
+- reset-names: Should contain the reset signal name "stmmaceth", if a
+ reset phandle is given
+- max-frame-size: See ethernet.txt file in the same directory
+- clocks: If present, the first clock should be the GMAC main clock,
+ further clocks may be specified in derived bindings.
+- clock-names: One name for each entry in the clocks property, the
+ first one should be "stmmaceth".
+- clk_ptp_ref: this is the PTP reference clock; in case of the PTP is
+ available this clock is used for programming the Timestamp Addend Register.
+ If not passed then the system clock will be used and this is fine on some
+ platforms.
+- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
+
+Examples:
+
+ gmac0: ethernet@e0800000 {
+ compatible = "st,spear600-gmac";
+ reg = <0xe0800000 0x8000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <24 23>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ max-frame-size = <3800>;
+ phy-mode = "gmii";
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ clocks = <&clock>;
+ clock-names = "stmmaceth";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pci/armada8k-pcie.txt b/roms/u-boot/doc/device-tree-bindings/pci/armada8k-pcie.txt
new file mode 100644
index 000000000..7230f1044
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pci/armada8k-pcie.txt
@@ -0,0 +1,49 @@
+Armada-8K PCIe DT details:
+==========================
+
+Armada-8k uses synopsis designware PCIe controller.
+
+Required properties:
+- compatible : should be "marvell,armada8k-pcie", "snps,dw-pcie".
+- reg: base addresses and lengths of the pcie control and global control registers.
+ "ctrl" registers points to the global control registers, while the "config" space
+ points to the pcie configuration registers as mentioned in dw-pcie dt bindings in the link below.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+- All other definitions as per generic PCI bindings
+See Linux kernel documentation:
+"Documentation/devicetree/bindings/pci/designware-pcie.txt"
+
+Optional properties:
+PHY support is still not supported for armada-8k, once it will, the following parameters can be used:
+- phys : phandle to phy node associated with pcie controller.
+- phy-names : must be "pcie-phy"
+- marvell,reset-gpio : specifies a gpio that needs to be activated for plug-in
+ card reset signal release.
+Example:
+
+cpm_pcie0: pcie@f2600000 {
+ compatible = "marvell,armada8k-pcie", "snps,dw-pcie";
+ reg = <0 0xf2600000 0 0x10000>,
+ <0 0xf6f00000 0 0x80000>;
+ reg-names = "ctrl", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ dma-coherent;
+
+ bus-range = <0 0xff>;
+ ranges =
+ /* downstream I/O */
+ <0x81000000 0 0xf9000000 0 0xf9000000 0 0x10000
+ /* non-prefetchable memory */
+ 0x82000000 0 0xf6000000 0 0xf6000000 0 0xf00000>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ num-lanes = <1>;
+ clocks = <&cpm_syscon0 1 13>;
+ marvell,reset-gpio = <&cpm_gpio1 20 GPIO_ACTIVE_HIGH>;
+ status = "disabled";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pci/mediatek-pcie.txt b/roms/u-boot/doc/device-tree-bindings/pci/mediatek-pcie.txt
new file mode 100644
index 000000000..2f9f549b7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pci/mediatek-pcie.txt
@@ -0,0 +1,122 @@
+MediaTek Gen2 PCIe controller
+
+Required properties:
+- compatible: Should contain one of the following strings:
+ "mediatek,mt7623-pcie"
+- device_type: Must be "pci"
+- reg: Base addresses and lengths of the PCIe subsys and root ports.
+- reg-names: Names of the above areas to use during resource lookup.
+- #address-cells: Address representation for root ports (must be 3)
+- #size-cells: Size representation for root ports (must be 2)
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names:
+ Mandatory entries:
+ - sys_ckN :transaction layer and data link layer clock
+ Required entries for MT7623:
+ - free_ck :for reference clock of PCIe subsys
+ where N starting from 0 to one less than the number of root ports.
+- phys: List of PHY specifiers (used by generic PHY framework).
+- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
+ number of PHYs as specified in *phys* property.
+- power-domains: A phandle and power domain specifier pair to the power domain
+ which is responsible for collapsing and restoring power to the peripheral.
+- bus-range: Range of bus numbers associated with this controller.
+- ranges: Ranges for the PCI memory and I/O regions.
+
+Required properties for MT7623:
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+ Please refer to the standard PCI bus binding document for a more detailed
+ explanation.
+- resets: Must contain an entry for each entry in reset-names.
+- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
+ number of root ports.
+
+In addition, the device tree node must have sub-nodes describing each
+PCIe port interface, having the following mandatory properties:
+
+Required properties:
+- device_type: Must be "pci"
+- reg: Only the first four bytes are used to refer to the correct bus number
+ and device number.
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- #interrupt-cells: Must be 1
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+ Please refer to the standard PCI bus binding document for a more detailed
+ explanation.
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+ property is sufficient.
+
+Examples for MT7623:
+
+ hifsys: syscon@1a000000 {
+ compatible = "mediatek,mt7623-hifsys",
+ "syscon";
+ reg = <0x1a000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pcie: pcie@1a140000 {
+ compatible = "mediatek,mt7623-pcie";
+ device_type = "pci";
+ reg = <0x1a140000 0x1000>, /* PCIe shared registers */
+ <0x1a142000 0x1000>, /* Port0 registers */
+ <0x1a143000 0x1000>, /* Port1 registers */
+ <0x1a144000 0x1000>; /* Port2 registers */
+ reg-names = "subsys", "port0", "port1", "port2";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0xf800 0 0 0>;
+ interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
+ <0x0800 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
+ <0x1000 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+ <&hifsys CLK_HIFSYS_PCIE0>,
+ <&hifsys CLK_HIFSYS_PCIE1>,
+ <&hifsys CLK_HIFSYS_PCIE2>;
+ clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
+ resets = <&hifsys HIFSYS_PCIE0_RST>,
+ <&hifsys HIFSYS_PCIE1_RST>,
+ <&hifsys HIFSYS_PCIE2_RST>;
+ reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
+ phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>,
+ <&pcie2_phy PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+ power-domains = <&scpsys MT7623_POWER_DOMAIN_HIF>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x81000000 0 0x1a160000 0x1a160000 0 0x00010000 /* I/O space */
+ 0x83000000 0 0x60000000 0x60000000 0 0x10000000>; /* memory space */
+
+ pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+
+ pcie@1,0 {
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+
+ pcie@2,0 {
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pci/x86-pci.txt b/roms/u-boot/doc/device-tree-bindings/pci/x86-pci.txt
new file mode 100644
index 000000000..95e370b3e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pci/x86-pci.txt
@@ -0,0 +1,47 @@
+x86 PCI DT details:
+===================
+
+Some options are available to affect how PCI operates on x86.
+
+Optional properties:
+- u-boot,skip-auto-config-until-reloc : Don't set up PCI configuration until
+ after U-Boot has relocated. Normally if PCI is used before relocation,
+ this happens before relocation also. Some platforms set up static
+ configuration in TPL/SPL to reduce code size and boot time, since these
+ phases only know about a small subset of PCI devices.
+
+For PCI devices the following optional property is available:
+
+- pci,no-autoconfig : Don't automatically configure this PCI device at all.
+ This is used when the device is statically configured and must maintain
+ this same config throughout the boot process. An example is a serial
+ UART being used to debug PCI configuration, since reconfiguring it stops
+ the UART from working until the driver is re-probed, and this can cause
+ output to be lost. This should not generally be used in production code,
+ although it is often harmless.
+
+
+Example:
+
+pci {
+ compatible = "pci-x86";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ u-boot,dm-pre-reloc;
+ ranges = <0x02000000 0x0 0xc0000000 0xc0000000 0 0x10000000
+ 0x42000000 0x0 0xb0000000 0xb0000000 0 0x10000000
+ 0x01000000 0x0 0x1000 0x1000 0 0xefff>;
+ u-boot,skip-auto-config-until-reloc;
+
+
+ serial: serial@18,2 {
+ reg = <0x0200c210 0 0 0 0>;
+ u-boot,dm-pre-reloc;
+ compatible = "intel,apl-ns16550";
+ early-regs = <0xde000000 0x20>;
+ reg-shift = <2>;
+ clock-frequency = <1843200>;
+ current-speed = <115200>;
+ pci,no-autoconfig;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt b/roms/u-boot/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
new file mode 100644
index 000000000..770543055
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
@@ -0,0 +1,18 @@
+* Cadence PCIe endpoint controller
+
+Required properties:
+- compatible: Should contain "cdns,cdns-pcie-ep" to identify the IP used.
+- reg: Should contain the controller register base address.
+
+Optional properties:
+- max-functions: Maximum number of functions that can be configured (default 1).
+- cdns,max-outbound-regions: Set to maximum number of outbound regions (default 8)
+
+Example:
+
+pcie_ep@fc000000 {
+ compatible = "cdns,cdns-pcie-ep";
+ reg = <0x0 0xfc000000 0x0 0x01000000>;
+ cdns,max-outbound-regions = <16>;
+ max-functions = /bits/ 8 <8>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/mvebu_comphy.txt b/roms/u-boot/doc/device-tree-bindings/phy/mvebu_comphy.txt
new file mode 100644
index 000000000..65b838485
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/mvebu_comphy.txt
@@ -0,0 +1,68 @@
+Marvell COMPHY SerDes lane bindings
+=====================================
+
+The COMPHY node includes a description of the COMPHY SerDes lane configuration.
+The COMPHY driver initializes the MUX of the SerDes lanes, and powers up the SerDes
+by dependencies on the FDT blob configurations
+
+Mandatory properties:
+SoC specific:
+ - compatible:
+ The compatible should include "marvell,mvebu-comphy"
+ and the COMPHY per chip compatible:
+ "marvell,comphy-cp110" for CP110 available in Aramda70x0/80x0.
+ The COMPHY per chip used to set which MUX configuration to use, and COMPHY power-up revision.
+ - reg: Base address and size of the COMPHY and hpipe units.
+ - max-lanes: Maximum number of comphy lanes.
+ - mux-bitcount: Number of bits that are allocated for every MUX in the COMPHY-selector register.
+Board specific:
+ - PHY: Entry that include the configuration of the PHY.
+ Every PHY should have the below parameters:
+ - phy-type: the mode of the PHY
+ Possible modes located in include/dt-bindings/comphy/comphy_data.h
+ Optional properties:
+ - phy-speed: the speed of the PHY
+ Possible speeds values located in include/dt-bindings/comphy/comphy_data.h
+ - phy-invert: Polarity invert (COMPHY_POLARITY_TXD_INVERT/COMPHY_POLARITY_RXD_INVERT)
+ the possible bits under include/dt-bindings/comphy/comphy_data.h
+ - clk-src: Set the clock source of PCIe, if configured to PCIe clock output
+ This relevant for SerDes lane 5 only (by default, lane 4 is the clock source)
+ for Armada-7040 boards.
+ - endpoint: Optional boolean specifying this SerDes should be configured as PCIe endpoint.
+
+Example:
+ cpm_comphy: comphy@441000 {
+ compatible = "marvell,mvebu-comphy", "marvell,comphy-cp110";
+ reg = <0x441000 0x8>, <0x120000 0x8>;
+ mux-bitcount = <4>;
+ max-lanes = <6>;
+
+ /*
+ * CP110 Serdes Configuration:
+ * Lane 0: SGMII1
+ * Lane 1: SATA 0
+ * Lane 2: USB HOST 0
+ * Lane 3: SATA1
+ * Lane 4: SFI (10G)
+ * Lane 5: SGMII2
+ */
+ phy0 {
+ phy-type = <COMPHY_TYPE_SGMII1>;
+ phy-speed = <COMPHY_SPEED_1_25G>;
+ };
+ phy1 {
+ phy-type = <COMPHY_TYPE_SATA0>;
+ };
+ phy2 {
+ phy-type = <COMPHY_TYPE_USB3_HOST0>;
+ };
+ phy3 {
+ phy-type = <COMPHY_TYPE_SATA1>;
+ };
+ phy4 {
+ phy-type = <COMPHY_TYPE_SFI>;
+ };
+ phy5 {
+ phy-type = <COMPHY_TYPE_SGMII2>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/no-op.txt b/roms/u-boot/doc/device-tree-bindings/phy/no-op.txt
new file mode 100644
index 000000000..a3381122e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/no-op.txt
@@ -0,0 +1,16 @@
+NOP PHY driver
+
+This driver is used to stub PHY operations in a driver (USB, SATA).
+This is useful when the 'client' driver (USB, SATA, ...) uses the PHY framework
+and there is no actual PHY harwdare to drive.
+
+Required properties:
+- compatible : must contain "nop-phy"
+- #phy-cells : must contain <0>
+
+Example:
+
+nop_phy {
+ compatible = "nop-phy";
+ #phy-cells = <0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/phy-mtk-tphy.txt b/roms/u-boot/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
new file mode 100644
index 000000000..8cd23d8c0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
@@ -0,0 +1,144 @@
+MediaTek T-PHY binding
+--------------------------
+
+T-phy controller supports physical layer functionality for a number of
+controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA.
+
+Required properties (controller (parent) node):
+ - compatible : should be one of
+ "mediatek,generic-tphy-v1"
+ "mediatek,generic-tphy-v2"
+
+- #address-cells: the number of cells used to represent physical
+ base addresses.
+- #size-cells: the number of cells used to represent the size of an address.
+- ranges: the address mapping relationship to the parent, defined with
+ - empty value: if optional 'reg' is used.
+ - non-empty value: if optional 'reg' is not used. should set
+ the child's base address to 0, the physical address
+ within parent's address space, and the length of
+ the address map.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register.
+ - mediatek,src-ref-clk-mhz : frequency of reference clock for slew rate
+ calibrate
+ - mediatek,src-coef : coefficient for slew rate calibrate, depends on
+ SoC process
+
+Required properties (port (child) node):
+- reg : address and length of the register set for the port.
+- #phy-cells : should be 1 (See second example)
+ cell after port phandle is phy type from:
+ - PHY_TYPE_USB2
+ - PHY_TYPE_USB3
+ - PHY_TYPE_PCIE
+ - PHY_TYPE_SATA
+
+Optional properties (port (child) node):
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : may contain
+ "ref": 48M reference clock for HighSpeed (digital) phy; and 26M
+ reference clock for SuperSpeed (digital) phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
+ "da_ref": the reference clock of analog phy, used if the clocks
+ of analog and digital phys are separated, otherwise uses
+ "ref" clock only if needed.
+
+Example:
+
+ u3phy2: usb-phy@1a244000 {
+ compatible = "mediatek,generic-tphy-v1";
+ reg = <0x1a244000 0x0700>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ u2port1: usb-phy@1a244800 {
+ reg = <0x1a244800 0x0100>;
+ clocks = <&topckgen CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u3port1: usb-phy@1a244900 {
+ reg = <0x1a244900 0x0700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
+Specifying phy control of devices
+---------------------------------
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include <dt-bindings/phy/phy.h>
+
+usb30: usb@11270000 {
+ ...
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
+ ...
+};
+
+Layout differences of banks between TPHY V1 and V2
+-------------------------------------------------------------
+IP V1:
+port offset bank
+shared 0x0000 SPLLC
+ 0x0100 FMREG
+u2 port0 0x0800 U2PHY_COM
+u3 port0 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 U2PHY_COM
+u3 port1 0x1100 U3PHYD
+ 0x1200 U3PHYD_BANK2
+ 0x1300 U3PHYA
+ 0x1400 U3PHYA_DA
+u2 port2 0x1800 U2PHY_COM
+ ...
+
+IP V2:
+port offset bank
+u2 port0 0x0000 MISC
+ 0x0100 FMREG
+ 0x0300 U2PHY_COM
+u3 port0 0x0700 SPLLC
+ 0x0800 CHIP
+ 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 MISC
+ 0x1100 FMREG
+ 0x1300 U2PHY_COM
+u3 port1 0x1700 SPLLC
+ 0x1800 CHIP
+ 0x1900 U3PHYD
+ 0x1a00 U3PHYD_BANK2
+ 0x1b00 U3PHYA
+ 0x1c00 U3PHYA_DA
+u2 port2 0x2000 MISC
+ ...
+
+ SPLLC shared by u3 ports and FMREG shared by u2 ports on
+TPHY V1 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on TPHY V2.
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/phy-stih407-usb.txt b/roms/u-boot/doc/device-tree-bindings/phy/phy-stih407-usb.txt
new file mode 100644
index 000000000..371a7fec0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/phy-stih407-usb.txt
@@ -0,0 +1,24 @@
+ST STiH407 USB PHY controller
+
+This file documents the dt bindings for the usb picoPHY driver which is the PHY for both USB2 and USB3
+host controllers (when controlling usb2/1.1 devices) available on STiH407 SoC family from STMicroelectronics.
+
+Required properties:
+- compatible : should be "st,stih407-usb2-phy"
+- st,syscfg : phandle of sysconfig bank plus integer array containing phyparam and phyctrl register offsets
+- resets : list of phandle and reset specifier pairs. There should be two entries, one
+ for the whole phy and one for the port
+- reset-names : list of reset signal names. Should be "global" and "port"
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+Example:
+
+usb2_picophy0: usbpicophy {
+ compatible = "st,stih407-usb2-phy";
+ #phy-cells = <0>;
+ st,syscfg = <&syscfg_core 0x100 0xf4>;
+ resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
+ <&picophyreset STIH407_PICOPHY0_RESET>;
+ reset-names = "global", "port";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt b/roms/u-boot/doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt
new file mode 100644
index 000000000..edfe4b426
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt
@@ -0,0 +1,75 @@
+STMicroelectronics STM32 USB HS PHY controller
+
+The STM32 USBPHYC block contains a dual port High Speed UTMI+ PHY and a UTMI
+switch. It controls PHY configuration and status, and the UTMI+ switch that
+selects either OTG or HOST controller for the second PHY port. It also sets
+PLL configuration.
+
+USBPHYC
+ |_ PLL
+ |
+ |_ PHY port#1 _________________ HOST controller
+ | _ |
+ | / 1|________________|
+ |_ PHY port#2 ----| |________________
+ | \_0| |
+ |_ UTMI switch_______| OTG controller
+
+
+Phy provider node
+=================
+
+Required properties:
+- compatible: must be "st,stm32mp1-usbphyc"
+- reg: address and length of the usb phy control register set
+- clocks: phandle + clock specifier for the PLL phy clock
+- vdda1v1-supply: phandle to the regulator providing 1V1 power to the PHY
+- vdda1v8-supply: phandle to the regulator providing 1V8 power to the PHY
+- #address-cells: number of address cells for phys sub-nodes, must be <1>
+- #size-cells: number of size cells for phys sub-nodes, must be <0>
+
+Optional properties:
+- assigned-clocks: phandle + clock specifier for the PLL phy clock
+- assigned-clock-parents: the PLL phy clock parent
+- resets: phandle + reset specifier
+
+Required nodes: one sub-node per port the controller provides.
+
+Phy sub-nodes
+==============
+
+Required properties:
+- reg: phy port index
+- phy-supply: phandle to the regulator providing 3V3 power to the PHY,
+ see phy-bindings.txt in the same directory.
+- #phy-cells: see phy-bindings.txt in the same directory, must be <0> for PHY
+ port#1 and must be <1> for PHY port#2, to select USB controller
+
+Optional properties:
+- vbus-supply: phandle to the regulator providing 5V vbus to the USB connector
+
+Example:
+ usbphyc: usb-phy@5a006000 {
+ compatible = "st,stm32mp1-usbphyc";
+ reg = <0x5a006000 0x1000>;
+ clocks = <&rcc_clk USBPHY_K>;
+ resets = <&rcc_rst USBPHY_R>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbphyc_port0: usb-phy@0 {
+ reg = <0>;
+ phy-supply = <&vdd_usb>;
+ vdda1v1-supply = <&reg11>;
+ vdda1v8-supply = <&reg18>
+ #phy-cells = <0>;
+ };
+
+ usbphyc_port1: usb-phy@1 {
+ reg = <1>;
+ phy-supply = <&vdd_usb>;
+ vdda1v1-supply = <&reg11>;
+ vdda1v8-supply = <&reg18>
+ #phy-cells = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/phy/sun4i-usb-phy.txt b/roms/u-boot/doc/device-tree-bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000000000..c1ce5a0a6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,65 @@
+Allwinner sun4i USB PHY
+-----------------------
+
+Required properties:
+- compatible : should be one of
+ * allwinner,sun4i-a10-usb-phy
+ * allwinner,sun5i-a13-usb-phy
+ * allwinner,sun6i-a31-usb-phy
+ * allwinner,sun7i-a20-usb-phy
+ * allwinner,sun8i-a23-usb-phy
+ * allwinner,sun8i-a33-usb-phy
+ * allwinner,sun8i-a83t-usb-phy
+ * allwinner,sun8i-h3-usb-phy
+ * allwinner,sun8i-v3s-usb-phy
+ * allwinner,sun50i-a64-usb-phy
+- reg : a list of offset + length pairs
+- reg-names :
+ * "phy_ctrl"
+ * "pmu0" for H3, V3s and A64
+ * "pmu1"
+ * "pmu2" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3
+ * "pmu3" for sun8i-h3
+- #phy-cells : from the generic phy bindings, must be 1
+- clocks : phandle + clock specifier for the phy clocks
+- clock-names :
+ * "usb_phy" for sun4i, sun5i or sun7i
+ * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
+ * "usb0_phy", "usb1_phy" for sun8i
+ * "usb0_phy", "usb1_phy", "usb2_phy" and "usb2_hsic_12M" for sun8i-a83t
+ * "usb0_phy", "usb1_phy", "usb2_phy" and "usb3_phy" for sun8i-h3
+- resets : a list of phandle + reset specifier pairs
+- reset-names :
+ * "usb0_reset"
+ * "usb1_reset"
+ * "usb2_reset" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3
+ * "usb3_reset" for sun8i-h3
+
+Optional properties:
+- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
+- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
+- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect
+- usb0_vbus-supply : regulator phandle for controller usb0 vbus
+- usb1_vbus-supply : regulator phandle for controller usb1 vbus
+- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+- usb3_vbus-supply : regulator phandle for controller usb3 vbus
+
+Example:
+ usbphy: phy@01c13400 {
+ #phy-cells = <1>;
+ compatible = "allwinner,sun4i-a10-usb-phy";
+ /* phy base regs, phy1 pmu reg, phy2 pmu reg */
+ reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
+ reg-names = "phy_ctrl", "pmu1", "pmu2";
+ clocks = <&usb_clk 8>;
+ clock-names = "usb_phy";
+ resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
+ reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+ usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
+ usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
+ usb0_vbus-supply = <&reg_usb0_vbus>;
+ usb1_vbus-supply = <&reg_usb1_vbus>;
+ usb2_vbus-supply = <&reg_usb2_vbus>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
new file mode 100644
index 000000000..6e936a08b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -0,0 +1,69 @@
+* Atmel PIO4 Controller
+
+The Atmel PIO4 controller is used to select the function of a pin and to
+configure it.
+
+Required properties:
+- compatible: "atmel,sama5d2-pinctrl".
+- reg: base address and length of the PIO controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Subnode format
+Each node (or subnode) will list the pins it needs and how to configured these
+pins.
+
+ node {
+ pinmux = <PIN_NUMBER_PINMUX>;
+ GENERIC_PINCONFIG;
+ };
+
+Required properties:
+- pinmux: integer array. Each integer represents a pin number plus mux and
+ioset settings. Use the macros from boot/dts/<soc>-pinfunc.h file to get the
+right representation of the pin.
+
+Optional properties:
+- GENERIC_PINCONFIG: generic pinconfig options to use:
+ - bias-disable, bias-pull-down, bias-pull-up, drive-open-drain,
+ input-schmitt-enable, input-debounce
+ - slew-rate: 0 - disabled, 1 - enabled (default)
+- atmel,drive-strength: 0 or 1 for low drive, 2 for medium drive and 3 for
+high drive. The default value is low drive.
+
+Example:
+
+#include <sama5d2-pinfunc.h>
+
+...
+{
+ spi0: spi@f8000000 {
+ cs-gpios = <&pioA 17 0>, <0>, <0>, <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi0_default>;
+ status = "okay";
+
+ spi_flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ };
+ };
+
+ ...
+
+ pioA: pinctrl@fc038000 {
+ compatible = "atmel,sama5d2-pinctrl";
+ reg = <0xfc038000 0x600>;
+
+ pinctrl_spi0_default: spi0_default {
+ pinmux = <PIN_PA14__SPI0_SPCK>,
+ <PIN_PA15__SPI0_MOSI>,
+ <PIN_PA16__SPI0_MISO>;
+ bias-disable;
+ };
+ ...
+ };
+};
+...
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/bcm6838-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/bcm6838-pinctrl.txt
new file mode 100644
index 000000000..2034f0599
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/bcm6838-pinctrl.txt
@@ -0,0 +1,35 @@
+* broadcom bcm6838 pinctrl
+
+Required properties for the pinctrl driver:
+- compatible: "brcm,bcm6838-pinctrl"
+- regmap: specify the gpio test port syscon
+- brcm,pins-count: the number of pin
+- brcm,functions-count: the number of function
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Example:
+
+ gpio_test_port: syscon@14e00294 {
+ compatible = "syscon";
+ reg = <0x14e00294 0x1c>;
+ };
+
+ pinctrl: pinctrl {
+ compatible = "brcm,bcm6838-pinctrl";
+ regmap = <&gpio_test_port>;
+ brcm,pins-count = <74>;
+ brcm,functions-count = <8>;
+
+ usb0: usb0 {
+ usb0_pwrflt {
+ pins = "69";
+ function = "1";
+ };
+ usb0_pwron {
+ pins = "70";
+ function = "1";
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt
new file mode 100644
index 000000000..12ec84610
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/intel,apl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Intel Apollo Lake pin controller
+
+The Apollo Lake (APL) pin controller is used to select the function of a pin
+and to configure it.
+
+Required properties:
+- compatible: "intel,apl-pinctrl"
+- intel,p2sb-port-id: Port ID number within the parent P2SB
+- reg: PCI address of the controller
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+Optional subnodes:
+
+GPIO nodes may be added as children of the pinctrl nodes. See intel,apl-gpio
+for the binding.
+
+
+Example:
+
+...
+{
+ p2sb: p2sb@d,0 {
+ reg = <0x02006810 0 0 0 0>;
+ compatible = "intel,p2sb";
+ early-regs = <IOMAP_P2SB_BAR 0x100000>;
+
+ n {
+ compatible = "intel,apl-pinctrl";
+ intel,p2sb-port-id = <PID_GPIO_N>;
+ gpio_n: gpio-n {
+ compatible = "intel,apl-gpio";
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+...
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/kendryte,k210-fpioa.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/kendryte,k210-fpioa.txt
new file mode 100644
index 000000000..73871f593
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/kendryte,k210-fpioa.txt
@@ -0,0 +1,102 @@
+Kendryte K210 FPIOA
+
+This binding describes the Fully-Programmable Input/Output Array (FPIOA) found
+in Kendryte K210 SoCs. Any of the 256 functions can be mapped to any of the 48
+pins.
+
+Required properties:
+- compatible: should be "kendryte,k210-fpioa"
+- reg: address and length of the FPIOA registers
+- kendryte,sysctl: phandle to the "sysctl" register map node
+- kendryte,power-offset: offset in the register map of the power bank control
+ register (in bytes)
+
+Configuration nodes
+
+Pin configuration nodes are documented in pinctrl-bindings.txt
+
+Required properties for pin-configuration nodes or sub-nodes are:
+- groups: list of power groups to which the configuration applies. Valid groups
+ are:
+ A0, A1, A2, B3, B4, B5, C6, C7
+ (either this or "pinmux" must be specified)
+- pinmux: integer array representing pin multiplexing configuration. In addition
+ to the 256 standard functions, each pin can also output the direction
+ indicator (DO) of any function. This signal is high whenever the function
+ would normally drive the output. Helper macros to ease assembling the "pinmux"
+ arguments from the pin and function are provided by the FPIOA header file at:
+ <dt-bindings/pinctrl/k210-pinctrl.h>
+ Integer values in the "pinmux" argument list are assembled as:
+ ((PIN << 16) | (DO << 8) | (FUNC))
+ Valid values for PIN are numbers 0 through 47.
+ Valid values for DO are 0 or 1.
+ Valid values for FUNC are numbers 0 through 255. For a complete list of
+ acceptable functions, consult the FPIOA header file.
+ (either this or "groups" must be specified)
+
+Optional properties for "pinmux" nodes are:
+ bias-disable, bias-pull-down, bias-pull-up, drive-strength,
+ drive-strength-ua, input-enable, input-disable, input-schmitt-enable,
+ input-schmitt-disable, output-low, output-high, output-enable,
+ output-disable, slew-rate, output-polarity-invert, input-polarity-invert
+
+Optional properties for "groups" nodes are:
+ power-source
+
+Notes on specific properties include:
+- bias-pull-up, -down, and -pin-default: The pull strength cannot be configured.
+- drive-strength: There are 8 drive strength settings between 11 and 50 mA.
+- input- and output-polarity-invert: Invert the polarity of either the input or
+ the output, respectively.
+- power-source: Controls the output voltage of a bank of pins. Either
+ K210_PC_POWER_1V8 or K210_PC_POWER_3V3 may be specified.
+- slew-rate: Specifying this property reduces the slew rate.
+
+Example:
+fpioa: pinmux@502B0000 {
+ compatible = "kendryte,k210-fpioa";
+ reg = <0x502B0000 0x100>;
+ kendryte,sysctl = <&sysctl>;
+ kendryte,power-offset = <K210_SYSCTL_POWER_SEL>;
+
+ /* JTAG running at 3.3V and driven at 11 mA */
+ fpioa_jtag: jtag {
+ voltage {
+ group = "A0";
+ power-source = <K210_PC_POWER_3V3>;
+ };
+
+ jtag {
+ pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCK)>,
+ <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+ <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+ <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+ drive-strength = <11>;
+ }
+ };
+
+ /* I2C configured for use with a TCA9800 level shifter */
+ fpioa_i2c: i2c {
+ i2c {
+ pinmux = <K210_FPIOA(6, K210_PCF_I2C0_SCLK)>,
+ <K210_FPIOA(7, K210_PCF_I2C0_SDA)>;
+ };
+
+ direction {
+ pinmux = <K210_FPIOA_DO(8, K210_PCF_I2C0_SDA)>;
+ output-polarity-invert;
+ };
+ };
+
+ /* UART with an active-high TX status LED */
+ fpioa_uart1: uart1 {
+ uart {
+ pinmux = <K210_FPIOA(9, K210_PCF_UART1_TX)>,
+ <K210_FPIOA(10, K210_PCF_UART1_RX)>;
+ };
+
+ status {
+ pinmux = <K210_FPIOA_DO(11, K210_PCF_UART1_TX)>;
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
new file mode 100644
index 000000000..86ec11361
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
@@ -0,0 +1,186 @@
+* Marvell Armada 37xx SoC pin and GPIO controller
+
+Each Armada 37xx SoC comes with two pin and GPIO controllers, one for the
+South Bridge and the other for the North Bridge.
+
+GPIO and pin controller:
+------------------------
+
+Main node:
+
+Refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning
+of the phrase "pin configuration node".
+
+Required properties for pinctrl driver:
+
+- compatible: "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
+ for the South Bridge
+ "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
+ for the North Bridge
+- reg: The first set of registers is for pinctrl/GPIO and the second
+ set is for the interrupt controller
+- interrupts: list of interrupts used by the GPIO
+
+Available groups and functions for the North Bridge:
+
+group: jtag
+ - pins 20-24
+ - functions jtag, gpio
+
+group sdio0
+ - pins 8-10
+ - functions sdio, gpio
+
+group emmc_nb
+ - pins 27-35
+ - functions emmc, gpio
+
+group pwm0
+ - pin 11 (GPIO1-11)
+ - functions pwm, gpio
+
+group pwm1
+ - pin 12
+ - functions pwm, gpio
+
+group pwm2
+ - pin 13
+ - functions pwm, gpio
+
+group pwm3
+ - pin 14
+ - functions pwm, gpio
+
+group pmic1
+ - pin 7
+ - functions pmic, gpio
+
+group pmic0
+ - pin 6
+ - functions pmic, gpio
+
+group i2c2
+ - pins 2-3
+ - functions i2c, gpio
+
+group i2c1
+ - pins 0-1
+ - functions i2c, gpio
+
+group spi_cs1
+ - pin 17
+ - functions spi, gpio
+
+group spi_cs2
+ - pin 18
+ - functions spi, gpio
+
+group spi_cs3
+ - pin 19
+ - functions spi, gpio
+
+group onewire
+ - pin 4
+ - functions onewire, gpio
+
+group uart1
+ - pins 25-26
+ - functions uart, gpio
+
+group spi_quad
+ - pins 15-16
+ - functions spi, gpio
+
+group uart_2
+ - pins 9-10
+ - functions uart, gpio
+
+Available groups and functions for the South Bridge:
+
+group usb32_drvvbus0
+ - pin 36
+ - functions drvbus, gpio
+
+group usb2_drvvbus1
+ - pin 37
+ - functions drvbus, gpio
+
+group sdio_sb
+ - pins 60-65
+ - functions sdio, gpio
+
+group rgmii
+ - pins 42-53
+ - functions mii, gpio
+
+group pcie1
+ - pins 39-41
+ - functions pcie, gpio
+
+group smi
+ - pins 54-55
+ - functions smi, gpio
+
+group ptp
+ - pins 56-58
+ - functions ptp, gpio
+
+group ptp_clk
+ - pin 57
+ - functions ptp, mii
+
+group ptp_trig
+ - pin 58
+ - functions ptp, mii
+
+group mii_col
+ - pin 59
+ - functions mii, mii_err
+
+GPIO subnode:
+
+Please refer to gpio.txt in "gpio" directory for details of gpio-ranges property
+and the common GPIO bindings used by client devices.
+
+Required properties for the GPIO driver under the gpio subnode:
+- interrupts: List of interrupt specifiers for the controllers interrupt.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be 2. The first cell is the GPIO number and the
+ second cell specifies GPIO flags, as defined in
+ <dt-bindings/gpio/gpio.h>. Only the GPIO_ACTIVE_HIGH and
+ GPIO_ACTIVE_LOW flags are supported.
+- gpio-ranges: Range of pins managed by the GPIO controller.
+
+Example:
+pinctrl_sb: pinctrl-sb@18800 {
+ compatible = "marvell,armada3710-sb-pinctrl",
+ "syscon", "simple-mfd";
+ reg = <0x18800 0x100>, <0x18C00 0x20>;
+ gpiosb: gpiosb {
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_sb 0 0 30>;
+ gpio-controller;
+ interrupts =
+ <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ rgmii_pins: mii-pins {
+ groups = "rgmii";
+ function = "mii";
+ };
+
+ sdio_pins: sdio-pins {
+ groups = "sdio_sb";
+ function = "sdio";
+ };
+
+ pcie_pins: pcie-pins {
+ groups = "pcie1";
+ function = "pcie";
+ };
+}; \ No newline at end of file
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt
new file mode 100644
index 000000000..51f2f2c79
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt
@@ -0,0 +1,25 @@
+ Functions of Armada APN806 pin controller
+ Function 0x0 for any MPP ID activates GPIO pin mode
+----------------------------------------------------------------------
+MPP# 0x1 0x2 0x3 0x4
+----------------------------------------------------------------------
+0 SDIO_CLK - SPI0_CLK -
+1 SDIO_CMD - SPI0_MISO -
+2 SDIO_D[0] - SPI0_MOSI -
+3 SDIO_D[1] - SPI0_CS0n -
+4 SDIO_D[2] - I2C0_SDA SPI0_CS1n
+5 SDIO_D[3] - I2C0_SCK -
+6 SDIO_DS - - -
+7 SDIO_D[4] - UART1_RXD -
+8 SDIO_D[5] - UART1_TXD -
+9 SDIO_D[6] - SPI0_CS1n -
+10 SDIO_D[7] - - -
+11 - - UART0_TXD -
+12 SDIO_CARD_PW_OFF SDIO_HW_RST - -
+13 - - - -
+14 - - - -
+15 - - - -
+16 - - - -
+17 - - - -
+18 - - - -
+19 - - UART0_RXD -
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt
new file mode 100644
index 000000000..3adcf3aae
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt
@@ -0,0 +1,270 @@
+ Functions of Armada CP110 pin controller
+ Function 0x0 for any MPP ID activates GPIO pin mode
+ Function 0xc for any MPP ID activates DEBUG_BUS pin mode
+-------------------------------------------------------------------------------
+MPP# 0x1 0x2 0x3 0x4
+-------------------------------------------------------------------------------
+0 DEV_ALE[1] AU_I2SMCLK GE0_RXD[3] TDM_PCLK
+1 DEV_ALE[0] AU_I2SDO_SPDIFO GE0_RXD[2] TDM_DRX
+2 DEV_AD[15] AU_I2SEXTCLK GE0_RXD[1] TDM_DTX
+3 DEV_AD[14] AU_I2SLRCLK GE0_RXD[0] TDM_FSYNC
+4 DEV_AD[13] AU_I2SBCLK GE0_RXCTL TDM_RSTn
+5 DEV_AD[12] AU_I2SDI GE0_RXCLK TDM_INTn
+6 DEV_AD[11] - GE0_TXD[3] SPI0_CSn[2]
+7 DEV_AD[10] - GE0_TXD[2] SPI0_CSn[1]
+8 DEV_AD[9] - GE0_TXD[1] SPI0_CSn[0]
+9 DEV_AD[8] - GE0_TXD[0] SPI0_MOSI
+10 DEV_READYn - GE0_TXCTL SPI0_MISO
+11 DEV_WEn[1] - GE0_TXCLKOUT SPI0_CLK
+12 DEV_CLK_OUT NF_RBn[1] SPI1_CSn[1] GE0_RXCLK
+13 DEV_BURSTn NF_RBn[0] SPI1_MISO GE0_RXCTL
+14 DEV_BOOTCSn DEV_CSn[0] SPI1_CSn[0] SPI0_CSn[3]
+15 DEV_AD[7] - SPI1_MOSI -
+16 DEV_AD[6] - SPI1_CLK -
+17 DEV_AD[5] - - GE0_TXD[3]
+18 DEV_AD[4] - - GE0_TXD[2]
+19 DEV_AD[3] - - GE0_TXD[1]
+20 DEV_AD[2] - - GE0_TXD[0]
+21 DEV_AD[1] - - GE0_TXCTL
+22 DEV_AD[0] - - GE0_TXCLKOUT
+23 DEV_A[1] - - -
+24 DEV_A[0] - - -
+25 DEV_OEn - - - -
+26 DEV_WEn[0] - - -
+27 DEV_CSn[0] SPI1_MISO MSS_GPIO[4] GE0_RXD[3]
+28 DEV_CSn[1] SPI1_CSn[0] MSS_GPIO[5] GE0_RXD[2]
+29 DEV_CSn[2] SPI1_MOSI MSS_GPIO[6] GE0_RXD[1]
+30 DEV_CSn[3] SPI1_CLK MSS_GPIO[7] GE0_RXD[0]
+31 DEV_A[2] - MSS_GPIO[4] -
+32 MII_COL MII_TXERR MSS_SPI_MISO TDM_DRX
+33 MII_TXCLK SDIO_PWR1[0] MSS_SPI_CSn TDM_FSYNC
+34 MII_RXERR SDIO_PWR1[1] MSS_SPI_MOSI TDM_DTX
+35 SATA1_PRESENT_ACTIVEn TWSI1_SDA MSS_SPI_CLK TDM_PCLK
+36 SYNCE2_CLK TWSI1_SCK PTP_CLK SYNCE1_CLK
+37 UART2_RXD TWSI0_SCK PTP_PCLK_OUT TDM_INTn
+38 UART2_TXD TWSI0_SDA PTP_PULSE TDM_RSTn
+39 SDIO_WR_PROTECT - - AU_I2SBCLK PTP_CLK
+40 SDIO_PWR1[1] SYNCE1_CLK MSS_TWSI_SDA AU_I2SDO_SPDIFO
+41 SDIO_PWR1[0] SDIO_BUS_PWR MSS_TWSI_SCK AU_I2SLRCLK
+42 SDIO_V18_EN SDIO_WR_PROTECT SYNCE2_CLK AU_I2SMCLK
+43 SDIO_CARD_DETECT - SYNCE1_CLK AU_I2SEXTCLK
+44 GE1_TXD[2] - - -
+45 GE1_TXD[3] - - -
+46 GE1_TXD[1] - - -
+47 GE1_TXD[0] - - -
+48 GE1_TXCTL_MII_TXEN - - -
+49 GE1_TXCLKOUT MII_CRS - -
+50 GE1_RXCLK MSS_TWSI_SDA - -
+51 GE1_RXD[0] MSS_TWSI_SCK - -
+52 GE1_RXD[1] SYNCE1_CLK - SYNCE2_CLK
+53 GE1_RXD[2] - PTP_CLK -
+54 GE1_RXD[3] SYNCE2_CLK PTP_PCLK_OUT SYNCE1_CLK
+55 GE1_RXCTL_MII_RXDV - PTP_PULSE -
+56 - - - TDM_DRX
+57 - MSS_TWSI_SDA PTP_PCLK_OUT TDM_INTn
+58 - MSS_TWSI_SCK PTP_CLK TDM_RSTn
+59 MSS_GPIO[7] SYNCE2_CLK - TDM_FSYNC
+60 MSS_GPIO[6] - PTP_PULSE TDM_DTX
+61 MSS_GPIO[5] - PTP_CLK TDM_PCLK
+62 MSS_GPIO[4] SYNCE1_CLK PTP_PCLK_OUT -
+
+-------------------------------------------------------------------------------
+MPP# 0x5 0x6 0x7
+-------------------------------------------------------------------------------
+0 - PTP_PULSE MSS_TWSI_SDA
+1 - PTP_CLK MSS_TWSI_SCK
+2 MSS_UART_RXD PTP_PCLK_OUT TWSI1_SCK
+3 MSS_UART_TXD PCIe_RSTOUTn TWSI1_SDA
+4 MSS_UART_RXD UART1_CTS PCIe0_CLKREQ
+5 MSS_UART_TXD UART1_RTS PCIe1_CLKREQ
+6 AU_I2SEXTCLK SATA1_PRESENT_ACTIVEn PCIe2_CLKREQ
+7 SPI1_CSn[1] SATA0_PRESENT_ACTIVEn LED_DATA
+8 SPI1_CSn[0] UART0_CTS LED_STB
+9 SPI1_MOSI - PCIe_RSTOUTn
+10 SPI1_MISO UART0_CTS SATA1_PRESENT_ACTIVEn
+11 SPI1_CLK UART0_RTS LED_CLK
+12 - - -
+13 - - -
+14 AU_I2SEXTCLK SPI0_MISO SATA0_PRESENT_ACTIVEn
+15 - SPI0_MOSI -
+16 - - -
+17 - - -
+18 - - -
+19 - - -
+20 - - -
+21 - - -
+22 - - -
+23 AU_I2SMCLK - -
+24 AU_I2SLRCLK - -
+25 AU_I2SDO_SPDIFO - -
+26 AU_I2SBCLK - -
+27 SPI0_CSn[4] - -
+28 SPI0_CSn[5] PCIe2_CLKREQ PTP_PULSE
+29 SPI0_CSn[6] PCIe1_CLKREQ PTP_CLK
+30 SPI0_CSn[7] PCIe0_CLKREQ PTP_PCLK_OUT
+31 - PCIe_RSTOUTn -
+32 AU_I2SEXTCLK AU_I2SDI GE_MDIO
+33 AU_I2SMCLK SDIO_BUS_PWR -
+34 AU_I2SLRCLK SDIO_WR_PROTECT GE_MDC
+35 AU_I2SDO_SPDIFO SDIO_CARD_DETECT XG_MDIO
+36 AU_I2SBCLK SATA0_PRESENT_ACTIVEn XG_MDC
+37 MSS_TWSI_SCK SATA1_PRESENT_ACTIVEn GE_MDC
+38 MSS_TWSI_SDA SATA0_PRESENT_ACTIVEn GE_MDIO
+39 SPI0_CSn[1] - -
+40 PTP_PCLK_OUT SPI0_CLK UART1_TXD
+41 PTP_PULSE SPI0_MOSI UART1_RXD
+42 MSS_UART_TXD SPI0_MISO UART1_CTS
+43 MSS_UART_RXD SPI0_CSn[0] UART1_RTS
+44 - - UART0_RTS
+45 - - UART0_TXD
+46 - - UART1_RTS
+47 SPI1_CLK - UART1_TXD
+48 SPI1_MOSI - -
+49 SPI1_MISO - UART1_RXD
+50 SPI1_CSn[0] UART2_TXD UART0_RXD
+51 SPI1_CSn[1] UART2_RXD UART0_CTS
+52 SPI1_CSn[2] - UART1_CTS
+53 SPI1_CSn[3] - UART1_RXD
+54 - - -
+55 - - -
+56 AU_I2SDO_SPDIFO SPI0_CLK UART1_RXD
+57 AU_I2SBCLK SPI0_MOSI UART1_TXD
+58 AU_I2SDI SPI0_MISO UART1_CTS
+59 AU_I2SLRCLK SPI0_CSn[0] UART0_CTS
+60 AU_I2SMCLK SPI0_CSn[1] UART0_RTS
+61 AU_I2SEXTCLK SPI0_CSn[2] UART0_TXD
+62 SATA1_PRESENT_ACTIVEn SPI0_CSn[3] UART0_RXD
+
+-------------------------------------------------------------------------------
+MPP# 0x8 0x9 0xA
+-------------------------------------------------------------------------------
+0 UART0_RXD SATA0_PRESENT_ACTIVEn GE_MDIO
+1 UART0_TXD SATA1_PRESENT_ACTIVEn GE_MDC
+2 UART1_RXD SATA0_PRESENT_ACTIVEn XG_MDC
+3 UART1_TXD SATA1_PRESENT_ACTIVEn XG_MDIO
+4 UART3_RXD - GE_MDC
+5 UART3_TXD - GE_MDIO
+6 UART0_RXD PTP_PULSE -
+7 UART0_TXD PTP_CLK -
+8 UART2_RXD PTP_PCLK_OUT SYNCE1_CLK
+9 - - SYNCE2_CLK
+10 - - -
+11 UART2_TXD SATA0_PRESENT_ACTIVEn -
+12 - - -
+13 MSS_SPI_MISO - -
+14 MSS_SPI_CSn - -
+15 MSS_SPI_MOSI - -
+16 MSS_SPI_CLK - -
+17 - - -
+18 - - -
+19 - - -
+20 - - -
+21 - - -
+22 - - -
+23 - - -
+24 - - -
+25 - - -
+26 - - -
+27 GE_MDIO SATA0_PRESENT_ACTIVEn UART0_RTS
+28 GE_MDC SATA1_PRESENT_ACTIVEn UART0_CTS
+29 MSS_TWSI_SDA SATA0_PRESENT_ACTIVEn UART0_RXD
+30 MSS_TWSI_SCK SATA1_PRESENT_ACTIVEn UART0_TXD
+31 GE_MDC - -
+32 SDIO_V18_EN PCIe1_CLKREQ MSS_GPIO[0]
+33 XG_MDIO PCIe2_CLKREQ MSS_GPIO[1]
+34 - PCIe0_CLKREQ MSS_GPIO[2]
+35 GE_MDIO PCIe_RSTOUTn MSS_GPIO[3]
+36 GE_MDC PCIe2_CLKREQ MSS_GPIO[5]
+37 XG_MDC PCIe1_CLKREQ MSS_GPIO[6]
+38 XG_MDIO AU_I2SEXTCLK MSS_GPIO[7]
+39 SATA1_PRESENT_ACTIVEn MSS_GPIO[0]
+40 GE_MDIO SATA0_PRESENT_ACTIVEn MSS_GPIO[1]
+41 GE_MDC SATA1_PRESENT_ACTIVEn MSS_GPIO[2]
+42 XG_MDC SATA0_PRESENT_ACTIVEn MSS_GPIO[4]
+43 XG_MDIO SATA1_PRESENT_ACTIVEn MSS_GPIO[5]
+44 - - -
+45 - PCIe_RSTOUTn -
+46 - - -
+47 GE_MDC CLKOUT -
+48 XG_MDC - -
+49 GE_MDIO PCIe0_CLKREQ SDIO_V18_EN
+50 XG_MDIO - SDIO_PWR1[1]
+51 - - SDIO_PWR1[0]
+52 LED_CLK PCIe_RSTOUTn PCIe0_CLKREQ
+53 LED_STB - -
+54 LED_DATA - SDIO_HW_RST
+55 - - SDIO_LED
+56 - SATA1_PRESENT_ACTIVEn -
+57 - SATA0_PRESENT_ACTIVEn -
+58 LED_CLK - -
+59 LED_STB UART1_TXD -
+60 LED_DATA UART1_RXD -
+61 UART2_TXD SATA1_PRESENT_ACTIVEn GE_MDIO
+62 UART2_RXD SATA0_PRESENT_ACTIVEn GE_MDC
+
+-------------------------------------------------------------------------------
+MPP# 0xB 0xD 0xE
+-------------------------------------------------------------------------------
+0 - - -
+1 - - -
+2 - - -
+3 - - -
+4 - - -
+5 - - -
+6 - - -
+7 - - -
+8 - - -
+9 - - -
+10 - - -
+11 - CLKOUT_MPP_11 -
+12 - - -
+13 - - -
+14 - - -
+15 PTP_PULSE_CP2CP SAR_IN[5] -
+16 - SAR_IN[3] -
+17 - SAR_IN[6] -
+18 PTP_CLK_CP2CP SAR_IN[11] -
+19 WAKEUP_OUT_CP2CP SAR_IN[7] -
+20 - SAR_IN[9] -
+21 SEI_IN_CP2CP SAR_IN[8] -
+22 WAKEUP_IN_CP2CP SAR_IN[10] -
+23 LINK_RD_IN_CP2CP SAR_IN[4] -
+24 - - -
+25 - CLKOUT_MPP_25 -
+26 - SAR_IN[0] -
+27 REI_IN_CP2CP SAR_IN[1] -
+28 LED_DATA SAR_IN[2] -
+29 LED_STB AVS_FB_IN_CP2CP -
+30 LED_CLK SAR_IN[13] -
+31 - - -
+32 - SAR_CP2CP_OUT[0] -
+33 - SAR_CP2CP_OUT[1] -
+34 - SAR_CP2CP_OUT[2] -
+35 - SAR_CP2CP_OUT[3] -
+36 - CLKIN -
+37 LINK_RD_OUT_CP2CP SAR_CP2CP_OUT[4] -
+38 PTP_PULSE_CP2CP SAR_CP2CP_OUT[5] -
+39 - AVS_FB_OUT_CP2CP -
+40 - - -
+41 REI_OUT_CP2CP - -
+42 - SAR_CP2CP_OUT[9] -
+43 WAKEUP_OUT_CP2CP SAR_CP2CP_OUT[10] -
+44 PTP_CLK_CP2CP SAR_CP2CP_OUT[11] -
+45 - SAR_CP2CP_OUT[6] -
+46 - SAR_CP2CP_OUT[13] -
+47 - - -
+48 WAKEUP_IN_CP2CP SAR_CP2CP_OUT[7] -
+49 SEI_OUT_CP2CP SAR_CP2CP_OUT[8] -
+50 - - -
+51 - - -
+52 - - -
+53 SDIO_LED - -
+54 SDIO_WR_PROTECT - -
+55 SDIO_CARD_DETECT - -
+56 - - SDIO0_CLK
+57 - - SDIO0_CMD
+58 - - SDIO0_D[0]
+59 - - SDIO0_D[1]
+60 - - SDIO0_D[2]
+61 - - SDIO0_D[3]
+62 - - -
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt
new file mode 100644
index 000000000..1fc1bc664
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt
@@ -0,0 +1,113 @@
+The pinctrl driver enables Marvell Armada 8K SoCs to configure the multi-purpose
+pins (mpp) to a specific function.
+A Marvell SoC pin configuration node is a node of a group of pins which can
+be used for a specific device or function. Each node requires one or more
+mpp pins or group of pins and a mpp function common to all pins.
+
+Required properties for the pinctrl driver:
+- compatible: "marvell,mvebu-pinctrl",
+ "marvell,ap806-pinctrl",
+ "marvell,armada-7k-pinctrl",
+ "marvell,armada-8k-cpm-pinctrl",
+ "marvell,armada-8k-cps-pinctrl"
+- bank-name: A string defining the pinc controller bank name
+- reg: A pair of values defining the pin controller base address
+ and the address space
+- pin-count: Numeric value defining the amount of multi purpose pins
+ included in this bank
+- max-func: Numeric value defining the maximum function value for
+ pins in this bank
+- pin-func: Array of pin function values for every pin in the bank.
+ When the function value for a specific pin equal 0xFF,
+ the pin configuration is skipped and a default function
+ value is used for this pin.
+
+The A8K is a hybrid SoC that contains several silicon dies interconnected in
+a single package. Each such die may have a separate pin controller.
+
+Example:
+/ {
+ ap806 {
+ config-space {
+ pinctl: pinctl@6F4000 {
+ compatible = "marvell,mvebu-pinctrl",
+ "marvell,ap806-pinctrl";
+ bank-name ="apn-806";
+ reg = <0x6F4000 0x10>;
+ pin-count = <20>;
+ max-func = <3>;
+ /* MPP Bus:
+ * SPI0 [0-3]
+ * I2C0 [4-5]
+ * UART0 [11,19]
+ */
+ /* 0 1 2 3 4 5 6 7 8 9 */
+ pin-func = < 3 3 3 3 3 3 0 0 0 0
+ 0 3 0 0 0 0 0 0 0 3>;
+ };
+ };
+ };
+
+ cp110-master {
+ config-space {
+ cpm_pinctl: pinctl@44000 {
+ compatible = "marvell,mvebu-pinctrl",
+ "marvell,armada-7k-pinctrl",
+ "marvell,armada-8k-cpm-pinctrl";
+ bank-name ="cp0-110";
+ reg = <0x440000 0x20>;
+ pin-count = <63>;
+ max-func = <0xf>;
+ /* MPP Bus:
+ * [0-31] = 0xff: Keep default CP0_shared_pins:
+ * [11] CLKOUT_MPP_11 (out)
+ * [23] LINK_RD_IN_CP2CP (in)
+ * [25] CLKOUT_MPP_25 (out)
+ * [29] AVS_FB_IN_CP2CP (in)
+ * [32,34] SMI
+ * [31] GPIO: push button/Wake
+ * [35-36] GPIO
+ * [37-38] I2C
+ * [40-41] SATA[0/1]_PRESENT_ACTIVEn
+ * [42-43] XSMI
+ * [44-55] RGMII1
+ * [56-62] SD
+ */
+ /* 0 1 2 3 4 5 6 7 8 9 */
+ pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0 7 0 7 0 0 2 2 0
+ 0 0 8 8 1 1 1 1 1 1
+ 1 1 1 1 1 1 0xE 0xE 0xE 0xE
+ 0xE 0xE 0xE>;
+ };
+ };
+ };
+
+ cp110-slave {
+ config-space {
+ cps_pinctl: pinctl@44000 {
+ compatible = "marvell,mvebu-pinctrl",
+ "marvell,armada-8k-cps-pinctrl";
+ bank-name ="cp1-110";
+ reg = <0x440000 0x20>;
+ pin-count = <63>;
+ max-func = <0xf>;
+ /* MPP Bus:
+ * [0-11] RGMII0
+ * [27,31] GE_MDIO/MDC
+ * [32-62] = 0xff: Keep default CP1_shared_pins:
+ */
+ /* 0 1 2 3 4 5 6 7 8 9 */
+ pin-func = < 0x3 0x3 0x3 0x3 0x3 0x3 0x3 0x3 0x3 0x3
+ 0x3 0x3 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x8 0xff 0xff
+ 0xff 0x8 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+ 0xff 0xff 0xff>;
+ };
+ };
+ };
+}
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt
new file mode 100644
index 000000000..115ab53a4
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt
@@ -0,0 +1,78 @@
+Binding for Nexell s5pxx18 pin cotroller
+========================================
+
+Nexell's ARM bases SoC's integrates a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pads/pins
+and also provides ability to multiplex and configure the output of various
+on-chip controllers onto these pads.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+
+Required properties:
+ - compatible: "nexell,s5pxx18-pinctrl"
+ - reg: should be register base and length as documented in the datasheet
+ - interrupts: interrupt specifier for the controller over gpio and alive pins
+
+Example:
+pinctrl_0: pinctrl@c0010000 {
+ compatible = "nexell,s5pxx18-pinctrl";
+ reg = <0xc0010000 0xf000>;
+ u-boot,dm-pre-reloc;
+};
+
+Nexell's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters.
+
+ Child nodes must be set at least one of the following settings:
+ - pins = Select pins for using this function.
+ - pin-function = Select the function for use in a selected pin.
+ - pin-pull = Pull up/down configuration.
+ - pin-strength = Drive strength configuration.
+
+ Valid values for nexell,pins are:
+ "gpioX-N" : X in {A,B,C,D,E}, N in {0-31}
+ Valid values for nexell,pin-function are:
+ "N" : N in {0-3}.
+ This setting means that the value is different for each pin.
+ Please refer to datasheet.
+ Valid values for nexell,pin-pull are:
+ "N" : 0 - Down, 1 - Up, 2 - Off
+ Valid values for nexell,pin-strength are:
+ "N" : 0,1,2,3
+
+
+Example:
+ - pin settings
+ mmc0_clk: mmc0-clk {
+ pins = "gpioa-29";
+ pin-function = <1>;
+ pin-pull = <2>;
+ pin-strength = <2>;
+ };
+
+ mmc0_cmd: mmc0-cmd {
+ pins = "gpioa-31";
+ pin-function = <1>;
+ pin-pull = <2>;
+ pin-strength = <1>;
+ };
+
+ mmc0_bus4: mmc0-bus-width4 {
+ pins = "gpiob-1, gpiob-3, gpiob-5, gpiob-7";
+ pin-function = <1>;
+ pin-pull = <2>;
+ pin-strength = <1>;
+ };
+
+ - used by client devices
+ mmc0:mmc@... {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_clk>, <&mmc0_cmd>, <&mmc0_bus4>;
+ ...
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt
new file mode 100644
index 000000000..603796f16
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt
@@ -0,0 +1,289 @@
+== Introduction ==
+
+Hardware modules that control pin multiplexing or configuration parameters
+such as pull-up/down, tri-state, drive-strength etc are designated as pin
+controllers. Each pin controller must be represented as a node in device tree,
+just like any other hardware module.
+
+Hardware modules whose signals are affected by pin configuration are
+designated client devices. Again, each client device must be represented as a
+node in device tree, just like any other hardware module.
+
+For a client device to operate correctly, certain pin controllers must
+set up certain specific pin configurations. Some client devices need a
+single static pin configuration, e.g. set up during initialization. Others
+need to reconfigure pins at run-time, for example to tri-state pins when the
+device is inactive. Hence, each client device can define a set of named
+states. The number and names of those states is defined by the client device's
+own binding.
+
+The common pinctrl bindings defined in this file provide an infrastructure
+for client device device tree nodes to map those state names to the pin
+configuration used by those states.
+
+Note that pin controllers themselves may also be client devices of themselves.
+For example, a pin controller may set up its own "active" state when the
+driver loads. This would allow representing a board's static pin configuration
+in a single place, rather than splitting it across multiple client device
+nodes. The decision to do this or not somewhat rests with the author of
+individual board device tree files, and any requirements imposed by the
+bindings for the individual client devices in use by that board, i.e. whether
+they require certain specific named states for dynamic pin configuration.
+
+== Pinctrl client devices ==
+
+For each client device individually, every pin state is assigned an integer
+ID. These numbers start at 0, and are contiguous. For each state ID, a unique
+property exists to define the pin configuration. Each state may also be
+assigned a name. When names are used, another property exists to map from
+those names to the integer IDs.
+
+Each client device's own binding determines the set of states that must be
+defined in its device tree node, and whether to define the set of state
+IDs that must be provided, or whether to define the set of state names that
+must be provided.
+
+Required properties:
+pinctrl-0: List of phandles, each pointing at a pin configuration
+ node. These referenced pin configuration nodes must be child
+ nodes of the pin controller that they configure. Multiple
+ entries may exist in this list so that multiple pin
+ controllers may be configured, or so that a state may be built
+ from multiple nodes for a single pin controller, each
+ contributing part of the overall configuration. See the next
+ section of this document for details of the format of these
+ pin configuration nodes.
+
+ In some cases, it may be useful to define a state, but for it
+ to be empty. This may be required when a common IP block is
+ used in an SoC either without a pin controller, or where the
+ pin controller does not affect the HW module in question. If
+ the binding for that IP block requires certain pin states to
+ exist, they must still be defined, but may be left empty.
+
+Optional properties:
+pinctrl-1: List of phandles, each pointing at a pin configuration
+ node within a pin controller.
+...
+pinctrl-n: List of phandles, each pointing at a pin configuration
+ node within a pin controller.
+pinctrl-names: The list of names to assign states. List entry 0 defines the
+ name for integer state ID 0, list entry 1 for state ID 1, and
+ so on.
+
+For example:
+
+ /* For a client device requiring named states */
+ device {
+ pinctrl-names = "active", "idle";
+ pinctrl-0 = <&state_0_node_a>;
+ pinctrl-1 = <&state_1_node_a &state_1_node_b>;
+ };
+
+ /* For the same device if using state IDs */
+ device {
+ pinctrl-0 = <&state_0_node_a>;
+ pinctrl-1 = <&state_1_node_a &state_1_node_b>;
+ };
+
+ /*
+ * For an IP block whose binding supports pin configuration,
+ * but in use on an SoC that doesn't have any pin control hardware
+ */
+ device {
+ pinctrl-names = "active", "idle";
+ pinctrl-0 = <>;
+ pinctrl-1 = <>;
+ };
+
+== Pin controller devices ==
+
+Pin controller devices should contain the pin configuration nodes that client
+devices reference.
+
+For example:
+
+ pincontroller {
+ ... /* Standard DT properties for the device itself elided */
+
+ state_0_node_a {
+ ...
+ };
+ state_1_node_a {
+ ...
+ };
+ state_1_node_b {
+ ...
+ };
+ }
+
+The contents of each of those pin configuration child nodes is defined
+entirely by the binding for the individual pin controller device. There
+exists no common standard for this content. The pinctrl framework only
+provides generic helper bindings that the pin controller driver can use.
+
+The pin configuration nodes need not be direct children of the pin controller
+device; they may be grandchildren, for example. Whether this is legal, and
+whether there is any interaction between the child and intermediate parent
+nodes, is again defined entirely by the binding for the individual pin
+controller device.
+
+== Generic pin multiplexing node content ==
+
+pin multiplexing nodes:
+
+function - the mux function to select
+groups - the list of groups to select with this function
+ (either this or "pins" must be specified)
+pins - the list of pins to select with this function (either
+ this or "groups" must be specified)
+
+Example:
+
+state_0_node_a {
+ uart0 {
+ function = "uart0";
+ groups = "u0rxtx", "u0rtscts";
+ };
+};
+state_1_node_a {
+ spi0 {
+ function = "spi0";
+ groups = "spi0pins";
+ };
+};
+state_2_node_a {
+ function = "i2c0";
+ pins = "mfio29", "mfio30";
+};
+
+For hardware where pin multiplexing configurations have to be specified for
+each single pin the number of required sub-nodes containing "pin" and
+"function" properties can quickly escalate and become hard to write and
+maintain.
+
+For cases like this, the pin controller driver may use the pinmux helper
+property, where the pin identifier is provided with mux configuration settings
+in a pinmux group. A pinmux group consists of the pin identifier and mux
+settings represented as a single integer or an array of integers.
+
+The pinmux property accepts an array of pinmux groups, each of them describing
+a single pin multiplexing configuration.
+
+pincontroller {
+ state_0_node_a {
+ pinmux = <PINMUX_GROUP>, <PINMUX_GROUP>, ...;
+ };
+};
+
+Each individual pin controller driver bindings documentation shall specify
+how pin IDs and pin multiplexing configuration are defined and assembled
+together in a pinmux group.
+
+== Generic pin configuration node content ==
+
+Many data items that are represented in a pin configuration node are common
+and generic. Pin control bindings should use the properties defined below
+where they are applicable; not all of these properties are relevant or useful
+for all hardware or binding structures. Each individual binding document
+should state which of these generic properties, if any, are used, and the
+structure of the DT nodes that contain these properties.
+
+Supported generic properties are:
+
+pins - the list of pins that properties in the node
+ apply to (either this, "group" or "pinmux" has to be
+ specified)
+group - the group to apply the properties to, if the driver
+ supports configuration of whole groups rather than
+ individual pins (either this, "pins" or "pinmux" has
+ to be specified)
+pinmux - the list of numeric pin ids and their mux settings
+ that properties in the node apply to (either this,
+ "pins" or "groups" have to be specified)
+bias-disable - disable any pin bias
+bias-high-impedance - high impedance mode ("third-state", "floating")
+bias-bus-hold - latch weakly
+bias-pull-up - pull up the pin
+bias-pull-down - pull down the pin
+bias-pull-pin-default - use pin-default pull state
+drive-push-pull - drive actively high and low
+drive-open-drain - drive with open drain
+drive-open-source - drive with open source
+drive-strength - sink or source at most X mA
+drive-strength-microamp - sink or source at most X uA
+input-enable - enable input on pin (no effect on output, such as
+ enabling an input buffer)
+input-disable - disable input on pin (no effect on output, such as
+ disabling an input buffer)
+input-schmitt-enable - enable schmitt-trigger mode
+input-schmitt-disable - disable schmitt-trigger mode
+input-debounce - debounce mode with debound time X
+power-source - select between different power supplies
+low-power-enable - enable low power mode
+low-power-disable - disable low power mode
+output-disable - disable output on a pin (such as disable an output
+ buffer)
+output-enable - enable output on a pin without actively driving it
+ (such as enabling an output buffer)
+output-low - set the pin to output mode with low level
+output-high - set the pin to output mode with high level
+sleep-hardware-state - indicate this is sleep related state which will be programmed
+ into the registers for the sleep state.
+slew-rate - set the slew rate
+skew-delay - this affects the expected clock skew on input pins
+ and the delay before latching a value to an output
+ pin. Typically indicates how many double-inverters are
+ used to delay the signal.
+
+For example:
+
+state_0_node_a {
+ cts_rxd {
+ pins = "GPIO0_AJ5", "GPIO2_AH4"; /* CTS+RXD */
+ bias-pull-up;
+ };
+};
+state_1_node_a {
+ rts_txd {
+ pins = "GPIO1_AJ3", "GPIO3_AH3"; /* RTS+TXD */
+ output-high;
+ };
+};
+state_2_node_a {
+ foo {
+ group = "foo-group";
+ bias-pull-up;
+ };
+};
+state_3_node_a {
+ mux {
+ pinmux = <GPIOx_PINm_MUXn>, <GPIOx_PINj_MUXk)>;
+ input-enable;
+ };
+};
+
+Some of the generic properties take arguments. For those that do, the
+arguments are described below.
+
+- pins takes a list of pin names or IDs as a required argument. The specific
+ binding for the hardware defines:
+ - Whether the entries are integers or strings, and their meaning.
+
+- pinmux takes a list of pin IDs and mux settings as required argument. The
+ specific bindings for the hardware defines:
+ - How pin IDs and mux settings are defined and assembled together in a single
+ integer or an array of integers.
+
+- bias-pull-up, -down and -pin-default take as optional argument on hardware
+ supporting it the pull strength in Ohm. bias-disable will disable the pull.
+
+- drive-strength takes as argument the target strength in mA.
+
+- drive-strength-microamp takes as argument the target strength in uA.
+
+- input-debounce takes the debounce time in usec as argument
+ or 0 to disable debouncing
+
+More in-depth documentation on these parameters can be found in
+<include/linux/pinctrl/pinconf-generic.h>
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/rockchip,pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/rockchip,pinctrl.txt
new file mode 100644
index 000000000..388b21324
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/rockchip,pinctrl.txt
@@ -0,0 +1,157 @@
+* Rockchip Pinmux Controller
+
+The Rockchip Pinmux Controller, enables the IC
+to share one PAD to several functional blocks. The sharing is done by
+multiplexing the PAD input/output signals. For each PAD there are several
+muxing options with option 0 being the use as a GPIO.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The Rockchip pin configuration node is a node of a group of pins which can be
+used for a specific device or function. This node represents both mux and
+config of the pins in that group. The 'pins' selects the function mode(also
+named pin mode) this pin can work on and the 'config' configures various pad
+settings such as pull-up, etc.
+
+The pins are grouped into up to 5 individual pin banks which need to be
+defined as gpio sub-nodes of the pinmux controller.
+
+Required properties for iomux controller:
+ - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
+ "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
+ "rockchip,rk3288-pinctrl"
+ - rockchip,grf: phandle referencing a syscon providing the
+ "general register files"
+
+Optional properties for iomux controller:
+ - rockchip,pmu: phandle referencing a syscon providing the pmu registers
+ as some SoCs carry parts of the iomux controller registers there.
+ Required for at least rk3188 and rk3288.
+
+Deprecated properties for iomux controller:
+ - reg: first element is the general register space of the iomux controller
+ It should be large enough to contain also separate pull registers.
+ second element is the separate pull register space of the rk3188.
+ Use rockchip,grf and rockchip,pmu described above instead.
+
+Required properties for gpio sub nodes:
+ - compatible: "rockchip,gpio-bank"
+ - reg: register of the gpio bank (different than the iomux registerset)
+ - interrupts: base interrupt of the gpio bank in the interrupt controller
+ - clocks: clock that drives this bank
+ - gpio-controller: identifies the node as a gpio controller and pin bank.
+ - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
+ binding is used, the amount of cells must be specified as 2. See generic
+ GPIO binding documentation for description of particular cells.
+ - interrupt-controller: identifies the controller node as interrupt-parent.
+ - #interrupt-cells: the value of this property should be 2 and the interrupt
+ cells should use the standard two-cell scheme described in
+ bindings/interrupt-controller/interrupts.txt
+
+Deprecated properties for gpio sub nodes:
+ - compatible: "rockchip,rk3188-gpio-bank0"
+ - reg: second element: separate pull register for rk3188 bank0, use
+ rockchip,pmu described above instead
+
+Required properties for pin configuration node:
+ - rockchip,pins: 3 integers array, represents a group of pins mux and config
+ setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
+ The MUX 0 means gpio and MUX 1 to N mean the specific device function.
+ The phandle of a node containing the generic pinconfig options
+ to use, as described in pinctrl-bindings.txt in this directory.
+
+Examples:
+
+#include <dt-bindings/pinctrl/rockchip.h>
+
+...
+
+pinctrl@20008000 {
+ compatible = "rockchip,rk3066a-pinctrl";
+ rockchip,grf = <&grf>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio0: gpio0@20034000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x20034000 0x100>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_gates8 9>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ...
+
+ pcfg_pull_default: pcfg_pull_default {
+ bias-pull-pin-default
+ };
+
+ uart2 {
+ uart2_xfer: uart2-xfer {
+ rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>,
+ <RK_GPIO1 9 1 &pcfg_pull_default>;
+ };
+ };
+};
+
+uart2: serial@20064000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x20064000 0x400>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <1>;
+ clocks = <&mux_uart2>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_xfer>;
+};
+
+Example for rk3188:
+
+ pinctrl@20008000 {
+ compatible = "rockchip,rk3188-pinctrl";
+ rockchip,grf = <&grf>;
+ rockchip,pmu = <&pmu>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio0: gpio0@0x2000a000 {
+ compatible = "rockchip,rk3188-gpio-bank0";
+ reg = <0x2000a000 0x100>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_gates8 9>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio1@0x2003c000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x2003c000 0x100>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_gates8 10>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ...
+
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt
new file mode 100644
index 000000000..00169255e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pinctrl/st,stm32-pinctrl.txt
@@ -0,0 +1,208 @@
+* STM32 GPIO and Pin Mux/Config controller
+
+STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pins and
+also provides ability to multiplex and configure the output of various on-chip
+controllers onto these pads.
+
+Pin controller node:
+Required properies:
+ - compatible: value should be one of the following:
+ "st,stm32f429-pinctrl"
+ "st,stm32f469-pinctrl"
+ "st,stm32f746-pinctrl"
+ "st,stm32f769-pinctrl"
+ "st,stm32h743-pinctrl"
+ "st,stm32mp157-pinctrl"
+ "st,stm32mp157-z-pinctrl"
+ - #address-cells: The value of this property must be 1
+ - #size-cells : The value of this property must be 1
+ - ranges : defines mapping between pin controller node (parent) to
+ gpio-bank node (children).
+ - pins-are-numbered: Specify the subnodes are using numbered pinmux to
+ specify pins.
+
+GPIO controller/bank node:
+Required properties:
+ - gpio-controller : Indicates this device is a GPIO controller
+ - #gpio-cells : Should be two.
+ The first cell is the pin number
+ The second one is the polarity:
+ - 0 for active high
+ - 1 for active low
+ - reg : The gpio address range, relative to the pinctrl range
+ - clocks : clock that drives this bank
+ - st,bank-name : Should be a name string for this bank as specified in
+ the datasheet
+
+Optional properties:
+ - reset: : Reference to the reset controller
+ - st,syscfg: Should be phandle/offset/mask.
+ -The phandle to the syscon node which includes IRQ mux selection register.
+ -The offset of the IRQ mux selection register
+ -The field mask of IRQ mux, needed if different of 0xf.
+ - gpio-ranges: Define a dedicated mapping between a pin-controller and
+ a gpio controller. Format is <&phandle a b c> with:
+ -(phandle): phandle of pin-controller.
+ -(a): gpio base offset in range.
+ -(b): pin base offset in range.
+ -(c): gpio count in range
+ This entry has to be used either if there are holes inside a bank:
+ GPIOB0/B1/B2/B14/B15 (see example 2)
+ or if banks are not contiguous:
+ GPIOA/B/C/E...
+ NOTE: If "gpio-ranges" is used for a gpio controller, all gpio-controller
+ have to use a "gpio-ranges" entry.
+ More details in Documentation/devicetree/bindings/gpio/gpio.txt.
+ - st,bank-ioport: should correspond to the EXTI IOport selection (EXTI line
+ used to select GPIOs as interrupts).
+ - hwlocks: reference to a phandle of a hardware spinlock provider node.
+ - st,package: Indicates the SOC package used.
+ More details in include/dt-bindings/pinctrl/stm32-pinfunc.h
+
+Example 1:
+#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+...
+
+ pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,stm32f429-pinctrl";
+ ranges = <0 0x40020000 0x3000>;
+ pins-are-numbered;
+
+ gpioa: gpio@40020000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ resets = <&reset_ahb1 0>;
+ st,bank-name = "GPIOA";
+ };
+ ...
+ pin-functions nodes follow...
+ };
+
+Example 2:
+#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+...
+
+ pinctrl: pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,stm32f429-pinctrl";
+ ranges = <0 0x40020000 0x3000>;
+ pins-are-numbered;
+
+ gpioa: gpio@40020000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ resets = <&reset_ahb1 0>;
+ st,bank-name = "GPIOA";
+ gpio-ranges = <&pinctrl 0 0 16>;
+ };
+
+ gpiob: gpio@40020400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ resets = <&reset_ahb1 0>;
+ st,bank-name = "GPIOB";
+ ngpios = 4;
+ gpio-ranges = <&pinctrl 0 16 3>,
+ <&pinctrl 14 30 2>;
+ };
+
+
+ ...
+ pin-functions nodes follow...
+ };
+
+
+Contents of function subnode node:
+----------------------------------
+Subnode format
+A pinctrl node should contain at least one subnode representing the
+pinctrl group available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive, output high/low and output speed.
+
+ node {
+ pinmux = <PIN_NUMBER_PINMUX>;
+ GENERIC_PINCONFIG;
+ };
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are defined in
+ dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+ These defines are calculated as:
+ ((port * 16 + line) << 8) | function
+ With:
+ - port: The gpio port index (PA = 0, PB = 1, ..., PK = 11)
+ - line: The line offset within the port (PA0 = 0, PA1 = 1, ..., PA15 = 15)
+ - function: The function number, can be:
+ * 0 : GPIO
+ * 1 : Alternate Function 0
+ * 2 : Alternate Function 1
+ * 3 : Alternate Function 2
+ * ...
+ * 16 : Alternate Function 15
+ * 17 : Analog
+
+ To simplify the usage, macro is available to generate "pinmux" field.
+ This macro is available here:
+ - include/dt-bindings/pinctrl/stm32-pinfunc.h
+
+ Some examples of using macro:
+ /* GPIO A9 set as alernate function 2 */
+ ... {
+ pinmux = <STM32_PINMUX('A', 9, AF2)>;
+ };
+ /* GPIO A9 set as GPIO */
+ ... {
+ pinmux = <STM32_PINMUX('A', 9, GPIO)>;
+ };
+ /* GPIO A9 set as analog */
+ ... {
+ pinmux = <STM32_PINMUX('A', 9, ANALOG)>;
+ };
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use.
+ Available options are:
+ - bias-disable,
+ - bias-pull-down,
+ - bias-pull-up,
+ - drive-push-pull,
+ - drive-open-drain,
+ - output-low
+ - output-high
+ - slew-rate = <x>, with x being:
+ < 0 > : Low speed
+ < 1 > : Medium speed
+ < 2 > : Fast speed
+ < 3 > : High speed
+
+Example:
+
+pin-controller {
+...
+ usart1_pins_a: usart1@0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('A', 9, AF7)>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('A', 10, AF7)>;
+ bias-disable;
+ };
+ };
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pmic/max77686.txt b/roms/u-boot/doc/device-tree-bindings/pmic/max77686.txt
new file mode 100644
index 000000000..09aee647a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pmic/max77686.txt
@@ -0,0 +1,35 @@
+MAXIM, MAX77686 pmic
+
+This device uses two drivers:
+- drivers/power/pmic/max77686.c (for parent device)
+- drivers/power/regulator/max77686.c (for child regulators)
+
+This file describes the binding info for the PMIC driver.
+
+To bind the regulators, please read the additional binding info:
+- doc/device-tree-bindings/regulator/max77686.txt
+
+Required properties:
+- compatible: "maxim,max77686"
+- reg = 0x9
+
+With those two properties, the pmic device can be used for read/write only.
+To bind each regulator, the optional regulators subnode should exists.
+
+Optional subnode:
+- voltage-regulators: subnode list of each device's regulator
+ (see max77686.txt - regulator binding info)
+
+Example:
+
+max77686@09 {
+ compatible = "maxim,max77686";
+ reg = <0x09>;
+
+ voltage-regulators {
+ ldo1 {
+ ...
+ };
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pmic/pm8916.txt b/roms/u-boot/doc/device-tree-bindings/pmic/pm8916.txt
new file mode 100644
index 000000000..15c598b8c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pmic/pm8916.txt
@@ -0,0 +1,18 @@
+Qualcomm pm8916 PMIC
+
+This PMIC is connected using SPMI bus so should be child of SPMI bus controller.
+
+Required properties:
+- compatible: "qcom,spmi-pmic";
+- reg: SPMI Slave ID, size (ignored)
+- #address-cells: 0x1 (peripheral ID)
+- #size-cells: 0x1 (size of peripheral register space)
+
+Example:
+
+pm8916@0 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x0 0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pmic/rn5t567.txt b/roms/u-boot/doc/device-tree-bindings/pmic/rn5t567.txt
new file mode 100644
index 000000000..e9e688537
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pmic/rn5t567.txt
@@ -0,0 +1,17 @@
+Ricoh RN5T567 PMIC
+
+This file describes the binding info for the PMIC driver.
+
+Required properties:
+- compatible: "ricoh,rn5t567"
+- reg: depending on strapping, e.g. 0x33
+
+With those two properties, the PMIC device can be used to read/write
+registers.
+
+Example:
+
+rn5t567@33 {
+ compatible = "ricoh,rn5t567";
+ reg = <0x33>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pmic/s2mps11.txt b/roms/u-boot/doc/device-tree-bindings/pmic/s2mps11.txt
new file mode 100644
index 000000000..422f14f13
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pmic/s2mps11.txt
@@ -0,0 +1,17 @@
+SAMSUNG, S2MPS11 PMIC
+
+This file describes the binding info for the PMIC driver:
+- drivers/power/pmic/s2mps11.c
+
+Required properties:
+- compatible: "samsung,s2mps11-pmic"
+- reg = 0x66
+
+With those two properties, the pmic device can be used for read/write only.
+
+Example:
+
+s2mps11@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg = <0x66>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pmic/sandbox.txt b/roms/u-boot/doc/device-tree-bindings/pmic/sandbox.txt
new file mode 100644
index 000000000..d84c97717
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pmic/sandbox.txt
@@ -0,0 +1,35 @@
+Sandbox pmic
+
+This device uses two drivers:
+- drivers/power/pmic/sandbox.c (for parent device)
+- drivers/power/regulator/sandbox.c (for child regulators)
+
+This file describes the binding info for the PMIC driver.
+
+To bind the regulators, please read the regulator binding info:
+- doc/device-tree-bindings/regulator/sandbox.txt
+
+Required PMIC node properties:
+- compatible: "sandbox,pmic"
+- reg = 0x40
+
+Required PMIC's "emul" subnode, with property:
+- compatible: "sandbox,i2c-pmic"
+
+With the above properties, the pmic device can be used for read/write only.
+To bind each regulator, the optional regulator subnodes should exists.
+
+Optional subnodes:
+- ldo/buck subnodes of each device's regulator (see regulator binding info)
+
+Example:
+
+sandbox_pmic {
+ compatible = "sandbox,pmic";
+ reg = <0x40>;
+
+ /* Mandatory for I/O */
+ emul {
+ compatible = "sandbox,i2c-pmic";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/power/ti,sci-pm-domain.txt b/roms/u-boot/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
new file mode 100644
index 000000000..72d9fbc83
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/power/ti,sci-pm-domain.txt
@@ -0,0 +1,59 @@
+Texas Instruments TI SCI Generic Power Domain
+=============================================
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the SYSFW. Because
+this relies on the TI SCI protocol to communicate with the SYSFW it must be a
+child of the sysfw node.
+
+Required Properties:
+--------------------
+- compatible: Must be "ti,sci-pm-domain"
+- #power-domain-cells: Can be one of the following:
+ 1: Containing the device id of each node
+ 2: First entry should be device id
+ Second entry should be one of the floowing:
+ TI_SCI_PD_EXCLUSIVE: To allow device to be
+ exclusively controlled by
+ the requesting hosts.
+ TI_SCI_PD_SHARED: To allow device to be shared
+ by multiple hosts.
+
+Example (AM65x):
+----------------
+ sysfw: sysfw {
+ compatible = "ti,am654-system-controller";
+ ...
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <1>;
+ };
+ };
+
+PM Domain Consumers
+===================
+Hardware blocks belonging to a PM domain should contain a "power-domains"
+property that is a phandle pointing to the corresponding PM domain node
+along with an index representing the device id to be passed to the PMMC
+for device control.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node
+ and an ID representing the device.
+
+Example (AM65x):
+----------------
+ uart2: serial@02800000 {
+ compatible = "ti,omap4-uart";
+ ...
+ power-domains = <&k3_pds 0x3f>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/power/tps65090.txt b/roms/u-boot/doc/device-tree-bindings/power/tps65090.txt
new file mode 100644
index 000000000..8e5e0d391
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/power/tps65090.txt
@@ -0,0 +1,17 @@
+TPS65090 Frontend PMU with Switchmode Charger
+
+Required Properties:
+-compatible: "ti,tps65090-charger"
+
+Optional Properties:
+-ti,enable-low-current-chrg: Enables charging when a low current is detected
+ while the default logic is to stop charging.
+
+This node is a subnode of the tps65090 PMIC.
+
+Example:
+
+ tps65090-charger {
+ compatible = "ti,tps65090-charger";
+ ti,enable-low-current-chrg;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pwm/cros-ec-pwm.txt b/roms/u-boot/doc/device-tree-bindings/pwm/cros-ec-pwm.txt
new file mode 100644
index 000000000..f198d0889
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pwm/cros-ec-pwm.txt
@@ -0,0 +1,23 @@
+PWM controlled by ChromeOS EC
+
+Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
+(EC) and controlled via a host-command interface.
+
+An EC PWM node should be only found as a sub-node of the EC node (see
+doc/device-tree-bindings/misc/cros-ec.txt).
+
+Required properties:
+- compatible: Must contain "google,cros-ec-pwm"
+- #pwm-cells: Should be 1. The cell specifies the PWM index.
+
+Example:
+ cros-ec@0 {
+ compatible = "google,cros-ec-spi";
+
+ ...
+
+ cros_ec_pwm: ec-pwm {
+ compatible = "google,cros-ec-pwm";
+ #pwm-cells = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pwm/pwm-sifive.txt b/roms/u-boot/doc/device-tree-bindings/pwm/pwm-sifive.txt
new file mode 100644
index 000000000..9a988372c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pwm/pwm-sifive.txt
@@ -0,0 +1,31 @@
+SiFive PWM controller
+
+Unlike most other PWM controllers, the SiFive PWM controller currently only
+supports one period for all channels in the PWM. All PWMs need to run at
+the same period. The period also has significant restrictions on the values
+it can achieve, which the driver rounds to the nearest achievable period.
+PWM RTL that corresponds to the IP block version numbers can be found
+here:
+
+https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
+
+Required properties:
+- compatible: Should be "sifive,<chip>-pwm" and "sifive,pwm<version>".
+ Supported compatible strings are: "sifive,fu540-c000-pwm" for the SiFive
+ PWM v0 as integrated onto the SiFive FU540 chip, and "sifive,pwm0" for the
+ SiFive PWM v0 IP block with no chip integration tweaks.
+- reg: physical base address and length of the controller's registers
+- clocks: Should contain a clock identifier for the PWM's parent clock.
+- #pwm-cells: Should be 3.
+- interrupts: one interrupt per PWM channel
+
+Examples:
+
+pwm: pwm@10020000 {
+ compatible = "sifive,fu540-c000-pwm", "sifive,pwm0";
+ reg = <0x0 0x10020000 0x0 0x1000>;
+ clocks = <&tlclk>;
+ interrupt-parent = <&plic>;
+ interrupts = <42 43 44 45>;
+ #pwm-cells = <3>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/pwm/pwm.txt b/roms/u-boot/doc/device-tree-bindings/pwm/pwm.txt
new file mode 100644
index 000000000..8556263b8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pwm/pwm.txt
@@ -0,0 +1,69 @@
+Specifying PWM information for devices
+======================================
+
+1) PWM user nodes
+-----------------
+
+PWM users should specify a list of PWM devices that they want to use
+with a property containing a 'pwm-list':
+
+ pwm-list ::= <single-pwm> [pwm-list]
+ single-pwm ::= <pwm-phandle> <pwm-specifier>
+ pwm-phandle : phandle to PWM controller node
+ pwm-specifier : array of #pwm-cells specifying the given PWM
+ (controller specific)
+
+PWM properties should be named "pwms". The exact meaning of each pwms
+property must be documented in the device tree binding for each device.
+An optional property "pwm-names" may contain a list of strings to label
+each of the PWM devices listed in the "pwms" property. If no "pwm-names"
+property is given, the name of the user node will be used as fallback.
+
+Drivers for devices that use more than a single PWM device can use the
+"pwm-names" property to map the name of the PWM device requested by the
+pwm_get() call to an index into the list given by the "pwms" property.
+
+The following example could be used to describe a PWM-based backlight
+device:
+
+ pwm: pwm {
+ #pwm-cells = <2>;
+ };
+
+ [...]
+
+ bl: backlight {
+ pwms = <&pwm 0 5000000>;
+ pwm-names = "backlight";
+ };
+
+Note that in the example above, specifying the "pwm-names" is redundant
+because the name "backlight" would be used as fallback anyway.
+
+pwm-specifier typically encodes the chip-relative PWM number and the PWM
+period in nanoseconds.
+
+Optionally, the pwm-specifier can encode a number of flags (defined in
+<dt-bindings/pwm/pwm.h>) in a third cell:
+- PWM_POLARITY_INVERTED: invert the PWM signal polarity
+
+Example with optional PWM specifier for inverse polarity
+
+ bl: backlight {
+ pwms = <&pwm 0 5000000 PWM_POLARITY_INVERTED>;
+ pwm-names = "backlight";
+ };
+
+2) PWM controller nodes
+-----------------------
+
+PWM controller nodes must specify the number of cells used for the
+specifier using the '#pwm-cells' property.
+
+An example PWM controller might look like this:
+
+ pwm: pwm@7000a000 {
+ compatible = "nvidia,tegra20-pwm";
+ reg = <0x7000a000 0x100>;
+ #pwm-cells = <2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt b/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt
new file mode 100644
index 000000000..01438ecd6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt
@@ -0,0 +1,18 @@
+Tegra SoC PWFM controller
+
+Required properties:
+- compatible: should be one of:
+ - "nvidia,tegra20-pwm"
+ - "nvidia,tegra30-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
+ first cell specifies the per-chip index of the PWM to use and the second
+ cell is the period in nanoseconds.
+
+Example:
+
+ pwm: pwm@7000a000 {
+ compatible = "nvidia,tegra20-pwm";
+ reg = <0x7000a000 0x100>;
+ #pwm-cells = <2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/ram/fsl,mpc83xx-mem-controller.txt b/roms/u-boot/doc/device-tree-bindings/ram/fsl,mpc83xx-mem-controller.txt
new file mode 100644
index 000000000..da01fe908
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/ram/fsl,mpc83xx-mem-controller.txt
@@ -0,0 +1,314 @@
+MPC83xx RAM controller
+
+This driver supplies support for the embedded RAM controller on MCP83xx-series
+SoCs.
+
+For static configuration mode, each controller node should have child nodes
+describing the actual RAM modules installed.
+
+Controller node
+===============
+
+Required properties:
+- compatible: Must be "fsl,mpc83xx-mem-controller"
+- reg: The address of the RAM controller's register space
+- #address-cells: Must be 2
+- #size-cells: Must be 1
+- driver_software_override: DDR driver software override is enabled (1) or
+ disabled (0)
+- p_impedance_override: DDR driver software p-impedance override; possible
+ values:
+ * DSO_P_IMPEDANCE_HIGHEST_Z
+ * DSO_P_IMPEDANCE_MUCH_HIGHER_Z
+ * DSO_P_IMPEDANCE_HIGHER_Z
+ * DSO_P_IMPEDANCE_NOMINAL
+ * DSO_P_IMPEDANCE_LOWER_Z
+- n_impedance_override: DDR driver software n-impedance override; possible
+ values:
+ * DSO_N_IMPEDANCE_HIGHEST_Z
+ * DSO_N_IMPEDANCE_MUCH_HIGHER_Z
+ * DSO_N_IMPEDANCE_HIGHER_Z
+ * DSO_N_IMPEDANCE_NOMINAL
+ * DSO_N_IMPEDANCE_LOWER_Z
+- odt_termination_value: ODT termination value for I/Os; possible values:
+ * ODT_TERMINATION_75_OHM
+ * ODT_TERMINATION_150_OHM
+- ddr_type: Selects voltage level for DDR pads; possible
+ values:
+ * DDR_TYPE_DDR2_1_8_VOLT
+ * DDR_TYPE_DDR1_2_5_VOLT
+- mvref_sel: Determine where MVREF_SEL signal is generated;
+ possible values:
+ * MVREF_SEL_EXTERNAL
+ * MVREF_SEL_INTERNAL_GVDD
+- m_odr: Disable memory transaction reordering; possible
+ values:
+ * M_ODR_ENABLE
+ * M_ODR_DISABLE
+- clock_adjust: Clock adjust; possible values:
+ * CLOCK_ADJUST_025
+ * CLOCK_ADJUST_05
+ * CLOCK_ADJUST_075
+ * CLOCK_ADJUST_1
+- ext_refresh_rec: Extended refresh recovery time; possible values:
+ 0, 16, 32, 48, 64, 80, 96, 112
+- read_to_write: Read-to-write turnaround; possible values:
+ 0, 1, 2, 3
+- write_to_read: Write-to-read turnaround; possible values:
+ 0, 1, 2, 3
+- read_to_read: Read-to-read turnaround; possible values:
+ 0, 1, 2, 3
+- write_to_write: Write-to-write turnaround; possible values:
+ 0, 1, 2, 3
+- active_powerdown_exit: Active powerdown exit timing; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- precharge_powerdown_exit: Precharge powerdown exit timing; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- odt_powerdown_exit: ODT powerdown exit timing; possible values:
+ 0, 1, 2, 3, 4, 5, 6, 7, 8,
+ 9, 10, 11, 12, 13, 14, 15
+- mode_reg_set_cycle: Mode register set cycle time; possible values:
+ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
+- precharge_to_activate: Precharge-to-acitvate interval; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- activate_to_precharge: Activate to precharge interval; possible values:
+ 4, 5, 6, 7, 8, 9, 10, 11, 12,
+ 13, 14, 15, 16, 17, 18, 19
+- activate_to_readwrite: Activate to read/write interval for SDRAM;
+ possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- mcas_latency: MCAS latency from READ command; possible values:
+ * CASLAT_20
+ * CASLAT_25
+ * CASLAT_30
+ * CASLAT_35
+ * CASLAT_40
+ * CASLAT_45
+ * CASLAT_50
+ * CASLAT_55
+ * CASLAT_60
+ * CASLAT_65
+ * CASLAT_70
+ * CASLAT_75
+ * CASLAT_80
+- refresh_recovery: Refresh recovery time; possible values:
+ 8, 9, 10, 11, 12, 13, 14, 15,
+ 16, 17, 18, 19, 20, 21, 22, 23
+- last_data_to_precharge: Last data to precharge minimum interval; possible
+ values:
+ 1, 2, 3, 4, 5, 6, 7
+- activate_to_activate: Activate-to-activate interval; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- last_write_data_to_read: Last write data pair to read command issue
+ interval; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- additive_latency: Additive latency; possible values:
+ 0, 1, 2, 3, 4, 5
+- mcas_to_preamble_override: MCAS-to-preamble-override; possible values:
+ * READ_LAT
+ * READ_LAT_PLUS_1_4
+ * READ_LAT_PLUS_1_2
+ * READ_LAT_PLUS_3_4
+ * READ_LAT_PLUS_1
+ * READ_LAT_PLUS_5_4
+ * READ_LAT_PLUS_3_2
+ * READ_LAT_PLUS_7_4
+ * READ_LAT_PLUS_2
+ * READ_LAT_PLUS_9_4
+ * READ_LAT_PLUS_5_2
+ * READ_LAT_PLUS_11_4
+ * READ_LAT_PLUS_3
+ * READ_LAT_PLUS_13_4
+ * READ_LAT_PLUS_7_2
+ * READ_LAT_PLUS_15_4
+ * READ_LAT_PLUS_4
+ * READ_LAT_PLUS_17_4
+ * READ_LAT_PLUS_9_2
+ * READ_LAT_PLUS_19_4
+- write_latency: Write latency; possible values:
+ 1, 2, 3, 4, 5, 6, 7
+- read_to_precharge: Read to precharge; possible values:
+ 1, 2, 3, 4
+- write_cmd_to_write_data: Write command to write data strobe timing
+ adjustment; possible values:
+ * CLOCK_DELAY_0
+ * CLOCK_DELAY_1_4
+ * CLOCK_DELAY_1_2
+ * CLOCK_DELAY_3_4
+ * CLOCK_DELAY_1
+ * CLOCK_DELAY_5_4
+ * CLOCK_DELAY_3_2
+- minimum_cke_pulse_width: Minimum CKE pulse width; possible values:
+ 1, 2, 3, 4
+- four_activates_window: Window for four activates; possible values:
+ 1, 2, 3, 4 8, 9, 10, 11, 12,
+ 13, 14, 15, 16, 17, 18, 19
+- self_refresh: Self refresh (during sleep); possible values:
+ * SREN_DISABLE
+ * SREN_ENABLE
+- ecc: Support for ECC; possible values:
+ * ECC_DISABLE
+ * ECC_ENABLE
+- registered_dram: Support for registered DRAM; possible values:
+ * RD_DISABLE
+ * RD_ENABLE
+- sdram_type: Type of SDRAM device to be used; possible values:
+ * TYPE_DDR1
+ * TYPE_DDR2
+- dynamic_power_management: Dynamic power management mode; possible values:
+ * DYN_PWR_DISABLE
+ * DYN_PWR_ENABLE
+- databus_width: DRAM data bus width; possible values
+ * DATA_BUS_WIDTH_16
+ * DATA_BUS_WIDTH_32
+- nc_auto_precharge: Non-concurrent auto-precharge; possible values:
+ * NCAP_DISABLE
+ * NCAP_ENABLE
+- timing_2t: 2T timing; possible values:
+ * TIMING_1T
+ * TIMING_2T
+- bank_interleaving_ctrl: Bank (chip select) interleaving control; possible
+ values:
+ * INTERLEAVE_NONE
+ * INTERLEAVE_1_AND_2
+- precharge_bit_8: Precharge bin 8; possible values
+ * PRECHARGE_MA_10
+ * PRECHARGE_MA_8
+- half_strength: Global half-strength override; possible values:
+ * STRENGTH_FULL
+ * STRENGTH_HALF
+- bypass_initialization: Bypass initialization; possible values:
+ * INITIALIZATION_DONT_BYPASS
+ * INITIALIZATION_BYPASS
+- force_self_refresh: Force self refresh; possible values:
+ * MODE_NORMAL
+ * MODE_REFRESH
+- dll_reset: DLL reset; possible values:
+ * DLL_RESET_ENABLE
+ * DLL_RESET_DISABLE
+- dqs_config: DQS configuration; possible values:
+ * DQS_TRUE
+- odt_config: ODT configuration; possible values:
+ * ODT_ASSERT_NEVER
+ * ODT_ASSERT_WRITES
+ * ODT_ASSERT_READS
+ * ODT_ASSERT_ALWAYS
+- posted_refreshes: Number of posted refreshes
+ 1, 2, 3, 4, 5, 6, 7, 8
+- sdmode: Initial value loaded into the DDR SDRAM mode
+ register
+- esdmode: Initial value loaded into the DDR SDRAM extended
+ mode register
+- esdmode2: Initial value loaded into the DDR SDRAM extended
+ mode 2 register
+- esdmode3: Initial value loaded into the DDR SDRAM extended
+ mode 3 register
+- refresh_interval: Refresh interval; possible values:
+ 0 - 65535
+- precharge_interval: Precharge interval; possible values:
+ 0 - 16383
+
+RAM module node:
+================
+
+Required properties:
+- reg: A triple <cs addr size>, which consists of:
+ * cs - the chipselect used to drive this RAM module
+ * addr - the address where this RAM module's memory is map
+ to in the global memory space
+ * size - the size of the RAM module's memory in bytes
+- auto_precharge: Chip select auto-precharge; possible values:
+ * AUTO_PRECHARGE_ENABLE
+ * AUTO_PRECHARGE_DISABLE
+- odt_rd_cfg: ODT for reads configuration; possible values:
+ * ODT_RD_NEVER
+ * ODT_RD_ONLY_CURRENT
+ * ODT_RD_ONLY_OTHER_CS
+ * ODT_RD_ONLY_OTHER_DIMM
+ * ODT_RD_ALL
+- odt_wr_cfg: ODT for writes configuration; possible values:
+ * ODT_WR_NEVER
+ * ODT_WR_ONLY_CURRENT
+ * ODT_WR_ONLY_OTHER_CS
+ * ODT_WR_ONLY_OTHER_DIMM
+ * ODT_WR_ALL
+- bank_bits: Number of bank bits for SDRAM on chip select; possible
+ values:
+ 2, 3
+- row_bits: Number of row bits for SDRAM on chip select; possible values:
+ 12, 13, 14
+- col_bits: Number of column bits for SDRAM on chip select; possible
+ values:
+ 8, 9, 10, 11
+
+Example:
+
+memory@2000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc83xx-mem-controller";
+ reg = <0x2000 0x1000>;
+ device_type = "memory";
+ u-boot,dm-pre-reloc;
+
+ driver_software_override = <DSO_ENABLE>;
+ p_impedance_override = <DSO_P_IMPEDANCE_NOMINAL>;
+ n_impedance_override = <DSO_N_IMPEDANCE_NOMINAL>;
+ odt_termination_value = <ODT_TERMINATION_150_OHM>;
+ ddr_type = <DDR_TYPE_DDR2_1_8_VOLT>;
+
+ clock_adjust = <CLOCK_ADJUST_05>;
+
+ read_to_write = <0>;
+ write_to_read = <0>;
+ read_to_read = <0>;
+ write_to_write = <0>;
+ active_powerdown_exit = <2>;
+ precharge_powerdown_exit = <6>;
+ odt_powerdown_exit = <8>;
+ mode_reg_set_cycle = <2>;
+
+ precharge_to_activate = <2>;
+ activate_to_precharge = <6>;
+ activate_to_readwrite = <2>;
+ mcas_latency = <CASLAT_40>;
+ refresh_recovery = <17>;
+ last_data_to_precharge = <2>;
+ activate_to_activate = <2>;
+ last_write_data_to_read = <2>;
+
+ additive_latency = <0>;
+ mcas_to_preamble_override = <READ_LAT_PLUS_1_2>;
+ write_latency = <3>;
+ read_to_precharge = <2>;
+ write_cmd_to_write_data = <CLOCK_DELAY_1_2>;
+ minimum_cke_pulse_width = <3>;
+ four_activates_window = <5>;
+
+ self_refresh = <SREN_ENABLE>;
+ sdram_type = <TYPE_DDR2>;
+ databus_width = <DATA_BUS_WIDTH_32>;
+
+ force_self_refresh = <MODE_NORMAL>;
+ dll_reset = <DLL_RESET_ENABLE>;
+ dqs_config = <DQS_TRUE>;
+ odt_config = <ODT_ASSERT_READS>;
+ posted_refreshes = <1>;
+
+ refresh_interval = <2084>;
+ precharge_interval = <256>;
+
+ sdmode = <0x0242>;
+ esdmode = <0x0440>;
+
+ ram@0 {
+ reg = <0x0 0x0 0x8000000>;
+ compatible = "nanya,nt5tu64m16hg";
+
+ odt_rd_cfg = <ODT_RD_NEVER>;
+ odt_wr_cfg = <ODT_WR_ONLY_CURRENT>;
+ bank_bits = <3>;
+ row_bits = <13>;
+ col_bits = <10>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/fan53555.txt b/roms/u-boot/doc/device-tree-bindings/regulator/fan53555.txt
new file mode 100644
index 000000000..b183738d6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/fan53555.txt
@@ -0,0 +1,23 @@
+Binding for Fairchild FAN53555 regulators
+
+Required properties:
+ - compatible: "fcs,fan53555"
+ - reg: I2C address
+
+Optional properties:
+ - fcs,suspend-voltage-selector: declare which of the two available
+ voltage selector registers should be used for the suspend
+ voltage. The other one is used for the runtime voltage setting
+ Possible values are either <0> or <1>
+ - vin-supply: regulator supplying the vin pin
+
+Example:
+
+ regulator@40 {
+ compatible = "fcs,fan53555";
+ regulator-name = "fan53555";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&parent_reg>;
+ fcs,suspend-voltage-selector = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/fixed.txt b/roms/u-boot/doc/device-tree-bindings/regulator/fixed.txt
new file mode 100644
index 000000000..453d2bef4
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/fixed.txt
@@ -0,0 +1,44 @@
+Fixed Voltage regulator
+
+Binding:
+The binding is done by the property "compatible" - this is different, than for
+binding by the node prefix (doc/device-tree-bindings/regulator/regulator.txt).
+
+Required properties:
+- compatible: "regulator-fixed"
+- regulator-name: this is required by the regulator uclass
+
+Optional properties:
+- gpio: GPIO to use for enable control
+- startup-delay-us: startup time in microseconds
+- u-boot,off-on-delay-us: off delay time in microseconds
+- regulator constraints (binding info: regulator.txt)
+- enable-active-high: Polarity of GPIO is Active high. If this property
+ is missing, the default assumed is Active low.
+
+
+Other kernel-style properties, are currently not used.
+
+Note:
+For the regulator constraints, driver expects that:
+- regulator-min-microvolt is equal to regulator-max-microvolt
+- regulator-min-microamp is equal to regulator-max-microamp
+
+Example:
+fixed_regulator@0 {
+ /* Mandatory */
+ compatible = "regulator-fixed";
+ regulator-name = "LED_3.3V";
+
+ /* Optional: */
+ gpio = <&gpc1 0 GPIO_ACTIVE_LOW>;
+
+ /* Optional for regulator uclass */
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microamp = <15000>;
+ regulator-max-microamp = <15000>;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt b/roms/u-boot/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt
new file mode 100644
index 000000000..2a60e4941
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt
@@ -0,0 +1,45 @@
+ANATOP REGULATOR
+
+Anatop is an integrated regulator inside i.MX6 SoC.
+
+Required properties:
+- compatible: Must be "fsl,anatop-regulator".
+- regulator-name: Name of the regulator
+- anatop-reg-offset: u32 value representing the anatop MFD register offset.
+- anatop-vol-bit-shift: u32 value representing the bit shift for the register.
+- anatop-vol-bit-width: u32 value representing the number of bits used in the
+ register.
+- anatop-min-bit-val: u32 value representing the minimum value of this
+ register.
+- anatop-min-voltage: u32 value representing the minimum voltage of this
+ regulator.
+- anatop-max-voltage: u32 value representing the maximum voltage of this
+ regulator.
+
+Optional properties:
+- anatop-delay-reg-offset: u32 value representing the anatop MFD step time
+ register offset.
+- anatop-delay-bit-shift: u32 value representing the bit shift for the step
+ time register.
+- anatop-delay-bit-width: u32 value representing the number of bits used in
+ the step time register.
+- anatop-enable-bit: u32 value representing regulator enable bit offset.
+- vin-supply: input supply phandle.
+
+Example:
+ regulator-vddpu {
+ compatible = "fsl,anatop-regulator";
+ regulator-name = "vddpu";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ anatop-reg-offset = <0x140>;
+ anatop-vol-bit-shift = <9>;
+ anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
+ anatop-min-bit-val = <1>;
+ anatop-min-voltage = <725000>;
+ anatop-max-voltage = <1300000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/max77686.txt b/roms/u-boot/doc/device-tree-bindings/regulator/max77686.txt
new file mode 100644
index 000000000..ae9b1b6e6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/max77686.txt
@@ -0,0 +1,70 @@
+MAXIM, MAX77686 regulators
+
+This device uses two drivers:
+- drivers/power/pmic/max77686.c (as parent I/O device)
+- drivers/power/regulator/max77686.c (for child regulators)
+
+This file describes the binding info for the REGULATOR driver.
+
+First, please read the binding info for the pmic:
+- doc/device-tree-bindings/pmic/max77686.txt
+
+Required subnode:
+- voltage-regulators: required for the PMIC driver
+
+Required properties:
+- regulator-name: used for regulator uclass platform data '.name'
+
+Optional:
+- regulator-min-microvolt: minimum allowed Voltage to set
+- regulator-max-microvolt: minimum allowed Voltage to set
+- regulator-always-on: regulator should be never disabled
+- regulator-boot-on: regulator should be enabled by the bootloader
+
+Example:
+(subnode of max77686 pmic node)
+voltage-regulators {
+ ldo1 {
+ regulator-name = "VDD_ALIVE_1.0V";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2 {
+ regulator-name = "VDDQ_VM1M2_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ .
+ .
+ .
+ ldo26 {
+ regulator-name = "nc";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck1 {
+ regulator-compatible = "BUCK1";
+ regulator-name = "VDD_MIF_1.0V";
+ regulator-min-microvolt = <8500000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ .
+ .
+ .
+ buck9 {
+ regulator-compatible = "BUCK9";
+ regulator-name = "nc";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/regulator.txt b/roms/u-boot/doc/device-tree-bindings/regulator/regulator.txt
new file mode 100644
index 000000000..6c9a02120
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/regulator.txt
@@ -0,0 +1,92 @@
+Voltage/Current regulator
+
+Binding:
+The regulator devices don't use the "compatible" property. The binding is done
+by the prefix of regulator node's name, or, if this fails, by the prefix of the
+regulator's "regulator-name" property. Usually the pmic I/O driver will provide
+the array of 'struct pmic_child_info' with the prefixes and compatible drivers.
+The bind is done by calling function: pmic_bind_childs().
+Example drivers:
+pmic: drivers/power/pmic/max77686.c
+regulator: drivers/power/regulator/max77686.c
+
+For the node name e.g.: "prefix[:alpha:]num { ... }":
+- the driver prefix should be: "prefix" - case sensitive
+- the node name's "num" is set as "dev->driver_data" on bind
+
+Example the prefix "ldo" will pass for: "ldo1", "ldo@1", "ldoreg@1, ...
+
+Binding by means of the node's name is preferred. However if the node names
+would produce ambiguous prefixes (like "regulator@1" and "regualtor@11") and you
+can't or do not want to change them then binding against the "regulator-name"
+property is possible. The syntax for the prefix of the "regulator-name" property
+is the same as the one for the regulator's node name.
+Use case: a regulator named "regulator@1" to be bound to a driver named
+"LDO_DRV" and a regulator named "regualator@11" to be bound to an other driver
+named "BOOST_DRV". Using prefix "regualtor@1" for driver matching would load
+the same driver for both regulators, hence the prefix is ambiguous.
+
+Optional properties:
+- regulator-name: a string, required by the regulator uclass, used for driver
+ binding if binding by node's name prefix fails
+- regulator-min-microvolt: a minimum allowed Voltage value
+- regulator-max-microvolt: a maximum allowed Voltage value
+- regulator-min-microamp: a minimum allowed Current value
+- regulator-max-microamp: a maximum allowed Current value
+- regulator-always-on: regulator should never be disabled
+- regulator-boot-on: enabled by bootloader/firmware
+- regulator-ramp-delay: ramp delay for regulator (in uV/us)
+- regulator-init-microvolt: a init allowed Voltage value
+- regulator-state-(standby|mem|disk)
+ type: object
+ description:
+ sub-nodes for regulator state in Standby, Suspend-to-RAM, and
+ Suspend-to-DISK modes. Equivalent with standby, mem, and disk Linux
+ sleep states.
+
+ properties:
+ regulator-on-in-suspend:
+ description: regulator should be on in suspend state.
+ type: boolean
+
+ regulator-off-in-suspend:
+ description: regulator should be off in suspend state.
+ type: boolean
+
+ regulator-suspend-microvolt:
+ description: the default voltage which regulator would be set in
+ suspend. This property is now deprecated, instead setting voltage
+ for suspend mode via the API which regulator driver provides is
+ recommended.
+
+Note
+The "regulator-name" constraint is used for setting the device's uclass
+platform data '.name' field. And the regulator device name is set from
+it's node name. If "regulator-name" is not provided in dts, node name
+is chosen for setting the device's uclass platform data '.name' field.
+
+Other kernel-style properties, are currently not used.
+
+Note:
+For the regulator autoset from constraints, the framework expects that:
+- regulator-min-microvolt is equal to regulator-max-microvolt
+- regulator-min-microamp is equal to regulator-max-microamp
+- regulator-always-on or regulator-boot-on is set
+
+Example:
+ldo0 {
+ /* Optional */
+ regulator-name = "VDDQ_EMMC_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microamp = <100000>;
+ regulator-max-microamp = <100000>;
+ regulator-init-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-ramp-delay = <12000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/sandbox.txt b/roms/u-boot/doc/device-tree-bindings/regulator/sandbox.txt
new file mode 100644
index 000000000..d70494c45
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/sandbox.txt
@@ -0,0 +1,45 @@
+Sandbox, PMIC regulators
+
+This device uses two drivers:
+- drivers/power/pmic/sandbox.c (as parent I/O device)
+- drivers/power/regulator/sandbox.c (for child regulators)
+
+This file describes the binding info for the REGULATOR driver.
+
+First, please read the binding info for the PMIC:
+- doc/device-tree-bindings/pmic/sandbox.txt
+
+Required subnodes:
+- ldoN { };
+- buckN { };
+
+The sandbox PMIC can support: ldo1, ldo2, buck1, buck2.
+
+For each PMIC's regulator subnode, there is one required property:
+- regulator-name: used for regulator uclass platform data '.name'
+
+Optional:
+- regulator-min-microvolt: minimum allowed Voltage to set
+- regulator-max-microvolt: minimum allowed Voltage to set
+- regulator-min-microamps: minimum allowed Current limit to set (LDO1/BUCK1)
+- regulator-max-microamps: minimum allowed Current limit to set (LDO1/BUCK1)
+- regulator-always-on: regulator should be never disabled
+- regulator-boot-on: regulator should be enabled by the bootloader
+
+Example PMIC's regulator subnodes:
+
+ldo1 {
+ regulator-name = "VDD_1.0V";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microamps = <100000>;
+ regulator-max-microamps = <400000>;
+ regulator-always-on;
+};
+
+buck2 {
+ regulator-name = "VDD_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/st,stm32-vrefbuf.txt b/roms/u-boot/doc/device-tree-bindings/regulator/st,stm32-vrefbuf.txt
new file mode 100644
index 000000000..0f6b6feda
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/st,stm32-vrefbuf.txt
@@ -0,0 +1,23 @@
+STM32 VREFBUF - Voltage reference buffer
+
+Some STM32 devices embed a voltage reference buffer which can be used as
+voltage reference for ADCs, DACs and also as voltage reference for external
+components through the dedicated VREF+ pin.
+
+Required properties:
+- compatible: Must be "st,stm32-vrefbuf".
+- reg: Offset and length of VREFBUF register set.
+- clocks: Must contain an entry for peripheral clock.
+
+Optional properties:
+- vdda-supply: Phandle to the parent vdda supply regulator node.
+
+Example:
+ vrefbuf: regulator@58003c00 {
+ compatible = "st,stm32-vrefbuf";
+ reg = <0x58003C00 0x8>;
+ clocks = <&rcc VREF_CK>;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2500000>;
+ vdda-supply = <&vdda>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/regulator/tps65090.txt b/roms/u-boot/doc/device-tree-bindings/regulator/tps65090.txt
new file mode 100644
index 000000000..313a60ba6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/regulator/tps65090.txt
@@ -0,0 +1,122 @@
+TPS65090 regulators
+
+Required properties:
+- compatible: "ti,tps65090"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+ device. Each sub-node is identified using the node's name, with valid
+ values listed below. The content of each sub-node is defined by the
+ standard binding for regulators; see regulator.txt.
+ dcdc[1-3], fet[1-7] and ldo[1-2] respectively.
+- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively.
+- infet[1-7]-supply: The input supply for FET[1-7] respectively.
+- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.
+
+Optional properties:
+- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
+ If DCDCs are externally controlled then this property should be there.
+- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
+ If DCDCs are externally controlled and if it is from GPIO then GPIO
+ number should be provided. If it is externally controlled and no GPIO
+ entry then driver will just configure this rails as external control
+ and will not provide any enable/disable APIs.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps65090@48 {
+ compatible = "ti,tps65090";
+ reg = <0x48>;
+ interrupts = <0 88 0x4>;
+
+ vsys1-supply = <&some_reg>;
+ vsys2-supply = <&some_reg>;
+ vsys3-supply = <&some_reg>;
+ infet1-supply = <&some_reg>;
+ infet2-supply = <&some_reg>;
+ infet3-supply = <&some_reg>;
+ infet4-supply = <&some_reg>;
+ infet5-supply = <&some_reg>;
+ infet6-supply = <&some_reg>;
+ infet7-supply = <&some_reg>;
+ vsys_l1-supply = <&some_reg>;
+ vsys_l2-supply = <&some_reg>;
+
+ regulators {
+ dcdc1 {
+ regulator-name = "dcdc1";
+ regulator-boot-on;
+ regulator-always-on;
+ ti,enable-ext-control;
+ dcdc-ext-control-gpios = <&gpio 10 0>;
+ };
+
+ dcdc2 {
+ regulator-name = "dcdc2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3 {
+ regulator-name = "dcdc3";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet1 {
+ regulator-name = "fet1";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet2 {
+ regulator-name = "fet2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet3 {
+ regulator-name = "fet3";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet4 {
+ regulator-name = "fet4";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet5 {
+ regulator-name = "fet5";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet6 {
+ regulator-name = "fet6";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet7 {
+ regulator-name = "fet7";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2 {
+ regulator-name = "ldo2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-rproc.txt b/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-rproc.txt
new file mode 100644
index 000000000..0a1e85822
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-rproc.txt
@@ -0,0 +1,50 @@
+Texas Instruments' K3 Remote processor driver
+=============================================
+
+In K3 generation Socs, loading an image on any processing entity
+cannot be done directly from U-Boot. In order to load an image,
+remoteproc driver should communicate to SYSFW with a specific sequence.
+Also enable the timer required for this remotecore.
+
+Required properties:
+--------------------
+- compatible: Shall be: "ti,am654-rproc"
+- reg: base address of the remoteproc timer.
+- power-domains: Should contain two sets of entries:
+ First set corresponds to pm domain of the
+ remotecore timer. Seconf entry corresponds to the
+ remoteproc to start.
+ This property is as per the binding,
+ doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+- resets: Should contain a phandle to a reset controller node
+ and an args specifier containing the remote code
+ device id and reset mask value. This is as per the
+ doc/device-tree-bindings/reset/ti,sci-reset.txt
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-proc-id: Processor id as identified by TISCI
+
+Optional properties:
+--------------------
+- assigned-clocks: Should contain a phandle to clock node and an args
+ specifier containing the remote core device id and
+ the clock id within the remote core. This is as per
+ doc/device-tree-bindings/clock/ti,sci-clk.txt
+- assigned-clock-rates: One entry for each entry of assigned-clocks. This is
+ the frequency at which the corresponding clock needs
+ to be assigned.
+- ti,sci-host-id: Host ID to which the processor control is transferred to
+
+Example:
+---------
+
+a53_0: a53@0 {
+ compatible = "ti,am654-rproc";
+ power-domains = <&k3_pds 61>,
+ <&k3_pds 202>;
+ resets = <&k3_reset 202 0>;
+ assigned-clocks = <&k3_clks 202 0>;
+ assigned-clock-rates = <800000000>;
+ ti,sci = <&dmsc>;
+ ti,sci-proc-id = <32>;
+ ti,sci-host-id = <10>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-system-controller.txt b/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
new file mode 100644
index 000000000..32f4720b0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/remoteproc/k3-system-controller.txt
@@ -0,0 +1,24 @@
+Texas Instruments' K3 System Controller
+=========================================
+
+K3 specific SoCs have a dedicated microcontroller for doing
+resource management. Any HLOS/firmware on compute clusters should
+load a firmware to this microcontroller before accessing any resource.
+This driver communicates with ROM for loading this firmware.
+
+Required properties:
+--------------------
+- compatible: Shall be: "ti,am654-system-controller"
+- mbox-names: "tx" for Transfer channel
+ "rx" for Receive channel
+- mboxes: Corresponding phandles to mailbox channels.
+
+
+Example:
+--------
+
+system-controller: system-controller {
+ compatible = "ti,am654-system-controller";
+ mboxes= <&secproxy 4>, <&secproxy 5>;
+ mbox-names = "tx", "rx";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/remoteproc/remoteproc.txt b/roms/u-boot/doc/device-tree-bindings/remoteproc/remoteproc.txt
new file mode 100644
index 000000000..031764f51
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/remoteproc/remoteproc.txt
@@ -0,0 +1,14 @@
+Remote Processor uclass
+
+Binding:
+
+Remoteproc devices shall have compatible corresponding to thier
+drivers. However the following generic properties will be supported
+
+Optional Properties:
+- remoteproc-name: a string, used if provided to describe the processor.
+ This must be unique in an operational system.
+- remoteproc-internal-memory-mapped: a bool, indicates that the remote
+ processor has internal memory that it uses to execute code and store
+ data. Such a device is not expected to have a MMU. If no type property
+ is provided, the device is assumed to map to such a model.
diff --git a/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt b/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
new file mode 100644
index 000000000..80ab7a409
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-dsp-rproc.txt
@@ -0,0 +1,101 @@
+TI K3 DSP devices
+=================
+
+The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems that
+are used to offload some of the processor-intensive tasks or algorithms, for
+achieving various system level goals.
+
+These processor sub-systems usually contain additional sub-modules like L1
+and/or L2 caches/SRAMs, an Interrupt Controller, an external memory controller,
+a dedicated local power/sleep controller etc. The DSP processor cores in the
+K3 SoCs is usually either a TMS320C66x CorePac processor or a TMS320C71x CorePac
+processor.
+
+DSP Device Node:
+================
+Each DSP Core sub-system is represented as a single DT node. Each node has a
+number of required or optional properties that enable the OS running on the
+host processor (Arm CorePac) to perform the device management of the remote
+processor and to communicate with the remote processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+ "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
+
+- reg: Should contain an entry for each value in 'reg-names'.
+ Each entry should have the memory region's start address
+ and the size of the region, the representation matching
+ the parent node's '#address-cells' and '#size-cells' values.
+
+- reg-names: Should contain strings with the following names, each
+ representing a specific internal memory region (if
+ present), and should be defined in this order,
+ "l2sram", "l1pram", "l1dram"
+ NOTE: C71x DSPs do not have a "l1pram" memory.
+
+- ti,sci: Should be a phandle to the TI-SCI System Controller node
+
+- ti,sci-dev-id: Should contain the TI-SCI device id corresponding to the
+ DSP Core. Please refer to the corresponding System
+ Controller documentation for valid values for the DSP
+ cores.
+
+- ti,sci-proc-ids: Should contain 2 integer values. The first cell should
+ contain the TI-SCI processor id for the DSP core device
+ and the second cell should contain the TI-SCI host id to
+ which the processor control ownership should be
+ transferred to.
+
+- resets: Should contain the phandle to the reset controller node
+ managing the resets for this device, and a reset
+ specifier. Please refer to the following reset bindings
+ for the reset argument specifier,
+ Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+
+Example:
+---------
+
+1. J721E SoC
+ /* J721E remoteproc alias */
+ aliases {
+ rproc6 = &c66_0;
+ rproc8 = &c71_0;
+ };
+
+ cbass_main: interconnect@100000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */
+ <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
+ <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
+
+ /* J721E C66_0 DSP node */
+ c66_0: dsp@4d80800000 {
+ compatible = "ti,j721e-c66-dsp";
+ reg = <0x4d 0x80800000 0x00 0x00048000>,
+ <0x4d 0x80e00000 0x00 0x00008000>,
+ <0x4d 0x80f00000 0x00 0x00008000>;
+ reg-names = "l2sram", "l1pram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <142>;
+ ti,sci-proc-ids = <0x03 0xFF>;
+ resets = <&k3_reset 142 1>;
+ };
+
+ /* J721E C71_0 DSP node */
+ c71_0: dsp@64800000 {
+ compatible = "ti,j721e-c71-dsp";
+ reg = <0x00 0x64800000 0x00 0x00080000>,
+ <0x00 0x64e00000 0x00 0x0000c000>;
+ reg-names = "l2sram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <15>;
+ ti,sci-proc-ids = <0x30 0xFF>;
+ resets = <&k3_reset 15 1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt b/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
new file mode 100644
index 000000000..25ee495fe
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
@@ -0,0 +1,167 @@
+TI K3 R5F processor subsystems
+==============================
+
+The TI K3 family of SoCs usually have one or more dual-core Arm Cortex
+R5F processor subsystems/clusters (R5FSS). The dual core cluster can be
+used either in a LockStep mode providing safety/fault tolerance features
+or in a Split mode providing two individual compute cores for doubling
+the compute capacity. These are used together with other processors
+present on the SoC to achieve various system level goals.
+
+R5F Sub-System Device Node:
+===========================
+Each Dual-Core R5F sub-system is represented as a single DTS node representing
+the cluster, with a pair of child DT nodes representing the individual R5F
+cores. Each node has a number of required or optional properties that enable
+the OS running on the host processor to perform the device management of the
+remote processor and to communicate with the remote processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,am654-r5fss" for R5F clusters/subsystems on
+ K3 AM65x SoCs
+ "ti,j721e-r5fss" for R5F clusters/subsystems on
+ K3 J721E SoCs
+ "ti,j7200-r5fss" for R5F clusters/subsystems on
+ K3 J7200 SoCs
+- power-domains: Should contain a phandle to a PM domain provider node
+ and an args specifier containing the R5FSS device id
+ value. This property is as per the binding,
+ Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- #address-cells: Should be 1
+- #size-cells: Should be 1
+- ranges: Standard ranges definition providing translations for
+ R5F TCM address spaces
+
+Optional properties:
+--------------------
+- ti,cluster-mode: Configuration Mode for the Dual R5F cores within the R5F
+ cluster. Should be either a value of 1 (LockStep mode) or
+ 0 (Split mode), default is LockStep mode if omitted.
+
+
+R5F Processor Child Nodes:
+==========================
+The R5F Sub-System device node should define two R5F child nodes, each node
+representing a TI instantiation of the Arm Cortex R5F core. There are some
+specific integration differences for the IP like the usage of a Region Address
+Translator (RAT) for translating the larger SoC bus addresses into a 32-bit
+address space for the processor.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,am654-r5f" for the R5F cores in K3 AM65x SoCs
+ "ti,j721e-r5f" for the R5F cores in K3 J721E SOCs
+ "ti,j7200-r5f" for the R5F cores in K3 J7200 SOCs
+- reg: Should contain an entry for each value in 'reg-names'.
+ Each entry should have the memory region's start address
+ and the size of the region, the representation matching
+ the parent node's '#address-cells' and '#size-cells' values.
+- reg-names: Should contain strings with the following names, each
+ representing a specific internal memory region, and
+ should be defined in this order,
+ "atcm", "btcm"
+- ti,sci: Should be a phandle to the TI-SCI System Controller node
+- ti,sci-dev-id: Should contain the TI-SCI device id corresponding to the
+ R5F Core. Please refer to the corresponding System
+ Controller documentation for valid values for the R5F
+ cores.
+- ti,sci-proc-ids: Should contain 2 integer values. The first cell should
+ contain the TI-SCI processor id for the R5F core device
+ and the second cell should contain the TI-SCI host id to
+ which the processor control ownership should be
+ transferred to.
+- resets: Should contain the phandle to the reset controller node
+ managing the resets for this device, and a reset
+ specifier. Please refer to the following reset bindings
+ for the reset argument specifier,
+ Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+ for AM65x, J721E and J7200 SoCs
+
+Optional properties:
+--------------------
+The following properties are optional properties for each of the R5F cores:
+
+- ti,atcm-enable: R5F core configuration mode dictating if ATCM should be
+ enabled. Should be either a value of 1 (enabled) or
+ 0 (disabled), default is disabled if omitted. R5F view
+ of ATCM dictated by ti,loczrama property.
+- ti,btcm-enable: R5F core configuration mode dictating if BTCM should be
+ enabled. Should be either a value of 1 (enabled) or
+ 0 (disabled), default is enabled if omitted. R5F view
+ of BTCM dictated by ti,loczrama property.
+- ti,loczrama: R5F core configuration mode dictating which TCM should
+ appear at address 0 (from core's view). Should be either
+ a value of 1 (ATCM at 0x0) or 0 (BTCM at 0x0), default
+ value is 1 if omitted.
+
+Example:
+--------
+1. AM654 SoC
+ /* AM65x remoteproc alias */
+ aliases {
+ remoteproc0 = &mcu_r5fss0_core0;
+ };
+
+ cbass_main: interconnect@100000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x41000000 0x00 0x41000000 0x00 0x00020000>,
+ <0x00 0x41400000 0x00 0x41400000 0x00 0x00020000>,
+ <0x00 0x41c00000 0x00 0x41c00000 0x00 0x00080000>;
+
+ cbass_mcu: interconnect@28380000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x41000000 0x00 0x41000000 0x00 0x00020000>, /* MCU R5F Core0 */
+ <0x00 0x41400000 0x00 0x41400000 0x00 0x00020000>, /* MCU R5F Core1 */
+ <0x00 0x41c00000 0x00 0x41c00000 0x00 0x00080000>; /* MCU SRAM */
+
+ /* AM65x MCU R5FSS node */
+ mcu_r5fss0: r5fss@41000000 {
+ compatible = "ti,am654-r5fss";
+ power-domains = <&k3_pds 129>;
+ ti,cluster-mode = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x41000000 0x00 0x41000000 0x20000>,
+ <0x41400000 0x00 0x41400000 0x20000>;
+
+ mcu_r5f0: r5f@41000000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41000000 0x00008000>,
+ <0x41010000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <159>;
+ ti,sci-proc-ids = <0x01 0xFF>;
+ resets = <&k3_reset 159 1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
+ };
+
+ mcu_r5f1: r5f@41400000 {
+ compatible = "ti,am654-r5f";
+ reg = <0x41400000 0x00008000>,
+ <0x41410000 0x00008000>;
+ reg-names = "atcm", "btcm";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <245>;
+ ti,sci-proc-ids = <0x02 0xFF>;
+ resets = <&k3_reset 245 1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
+ };
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/reserved-memory/reserved-memory.txt b/roms/u-boot/doc/device-tree-bindings/reserved-memory/reserved-memory.txt
new file mode 100644
index 000000000..bac4afa3b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/reserved-memory/reserved-memory.txt
@@ -0,0 +1,136 @@
+*** Reserved memory regions ***
+
+Reserved memory is specified as a node under the /reserved-memory node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions. Such memory regions are usually designed for
+the special usage by various device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory node
+---------------------
+#address-cells, #size-cells (required) - standard definition
+ - Should use the same values as the root node
+ranges (required) - standard definition
+ - Should be empty
+
+/reserved-memory/ child nodes
+-----------------------------
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a 'reg' property to
+specify a specific range of reserved memory, or a 'size' property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+address (@<address>) should be appended to the name if the node is a
+static allocation.
+
+Properties:
+Requires either a) or b) below.
+a) static allocation
+ reg (required) - standard definition
+b) dynamic allocation
+ size (required) - length based on parent's #size-cells
+ - Size in bytes of memory to reserve.
+ alignment (optional) - length based on parent's #size-cells
+ - Address boundary for alignment of allocation.
+ alloc-ranges (optional) - prop-encoded-array (address, length pairs).
+ - Specifies regions of memory that are
+ acceptable to allocate from.
+
+If both reg and size are present, then the reg property takes precedence
+and size is ignored.
+
+Additional properties:
+compatible (optional) - standard definition
+ - may contain the following strings:
+ - shared-dma-pool: This indicates a region of memory meant to be
+ used as a shared pool of DMA buffers for a set of devices. It can
+ be used by an operating system to instantiate the necessary pool
+ management subsystem if necessary.
+ - vendor specific string in the form <vendor>,[<device>-]<usage>
+no-map (optional) - empty property
+ - Indicates the operating system must not create a virtual mapping
+ of the region as part of its standard mapping of system memory,
+ nor permit speculative access to it under any circumstances other
+ than under the control of the device driver using the region.
+reusable (optional) - empty property
+ - The operating system can use the memory in this region with the
+ limitation that the device driver(s) owning the region need to be
+ able to reclaim it back. Typically that means that the operating
+ system can use that region to store volatile or cached data that
+ can be otherwise regenerated or migrated elsewhere.
+
+Linux implementation note:
+- If a "linux,cma-default" property is present, then Linux will use the
+ region for the default pool of the contiguous memory allocator.
+
+- If a "linux,dma-default" property is present, then Linux will use the
+ region for the default pool of the consistent DMA allocator.
+
+Device node references to reserved memory
+-----------------------------------------
+Regions in the /reserved-memory node may be referenced by other device
+nodes by adding a memory-region property to the device node.
+
+memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
+
+Example
+-------
+This example defines 3 contiguous regions are defined for Linux kernel:
+one default of all device drivers (named linux,cma@72000000 and 64MiB in size),
+one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and
+one for multimedia processing (named multimedia-memory@77000000, 64MiB).
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory {
+ reg = <0x40000000 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x4000000>;
+ alignment = <0x2000>;
+ linux,cma-default;
+ };
+
+ display_reserved: framebuffer@78000000 {
+ reg = <0x78000000 0x800000>;
+ };
+
+ multimedia_reserved: multimedia@77000000 {
+ compatible = "acme,multimedia-memory";
+ reg = <0x77000000 0x4000000>;
+ };
+ };
+
+ /* ... */
+
+ fb0: video@12300000 {
+ memory-region = <&display_reserved>;
+ /* ... */
+ };
+
+ scaler: scaler@12500000 {
+ memory-region = <&multimedia_reserved>;
+ /* ... */
+ };
+
+ codec: codec@12600000 {
+ memory-region = <&multimedia_reserved>;
+ /* ... */
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/reset/reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/reset.txt
new file mode 100644
index 000000000..31db6ff84
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/reset/reset.txt
@@ -0,0 +1,75 @@
+= Reset Signal Device Tree Bindings =
+
+This binding is intended to represent the hardware reset signals present
+internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+standalone chips are most likely better represented as GPIOs, although there
+are likely to be exceptions to this rule.
+
+Hardware blocks typically receive a reset signal. This signal is generated by
+a reset provider (e.g. power management or clock module) and received by a
+reset consumer (the module being reset, or a module managing when a sub-
+ordinate module is reset). This binding exists to represent the provider and
+consumer, and provide a way to couple the two together.
+
+A reset signal is represented by the phandle of the provider, plus a reset
+specifier - a list of DT cells that represents the reset signal within the
+provider. The length (number of cells) and semantics of the reset specifier
+are dictated by the binding of the reset provider, although common schemes
+are described below.
+
+A word on where to place reset signal consumers in device tree: It is possible
+in hardware for a reset signal to affect multiple logically separate HW blocks
+at once. In this case, it would be unwise to represent this reset signal in
+the DT node of each affected HW block, since if activated, an unrelated block
+may be reset. Instead, reset signals should be represented in the DT node
+where it makes most sense to control it; this may be a bus node if all
+children of the bus are affected by the reset signal, or an individual HW
+block node for dedicated reset signals. The intent of this binding is to give
+appropriate software access to the reset signals in order to manage the HW,
+rather than to slavishly enumerate the reset signal that affects each HW
+block.
+
+= Reset providers =
+
+Required properties:
+#reset-cells: Number of cells in a reset specifier; Typically 0 for nodes
+ with a single reset output and 1 for nodes with multiple
+ reset outputs.
+
+For example:
+
+ rst: reset-controller {
+ #reset-cells = <1>;
+ };
+
+= Reset consumers =
+
+Required properties:
+resets: List of phandle and reset specifier pairs, one pair
+ for each reset signal that affects the device, or that the
+ device manages. Note: if the reset provider specifies '0' for
+ #reset-cells, then only the phandle portion of the pair will
+ appear.
+
+Optional properties:
+reset-names: List of reset signal name strings sorted in the same order as
+ the resets property. Consumers drivers will use reset-names to
+ match reset signal names with reset specifiers.
+
+For example:
+
+ device {
+ resets = <&rst 20>;
+ reset-names = "reset";
+ };
+
+This represents a device with a single reset signal named "reset".
+
+ bus {
+ resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
+ reset-names = "i2s1", "i2s2", "dma", "mixer";
+ };
+
+This represents a bus that controls the reset signal of each of four sub-
+ordinate devices. Consider for example a bus that fails to operate unless no
+child device has reset asserted.
diff --git a/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt b/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 000000000..01db34375
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,6 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+====================================================
+
+The RCC IP is both a reset and a clock controller.
+
+Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
diff --git a/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt
new file mode 100644
index 000000000..f136b3d22
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/reset/syscon-reset.txt
@@ -0,0 +1,36 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset and
+shifted by the reset specifier/
+
+To assert a reset on some device, the equivalent of the following operation is
+performed, where reset_id is the reset specifier from the device's resets
+property.
+
+ if (BIT(reset_id) & mask)
+ regmap[offset][reset_id] = assert-high;
+
+Required properties:
+- compatible: should contain "syscon-reset"
+- #reset-cells: must be 1
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+
+Optional properties:
+- mask: accept only the reset specifiers defined by the mask (32 bit)
+- assert-high: Bit to write when asserting a reset. Defaults to 1.
+
+Default will be little endian mode, 32 bit access only.
+
+Example:
+
+ reset-controller {
+ compatible = "syscon-reset";
+ #reset-cells = <1>;
+ regmap = <&sysctl>;
+ offset = <0x20>;
+ mask = <0x27FFFFFF>;
+ assert-high = <0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt b/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt
new file mode 100644
index 000000000..e7e2d13f9
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/reset/ti,sci-reset.txt
@@ -0,0 +1,54 @@
+Texas Instruments TI SCI Reset Controller
+=========================================
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+Reset Controller Node
+=====================
+The reset controller node represents the resets of various hardware modules
+present on the SoC managed by the SYSFW. Because this relies on the TI SCI
+protocol to communicate with the SYSFW it must be a child of the sysfw node.
+
+Required Properties:
+--------------------
+ - compatible: Must be "ti,sci-reset"
+ - #reset-cells: Must be 2. Please see the reset consumer node below for
+ usage details.
+
+Example (AM65x):
+----------------
+ sysfw: sysfw {
+ compatible = "ti,am654-system-controller";
+ ...
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
+
+Reset Consumers
+===============
+Each of the reset consumer nodes should have the following properties,
+in addition to their own properties.
+
+Required Properties:
+--------------------
+ - resets: A phandle and reset specifier pair, one pair for each reset signal
+ that affects the device, or that the device manages. The phandle
+ should point to the TI SCI reset controller node, and the reset
+ specifier should have 2 cell-values. The first cell should contain
+ the device ID. The second cell should contain the reset mask value
+ used by system controller.
+
+Example (AM65x):
+----------------
+ uart2: serial@02800000 {
+ compatible = "ti,omap4-uart";
+ ...
+ resets = <&k3_reset 5 1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/root.txt b/roms/u-boot/doc/device-tree-bindings/root.txt
new file mode 100644
index 000000000..001ccf36c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/root.txt
@@ -0,0 +1,4 @@
+The root node
+
+Optional properties:
+ - serial-number : a string representing the device's serial number
diff --git a/roms/u-boot/doc/device-tree-bindings/rtc/abracon,abx80x.txt b/roms/u-boot/doc/device-tree-bindings/rtc/abracon,abx80x.txt
new file mode 100644
index 000000000..2405e35a1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/rtc/abracon,abx80x.txt
@@ -0,0 +1,31 @@
+Abracon ABX80X I2C ultra low power RTC/Alarm chip
+
+The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, ab1801,
+ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the ab1805
+is the superset of ab180x.
+
+Required properties:
+
+ - "compatible": should one of:
+ "abracon,abx80x"
+ "abracon,ab0801"
+ "abracon,ab0803"
+ "abracon,ab0804"
+ "abracon,ab0805"
+ "abracon,ab1801"
+ "abracon,ab1803"
+ "abracon,ab1804"
+ "abracon,ab1805"
+ "microcrystal,rv1805"
+ Using "abracon,abx80x" will enable chip autodetection.
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+The abx804 and abx805 have a trickle charger that is able to charge the
+connected battery or supercap. Both the following properties have to be defined
+and valid to enable charging:
+
+ - "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V)
+ - "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the output
+ resistor, the other values are in kOhm.
diff --git a/roms/u-boot/doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt b/roms/u-boot/doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt
new file mode 100644
index 000000000..1d990bcc0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/rtc/brcm,brcmstb-waketimer.txt
@@ -0,0 +1,22 @@
+Broadcom STB wake-up Timer
+
+The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the
+ability to wake up the system from low-power suspend/standby modes.
+
+Required properties:
+- compatible : should contain "brcm,brcmstb-waketimer"
+- reg : the register start and length for the WKTMR block
+- interrupts : The TIMER interrupt
+- interrupt-parent: The phandle to the Always-On (AON) Power Management (PM) L2
+ interrupt controller node
+- clocks : The phandle to the UPG fixed clock (27Mhz domain)
+
+Example:
+
+waketimer@f0411580 {
+ compatible = "brcm,brcmstb-waketimer";
+ reg = <0xf0411580 0x14>;
+ interrupts = <0x3>;
+ interrupt-parent = <&aon_pm_l2_intc>;
+ clocks = <&upg_fixed>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/rtc/ds3232.txt b/roms/u-boot/doc/device-tree-bindings/rtc/ds3232.txt
new file mode 100644
index 000000000..254b7bc3c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/rtc/ds3232.txt
@@ -0,0 +1,15 @@
+DS3232 Real-Time Clock with SRAM
+
+The RTC driver provides time and date functionality. Also read and write
+functions are provided that can be used to access the SRAM memory.
+
+Required properties:
+- compatible : should contain "dallas,ds3232"
+- reg : the I2C RTC address
+
+Example:
+
+rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/8250.txt b/roms/u-boot/doc/device-tree-bindings/serial/8250.txt
new file mode 100644
index 000000000..ba8edae0e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/8250.txt
@@ -0,0 +1,66 @@
+* UART (Universal Asynchronous Receiver/Transmitter)
+
+Required properties:
+- compatible : one of:
+ - "ns8250"
+ - "ns16450"
+ - "ns16550a"
+ - "ns16550"
+ - "ns16750"
+ - "ns16850"
+ - For Tegra20, must contain "nvidia,tegra20-uart"
+ - For other Tegra, must contain '"nvidia,<chip>-uart",
+ "nvidia,tegra20-uart"' where <chip> is tegra30, tegra114, tegra124,
+ tegra132, or tegra210.
+ - "nxp,lpc3220-uart"
+ - "ralink,rt2880-uart"
+ - "ibm,qpace-nwp-serial"
+ - "altr,16550-FIFO32"
+ - "altr,16550-FIFO64"
+ - "altr,16550-FIFO128"
+ - "fsl,16550-FIFO64"
+ - "fsl,ns16550"
+ - "serial" if the port type is unknown.
+- reg : offset and length of the register set for the device.
+- interrupts : should contain uart interrupt.
+- clock-frequency : the input clock frequency for the UART
+ or
+ clocks phandle to refer to the clk used as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+
+Optional properties:
+- current-speed : the current active speed of the UART.
+- reg-offset : offset to apply to the mapbase from the start of the registers.
+- reg-shift : quantity to shift the register offsets by.
+- reg-io-width : the size (in bytes) of the IO accesses that should be
+ performed on the device. There are some systems that require 32-bit
+ accesses to the UART (e.g. TI davinci).
+- used-by-rtas : set to indicate that the port is in use by the OpenFirmware
+ RTAS and should not be registered.
+- no-loopback-test: set to indicate that the port does not implements loopback
+ test mode
+- fifo-size: the fifo size of the UART.
+- auto-flow-control: one way to enable automatic flow control support. The
+ driver is allowed to detect support for the capability even without this
+ property.
+
+Note:
+* fsl,ns16550:
+ ------------
+ Freescale DUART is very similar to the PC16552D (and to a
+ pair of NS16550A), albeit with some nonstandard behavior such as
+ erratum A-004737 (relating to incorrect BRK handling).
+
+ Represents a single port that is compatible with the DUART found
+ on many Freescale chips (examples include mpc8349, mpc8548,
+ mpc8641d, p4080 and ls2080a).
+
+Example:
+
+ uart@80230000 {
+ compatible = "ns8250";
+ reg = <0x80230000 0x100>;
+ clock-frequency = <3686400>;
+ interrupts = <10>;
+ reg-shift = <2>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/altera_jtaguart.txt b/roms/u-boot/doc/device-tree-bindings/serial/altera_jtaguart.txt
new file mode 100644
index 000000000..97c7062c5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/altera_jtaguart.txt
@@ -0,0 +1,4 @@
+Altera JTAG UART
+
+Required properties:
+- compatible : should be "altr,juart-1.0"
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/altera_uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/altera_uart.txt
new file mode 100644
index 000000000..ebac3f5c1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/altera_uart.txt
@@ -0,0 +1,7 @@
+Altera UART
+
+Required properties:
+- compatible : should be "altr,uart-1.0"
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/bcm2835-aux-uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/bcm2835-aux-uart.txt
new file mode 100644
index 000000000..75886e5fd
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/bcm2835-aux-uart.txt
@@ -0,0 +1,10 @@
+* BCM283x mini UART
+
+Required properties:
+- compatible: must be "brcm,bcm2835-aux-uart"
+- reg: exactly one register range with length 0x1000
+- clock: input clock frequency for the UART (used to calculate the baud
+ rate divisor)
+
+Optional properties:
+- skip-init: if present, the baud rate divisor is not changed
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/mcf-uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/mcf-uart.txt
new file mode 100644
index 000000000..d73f764c0
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/mcf-uart.txt
@@ -0,0 +1,19 @@
+Freescale ColdFire UART
+
+Required properties:
+- compatible : should be "fsl,mcf-uart"
+- reg: start address and size of the registers
+
+Example:
+
+soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uart0: uart@fc060000 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc060000 0x40>;
+ status = "disabled";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/microchip,pic32-uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/microchip,pic32-uart.txt
new file mode 100644
index 000000000..f00e215cf
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/microchip,pic32-uart.txt
@@ -0,0 +1,5 @@
+* Microchip PIC32 serial UART
+
+Required properties:
+- compatible: must be "microchip,pic32mzda-uart".
+- reg: exactly one register range.
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/msm-serial.txt b/roms/u-boot/doc/device-tree-bindings/serial/msm-serial.txt
new file mode 100644
index 000000000..dca995798
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/msm-serial.txt
@@ -0,0 +1,10 @@
+Qualcomm UART (Data Mover mode)
+
+Required properties:
+- compatible: must be "qcom,msm-uartdm-v1.4"
+- reg: start address and size of the registers
+- clock: interface clock (must accept baudrate as a frequency)
+
+Optional properties:
+- bit-rate: Data Mover bit rate register value
+ (If not defined then 0xCC is used as default)
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/mxc-serial.txt b/roms/u-boot/doc/device-tree-bindings/serial/mxc-serial.txt
new file mode 100644
index 000000000..ede92a485
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/mxc-serial.txt
@@ -0,0 +1,8 @@
+NXP i.MX (MXC) UART
+
+Required properties:
+- compatible: must be "fsl,imx7d-uart"
+- reg: start address and size of the registers
+
+Optional properties:
+- fsl,dte-mode: use DTE mode
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/omap_serial.txt b/roms/u-boot/doc/device-tree-bindings/serial/omap_serial.txt
new file mode 100644
index 000000000..7a71b5de7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/omap_serial.txt
@@ -0,0 +1,33 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- compatible : should be "ti,am4372-uart" for AM437x controllers
+- compatible : should be "ti,am3352-uart" for AM335x controllers
+- compatible : should be "ti,dra742-uart" for DRA7x controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
+- ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+ uart4: serial@49042000 {
+ compatible = "ti,omap3-uart";
+ reg = <0x49042000 0x400>;
+ interrupts = <80>;
+ dmas = <&sdma 81 &sdma 82>;
+ dma-names = "tx", "rx";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/pl01x.txt b/roms/u-boot/doc/device-tree-bindings/serial/pl01x.txt
new file mode 100644
index 000000000..017b1e235
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/pl01x.txt
@@ -0,0 +1,10 @@
+* ARM AMBA Primecell PL011 & PL010 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011" or "arm,pl010"
+- reg: exactly one register range with length 0x1000
+- clock: input clock frequency for the UART (used to calculate the baud
+ rate divisor)
+
+Optional properties:
+- skip-init: if present, the baud rate divisor is not changed
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/qca,ar9330-uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/qca,ar9330-uart.txt
new file mode 100644
index 000000000..ec576a1ce
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/qca,ar9330-uart.txt
@@ -0,0 +1,24 @@
+* Qualcomm Atheros AR9330 High-Speed UART
+
+Required properties:
+
+- compatible: Must be "qca,ar9330-uart"
+
+- reg: Specifies the physical base address of the controller and
+ the length of the memory mapped region.
+
+Additional requirements:
+
+ Each UART port must have an alias correctly numbered in "aliases"
+ node.
+
+Example:
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ uart0: uart@18020000 {
+ compatible = "qca,ar9330-uart";
+ reg = <0x18020000 0x14>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/sandbox-serial.txt b/roms/u-boot/doc/device-tree-bindings/serial/sandbox-serial.txt
new file mode 100644
index 000000000..f429c9042
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/sandbox-serial.txt
@@ -0,0 +1,13 @@
+Sandbox serial
+
+The sandbox serial device is an emulated device which displays its output
+on the host machine's console, and accepts input from its keyboard.
+
+Required properties:
+ compatible: "sandbox,serial"
+
+Optional properties:
+ sandbox,text-colour: If present, this is the colour of the console text.
+ Supported values are:
+ "black", "red", "green", "yellow", "blue", "megenta", "cyan",
+ "white"
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/sh.txt b/roms/u-boot/doc/device-tree-bindings/serial/sh.txt
new file mode 100644
index 000000000..99634a5e7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/sh.txt
@@ -0,0 +1,6 @@
+* Renesas SCI serial interface
+
+Required properties:
+- compatible: must be "renesas,scif", "renesas,scifa" or "renesas,sci"
+- reg: exactly one register range with length
+- clock: input clock frequency for the SCI unit
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt b/roms/u-boot/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt
new file mode 100644
index 000000000..12bbe9f22
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt
@@ -0,0 +1,76 @@
+* Synopsys DesignWare ABP UART
+
+Required properties:
+- compatible : "snps,dw-apb-uart"
+- reg : offset and length of the register set for the device.
+- interrupts : should contain uart interrupt.
+
+Clock handling:
+The clock rate of the input clock needs to be supplied by one of
+- clock-frequency : the input clock frequency for the UART.
+- clocks : phandle to the input clock
+
+The supplying peripheral clock can also be handled, needing a second property
+- clock-names: tuple listing input clock names.
+ Required elements: "baudclk", "apb_pclk"
+
+Optional properties:
+- snps,uart-16550-compatible : reflects the value of UART_16550_COMPATIBLE
+ configuration parameter. Define this if your UART does not implement the busy
+ functionality.
+- resets : phandle to the parent reset controller.
+- reg-shift : quantity to shift the register offsets by. If this property is
+ not present then the register offsets are not shifted.
+- reg-io-width : the size (in bytes) of the IO accesses that should be
+ performed on the device. If this property is not present then single byte
+ accesses are used.
+- dcd-override : Override the DCD modem status signal. This signal will always
+ be reported as active instead of being obtained from the modem status
+ register. Define this if your serial port does not use this pin.
+- dsr-override : Override the DTS modem status signal. This signal will always
+ be reported as active instead of being obtained from the modem status
+ register. Define this if your serial port does not use this pin.
+- cts-override : Override the CTS modem status signal. This signal will always
+ be reported as active instead of being obtained from the modem status
+ register. Define this if your serial port does not use this pin.
+- ri-override : Override the RI modem status signal. This signal will always be
+ reported as inactive instead of being obtained from the modem status register.
+ Define this if your serial port does not use this pin.
+
+Example:
+
+ uart@80230000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x80230000 0x100>;
+ clock-frequency = <3686400>;
+ interrupts = <10>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ dcd-override;
+ dsr-override;
+ cts-override;
+ ri-override;
+ };
+
+Example with one clock:
+
+ uart@80230000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x80230000 0x100>;
+ clocks = <&baudclk>;
+ interrupts = <10>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+Example with two clocks:
+
+ uart@80230000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x80230000 0x100>;
+ clocks = <&baudclk>, <&apb_pclk>;
+ clock-names = "baudclk", "apb_pclk";
+ interrupts = <10>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/serial/xilinx_uartlite.txt b/roms/u-boot/doc/device-tree-bindings/serial/xilinx_uartlite.txt
new file mode 100644
index 000000000..d15753c8c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/serial/xilinx_uartlite.txt
@@ -0,0 +1,13 @@
+Binding for Xilinx Uartlite Controller
+
+Required properties:
+- compatible : should be "xlnx,xps-uartlite-1.00.a", or "xlnx,opb-uartlite-1.00.b"
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+
+Example:
+ serial@40600000 {
+ compatible = "xlnx,xps-uartlite-1.00.a";
+ interrupts = <1 0>;
+ reg = <0x40600000 0x10000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt b/roms/u-boot/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt
new file mode 100644
index 000000000..2758f8643
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt
@@ -0,0 +1,53 @@
+* UCC (Unified Communications Controllers)
+
+Required properties:
+- compatible : ucc_geth
+- cell-index : the ucc number(1-8), corresponding to UCCx in UM.
+- reg : Offset and length of the register set for the device
+- rx-clock-name: the UCC receive clock source
+ "none": clock source is disabled
+ "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+ "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+- tx-clock-name: the UCC transmit clock source
+ "none": clock source is disabled
+ "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+ "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+The following two properties are deprecated. rx-clock has been replaced
+with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
+Drivers that currently use the deprecated properties should continue to
+do so, in order to support older device trees, but they should be updated
+to check for the new properties first.
+- rx-clock : represents the UCC receive clock source.
+ 0x00 : clock source is disabled;
+ 0x1~0x10 : clock source is BRG1~BRG16 respectively;
+ 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+- tx-clock: represents the UCC transmit clock source;
+ 0x00 : clock source is disabled;
+ 0x1~0x10 : clock source is BRG1~BRG16 respectively;
+ 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+- phy-handle : The phandle for the PHY connected to this controller.
+- phy-connection-type : a string naming the controller/PHY interface type,
+ i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+ Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+ "tbi", or "rtbi".
+- pio-handle : The phandle for the Parallel I/O port configuration.
+
+Deprecated properties:
+- device-id : the ucc number(1-8), corresponding to UCCx in UM.
+ you should use cell-index
+
+Example:
+ ucc@2000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <1>;
+ reg = <2000 200>;
+ interrupts = <a0 0>;
+ interrupt-parent = <700>;
+ mac-address = [ 00 04 9f 00 23 23 ];
+ rx-clock = "none";
+ tx-clock = "clk9";
+ phy-handle = <212000>;
+ phy-connection-type = "gmii";
+ pio-handle = <140001>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/sound/da7219.txt b/roms/u-boot/doc/device-tree-bindings/sound/da7219.txt
new file mode 100644
index 000000000..5fd8a9f1e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sound/da7219.txt
@@ -0,0 +1,113 @@
+Dialog Semiconductor DA7219 Audio Codec bindings
+
+DA7219 is an audio codec with advanced accessory detect features.
+
+======
+
+Required properties:
+- compatible : Should be "dlg,da7219"
+- reg: Specifies the I2C slave address
+
+- interrupts : IRQ line info for DA7219.
+ (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
+ further information relating to interrupt properties)
+
+- VDD-supply: VDD power supply for the device
+- VDDMIC-supply: VDDMIC power supply for the device
+- VDDIO-supply: VDDIO power supply for the device
+ (See Documentation/devicetree/bindings/regulator/regulator.txt for further
+ information relating to regulators)
+
+Optional properties:
+- interrupt-names : Name associated with interrupt line. Should be "wakeup" if
+ interrupt is to be used to wake system, otherwise "irq" should be used.
+- wakeup-source: Flag to indicate this device can wake system (suspend/resume).
+
+- #clock-cells : Should be set to '<0>', only one clock source provided;
+- clock-output-names : Name given for DAI clocks output;
+
+- clocks : phandle and clock specifier for codec MCLK.
+- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
+
+- dlg,micbias-lvl : Voltage (mV) for Mic Bias
+ [<1600>, <1800>, <2000>, <2200>, <2400>, <2600>]
+- dlg,mic-amp-in-sel : Mic input source type
+ ["diff", "se_p", "se_n"]
+- dlg,mclk-name : String name of MCLK for ACPI
+
+Deprecated properties:
+- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine
+ (LDO unavailable in production HW so property no longer required).
+
+======
+
+Child node - 'da7219_aad':
+
+Optional properties:
+- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV).
+ [<2800>, <2900>]
+- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms)
+- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms)
+ [<2>, <5>, <10>, <50>, <100>, <200>, <500>]
+- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms)
+ [<200>, <500>, <750>, <1000>]
+- dlg,jack-ins-deb : Debounce time for jack insertion (ms)
+ [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>]
+- dlg,jack-det-rate: Jack type detection latency (3/4 pole)
+ ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"]
+- dlg,jack-rem-deb : Debounce time for jack removal (ms)
+ [<1>, <5>, <10>, <20>]
+- dlg,a-d-btn-thr : Impedance threshold between buttons A and D
+ [0x0 - 0xFF]
+- dlg,d-b-btn-thr : Impedance threshold between buttons D and B
+ [0x0 - 0xFF]
+- dlg,b-c-btn-thr : Impedance threshold between buttons B and C
+ [0x0 - 0xFF]
+- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic
+ [0x0 - 0xFF]
+- dlg,btn-avg : Number of 8-bit readings for averaged button measurement
+ [<1>, <2>, <4>, <8>]
+- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement
+ [<1>, <2>, <4>, <8>]
+
+======
+
+Example:
+
+ codec: da7219@1a {
+ compatible = "dlg,da7219";
+ reg = <0x1a>;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ VDD-supply = <&reg_audio>;
+ VDDMIC-supply = <&reg_audio>;
+ VDDIO-supply = <&reg_audio>;
+
+ #clock-cells = <0>;
+ clock-output-names = "dai-clks";
+
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+
+ dlg,ldo-lvl = <1200>;
+ dlg,micbias-lvl = <2600>;
+ dlg,mic-amp-in-sel = "diff";
+
+ da7219_aad {
+ dlg,btn-cfg = <50>;
+ dlg,mic-det-thr = <500>;
+ dlg,jack-ins-deb = <20>;
+ dlg,jack-det-rate = "32ms_64ms";
+ dlg,jack-rem-deb = <1>;
+
+ dlg,a-d-btn-thr = <0xa>;
+ dlg,d-b-btn-thr = <0x16>;
+ dlg,b-c-btn-thr = <0x21>;
+ dlg,c-mic-btn-thr = <0x3E>;
+
+ dlg,btn-avg = <4>;
+ dlg,adc-1bit-rpt = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/sound/intel-hda.txt b/roms/u-boot/doc/device-tree-bindings/sound/intel-hda.txt
new file mode 100644
index 000000000..aa96be06e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sound/intel-hda.txt
@@ -0,0 +1,26 @@
+* Intel High-definition Audio
+
+Configuration is set using 'verbs' which are blocks of 16 bytes of data each
+with a different purpose, a little like a simple instruction set.
+
+Top-level node
+--------------
+
+Required properties:
+- compatible: "intel,hd-audio"
+- beep-verbs: list of verbs to send for a beep
+
+Optional properties
+- intel,beep-nid: Node ID to use for beep (will be detected if not provided)
+- codec-enable-gpio : The GPIO used to enable the audio codec
+
+Required subnodes:
+- codecs: Contains a list of codec nodes
+
+
+* Codec nodes
+
+Required properties:
+- vendor-id: 16-bit vendor ID for audio codec
+- device-id: 16-bit device ID for audio codec
+- verbs: List of verbs, each 4 cells in length
diff --git a/roms/u-boot/doc/device-tree-bindings/sound/max98357a.txt b/roms/u-boot/doc/device-tree-bindings/sound/max98357a.txt
new file mode 100644
index 000000000..4bce14ce8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sound/max98357a.txt
@@ -0,0 +1,22 @@
+Maxim MAX98357A audio DAC
+
+This node models the Maxim MAX98357A DAC.
+
+Required properties:
+- compatible : "maxim,max98357a"
+
+Optional properties:
+- sdmode-gpios : GPIO specifier for the chip's SD_MODE pin.
+ If this option is not specified then driver does not manage
+ the pin state (e.g. chip is always on).
+- sdmode-delay : specify delay time for SD_MODE pin.
+ If this option is specified, which means it's required i2s clocks
+ ready before SD_MODE is unmuted in order to avoid the speaker pop noise.
+ It's observed that 5ms is sufficient.
+
+Example:
+
+max98357a {
+ compatible = "maxim,max98357a";
+ sdmode-gpios = <&qcom_pinmux 25 0>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt b/roms/u-boot/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
new file mode 100644
index 000000000..25c63eac6
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
@@ -0,0 +1,54 @@
+NVIDIA Tegra audio complex, with MAX98090 CODEC
+
+Required properties:
+- compatible : "nvidia,tegra-audio-max98090"
+- clocks : Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+ - pll_a
+ - pll_a_out0
+ - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+- nvidia,model : The user-visible name of this sound complex.
+- nvidia,audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the MAX98090's pins (as documented in its binding), and the jacks
+ on the board:
+
+ * Headphones
+ * Speakers
+ * Mic Jack
+ * Int Mic
+
+- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
+ connected to the CODEC.
+- nvidia,audio-codec : The phandle of the MAX98090 audio codec.
+
+Optional properties:
+- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
+- nvidia,mic-det-gpios : The GPIO that detect microphones are plugged in
+- codec-enable-gpio : The GPIO used to enable the audio codec
+
+Example:
+
+sound {
+ compatible = "nvidia,tegra-audio-max98090-venice2",
+ "nvidia,tegra-audio-max98090";
+ nvidia,model = "NVIDIA Tegra Venice2";
+
+ nvidia,audio-routing =
+ "Headphones", "HPR",
+ "Headphones", "HPL",
+ "Speakers", "SPKR",
+ "Speakers", "SPKL",
+ "Mic Jack", "MICBIAS",
+ "IN34", "Mic Jack";
+
+ nvidia,i2s-controller = <&tegra_i2s1>;
+ nvidia,audio-codec = <&acodec>;
+
+ clocks = <&tegra_car TEGRA124_CLK_PLL_A>,
+ <&tegra_car TEGRA124_CLK_PLL_A_OUT0>,
+ <&tegra_car TEGRA124_CLK_EXTERN1>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sound/snow.txt b/roms/u-boot/doc/device-tree-bindings/sound/snow.txt
new file mode 100644
index 000000000..fa06956e7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sound/snow.txt
@@ -0,0 +1,32 @@
+Audio Binding for Snow boards
+
+Required properties:
+- compatible : Can be one of the following,
+ "google,snow-audio-max98090" or
+ "google,snow-audio-max98091" or
+ "google,snow-audio-max98095"
+- samsung,i2s-controller (deprecated): The phandle of the Samsung I2S controller
+- samsung,audio-codec (deprecated): The phandle of the audio codec
+
+Required sub-nodes:
+
+ - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S
+ controller
+ - 'codec' subnode with a 'sound-dai' property containing list of phandles
+ to the CODEC nodes, first entry must be the phandle of the MAX98090,
+ MAX98091 or MAX98095 CODEC (exact device type is indicated by the compatible
+ string) and the second entry must be the phandle of the HDMI IP block node
+
+Optional:
+- samsung,model: The name of the sound-card
+- codec-enable-gpio : The GPIO used to enable the audio codec
+
+Example:
+
+sound {
+ compatible = "google,snow-audio-max98095";
+
+ samsung,model = "Snow-I2S-MAX98095";
+ samsung,i2s-controller = <&i2s0>;
+ samsung,audio-codec = <&max98095>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt b/roms/u-boot/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
new file mode 100644
index 000000000..8d2888fbe
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
@@ -0,0 +1,56 @@
+Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface
+and Synopsys DesignWare High Performance Synchronous Serial Interface
+
+Required properties:
+- compatible : One of
+ "altr,socfpga-spi",
+ "altr,socfpga-arria10-spi",
+ "canaan,kendryte-k210-spi",
+ "canaan,kendryte-k210-ssi",
+ "intel,stratix10-spi",
+ "intel,agilex-spi",
+ "mscc,ocelot-spi",
+ or "mscc,jaguar2-spi";
+ and one of
+ "snps,dw-apb-ssi-3.20a",
+ "snps,dw-apb-ssi-3.22a",
+ "snps,dw-apb-ssi-3.23",
+ "snps,dw-apb-ssi-4.00a",
+ "snps,dw-apb-ssi-4.01",
+ or "snps,dwc-ssi-1.01a".
+ "snps,dw-apb-ssi" may also be used, but is deprecated in favor of specific
+ version strings.
+- reg : The register base for the controller. For "mscc,<soc>-spi", a second
+ register set is required (named ICPU_CFG:SPI_MST)
+- #address-cells : <1>, as required by generic SPI binding.
+- #size-cells : <0>, also as required by generic SPI binding.
+- clocks : phandles for the clocks, see the description of clock-names below.
+ The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock
+ is optional. If a single clock is specified but no clock-name, it is the
+ "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
+
+Optional properties:
+- clock-names : Contains the names of the clocks:
+ "ssi_clk", for the core clock used to generate the external SPI clock.
+ "pclk", the interface clock, required for register access.
+- cs-gpios : Specifies the gpio pins to be used for chipselects.
+- num-cs : The number of chipselects. If omitted, this will default to 4.
+- reg-io-width : The I/O register width (in bytes) implemented by this
+ device. Supported values are 2 or 4 (the default).
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+ spi@fff00000 {
+ compatible = "altr,socfpga-arria10-spi",
+ "snps,dw-apb-ssi-4.00a", "snps,dw-apb-ssi";
+ reg = <0xfff00000 0x1000>;
+ interrupts = <0 154 4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&spi_m_clk>;
+ num-cs = <2>;
+ cs-gpios = <&gpio0 13 0>,
+ <&gpio0 14 0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/soft-spi.txt b/roms/u-boot/doc/device-tree-bindings/spi/soft-spi.txt
new file mode 100644
index 000000000..dfb506647
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/soft-spi.txt
@@ -0,0 +1,38 @@
+Soft SPI
+
+The soft SPI bus implementation allows the use of GPIO pins to simulate a
+SPI bus. No SPI host is required for this to work. The down-side is that the
+performance will typically be much lower than a real SPI bus.
+
+The soft SPI node requires the following properties:
+
+Mandatory properties:
+compatible: "spi-gpio"
+cs-gpios: GPIOs to use for SPI chip select (output)
+gpio-sck: GPIO to use for SPI clock (output)
+And at least one of:
+gpio-mosi: GPIO to use for SPI MOSI line (output)
+gpio-miso: GPIO to use for SPI MISO line (input)
+
+Optional propertie:
+spi-delay-us: Number of microseconds of delay between each CS transition
+
+The GPIOs should be specified as required by the GPIO controller referenced.
+The first cell holds the phandle of the controller and the second cell
+typically holds the GPIO number.
+
+
+Example:
+
+ soft-spi {
+ compatible = "spi-gpio";
+ cs-gpios = <&gpio 235 0>; /* Y43 */
+ gpio-sck = <&gpio 225 0>; /* Y31 */
+ gpio-mosi = <&gpio 227 0>; /* Y33 */
+ gpio-miso = <&gpio 224 0>; /* Y30 */
+ spi-delay-us = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs@0 {
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-atcspi200.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-atcspi200.txt
new file mode 100644
index 000000000..e67b3425f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-atcspi200.txt
@@ -0,0 +1,37 @@
+Andestech ATCSPI200 SPI controller Device Tree Bindings
+-------------------------------------------------------
+ATCSPI200 is a Serial Peripheral Interface (SPI) controller
+which serves as a SPI master or a SPI slave.
+
+It is often be embedded in AE3XX and AE250 platforms.
+
+Required properties:
+- compatible: has to be "andestech,atcspi200".
+- reg: Base address and size of the controllers memory area.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- interrupts: Property with a value describing the interrupt number.
+- clocks: Clock phandles (see clock bindings for details).
+- spi-max-frequency: Maximum SPI clocking speed of device in Hz.
+
+Optional properties:
+- num-cs: Number of chip selects used.
+
+Example:
+
+ spi: spi@f0b00000 {
+ compatible = "andestech,atcspi200";
+ reg = <0xf0b00000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ num-cs = <1>;
+ clocks = <&spiclk>;
+ interrupts = <3 4>;
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ spi-cpol;
+ spi-cpha;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-ath79.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-ath79.txt
new file mode 100644
index 000000000..3fd9d67a2
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-ath79.txt
@@ -0,0 +1,19 @@
+Binding for Qualcomm Atheros AR7xxx/AR9xxx SPI controller
+
+Required properties:
+- compatible: has to be "qca,<soc-type>-spi", "qca,ar7100-spi" as fallback.
+- reg: Base address and size of the controllers memory area
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+ spi@1f000000 {
+ compatible = "qca,ar9132-spi", "qca,ar7100-spi";
+ reg = <0x1f000000 0x10>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt
new file mode 100644
index 000000000..420ec9529
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt
@@ -0,0 +1,94 @@
+SPI (Serial Peripheral Interface) busses
+
+SPI busses can be described with a node for the SPI master device
+and a set of child nodes for each SPI slave on the bus. For this
+discussion, it is assumed that the system's SPI controller is in
+SPI master mode. This binding does not describe SPI controllers
+in slave mode.
+
+The SPI master node requires the following properties:
+- #address-cells - number of cells required to define a chip select
+ address on the SPI bus.
+- #size-cells - should be zero.
+- compatible - name of SPI bus controller following generic names
+ recommended practice.
+- cs-gpios - (optional) gpios chip select.
+No other properties are required in the SPI bus node. It is assumed
+that a driver for an SPI bus device will understand that it is an SPI bus.
+However, the binding does not attempt to define the specific method for
+assigning chip select numbers. Since SPI chip select configuration is
+flexible and non-standardized, it is left out of this binding with the
+assumption that board specific platform code will be used to manage
+chip selects. Individual drivers can define additional properties to
+support describing the chip select layout.
+
+Optional property:
+- num-cs : total number of chipselects
+
+If cs-gpios is used the number of chip select will automatically increased
+with max(cs-gpios > hw cs)
+
+So if for example the controller has 2 CS lines, and the cs-gpios
+property looks like this:
+
+cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;
+
+Then it should be configured so that num_chipselect = 4 with the
+following mapping:
+
+cs0 : &gpio1 0 0
+cs1 : native
+cs2 : &gpio1 1 0
+cs3 : &gpio1 2 0
+
+SPI slave nodes must be children of the SPI master node and can
+contain the following properties.
+- reg - (required) chip select address of device.
+- compatible - (required) name of SPI device following generic names
+ recommended practice
+- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
+- spi-cpol - (optional) Empty property indicating device requires
+ inverse clock polarity (CPOL) mode
+- spi-cpha - (optional) Empty property indicating device requires
+ shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device requires
+ chip select active high
+- spi-3wire - (optional) Empty property indicating device requires
+ 3-wire mode.
+- spi-tx-bus-width - (optional) The bus width(number of data wires) that
+ used for MOSI. Defaults to 1 if not present.
+- spi-rx-bus-width - (optional) The bus width(number of data wires) that
+ used for MISO. Defaults to 1 if not present.
+- spi-half-duplex - (optional) Indicates that the SPI bus should wait for
+ a header byte before reading data from the slave.
+
+Some SPI controllers and devices support Dual and Quad SPI transfer mode.
+It allows data in SPI system transferred in 2 wires(DUAL) or 4 wires(QUAD).
+Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
+only 1(SINGLE), 2(DUAL) and 4(QUAD).
+Dual/Quad mode is not allowed when 3-wire mode is used.
+
+If a gpio chipselect is used for the SPI slave the gpio number will be passed
+via the cs_gpio
+
+SPI example for an MPC5200 SPI bus:
+ spi@f00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+ reg = <0xf00 0x20>;
+ interrupts = <2 13 0 2 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+
+ codec@1 {
+ compatible = "ti,tlv320aic26";
+ spi-max-frequency = <100000>;
+ reg = <1>;
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-cadence.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-cadence.txt
new file mode 100644
index 000000000..69e02c1c4
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -0,0 +1,31 @@
+Cadence QSPI controller device tree bindings
+--------------------------------------------
+
+Required properties:
+- compatible : should be "cdns,qspi-nor"
+- reg : 1.Physical base address and size of SPI registers map.
+ 2. Physical base address & size of NOR Flash.
+- clocks : Clock phandles (see clock bindings for details).
+- cdns,fifo-depth : Size of the data FIFO in words.
+- cdns,fifo-width : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
+- status : enable in requried dts.
+
+connected flash properties
+--------------------------
+
+- spi-max-frequency : Max supported spi frequency.
+- page-size : Flash page size.
+- block-size : Flash memory block size.
+- cdns,tshsl-ns : Added delay in master reference clocks (ref_clk) for
+ the length that the master mode chip select outputs
+ are de-asserted between transactions.
+- cdns,tsd2d-ns : Delay in master reference clocks (ref_clk) between one
+ chip select being de-activated and the activation of
+ another.
+- cdns,tchsh-ns : Delay in master reference clocks between last bit of
+ current transaction and de-asserting the device chip
+ select (n_ss_out).
+- cdns,tslch-ns : Delay in master reference clocks between setting
+ n_ss_out low and first bit transfer
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-mcf-dspi.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-mcf-dspi.txt
new file mode 100644
index 000000000..4684d7846
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-mcf-dspi.txt
@@ -0,0 +1,34 @@
+Freescale ColdFire DSPI controller
+
+Required properties:
+- compatible : "fsl,mcf-dspi"
+- #address-cells: <1>, as required by generic SPI binding
+- #size-cells: <0>, also as required by generic SPI binding
+- reg : offset and length of the register set for the device
+
+Optional properties:
+- spi-max-frequency : max supported spi frequency
+- num-cs : the number of the chipselect signals
+- spi-mode: spi motorola mode, 0 to 3
+- ctar-params: CTAR0 to 7 register configuration, as an array
+ of 8 integer fields for each register, where each register
+ is defined as: <fmsz, pcssck, pasc, pdt, cssck, asc, dt, br>.
+- fsl,spi-cs-sck-delay: a delay in nanoseconds between activating chip
+ select and the start of clock signal, at the start of a transfer.
+- fsl,spi-sck-cs-delay: a delay in nanoseconds between stopping the clock
+ signal and deactivating chip select, at the end of a transfer.
+
+Example:
+
+dspi0: dspi@fc05c000 {
+ compatible = "fsl,mcf-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfc05c000 0x100>;
+ spi-max-frequency = <50000000>;
+ num-cs = <4>;
+ spi-mode = <0>;
+ ctar-fields = <7, 0, 0, 0, 0, 0, 1, 6>,
+ <7, 0, 0, 0, 0, 0, 1, 6>,
+ <7, 0, 0, 0, 0, 0, 1, 6>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-qup.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-qup.txt
new file mode 100644
index 000000000..3697df263
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-qup.txt
@@ -0,0 +1,33 @@
+Qualcomm QUP SPI controller Device Tree Bindings
+-------------------------------------------
+
+Required properties:
+- compatible : Should be "qcom,spi-qup-v1.1.1", "qcom,spi-qup-v2.1.1"
+ or "qcom,spi-qup-v2.2.1"
+- reg : Physical base address and size of SPI registers map.
+- clock : Clock phandle (see clock bindings for details).
+- #address-cells : Number of cells required to define a chip select
+ address on the SPI bus. Should be set to 1.
+- #size-cells : Should be zero.
+- pinctrl-names : Must be "default"
+- pinctrl-n : At least one pinctrl phandle
+- cs-gpios : Should specify GPIOs used for chipselects.
+ The gpios will be referred to as reg = <index> in the
+ SPI child nodes.
+
+Optional properties:
+- num-cs : total number of chipselects
+
+Example:
+
+ blsp1_spi1: spi@78b5000 {
+ compatible = "qcom,spi-qup-v2.2.1";
+ reg = <0x78b5000 0x600>;
+ clock = <&gcc 23>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "spi";
+ pinctrl-0 = <&blsp_spi0>;
+ num-cs = <2>;
+ cs-gpios = <&soc_gpios 54 GPIO_ACTIVE_HIGH>, <&soc_gpios 4 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-stm32-qspi.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-stm32-qspi.txt
new file mode 100644
index 000000000..adeeb63e8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-stm32-qspi.txt
@@ -0,0 +1,44 @@
+* STMicroelectronics Quad Serial Peripheral Interface(QSPI)
+
+Required properties:
+- compatible: should be "st,stm32f469-qspi"
+- reg: the first contains the register location and length.
+ the second contains the memory mapping address and length
+- reg-names: should contain the reg names "qspi" "qspi_mm"
+- interrupts: should contain the interrupt for the device
+- clocks: the phandle of the clock needed by the QSPI controller
+- A pinctrl must be defined to set pins in mode of operation for QSPI transfer
+
+Optional properties:
+- resets: must contain the phandle to the reset controller.
+
+A spi flash (NOR/NAND) must be a child of spi node and could have some
+properties. Also see jedec,spi-nor.txt.
+
+Required properties:
+- reg: chip-Select number (QSPI controller may connect 2 flashes)
+- spi-max-frequency: max frequency of spi bus
+
+Optional property:
+- spi-rx-bus-width: see ./spi-bus.txt for the description
+
+Example:
+
+qspi: spi@a0001000 {
+ compatible = "st,stm32f469-qspi";
+ reg = <0xa0001000 0x1000>, <0x90000000 0x10000000>;
+ reg-names = "qspi", "qspi_mm";
+ interrupts = <91>;
+ resets = <&rcc STM32F4_AHB3_RESET(QSPI)>;
+ clocks = <&rcc 0 STM32F4_AHB3_CLOCK(QSPI)>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <108000000>;
+ ...
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq-qspi.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq-qspi.txt
new file mode 100644
index 000000000..47472fdb8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq-qspi.txt
@@ -0,0 +1,26 @@
+Xilinx Zynq QSPI controller Device Tree Bindings
+-------------------------------------------------
+
+Required properties:
+- compatible : Should be "xlnx,zynq-qspi-1.0".
+- reg : Physical base address and size of QSPI registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names : List of input clock names - "ref_clk", "pclk"
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+
+Optional properties:
+- num-cs : Number of chip selects used.
+
+Example:
+ qspi@e000d000 {
+ compatible = "xlnx,zynq-qspi-1.0";
+ clock-names = "ref_clk", "pclk";
+ clocks = <&clkc 10>, <&clkc 43>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 19 4>;
+ num-cs = <1>;
+ reg = <0xe000d000 0x1000>;
+ } ;
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq.txt
new file mode 100644
index 000000000..cb2945789
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi-zynq.txt
@@ -0,0 +1,32 @@
+Cadence SPI controller Device Tree Bindings
+-------------------------------------------
+
+Required properties:
+- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6".
+- reg : Physical base address and size of SPI registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names : List of input clock names - "ref_clk", "pclk"
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+- spi-max-frequency : Maximum SPI clocking speed of device in Hz
+
+Optional properties:
+- num-cs : Number of chip selects used.
+ If a decoder is used, this will be the number of
+ chip selects after the decoder.
+- is-decoded-cs : Flag to indicate whether decoder is used or not.
+
+Example:
+
+ spi@e0007000 {
+ compatible = "xlnx,zynq-spi-r1p6";
+ clock-names = "ref_clk", "pclk";
+ clocks = <&clkc 26>, <&clkc 35>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 49 4>;
+ num-cs = <4>;
+ is-decoded-cs = <0>;
+ reg = <0xe0007000 0x1000>;
+ } ;
diff --git a/roms/u-boot/doc/device-tree-bindings/spi/spi_altera.txt b/roms/u-boot/doc/device-tree-bindings/spi/spi_altera.txt
new file mode 100644
index 000000000..de4fae831
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spi/spi_altera.txt
@@ -0,0 +1,4 @@
+Altera SPI
+
+Required properties:
+- compatible : should be "altr,spi-1.0".
diff --git a/roms/u-boot/doc/device-tree-bindings/spmi/spmi-msm.txt b/roms/u-boot/doc/device-tree-bindings/spmi/spmi-msm.txt
new file mode 100644
index 000000000..ae47673b7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spmi/spmi-msm.txt
@@ -0,0 +1,26 @@
+Qualcomm SPMI arbiter/bus driver
+
+This is bus driver for Qualcomm chips that use SPMI to communicate with PMICs.
+
+Required properties:
+- compatible: "qcom,spmi-pmic-arb"
+- reg: Register block adresses and sizes for various parts of device:
+ 1) PMIC arbiter channel mapping base (PMIC_ARB_REG_CHNLn)
+ 2) SPMI write command (master) registers (PMIC_ARB_CORE_SW_DEC_CHANNELS)
+ 3) SPMI read command (observer) registers (PMIC_ARB_CORE_REGISTERS_OBS)
+
+Optional properties (if not set by parent):
+- #address-cells: 0x1 - childs slave ID address
+- #size-cells: 0x1
+
+All PMICs should be placed as a child nodes of bus arbiter.
+Automatic detection of childs is currently not supported.
+
+Example:
+
+spmi@200f000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0x200f800 0x200 0x2400000 0x400000 0x2c00000 0x400000>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/spmi/spmi-sandbox.txt b/roms/u-boot/doc/device-tree-bindings/spmi/spmi-sandbox.txt
new file mode 100644
index 000000000..8569a1a84
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/spmi/spmi-sandbox.txt
@@ -0,0 +1,31 @@
+Sandbox SPMI emulated arbiter.
+
+This is bus driver for Sandbox. It includes part of emulated pm8916 pmic.
+
+Required properties:
+- compatible: "sandbox,spmi"
+- #address-cells: 0x1 - childs slave ID address
+- #size-cells: 0x1
+
+Example:
+
+spmi: spmi@0 {
+ compatible = "sandbox,spmi";
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ pm8916@0 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x0 0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ spmi_gpios: gpios@c000 {
+ compatible = "qcom,pm8916-gpio";
+ reg = <0xc000 0x400>;
+ gpio-controller;
+ gpio-count = <4>;
+ #gpio-cells = <2>;
+ gpio-bank-name="spmi";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sysinfo/gdsys,sysinfo_gazerbeam.txt b/roms/u-boot/doc/device-tree-bindings/sysinfo/gdsys,sysinfo_gazerbeam.txt
new file mode 100644
index 000000000..f70652d3c
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysinfo/gdsys,sysinfo_gazerbeam.txt
@@ -0,0 +1,46 @@
+gdsys Gazerbeam sysinfo driver
+
+This driver provides capabilities to access the gdsys Gazerbeam board's device
+information. Furthermore, phandles to some internal devices are provided for
+the board files.
+
+Required properties:
+- compatible: should be "gdsys,sysinfo-gazerbeam"
+- csb: phandle to the board's coherent system bus (CSB) device node
+- rxaui[0-3]: phandles to the rxaui control device nodes
+- fpga[0-1]: phandles to the board's gdsys FPGA device nodes
+- ioep[0-1]: phandles to the board's IO endpoint device nodes
+- ver-gpios: GPIO list to read the hardware version from
+- var-gpios: GPIO list to read the hardware variant information from
+- reset-gpios: GPIO list for the board's reset GPIOs
+
+Example:
+
+
+sysinfo {
+ compatible = "gdsys,sysinfo-gazerbeam";
+ csb = <&board_soc>;
+ serdes = <&SERDES>;
+ rxaui0 = <&RXAUI0>;
+ rxaui1 = <&RXAUI1>;
+ rxaui2 = <&RXAUI2>;
+ rxaui3 = <&RXAUI3>;
+ fpga0 = <&FPGA0>;
+ fpga1 = <&FPGA1>;
+ ioep0 = <&IOEP0>;
+ ioep1 = <&IOEP1>;
+
+ ver-gpios = <&PPCPCA 12 0
+ &PPCPCA 13 0
+ &PPCPCA 14 0
+ &PPCPCA 15 0>;
+
+ /* MC2/SC-Board */
+ var-gpios-mc2 = <&GPIO_VB0 0 0 /* VAR-MC_SC */
+ &GPIO_VB0 11 0>; /* VAR-CON */
+ /* MC4-Board */
+ var-gpios-mc4 = <&GPIO_VB1 0 0 /* VAR-MC_SC */
+ &GPIO_VB1 11 0>; /* VAR-CON */
+
+ reset-gpios = <&gpio0 1 0 &gpio0 2 1>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sysinfo/google,coral.txt b/roms/u-boot/doc/device-tree-bindings/sysinfo/google,coral.txt
new file mode 100644
index 000000000..d8a1a7968
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysinfo/google,coral.txt
@@ -0,0 +1,37 @@
+Google Coral sysinfo information
+================================
+
+This binding allows information about the board to be described. It includes
+the SMBIOS binding as well.
+
+Required properties:
+
+ - compatible: "google,coral"
+ - recovery-gpios: GPIO to use for recovery button (-1 if none)
+ - wite-protect-gpios: GPIO to use for write-protect screw
+ - phase-enforce-gpios: GPIO to indicate the board is in final ship mode
+ - memconfig-gpios: 4 GPIOs to use to read memory config (as base2 int)
+
+Optional properties:
+ - skuconfig-gpios: 2 GPIOs to use to read SKU ID. If not present, the
+ Chromium OS EC SKU_ID is used instead
+
+Example:
+
+board: board {
+ compatible = "google,coral";
+ recovery-gpios = <&gpio_nw (-1) GPIO_ACTIVE_LOW>;
+ write-protect-gpios = <&gpio_nw GPIO_75 GPIO_ACTIVE_HIGH>;
+ phase-enforce-gpios = <&gpio_n GPIO_10 GPIO_ACTIVE_HIGH>;
+ memconfig-gpios = <&gpio_nw GPIO_101 GPIO_ACTIVE_HIGH
+ &gpio_nw GPIO_102 GPIO_ACTIVE_HIGH
+ &gpio_n GPIO_38 GPIO_ACTIVE_HIGH
+ &gpio_n GPIO_45 GPIO_ACTIVE_HIGH>;
+
+ /*
+ * This is used for reef only:
+ *
+ * skuconfig-gpios = <&gpio_nw GPIO_16 GPIO_ACTIVE_HIGH
+ * &gpio_nw GPIO_17 GPIO_ACTIVE_HIGH>;
+ */
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/sysinfo/gpio-sysinfo.txt b/roms/u-boot/doc/device-tree-bindings/sysinfo/gpio-sysinfo.txt
new file mode 100644
index 000000000..b5739d94e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysinfo/gpio-sysinfo.txt
@@ -0,0 +1,37 @@
+GPIO-based Sysinfo device
+
+This binding describes several GPIOs which specify a board revision. Each GPIO
+forms a digit in a ternary revision number. This revision is then mapped to a
+name using the revisions and names properties.
+
+Each GPIO may be floating, pulled-up, or pulled-down, mapping to digits 2, 1,
+and 0, respectively. The first GPIO forms the least-significant digit of the
+revision. For example, consider the property
+
+ gpios = <&gpio 0>, <&gpio 1>, <&gpio 2>;
+
+If GPIO 0 is pulled-up, GPIO 1 is pulled-down, and GPIO 2 is floating, then the
+revision would be
+
+ 0t201 = 2*9 + 0*3 + 1*3 = 19
+
+If instead GPIO 0 is floating, GPIO 1 is pulled-up, and GPIO 2 is pulled-down,
+then the revision would be
+
+ 0t012 = 0*9 + 1*3 + 2*1 = 5
+
+Required properties:
+- compatible: should be "gpio-sysinfo".
+- gpios: should be a list of gpios forming the revision number,
+ least-significant-digit first
+- revisions: a list of known revisions; any revisions not present will have the
+ name "unknown"
+- names: the name of each revision in revisions
+
+Example:
+sysinfo {
+ compatible = "gpio-sysinfo";
+ gpios = <&gpio_a 15>, <&gpio_a 16>, <&gpio_a 17>;
+ revisions = <19>, <5>;
+ names = "rev_a", "foo";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sysinfo/smbios.txt b/roms/u-boot/doc/device-tree-bindings/sysinfo/smbios.txt
new file mode 100644
index 000000000..b52232280
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysinfo/smbios.txt
@@ -0,0 +1,77 @@
+SMBIOS sysinfo information
+==========================
+
+This binding allows the values for the SMBIOS tables to be specified in the
+devicetree, as below.
+
+Required properties:
+
+ - compatible: "u-boot,smbios" or any other string depending on your board
+
+This driver allows providing board-specific features such as power control
+GPIOs. In addition, the SMBIOS values can be specified in the device tree,
+as below:
+
+An optional 'smbios' subnode can be used to provide these properties. Within
+that, the properties are broken down by table type, as in the System Management
+BIOS (Basic Input/Output System) Specification.
+
+Available subnodes for each table type are:
+
+ - 1 : system
+ - 2 : baseboard
+ - 3 : chassis
+
+Within each subnode the following tables are recognised:
+
+"system" subnode optional properties:
+
+ - manufacturer: Product manufacturer for system
+ - product: Product name
+ - version: Product version string
+ - serial: Serial number for system (note that this can be overridden by
+ the serial# environment variable)
+ - sku: Product SKU (Stock-Keeping Unit)
+ - family: Product family
+
+"baseboard" subnode optional properties:
+
+ - manufacturer: Product manufacturer for baseboard
+ - product: Product name
+ - asset-tag: Asset tag for the motherboard, sometimes used in organisations
+ to track devices
+
+"chassis" subnode optional properties:
+
+ - manufacturer: Product manufacturer for chassis
+
+
+Example:
+
+sysinfo {
+ compatible = "sandbox,sysinfo-sandbox";
+
+ smbios {
+ /* Type 1 table */
+ system {
+ manufacturer = "Google";
+ product = "Coral";
+ version = "rev2";
+ serial = "123456789";
+ sku = "sku3";
+ family = "Google_Coral";
+ };
+
+ /* Type 2 table */
+ baseboard {
+ manufacturer = "Google";
+ product = "Coral";
+ asset-tag = "ABC123";
+ };
+
+ /* Type 3 table */
+ chassis {
+ manufacturer = "Google";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sysinfo/sysinfo.txt b/roms/u-boot/doc/device-tree-bindings/sysinfo/sysinfo.txt
new file mode 100644
index 000000000..9445031b1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysinfo/sysinfo.txt
@@ -0,0 +1,19 @@
+Sysinfo
+=======
+
+This provides capabilities to access information about a board/system, for
+use by drivers.
+
+Required properties:
+
+ - compatible: any suitable string where the driver is in the UCLASS_SYSINFO
+ class
+
+See also smbios.txt
+
+
+Example
+
+sysinfo {
+ compatible = "sandbox,sysinfo-sandbox";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt b/roms/u-boot/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt
new file mode 100644
index 000000000..02704c648
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt
@@ -0,0 +1,29 @@
+Texas Instruments TI SCI System Reset Controller
+================================================
+
+Some TI SoCs contain a system controller (like the SYSFW, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI SCI [1].
+
+[1] http://processors.wiki.ti.com/index.php/TISCI
+
+System Reset Controller Node
+============================
+The sysreset controller node represents the reset for the overall SoC
+which is managed by the SYSFW. Because this relies on the TI SCI protocol
+to communicate with the SYSFW it must be a child of the sysfw node.
+
+Required Properties:
+--------------------
+ - compatible: Must be "ti,sci-sysreset"
+
+Example (AM65x):
+----------------
+ sysfw: sysfw {
+ compatible = "ti,am654-system-controller";
+ ...
+ k3_sysreset: sysreset-controller {
+ compatible = "ti,sci-sysreset";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/thermal/rockchip-thermal.txt b/roms/u-boot/doc/device-tree-bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000000000..ef802de49
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,68 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+ region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+ the peripheral clock.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the name "tsadc-apb".
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
+- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
+- rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW
+ 1:HIGH.
+
+Exiample:
+tsadc: tsadc@ff280000 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff280000 0x100>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ resets = <&cru SRST_TSADC>;
+ reset-names = "tsadc-apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&otp_out>;
+ #thermal-sensor-cells = <1>;
+ rockchip,hw-tshut-temp = <95000>;
+ rockchip,hw-tshut-mode = <0>;
+ rockchip,hw-tshut-polarity = <0>;
+};
+
+Example: referring to thermal sensors:
+thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&tsadc 1>;
+
+ trips {
+ cpu_alert0: cpu_alert {
+ temperature = <70000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <90000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/thermal/ti_soc_thermal.txt b/roms/u-boot/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
new file mode 100644
index 000000000..b4e88c2d1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/thermal/ti_soc_thermal.txt
@@ -0,0 +1,35 @@
+* Texas Instrument dra7xx SCM bandgap bindings
+
+In the System Control Module, SoC supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - "ti,dra752-bandgap"
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+- regs : this is specific to each bandgap version, because
+the mapping may change from soc to soc, apart from depending
+on available features.
+
+Optional:
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
+
+Example:
+bandgap {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c
+ 0x4a002564 0x8
+ 0x4a002574 0x50>;
+ compatible = "ti,dra752-bandgap";
+ interrupts = <0 126 4>; /* talert */
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/timer/altera_timer.txt b/roms/u-boot/doc/device-tree-bindings/timer/altera_timer.txt
new file mode 100644
index 000000000..904a5846d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/timer/altera_timer.txt
@@ -0,0 +1,19 @@
+Altera Timer
+
+Required properties:
+
+- compatible : should be "altr,timer-1.0"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-parent: phandle of the interrupt controller
+- interrupts : Should contain the timer interrupt number
+- clock-frequency : The frequency of the clock that drives the counter, in Hz.
+
+Example:
+
+timer {
+ compatible = "altr,timer-1.0";
+ reg = <0x00400000 0x00000020>;
+ interrupt-parent = <&cpu>;
+ interrupts = <11>;
+ clock-frequency = <125000000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/timer/arc_timer.txt b/roms/u-boot/doc/device-tree-bindings/timer/arc_timer.txt
new file mode 100644
index 000000000..5493b21d2
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/timer/arc_timer.txt
@@ -0,0 +1,24 @@
+ARC Timer
+
+Required properties:
+
+- compatible : should be "snps,arc-timer".
+- reg : Specifies timer ID, could be either 0 or 1.
+- clocks : Specifies clocks that drives the counter.
+
+Examples:
+
+timer@0 {
+ compatible = "snps,arc-timer";
+ clocks = <&core_clk>;
+ reg = <0>;
+};
+
+timer@1 {
+ compatible = "snps,arc-timer";
+ clocks = <&core_clk>;
+ reg = <1>;
+};
+
+NOTE: if you specify both timers, clocks always should be the same
+as each timer is driven by the same core clock.
diff --git a/roms/u-boot/doc/device-tree-bindings/timer/atcpit100_timer.txt b/roms/u-boot/doc/device-tree-bindings/timer/atcpit100_timer.txt
new file mode 100644
index 000000000..620814e94
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/timer/atcpit100_timer.txt
@@ -0,0 +1,31 @@
+Andestech ATCPIT100 timer
+------------------------------------------------------------------
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX, AE250 platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible : Should be "andestech,atcpit100"
+- reg : Address and length of the register set
+- interrupts : Reference to the timer interrupt
+- clock-frequency : The rate in HZ in input of the Andestech ATCPIT100 timer
+
+Examples:
+
+timer0: timer@f0400000 {
+ compatible = "andestech,atcpit100";
+ reg = <0xf0400000 0x1000>;
+ interrupts = <2 4>;
+ clock-frequency = <30000000>;
+}:
diff --git a/roms/u-boot/doc/device-tree-bindings/timer/fsl,mpc83xx-timer.txt b/roms/u-boot/doc/device-tree-bindings/timer/fsl,mpc83xx-timer.txt
new file mode 100644
index 000000000..608d24110
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/timer/fsl,mpc83xx-timer.txt
@@ -0,0 +1,21 @@
+MPC83xx timer devices
+
+MPC83xx SoCs offer a decrementer interrupt that can be used to implement delay
+functionality, and periodically triggered actions.
+
+Required properties:
+- compatible: must be "fsl,mpc83xx-timer"
+- clocks: must be a reference to the system's CSB (coherent system bus) clock,
+ provided by one of the "fsl,mpc83xx-clk" devices
+
+Example:
+
+socclocks: clocks {
+ compatible = "fsl,mpc832x-clk";
+ #clock-cells = <1>;
+};
+
+timer {
+ compatible = "fsl,mpc83xx-timer";
+ clocks = <&socclocks MPC83XX_CLK_CSB>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/timer/sandbox_timer.txt b/roms/u-boot/doc/device-tree-bindings/timer/sandbox_timer.txt
new file mode 100644
index 000000000..3e113f83f
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/timer/sandbox_timer.txt
@@ -0,0 +1,7 @@
+Sandbox timer
+
+The sandbox timer device is an emulated device which gets time from
+host os.
+
+Required properties:
+ compatible: "sandbox,timer"
diff --git a/roms/u-boot/doc/device-tree-bindings/tpm2/sandbox.txt b/roms/u-boot/doc/device-tree-bindings/tpm2/sandbox.txt
new file mode 100644
index 000000000..3d0f727cc
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/tpm2/sandbox.txt
@@ -0,0 +1,11 @@
+Sandbox TPMv2.0 bindings
+------------------------
+
+Required properties:
+- compatible : Should be "sandbox,tpm2"
+
+Example:
+
+ tpm {
+ compatible = "sandbox,tpm2";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt b/roms/u-boot/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
new file mode 100644
index 000000000..3a2ee4bd1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
@@ -0,0 +1,18 @@
+ST33TPHF20 SPI TPMv2.0 bindings
+-------------------------------
+
+Required properties:
+- compatible : Should be "tcg,tpm_tis-spi"
+- reg : SPI Chip select
+
+Optional properties:
+- gpio-reset : Reset GPIO (if not connected to the SoC reset line)
+- spi-max-frequency : See spi-bus.txt
+
+Example:
+
+ tpm@1 {
+ compatible = "tcg,tpm_tis-spi";
+ reg = <1>;
+ spi-max-frequency = <10000000>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/dwc2.txt b/roms/u-boot/doc/device-tree-bindings/usb/dwc2.txt
new file mode 100644
index 000000000..61493f7cb
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/dwc2.txt
@@ -0,0 +1,58 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-----------------------------------------------------
+
+Required properties:
+- compatible : One of:
+ - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+ - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
+ - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
+ - "rockchip,px30-usb", "rockchip,rk3066-usb", "snps,dwc2": for px30 Soc;
+ - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
+ - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
+ - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
+ - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
+ - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic Meson8 SoCs;
+ - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
+ - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
+ - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
+ - snps,dwc2: A generic DWC2 USB controller with default parameters.
+ - "st,stm32f4x9-fsotg": The DWC2 USB FS/HS controller instance in STM32F4x9 SoCs
+ configured in FS mode;
+ - "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs
+ configured in HS mode;
+ - "st,stm32f7-hsotg": The DWC2 USB HS controller instance in STM32F7 SoCs
+ configured in HS mode;
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+- clocks: clock provider specifier
+- clock-names: shall be "otg"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Optional properties:
+- phys: phy provider specifier
+- phy-names: shall be "usb2-phy"
+Refer to phy/phy-bindings.txt for generic phy consumer properties
+- dr_mode: shall be one of "host", "peripheral" and "otg"
+ Refer to usb/generic.txt
+- g-rx-fifo-size: size of rx fifo size in gadget mode.
+- g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
+- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode.
+- usb33d-supply: external VBUS and ID sensing comparators supply, in order to
+ perform OTG operation, used on STM32MP1 SoCs.
+- u-boot,force-b-session-valid: force B-peripheral session instead of relying on
+ VBUS sensing (only valid when dr_mode = "peripheral" and for u-boot).
+
+Deprecated properties:
+- g-use-dma: gadget DMA mode is automatically detected
+
+Example:
+
+ usb@101c0000 {
+ compatible = "ralink,rt3050-usb, snps,dwc2";
+ reg = <0x101c0000 40000>;
+ interrupts = <18>;
+ clocks = <&usb_otg_ahb_clk>;
+ clock-names = "otg";
+ phys = <&usbphy>;
+ phy-names = "usb2-phy";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/dwc3-st.txt b/roms/u-boot/doc/device-tree-bindings/usb/dwc3-st.txt
new file mode 100644
index 000000000..a26a1397e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/dwc3-st.txt
@@ -0,0 +1,60 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be "st,stih407-dwc3"
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be "reg-glue" and "syscfg-reg"
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be "powerdown" and "softreset"
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names : A pinctrl state named "default" must be defined
+
+ - pinctrl-0 : Pin control group
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below.
+
+NB: The dr_mode property is NOT optional for this driver, as the default value
+is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st are
+either "host" or "device".
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = "disabled";
+ compatible = "st,stih407-dwc3";
+ reg = <0x08f94000 0x1000>, <0x110 0x4>;
+ reg-names = "reg-glue", "syscfg-reg";
+ st,syscfg = <&syscfg_core>;
+ resets = <&powerdown STIH407_USB3_POWERDOWN>,
+ <&softreset STIH407_MIPHY2_SOFTRESET>;
+ reset-names = "powerdown", "softreset";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb3>;
+ ranges;
+
+ dwc3: dwc3@9900000 {
+ compatible = "snps,dwc3";
+ reg = <0x09900000 0x100000>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_NONE>;
+ dr_mode = "host";
+ phy-names = "usb2-phy", "usb3-phy";
+ phys = <&usb2_picophy2>, <&phy_port2 PHY_TYPE_USB3>;
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/ehci-msm.txt b/roms/u-boot/doc/device-tree-bindings/usb/ehci-msm.txt
new file mode 100644
index 000000000..205bb0722
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/ehci-msm.txt
@@ -0,0 +1,10 @@
+Chipidea EHCI controller (part of OTG controller) used on Qualcomm devices.
+
+Required properties:
+- compatible: must be "qcom,ehci-host"
+- reg: start address and size of the registers
+
+ehci@78d9000 {
+ compatible = "qcom,ehci-host";
+ reg = <0x78d9000 0x400>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/generic.txt b/roms/u-boot/doc/device-tree-bindings/usb/generic.txt
new file mode 100644
index 000000000..a02a198df
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/generic.txt
@@ -0,0 +1,31 @@
+Generic USB Properties
+
+Optional properties:
+ - maximum-speed: tells USB controllers we want to work up to a certain
+ speed. Valid arguments are "super-speed-plus",
+ "super-speed", "high-speed", "full-speed" and
+ "low-speed". In case this isn't passed via DT, USB
+ controllers should default to their maximum HW
+ capability.
+ - dr_mode: tells Dual-Role USB controllers that we want to work on a
+ particular mode. Valid arguments are "host",
+ "peripheral" and "otg". In case this attribute isn't
+ passed via DT, USB DRD controllers should default to
+ OTG.
+ - phy_type: tells USB controllers that we want to configure the core to support
+ a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
+ selected. Valid arguments are "utmi" and "utmi_wide".
+ In case this isn't passed via DT, USB controllers should
+ default to HW capability.
+
+This is an attribute to a USB controller such as:
+
+dwc3@4a030000 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4a030000 0xcfff>;
+ interrupts = <0 92 4>
+ usb-phy = <&usb2_phy>, <&usb3,phy>;
+ maximum-speed = "super-speed";
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/marvell.xhci-usb.txt b/roms/u-boot/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000000000..e042d1b96
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,28 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+ - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+ - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+ register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: phandle to system controller clock driving this unit
+ - vbus-supply : If present, specifies the fixed regulator to be turned on
+ for providing power to the USB VBUS rail.
+
+Example:
+ cpm_usb3_0: usb3@500000 {
+ compatible = "marvell,armada-8k-xhci",
+ "generic-xhci";
+ reg = <0x500000 0x4000>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 22>;
+ vbus-supply = <&reg_usb3h0_vbus>;
+ status = "disabled";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt b/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
new file mode 100644
index 000000000..2a298f7b1
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
@@ -0,0 +1,44 @@
+MediaTek xHCI
+
+The device node for USB3 host controller on MediaTek SoCs.
+
+Required properties:
+ - compatible : should be "mediatek,mtk-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
+ - power-domains : a phandle to USB power domain node to control USB's
+ MTCMOS
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "sys_ck": controller clock used by normal mode,
+ the following ones are optional:
+ "ref_ck": reference clock used by low power mode etc,
+ "mcu_ck": mcu_bus clock for register access,
+ "dma_ck": dma_bus clock for data transfer by DMA,
+ "xhci_ck": controller clock
+
+ - phys : list of all the USB PHYs on this HCD
+ - phy-names: name specifier for the USB PHY
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
+ bit1 for u3port1, ... etc;
+ - mediatek,u2p-dis-msk : mask to disable u2ports, bit0 for u2port0,
+ bit1 for u2port1, ... etc;
+
+Example:
+xhci: usb@1a0c0000 {
+ compatible = "mediatek,mt7629-xhci", "mediatek,mtk-xhci";
+ reg = <0x1a0c0000 0x1000>, <0x1a0c3e00 0x0100>;
+ reg-names = "mac", "ippc";
+ power-domains = <&scpsys MT7629_POWER_DOMAIN_HIF1>;
+ clocks = <&ssusbsys CLK_SSUSB_SYS_EN>, <&ssusbsys CLK_SSUSB_REF_EN>,
+ <&ssusbsys CLK_SSUSB_MCU_EN>, <&ssusbsys CLK_SSUSB_DMA_EN>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ status = "disabled";
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtu3.txt b/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtu3.txt
new file mode 100644
index 000000000..ab877bfa8
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/usb/mediatek,mtu3.txt
@@ -0,0 +1,79 @@
+The device node for Mediatek USB3 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,<soc-model>-mtu3", "mediatek,mtu3",
+ soc-model is the name of SoC, such as mt8512 etc,
+ when using "mediatek,mtu3" compatible string, you need SoC specific
+ ones in addition, one of:
+ - "mediatek,mt8512-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be
+ - "ippc" : IP Port Control
+ - power-domains : a phandle to USB power domain node to control USB's MTCMOS
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller,
+ the following clocks are optional:
+ "ref_ck", "mcu_ck", "dma_ck" and "xhci_ck";
+ - phys : list of all the USB PHYs on this HCD
+ - #address-cells, #size-cells : used for sub-nodes with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Optional properties:
+ - vusb33-supply : regulator of USB AVDD3.3v
+ - vbus-supply : regulator of VBUS 5v, needed when supports host mode.
+
+Sub-nodes:
+Required properties:
+ - compatible : should be "mediatek,ssusb"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be
+ - "mac" : SSUSB MAC, include xHCI and device
+ - interrupts : interrupt used by xHCI or device
+ - dr_mode : should be one of "host" or "peripheral",
+ see : usb/generic.txt
+
+Optional properties:
+ - pinctrl-names : a pinctrl state named "default" is optional
+ - pinctrl-0 : pin control group
+ See: pinctrl/pinctrl-bindings.txt
+
+ - device mode:
+ - maximum-speed : valid arguments are "full-speed", "high-speed",
+ "super-speed" and "super-speed-plus",
+ see: usb/generic.txt
+ - mediatek,force-vbus : force vbus as valid by SW
+
+ - host mode (dr_mode is "host"):
+ - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
+ bit1 for u3port1, ... etc;
+
+Example:
+usb3: usb@11213e00 {
+ compatible = "mediatek,mt8512-mtu3", "mediatek,mtu3";
+ reg = <0x11213e00 0x0100>;
+ reg-names = "ippc";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u2port1 PHY_TYPE_USB2>;
+ power-domains = <&scpsys MT8512_POWER_DOMAIN_USB>;
+ clocks = <&infracfg CLK_INFRA_USB_SYS>,
+ <&topckgen CLK_TOP_SSUSB_TOP_CK_EN>,
+ <&infracfg CLK_INFRA_ICUSB>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck";
+ vusb33-supply = <reg_3p3v>;
+ vbus-supply = <&usb_p0_vbus>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ ssusb: usb@11210000 {
+ compatible = "mediatek,ssusb";
+ reg = <0x11210000 0x3e00>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_LOW>;
+ reg-names = "mac";
+ dr_mode = "peripheral";
+ maximum-speed = "high-speed";
+ status = "disabled";
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt b/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt
new file mode 100644
index 000000000..5282d44ac
--- /dev/null
+++ b/roms/u-boot/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.
diff --git a/roms/u-boot/doc/device-tree-bindings/video/atmel-hlcdc.txt b/roms/u-boot/doc/device-tree-bindings/video/atmel-hlcdc.txt
new file mode 100644
index 000000000..b378cbf9d
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/atmel-hlcdc.txt
@@ -0,0 +1,42 @@
+Atmel HLCDC Framebuffer
+-----------------------------------------------------
+Required properties:
+- compatible :
+ "atmel,sama5d2-hlcdc", "atmel,at91sam9x5-hlcdc".
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks: phandles to input clocks.
+- atmel,vl-bpix: Bits per pixel.
+- atmel,output-mode: LCD Controller Output Mode,
+ The unit is bits per pixel, there are four values,
+ <12>, <16>, <18>, <24>, the default value is <24>.
+- atmel,guard-time: lcd guard time (Delay in frame periods).
+- display-timings: please refer the displaymode.txt.
+
+Example:
+hlcdc: hlcdc@f0000000 {
+ u-boot,dm-pre-reloc;
+ compatible = "atmel,sama5d2-hlcdc";
+ reg = <0xf0000000 0x2000>;
+ clocks = <&lcdc_clk>;
+ atmel,vl-bpix = <4>;
+ atmel,output-mode = <24>;
+ atmel,guard-time = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_pwm &pinctrl_lcd_rgb666>;
+ status = "okay";
+
+ display-timings {
+ 480x272 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hsync-len = <41>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ vfront-porch = <2>;
+ vback-porch = <2>;
+ vsync-len = <11>;
+ };
+ };
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/video/bridge/ps8622.txt b/roms/u-boot/doc/device-tree-bindings/video/bridge/ps8622.txt
new file mode 100644
index 000000000..66d5d07eb
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/bridge/ps8622.txt
@@ -0,0 +1,33 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8622" or "parade,ps8625"
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+ - parade,regs: List of 3-byte registers tuples to write:
+ <I2C chip address offset> <register> <value>
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
+ - video interfaces: Device node can contain video interface port
+ nodes for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ lvds-bridge@48 {
+ compatible = "parade,ps8622";
+ reg = <0x48>;
+ sleep-gpios = <&gpc3 6 1 0 0>;
+ reset-gpios = <&gpc3 1 1 0 0>;
+ lane-count = <1>;
+ ports {
+ port@0 {
+ bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/display-timing.txt b/roms/u-boot/doc/device-tree-bindings/video/display-timing.txt
new file mode 100644
index 000000000..e1d4a0b59
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/display-timing.txt
@@ -0,0 +1,110 @@
+display-timing bindings
+=======================
+
+display-timings node
+--------------------
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
+
+timing subnode
+--------------
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+ lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+ - active high = drive pixel data on rising edge/
+ sample data on falling edge
+ - active low = drive pixel data on falling edge/
+ sample data on rising edge
+ - ignored = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool): boolean to enable doubleclock mode
+
+All the optional properties that are not bool follow the following logic:
+ <1>: high active
+ <0>: low active
+ omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+ +----------+-------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vback_porch | | |
+ | | ↓ | | |
+ +----------#######################################----------+-------+
+ | # ↑ # | |
+ | # | # | |
+ | hback # | # hfront | hsync |
+ | porch # | hactive # porch | len |
+ |<-------->#<-------+--------------------------->#<-------->|<----->|
+ | # | # | |
+ | # |vactive # | |
+ | # | # | |
+ | # ↓ # | |
+ +----------#######################################----------+-------+
+ | | ↑ | | |
+ | | |vfront_porch | | |
+ | | ↓ | | |
+ +----------+-------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vsync_len | | |
+ | | ↓ | | |
+ +----------+-------------------------------------+----------+-------+
+
+Example:
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = <52000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ };
+ };
+
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with minimum, typical and maximum values can be used.
+
+Example:
+
+ timing1: timing {
+ /* 1920x1080p24 */
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <0 44 60>;
+ hfront-porch = <80 88 95>;
+ hback-porch = <100 148 160>;
+ vfront-porch = <0 4 6>;
+ vback-porch = <0 36 50>;
+ vsync-len = <0 5 6>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt b/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt
new file mode 100644
index 000000000..45ca42db5
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt
@@ -0,0 +1,42 @@
+videomode bindings
+==================
+
+(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html)
+
+Required properties:
+ - xres, yres: Display resolution
+ - left-margin, right-margin, hsync-len: Horizontal Display timing
+ parameters in pixels
+ - upper-margin, lower-margin, vsync-len: Vertical display timing
+ parameters in lines
+ - clock: display clock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree
+representation corresponds to the one used by the Linux Framebuffer
+framework described here in Documentation/fb/framebuffer.txt. This
+representation has been chosen because it's the only format which does
+not allow for inconsistent parameters. Unlike the Framebuffer framework
+the devicetree has the clock in Hz instead of ps.
+
+Example:
+
+ display@0 {
+ /* 1920x1080p24 */
+ clock = <52000000>;
+ xres = <1920>;
+ yres = <1080>;
+ left-margin = <25>;
+ right-margin = <25>;
+ hsync-len = <25>;
+ lower-margin = <2>;
+ upper-margin = <2>;
+ vsync-len = <2>;
+ hsync-active-high;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt b/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt
new file mode 100644
index 000000000..464a85302
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt
@@ -0,0 +1,69 @@
+Exynos Display port controller
+==============================
+
+Required properties:
+SOC specific:
+ compatible: should be "samsung,exynos5-dp"
+ reg: Base address of DP IP
+
+Optional properties:
+ samsung,h-res: X resolution of the panel
+ samsung,h-sync-width: hsync value
+ samsung,h-back-porch: left margin
+ samsung,h-front-porch right margin
+ samsung,v-res: Y resolution of the panel
+ samsung,v-sync-width: vsync value
+ samsung,v-back-porch: upper margin
+ samsung,v-front-porch: lower margin
+ samsung,v-sync-rate: refresh rate
+
+ samsung,lt-status: Link training status
+ 0(DP_LT_NONE), 1(DP_LT_START), 2(DP_LT_CR), 3(DP_LT_ET),
+ 4(DP_LT_FINISHED), 5(DP_LT_FAIL)
+
+ samsung,master-mode: 1 if you want to run DP as master, else 0
+ samsung,bist-mode: 1 to enable video bist mode, else 0
+ samsung,bist-pattern: bist mode pattern type
+ 0(NO_PATTERN), 1(COLOR_RAMP), 2(BALCK_WHITE_V_LINES),
+ 3(COLOR_SQUARE), 4(INVALID_PATTERN), 5(COLORBAR_32),
+ 6(COLORBAR_64),7(WHITE_GRAY_BALCKBAR_32),
+ 8(WHITE_GRAY_BALCKBAR_64),9(MOBILE_WHITEBAR_32),
+ 10(MOBILE_WHITEBAR_64)
+ samsung,h-sync-polarity: Horizontal Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,v-sync-polarity: Vertical Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,interlaced: Progressive if 0, else Interlaced
+ samsung,color-space: input video data format
+ COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+ samsung,dynamic-range: dynamic range for input video data
+ VESA = 0, CEA = 1
+ samsung,ycbcr-coeff: YCbCr co-efficients for input video
+ COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
+ samsung,color-depth: number of bits per colour component
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+
+Example:
+SOC specific part:
+ dp@145b0000 {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b0000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+Board(panel) specific part:
+ dp@145b0000 {
+ samsung,lt-status = <0>;
+
+ samsung,master-mode = <0>;
+ samsung,bist-mode = <0>;
+ samsung,bist-pattern = <0>;
+ samsung,h-sync-polarity = <0>;
+ samsung,v-sync-polarity = <0>;
+ samsung,interlaced = <0>;
+ samsung,color-space = <0>;
+ samsung,dynamic-range = <0>;
+ samsung,ycbcr-coeff = <0>;
+ samsung,color-depth = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt b/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt
new file mode 100644
index 000000000..b022f6163
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt
@@ -0,0 +1,100 @@
+Exynos Display Controller
+=========================
+Required properties:
+SOC specific:
+ compatible: should be "samsung,exynos-fimd"
+ reg: Base address of FIMD IP.
+
+Board(panel specific):
+ samsung,vl-col: X resolution of the panel
+ samsung,vl-row: Y resolution of the panel
+ samsung,vl-freq: Refresh rate
+ samsung,vl-bpix: Bits per pixel
+ samsung,vl-hspw: Hsync value
+ samsung,vl-hfpd: Right margin
+ samsung,vl-hbpd: Left margin
+ samsung,vl-vspw: Vsync value
+ samsung,vl-vfpd: Lower margin
+ samsung,vl-vbpd: Upper margin
+
+Optional properties:
+Board(panel specific):
+ samsung,vl-width: width of display area in mm
+ samsung,vl-height: Height of display area in mm
+
+ samsung,vl-clkp: Clock polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-oep: Output Enable polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-hsp: Horizontal Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-vsp: Vertical Sync polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+ samsung,vl-dp: Data polarity
+ CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH
+
+ samsung,vl-cmd-allow-len: Wait end of frame
+ samsung,winid: Window number on which data is to be displayed
+ samsung,init-delay: Delay before LCD initialization starts
+ samsung,power-on-delay: Delay after LCD is powered on
+ samsung,reset-delay: Delay after LCD is reset
+ samsung,interface-mode: 1(FIMD_RGB_INTERFACE), 2(FIMD_CPU_INTERFACE)
+ samsung,mipi-enabled: 1 if you want to use MIPI, else 0
+ samsung,dp-enabled: 1is you want to use DP, else 0
+ samsung,cs-setup: cs_setup value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-setup: wr_setup value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-act: wr_act value in FIMD_CPU_INTERFACE mode.
+ samsung,wr-hold: wr_hold value in FIMD_CPU_INTERFACE mode.
+ samsung,logo-on: 1 if you want to use custom logo.
+ 0 if you want LCD console.
+ samsung,logo-width: pixel width of logo image. Valid if logo_on = 1
+ samsung,logo-height: pixel height of logo image. Valid if logo_on = 1
+ samsung,logo-addr: Address of logo image. Valid if logo_on = 1
+ samsung,rgb-mode: 0(MODE_RGB_P), 1(MODE_BGR_P),
+ 2(MODE_RGB_S), 3(MODE_BGR_S)
+ samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL)
+ samsung,sclk-div: parent_clock/source_clock ratio
+ samsung,dual-lcd-enabled: 1 if you support two LCD, else 0
+ samsung,disable-sysmmu: Define this if you want to disable FIMD sysmmu.
+ (needed for Exynos5420 and newer versions)
+ Add the required FIMD sysmmu nodes to be
+ disabled with compatible string
+ "samsung,sysmmu-v3.3", with a "reg" property
+ holding the register address of FIMD sysmmu.
+ samsung,pwm-out-gpio: PWM output GPIO.
+ samsung,bl-en-gpio: backlight enable GPIO.
+
+Example:
+SOC specific part:
+ fimd@14400000 {
+ compatible = "samsung,exynos-fimd";
+ reg = <0x14400000 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+Board specific part:
+ fimd@14400000 {
+ samsung,vl-freq = <60>;
+ samsung,vl-col = <2560>;
+ samsung,vl-row = <1600>;
+ samsung,vl-width = <2560>;
+ samsung,vl-height = <1600>;
+
+ samsung,vl-clkp;
+ samsung,vl-dp;
+ samsung,vl-bpix = <4>;
+
+ samsung,vl-hspw = <32>;
+ samsung,vl-hbpd = <80>;
+ samsung,vl-hfpd = <48>;
+ samsung,vl-vspw = <6>;
+ samsung,vl-vbpd = <37>;
+ samsung,vl-vfpd = <3>;
+ samsung,vl-cmd-allow-len = <0xf>;
+
+ samsung,winid = <3>;
+ samsung,interface-mode = <1>;
+ samsung,dp-enabled = <1>;
+ samsung,dual-lcd-enabled = <0>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt b/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt
new file mode 100644
index 000000000..4938ea01e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt
@@ -0,0 +1,82 @@
+Exynos MIPI-DSIM Controller
+=========================
+
+Required properties:
+SOC specific:
+ compatible: should be "samsung,exynos-mipi-dsi"
+ reg: Base address of MIPI-DSIM IP.
+
+Board specific:
+ samsung,dsim-config-e-interface: interface to be used (RGB interface
+ for main display or CPU interface for main or sub display).
+ samsung,dsim-config-e-virtual-ch: virtual channel number that main
+ or sub display uses.
+ samsung,dsim-config-e-pixel-format: pixel stream format for main
+ or sub display.
+ samsung,dsim-config-e-burst-mode: selects Burst mode in Video mode.
+ in Non-burst mode, RGB data area is filled with RGB data and
+ NULL packets, according to input bandwidth of RGB interface.
+ samsung,dsim-config-e-no-data-lane: data lane count used by Master.
+ samsung,dsim-config-e-byte-clk: select byte clock source.
+ It must be DSIM_PLL_OUT_DIV8.
+ DSIM_EXT_CLK_DIV8 and DSIM_EXT_CLK_BYPASSS are not supported.
+ samsung,dsim-config-hfp: HFP disable mode.
+ If set, DSI master ignores HFP area in VIDEO mode.
+ In command mode, this variable is ignored.
+ samsung,dsim-config-p: P value for PMS setting.
+ samsung,dsim-config-m: M value for PMS setting.
+ samsung,dsim-config-s: S value for PMS setting.
+ samsung,dsim-config-pll-stable-time: the PLL Timer for stability
+ of the ganerated clock.
+ samsung,dsim-config-esc-clk: escape clock frequency for getting
+ the escape clock prescaler value.
+ samsung,dsim-config-stop-holding-cnt: the interval value between
+ transmitting read packet (or write "set_tear_on" command)
+ and BTA request. After transmitting read packet or write
+ "set_tear_on" command, BTA requests to D-PHY automatically.
+ This counter value specifies the interval between them.
+ samsung,dsim-config-bta-timeout: the timer for BTA. This register
+ specifies time out from BTA request to change the direction
+ with respect to Tx escape clock.
+ samsung,dsim-config-rx-timeout: the timer for LP Rx mode timeout.
+ this register specifies time out on how long RxValid deasserts,
+ after RxLpdt asserts with respect to Tx escape clock.
+ - RxValid specifies Rx data valid indicator.
+ - RxLpdt specifies an indicator that D-PHY is under RxLpdt mode
+ - RxValid and RxLpdt specifies signal from D-PHY.
+ samsung,dsim-device-name: name of the device.
+ samsung,dsim-device-id: unique device id.
+ samsung,dsim-device-bus_id: bus id for identifing connected bus
+ and this bus id should be same as id of mipi_dsim_device.
+
+Optional properties:
+ samsung,dsim-device-reverse-panel: reverse panel.
+
+Example:
+ mipidsi@11c80000 {
+ compatible = "samsung,exynos-mipi-dsi";
+ reg = <0x11c80000 0x5c>;
+
+ samsung,dsim-config-e-interface = <1>;
+ samsung,dsim-config-e-virtual-ch = <0>;
+ samsung,dsim-config-e-pixel-format = <7>;
+ samsung,dsim-config-e-burst-mode = <1>;
+ samsung,dsim-config-e-no-data-lane = <3>;
+ samsung,dsim-config-e-byte-clk = <0>;
+ samsung,dsim-config-hfp = <1>;
+
+ samsung,dsim-config-p = <3>;
+ samsung,dsim-config-m = <120>;
+ samsung,dsim-config-s = <1>;
+
+ samsung,dsim-config-pll-stable-time = <500>;
+ samsung,dsim-config-esc-clk = <20000000>;
+ samsung,dsim-config-stop-holding-cnt = <0x7ff>;
+ samsung,dsim-config-bta-timeout = <0xff>;
+ samsung,dsim-config-rx-timeout = <0xffff>;
+
+ samsung,dsim-device-id = <0xffffffff>;
+ samsung,dsim-device-bus-id = <0>;
+
+ samsung,dsim-device-reverse-panel = <1>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/intel-gma.txt b/roms/u-boot/doc/device-tree-bindings/video/intel-gma.txt
new file mode 100644
index 000000000..914be4fed
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/intel-gma.txt
@@ -0,0 +1,40 @@
+Intel GMA Bindings
+==================
+
+This is the Intel Graphics Media Accelerator. This binding supports selection
+of display parameters only.
+
+
+Required properties:
+ - compatible : "intel,gma";
+
+Optional properties:
+ - intel,dp-hotplug : values for digital port hotplug, one cell per value for
+ ports B, C and D
+ - intel,panel-port-select : output port to use: 0=LVDS 1=DP_B 2=DP_C 3=DP_D
+ - intel,panel-power-cycle-delay : T4 time sequence (6 = 500ms)
+
+ The following delays are in units of 0.1ms:
+ - intel,panel-power-up-delay : T1+T2 time sequence
+ - intel,panel-power-down-delay : T3 time sequence
+ - intel,panel-power-backlight-on-delay : T5 time sequence
+ - intel,panel-power-backlight-off-delay : Tx time sequence
+
+ - intel,cpu-backlight : Value for CPU Backlight PWM
+ - intel,pch-backlight : Value for PCH Backlight PWM
+
+Example
+-------
+
+gma {
+ compatible = "intel,gma";
+ intel,dp_hotplug = <0 0 0x06>;
+ intel,panel-port-select = <1>;
+ intel,panel-power-cycle-delay = <6>;
+ intel,panel-power-up-delay = <2000>;
+ intel,panel-power-down-delay = <500>;
+ intel,panel-power-backlight-on-delay = <2000>;
+ intel,panel-power-backlight-off-delay = <2000>;
+ intel,cpu-backlight = <0x00000200>;
+ intel,pch-backlight = <0x04000000>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt b/roms/u-boot/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
new file mode 100644
index 000000000..d7aacc827
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/osd/gdsys,ihs_video_out.txt
@@ -0,0 +1,23 @@
+* Guntermann & Drunck Integrated Hardware Systems OSD
+
+Required properties:
+- compatible: "gdsys,ihs_video_out"
+- reg: A combination of three register spaces:
+ - Register base for the video registers
+ - Register base for the OSD registers
+ - Address of the OSD video memory
+- mode: The initial resolution and frequency: "1024_768_60", "720_400_70", or
+ "640_480_70"
+- clk_gen: phandle to the pixel clock generator
+- dp_tx: phandle to the display associated with the OSD
+
+Example:
+
+fpga0_video0 {
+ compatible = "gdsys,ihs_video_out";
+ reg = <0x100 0x40
+ 0x180 0x20
+ 0x1000 0x1000>;
+ dp_tx = <&fpga0_dp_video0>;
+ clk_gen = <&fpga0_video0_clkgen>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/video/rockchip-lvds.txt b/roms/u-boot/doc/device-tree-bindings/video/rockchip-lvds.txt
new file mode 100644
index 000000000..7432e2216
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/rockchip-lvds.txt
@@ -0,0 +1,77 @@
+Rockchip LVDS interface
+------------------
+
+Required properties:
+- compatible: "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+ of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- rockchip,grf: phandle to the general register files syscon
+
+- rockchip,data-mapping: should be <LVDS_FORMAT_VESA> or <LVDS_FORMAT_JEIDA>,
+ This describes how the color bits are laid out in the
+ serialized LVDS signal.
+- rockchip,data-width : should be <18> or <24>;
+- rockchip,output: should be <LVDS_OUTPUT_RGB>, <LVDS_OUTPUT_SINGLE> or
+ <LVDS_OUTPUT_DUAL>, This describes the output face.
+
+- display-timings : described by
+ doc/device-tree-bindings/video/display-timing.txt.
+
+Example:
+ lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ reg = <0xff96c000 0x4000>;
+ clocks = <&cru PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcdc0_ctl>;
+ rockchip,grf = <&grf>;
+ status = "disabled";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in: port@0 {
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_lvds>;
+ };
+ lvds_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_lvds>;
+ };
+ };
+ };
+ };
+
+ &lvds {
+ rockchip,data-mapping = <LVDS_FORMAT_VESA>;
+ rockchip,data-width = <24>;
+ rockchip,output = <LVDS_OUTPUT_DUAL>;
+ rockchip,panel = <&panel>;
+ status = "okay";
+
+ display-timings {
+ timing@0 {
+ clock-frequency = <40000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt b/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt
new file mode 100644
index 000000000..230d25c23
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt
@@ -0,0 +1,17 @@
+Sandbox LCD
+===========
+
+This uses the displaymode.txt binding except that only xres and yres are
+required properties. Also an additional optional property is defined:
+
+log2-depth: Log base 2 of the U-Boot display buffer depth (4=16bpp, 5=32bpp).
+ If not provided, a value of 4 is used.
+
+Example:
+
+ lcd {
+ compatible = "sandbox,lcd-sdl";
+ xres = <800>;
+ yres = <600>;
+ log2-depth = <5>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt b/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt
new file mode 100644
index 000000000..3ea460583
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+ - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+
+Example:
+
+ framebuffer {
+ compatible = "simple-framebuffer";
+ reg = <0x1d385000 (1600 * 1200 * 2)>;
+ width = <1600>;
+ height = <1200>;
+ stride = <(1600 * 2)>;
+ format = "r5g6b5";
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/syncoam,seps525.txt b/roms/u-boot/doc/device-tree-bindings/video/syncoam,seps525.txt
new file mode 100644
index 000000000..e1e0db9d7
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/syncoam,seps525.txt
@@ -0,0 +1,24 @@
+spi based seps525 framebuffer display driver
+
+Driver for seps525 display controller (in spi mode), This binding supports selection
+of spi chipselect, spi max frequency, gpio to drive dc and reset pin of seps525
+controller and spi transaction bit length.
+
+Required properties:
+- compatible: "syncoam,seps525"
+- reg: Specifies the chip-select the seps525 is connected to on the spi bus
+- reset-gpios: gpio connected to reset pin of seps525 controller.
+- dc-gpios: gpio connected to dc pin of seps525 controller:
+- buswidth: bitlength of each spi transaction
+
+Example:
+ displayspi@0 {
+ compatible = "syncoam,seps525";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ spi-cpol;
+ spi-cpha;
+ buswidth = <8>;
+ reset-gpios = <&gpio 0x1c GPIO_ACTIVE_LOW>;
+ dc-gpios = <&gpio 0x1b GPIO_ACTIVE_HIGH>;
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt b/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt
new file mode 100644
index 000000000..4731c3fba
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt
@@ -0,0 +1,85 @@
+Display Controller
+------------------
+
+(there isn't yet a generic binding in Linux, so this describes what is in
+U-Boot, and may change based on Linux activity)
+
+The device node for a display device 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-dc"
+
+Required subnode 'rgb' is as follows:
+
+Required properties (rgb) :
+ - nvidia,panel : phandle of LCD panel information
+
+
+The panel node describes the panel itself. This has the properties listed in
+displaymode.txt as well as:
+
+Required properties (panel) :
+ - nvidia,bits-per-pixel: number of bits per pixel (depth)
+ - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt)
+ - nvidia,panel-timings: 4 cells containing required timings in ms:
+ * delay before asserting panel_vdd
+ * delay between panel_vdd-rise and data-rise
+ * delay between data-rise and backlight_vdd-rise
+ * delay between backlight_vdd and pwm-rise
+ * delay between pwm-rise and backlight_en-rise
+
+Optional GPIO properies all have (phandle, GPIO number, flags):
+ - nvidia,backlight-enable-gpios: backlight enable GPIO
+ - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO
+ - nvidia,backlight-vdd-gpios: backlight power GPIO
+ - nvidia,panel-vdd-gpios: panel power GPIO
+
+Example:
+
+host1x {
+ compatible = "nvidia,tegra20-host1x", "simple-bus";
+ reg = <0x50000000 0x00024000>;
+ interrupts = <0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04>; /* mpcore general */
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ ranges = <0x54000000 0x54000000 0x04000000>;
+
+ dc@54200000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54200000 0x00040000>;
+ interrupts = <0 73 0x04>;
+ status = "okay";
+
+ rgb {
+ status = "okay";
+ nvidia,panel = <&lcd_panel>;
+ };
+ };
+};
+
+lcd_panel: panel {
+ /* Seaboard has 1366x768 */
+ clock = <70600000>;
+ xres = <1366>;
+ yres = <768>;
+ left-margin = <58>;
+ right-margin = <58>;
+ hsync-len = <58>;
+ lower-margin = <4>;
+ upper-margin = <4>;
+ vsync-len = <4>;
+ hsync-active-high;
+ nvidia,bits-per-pixel = <16>;
+ nvidia,pwm = <&pwm 2 0>;
+ nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */
+ nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */
+ nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */
+ nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */
+ nvidia,panel-timings = <400 4 203 17 15>;
+};
diff --git a/roms/u-boot/doc/device-tree-bindings/video/tilcdc/panel.txt b/roms/u-boot/doc/device-tree-bindings/video/tilcdc/panel.txt
new file mode 100644
index 000000000..808216310
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/tilcdc/panel.txt
@@ -0,0 +1,66 @@
+Device-Tree bindings for tilcdc DRM generic panel output driver
+
+Required properties:
+ - compatible: value should be "ti,tilcdc,panel".
+ - panel-info: configuration info to configure LCDC correctly for the panel
+ - ac-bias: AC Bias Pin Frequency
+ - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
+ - dma-burst-sz: DMA burst size
+ - bpp: Bits per pixel
+ - fdd: FIFO DMA Request Delay
+ - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
+ - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
+ - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
+ - fifo-th: DMA FIFO threshold
+ - display-timings: typical videomode of lcd panel. Multiple video modes
+ can be listed if the panel supports multiple timings, but the 'native-mode'
+ should be the preferred/default resolution. Refer to
+ Documentation/devicetree/bindings/display/panel/display-timing.txt for display
+ timing binding details.
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- enable-gpios: GPIO pin to enable or disable the panel
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+ muxing properly for pins that connect to TFP410 device
+
+Example:
+
+ /* Settings for CDTech_S035Q01 / LCD3 cape: */
+ lcd3 {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
+ backlight = <&backlight>;
+ enable-gpios = <&gpio3 19 0>;
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 320x240 {
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <21>;
+ hfront-porch = <58>;
+ hsync-len = <47>;
+ vback-porch = <11>;
+ vfront-porch = <23>;
+ vsync-len = <2>;
+ clock-frequency = <8000000>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/video/tilcdc/tilcdc.txt b/roms/u-boot/doc/device-tree-bindings/video/tilcdc/tilcdc.txt
new file mode 100644
index 000000000..7bf1bb444
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/video/tilcdc/tilcdc.txt
@@ -0,0 +1,82 @@
+Device-Tree bindings for tilcdc DRM driver
+
+Required properties:
+ - compatible: value should be one of the following:
+ - "ti,am33xx-tilcdc" for AM335x based boards
+ - "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138 based boards
+ - interrupts: the interrupt number
+ - reg: base address and size of the LCDC device
+
+Recommended properties:
+ - ti,hwmods: Name of the hwmod associated to the LCDC
+
+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+ interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+ the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+ by the lcd controller in KHz.
+ - blue-and-red-wiring: Recognized values "straight" or "crossed".
+ This property deals with the LCDC revision 2 (found on AM335x)
+ color errata [1].
+ - "straight" indicates normal wiring that supports RGB565,
+ BGR888, and XBGR8888 color formats.
+ - "crossed" indicates wiring that has blue and red wires
+ crossed. This setup supports BGR565, RGB888 and XRGB8888
+ formats.
+ - If the property is not present or its value is not recognized
+ the legacy mode is assumed. This configuration supports RGB565,
+ RGB888 and XRGB8888 formats. However, depending on wiring, the red
+ and blue colors are swapped in either 16 or 24-bit color modes.
+
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+ binding follows Documentation/devicetree/bindings/graph.txt and
+ supports a single port with a single endpoint.
+
+ - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
+ Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
+ tfp410 DVI encoder or lcd panel to lcdc
+
+[1] There is an errata about AM335x color wiring. For 16-bit color mode
+ the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]),
+ but for 24 bit color modes the wiring of blue and red components is
+ crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
+ for Blue[3-7]. For more details see section 3.1.1 in AM335x
+ Silicon Errata:
+ http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
+
+Example:
+
+ fb: fb@4830e000 {
+ compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
+ reg = <0x4830e000 0x1000>;
+ interrupt-parent = <&intc>;
+ interrupts = <36>;
+ ti,hwmods = "lcdc";
+
+ blue-and-red-wiring = "crossed";
+
+ port {
+ lcdc_0: endpoint@0 {
+ remote-endpoint = <&hdmi_0>;
+ };
+ };
+ };
+
+ tda19988: tda19988 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+
+ pinctrl-names = "default", "off";
+ pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = <&lcdc_0>;
+ };
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds24xxx.txt b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds24xxx.txt
new file mode 100644
index 000000000..2e91be93b
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds24xxx.txt
@@ -0,0 +1,37 @@
+Maxim DS24 families driver device binding - one wire protocol EEPROMS from Maxim
+=======================
+
+This memory needs to be connected to a onewire bus, as a child node.
+The bus will read the device serial number and match this node with a found
+device on the bus
+Also check doc/device-tree-bindings/w1 for onewire bus drivers
+
+Driver:
+- drivers/w1-eeprom/ds24xxx.c
+
+Software ds24xxx device-tree node properties:
+Required:
+* compatible = "maxim,ds24b33"
+or
+* compatible = "maxim,ds2431"
+Further memories can be added.
+
+Optional:
+* none
+
+Example:
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds24xxx";
+ }
+
+Example with parent bus:
+
+onewire_tm: onewire {
+ compatible = "w1-gpio";
+ gpios = <&pioA 32 0>;
+
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds24xxx";
+ }
+};
+
diff --git a/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds2502.txt b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds2502.txt
new file mode 100644
index 000000000..7f05fc432
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/ds2502.txt
@@ -0,0 +1,33 @@
+Maxim DS2502 driver device binding - one wire protocol add only memory from Maxim
+=======================
+
+This memory needs to be connected to a onewire bus, as a child node.
+The bus will read the device serial number and match this node with a found
+device on the bus
+Also check doc/device-tree-bindings/w1 for onewire bus drivers
+
+Driver:
+- drivers/w1-eeprom/ds2502.c
+
+Ds2502 device-tree node properties:
+Required:
+* compatible = "maxim,ds2502"
+
+Optional:
+* none
+
+Example:
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds2502";
+ };
+
+Example with parent bus:
+ onewire {
+ compatible = "fsl,imx53-owire";
+ reg = <0x63fa4000 0x4000>;
+
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds2502";
+ };
+ };
+
diff --git a/roms/u-boot/doc/device-tree-bindings/w1-eeprom/eep_sandbox.txt b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/eep_sandbox.txt
new file mode 100644
index 000000000..82bb5899a
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/w1-eeprom/eep_sandbox.txt
@@ -0,0 +1,34 @@
+Onewire EEPROM sandbox driver device binding - one wire protocol sandbox EEPROM
+=======================
+
+This memory needs to be connected to a onewire bus, as a child node.
+The bus will read the device serial number and match this node with a found
+device on the bus
+Also check doc/device-tree-bindings/w1 for onewire bus drivers
+
+Driver:
+- drivers/w1-eeprom/eep_sandbox.c
+
+Software ds24xxx device-tree node properties:
+Required:
+* compatible = "sandbox,w1-eeprom"
+
+Optional:
+* none
+
+Example:
+ eeprom1: eeprom@0 {
+ compatible = "sandbox,w1-eeprom";
+ }
+
+Example with parent bus:
+
+onewire_tm: onewire {
+ compatible = "w1-gpio";
+ gpios = <&gpio_a 8>;
+
+ eeprom1: eeprom@0 {
+ compatible = "sandbox,w1-eeprom";
+ }
+};
+
diff --git a/roms/u-boot/doc/device-tree-bindings/w1/mxc-w1.txt b/roms/u-boot/doc/device-tree-bindings/w1/mxc-w1.txt
new file mode 100644
index 000000000..1fb49cc11
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/w1/mxc-w1.txt
@@ -0,0 +1,37 @@
+NXP i.MX (MXC) One wire bus master controller
+=======================
+
+Child nodes are required in device tree. The driver will detect
+the devices serial number and then search in the child nodes in the device tree
+for the proper node and try to match it with the device.
+
+Also check doc/device-tree-bindings/w1-eeprom for possible child nodes drivers
+
+Driver:
+- drivers/w1/mxc_w1.c
+
+Required properties:
+- compatible : should be one of
+ "fsl,imx21-owire", "fsl,imx27-owire", "fsl,imx31-owire", "fsl,imx25-owire"
+ "fsl,imx25-owire", "fsl,imx35-owire", "fsl,imx50-owire", "fsl,imx53-owire"
+
+- reg : Address and length of the register set for the device
+
+Optional:
+* none
+
+Example:
+ onewire {
+ compatible = "fsl,imx53-owire";
+ reg = <0x63fa4000 0x4000>;
+ };
+
+Example with child:
+ onewire {
+ compatible = "fsl,imx53-owire";
+ reg = <0x63fa4000 0x4000>;
+
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds24xxx";
+ };
+ };
diff --git a/roms/u-boot/doc/device-tree-bindings/w1/w1-gpio.txt b/roms/u-boot/doc/device-tree-bindings/w1/w1-gpio.txt
new file mode 100644
index 000000000..5a582448e
--- /dev/null
+++ b/roms/u-boot/doc/device-tree-bindings/w1/w1-gpio.txt
@@ -0,0 +1,40 @@
+W1 gpio device binding - one wire protocol over bitbanged gpio
+=======================
+
+
+Child nodes are required in device tree. The driver will detect
+the devices serial number and then search in the child nodes in the device tree
+for the proper node and try to match it with the device.
+
+Also check doc/device-tree-bindings/w1-eeprom for possible child nodes drivers
+
+Driver:
+- drivers/w1/w1-gpio.c
+
+Software w1 device-tree node properties:
+Required:
+* compatible = "w1-gpio";
+* gpios = <...>;
+ This is the gpio used for one wire protocol, using bitbanging
+
+Optional:
+* none
+
+Example:
+
+onewire_tm: onewire {
+ compatible = "w1-gpio";
+ gpios = <&pioA 32 0>;
+};
+
+Example with child:
+
+onewire_tm: onewire {
+ compatible = "w1-gpio";
+ gpios = <&pioA 32 0>;
+
+ eeprom1: eeprom@0 {
+ compatible = "maxim,ds24xxx";
+ }
+};
+
diff --git a/roms/u-boot/doc/feature-removal-schedule.txt b/roms/u-boot/doc/feature-removal-schedule.txt
new file mode 100644
index 000000000..546d2da17
--- /dev/null
+++ b/roms/u-boot/doc/feature-removal-schedule.txt
@@ -0,0 +1,31 @@
+The following is a list of files and features that are going to be
+removed from the U-Boot source tree. Every entry should contain what
+exactly is going away, when it will be gone, why it is being removed,
+and who is going to be doing the work. When the feature is removed
+from U-Boot, its corresponding entry should also be removed from this
+file.
+
+---------------------------
+
+What: Users of the legacy miiphy_* code
+When: undetermined
+
+Why: We now have a PHY library, which allows everyone to share PHY
+ drivers. All new drivers should use this infrastructure, and
+ all old drivers should get converted to use it.
+
+Who: Andy Fleming <afleming@gmail.com> and driver maintainers
+
+---------------------------
+
+What: GPL cleanup
+When: August 2009
+Why: Over time, a couple of files have sneaked in into the U-Boot
+ source code that are either missing a valid GPL license
+ header or that carry a license that is incompatible with the
+ GPL.
+ Such files shall be removed from the U-Boot source tree.
+ See http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files
+ for an old and probably incomplete list of such files.
+
+Who: Wolfgang Denk <wd@denx.de> and board maintainers
diff --git a/roms/u-boot/doc/git-mailrc b/roms/u-boot/doc/git-mailrc
new file mode 100644
index 000000000..dc7b39b32
--- /dev/null
+++ b/roms/u-boot/doc/git-mailrc
@@ -0,0 +1,134 @@
+# To use this file, run in your u-boot tree:
+# git config sendemail.aliasesfile doc/git-mailrc
+# git config sendemail.aliasfiletype mutt
+#
+# Then when sending patches, you can use:
+# git send-email --to u-boot --cc i2c ...
+
+alias uboot u-boot@lists.denx.de
+alias u-boot uboot
+
+# Maintainer aliases. Use the same alias here as patchwork to keep
+# things simple and easy to look up/coordinate.
+alias abiessmann Andreas Bießmann <andreas@biessmann.org>
+alias abrodkin Alexey Brodkin <alexey.brodkin@synopsys.com>
+alias afleming Andy Fleming <afleming@gmail.com>
+alias ag Anatolij Gustschin <agust@denx.de>
+alias agraf Alexander Graf <agraf@csgraf.de>
+alias alexnemirovsky Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
+alias alisonwang Alison Wang <alison.wang@nxp.com>
+alias angelo_ts Angelo Dureghello <angelo@sysam.it>
+alias apritzel Andre Przywara <andre.przywara@arm.com>
+alias bmeng Bin Meng <bmeng.cn@gmail.com>
+alias danielschwierzeck Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
+alias dinh Dinh Nguyen <dinguyen@kernel.org>
+alias hs Heiko Schocher <hs@denx.de>
+alias freenix Peng Fan <peng.fan@nxp.com>
+alias iwamatsu Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+alias jaehoon Jaehoon Chung <jh80.chung@samsung.com>
+alias jagan Jagan Teki <jagan@amarulasolutions.com>
+alias jhersh Joe Hershberger <joe.hershberger@ni.com>
+alias kevery Kever Yang <kever.yang@rock-chips.com>
+alias leyfoon Ley Foon Tan <lftan.linux@gmail.com>
+alias lokeshvutla Lokesh Vutla <lokeshvutla@ti.com>
+alias lukma Lukasz Majewski <lukma@denx.de>
+alias macpaul Macpaul Lin <macpaul@andestech.com>
+alias marex Marek Vasut <marex@denx.de>
+alias mariosix Mario Six <mario.six@gdsys.cc>
+alias masahiro Masahiro Yamada <yamada.masahiro@socionext.com>
+alias mateusz Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
+alias mbrugger Matthias Brugger <mbrugger@suse.com>
+alias monstr Michal Simek <monstr@monstr.eu>
+alias prom Minkyu Kang <mk7.kang@samsung.com>
+alias ptomsich Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
+alias sbabic Stefano Babic <sbabic@denx.de>
+alias simongoldschmidt Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
+alias sjg Simon Glass <sjg@chromium.org>
+alias smcnutt Scott McNutt <smcnutt@psyent.com>
+alias stroese Stefan Roese <sr@denx.de>
+alias trini Tom Rini <trini@konsulko.com>
+alias wd Wolfgang Denk <wd@denx.de>
+alias priyankajain Priyanka Jain <priyanka.jain@nxp.com>
+
+# Architecture aliases
+alias arch arc, arm, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, x86
+alias arches arch
+
+alias arc uboot, abrodkin
+
+alias arm uboot, trini
+alias at91 uboot, abiessmann
+alias cortina uboot, alexnemirovsky
+alias davinci ti
+alias imx uboot, sbabic
+alias kirkwood uboot, stroese
+alias omap ti
+alias pxa uboot, marex
+alias rmobile uboot, iwamatsu
+alias s3c samsung
+alias s5pc samsung
+alias samsung uboot, prom
+alias snapdragon uboot, mateusz
+alias socfpga uboot, marex, dinh, simongoldschmidt, leyfoon
+alias sunxi uboot, jagan, apritzel
+alias tegra uboot, sjg, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com>
+alias tegra2 tegra
+alias ti uboot, lokeshvutla
+alias uniphier uboot, masahiro
+alias zynq uboot, monstr
+alias rockchip uboot, sjg, kevery, ptomsich
+
+alias bcm283x uboot, mbrugger
+alias rpi uboot, mbrugger
+
+alias m68k uboot, alisonwang, angelo_ts
+alias coldfire m68k
+
+alias microblaze uboot, monstr
+alias mb microblaze
+
+alias mips uboot, danielschwierzeck
+
+alias nds32 uboot, macpaul
+
+alias nios uboot, Thomas Chou <thomas@wytron.com.tw>, smcnutt
+alias nios2 nios
+
+alias powerpc uboot, afleming, stroese, wd, priyankajain, mariosix
+alias ppc powerpc
+alias mpc8xx uboot, wd, Christophe Leroy <christophe.leroy@c-s.fr>
+alias mpc83xx uboot, mariosix
+alias mpc85xx uboot, afleming, priyankajain
+alias mpc86xx uboot, afleming, priyankajain
+
+alias sandbox sjg
+alias sb sandbox
+
+alias superh uboot, iwamatsu, marex
+alias sh superh
+
+alias x86 uboot, sjg, bmeng
+
+# Subsystem aliases
+alias dm uboot, sjg
+alias cfi uboot, stroese
+alias dfu uboot, lukma
+alias efi uboot, agraf
+alias eth uboot, jhersh
+alias kerneldoc uboot, marex
+alias fdt uboot, sjg
+alias i2c uboot, hs
+alias kconfig uboot, masahiro
+alias mmc uboot, freenix, jaehoon
+alias nand uboot
+alias net uboot, jhersh
+alias phy uboot, jhersh
+alias spi uboot, jagan
+alias spmi uboot, mateusz
+alias ubi uboot, hs
+alias usb uboot, marex
+alias xhci uboot, bmeng
+alias video uboot, ag
+alias patman uboot, sjg
+alias buildman uboot, sjg
+alias pmic uboot, jaehoon
diff --git a/roms/u-boot/doc/imx/ahab/csf_examples/csf_enc_boot_image.txt b/roms/u-boot/doc/imx/ahab/csf_examples/csf_enc_boot_image.txt
new file mode 100644
index 000000000..6c70db657
--- /dev/null
+++ b/roms/u-boot/doc/imx/ahab/csf_examples/csf_enc_boot_image.txt
@@ -0,0 +1,27 @@
+[Header]
+Target = AHAB
+Version = 1.0
+
+[Install SRK]
+# SRK table generated by srktool
+File = "./release/crts/SRK_1_2_3_4_table.bin"
+# Public key certificate in PEM format
+Source = "./release/crts/SRK1_sha384_secp384r1_v3_usr_crt.pem"
+# Index of the public key certificate within the SRK table (0 .. 3)
+Source index = 0
+# Type of SRK set (NXP or OEM)
+Source set = OEM
+# bitmask of the revoked SRKs
+Revocations = 0x0
+
+[Authenticate Data]
+# Binary to be signed generated by mkimage
+File = "flash.bin"
+# Offsets = Container header Signature block (printed out by mkimage)
+Offsets = 0x400 0x590
+
+[Install Secret Key]
+Key = "dek.bin"
+Key Length = 128
+#Key Identifier = 0x1234CAFE
+Image Indexes = 0xFFFFFFFE
diff --git a/roms/u-boot/doc/imx/ahab/guides/mx8_mx8x_encrypted_boot.txt b/roms/u-boot/doc/imx/ahab/guides/mx8_mx8x_encrypted_boot.txt
new file mode 100644
index 000000000..dfea4c827
--- /dev/null
+++ b/roms/u-boot/doc/imx/ahab/guides/mx8_mx8x_encrypted_boot.txt
@@ -0,0 +1,293 @@
+ +=========================================================+
+ + i.MX 8, i.MX 8X Encrypted Boot guide using AHAB +
+ +=========================================================+
+
+1. AHAB Encrypted Boot process
+-------------------------------
+
+This document describes a step-by-step procedure on how to encrypt and sign a
+bootloader image for i.MX8/8x family devices. It is assumed that the reader
+is familiar with basic AHAB concepts and has already closed the device,
+step-by-step procedure can be found in mx8_mx8x_secure_boot.txt and
+mx8_mx8x_spl_secure_boot.txt guides.
+
+The steps described in this document were based in i.MX8QM device, the same
+concept can be applied to others processors in i.MX8/8X family devices.
+
+1.1 Understanding the encrypted image signature block
+------------------------------------------------------
+
+As described in mx8_mx8x_secure_boot.txt guide a single binary is used to boot
+the device. The imx-mkimage tool combines all the input images in a container
+structure, generating a flash.bin binary.
+
+AHAB is able to decrypt image containers by calling SECO authentication
+functions, the image must be encrypted by CST and the resulting DEK (Data
+Encryption Key) must be encapsulated and included into the container signature
+block:
+
+ +----------------------------+
+ | | ^
+ | | |
+ | Container header | |
+ | | |
+ | | |
+ +---+------------------------+ |
+ | S | Signature block header | | Signed
+ | i +------------------------+ |
+ | g | | |
+ | n | | |
+ | a | SRK table | |
+ | t | | |
+ | u | | v
+ | r +------------------------+
+ | e | Signature |
+ | +------------------------+
+ | B | |
+ | l | SGK Key |
+ | o | Certificate (optional) |
+ | c | |
+ | k +------------------------+
+ | | DEK Blob |
+ +---+------------------------+
+
+1.1.1 Understanding and generating the DEK blob
+------------------------------------------------
+
+The encrypted boot image requires a DEK blob on each time AHAB is used to
+decrypt an image. The DEK blob is used as a security layer to wrap and store
+the DEK off-chip using the OTPMK which is unique per device.
+
+On i.MX8/8x devices the DEK blob is generated using the SECO API, the following
+funtion is available in U-Boot and can be executed through dek_blob command:
+
+- sc_seco_gen_key_blob(sc_ipc_t ipc, uint32_t id, sc_faddr_t load_addr,
+ sc_faddr_t export_addr, uint16_t max_size)
+
+Details in API usage can be found in SCFW API guide [1].
+
+1.2 Enabling the encrypted boot support in U-Boot
+--------------------------------------------------
+
+For deploying an encrypted boot image additional U-Boot tools are needed,
+please be sure to have the following features enabled, this can be achieved
+by following one of the methods below:
+
+- Defconfig:
+
+ CONFIG_AHAB_BOOT=y
+ CONFIG_CMD_DEKBLOB=y
+ CONFIG_IMX_SECO_DEK_ENCAP=y
+ CONFIG_FAT_WRITE=y
+
+- Kconfig:
+
+ ARM architecture -> Support i.MX8 AHAB features
+ ARM architecture -> Support the 'dek_blob' command
+ File systems -> Enable FAT filesystem support-> Enable FAT filesystem
+ write support
+
+1.3 Enabling the encrypted boot support in CST
+-----------------------------------------------
+
+The encryption feature is not enabled by default in Code Signing tools (CST).
+The CST backend must be recompiled, execute the following commands to enable
+encryption support in CST:
+
+ $ sudo apt-get install libssl-dev openssl
+ $ cd <CST install directory>/code/back_end/src
+ $ gcc -o cst_encrypted -I ../hdr -L ../../../linux64/lib *.c
+ -lfrontend -lcrypto
+ $ cp cst_encrypted ../../../linux64/bin/
+
+1.4 Preparing the image container
+----------------------------------
+
+The container generation is explained in and mx8_mx8x_secure_boot.txt and
+mx8_mx8x_spl_secure_boot.txt guides. This document is based in imx-mkimage
+flash target (2 containers in flash.bin).
+
+- Assembly flash.bin binary:
+
+ $ make SOC=<SoC Name> flash
+
+The mkimage log is used during the encrypted boot procedure to create the
+Command Sequence File (CSF):
+
+ CST: CONTAINER 0 offset: 0x400
+ CST: CONTAINER 0: Signature Block: offset is at 0x590
+ DONE.
+ Note: Please copy image to offset: IVT_OFFSET + IMAGE_OFFSET
+
+1.6 Creating the CSF description to encrypt the 2nd container
+--------------------------------------------------------------
+
+The csf_enc_boot_image.txt available under ahab/csf_examples/ can be used as
+example for encrypting the flash.bin binary, the main change is the Install
+Secret Key command that must be added after Authenticate Data command.
+
+ [Install Secret Key]
+ Key = "dek.bin"
+ Key Length = 128
+ #Key Identifier = 0x1234CAFE
+ Image Indexes = 0xFFFFFFFE
+
+By default all images are encrypted and image indexes parameter can be used
+to mask the images indexes that must be encrypted, on this example only the
+2nd container will be encrypted.
+
+Optionally users can provide a key identifier that must match the value
+provided during the blob generation, by default its value is zero.
+
+1.7 Encrypting the 2nd container
+---------------------------------
+
+The image is encrypted using the Code Signing Tool. The tool generates the
+encrypted image and a random dek.bin file.
+
+- Encrypt flash.bin binary:
+
+ $ ./cst_encrypted -i csf_enc_boot_image.txt -o enc_flash.bin
+ The DEK BLOB must be inserted at offset 0x7c0 (its expected size is 72 bytes)
+ CSF Processed successfully and signed image available in enc_boot_image.bin
+
+The output log will be used in a later step to insert the DEK blob into the
+signature block.
+
+1.8 Generating the DEK Blob
+----------------------------
+
+The DEK must be encapsulated into a CAAM blob so it can be included into the
+final encrypted binary. The U-Boot provides a tool called dek_blob which is
+calling the SECO blob encapsulation API.
+
+Copy the dek.bin in SDCard FAT partition and run the following commands from
+U-Boot prompt:
+
+ => mmc list
+ FSL_SDHC: 1 (SD)
+ FSL_SDHC: 2
+ => fatload mmc 1:1 0x80280000 dek.bin
+ => dek_blob 0x80280000 0x80280100 128
+ => fatwrite mmc 1:1 0x80280100 dek_blob.bin 0x48
+
+In host PC copy the generated dek_blob.bin to the CST directory.
+
+1.9 Assembling the encrypted image
+-----------------------------------
+
+The DEK blob generated in the step above have to be inserted into the container
+signature block.
+
+The CSF log is used to determine the DEK Blob offset:
+
+ The DEK BLOB must be inserted at offset 0x7c0 (its expected size is 72 bytes)
+ CSF Processed successfully and signed image available in enc_boot_image.bin
+
+- Insert DEK Blob into container signature block:
+
+ $ dd if=dek_blob.bin of=enc_flash.bin bs=1 seek=$((0x7c0)) conv=notrunc
+
+1.10 Flashing the encrypted boot image
+---------------------------------------
+
+The same offset is used for encrypted boot images, in case booting from
+eMMC/SDCard the offset is 32K.
+
+- Flash encrypted image in SDCard:
+
+ $ sudo dd if=enc_flash.bin of=/dev/sd<x> bs=1K seek=32 && sync
+
+2.0 Encrypting a standalone container
+--------------------------------------
+
+CST is also able to encrypt additional images containers, the steps documented
+in this section are based in OS container but can be also applied to SPL
+targets and 3rd containers.
+
+2.1 Creating the OS container
+------------------------------
+
+As explained in mx8_mx8x_secure_boot.txt guide the imx-mkimage tool is used to
+generate an image container for OS images, the mkimage log is used during the
+encrypted boot procedure to create the Command Sequence File (CSF).
+
+- Creating OS container:
+
+ $ make SOC=<SoC Name> flash_kernel
+ ...
+ CST: CONTAINER 0 offset: 0x0
+ CST: CONTAINER 0: Signature Block: offset is at 0x110
+
+2.2 Creating the CSF description file for standalone container
+---------------------------------------------------------------
+
+The Image Indexes parameter is used to mask the images that are encrypted by
+CST, as a single container is used for OS images the Image Indexes command can
+be commented or set to 0xFFFFFFFF.
+
+ [Install Secret Key]
+ Key = "dek_os.bin"
+ Key Length = 128
+ #Key Identifier = 0x1234CAFE
+ Image Indexes = 0xFFFFFFFF
+
+2.3 Encrypting the standalone container
+----------------------------------------
+
+As explained in section 1.7 the CST generates the encrypted image and a random
+dek.bin file.
+
+- Encrypt the standalone container:
+
+ $ ./cst_encrypted -i csf_linux_img.txt -o enc_flash_os.bin
+ The DEK BLOB must be inserted at offset 0x340 (its expected size is 72 bytes)
+ CSF Processed successfully and signed image available in enc_flash_os.bin
+
+The output log will be used in a later step to insert the DEK blob into the
+signature block.
+
+2.4 Generating the DEK Blob for standalone container
+----------------------------------------------------
+
+Similar to section 1.8 the DEK must be encapsulated into a CAAM blob so it can
+be included into the final encrypted binary.
+
+Copy the dek_os.bin in SDCard FAT partition and run the following commands from
+U-Boot prompt:
+
+ => mmc list
+ FSL_SDHC: 1 (SD)
+ FSL_SDHC: 2
+ => fatload mmc 1:1 0x80280000 dek_os.bin
+ => dek_blob 0x80280000 0x80280100 128
+ => fatwrite mmc 1:1 0x80280100 dek_blob_os.bin 0x48
+
+In host PC copy the generated dek_blob_os.bin to the CST directory.
+
+2.5 Assembling the encrypted image
+-----------------------------------
+
+The DEK blob generated in the step above have to be inserted into the container
+signature block.
+
+The CSF log is used to determine the DEK Blob offset:
+
+ The DEK BLOB must be inserted at offset 0x340 (its expected size is 72 bytes)
+ CSF Processed successfully and signed image available in enc_flash_os.bin
+
+- Insert DEK Blob into container signature block:
+
+ $ dd if=dek_blob_os.bin of=enc_flash_os.bin bs=1 seek=$((0x340)) conv=notrunc
+
+2.6 Copy encrypted image to SDCard
+-----------------------------------
+
+The encrypted container can be copied to SDCard FAT partition, please note
+that U-Boot requires signed and encrypted containers to be named as
+os_cntr_signed.bin.
+
+ $ sudo cp enc_flash_os.bin /media/UserID/Boot\ imx8/os_cntr_signed.bin
+
+References:
+[1] SCFW API guide: "System Controller Firmware API Reference Guide - Rev 1.5"
diff --git a/roms/u-boot/doc/imx/clk/ccf.txt b/roms/u-boot/doc/imx/clk/ccf.txt
new file mode 100644
index 000000000..f47ca8832
--- /dev/null
+++ b/roms/u-boot/doc/imx/clk/ccf.txt
@@ -0,0 +1,102 @@
+Introduction:
+=============
+
+This documentation entry describes the Common Clock Framework [CCF] port from
+Linux kernel (v5.1.12) to U-Boot.
+
+This code is supposed to bring CCF to IMX based devices (imx6q, imx7 imx8).
+Moreover, it also provides some common clock code, which would allow easy
+porting of CCF Linux code to other platforms.
+
+Design decisions:
+=================
+
+* U-Boot's driver model [DM] for clk differs from Linux CCF. The most notably
+ difference is the lack of support for hierarchical clocks and "clock as a
+ manager driver" (single clock DTS node acts as a starting point for all other
+ clocks).
+
+* The clk_get_rate() caches the previously read data if CLK_GET_RATE_NOCACHE is
+ not set (no need for recursive access).
+
+* On purpose the "manager" clk driver (clk-imx6q.c) is not using large table to
+ store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = .... Instead we
+ use udevice's linked list for the same class (UCLASS_CLK).
+
+ Rationale:
+ ----------
+ When porting the code as is from Linux, one would need ~1KiB of RAM to store
+ it. This is way too much if we do plan to use this driver in SPL.
+
+* The "central" structure of this patch series is struct udevice and its
+ uclass_priv field contains the struct clk pointer (to the originally created
+ one).
+
+* To keep things simple the struct udevice's uclass_priv pointer is used to
+ store back pointer to corresponding struct clk. However, it is possible to
+ modify clk-uclass.c file and add there struct uc_clk_priv, which would have
+ clock related members (like pointer to clk). As of this writing there is no
+ such need, so to avoid extra allocations (as it can be auto allocated by
+ setting .per_device_auto = sizeof(struct uc_clk_priv)) the
+ uclass_priv stores the pointer to struct clk.
+
+* Non-CCF clocks do not have a pointer to a clock in clk->dev->priv. In the case
+ of composite clocks, clk->dev->priv may not match clk. Drivers should always
+ use the struct clk which is passed to them, and not clk->dev->priv.
+
+* It is advised to add common clock code (like already added rate and flags) to
+ the struct clk, which is a top level description of the clock.
+
+* U-Boot's driver model already provides the facility to automatically allocate
+ (via private_alloc_size) device private data (accessible via dev->priv). It
+ may look appealing to use this feature to allocate private structures for CCF
+ clk devices e.g. divider (struct clk_divider *divider) for IMX6Q clock.
+
+ The above feature had not been used for following reasons:
+ - The original CCF Linux kernel driver is the "manager" for clocks - it
+ decides when clock is instantiated (and when memory for it is allocated).
+
+ - Using it would change the original structure of the CCF code.
+
+ - To bind (via clk_register()) the clock device with U-Boot driver model we
+ first need udevice for it (the "chicken and egg problem").
+
+* I've added the clk_get_parent(), which reads parent's dev->uclass_priv to
+ provide parent's struct clk pointer. This seems the easiest way to get
+ child/parent relationship for struct clk in U-Boot's udevice based clocks. In
+ the future arbitrary parents may be supported by adding a get_parent function
+ to clk_ops.
+
+* Linux's CCF 'struct clk_core' corresponds to U-Boot's udevice in 'struct clk'.
+ Clock IP block agnostic flags from 'struct clk_core' (e.g. NOCACHE) have been
+ moved from this struct one level up to 'struct clk'. Many flags are
+ unimplemented at the moment.
+
+* For tests the new ./test/dm/clk_ccf.c and ./drivers/clk/clk_sandbox_ccf.c
+ files have been introduced. The latter setups the CCF clock structure for
+ sandbox by reusing, if possible, generic clock primitives - like divier and
+ mux. The former file provides code to tests this setup.
+
+ For sandbox new CONFIG_SANDBOX_CLK_CCF Kconfig define has been introduced.
+ All new primitives added for new architectures must have corresponding test in
+ the two aforementioned files.
+
+Testing (sandbox):
+==================
+
+make mrproper; make sandbox_defconfig; make -j4
+./u-boot -i -d arch/sandbox/dts/test.dtb
+=> ut dm clk
+
+or in a more "scriptable" way (with -v to print debug output):
+./u-boot --fdt arch/sandbox/dts/test.dtb --command "ut dm clk_ccf" -v
+
+To do:
+------
+
+* Use of OF_PLATDATA in the SPL setup for CCF - as it is now - the SPL grows
+ considerably and using CCF in boards with tiny resources (OCRAM) is
+ problematic.
+
+* On demand port other parts of CCF to U-Boot - as now only features _really_
+ needed by DM/DTS converted drivers are used.
diff --git a/roms/u-boot/doc/imx/common/imx25.txt b/roms/u-boot/doc/imx/common/imx25.txt
new file mode 100644
index 000000000..0ca21b6df
--- /dev/null
+++ b/roms/u-boot/doc/imx/common/imx25.txt
@@ -0,0 +1,10 @@
+U-Boot for Freescale i.MX25
+
+This file contains information for the port of U-Boot to the Freescale i.MX25
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in the words 26 to 31 of fuse bank 0, using the
+ natural MAC byte order (i.e. MSB first).
diff --git a/roms/u-boot/doc/imx/common/imx27.txt b/roms/u-boot/doc/imx/common/imx27.txt
new file mode 100644
index 000000000..6f92cb47c
--- /dev/null
+++ b/roms/u-boot/doc/imx/common/imx27.txt
@@ -0,0 +1,10 @@
+U-Boot for Freescale i.MX27
+
+This file contains information for the port of U-Boot to the Freescale i.MX27
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in the words 4 to 9 of fuse bank 0, using the
+ reversed MAC byte order (i.e. LSB first).
diff --git a/roms/u-boot/doc/imx/common/imx5.txt b/roms/u-boot/doc/imx/common/imx5.txt
new file mode 100644
index 000000000..ea0e144ce
--- /dev/null
+++ b/roms/u-boot/doc/imx/common/imx5.txt
@@ -0,0 +1,40 @@
+U-Boot for Freescale i.MX5x
+
+This file contains information for the port of U-Boot to the Freescale
+i.MX5x SoCs.
+
+1. CONFIGURATION OPTIONS/SETTINGS
+---------------------------------
+
+1.1 CONFIG_MX51_PLL_ERRATA: Workaround for i.MX51 PLL errata.
+ This option should be enabled by all boards using the i.MX51 silicon
+ version up until (including) 3.0 running at 800MHz.
+ The PLL's in the i.MX51 processor can go out of lock due to a metastable
+ condition in an analog flip-flop when used at high frequencies.
+ This workaround implements an undocumented feature in the PLL (dither
+ mode), which causes the effect of this failure to be much lower (in terms
+ of frequency deviation), avoiding system failure, or at least decreasing
+ the likelihood of system failure.
+
+1.2 CONFIG_SYS_MAIN_PWR_ON: Trigger MAIN_PWR_ON upon startup.
+ This option should be enabled for boards having a SYS_ON_OFF_CTL signal
+ connected to GPIO1[23] and triggering the MAIN_PWR_ON signal like in the
+ reference designs.
+
+2. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+2.1 MAC Address: It is stored in the words 9 to 14 of fuse bank 1, using the
+ natural MAC byte order (i.e. MSB first).
+
+ This is an example how to program an example MAC address 01:23:45:67:89:ab
+ into the eFuses. Assure that the programming voltage is available and then
+ execute:
+
+ => fuse prog -y 1 9 01 23 45 67 89 ab
+
+ After programming a MAC address, consider locking the MAC fuses. This is
+ done by programming the MAC_ADDR_LOCK fuse, which is bit 4 of word 0 in
+ bank 1:
+
+ => fuse prog -y 1 0 10
diff --git a/roms/u-boot/doc/imx/common/imx6.txt b/roms/u-boot/doc/imx/common/imx6.txt
new file mode 100644
index 000000000..0b5061128
--- /dev/null
+++ b/roms/u-boot/doc/imx/common/imx6.txt
@@ -0,0 +1,164 @@
+U-Boot for Freescale i.MX6
+
+This file contains information for the port of U-Boot to the Freescale i.MX6
+SoC.
+
+1. CONVENTIONS FOR FUSE ASSIGNMENTS
+-----------------------------------
+
+1.1 MAC Address: It is stored in fuse bank 4, with the 32 lsbs in word 2 and the
+ 16 msbs in word 3[15:0].
+ For i.MX6SX and i.MX6UL, they have two MAC addresses. The second MAC address
+ is stored in fuse bank 4, with the 16 lsb in word 3[31:16] and the 32 msbs in
+ word 4.
+
+Example:
+
+For reading the MAC address fuses on a MX6Q:
+
+- The MAC address is stored in two fuse addresses (the fuse addresses are
+described in the Fusemap Descriptions table from the mx6q Reference Manual):
+
+0x620[31:0] - MAC_ADDR[31:0]
+0x630[15:0] - MAC_ADDR[47:32]
+
+In order to use the fuse API, we need to pass the bank and word values, which
+are calculated as below:
+
+Fuse address for the lower MAC address: 0x620
+Base address for the fuses: 0x400
+
+(0x620 - 0x400)/0x10 = 0x22 = 34 decimal
+
+As the fuses are arranged in banks of 8 words:
+
+34 / 8 = 4 and the remainder is 2, so in this case:
+
+bank = 4
+word = 2
+
+And the U-Boot command would be:
+
+=> fuse read 4 2
+Reading bank 4:
+
+Word 0x00000002: 9f027772
+
+Doing the same for the upper MAC address:
+
+Fuse address for the upper MAC address: 0x630
+Base address for the fuses: 0x400
+
+(0x630 - 0x400)/0x10 = 0x23 = 35 decimal
+
+As the fuses are arranged in banks of 8 words:
+
+35 / 8 = 4 and the remainder is 3, so in this case:
+
+bank = 4
+word = 3
+
+And the U-Boot command would be:
+
+=> fuse read 4 3
+Reading bank 4:
+
+Word 0x00000003: 00000004
+
+,which matches the ethaddr value:
+=> echo ${ethaddr}
+00:04:9f:02:77:72
+
+Some other useful hints:
+
+- The 'bank' and 'word' numbers can be easily obtained from the mx6 Reference
+Manual. For the mx6quad case, please check the "46.5 OCOTP Memory Map/Register
+Definition" from the "i.MX 6Dual/6Quad Applications Processor Reference Manual,
+Rev. 1, 04/2013" document. For example, for the MAC fuses we have:
+
+Address:
+21B_C620 Value of OTP Bank4 Word2 (MAC Address)(OCOTP_MAC0)
+
+21B_C630 Value of OTP Bank4 Word3 (MAC Address)(OCOTP_MAC1)
+
+- The command '=> fuse read 4 2 2' reads the whole MAC addresses at once:
+
+=> fuse read 4 2 2
+Reading bank 4:
+
+Word 0x00000002: 9f027772 00000004
+
+NAND Boot on i.MX6 with SPL support
+--------------------------------------
+
+Writing/updating boot image in nand device is not straight forward in
+i.MX6 platform and it requires boot control block(BCB) to be configured.
+
+BCB contains two data structures, Firmware Configuration Block(FCB) and
+Discovered Bad Block Table(DBBT). FCB has nand timings, DBBT search area,
+and firmware. See IMX6DQRM Section 8.5.2.2
+for more information.
+
+We can't use 'nand write' command to write SPL/firmware image directly
+like other platforms does. So we need special setup to write BCB block
+as per IMX6QDL reference manual 'nandbcb update' command do that job.
+
+for nand boot, up on reset bootrom look for FCB structure in
+first block's if FCB found the nand timings are loaded for
+further reads. once FCB read done, DTTB will be loaded and
+finally firmware will be loaded which is boot image.
+
+cmd_nandbcb will create FCB these structures
+by taking mtd partition as an example.
+- initial code will erase entire partition
+- followed by FCB setup, like first 2 blocks for FCB/DBBT write,
+ and next block for FW1/SPL
+- write firmware at FW1 block and
+- finally write fcb/dttb in first 2 block.
+
+Typical NAND BCB layout:
+=======================
+
+ no.of blocks = partition size / erasesize
+ no.of fcb/dbbt blocks = 2
+ FW1 offset = no.of fcb/dbbt
+
+block 0 1 2
+ -------------------------------
+ |FCB/DBBT 0|FCB/DBBT 1| FW 1 |
+ --------------------------------
+
+On summary, nandbcb update will
+- erase the entire partition
+- create BCB by creating 2 FCB/BDDT block followed by
+ 1 FW blocks based on partition size and erasesize.
+- fill FCB/DBBT structures
+- write FW/SPL in FW1
+- write FCB/DBBT in first 2 blocks
+
+step-1: write SPL
+
+icorem6qdl> ext4load mmc 0:1 $loadaddr SPL
+39936 bytes read in 10 ms (3.8 MiB/s)
+
+icorem6qdl> nandbcb update $loadaddr spl $filesize
+device 0 offset 0x0, size 0x9c00
+Erasing at 0x1c0000 -- 100% complete.
+NAND fw write: 0x80000 offset, 0xb000 bytes written: OK
+
+step-2: write u-boot-dtb.img
+
+icorem6qdl> nand erase.part uboot
+
+NAND erase.part: device 0 offset 0x200000, size 0x200000
+Erasing at 0x3c0000 -- 100% complete.
+OK
+
+icorem6qdl> ext4load mmc 0:1 $loadaddr u-boot-dtb.img
+589094 bytes read in 37 ms (15.2 MiB/s)
+
+icorem6qdl> nand write ${loadaddr} uboot ${filesize}
+
+NAND write: device 0 offset 0x200000, size 0x8fd26
+ 589094 bytes written: OK
+icorem6qdl>
diff --git a/roms/u-boot/doc/imx/common/mxs.txt b/roms/u-boot/doc/imx/common/mxs.txt
new file mode 100644
index 000000000..372062c0e
--- /dev/null
+++ b/roms/u-boot/doc/imx/common/mxs.txt
@@ -0,0 +1,290 @@
+Booting U-Boot on a MXS processor
+=================================
+
+This document describes the MXS U-Boot port. This document mostly covers topics
+related to making the module/board bootable.
+
+Terminology
+-----------
+
+The term "MXS" refers to a family of Freescale SoCs that is composed by MX23
+and MX28.
+
+The dollar symbol ($) introduces a snipped of shell code. This shall be typed
+into the unix command prompt in U-Boot source code root directory.
+
+The (=>) introduces a snipped of code that should by typed into U-Boot command
+prompt
+
+Contents
+--------
+
+1) Prerequisites
+2) Compiling U-Boot for a MXS based board
+3) Installation of U-Boot for a MXS based board to SD card
+4) Installation of U-Boot into NAND flash on a MX28 based board
+5) Installation of U-Boot into SPI NOR flash on a MX28 based board
+
+1) Prerequisites
+----------------
+
+To make a MXS based board bootable, some tools are necessary. The only
+mandatory tool is the "mxsboot" tool found in U-Boot source tree. The
+tool is built automatically when compiling U-Boot for i.MX23 or i.MX28.
+
+The production of BootStream image is handled via "mkimage", which is
+also part of the U-Boot source tree. The "mkimage" requires OpenSSL
+development libraries to be installed. In case of Debian and derivates,
+this is installed by running:
+
+ $ sudo apt-get install libssl-dev
+
+NOTE: The "elftosb" tool distributed by Freescale Semiconductor is no
+ longer necessary for general use of U-Boot on i.MX23 and i.MX28.
+ The mkimage supports generation of BootStream images encrypted
+ with a zero key, which is the vast majority of use-cases. In
+ case you do need to produce image encrypted with non-zero key
+ or other special features, please use the "elftosb" tool,
+ otherwise continue to section 2). The installation procedure of
+ the "elftosb" is outlined below:
+
+Firstly, obtain the elftosb archive from the following location:
+
+ ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
+
+We use a $VER variable here to denote the current version. At the time of
+writing of this document, that is "10.12.01". To obtain the file from command
+line, use:
+
+ $ VER="10.12.01"
+ $ wget http://repository.timesys.com/buildsources/e/elftosb/elftosb-10.12.01/elftosb-${VER}.tar.gz
+
+Extract the file:
+
+ $ tar xzf elftosb-${VER}.tar.gz
+
+Compile the file. We need to manually tell the linker to use also libm:
+
+ $ cd elftosb-${VER}/
+ $ make LIBS="-lstdc++ -lm" elftosb
+
+Optionally, remove debugging symbols from elftosb:
+
+ $ strip bld/linux/elftosb
+
+Finally, install the "elftosb" binary. The "install" target is missing, so just
+copy the binary by hand:
+
+ $ sudo cp bld/linux/elftosb /usr/local/bin/
+
+Make sure the "elftosb" binary can be found in your $PATH, in this case this
+means "/usr/local/bin/" has to be in your $PATH.
+
+2) Compiling U-Boot for a MXS based board
+-------------------------------------------
+
+Compiling the U-Boot for a MXS board is straightforward and done as compiling
+U-Boot for any other ARM device. For cross-compiler setup, please refer to
+ELDK5.0 documentation. First, clean up the source code:
+
+ $ make mrproper
+
+Next, configure U-Boot for a MXS based board
+
+ $ make <mxs_based_board_name>_config
+
+Examples:
+
+1. For building U-Boot for Aries M28EVK board:
+
+ $ make m28evk_config
+
+2. For building U-Boot for Freescale MX28EVK board:
+
+ $ make mx28evk_config
+
+3. For building U-Boot for Freescale MX23EVK board:
+
+ $ make mx23evk_config
+
+4. For building U-Boot for Olimex MX23 Olinuxino board:
+
+ $ make mx23_olinuxino_config
+
+Lastly, compile U-Boot and prepare a "BootStream". The "BootStream" is a special
+type of file, which MXS CPUs can boot. This is handled by the following
+command:
+
+ $ make u-boot.sb
+
+HINT: To speed-up the build process, you can add -j<N>, where N is number of
+ compiler instances that'll run in parallel.
+
+The code produces "u-boot.sb" file. This file needs to be augmented with a
+proper header to allow successful boot from SD or NAND. Adding the header is
+discussed in the following chapters.
+
+NOTE: The process that produces u-boot.sb uses the mkimage to generate the
+ BootStream. The BootStream is encrypted with zero key. In case you need
+ some special features of the BootStream and plan on using the "elftosb"
+ tool instead, the invocation to produce a compatible BootStream with the
+ one produced by mkimage is outlined below. For further details, refer to
+ the documentation bundled with the "elftosb" package.
+
+ $ elftosb -zf imx23 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd \
+ -o u-boot.sb
+ $ elftosb -zf imx28 -c arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd \
+ -o u-boot.sb
+
+3) Installation of U-Boot for a MXS based board to SD card
+----------------------------------------------------------
+
+To boot a MXS based board from SD, set the boot mode DIP switches according to
+to MX28 manual, section 12.2.1 (Table 12-2) or MX23 manual, section 35.1.2
+(Table 35-3).
+
+The SD card used to boot U-Boot must contain a DOS partition table, which in
+turn carries a partition of special type and which contains a special header.
+The rest of partitions in the DOS partition table can be used by the user.
+
+To prepare such partition, use your favourite partitioning tool. The partition
+must have the following parameters:
+
+ * Start sector .......... sector 2048
+ * Partition size ........ at least 1024 kb
+ * Partition type ........ 0x53 (sometimes "OnTrack DM6 Aux3")
+
+For example in Linux fdisk, the sequence for a clear card follows. Be sure to
+run fdisk with the option "-u=sectors" to set units to sectors:
+
+ * o ..................... create a clear partition table
+ * n ..................... create new partition
+ * p ............. primary partition
+ * 1 ............. first partition
+ * 2048 .......... first sector is 2048
+ * +1M ........... make the partition 1Mb big
+ * t 1 ................... change first partition ID
+ * 53 ............ change the ID to 0x53 (OnTrack DM6 Aux3)
+ * <create other partitions>
+ * w ..................... write partition table to disk
+
+The partition layout is ready, next the special partition must be filled with
+proper contents. The contents is generated by running the following command
+(see chapter 2)):
+
+ $ ./tools/mxsboot sd u-boot.sb u-boot.sd
+
+The resulting file, "u-boot.sd", shall then be written to the partition. In this
+case, we assume the first partition of the SD card is /dev/mmcblk0p1:
+
+ $ dd if=u-boot.sd of=/dev/mmcblk0p1
+
+Last step is to insert the card into the MXS based board and boot.
+
+NOTE: If the user needs to adjust the start sector, the "mxsboot" tool contains
+ a "-p" switch for that purpose. The "-p" switch takes the sector number as
+ an argument.
+
+4) Installation of U-Boot into NAND flash on a MX28 based board
+---------------------------------------------------------------
+
+To boot a MX28 based board from NAND, set the boot mode DIP switches according
+to MX28 manual section 12.2.1 (Table 12-2), PORT=GPMI, NAND 1.8 V.
+
+There are two possibilities when preparing an image writable to NAND flash.
+
+ I) The NAND wasn't written at all yet or the BCB is broken
+ ----------------------------------------------------------
+ In this case, both BCB (FCB and DBBT) and firmware needs to be
+ written to NAND. To generate NAND image containing all these,
+ there is a tool called "mxsboot" in the "tools/" directory. The tool
+ is invoked on "u-boot.sb" file from chapter 2):
+
+ $ ./tools/mxsboot nand u-boot.sb u-boot.nand
+
+ NOTE: The above invokation works for NAND flash with geometry of
+ 2048b per page, 64b OOB data, 128kb erase size. If your chip
+ has a different geometry, please use:
+
+ -w <size> change page size (default 2048 b)
+ -o <size> change oob size (default 64 b)
+ -e <size> change erase size (default 131072 b)
+
+ The geometry information can be obtained from running U-Boot
+ on the MX28 board by issuing the "nand info" command.
+
+ The resulting file, "u-boot.nand" can be written directly to NAND
+ from the U-Boot prompt. To simplify the process, the U-Boot default
+ environment contains script "update_nand_full" to update the system.
+
+ This script expects a working TFTP server containing the file
+ "u-boot.nand" in it's root directory. This can be changed by
+ adjusting the "update_nand_full_filename" variable.
+
+ To update the system, run the following in U-Boot prompt:
+
+ => run update_nand_full
+
+ In case you would only need to update the bootloader in future,
+ see II) below.
+
+ II) The NAND was already written with a good BCB
+ ------------------------------------------------
+ This part applies after the part I) above was done at least once.
+
+ If part I) above was done correctly already, there is no need to
+ write the FCB and DBBT parts of NAND again. It's possible to upgrade
+ only the bootloader image.
+
+ To simplify the process of firmware update, the U-Boot default
+ environment contains script "update_nand_firmware" to update only
+ the firmware, without rewriting FCB and DBBT.
+
+ This script expects a working TFTP server containing the file
+ "u-boot.sb" in it's root directory. This can be changed by
+ adjusting the "update_nand_firmware_filename" variable.
+
+ To update the system, run the following in U-Boot prompt:
+
+ => run update_nand_firmware
+
+ III) Special settings for the update scripts
+ --------------------------------------------
+ There is a slight possibility of the user wanting to adjust the
+ STRIDE and COUNT options of the NAND boot. For description of these,
+ see MX28 manual section 12.12.1.2 and 12.12.1.3.
+
+ The update scripts take this possibility into account. In case the
+ user changes STRIDE by blowing fuses, the user also has to change
+ "update_nand_stride" variable. In case the user changes COUNT by
+ blowing fuses, the user also has to change "update_nand_count"
+ variable for the update scripts to work correctly.
+
+ In case the user needs to boot a firmware image bigger than 1Mb, the
+ user has to adjust the "update_nand_firmware_maxsz" variable for the
+ update scripts to work properly.
+
+5) Installation of U-Boot into SPI NOR flash on a MX28 based board
+------------------------------------------------------------------
+
+The u-boot.sb file can be directly written to SPI NOR from U-Boot prompt.
+
+Load u-boot.sb into RAM, this can be done in several ways and one way is to use
+tftp:
+ => tftp u-boot.sb 0x42000000
+
+Probe the SPI NOR flash:
+ => sf probe
+
+(SPI NOR should be succesfully detected in this step)
+
+Erase the blocks where U-Boot binary will be written to:
+ => sf erase 0x0 0x80000
+
+Write u-boot.sb to SPI NOR:
+ => sf write 0x42000000 0 0x80000
+
+Power off the board and set the boot mode DIP switches to boot from the SPI NOR
+according to MX28 manual section 12.2.1 (Table 12-2)
+
+Last step is to power up the board and U-Boot should start from SPI NOR.
diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt b/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
new file mode 100644
index 000000000..bbe489714
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/additional_images/csf_additional_images.txt
@@ -0,0 +1,34 @@
+[Header]
+ Version = 4.2
+ Hash Algorithm = sha256
+ Engine Configuration = 0
+ Certificate Format = X509
+ Signature Format = CMS
+ Engine = CAAM
+
+[Install SRK]
+ # Index of the key location in the SRK table to be installed
+ File = "../crts/SRK_1_2_3_4_table.bin"
+ Source index = 0
+
+[Install CSFK]
+ # Key used to authenticate the CSF data
+ File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+ # Key slot index used to authenticate the key to be installed
+ Verification index = 0
+ # Target key slot in HAB key store where key will be installed
+ Target Index = 2
+ # Key to install
+ File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+ # Key slot index used to authenticate the image data
+ Verification index = 2
+ # Authenticate Start Address, Offset, Length and file
+ Blocks = 0x80800000 0x00000000 0x80EEA020 "zImage", \
+ 0x83800000 0x00000000 0x8380B927 "imx7d-sdb.dtb", \
+ 0x84000000 0x00000000 0x840425B8 "uTee-7dsdb"
diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
new file mode 100644
index 000000000..39986243e
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot.txt
@@ -0,0 +1,32 @@
+[Header]
+ Version = 4.2
+ Hash Algorithm = sha256
+ Engine Configuration = 0
+ Certificate Format = X509
+ Signature Format = CMS
+ Engine = CAAM
+
+[Install SRK]
+ # Index of the key location in the SRK table to be installed
+ File = "../crts/SRK_1_2_3_4_table.bin"
+ Source index = 0
+
+[Install CSFK]
+ # Key used to authenticate the CSF data
+ File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Install Key]
+ # Key slot index used to authenticate the key to be installed
+ Verification index = 0
+ # Target key slot in HAB key store where key will be installed
+ Target Index = 2
+ # Key to install
+ File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate Data]
+ # Key slot index used to authenticate the image data
+ Verification index = 2
+ # Authenticate Start Address, Offset, Length and file
+ Blocks = 0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
diff --git a/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
new file mode 100644
index 000000000..cdb34bcf7
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/csf_examples/mx6_mx7/csf_uboot_fast_authentication.txt
@@ -0,0 +1,23 @@
+[Header]
+ Version = 4.2
+ Hash Algorithm = sha256
+ Engine Configuration = 0
+ Certificate Format = X509
+ Signature Format = CMS
+ Engine = CAAM
+
+[Install SRK]
+ # Index of the key location in the SRK table to be installed
+ File = "../crts/SRK_1_2_3_4_table.bin"
+ Source index = 0
+
+[Install NOCAK]
+ File = "../crts/SRK1_sha256_2048_65537_v3_usr_crt.pem"
+
+[Authenticate CSF]
+
+[Authenticate Data]
+ # Key slot index 0 used to authenticate the image data
+ Verification index = 0
+ # Authenticate Start Address, Offset, Length and file
+ Blocks = 0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
diff --git a/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt b/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt
new file mode 100644
index 000000000..e2b435749
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/encrypted_boot.txt
@@ -0,0 +1,43 @@
+1. Setup U-Boot Image for Encrypted Boot
+----------------------------------------
+An authenticated U-Boot image is used as starting point for
+Encrypted Boot. The image is encrypted by i.MX Code Signing
+Tool (CST). The CST replaces only the image data of
+u-boot-dtb.imx with the encrypted data. The Initial Vector Table,
+DCD, and Boot data, remains in plaintext.
+
+The image data is encrypted with a Encryption Key (DEK).
+Therefore, this key is needed to decrypt the data during the
+booting process. The DEK is protected by wrapping it in a Blob,
+which needs to be appended to the U-Boot image and specified in
+the CSF file.
+
+The DEK blob is generated by an authenticated U-Boot image with
+the dek_blob cmd enabled. The image used for DEK blob generation
+needs to have the following configurations enabled in Kconfig:
+
+CONFIG_IMX_HAB=y
+CONFIG_CMD_DEKBLOB=y
+
+Note: The encrypted boot feature is only supported by HABv4 or
+greater.
+
+The dek_blob command then can be used to generate the DEK blob of
+a DEK previously loaded in memory. The command is used as follows:
+
+dek_blob <DEK address> <Output Address> <Key Size in Bits>
+example: dek_blob 0x10800000 0x10801000 192
+
+The resulting DEK blob then is used to construct the encrypted
+U-Boot image. Note that the blob needs to be transferred back
+to the host.Then the following commands are used to construct
+the final image.
+
+cat u-boot-dtb.imx csf-u-boot.bin > u-boot-signed.imx
+objcopy -I binary -O binary --pad-to <blob_dst> --gap-fill=0x00 \
+ u-boot-signed.imx u-boot-signed-pad.bin
+cat u-boot-signed-pad.imx DEK_blob.bin > u-boot-encrypted.imx
+
+ NOTE: u-boot-signed.bin needs to be padded to the value
+ equivalent to the address in which the DEK blob is specified
+ in the CSF.
diff --git a/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
new file mode 100644
index 000000000..53f71fbc3
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt
@@ -0,0 +1,427 @@
+ +=======================================================+
+ + i.MX6, i.MX7 U-Boot Secure Boot guide using HABv4 +
+ +=======================================================+
+
+1. HABv4 secure boot process
+-----------------------------
+
+This document describes a step-by-step procedure on how to sign and securely
+boot an U-Boot image for non-SPL targets. It is assumed that the reader is
+familiar with basic HAB concepts and with the PKI tree generation.
+
+Details about HAB can be found in the application note AN4581[1] and in the
+introduction_habv4.txt document.
+
+1.1 Building a u-boot-dtb.imx image supporting secure boot
+-----------------------------------------------------------
+
+The U-Boot provides support to secure boot configuration and also provide
+access to the HAB APIs exposed by the ROM vector table, the support is
+enabled by selecting the CONFIG_IMX_HAB option.
+
+When built with this configuration, the U-Boot provides extra functions for
+HAB, such as the HAB status logs retrievement through the hab_status command
+and support for extending the root of trust.
+
+The U-Boot also correctly pads the final image by aligning to the next 0xC00
+address, so the CSF signature data generated by CST can be concatenated to
+image.
+
+The diagram below illustrate a signed u-boot-dtb.imx image layout:
+
+ ------- +-----------------------------+ <-- *start
+ ^ | Image Vector Table |
+ | +-----------------------------+ <-- *boot_data
+ | | Boot Data |
+ | +-----------------------------+ <-- *dcd
+ | | DCD Table |
+ | +-----------------------------+
+ Signed | | Padding |
+ Data | +-----------------------------+ <-- *entry
+ | | |
+ | | |
+ | | u-boot-dtb.bin |
+ | | |
+ | | |
+ | +-----------------------------+
+ v | Padding |
+ ------- +-----------------------------+ <-- *csf
+ | |
+ | Command Sequence File (CSF) |
+ | |
+ +-----------------------------+
+ | Padding (optional) |
+ +-----------------------------+
+
+1.2 Enabling the secure boot support
+-------------------------------------
+
+The first step is to generate an U-Boot image supporting the HAB features
+mentioned above, this can be achieved by adding CONFIG_IMX_HAB to the
+build configuration:
+
+- Defconfig:
+
+ CONFIG_IMX_HAB=y
+
+- Kconfig:
+
+ ARM architecture -> Support i.MX HAB features
+
+1.3 Creating the CSF description file
+--------------------------------------
+
+The CSF contains all the commands that the HAB executes during the secure
+boot. These commands instruct the HAB on which memory areas of the image
+to authenticate, which keys to install, use and etc.
+
+CSF examples are available under doc/imx/habv4/csf_examples/ directory.
+
+A build log containing the "Authenticate Data" parameters is available after
+the U-Boot build, the example below is a log for mx7dsabresd_defconfig target:
+
+- mkimage build log:
+
+ $ cat u-boot-dtb.imx.log
+
+ Image Type: Freescale IMX Boot Image
+ Image Ver: 2 (i.MX53/6/7 compatible)
+ Mode: DCD
+ Data Size: 667648 Bytes = 652.00 KiB = 0.64 MiB
+ Load Address: 877ff420
+ Entry Point: 87800000
+ HAB Blocks: 0x877ff400 0x00000000 0x0009ec00
+ ^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^
+ | | |
+ | | ------- (1)
+ | |
+ | ------------------ (2)
+ |
+ ----------------------------- (3)
+
+ (1) Size of area in file u-boot-dtb.imx to sign.
+ This area should include the IVT, the Boot Data the DCD
+ and the U-Boot itself.
+ (2) Start of area in u-boot-dtb.imx to sign.
+ (3) Start of area in RAM to authenticate.
+
+- In "Authenticate Data" CSF command users can copy and past the output
+ addresses:
+
+ Block = 0x877ff400 0x00000000 0x0009ec00 "u-boot-dtb.imx"
+
+1.4 Signing the U-Boot binary
+------------------------------
+
+The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+users should input the CSF description file created in the step above and
+should receive a CSF binary, which contains the CSF commands, SRK table,
+signatures and certificates.
+
+- Create CSF binary file:
+
+ $ ./cst -i csf_uboot.txt -o csf_uboot.bin
+
+- Append CSF signature to the end of U-Boot image:
+
+ $ cat u-boot-dtb.imx csf_uboot.bin > u-boot-signed.imx
+
+The u-boot-signed.imx is the signed binary and should be flashed into the boot
+media.
+
+- Flash signed U-Boot binary:
+
+ $ sudo dd if=u-boot-signed.imx of=/dev/sd<x> bs=1K seek=1 && sync
+
+1.5 Programming SRK Hash
+-------------------------
+
+As explained in AN4581[1] and in introduction_habv4.txt document the SRK Hash
+fuse values are generated by the srktool and should be programmed in the
+SoC SRK_HASH[255:0] fuses.
+
+Be careful when programming these values, as this data is the basis for the
+root of trust. An error in SRK Hash results in a part that does not boot.
+
+The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs.
+
+- Dump SRK Hash fuses values in host machine:
+
+ $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin
+ 0x20593752
+ 0x6ACE6962
+ 0x26E0D06C
+ 0xFC600661
+ 0x1240E88F
+ 0x1209F144
+ 0x831C8117
+ 0x1190FD4D
+
+- Program SRK_HASH[255:0] fuses, using i.MX6 series as example:
+
+ => fuse prog 3 0 0x20593752
+ => fuse prog 3 1 0x6ACE6962
+ => fuse prog 3 2 0x26E0D06C
+ => fuse prog 3 3 0xFC600661
+ => fuse prog 3 4 0x1240E88F
+ => fuse prog 3 5 0x1209F144
+ => fuse prog 3 6 0x831C8117
+ => fuse prog 3 7 0x1190FD4D
+
+The table below lists the SRK_HASH bank and word according to the i.MX device:
+
+ +-------------------+---------------+---------------+---------------+
+ | | i.MX6 Series | i.MX7D/S | i.MX7ULP |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[31:00] | bank 3 word 0 | bank 6 word 0 | bank 5 word 0 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[63:32] | bank 3 word 1 | bank 6 word 1 | bank 5 word 1 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[95:64] | bank 3 word 2 | bank 6 word 2 | bank 5 word 2 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[127:96] | bank 3 word 3 | bank 6 word 3 | bank 5 word 3 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[159:128] | bank 3 word 4 | bank 7 word 0 | bank 5 word 4 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[191:160] | bank 3 word 5 | bank 7 word 1 | bank 5 word 5 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[223:192] | bank 3 word 6 | bank 7 word 2 | bank 5 word 6 |
+ +-------------------+---------------+---------------+---------------+
+ | SRK_HASH[255:224] | bank 3 word 7 | bank 7 word 3 | bank 5 word 7 |
+ +-------------------+---------------+---------------+---------------+
+
+1.6 Verifying HAB events
+-------------------------
+
+The next step is to verify that the signature attached to U-Boot is
+successfully processed without errors. HAB generates events when processing
+the commands if it encounters issues.
+
+The hab_status U-Boot command call the hab_report_event() and hab_status()
+HAB API functions to verify the processor security configuration and status.
+This command displays any events that were generated during the process.
+
+Prior to closing the device users should ensure no HAB events were found, as
+the example below:
+
+- Verify HAB events:
+
+ => hab_status
+
+ Secure boot disabled
+
+ HAB Configuration: 0xf0, HAB State: 0x66
+ No HAB Events Found!
+
+1.6.1 Verifying HAB events in i.MX7ULP
+---------------------------------------
+
+When booting i.MX7ULP in low power or dual boot modes the M4 binary is
+authenticated by an independent HAB in M4 ROM code using a
+different SRK key set.
+
+The U-Boot provides a M4 option in hab_status command so users can retrieve
+M4 HAB failure and warning events.
+
+- Verify HAB M4 events:
+
+ => hab_status m4
+
+ Secure boot disabled
+
+ HAB Configuration: 0xf0, HAB State: 0x66
+ No HAB Events Found!
+
+As HAB M4 API cannot be called from A7 core the command is parsing the M4 HAB
+persistent memory region, M4 software should not modify this reserved region.
+
+Details about HAB persistent memory region can be found in AN12263[2].
+
+1.7 Closing the device
+-----------------------
+
+After the device successfully boots a signed image without generating any HAB
+events, it is safe to close the device. This is the last step in the HAB
+process, and is achieved by programming the SEC_CONFIG[1] fuse bit.
+
+Once the fuse is programmed, the chip does not load an image that has not been
+signed using the correct PKI tree.
+
+- Program SEC_CONFIG[1] fuse, using i.MX6 series as example:
+
+ => fuse prog 0 6 0x00000002
+
+The table below list the SEC_CONFIG[1] bank and word according to the i.MX
+device:
+
+ +--------------+-----------------+------------+
+ | Device | Bank and Word | Value |
+ +--------------+-----------------+------------+
+ | i.MX6 Series | bank 0 word 6 | 0x00000002 |
+ +--------------+-----------------+------------+
+ | i.MX7D/S | bank 1 word 3 | 0x02000000 |
+ +--------------+-----------------+------------+
+ | i.MX7ULP | bank 29 word 6 | 0x80000000 |
+ +--------------+-----------------+------------+
+
+1.8 Completely secure the device
+---------------------------------
+
+Additional fuses can be programmed for completely secure the device, more
+details about these fuses and their possible impact can be found at AN4581[1].
+
+- Program SRK_LOCK, using i.MX6 series as example:
+
+ => fuse prog 0 0 0x4000
+
+- Program DIR_BT_DIS, using i.MX6 series as example:
+
+ => fuse prog 0 6 0x8
+
+- Program SJC_DISABLE, using i.MX6 series as example:
+
+ => fuse prog 0 6 0x100000
+
+- JTAG_SMODE, using i.MX6 series as example:
+
+ => fuse prog 0 6 0xC00000
+
+The table below list the SRK_LOCK, DIR_BT_DIS, SJC_DISABLE, and JTAG_SMODE bank
+and word according to the i.MX device:
+
+ +--------------+---------------+------------+
+ | Device | Bank and Word | Value |
+ +--------------+---------------+------------+
+ | SRK_LOCK |
+ +-------------------------------------------+
+ | i.MX6 Series | bank 0 word 0 | 0x00004000 |
+ +--------------+---------------+------------+
+ | i.MX7D/S | bank 0 word 0 | 0x00000200 |
+ +--------------+---------------+------------+
+ | i.MX7ULP | bank 1 word 1 | 0x00000080 |
+ +--------------+---------------+------------+
+ | DIR_BT_DIS |
+ +-------------------------------------------+
+ | i.MX6 Series | bank 0 word 6 | 0x00000008 |
+ +--------------+---------------+------------+
+ | i.MX7D/S | bank 1 word 3 | 0x08000000 |
+ +--------------+---------------+------------+
+ | i.MX7ULP | bank 1 word 1 | 0x00002000 |
+ +--------------+---------------+------------+
+ | SJC_DISABLE |
+ +-------------------------------------------+
+ | i.MX6 Series | bank 0 word 6 | 0x00100000 |
+ +--------------+---------------+------------+
+ | i.MX7D/S | bank 1 word 3 | 0x00200000 |
+ +--------------+---------------+------------+
+ | i.MX7ULP | bank 1 word 1 | 0x00000020 |
+ +--------------+---------------+------------+
+ | JTAG_SMODE |
+ +-------------------------------------------+
+ | i.MX6 Series | bank 0 word 6 | 0x00C00000 |
+ +--------------+---------------+------------+
+ | i.MX7D/S | bank 1 word 3 | 0x00C00000 |
+ +--------------+---------------+------------+
+ | i.MX7ULP | bank 1 word 1 | 0x000000C0 |
+ +--------------+---------------+------------+
+
+2. Extending the root of trust
+-------------------------------
+
+The High Assurance Boot (HAB) code located in the on-chip ROM provides an
+Application Programming Interface (API) making it possible to call back
+into the HAB code for authenticating additional boot images.
+
+The U-Boot supports this feature and can be used to authenticate the Linux
+Kernel Image.
+
+The process of signing an additional image is similar to the U-Boot.
+The diagram below illustrate the zImage layout:
+
+ ------- +-----------------------------+ <-- *load_address
+ ^ | |
+ | | |
+ | | |
+ | | |
+ | | zImage |
+ Signed | | |
+ Data | | |
+ | | |
+ | +-----------------------------+
+ | | Padding Next Boundary |
+ | +-----------------------------+ <-- *ivt
+ v | Image Vector Table |
+ ------- +-----------------------------+ <-- *csf
+ | |
+ | Command Sequence File (CSF) |
+ | |
+ +-----------------------------+
+ | Padding (optional) |
+ +-----------------------------+
+
+2.1 Padding the image
+----------------------
+
+The zImage must be padded to the next boundary address (0x1000), for instance
+if the image size is 0x649920 it must be padded to 0x64A000.
+
+The tool objcopy can be used for padding the image.
+
+- Pad the zImage:
+
+ $ objcopy -I binary -O binary --pad-to 0x64A000 --gap-fill=0x00 \
+ zImage zImage_pad.bin
+
+2.2 Generating Image Vector Table
+----------------------------------
+
+The HAB code requires an Image Vector Table (IVT) for determining the image
+length and the CSF location. Since zImage does not include an IVT this has
+to be manually created and appended to the end of the padded zImage, the
+script genIVT.pl in script_examples directory can be used as reference.
+
+- Generate IVT:
+
+ $ genIVT.pl
+
+Note: The load Address may change depending on the device.
+
+- Append the ivt.bin at the end of the padded zImage:
+
+ $ cat zImage_pad.bin ivt.bin > zImage_pad_ivt.bin
+
+2.3 Signing the image
+----------------------
+
+A CSF file has to be created to sign the image. HAB does not allow to change
+the SRK once the first image is authenticated, so the same SRK key used in
+U-Boot must be used when extending the root of trust.
+
+CSF examples are available in ../csf_examples/additional_images/
+directory.
+
+- Create CSF binary file:
+
+ $ ./cst --i csf_additional_images.txt --o csf_zImage.bin
+
+- Attach the CSF binary to the end of the image:
+
+ $ cat zImage_pad_ivt.bin csf_zImage.bin > zImage_signed.bin
+
+2.4 Verifying HAB events
+-------------------------
+
+The U-Boot includes the hab_auth_img command which can be used for
+authenticating and troubleshooting the signed image, zImage must be
+loaded at the load address specified in the IVT.
+
+- Authenticate additional image:
+
+ => hab_auth_img <Load Address> <Image Size> <IVT Offset>
+
+If no HAB events were found the zImage is successfully signed.
+
+References:
+[1] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
+[2] AN12263: "HABv4 RVT Guidelines and Recommendations" - Rev 0.
diff --git a/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
new file mode 100644
index 000000000..fde0f27ef
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/guides/mx6_mx7_spl_secure_boot.txt
@@ -0,0 +1,181 @@
+ +===============================================================+
+ + i.MX6, i.MX7 U-Boot HABv4 Secure Boot guide for SPL targets +
+ +===============================================================+
+
+1. HABv4 secure boot process
+-----------------------------
+
+This document is an addendum of mx6_mx7_secure_boot.txt guide describing a
+step-by-step procedure on how to sign and securely boot an U-Boot image for
+SPL targets.
+
+Details about HAB can be found in the application note AN4581[1] and in the
+introduction_habv4.txt document.
+
+1.1 Building a SPL target supporting secure boot
+-------------------------------------------------
+
+The U-Boot provides Second Program Loader (SPL) support which generates two
+final images, SPL and U-Boot proper. The HABv4 can be used to authenticate
+both binaries.
+
+Out of reset the ROM code authenticates the SPL which is responsible for
+initializing essential features such as DDR, UART, PMIC and clock
+enablement. Once the DDR is available, the SPL code loads the U-Boot proper
+image to its specific execution address and call the HAB APIs to extend the
+root of trust.
+
+The U-Boot provides support to secure boot configuration and also provide
+access to the HAB APIs exposed by the ROM vector table, the support is
+enabled by selecting the CONFIG_IMX_HAB option.
+
+When built with this configuration the U-Boot correctly pads the final SPL
+image by aligning to the next 0xC00 address, so the CSF signature data
+generated by CST can be concatenated to the image.
+
+The U-Boot also append an Image Vector Table (IVT) in the final U-Boot proper
+binary (u-boot-ivt.img) so it can be used by HAB API in a post ROM stage.
+
+The diagram below illustrate a signed SPL image layout:
+
+ ------- +-----------------------------+ <-- *start
+ ^ | Image Vector Table |
+ | +-----------------------------+ <-- *boot_data
+ | | Boot Data |
+ | +-----------------------------+
+ Signed | | Padding |
+ Data | +-----------------------------+ <-- *entry
+ | | |
+ | | SPL |
+ | | |
+ | +-----------------------------+
+ v | Padding |
+ ------- +-----------------------------+ <-- *csf
+ | |
+ | Command Sequence File (CSF) |
+ | |
+ +-----------------------------+
+ | Padding (optional) |
+ +-----------------------------+
+
+The diagram below illustrate a signed u-boot-ivt.img image layout:
+
+ ------- +-----------------------------+ <-- *load_address
+ ^ | |
+ | | |
+ | | u-boot.img |
+ Signed | | |
+ Data | | |
+ | +-----------------------------+
+ | | Padding Next Boundary |
+ | +-----------------------------+ <-- *ivt
+ v | Image Vector Table |
+ ------- +-----------------------------+ <-- *csf
+ | |
+ | Command Sequence File (CSF) |
+ | |
+ +-----------------------------+
+ | Padding (optional) |
+ +-----------------------------+
+
+1.2 Enabling the secure boot support
+-------------------------------------
+
+The first step is to generate an U-Boot image supporting the HAB features
+mentioned above, this can be achieved by adding CONFIG_IMX_HAB to the
+build configuration:
+
+- Defconfig:
+
+ CONFIG_IMX_HAB=y
+
+- Kconfig:
+
+ ARM architecture -> Support i.MX HAB features
+
+1.3 Creating the CSF description file
+--------------------------------------
+
+The CSF contains all the commands that the HAB executes during the secure
+boot. These commands instruct the HAB code on which memory areas of the image
+to authenticate, which keys to install, use and etc.
+
+CSF examples are available under doc/imx/habv4/csf_examples/ directory.
+
+Build logs containing the "Authenticate Data" parameters are available after
+the U-Boot build, the example below is a log for mx6sabresd_defconfig target:
+
+- SPL build log:
+
+ $ cat SPL.log
+ Image Type: Freescale IMX Boot Image
+ Image Ver: 2 (i.MX53/6/7 compatible)
+ Mode: DCD
+ Data Size: 69632 Bytes = 68.00 KiB = 0.07 MiB
+ Load Address: 00907420
+ Entry Point: 00908000
+ HAB Blocks: 0x00907400 0x00000000 0x0000ec00
+
+- u-boot-ivt.img build log:
+
+ $ cat u-boot-ivt.img.log
+ Image Name: U-Boot 2019.01-00003-g78ee492eb3
+ Created: Mon Jan 14 17:58:10 2019
+ Image Type: ARM U-Boot Firmware with HABv4 IVT (uncompressed)
+ Data Size: 458688 Bytes = 447.94 KiB = 0.44 MiB
+ Load Address: 17800000
+ Entry Point: 00000000
+ HAB Blocks: 0x177fffc0 0x0000 0x0006e020
+
+As explained in section above the SPL is first authenticated by the ROM code
+and the root of trust is extended to the U-Boot image, hence two CSF files are
+necessary to completely sign a bootloader image.
+
+In "Authenticate Data" CSF command users can copy and past the output
+addresses, the csf_uboot.txt can be used as example:
+
+- In csf_SPL.txt:
+
+ Block = 0x00907400 0x00000000 0x0000ec00 "SPL"
+
+- In csf_uboot-ivt.txt:
+
+ Block = 0x177fffc0 0x0000 0x0006e020 "u-boot-ivt.img"
+
+1.4 Signing the images
+-----------------------
+
+The CST tool is used for singing the U-Boot binary and generating a CSF binary,
+users should input the CSF description file created in the step above and
+receive a CSF binary, which contains the CSF commands, SRK table, signatures
+and certificates.
+
+- Create SPL CSF binary file:
+
+ $ ./cst -i csf_SPL.txt -o csf_SPL.bin
+
+- Append CSF signature to the end of SPL image:
+
+ $ cat SPL csf_SPL.bin > SPL-signed
+
+- Create U-Boot proper CSF binary file:
+
+ $ ./cst -i csf_uboot-ivt.txt -o csf_uboot-ivt.bin
+
+- Append CSF signature to the end of U-Boot proper image:
+
+ $ cat u-boot-ivt.img csf_uboot-ivt.bin > u-boot-signed.img
+
+The bootloader is signed and can be flashed into the boot media.
+
+1.5 Closing the device
+-----------------------
+
+The procedure for closing the device is similar as in Non-SPL targets, for a
+complete procedure please refer to section "1.5 Programming SRK Hash" in
+mx6_mx7_secure_boot.txt document available under doc/imx/habv4/guides/
+directory.
+
+References:
+[1] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
diff --git a/roms/u-boot/doc/imx/habv4/introduction_habv4.txt b/roms/u-boot/doc/imx/habv4/introduction_habv4.txt
new file mode 100644
index 000000000..25711bbe9
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/introduction_habv4.txt
@@ -0,0 +1,262 @@
+ +=======================================================+
+ + i.MX Secure and Encrypted Boot using HABv4 +
+ +=======================================================+
+
+1. Introduction
+----------------
+
+The i.MX family of applications processors provides the High Assurance Boot
+(HAB) feature in the on-chip ROM. The ROM is responsible for loading the
+initial program image (U-Boot) from the boot media and HAB enables the ROM
+to authenticate and/or decrypt the program image by using cryptography
+operations.
+
+This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and
+ i.MX 8M, i.MX 8MM devices.
+
+Step-by-step guides are available under doc/imx/habv4/guides/ directory,
+users familiar with HAB and CST PKI tree generation should refer to these
+documents instead.
+
+1.1 The HABv4 Secure Boot Architecture
+---------------------------------------
+
+The HABv4 secure boot feature uses digital signatures to prevent unauthorized
+software execution during the device boot sequence. In case a malware takes
+control of the boot sequence, sensitive data, services and network can be
+impacted.
+
+The HAB authentication is based on public key cryptography using the RSA
+algorithm in which image data is signed offline using a series of private
+keys. The resulting signed image data is then verified on the i.MX processor
+using the corresponding public keys. The public keys are included in the CSF
+binary and the SRK Hash is programmed in the SoC fuses for establishing the
+root of trust.
+
+The diagram below illustrate the secure boot process overview:
+
+ Host PC + CST i.MX + HAB
+ +----------+ +----------+
+ ---> | U-Boot | | Compare |
+ | +----------+ +----------+
+ | | ^ ^
+ | v Reference / \ Generated
+ | +----------+ Hash / \ Hash
+ | | Hash | Private / \
+ | +----------+ Key / \
+ | | | +----------+ +----------+
+ | v | | Verify | | Hash |
+ | +----------+ | +----------+ +----------+
+ | | Sign | <--- SRK ^ ^
+ | +----------+ HASH \ /
+ | | | CSF \ / U-Boot
+ | v v \ /
+ | +----------+ +----------+ +----------+
+ | | U-Boot | | | | U-Boot |
+ ---> | + | -----> | i.MX | -----> | + |
+ | CSF | | | | CSF |
+ +----------+ +----------+ +----------+
+
+The U-Boot image to be programmed into the boot media needs to be properly
+constructed i.e. it must contain a proper Command Sequence File (CSF).
+
+The CSF is a binary data structure interpreted by the HAB to guide
+authentication process, this is generated by the Code Signing Tool[1].
+The CSF structure contains the commands, SRK table, signatures and
+certificates.
+
+Details about the Secure Boot and Code Signing Tool (CST) can be found in
+the application note AN4581[2] and in the secure boot guides.
+
+1.2 The HABv4 Encrypted Boot Architecture
+------------------------------------------
+
+The HAB Encrypted Boot feature available in CAAM supported devices adds an
+extra security operation to the bootloading sequence. It uses cryptographic
+techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used
+by unauthorized users. This mechanism protects the U-Boot code residing on
+flash or external memory and also ensures that the final image is unique
+per device.
+
+The process can be divided into two protection mechanisms. The first mechanism
+is the bootloader code encryption which provides data confidentiality and the
+second mechanism is the digital signature, which authenticates the encrypted
+image.
+
+Keep in mind that the encrypted boot makes use of both mechanisms whatever the
+order is (sign and then encrypt, or encrypt and then sign), both operations
+can be applied on the same region with exception of the U-Boot Header (IVT,
+boot data and DCD) which can only be signed, not encrypted.
+
+The diagram below illustrate the encrypted boot process overview:
+
+ Host PC + CST i.MX + HAB
+ +------------+ +--------------+
+ | U-Boot | | U-Boot |
+ +------------+ +--------------+
+ | ^
+ | |
+ v DEK +--------------+
+ +------------+ | ----> | Decrypt |
+ | Encrypt | <--- | +--------------+
+ +------------+ DEK | ^
+ | | |
+ | Private | |
+ v Key +------+ +--------------+
+ +------------+ | | CAAM | | Authenticate |
+ | Sign | <--- +------+ +--------------+
+ +------------+ DEK ^ ^
+ | + OTPMK DEK \ / U-Boot
+ | | Blob \ / + CSF
+ v v \ /
+ +------------+ +----------+ +------------+
+ | Enc U-Boot | | | | Enc U-Boot |
+ | + CSF | ----> | i.MX | -------> | + CSF |
+ | + DEK Blob | | | | + DEK Blob |
+ +------------+ +----------+ +------------+
+ ^ |
+ | |
+ ---------------------
+ DEK Blob
+ (CAAM)
+
+The Code Signing Tool automatically generates a random AES Data Encryption Key
+(DEK) when encrypting an image. This key is used in both encrypt and decrypt
+operations and should be present in the final image structure encapsulated
+by a CAAM blob.
+
+The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob
+structure. The OTPMK is unique per device and can be accessed by CAAM only.
+To further add to the security of the DEK, the blob is decapsulated and
+decrypted inside a secure memory partition that can only be accessed by CAAM.
+
+During the design of encrypted boot using DEK blob, it is necessary to inhibit
+any modification or replacement of DEK blob with a counterfeit one allowing
+execution of malicious code. The PRIBLOB setting in CAAM allows secure boot
+software to have its own private blobs that cannot be decapsulated or
+encapsulated by any other user code, including any software running in trusted
+mode.
+
+Details about DEK Blob generation and PRIBLOB setting can be found in the
+encrypted boot guide and application note AN12056[3] .
+
+2. Generating a PKI tree
+-------------------------
+
+The first step is to generate the private keys and public keys certificates.
+The HAB architecture is based in a Public Key Infrastructure (PKI) tree.
+
+The Code Signing Tools package contains an OpenSSL based key generation script
+under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI
+tree containing up to 4 Super Root Keys (SRK) as well as their subordinated
+IMG and CSF keys.
+
+A new PKI tree can be generated by following the example below:
+
+- Generating 2048-bit PKI tree on CST v3.1.0:
+
+ $ ./hab4_pki_tree.sh
+ ...
+ Do you want to use an existing CA key (y/n)?: n
+ Do you want to use Elliptic Curve Cryptography (y/n)?: n
+ Enter key length in bits for PKI tree: 2048
+ Enter PKI tree duration (years): 5
+ How many Super Root Keys should be generated? 4
+ Do you want the SRK certificates to have the CA flag set? (y/n)?: y
+
+The diagram below illustrate the PKI tree:
+
+ +---------+
+ | CA |
+ +---------+
+ |
+ |
+ ---------------------------------------------------
+ | | | |
+ | | | |
+ v v v v
+ +--------+ +--------+ +--------+ +--------+
+ | SRK1 | | SRK2 | | SRK3 | | SRK4 |
+ +--------+ +--------+ +--------+ +--------+
+ / \ / \ / \ / \
+ v v v v v v v v
+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+ |CSF1| |IMG1| |CSF2| |IMG2| |CSF3| |IMG3| |CSF4| |IMG4|
+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
+
+After running the script users can check the private keys under keys/ directory
+and their respective X.509v3 public key certificates under crts/ directory.
+Those files will be used during the signing and authentication process.
+
+2.1 Generating a fast authentication PKI tree
+----------------------------------------------
+
+Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both
+CSF and IMG contents. This reduces the number of key pair authentications that
+must occur during the ROM/HAB boot stage, thus providing a faster boot process.
+
+The script hab4_pki_tree.sh is also able to generate a Public Key Infrastructure
+(PKI) tree which only contains SRK Keys, users should not set the CA flag when
+generating the SRK certificates.
+
+- Generating 2048-bit fast authentication PKI tree on CST v3.1.0:
+
+ $ ./hab4_pki_tree.sh
+ ...
+ Do you want to use an existing CA key (y/n)?: n
+ Do you want to use Elliptic Curve Cryptography (y/n)?: n
+ Enter key length in bits for PKI tree: 2048
+ Enter PKI tree duration (years): 5
+ How many Super Root Keys should be generated? 4
+ Do you want the SRK certificates to have the CA flag set? (y/n)?: n
+
+The diagram below illustrate the PKI tree generated:
+
+ +---------+
+ | CA |
+ +---------+
+ |
+ |
+ ---------------------------------------------------
+ | | | |
+ | | | |
+ v v v v
+ +--------+ +--------+ +--------+ +--------+
+ | SRK1 | | SRK2 | | SRK3 | | SRK4 |
+ +--------+ +--------+ +--------+ +--------+
+
+2.2 Generating a SRK Table and SRK Hash
+----------------------------------------
+
+The next step is to generated the SRK Table and its respective SRK Table Hash
+from the SRK public key certificates created in one of the steps above.
+
+In the HAB architecture, the SRK Table is included in the CSF binary and the
+SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses.
+
+On the target device during the authentication process the HAB code verify the
+SRK Table against the SoC SRK_HASH fuses, in case the verification success the
+root of trust is established and the HAB code can progress with the image
+authentication.
+
+The srktool can be used for generating the SRK Table and its respective SRK
+Table Hash.
+
+- Generating SRK Table and SRK Hash in Linux 64-bit machines:
+
+ $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \
+ SRK_1_2_3_4_fuse.bin -d sha256 -c \
+ SRK1_sha256_2048_65537_v3_ca_crt.pem,\
+ SRK2_sha256_2048_65537_v3_ca_crt.pem,\
+ SRK3_sha256_2048_65537_v3_ca_crt.pem,\
+ SRK4_sha256_2048_65537_v3_ca_crt.pem
+
+The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further
+steps as explained in HAB guides available under doc/imx/habv4/guides/
+directory.
+
+References:
+[1] CST: i.MX High Assurance Boot Reference Code Signing Tool.
+[2] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
+ HABv4" - Rev 2.
+[3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1
diff --git a/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl b/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl
new file mode 100644
index 000000000..84a4fcb16
--- /dev/null
+++ b/roms/u-boot/doc/imx/habv4/script_examples/genIVT.pl
@@ -0,0 +1,12 @@
+#! /usr/bin/perl -w
+use strict;
+open(my $out, '>:raw', 'ivt.bin') or die "Unable to open: $!";
+print $out pack("V", 0x412000D1); # Signature
+print $out pack("V", 0x80800000); # Load Address (*load_address)
+print $out pack("V", 0x0); # Reserved
+print $out pack("V", 0x0); # DCD pointer
+print $out pack("V", 0x0); # Boot Data
+print $out pack("V", 0x80EEA000); # Self Pointer (*ivt)
+print $out pack("V", 0x80EEA020); # CSF Pointer (*csf)
+print $out pack("V", 0x0); # Reserved
+close($out);
diff --git a/roms/u-boot/doc/imx/index.rst b/roms/u-boot/doc/imx/index.rst
new file mode 100644
index 000000000..b225b1d18
--- /dev/null
+++ b/roms/u-boot/doc/imx/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+NXP i.MX Machine-specific doc
+=============================
+
+.. toctree::
+ :maxdepth: 2
+
+ misc/index
diff --git a/roms/u-boot/doc/imx/misc/index.rst b/roms/u-boot/doc/imx/misc/index.rst
new file mode 100644
index 000000000..85fbdb658
--- /dev/null
+++ b/roms/u-boot/doc/imx/misc/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Miscellaneous
+=============
+
+.. toctree::
+ :maxdepth: 2
+
+ psb
diff --git a/roms/u-boot/doc/imx/misc/psb.rst b/roms/u-boot/doc/imx/misc/psb.rst
new file mode 100644
index 000000000..71ac09fac
--- /dev/null
+++ b/roms/u-boot/doc/imx/misc/psb.rst
@@ -0,0 +1,174 @@
+i.MX7D/i.MX8MM SRC_GPR10 PERSIST_SECONDARY_BOOT for bootloader A/B switching
+============================================================================
+
+Introduction
+------------
+Since at least iMX53 until iMX8MM, it is possible to have two copies of
+bootloader in SD/eMMC and switch between them. The switch is triggered
+either by the BootROM in case the bootloader image is faulty OR can be
+enforced by the user.
+
+Operation
+---------
+ #. Upon Power-On Reset (POR)
+
+ - SRC_GPR10 bit PERSIST_SECONDARY_BOOT is set to 0
+ - BootROM attempts to start bootloader A-copy
+
+ - if A-copy valid
+
+ - BootROM starts A-copy
+ - END
+
+ - if A-copy NOT valid
+
+ - BootROM sets SRC_GPR10 bit PERSIST_SECONDARY_BOOT to 1
+ - BootROM triggers WARM reset, GOTO 1)
+ - END
+
+ #. Upon COLD Reset
+
+ - GOTO 1)
+ - END
+
+ #. Upon WARM Reset
+
+ - SRC_GPR10 bit PERSIST_SECONDARY_BOOT is retained
+
+ - if SRC_GPR10 bit PERSIST_SECONDARY_BOOT is 0
+
+ - BootROM attempts to start bootloader A-copy
+
+ - if A-copy valid
+
+ - BootROM starts A-copy
+ - END
+
+ - if A-copy NOT valid
+
+ - BootROM sets SRC_GPR10 bit PERSIST_SECONDARY_BOOT to 1
+ - BootROM triggers WARM reset. GOTO 1.3)
+ - END
+
+ - if SRC_GPR10 bit PERSIST_SECONDARY_BOOT is 1
+
+ - BootROM attempts to start bootloader B-copy
+
+ - if B-copy valid
+
+ - BootROM starts B-copy
+ - END
+
+ - if B-copy NOT valid
+ - System hangs
+ - END
+
+Setup
+-----
+The bootloader A-copy must be placed at predetermined offset in SD/eMMC. The
+bootloader B-copy area offset is determined by an offset stored in Secondary
+Image Table (SIT). The SIT must be placed at predetermined offset in SD/eMMC.
+
+The following table contains offset of SIT, bootloader A-copy and recommended
+bootloader B-copy offset. The offsets are in 512 Byte sector units (that is
+offset 0x1 means 512 Bytes from the start of SD/eMMC card data partition).
+For details on the addition of two numbers in recommended B-copy offset, see
+SIT format below.
+
++----------+--------------------+-----------------------+-----------------------------+
+| SoC | SIT offset (fixed) | A-copy offset (fixed) | B-copy offset (recommended) |
++----------+--------------------+-----------------------+-----------------------------+
+| iMX7D | 0x1 | 0x2 | 0x800+0x2 |
++----------+--------------------+-----------------------+-----------------------------+
+| iMX8MM | 0x41 | 0x42 | 0x1000+0x42 |
++----------+--------------------+-----------------------+-----------------------------+
+
+SIT format
+~~~~~~~~~~
+SIT is a 20 byte long structure containing of 5 32-bit words. Those encode
+bootloader B-copy area offset (called "firstSectorNumber"), magic value
+(called "tag") that is always 0x00112233, and three unused words set to 0.
+SIT is documented in [1]_ and [2]_. Example SIT are below::
+
+ $ hexdump -vC sit-mx7d.bin
+ 00000000 00 00 00 00
+ 00000004 00 00 00 00
+ 00000008 33 22 11 00 <--- This is the "tag"
+ 0000000c 00 08 00 00 <--- This is the "firstSectorNumber"
+ 00000010 00 00 00 00
+
+ $ hexdump -vC sit-mx8mm.bin
+ 00000000 00 00 00 00
+ 00000004 00 00 00 00
+ 00000008 33 22 11 00 <--- This is the "tag"
+ 0000000c 00 10 00 00 <--- This is the "firstSectorNumber"
+ 00000010 00 00 00 00
+
+B-copy area offset ("firstSectorNumber") is offset, in units of 512 Byte
+sectors, that is added to the start of boot media when switching between
+A-copy and B-copy. For A-copy, this offset is 0x0. For B-copy, this offset
+is determined by SIT (e.g. if firstSectorNumber is 0x1000 as it is above
+in sit-mx8mm.bin, then the B-copy offset is 0x1000 sectors = 2 MiB).
+
+Bootloader A-copy (e.g. u-boot.imx or flash.bin) is placed at fixed offset
+from A-copy area offset (e.g. 0x2 sectors from sector 0x0 for iMX7D, which
+means u-boot.imx A-copy must be written to sector 0x2).
+
+The same applies to bootloader B-copy, which is placed at fixed offset from
+B-copy area offset determined by SIT (e.g. 0x2 sectors from sector 0x800 [see
+sit-mx7d.bin example above, this can be changed in SIT firstSectorNumber] for
+iMX7D, which means u-boot.imx B-copy must be written to sector 0x802)
+
+**WARNING:**
+B-copy area offset ("firstSectorNumber") is NOT equal to bootloader
+(image, which is u-boot.imx or flash.bin) B-copy offset.
+
+To generate SIT, use for example the following bourne shell printf command::
+
+$ printf '\x0\x0\x0\x0\x0\x0\x0\x0\x33\x22\x11\x00\x00\x08\x00\x00\x0\x0\x0\x0' > sit-mx7d.bin
+$ printf '\x0\x0\x0\x0\x0\x0\x0\x0\x33\x22\x11\x00\x00\x10\x00\x00\x0\x0\x0\x0' > sit-mx8mm.bin
+
+Write bootloader A/B copy and SIT to SD/eMMC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Examples of writing SIT and two copies of bootloader to SD or eMMC:
+
+- iMX8MM, SD card at /dev/sdX, Linux command line
+ ::
+
+ $ dd if=sit-mx8mm.bin of=/dev/sdX bs=512 seek=65
+ $ dd if=flash.bin of=/dev/sdX bs=512 seek=66
+ $ dd if=flash.bin of=/dev/sdX bs=512 seek=4162
+
+- iMX8MM, eMMC 1 data partition, U-Boot command line
+ ::
+
+ => mmc partconf 1 0 0 0
+
+ => dhcp ${loadaddr} sit-mx8mm.bin
+ => mmc dev 1
+ => mmc write ${loadaddr} 0x41 0x1
+
+ => dhcp ${loadaddr} flash.bin
+ => setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+ => mmc dev 1
+ => mmc write ${loadaddr} 0x42 ${blkcnt}
+ => mmc write ${loadaddr} 0x1042 ${blkcnt}
+
+WARM reset into B-copy using WDT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To perform a reboot into B-copy, the PERSIST_SECONDARY_BOOT must be set
+in SRC_GPR0 register. Example on iMX8MM::
+
+ => mw 0x30390098 0x40000000
+
+A WARM reset can be triggered using WDT as follows::
+
+ => mw.w 0x30280000 0x25
+
+References
+----------
+
+.. [1] i.MX 7Dual Applications Processor Reference Manual, Rev. 1, 01/2018 ; section 6.6.5.3.5 Redundant boot support for expansion device
+.. [2] i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 ; section 6.1.5.4.5 Redundant boot support for expansion device
diff --git a/roms/u-boot/doc/imx/misc/sdp.txt b/roms/u-boot/doc/imx/misc/sdp.txt
new file mode 100644
index 000000000..49b281234
--- /dev/null
+++ b/roms/u-boot/doc/imx/misc/sdp.txt
@@ -0,0 +1,118 @@
+-------------
+SDP in U-Boot
+-------------
+
+SDP stands for serial download protocol. It is the protocol used in NXP's
+i.MX SoCs ROM Serial Downloader and provides means to download a program
+image to the chip over USB and UART serial connection.
+
+The implementation in U-Boot uses the USB Downloader Gadget (g_dnl) to
+provide a SDP implementation over USB. This allows to download program
+images to the target in SPL/U-Boot using the same protocol/tooling the
+SoC's recovery mechanism is using.
+
+The SDP protocol over USB is a USB HID class protocol. USB HID class
+protocols allow to access a USB device without OS specific drivers. The
+U-Boot implementation has primarly been tested using the open source
+imx_loader utility (https://github.com/boundarydevices/imx_usb_loader).
+
+imx_usb_loader is a very nice tool by Boundary Devices that allow to
+install U-Boot without a JTAG debugger, using the USB boot mode as
+described in the manual. It is a replacement for Freescale's
+MFGTOOLS.
+
+The host side utilities are typically capable to interpret the i.MX
+specific image header (see doc/imx/mkimage/imximage.txt). There are extensions
+for imx_loader's imx_usb utility which allow to interpret the U-Boot
+specific legacy image format (see mkimage(1)). Also the U-Boot side
+support beside the i.MX specific header the U-Boot legacy header.
+
+1. Using imx_usb_loader for first install with SPL
+--------------------------------------------------
+
+This implementation can be started in U-Boot using the sdp command
+(CONFIG_CMD_USB_SDP) or in SPL if Serial Downloader boot mode has been
+detected (CONFIG_SPL_USB_SDP_SUPPORT).
+
+A typical use case is downloading full U-Boot after SPL has been
+downloaded through the boot ROM's Serial Downloader. Using boot mode
+detection the SPL will run the SDP implementation automatically in
+this case:
+
+ # imx_usb SPL
+
+Targets Serial Console:
+
+ Trying to boot from USB SDP
+ SDP: initialize...
+ SDP: handle requests...
+
+At this point the SPL reenumerated as a new HID device and emulating
+the boot ROM's SDP protocol. The USB VID/PID will depend on standard
+U-Boot configurations CONFIG_G_DNL_(VENDOR|PRODUCT)_NUM. Make sure
+imx_usb is aware of the USB VID/PID for your device by adding a
+configuration entry in imx_usb.conf:
+
+ 0x1b67:0x4fff, mx6_usb_sdp_spl.conf
+
+And the device specific configuration file mx6_usb_sdp_spl.conf:
+
+ mx6_spl_sdp
+ hid,uboot_header,1024,0x910000,0x10000000,1G,0x00900000,0x40000
+
+This allows to download the regular U-Boot with legacy image headers
+(u-boot.img) using a second invocation of imx_usb:
+
+ # imx_usb u-boot.img
+
+Furthermore, when U-Boot is running the sdp command can be used to
+download and run scripts:
+
+ # imx_usb script.scr
+
+imx_usb configuration files can be also used to download multiple
+files and of arbitrary types, e.g.
+
+ mx6_usb_sdp_uboot
+ hid,1024,0x10000000,1G,0x00907000,0x31000
+ full.itb:load 0x12100000
+ boot.scr:load 0x12000000,jump 0x12000000
+
+There is also a batch mode which allows imx_usb to handle multiple
+consecutive reenumerations by adding multiple VID/PID specifications
+in imx_usb.conf:
+
+ 0x15a2:0x0061, mx6_usb_rom.conf, 0x1b67:0x4fff, mx6_usb_sdp_spl.conf
+
+In this mode the file to download (imx_usb job) needs to be specified
+in the configuration files.
+
+mx6_usb_rom.conf:
+
+ mx6_qsb
+ hid,1024,0x910000,0x10000000,1G,0x00900000,0x40000
+ SPL:jump header2
+
+mx6_usb_sdp_spl.conf:
+
+ mx6_spl_sdp
+ hid,uboot_header,1024,0x10000000,1G,0x00907000,0x31000
+ u-boot.img:jump header2
+
+With that SPL and U-Boot can be downloaded with a single invocation
+of imx_usb without arguments:
+
+ # imx_usb
+
+2. Using imx_usb_loader non-SPL images
+---------------------------------------
+
+Booting in USB mode, the i.MX6 announces itself to the Linux Host as:
+
+Bus 001 Device 111: ID 15a2:0061 Freescale Semiconductor, Inc.
+
+imx_usb_loader is able to download a single file (u-boot.imx)
+to the board. For boards without SPL support, it is enough to
+issue the command:
+
+ sudo ../imx_usb_loader/imx_usb -v u-boot.imx
diff --git a/roms/u-boot/doc/imx/mkimage/imx8image.txt b/roms/u-boot/doc/imx/mkimage/imx8image.txt
new file mode 100644
index 000000000..76664a86f
--- /dev/null
+++ b/roms/u-boot/doc/imx/mkimage/imx8image.txt
@@ -0,0 +1,45 @@
+Introduction:
+=============
+
+This documentation entry describes the i.MX8 container format and how
+to use.
+
+A Boot image consists of:
+ - Primary Boot Container Set
+ - Optional Secondary Boot Container Set
+
+The imx8image only support the Primary Boot Container Set.
+
+The Primary Boot Container Set contains two containers. The 1st container
+only contain the SECO firmware image, the 2nd container can contain
+multiple images and typically have:
+ - SCF FW image
+ - M4 FW image
+ - AP FW image
+
+For more details, refer i.MX8 Reference Mannual Chapter 5
+"System Boot and section", "5.9 (Boot image) of the processor's manual"
+
+Configuration file:
+==================
+BOOT_FROM [sd|emmc_fastboot|fspi|nand_4k|nand_8k|nand_16k] [sector_size]
+ - indicates the boot media
+SOC_TYPE [IMX8QM|IMX8QX]
+ - indicates the soc
+APPEND [ahab container image]
+ - indicates the ahah image that will be put in the 1st container
+ When creating container image will be loaded by SPL, this entry
+ should not this included
+CONTAINER
+ - indicates to create the 2nd container
+IMAGE [SCU|M40|M41|A35|A53|A72] [image file] [load address]
+ - indicates images will be put in the 2nd container
+
+Example:
+=======
+BOOT_FROM SD 0x400
+SOC_TYPE IMX8QM
+APPEND mx8qm-ahab-container.img
+CONTAINER
+IMAGE SCU mx8qm-mek-scfw-tcm.bin
+IMAGE A35 spl/u-boot-spl.bin 0x00100000
diff --git a/roms/u-boot/doc/imx/mkimage/imximage.txt b/roms/u-boot/doc/imx/mkimage/imximage.txt
new file mode 100644
index 000000000..f2cf23c5d
--- /dev/null
+++ b/roms/u-boot/doc/imx/mkimage/imximage.txt
@@ -0,0 +1,239 @@
+---------------------------------------------
+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, 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. 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.
+
+For more details refer Chapter 2 - System Boot and section 2.14
+(flash header description) of the processor's manual.
+
+Command syntax:
+--------------
+./tools/mkimage -l <mx u-boot_file>
+ to list the imx image file details
+
+./tools/mkimage -T imximage \
+ -n <board specific configuration file> \
+ -e <execution address> -d <u-boot binary> <output image file>
+
+For example, for the mx51evk board:
+./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \
+ -T imximage -e 0x97800000 \
+ -d u-boot.bin u-boot.imx
+
+You can generate directly the image when you compile u-boot with:
+
+$ make u-boot.imx
+
+The output image can be flashed on the board SPI flash or on a SD card.
+In both cases, you have to copy the image at the offset required for the
+chosen media devices (0x400 for both SPI flash or SD card).
+
+Please check Freescale documentation for further details.
+
+Board specific configuration file specifications:
+-------------------------------------------------
+1. This file must present in the $(BOARDDIR) and the name should be
+ imximage.cfg (since this is used in Makefile).
+2. This file can have empty lines and lines starting with "#" as first
+ character to put comments.
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+---------------------------------
+1. Each command line is must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -------------- -----------
+ IMXIMAGE_VERSION 1/2
+ 1 is for mx25/mx35/mx51 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_OFFSET value
+
+ This command is parallel to BOOT_FROM and
+ is preferred over BOOT_FROM.
+
+ value: Offset of the image header, this
+ value shall be set to one of the
+ values found in the file:
+ arch/arm/include/asm/\
+ mach-imx/imximage.cfg
+ Example:
+ BOOT_OFFSET FLASH_OFFSET_STANDARD
+
+ BOOT_FROM nand/spi/sd/onenand/nor/sata
+
+ This command is parallel to BOOT_OFFSET and
+ is to be deprecated in favor of BOOT_OFFSET.
+
+ Example:
+ BOOT_FROM spi
+
+ CSF value
+
+ Total size of CSF (Command Sequence File)
+ used for Secure Boot/ High Assurance Boot
+ (HAB).
+
+ Using this command will populate the IVT
+ (Initial Vector Table) CSF pointer and adjust
+ the length fields only. The CSF itself needs
+ to be generated with Freescale tools and
+ 'manually' appended to the u-boot.imx file.
+
+ The CSF is then simply concatenated
+ to the u-boot image, making a signed bootloader,
+ that the processor can verify
+ if the fuses for the keys are burned.
+
+ Further infos how to configure the SOC to verify
+ the bootloader can be found in the "High
+ Assurance Boot Version Application Programming
+ Interface Reference Manual" as part of the
+ Freescale Code Signing Tool, available on the
+ manufacturer's website.
+
+ Example:
+ CSF 0x2000
+
+ DATA type address value
+
+ type: word=4, halfword=2, byte=1
+ address: physycal register address
+ value: value to be set in register
+ All values are in in hexadecimal.
+ Example (write to IOMUXC):
+ DATA 4 0x73FA88a0 0x200
+
+The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1
+and 220 register programming commands for IMXIMAGE_VERSION 2.
+An error is generated if more commands are found in the configuration file.
+
+3. All commands are optional to program.
+
+Setup a SD Card for booting
+--------------------------------
+
+The following example prepare a SD card with u-boot and a FAT partition
+to be used to stored the kernel to be booted.
+I will set the SD in the most compatible mode, setting it with
+255 heads and 63 sectors, as suggested from several documentation and
+howto on line (I took as reference the preparation of a SD Card for the
+Beagleboard, running u-boot as bootloader).
+
+You should start clearing the partitions table on the SD card. Because
+the u-boot image must be stored at the offset 0x400, it must be assured
+that there is no partition at that address. A new SD card is already
+formatted with FAT filesystem and the partition starts from the first
+cylinder, so we need to change it.
+
+You can do all steps with fdisk. If the device for the SD card is
+/dev/mmcblk0, the following commands make the job:
+
+1. Start the fdisk utility (as superuser)
+ fdisk /dev/mmcblk0
+
+2. Clear the actual partition
+
+Command (m for help): o
+
+3. Print card info:
+
+Command (m for help): p
+Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes
+
+In my case, I have a 2 GB card. I need the size to set later the correct value
+for the cylinders.
+
+4. Go to expert mode:
+
+Command (m for help): x
+
+5. Set card geometry
+
+Expert command (m for help): h
+Number of heads (1-256, default 4): 255
+
+Expert command (m for help): s
+Number of sectors (1-63, default 16): 63
+Warning: setting sector offset for DOS compatiblity
+
+We have set 255 heads, 63 sector. We have to set the cylinder.
+The value to be set can be calculated with:
+
+ cylinder = <total size> / <heads> / <sectors> / <blocksize>
+
+in this example,
+ 1981284352 / 255 / 63 / 512 = 239.x = 239
+
+
+Expert command (m for help): c
+Number of cylinders (1-1048576, default 60032): 239
+
+6. Leave the expert mode
+Expert command (m for help): r
+
+7. Set up a partition
+
+Now set a partition table to store the kernel or whatever you want. Of course,
+you can set additional partitions to store rootfs, data, etc.
+In my example I want to set a single partition. I must take care
+to not overwrite the space where I will put u-boot.
+
+Command (m for help): n
+Command action
+ e extended
+ p primary partition (1-4)
+p
+Partition number (1-4): 1
+First cylinder (1-239, default 1): 3
+Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M
+
+Command (m for help): p
+
+Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes
+255 heads, 63 sectors/track, 239 cylinders
+Units = cylinders of 16065 * 512 = 8225280 bytes
+Disk identifier: 0xb712a870
+
+ Device Boot Start End Blocks Id System
+/dev/mmcblk0p1 3 16 112455 83 Linux
+
+I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
+there.
+
+8. Write the partition table and exit.
+
+Command (m for help): w
+The partition table has been altered!
+
+Calling ioctl() to re-read partition table.
+
+9. Copy u-boot.imx on the SD card
+
+I use dd:
+
+dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
+
+This command copies the u-boot image at the address 0x400, as required
+by the processor.
+
+Now remove your card from the PC and go to the target. If evrything went right,
+the u-boot prompt should come after power on.
+
+------------------------------------------------
+Author: Stefano babic <sbabic@denx.de>
diff --git a/roms/u-boot/doc/imx/mkimage/mxsimage.txt b/roms/u-boot/doc/imx/mkimage/mxsimage.txt
new file mode 100644
index 000000000..9159f93a9
--- /dev/null
+++ b/roms/u-boot/doc/imx/mkimage/mxsimage.txt
@@ -0,0 +1,170 @@
+Freescale i.MX233/i.MX28 SB image generator via mkimage
+=======================================================
+
+This tool allows user to produce SB BootStream encrypted with a zero key.
+Such a BootStream is then bootable on i.MX23/i.MX28.
+
+Usage -- producing image:
+=========================
+The mxsimage tool is targeted to be a simple replacement for the elftosb2 .
+To generate an image, write an image configuration file and run:
+
+ mkimage -A arm -O u-boot -T mxsimage -n <path to configuration file> \
+ <output bootstream file>
+
+The output bootstream file is usually using the .sb file extension. Note
+that the example configuration files for producing bootable BootStream with
+the U-Boot bootloader can be found under arch/arm/boot/cpu/arm926ejs/mxs/
+directory. See the following files:
+
+ mxsimage.mx23.cfg -- This is an example configuration for i.MX23
+ mxsimage.mx28.cfg -- This is an example configuration for i.MX28
+
+Each configuration file uses very simple instruction semantics and a few
+additional rules have to be followed so that a useful image can be produced.
+These semantics and rules will be outlined now.
+
+- Each line of the configuration file contains exactly one instruction.
+- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
+- The configuration file is a concatenation of blocks called "sections" and
+ optionally "DCD blocks" (see below), and optional flags lines.
+ - Each "section" is started by the "SECTION" instruction.
+ - The "SECTION" instruction has the following semantics:
+
+ SECTION u32_section_number [BOOTABLE]
+ - u32_section_number :: User-selected ID of the section
+ - BOOTABLE :: Sets the section as bootable
+
+ - A bootable section is one from which the BootROM starts executing
+ subsequent instructions or code. Exactly one section must be selected
+ as bootable, usually the one containing the instructions and data to
+ load the bootloader.
+
+ - A "SECTION" must be immediatelly followed by a "TAG" instruction.
+ - The "TAG" instruction has the following semantics:
+
+ TAG [LAST]
+ - LAST :: Flag denoting the last section in the file
+
+ - After a "TAG" instruction, any of the following instructions may follow
+ in any order and any quantity:
+
+ NOOP
+ - This instruction does nothing
+
+ LOAD u32_address string_filename
+ - Instructs the BootROM to load file pointed by "string_filename" onto
+ address "u32_address".
+
+ LOAD IVT u32_address u32_IVT_entry_point
+ - Crafts and loads IVT onto address "u32_address" with the entry point
+ of u32_IVT_entry_point.
+ - i.MX28-specific instruction!
+
+ LOAD DCD u32_address u32_DCD_block_ID
+ - Loads the DCD block with ID "u32_DCD_block_ID" onto address
+ "u32_address" and executes the contents of this DCD block
+ - i.MX28-specific instruction!
+
+ FILL u32_address u32_pattern u32_length
+ - Starts to write memory from addres "u32_address" with a pattern
+ specified by "u32_pattern". Writes exactly "u32_length" bytes of the
+ pattern.
+
+ JUMP [HAB] u32_address [u32_r0_arg]
+ - Jumps onto memory address specified by "u32_address" by setting this
+ address in PT. The BootROM will pass the "u32_r0_arg" value in ARM
+ register "r0" to the executed code if this option is specified.
+ Otherwise, ARM register "r0" will default to value 0x00000000. The
+ optional "HAB" flag is i.MX28-specific flag turning on the HAB boot.
+
+ CALL [HAB] u32_address [u32_r0_arg]
+ - See JUMP instruction above, as the operation is exactly the same with
+ one difference. The CALL instruction does allow returning into the
+ BootROM from the executed code. U-Boot makes use of this in it's SPL
+ code.
+
+ MODE string_mode
+ - Restart the CPU and start booting from device specified by the
+ "string_mode" argument. The "string_mode" differs for each CPU
+ and can be:
+ i.MX23, string_mode = USB/I2C/SPI1_FLASH/SPI2_FLASH/NAND_BCH
+ JTAG/SPI3_EEPROM/SD_SSP0/SD_SSP1
+ i.MX28, string_mode = USB/I2C/SPI2_FLASH/SPI3_FLASH/NAND_BCH
+ JTAG/SPI2_EEPROM/SD_SSP0/SD_SSP1
+
+ - An optional "DCD" blocks can be added at the begining of the configuration
+ file. Note that the DCD is only supported on i.MX28.
+ - The DCD blocks must be inserted before the first "section" in the
+ configuration file.
+ - The DCD block has the following semantics:
+
+ DCD u32_DCD_block_ID
+ - u32_DCD_block_ID :: The ID number of the DCD block, must match
+ the ID number used by "LOAD DCD" instruction.
+
+ - The DCD block must be followed by one of the following instructions. All
+ of the instructions operate either on 1, 2 or 4 bytes. This is selected by
+ the 'n' suffix of the instruction:
+
+ WRITE.n u32_address u32_value
+ - Write the "u32_value" to the "u32_address" address.
+
+ ORR.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-OR with the "u32_value" and
+ write the result back to "u32_address".
+
+ ANDC.n u32_address u32_value
+ - Read the "u32_address", perform a bitwise-AND with the complement of
+ "u32_value" and write the result back to "u32_address".
+
+ EQZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is zero. If it is, break the loop earlier.
+
+ NEZ.n u32_address u32_count
+ - Read the "u32_address" at most "u32_count" times and test if the value
+ read is non-zero. If it is, break the loop earlier.
+
+ EQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" equals the "u32_mask". If the values are equal, break the
+ reading loop.
+
+ NEQ.n u32_address u32_mask
+ - Read the "u32_address" in a loop and test if the result masked with
+ "u32_mask" does not equal the "u32_mask". If the values are not equal,
+ break the reading loop.
+
+ NOOP
+ - This instruction does nothing.
+
+ - An optional flags lines can be one of the following:
+
+ DISPLAYPROGRESS
+ - Enable boot progress output from the BootROM.
+
+- If the boot progress output from the BootROM is enabled, the BootROM will
+ produce a letter on the Debug UART for each instruction it started processing.
+ Here is a mapping between the above instructions and the BootROM output:
+
+ H -- SB Image header loaded
+ T -- TAG instruction
+ N -- NOOP instruction
+ L -- LOAD instruction
+ F -- FILL instruction
+ J -- JUMP instruction
+ C -- CALL instruction
+ M -- MODE instruction
+
+Usage -- verifying image:
+=========================
+
+The mxsimage can also verify and dump contents of an image. Use the following
+syntax to verify and dump contents of an image:
+
+ mkimage -l <input bootstream file>
+
+This will output all the information from the SB image header and all the
+instructions contained in the SB image. It will also check if the various
+checksums in the SB image are correct.
diff --git a/roms/u-boot/doc/index.rst b/roms/u-boot/doc/index.rst
new file mode 100644
index 000000000..8066fcbfc
--- /dev/null
+++ b/roms/u-boot/doc/index.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+.. _u-boot_doc:
+
+The U-Boot Documentation
+========================
+
+This is the top level of the U-Boot's documentation tree. U-Boot
+documentation, like the U-Boot itself, is very much a work in progress;
+that is especially true as we work to integrate our many scattered
+documents into a coherent whole. Please note that improvements to the
+documentation are welcome; join the U-Boot list at http://lists.denx.de
+if you want to help out.
+
+.. toctree::
+ :maxdepth: 2
+
+User-oriented documentation
+---------------------------
+
+The following manuals are written for *users* of the U-Boot - those who are
+trying to get it to work optimally on a given system.
+
+.. toctree::
+ :maxdepth: 2
+
+ build/index
+ usage/index
+
+Developer-oriented documentation
+--------------------------------
+
+The following manuals are written for *developers* of the U-Boot - those who
+want to contribute to U-Boot.
+
+.. toctree::
+ :maxdepth: 2
+
+ develop/index
+
+
+U-Boot API documentation
+------------------------
+
+These books get into the details of how specific U-Boot subsystems work
+from the point of view of a U-Boot developer. Much of the information here
+is taken directly from the U-Boot source, with supplemental material added
+as needed (or at least as we managed to add it - probably *not* all that is
+needed).
+
+.. toctree::
+ :maxdepth: 2
+
+ api/index
+
+Architecture-specific doc
+-------------------------
+
+These books provide programming details about architecture-specific
+implementation.
+
+.. toctree::
+ :maxdepth: 2
+
+ arch/index
+
+Machine-specific doc
+--------------------
+
+These books provide programming details about machine-specific
+implementation.
+
+.. toctree::
+ :maxdepth: 2
+
+ imx/index
+
+Board-specific doc
+------------------
+
+These books provide details about board-specific information. They are
+organized in a vendor subdirectory.
+
+.. toctree::
+ :maxdepth: 2
+
+ board/index
+
+Android-specific doc
+--------------------
+
+These books provide information about booting the Android OS from U-Boot,
+manipulating Android images from U-Boot shell and discusses other
+Android-specific features available in U-Boot.
+
+.. toctree::
+ :maxdepth: 2
+
+ android/index
+
+Chromium OS-specific doc
+------------------------
+
+.. toctree::
+ :maxdepth: 2
+
+ chromium/index
+
+Indices and tables
+==================
+
+* :ref:`genindex`
diff --git a/roms/u-boot/doc/kwboot.1 b/roms/u-boot/doc/kwboot.1
new file mode 100644
index 000000000..1e9ca268f
--- /dev/null
+++ b/roms/u-boot/doc/kwboot.1
@@ -0,0 +1,84 @@
+.TH KWBOOT 1 "2012-05-19"
+
+.SH NAME
+kwboot \- Boot Marvell Kirkwood SoCs over a serial link.
+.SH SYNOPSIS
+.B kwboot
+.RB [ "-b \fIimage\fP" ]
+.RB [ "-p" ]
+.RB [ "-t" ]
+.RB [ "-B \fIbaudrate\fP" ]
+.RB \fITTY\fP
+.SH "DESCRIPTION"
+
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+platform over their integrated UART. Boot image files will typically
+contain a second stage boot loader, such as U-Boot. The image file
+must conform to Marvell's BootROM firmware image format
+(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
+
+Following power-up or a system reset, system BootROM code polls the
+UART for a brief period of time, sensing a handshake message which
+initiates an image upload. This program sends this boot message until
+it receives a positive acknowledgement. The image is transferred using
+Xmodem.
+
+Additionally, this program implements a minimal terminal mode, which
+can be used either standalone, or entered immediately following boot
+image transfer completion. This is often useful to catch early boot
+messages, or to manually interrupt a default boot procedure performed
+by the second-stage loader.
+
+.SH "OPTIONS"
+
+.TP
+.BI "\-b \fIimage\fP"
+Handshake; then upload file \fIimage\fP over \fITTY\fP.
+
+Note that for the encapsulated boot code to be executed, \fIimage\fP
+must be of type "UART boot" (0x69). Boot images of different types,
+such as backup images of vendor firmware downloaded from flash memory
+(type 0x8B), will not work (or not as expected). See \fB-p\fP for a
+workaround.
+
+This mode writes handshake status and upload progress indication to
+stdout.
+
+.TP
+.BI "\-p"
+In combination with \fB-b\fP, patches the header in \fIimage\fP prior
+to upload, to "UART boot" type.
+
+This option attempts on-the-fly conversion of some none-UART image
+types, such as images which were originally formatted to be stored in
+flash memory.
+
+Conversion is performed in memory. The contents of \fIimage\fP will
+not be altered.
+
+.TP
+.BI "\-t"
+Run a terminal program, connecting standard input and output to
+.RB \fITTY\fP.
+
+If used in combination with \fB-b\fP, terminal mode is entered
+immediately following a successful image upload.
+
+If standard I/O streams connect to a console, this mode will terminate
+after receiving 'ctrl-\\' followed by 'c' from console input.
+
+.TP
+.BI "\-B \fIbaudrate\fP"
+Adjust the baud rate on \fITTY\fP. Default rate is 115200.
+
+.SH "SEE ALSO"
+.PP
+\fBmkimage\fP(1)
+
+.SH "AUTHORS"
+
+Daniel Stodden <daniel.stodden@gmail.com>
+.br
+Luka Perkov <luka@openwrt.org>
+.br
+David Purdy <david.c.purdy@gmail.com>
diff --git a/roms/u-boot/doc/media/Makefile b/roms/u-boot/doc/media/Makefile
new file mode 100644
index 000000000..b9b43a34c
--- /dev/null
+++ b/roms/u-boot/doc/media/Makefile
@@ -0,0 +1,38 @@
+# Rules to convert a .h file to inline RST documentation
+
+SRC_DIR=$(srctree)/doc/media
+PARSER = $(srctree)/doc/sphinx/parse-headers.pl
+API = $(srctree)/include
+
+FILES = linker_lists.h.rst
+
+TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
+
+gen_rst = \
+ echo ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions; \
+ ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
+
+quiet_gen_rst = echo ' PARSE $(patsubst $(srctree)/%,%,$<)'; \
+ ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
+
+silent_gen_rst = ${gen_rst}
+
+$(BUILDDIR)/linker_lists.h.rst: ${API}/linker_lists.h ${PARSER} $(SRC_DIR)/linker_lists.h.rst.exceptions
+ @$($(quiet)gen_rst)
+
+# Media build rules
+
+.PHONY: all html epub xml latex
+
+all: $(IMGDOT) $(BUILDDIR) ${TARGETS}
+html: all
+epub: all
+xml: all
+latex: $(IMGPDF) all
+linkcheck:
+
+clean:
+ -rm -f $(DOTTGT) $(IMGTGT) ${TARGETS} 2>/dev/null
+
+$(BUILDDIR):
+ $(Q)mkdir -p $@
diff --git a/roms/u-boot/doc/media/linker_lists.h.rst.exceptions b/roms/u-boot/doc/media/linker_lists.h.rst.exceptions
new file mode 100644
index 000000000..e69de29bb
--- /dev/null
+++ b/roms/u-boot/doc/media/linker_lists.h.rst.exceptions
diff --git a/roms/u-boot/doc/mkimage.1 b/roms/u-boot/doc/mkimage.1
new file mode 100644
index 000000000..fea528878
--- /dev/null
+++ b/roms/u-boot/doc/mkimage.1
@@ -0,0 +1,242 @@
+.TH MKIMAGE 1 "2010-05-16"
+
+.SH NAME
+mkimage \- Generate image for U-Boot
+.SH SYNOPSIS
+.B mkimage
+.RB "\-l [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " \-f [" "image tree source file" "]" " [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " \-F [" "uimage file name" "]"
+
+.B mkimage
+.RB [\fIoptions\fP] " (legacy mode)"
+
+.SH "DESCRIPTION"
+The
+.B mkimage
+command is used to create images for use with the U-Boot boot loader.
+These images can contain the linux kernel, device tree blob, root file
+system image, firmware images etc., either separate or combined.
+
+.B mkimage
+supports two different formats:
+
+The old
+.I legacy image
+format concatenates the individual parts (for example, kernel image,
+device tree blob and ramdisk image) and adds a 64 bytes header
+containing information about target architecture, operating system,
+image type, compression method, entry points, time stamp, checksums,
+etc.
+
+The new
+.I FIT (Flattened Image Tree) format
+allows for more flexibility in handling images of various types and also
+enhances integrity protection of images with stronger checksums. It also
+supports verified boot.
+
+.SH "OPTIONS"
+
+.B List image information:
+
+.TP
+.BI "\-l [" "uimage file name" "]"
+mkimage lists the information contained in the header of an existing U-Boot image.
+
+.P
+.B Create old legacy image:
+
+.TP
+.BI "\-A [" "architecture" "]"
+Set architecture. Pass \-h as the architecture to see the list of supported architectures.
+
+.TP
+.BI "\-O [" "os" "]"
+Set operating system. bootm command of u-boot changes boot method by os type.
+Pass \-h as the OS to see the list of supported OS.
+
+.TP
+.BI "\-T [" "image type" "]"
+Set image type.
+Pass \-h as the image to see the list of supported image type.
+
+.TP
+.BI "\-C [" "compression type" "]"
+Set compression type.
+Pass \-h as the compression to see the list of supported compression type.
+
+.TP
+.BI "\-a [" "load address" "]"
+Set load address with a hex number.
+
+.TP
+.BI "\-e [" "entry point" "]"
+Set entry point with a hex number.
+
+.TP
+.BI "\-l"
+List the contents of an image.
+
+.TP
+.BI "\-n [" "image name" "]"
+Set image name to 'image name'.
+
+.TP
+.BI "\-d [" "image data file" "]"
+Use image data from 'image data file'.
+
+.TP
+.BI "\-x"
+Set XIP (execute in place) flag.
+
+.P
+.B Create FIT image:
+
+.TP
+.BI "\-b [" "device tree file" "]
+Appends the device tree binary file (.dtb) to the FIT.
+
+.TP
+.BI "\-c [" "comment" "]"
+Specifies a comment to be added when signing. This is typically a useful
+message which describes how the image was signed or some other useful
+information.
+
+.TP
+.BI "\-D [" "dtc options" "]"
+Provide special options to the device tree compiler that is used to
+create the image.
+
+.TP
+.BI "\-E
+After processing, move the image data outside the FIT and store a data offset
+in the FIT. Images will be placed one after the other immediately after the
+FIT, with each one aligned to a 4-byte boundary. The existing 'data' property
+in each image will be replaced with 'data-offset' and 'data-size' properties.
+A 'data-offset' of 0 indicates that it starts in the first (4-byte aligned)
+byte after the FIT.
+
+.TP
+.BI "\-f [" "image tree source file" " | " "auto" "]"
+Image tree source file that describes the structure and contents of the
+FIT image.
+
+This can be automatically generated for some simple cases.
+Use "-f auto" for this. In that case the arguments -d, -A, -O, -T, -C, -a
+and -e are used to specify the image to include in the FIT and its attributes.
+No .its file is required.
+
+.TP
+.BI "\-F"
+Indicates that an existing FIT image should be modified. No dtc
+compilation is performed and the \-f flag should not be given.
+This can be used to sign images with additional keys after initial image
+creation.
+
+.TP
+.BI "\-i [" "ramdisk_file" "]"
+Appends the ramdisk file to the FIT.
+
+.TP
+.BI "\-k [" "key_directory" "]"
+Specifies the directory containing keys to use for signing. This directory
+should contain a private key file <name>.key for use with signing and a
+certificate <name>.crt (containing the public key) for use with verification.
+
+.TP
+.BI "\-K [" "key_destination" "]"
+Specifies a compiled device tree binary file (typically .dtb) to write
+public key information into. When a private key is used to sign an image,
+the corresponding public key is written into this file for for run-time
+verification. Typically the file here is the device tree binary used by
+CONFIG_OF_CONTROL in U-Boot.
+
+.TP
+.BI "\-p [" "external position" "]"
+Place external data at a static external position. See \-E. Instead of writing
+a 'data-offset' property defining the offset from the end of the FIT, \-p will
+use 'data-position' as the absolute position from the base of the FIT.
+
+.TP
+.BI "\-r
+Specifies that keys used to sign the FIT are required. This means that they
+must be verified for the image to boot. Without this option, the verification
+will be optional (useful for testing but not for release).
+
+.TP
+.BI "\-t
+Update the timestamp in the FIT.
+
+Normally the FIT timestamp is created the first time mkimage is run on a FIT,
+when converting the source .its to the binary .fit file. This corresponds to
+using the -f flag. But if the original input to mkimage is a binary file
+(already compiled) then the timestamp is assumed to have been set previously.
+
+.SH EXAMPLES
+
+List image information:
+.nf
+.B mkimage -l uImage
+.fi
+.P
+Create legacy image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -A powerpc -O linux -T kernel -C gzip \\\\
+.br
+.B -a 0 -e 0 -n Linux -d vmlinux.gz uImage
+.fi
+.P
+Create FIT image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -f kernel.its kernel.itb
+.fi
+.P
+Create FIT image with compressed kernel and sign it with keys in the
+/public/signing-keys directory. Add corresponding public keys into u-boot.dtb,
+skipping those for which keys cannot be found. Also add a comment.
+.nf
+.B mkimage -f kernel.its -k /public/signing-keys -K u-boot.dtb \\\\
+.br
+.B -c """Kernel 3.8 image for production devices""" kernel.itb
+.fi
+
+.P
+Update an existing FIT image, signing it with additional keys.
+Add corresponding public keys into u-boot.dtb. This will resign all images
+with keys that are available in the new directory. Images that request signing
+with unavailable keys are skipped.
+.nf
+.B mkimage -F -k /secret/signing-keys -K u-boot.dtb \\\\
+.br
+.B -c """Kernel 3.8 image for production devices""" kernel.itb
+.fi
+
+.P
+Create a FIT image containing a kernel, using automatic mode. No .its file
+is required.
+.nf
+.B mkimage -f auto -A arm -O linux -T kernel -C none -a 43e00000 -e 0 \\\\
+.br
+.B -c """Kernel 4.4 image for production devices""" -d vmlinuz kernel.itb
+.fi
+.P
+Create a FIT image containing a kernel and some device tree files, using
+automatic mode. No .its file is required.
+.nf
+.B mkimage -f auto -A arm -O linux -T kernel -C none -a 43e00000 -e 0 \\\\
+.br
+.B -c """Kernel 4.4 image for production devices""" -d vmlinuz \\\\
+.B -b /path/to/rk3288-firefly.dtb -b /path/to/rk3288-jerry.dtb kernel.itb
+.fi
+
+.SH HOMEPAGE
+http://www.denx.de/wiki/U-Boot/WebHome
+.PP
+.SH AUTHOR
+This manual page was written by Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+and Wolfgang Denk <wd@denx.de>. It was updated for image signing by
+Simon Glass <sjg@chromium.org>.
diff --git a/roms/u-boot/doc/mvebu/armada-8k-memory.txt b/roms/u-boot/doc/mvebu/armada-8k-memory.txt
new file mode 100644
index 000000000..064518eb5
--- /dev/null
+++ b/roms/u-boot/doc/mvebu/armada-8k-memory.txt
@@ -0,0 +1,56 @@
+ Memory Layout on Armada-8k SoC's
+ ================================
+
+The below desribes the physical memory layout for Marvell's Armada-8k SoC's.
+
+This assumes that the SoC includes Dual CP configuration, in case the flavor is using
+a single CP configuration, then all secondary-CP mappings are invalid.
+
+All "Reserved" areas below, are kept for future usage.
+
+Start End Use
+--------------------------------------------------------------------------
+0x00000000 0xEFFFFFFF DRAM
+
+0xF0000000 0xF0FFFFFF AP Internal registers space
+
+0xF1000000 0xF1FFFFFF Reserved.
+
+0xF2000000 0xF3FFFFFF CP-0 Internal (configuration) registers
+ space.
+
+0xF4000000 0xF5FFFFFF CP-1 Internal (configuration) registers
+ space.
+
+0xF6000000 0xF6FFFFFF CP-0 / PCIe#0 Memory space.
+
+0xF7000000 0xF7FFFFFF CP-0 / PCIe#1 Memory space.
+
+0xF8000000 0xF8FFFFFF CP-0 / PCIe#2 Memory space.
+
+0xF9000000 0xF900FFFF CP-0 / PCIe#0 IO space.
+
+0xF9010000 0xF901FFFF CP-0 / PCIe#1 IO space.
+
+0xF9020000 0xF902FFFF CP-0 / PCIe#2 IO space.
+
+0xF9030000 0xF9FFFFFF Reserved.
+
+0xFA000000 0xFAFFFFFF CP-1 / PCIe#0 Memory space.
+
+0xFB000000 0xFBFFFFFF CP-1 / PCIe#1 Memory space.
+
+0xFC000000 0xFCFFFFFF CP-1 / PCIe#2 Memory space.
+
+0xFD000000 0xFD00FFFF CP-1 / PCIe#0 IO space.
+
+0xFD010000 0xFD01FFFF CP-1 / PCIe#1 IO space.
+
+0xFD020000 0xFD02FFFF CP-1 / PCIe#2 IO space.
+
+0xFD030000 0xFFEFFFFF Reserved.
+
+0xFFF00000 0xFFFFFFFF Bootrom
+
+0x100000000 <DRAM Size>-1 DRAM
+
diff --git a/roms/u-boot/doc/mvebu/cmd/bubt.txt b/roms/u-boot/doc/mvebu/cmd/bubt.txt
new file mode 100644
index 000000000..a539c15bc
--- /dev/null
+++ b/roms/u-boot/doc/mvebu/cmd/bubt.txt
@@ -0,0 +1,55 @@
+BUBT (Burn ATF) command
+--------------------------
+Bubt command is used to burn a new ATF image to flash device.
+
+The bubt command gets the following parameters: ATF file name, destination device and source device.
+bubt [file-name] [destination [source]]
+ - file-name Image file name to burn. default = flash-image.bin
+ - destination Flash to burn to [spi, nand, mmc]. default = active flash
+ - source Source to load image from [tftp, usb]. default = tftp
+
+Examples:
+ bubt - Burn flash-image.bin from tftp to active flash
+ bubt latest-spi.bin nand - Burn latest-spi.bin from tftp to NAND flash
+
+Notes:
+- For the TFTP interface set serverip and ipaddr.
+- To burn image to SD/eMMC device, the target is defined
+ by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
+
+Bubt command details (burn image step by-step)
+----------------------------------------------
+This section describes bubt command flow:
+
+1. Fetch the requested ATF image from an available interface (USB/SD/SATA/XDB, etc.)
+ into the DRAM, and place it at <load_address>
+ Example: when using the FAT file system on USB flash device:
+ # usb reset
+ # fatls usb 0 (see files in device)
+ # fatload usb 0 <load_address> <file_name>
+
+2. Erase the target device:
+ - NAND: # nand erase 0 100000
+ - SPI: # sf probe 0
+ # sf erase 0 100000
+ - SD/eMMC: # mmc dev <dev_id> <boot_partition>
+
+Notes:
+- The eMMC has 2 boot partitions (BOOT0 and BOOT1) and a user data partition (DATA).
+ The boot partitions are numbered as partition 1 and 2 in MMC driver.
+ Number 0 is used for user data partition and should not be utilized for storing
+ boot images and U-Boot environment in RAW mode since it will break file system
+ structures usually located here.
+ The default boot partition is BOOT0. It is selected by the following parameter:
+ CONFIG_SYS_MMC_ENV_PART=1
+ Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
+ Please never use partition number 0 here!
+- The partition number is ignored if the target device is SD card.
+- The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
+ The block 0 on SD devices is left for MBR storage.
+
+3. Write the ATF image:
+ - NAND: # nand write <load_address> 0 <ATF Size>
+ - SPI: # sf write <load_address> 0 <ATF Size>
+ - SD/eMMC: # mmc write <load_address> [0|1] <ATF Size>/<block_size>
+
diff --git a/roms/u-boot/doc/sphinx-static/theme_overrides.css b/roms/u-boot/doc/sphinx-static/theme_overrides.css
new file mode 100644
index 000000000..522b6d4c4
--- /dev/null
+++ b/roms/u-boot/doc/sphinx-static/theme_overrides.css
@@ -0,0 +1,89 @@
+/* -*- coding: utf-8; mode: css -*-
+ *
+ * Sphinx HTML theme customization: read the doc
+ *
+ */
+
+/* Interim: Code-blocks with line nos - lines and line numbers don't line up.
+ * see: https://github.com/rtfd/sphinx_rtd_theme/issues/419
+ */
+
+div[class^="highlight"] pre {
+ line-height: normal;
+}
+.rst-content .highlight > pre {
+ line-height: normal;
+}
+
+@media screen {
+
+ /* content column
+ *
+ * RTD theme's default is 800px as max width for the content, but we have
+ * tables with tons of columns, which need the full width of the view-port.
+ */
+
+ .wy-nav-content{max-width: none; }
+
+ /* table:
+ *
+ * - Sequences of whitespace should collapse into a single whitespace.
+ * - make the overflow auto (scrollbar if needed)
+ * - align caption "left" ("center" is unsuitable on vast tables)
+ */
+
+ .wy-table-responsive table td { white-space: normal; }
+ .wy-table-responsive { overflow: auto; }
+ .rst-content table.docutils caption { text-align: left; font-size: 100%; }
+
+ /* captions:
+ *
+ * - captions should have 100% (not 85%) font size
+ * - hide the permalink symbol as long as link is not hovered
+ */
+
+ .toc-title {
+ font-size: 150%;
+ font-weight: bold;
+ }
+
+ caption, .wy-table caption, .rst-content table.field-list caption {
+ font-size: 100%;
+ }
+ caption a.headerlink { opacity: 0; }
+ caption a.headerlink:hover { opacity: 1; }
+
+ /* Menu selection and keystrokes */
+
+ span.menuselection {
+ color: blue;
+ font-family: "Courier New", Courier, monospace
+ }
+
+ code.kbd, code.kbd span {
+ color: white;
+ background-color: darkblue;
+ font-weight: bold;
+ font-family: "Courier New", Courier, monospace
+ }
+
+ /* fix bottom margin of lists items */
+
+ .rst-content .section ul li:last-child, .rst-content .section ul li p:last-child {
+ margin-bottom: 12px;
+ }
+
+ /* inline literal: drop the borderbox, padding and red color */
+
+ code, .rst-content tt, .rst-content code {
+ color: inherit;
+ border: none;
+ padding: unset;
+ background: inherit;
+ font-size: 85%;
+ }
+
+ .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
+ color: inherit;
+ }
+}
diff --git a/roms/u-boot/doc/sphinx/automarkup.py b/roms/u-boot/doc/sphinx/automarkup.py
new file mode 100644
index 000000000..953b24b6e
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/automarkup.py
@@ -0,0 +1,290 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright 2019 Jonathan Corbet <corbet@lwn.net>
+#
+# Apply kernel-specific tweaks after the initial document processing
+# has been done.
+#
+from docutils import nodes
+import sphinx
+from sphinx import addnodes
+if sphinx.version_info[0] < 2 or \
+ sphinx.version_info[0] == 2 and sphinx.version_info[1] < 1:
+ from sphinx.environment import NoUri
+else:
+ from sphinx.errors import NoUri
+import re
+from itertools import chain
+
+#
+# Python 2 lacks re.ASCII...
+#
+try:
+ ascii_p3 = re.ASCII
+except AttributeError:
+ ascii_p3 = 0
+
+#
+# Regex nastiness. Of course.
+# Try to identify "function()" that's not already marked up some
+# other way. Sphinx doesn't like a lot of stuff right after a
+# :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
+# bit tries to restrict matches to things that won't create trouble.
+#
+RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3)
+
+#
+# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
+#
+RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
+ flags=ascii_p3)
+
+#
+# Sphinx 3 uses a different C role for each one of struct, union, enum and
+# typedef
+#
+RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
+RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
+RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
+RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
+
+#
+# Detects a reference to a documentation page of the form Documentation/... with
+# an optional extension
+#
+RE_doc = re.compile(r'\bDocumentation(/[\w\-_/]+)(\.\w+)*')
+
+RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
+
+#
+# Reserved C words that we should skip when cross-referencing
+#
+Skipnames = [ 'for', 'if', 'register', 'sizeof', 'struct', 'unsigned' ]
+
+
+#
+# Many places in the docs refer to common system calls. It is
+# pointless to try to cross-reference them and, as has been known
+# to happen, somebody defining a function by these names can lead
+# to the creation of incorrect and confusing cross references. So
+# just don't even try with these names.
+#
+Skipfuncs = [ 'open', 'close', 'read', 'write', 'fcntl', 'mmap',
+ 'select', 'poll', 'fork', 'execve', 'clone', 'ioctl',
+ 'socket' ]
+
+c_namespace = ''
+
+def markup_refs(docname, app, node):
+ t = node.astext()
+ done = 0
+ repl = [ ]
+ #
+ # Associate each regex with the function that will markup its matches
+ #
+ markup_func_sphinx2 = {RE_doc: markup_doc_ref,
+ RE_function: markup_c_ref,
+ RE_generic_type: markup_c_ref}
+
+ markup_func_sphinx3 = {RE_doc: markup_doc_ref,
+ RE_function: markup_func_ref_sphinx3,
+ RE_struct: markup_c_ref,
+ RE_union: markup_c_ref,
+ RE_enum: markup_c_ref,
+ RE_typedef: markup_c_ref}
+
+ if sphinx.version_info[0] >= 3:
+ markup_func = markup_func_sphinx3
+ else:
+ markup_func = markup_func_sphinx2
+
+ match_iterators = [regex.finditer(t) for regex in markup_func]
+ #
+ # Sort all references by the starting position in text
+ #
+ sorted_matches = sorted(chain(*match_iterators), key=lambda m: m.start())
+ for m in sorted_matches:
+ #
+ # Include any text prior to match as a normal text node.
+ #
+ if m.start() > done:
+ repl.append(nodes.Text(t[done:m.start()]))
+
+ #
+ # Call the function associated with the regex that matched this text and
+ # append its return to the text
+ #
+ repl.append(markup_func[m.re](docname, app, m))
+
+ done = m.end()
+ if done < len(t):
+ repl.append(nodes.Text(t[done:]))
+ return repl
+
+#
+# In sphinx3 we can cross-reference to C macro and function, each one with its
+# own C role, but both match the same regex, so we try both.
+#
+def markup_func_ref_sphinx3(docname, app, match):
+ class_str = ['c-func', 'c-macro']
+ reftype_str = ['function', 'macro']
+
+ cdom = app.env.domains['c']
+ #
+ # Go through the dance of getting an xref out of the C domain
+ #
+ base_target = match.group(2)
+ target_text = nodes.Text(match.group(0))
+ xref = None
+ possible_targets = [base_target]
+ # Check if this document has a namespace, and if so, try
+ # cross-referencing inside it first.
+ if c_namespace:
+ possible_targets.insert(0, c_namespace + "." + base_target)
+
+ if base_target not in Skipnames:
+ for target in possible_targets:
+ if target not in Skipfuncs:
+ for class_s, reftype_s in zip(class_str, reftype_str):
+ lit_text = nodes.literal(classes=['xref', 'c', class_s])
+ lit_text += target_text
+ pxref = addnodes.pending_xref('', refdomain = 'c',
+ reftype = reftype_s,
+ reftarget = target, modname = None,
+ classname = None)
+ #
+ # XXX The Latex builder will throw NoUri exceptions here,
+ # work around that by ignoring them.
+ #
+ try:
+ xref = cdom.resolve_xref(app.env, docname, app.builder,
+ reftype_s, target, pxref,
+ lit_text)
+ except NoUri:
+ xref = None
+
+ if xref:
+ return xref
+
+ return target_text
+
+def markup_c_ref(docname, app, match):
+ class_str = {# Sphinx 2 only
+ RE_function: 'c-func',
+ RE_generic_type: 'c-type',
+ # Sphinx 3+ only
+ RE_struct: 'c-struct',
+ RE_union: 'c-union',
+ RE_enum: 'c-enum',
+ RE_typedef: 'c-type',
+ }
+ reftype_str = {# Sphinx 2 only
+ RE_function: 'function',
+ RE_generic_type: 'type',
+ # Sphinx 3+ only
+ RE_struct: 'struct',
+ RE_union: 'union',
+ RE_enum: 'enum',
+ RE_typedef: 'type',
+ }
+
+ cdom = app.env.domains['c']
+ #
+ # Go through the dance of getting an xref out of the C domain
+ #
+ base_target = match.group(2)
+ target_text = nodes.Text(match.group(0))
+ xref = None
+ possible_targets = [base_target]
+ # Check if this document has a namespace, and if so, try
+ # cross-referencing inside it first.
+ if c_namespace:
+ possible_targets.insert(0, c_namespace + "." + base_target)
+
+ if base_target not in Skipnames:
+ for target in possible_targets:
+ if not (match.re == RE_function and target in Skipfuncs):
+ lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]])
+ lit_text += target_text
+ pxref = addnodes.pending_xref('', refdomain = 'c',
+ reftype = reftype_str[match.re],
+ reftarget = target, modname = None,
+ classname = None)
+ #
+ # XXX The Latex builder will throw NoUri exceptions here,
+ # work around that by ignoring them.
+ #
+ try:
+ xref = cdom.resolve_xref(app.env, docname, app.builder,
+ reftype_str[match.re], target, pxref,
+ lit_text)
+ except NoUri:
+ xref = None
+
+ if xref:
+ return xref
+
+ return target_text
+
+#
+# Try to replace a documentation reference of the form Documentation/... with a
+# cross reference to that page
+#
+def markup_doc_ref(docname, app, match):
+ stddom = app.env.domains['std']
+ #
+ # Go through the dance of getting an xref out of the std domain
+ #
+ target = match.group(1)
+ xref = None
+ pxref = addnodes.pending_xref('', refdomain = 'std', reftype = 'doc',
+ reftarget = target, modname = None,
+ classname = None, refexplicit = False)
+ #
+ # XXX The Latex builder will throw NoUri exceptions here,
+ # work around that by ignoring them.
+ #
+ try:
+ xref = stddom.resolve_xref(app.env, docname, app.builder, 'doc',
+ target, pxref, None)
+ except NoUri:
+ xref = None
+ #
+ # Return the xref if we got it; otherwise just return the plain text.
+ #
+ if xref:
+ return xref
+ else:
+ return nodes.Text(match.group(0))
+
+def get_c_namespace(app, docname):
+ source = app.env.doc2path(docname)
+ with open(source) as f:
+ for l in f:
+ match = RE_namespace.search(l)
+ if match:
+ return match.group(1)
+ return ''
+
+def auto_markup(app, doctree, name):
+ global c_namespace
+ c_namespace = get_c_namespace(app, name)
+ #
+ # This loop could eventually be improved on. Someday maybe we
+ # want a proper tree traversal with a lot of awareness of which
+ # kinds of nodes to prune. But this works well for now.
+ #
+ # The nodes.literal test catches ``literal text``, its purpose is to
+ # avoid adding cross-references to functions that have been explicitly
+ # marked with cc:func:.
+ #
+ for para in doctree.traverse(nodes.paragraph):
+ for node in para.traverse(nodes.Text):
+ if not isinstance(node.parent, nodes.literal):
+ node.parent.replace(node, markup_refs(name, app, node))
+
+def setup(app):
+ app.connect('doctree-resolved', auto_markup)
+ return {
+ 'parallel_read_safe': True,
+ 'parallel_write_safe': True,
+ }
diff --git a/roms/u-boot/doc/sphinx/cdomain.py b/roms/u-boot/doc/sphinx/cdomain.py
new file mode 100644
index 000000000..014a5229e
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/cdomain.py
@@ -0,0 +1,259 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=W0141,C0113,C0103,C0325
+u"""
+ cdomain
+ ~~~~~~~
+
+ Replacement for the sphinx c-domain.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :license: GPL Version 2, June 1991 see Linux/COPYING for details.
+
+ List of customizations:
+
+ * Moved the *duplicate C object description* warnings for function
+ declarations in the nitpicky mode. See Sphinx documentation for
+ the config values for ``nitpick`` and ``nitpick_ignore``.
+
+ * Add option 'name' to the "c:function:" directive. With option 'name' the
+ ref-name of a function can be modified. E.g.::
+
+ .. c:function:: int ioctl( int fd, int request )
+ :name: VIDIOC_LOG_STATUS
+
+ The func-name (e.g. ioctl) remains in the output but the ref-name changed
+ from 'ioctl' to 'VIDIOC_LOG_STATUS'. The function is referenced by::
+
+ * :c:func:`VIDIOC_LOG_STATUS` or
+ * :any:`VIDIOC_LOG_STATUS` (``:any:`` needs sphinx 1.3)
+
+ * Handle signatures of function-like macros well. Don't try to deduce
+ arguments types of function-like macros.
+
+"""
+
+from docutils import nodes
+from docutils.parsers.rst import directives
+
+import sphinx
+from sphinx import addnodes
+from sphinx.domains.c import c_funcptr_sig_re, c_sig_re
+from sphinx.domains.c import CObject as Base_CObject
+from sphinx.domains.c import CDomain as Base_CDomain
+from itertools import chain
+import re
+
+__version__ = '1.1'
+
+# Get Sphinx version
+major, minor, patch = sphinx.version_info[:3]
+
+# Namespace to be prepended to the full name
+namespace = None
+
+#
+# Handle trivial newer c domain tags that are part of Sphinx 3.1 c domain tags
+# - Store the namespace if ".. c:namespace::" tag is found
+#
+RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
+
+def markup_namespace(match):
+ global namespace
+
+ namespace = match.group(1)
+
+ return ""
+
+#
+# Handle c:macro for function-style declaration
+#
+RE_macro = re.compile(r'^\s*..\s*c:macro::\s*(\S+)\s+(\S.*)\s*$')
+def markup_macro(match):
+ return ".. c:function:: " + match.group(1) + ' ' + match.group(2)
+
+#
+# Handle newer c domain tags that are evaluated as .. c:type: for
+# backward-compatibility with Sphinx < 3.0
+#
+RE_ctype = re.compile(r'^\s*..\s*c:(struct|union|enum|enumerator|alias)::\s*(.*)$')
+
+def markup_ctype(match):
+ return ".. c:type:: " + match.group(2)
+
+#
+# Handle newer c domain tags that are evaluated as :c:type: for
+# backward-compatibility with Sphinx < 3.0
+#
+RE_ctype_refs = re.compile(r':c:(var|struct|union|enum|enumerator)::`([^\`]+)`')
+def markup_ctype_refs(match):
+ return ":c:type:`" + match.group(2) + '`'
+
+#
+# Simply convert :c:expr: and :c:texpr: into a literal block.
+#
+RE_expr = re.compile(r':c:(expr|texpr):`([^\`]+)`')
+def markup_c_expr(match):
+ return '\ ``' + match.group(2) + '``\ '
+
+#
+# Parse Sphinx 3.x C markups, replacing them by backward-compatible ones
+#
+def c_markups(app, docname, source):
+ result = ""
+ markup_func = {
+ RE_namespace: markup_namespace,
+ RE_expr: markup_c_expr,
+ RE_macro: markup_macro,
+ RE_ctype: markup_ctype,
+ RE_ctype_refs: markup_ctype_refs,
+ }
+
+ lines = iter(source[0].splitlines(True))
+ for n in lines:
+ match_iterators = [regex.finditer(n) for regex in markup_func]
+ matches = sorted(chain(*match_iterators), key=lambda m: m.start())
+ for m in matches:
+ n = n[:m.start()] + markup_func[m.re](m) + n[m.end():]
+
+ result = result + n
+
+ source[0] = result
+
+#
+# Now implements support for the cdomain namespacing logic
+#
+
+def setup(app):
+
+ # Handle easy Sphinx 3.1+ simple new tags: :c:expr and .. c:namespace::
+ app.connect('source-read', c_markups)
+
+ if (major == 1 and minor < 8):
+ app.override_domain(CDomain)
+ else:
+ app.add_domain(CDomain, override=True)
+
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
+
+class CObject(Base_CObject):
+
+ """
+ Description of a C language object.
+ """
+ option_spec = {
+ "name" : directives.unchanged
+ }
+
+ def handle_func_like_macro(self, sig, signode):
+ u"""Handles signatures of function-like macros.
+
+ If the objtype is 'function' and the the signature ``sig`` is a
+ function-like macro, the name of the macro is returned. Otherwise
+ ``False`` is returned. """
+
+ global namespace
+
+ if not self.objtype == 'function':
+ return False
+
+ m = c_funcptr_sig_re.match(sig)
+ if m is None:
+ m = c_sig_re.match(sig)
+ if m is None:
+ raise ValueError('no match')
+
+ rettype, fullname, arglist, _const = m.groups()
+ arglist = arglist.strip()
+ if rettype or not arglist:
+ return False
+
+ arglist = arglist.replace('`', '').replace('\\ ', '') # remove markup
+ arglist = [a.strip() for a in arglist.split(",")]
+
+ # has the first argument a type?
+ if len(arglist[0].split(" ")) > 1:
+ return False
+
+ # This is a function-like macro, it's arguments are typeless!
+ signode += addnodes.desc_name(fullname, fullname)
+ paramlist = addnodes.desc_parameterlist()
+ signode += paramlist
+
+ for argname in arglist:
+ param = addnodes.desc_parameter('', '', noemph=True)
+ # separate by non-breaking space in the output
+ param += nodes.emphasis(argname, argname)
+ paramlist += param
+
+ if namespace:
+ fullname = namespace + "." + fullname
+
+ return fullname
+
+ def handle_signature(self, sig, signode):
+ """Transform a C signature into RST nodes."""
+
+ global namespace
+
+ fullname = self.handle_func_like_macro(sig, signode)
+ if not fullname:
+ fullname = super(CObject, self).handle_signature(sig, signode)
+
+ if "name" in self.options:
+ if self.objtype == 'function':
+ fullname = self.options["name"]
+ else:
+ # FIXME: handle :name: value of other declaration types?
+ pass
+ else:
+ if namespace:
+ fullname = namespace + "." + fullname
+
+ return fullname
+
+ def add_target_and_index(self, name, sig, signode):
+ # for C API items we add a prefix since names are usually not qualified
+ # by a module name and so easily clash with e.g. section titles
+ targetname = 'c.' + name
+ if targetname not in self.state.document.ids:
+ signode['names'].append(targetname)
+ signode['ids'].append(targetname)
+ signode['first'] = (not self.names)
+ self.state.document.note_explicit_target(signode)
+ inv = self.env.domaindata['c']['objects']
+ if (name in inv and self.env.config.nitpicky):
+ if self.objtype == 'function':
+ if ('c:func', name) not in self.env.config.nitpick_ignore:
+ self.state_machine.reporter.warning(
+ 'duplicate C object description of %s, ' % name +
+ 'other instance in ' + self.env.doc2path(inv[name][0]),
+ line=self.lineno)
+ inv[name] = (self.env.docname, self.objtype)
+
+ indextext = self.get_index_text(name)
+ if indextext:
+ if major == 1 and minor < 4:
+ # indexnode's tuple changed in 1.4
+ # https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c
+ self.indexnode['entries'].append(
+ ('single', indextext, targetname, ''))
+ else:
+ self.indexnode['entries'].append(
+ ('single', indextext, targetname, '', None))
+
+class CDomain(Base_CDomain):
+
+ """C language domain."""
+ name = 'c'
+ label = 'C'
+ directives = {
+ 'function': CObject,
+ 'member': CObject,
+ 'macro': CObject,
+ 'type': CObject,
+ 'var': CObject,
+ }
diff --git a/roms/u-boot/doc/sphinx/kernel_abi.py b/roms/u-boot/doc/sphinx/kernel_abi.py
new file mode 100644
index 000000000..f3da859c9
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kernel_abi.py
@@ -0,0 +1,194 @@
+# -*- coding: utf-8; mode: python -*-
+# coding=utf-8
+# SPDX-License-Identifier: GPL-2.0
+#
+u"""
+ kernel-abi
+ ~~~~~~~~~~
+
+ Implementation of the ``kernel-abi`` reST-directive.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :copyright: Copyright (C) 2016-2020 Mauro Carvalho Chehab
+ :maintained-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+ :license: GPL Version 2, June 1991 see Linux/COPYING for details.
+
+ The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the
+ scripts/get_abi.pl script to parse the Kernel ABI files.
+
+ Overview of directive's argument and options.
+
+ .. code-block:: rst
+
+ .. kernel-abi:: <ABI directory location>
+ :debug:
+
+ The argument ``<ABI directory location>`` is required. It contains the
+ location of the ABI files to be parsed.
+
+ ``debug``
+ Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+ what reST is generated.
+
+"""
+
+import codecs
+import os
+import subprocess
+import sys
+import re
+import kernellog
+
+from os import path
+
+from docutils import nodes, statemachine
+from docutils.statemachine import ViewList
+from docutils.parsers.rst import directives, Directive
+from docutils.utils.error_reporting import ErrorString
+
+#
+# AutodocReporter is only good up to Sphinx 1.7
+#
+import sphinx
+
+Use_SSI = sphinx.__version__[:3] >= '1.7'
+if Use_SSI:
+ from sphinx.util.docutils import switch_source_input
+else:
+ from sphinx.ext.autodoc import AutodocReporter
+
+__version__ = '1.0'
+
+def setup(app):
+
+ app.add_directive("kernel-abi", KernelCmd)
+ return dict(
+ version = __version__
+ , parallel_read_safe = True
+ , parallel_write_safe = True
+ )
+
+class KernelCmd(Directive):
+
+ u"""KernelABI (``kernel-abi``) directive"""
+
+ required_arguments = 1
+ optional_arguments = 2
+ has_content = False
+ final_argument_whitespace = True
+
+ option_spec = {
+ "debug" : directives.flag,
+ "rst" : directives.unchanged
+ }
+
+ def run(self):
+
+ doc = self.state.document
+ if not doc.settings.file_insertion_enabled:
+ raise self.warning("docutils: file insertion disabled")
+
+ env = doc.settings.env
+ cwd = path.dirname(doc.current_source)
+ cmd = "get_abi.pl rest --enable-lineno --dir "
+ cmd += self.arguments[0]
+
+ if 'rst' in self.options:
+ cmd += " --rst-source"
+
+ srctree = path.abspath(os.environ["srctree"])
+
+ fname = cmd
+
+ # extend PATH with $(srctree)/scripts
+ path_env = os.pathsep.join([
+ srctree + os.sep + "scripts",
+ os.environ["PATH"]
+ ])
+ shell_env = os.environ.copy()
+ shell_env["PATH"] = path_env
+ shell_env["srctree"] = srctree
+
+ lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
+ nodeList = self.nestedParse(lines, self.arguments[0])
+ return nodeList
+
+ def runCmd(self, cmd, **kwargs):
+ u"""Run command ``cmd`` and return it's stdout as unicode."""
+
+ try:
+ proc = subprocess.Popen(
+ cmd
+ , stdout = subprocess.PIPE
+ , stderr = subprocess.PIPE
+ , **kwargs
+ )
+ out, err = proc.communicate()
+
+ out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
+
+ if proc.returncode != 0:
+ raise self.severe(
+ u"command '%s' failed with return code %d"
+ % (cmd, proc.returncode)
+ )
+ except OSError as exc:
+ raise self.severe(u"problems with '%s' directive: %s."
+ % (self.name, ErrorString(exc)))
+ return out
+
+ def nestedParse(self, lines, fname):
+ content = ViewList()
+ node = nodes.section()
+
+ if "debug" in self.options:
+ code_block = "\n\n.. code-block:: rst\n :linenos:\n"
+ for l in lines.split("\n"):
+ code_block += "\n " + l
+ lines = code_block + "\n\n"
+
+ line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$")
+ ln = 0
+ n = 0
+ f = fname
+
+ for line in lines.split("\n"):
+ n = n + 1
+ match = line_regex.search(line)
+ if match:
+ new_f = match.group(1)
+
+ # Sphinx parser is lazy: it stops parsing contents in the
+ # middle, if it is too big. So, handle it per input file
+ if new_f != f and content:
+ self.do_parse(content, node)
+ content = ViewList()
+
+ f = new_f
+
+ # sphinx counts lines from 0
+ ln = int(match.group(2)) - 1
+ else:
+ content.append(line, f, ln)
+
+ kernellog.info(self.state.document.settings.env.app, "%s: parsed %i lines" % (fname, n))
+
+ if content:
+ self.do_parse(content, node)
+
+ return node.children
+
+ def do_parse(self, content, node):
+ if Use_SSI:
+ with switch_source_input(self.state, content):
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ else:
+ buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
+
+ self.state.memo.title_styles = []
+ self.state.memo.section_level = 0
+ self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
+ try:
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ finally:
+ self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
diff --git a/roms/u-boot/doc/sphinx/kernel_feat.py b/roms/u-boot/doc/sphinx/kernel_feat.py
new file mode 100644
index 000000000..2fee04f1d
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kernel_feat.py
@@ -0,0 +1,169 @@
+# coding=utf-8
+# SPDX-License-Identifier: GPL-2.0
+#
+u"""
+ kernel-feat
+ ~~~~~~~~~~~
+
+ Implementation of the ``kernel-feat`` reST-directive.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :copyright: Copyright (C) 2016-2019 Mauro Carvalho Chehab
+ :maintained-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+ :license: GPL Version 2, June 1991 see Linux/COPYING for details.
+
+ The ``kernel-feat`` (:py:class:`KernelFeat`) directive calls the
+ scripts/get_feat.pl script to parse the Kernel ABI files.
+
+ Overview of directive's argument and options.
+
+ .. code-block:: rst
+
+ .. kernel-feat:: <ABI directory location>
+ :debug:
+
+ The argument ``<ABI directory location>`` is required. It contains the
+ location of the ABI files to be parsed.
+
+ ``debug``
+ Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+ what reST is generated.
+
+"""
+
+import codecs
+import os
+import subprocess
+import sys
+
+from os import path
+
+from docutils import nodes, statemachine
+from docutils.statemachine import ViewList
+from docutils.parsers.rst import directives, Directive
+from docutils.utils.error_reporting import ErrorString
+
+#
+# AutodocReporter is only good up to Sphinx 1.7
+#
+import sphinx
+
+Use_SSI = sphinx.__version__[:3] >= '1.7'
+if Use_SSI:
+ from sphinx.util.docutils import switch_source_input
+else:
+ from sphinx.ext.autodoc import AutodocReporter
+
+__version__ = '1.0'
+
+def setup(app):
+
+ app.add_directive("kernel-feat", KernelFeat)
+ return dict(
+ version = __version__
+ , parallel_read_safe = True
+ , parallel_write_safe = True
+ )
+
+class KernelFeat(Directive):
+
+ u"""KernelFeat (``kernel-feat``) directive"""
+
+ required_arguments = 1
+ optional_arguments = 2
+ has_content = False
+ final_argument_whitespace = True
+
+ option_spec = {
+ "debug" : directives.flag
+ }
+
+ def warn(self, message, **replace):
+ replace["fname"] = self.state.document.current_source
+ replace["line_no"] = replace.get("line_no", self.lineno)
+ message = ("%(fname)s:%(line_no)s: [kernel-feat WARN] : " + message) % replace
+ self.state.document.settings.env.app.warn(message, prefix="")
+
+ def run(self):
+
+ doc = self.state.document
+ if not doc.settings.file_insertion_enabled:
+ raise self.warning("docutils: file insertion disabled")
+
+ env = doc.settings.env
+ cwd = path.dirname(doc.current_source)
+ cmd = "get_feat.pl rest --dir "
+ cmd += self.arguments[0]
+
+ if len(self.arguments) > 1:
+ cmd += " --arch " + self.arguments[1]
+
+ srctree = path.abspath(os.environ["srctree"])
+
+ fname = cmd
+
+ # extend PATH with $(srctree)/scripts
+ path_env = os.pathsep.join([
+ srctree + os.sep + "scripts",
+ os.environ["PATH"]
+ ])
+ shell_env = os.environ.copy()
+ shell_env["PATH"] = path_env
+ shell_env["srctree"] = srctree
+
+ lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
+ nodeList = self.nestedParse(lines, fname)
+ return nodeList
+
+ def runCmd(self, cmd, **kwargs):
+ u"""Run command ``cmd`` and return it's stdout as unicode."""
+
+ try:
+ proc = subprocess.Popen(
+ cmd
+ , stdout = subprocess.PIPE
+ , stderr = subprocess.PIPE
+ , **kwargs
+ )
+ out, err = proc.communicate()
+
+ out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
+
+ if proc.returncode != 0:
+ raise self.severe(
+ u"command '%s' failed with return code %d"
+ % (cmd, proc.returncode)
+ )
+ except OSError as exc:
+ raise self.severe(u"problems with '%s' directive: %s."
+ % (self.name, ErrorString(exc)))
+ return out
+
+ def nestedParse(self, lines, fname):
+ content = ViewList()
+ node = nodes.section()
+
+ if "debug" in self.options:
+ code_block = "\n\n.. code-block:: rst\n :linenos:\n"
+ for l in lines.split("\n"):
+ code_block += "\n " + l
+ lines = code_block + "\n\n"
+
+ for c, l in enumerate(lines.split("\n")):
+ content.append(l, fname, c)
+
+ buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
+
+ if Use_SSI:
+ with switch_source_input(self.state, content):
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ else:
+ self.state.memo.title_styles = []
+ self.state.memo.section_level = 0
+ self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
+ try:
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ finally:
+ self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
+
+ return node.children
diff --git a/roms/u-boot/doc/sphinx/kernel_include.py b/roms/u-boot/doc/sphinx/kernel_include.py
new file mode 100755
index 000000000..f523aa68a
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kernel_include.py
@@ -0,0 +1,190 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=R0903, C0330, R0914, R0912, E0401
+
+u"""
+ kernel-include
+ ~~~~~~~~~~~~~~
+
+ Implementation of the ``kernel-include`` reST-directive.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :license: GPL Version 2, June 1991 see linux/COPYING for details.
+
+ The ``kernel-include`` reST-directive is a replacement for the ``include``
+ directive. The ``kernel-include`` directive expand environment variables in
+ the path name and allows to include files from arbitrary locations.
+
+ .. hint::
+
+ Including files from arbitrary locations (e.g. from ``/etc``) is a
+ security risk for builders. This is why the ``include`` directive from
+ docutils *prohibit* pathnames pointing to locations *above* the filesystem
+ tree where the reST document with the include directive is placed.
+
+ Substrings of the form $name or ${name} are replaced by the value of
+ environment variable name. Malformed variable names and references to
+ non-existing variables are left unchanged.
+"""
+
+# ==============================================================================
+# imports
+# ==============================================================================
+
+import os.path
+
+from docutils import io, nodes, statemachine
+from docutils.utils.error_reporting import SafeString, ErrorString
+from docutils.parsers.rst import directives
+from docutils.parsers.rst.directives.body import CodeBlock, NumberLines
+from docutils.parsers.rst.directives.misc import Include
+
+__version__ = '1.0'
+
+# ==============================================================================
+def setup(app):
+# ==============================================================================
+
+ app.add_directive("kernel-include", KernelInclude)
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
+
+# ==============================================================================
+class KernelInclude(Include):
+# ==============================================================================
+
+ u"""KernelInclude (``kernel-include``) directive"""
+
+ def run(self):
+ path = os.path.realpath(
+ os.path.expandvars(self.arguments[0]))
+
+ # to get a bit security back, prohibit /etc:
+ if path.startswith(os.sep + "etc"):
+ raise self.severe(
+ 'Problems with "%s" directive, prohibited path: %s'
+ % (self.name, path))
+
+ self.arguments[0] = path
+
+ #return super(KernelInclude, self).run() # won't work, see HINTs in _run()
+ return self._run()
+
+ def _run(self):
+ """Include a file as part of the content of this reST file."""
+
+ # HINT: I had to copy&paste the whole Include.run method. I'am not happy
+ # with this, but due to security reasons, the Include.run method does
+ # not allow absolute or relative pathnames pointing to locations *above*
+ # the filesystem tree where the reST document is placed.
+
+ if not self.state.document.settings.file_insertion_enabled:
+ raise self.warning('"%s" directive disabled.' % self.name)
+ source = self.state_machine.input_lines.source(
+ self.lineno - self.state_machine.input_offset - 1)
+ source_dir = os.path.dirname(os.path.abspath(source))
+ path = directives.path(self.arguments[0])
+ if path.startswith('<') and path.endswith('>'):
+ path = os.path.join(self.standard_include_path, path[1:-1])
+ path = os.path.normpath(os.path.join(source_dir, path))
+
+ # HINT: this is the only line I had to change / commented out:
+ #path = utils.relative_path(None, path)
+
+ path = nodes.reprunicode(path)
+ encoding = self.options.get(
+ 'encoding', self.state.document.settings.input_encoding)
+ e_handler=self.state.document.settings.input_encoding_error_handler
+ tab_width = self.options.get(
+ 'tab-width', self.state.document.settings.tab_width)
+ try:
+ self.state.document.settings.record_dependencies.add(path)
+ include_file = io.FileInput(source_path=path,
+ encoding=encoding,
+ error_handler=e_handler)
+ except UnicodeEncodeError as error:
+ raise self.severe('Problems with "%s" directive path:\n'
+ 'Cannot encode input file path "%s" '
+ '(wrong locale?).' %
+ (self.name, SafeString(path)))
+ except IOError as error:
+ raise self.severe('Problems with "%s" directive path:\n%s.' %
+ (self.name, ErrorString(error)))
+ startline = self.options.get('start-line', None)
+ endline = self.options.get('end-line', None)
+ try:
+ if startline or (endline is not None):
+ lines = include_file.readlines()
+ rawtext = ''.join(lines[startline:endline])
+ else:
+ rawtext = include_file.read()
+ except UnicodeError as error:
+ raise self.severe('Problem with "%s" directive:\n%s' %
+ (self.name, ErrorString(error)))
+ # start-after/end-before: no restrictions on newlines in match-text,
+ # and no restrictions on matching inside lines vs. line boundaries
+ after_text = self.options.get('start-after', None)
+ if after_text:
+ # skip content in rawtext before *and incl.* a matching text
+ after_index = rawtext.find(after_text)
+ if after_index < 0:
+ raise self.severe('Problem with "start-after" option of "%s" '
+ 'directive:\nText not found.' % self.name)
+ rawtext = rawtext[after_index + len(after_text):]
+ before_text = self.options.get('end-before', None)
+ if before_text:
+ # skip content in rawtext after *and incl.* a matching text
+ before_index = rawtext.find(before_text)
+ if before_index < 0:
+ raise self.severe('Problem with "end-before" option of "%s" '
+ 'directive:\nText not found.' % self.name)
+ rawtext = rawtext[:before_index]
+
+ include_lines = statemachine.string2lines(rawtext, tab_width,
+ convert_whitespace=True)
+ if 'literal' in self.options:
+ # Convert tabs to spaces, if `tab_width` is positive.
+ if tab_width >= 0:
+ text = rawtext.expandtabs(tab_width)
+ else:
+ text = rawtext
+ literal_block = nodes.literal_block(rawtext, source=path,
+ classes=self.options.get('class', []))
+ literal_block.line = 1
+ self.add_name(literal_block)
+ if 'number-lines' in self.options:
+ try:
+ startline = int(self.options['number-lines'] or 1)
+ except ValueError:
+ raise self.error(':number-lines: with non-integer '
+ 'start value')
+ endline = startline + len(include_lines)
+ if text.endswith('\n'):
+ text = text[:-1]
+ tokens = NumberLines([([], text)], startline, endline)
+ for classes, value in tokens:
+ if classes:
+ literal_block += nodes.inline(value, value,
+ classes=classes)
+ else:
+ literal_block += nodes.Text(value, value)
+ else:
+ literal_block += nodes.Text(text, text)
+ return [literal_block]
+ if 'code' in self.options:
+ self.options['source'] = path
+ codeblock = CodeBlock(self.name,
+ [self.options.pop('code')], # arguments
+ self.options,
+ include_lines, # content
+ self.lineno,
+ self.content_offset,
+ self.block_text,
+ self.state,
+ self.state_machine)
+ return codeblock.run()
+ self.state_machine.insert_input(include_lines, path)
+ return []
diff --git a/roms/u-boot/doc/sphinx/kerneldoc.py b/roms/u-boot/doc/sphinx/kerneldoc.py
new file mode 100644
index 000000000..e9857ab90
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kerneldoc.py
@@ -0,0 +1,190 @@
+# coding=utf-8
+#
+# Copyright © 2016 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+# Jani Nikula <jani.nikula@intel.com>
+#
+# Please make sure this works on both python2 and python3.
+#
+
+import codecs
+import os
+import subprocess
+import sys
+import re
+import glob
+
+from docutils import nodes, statemachine
+from docutils.statemachine import ViewList
+from docutils.parsers.rst import directives, Directive
+
+#
+# AutodocReporter is only good up to Sphinx 1.7
+#
+import sphinx
+
+Use_SSI = sphinx.__version__[:3] >= '1.7'
+if Use_SSI:
+ from sphinx.util.docutils import switch_source_input
+else:
+ from sphinx.ext.autodoc import AutodocReporter
+
+import kernellog
+
+__version__ = '1.0'
+
+class KernelDocDirective(Directive):
+ """Extract kernel-doc comments from the specified file"""
+ required_argument = 1
+ optional_arguments = 4
+ option_spec = {
+ 'doc': directives.unchanged_required,
+ 'export': directives.unchanged,
+ 'internal': directives.unchanged,
+ 'identifiers': directives.unchanged,
+ 'no-identifiers': directives.unchanged,
+ 'functions': directives.unchanged,
+ }
+ has_content = False
+
+ def run(self):
+ env = self.state.document.settings.env
+ cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
+
+ # Pass the version string to kernel-doc, as it needs to use a different
+ # dialect, depending what the C domain supports for each specific
+ # Sphinx versions
+ cmd += ['-sphinx-version', sphinx.__version__]
+
+ filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
+ export_file_patterns = []
+
+ # Tell sphinx of the dependency
+ env.note_dependency(os.path.abspath(filename))
+
+ tab_width = self.options.get('tab-width', self.state.document.settings.tab_width)
+
+ # 'function' is an alias of 'identifiers'
+ if 'functions' in self.options:
+ self.options['identifiers'] = self.options.get('functions')
+
+ # FIXME: make this nicer and more robust against errors
+ if 'export' in self.options:
+ cmd += ['-export']
+ export_file_patterns = str(self.options.get('export')).split()
+ elif 'internal' in self.options:
+ cmd += ['-internal']
+ export_file_patterns = str(self.options.get('internal')).split()
+ elif 'doc' in self.options:
+ cmd += ['-function', str(self.options.get('doc'))]
+ elif 'identifiers' in self.options:
+ identifiers = self.options.get('identifiers').split()
+ if identifiers:
+ for i in identifiers:
+ cmd += ['-function', i]
+ else:
+ cmd += ['-no-doc-sections']
+
+ if 'no-identifiers' in self.options:
+ no_identifiers = self.options.get('no-identifiers').split()
+ if no_identifiers:
+ for i in no_identifiers:
+ cmd += ['-nosymbol', i]
+
+ for pattern in export_file_patterns:
+ for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
+ env.note_dependency(os.path.abspath(f))
+ cmd += ['-export-file', f]
+
+ cmd += [filename]
+
+ try:
+ kernellog.verbose(env.app,
+ 'calling kernel-doc \'%s\'' % (" ".join(cmd)))
+
+ p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+ out, err = p.communicate()
+
+ out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
+
+ if p.returncode != 0:
+ sys.stderr.write(err)
+
+ kernellog.warn(env.app,
+ 'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
+ return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
+ elif env.config.kerneldoc_verbosity > 0:
+ sys.stderr.write(err)
+
+ lines = statemachine.string2lines(out, tab_width, convert_whitespace=True)
+ result = ViewList()
+
+ lineoffset = 0;
+ line_regex = re.compile("^#define LINENO ([0-9]+)$")
+ for line in lines:
+ match = line_regex.search(line)
+ if match:
+ # sphinx counts lines from 0
+ lineoffset = int(match.group(1)) - 1
+ # we must eat our comments since the upset the markup
+ else:
+ doc = env.srcdir + "/" + env.docname + ":" + str(self.lineno)
+ result.append(line, doc + ": " + filename, lineoffset)
+ lineoffset += 1
+
+ node = nodes.section()
+ self.do_parse(result, node)
+
+ return node.children
+
+ except Exception as e: # pylint: disable=W0703
+ kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' %
+ (" ".join(cmd), str(e)))
+ return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
+
+ def do_parse(self, result, node):
+ if Use_SSI:
+ with switch_source_input(self.state, result):
+ self.state.nested_parse(result, 0, node, match_titles=1)
+ else:
+ save = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
+ self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
+ self.state.memo.title_styles, self.state.memo.section_level = [], 0
+ try:
+ self.state.nested_parse(result, 0, node, match_titles=1)
+ finally:
+ self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = save
+
+
+def setup(app):
+ app.add_config_value('kerneldoc_bin', None, 'env')
+ app.add_config_value('kerneldoc_srctree', None, 'env')
+ app.add_config_value('kerneldoc_verbosity', 1, 'env')
+
+ app.add_directive('kernel-doc', KernelDocDirective)
+
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
diff --git a/roms/u-boot/doc/sphinx/kernellog.py b/roms/u-boot/doc/sphinx/kernellog.py
new file mode 100644
index 000000000..8ac7d274f
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kernellog.py
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Sphinx has deprecated its older logging interface, but the replacement
+# only goes back to 1.6. So here's a wrapper layer to keep around for
+# as long as we support 1.4.
+#
+import sphinx
+
+if sphinx.__version__[:3] >= '1.6':
+ UseLogging = True
+ from sphinx.util import logging
+ logger = logging.getLogger('kerneldoc')
+else:
+ UseLogging = False
+
+def warn(app, message):
+ if UseLogging:
+ logger.warning(message)
+ else:
+ app.warn(message)
+
+def verbose(app, message):
+ if UseLogging:
+ logger.verbose(message)
+ else:
+ app.verbose(message)
+
+def info(app, message):
+ if UseLogging:
+ logger.info(message)
+ else:
+ app.info(message)
diff --git a/roms/u-boot/doc/sphinx/kfigure.py b/roms/u-boot/doc/sphinx/kfigure.py
new file mode 100644
index 000000000..788704886
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/kfigure.py
@@ -0,0 +1,557 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=C0103, R0903, R0912, R0915
+u"""
+ scalable figure and image handling
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Sphinx extension which implements scalable image handling.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :license: GPL Version 2, June 1991 see Linux/COPYING for details.
+
+ The build for image formats depend on image's source format and output's
+ destination format. This extension implement methods to simplify image
+ handling from the author's POV. Directives like ``kernel-figure`` implement
+ methods *to* always get the best output-format even if some tools are not
+ installed. For more details take a look at ``convert_image(...)`` which is
+ the core of all conversions.
+
+ * ``.. kernel-image``: for image handling / a ``.. image::`` replacement
+
+ * ``.. kernel-figure``: for figure handling / a ``.. figure::`` replacement
+
+ * ``.. kernel-render``: for render markup / a concept to embed *render*
+ markups (or languages). Supported markups (see ``RENDER_MARKUP_EXT``)
+
+ - ``DOT``: render embedded Graphviz's **DOC**
+ - ``SVG``: render embedded Scalable Vector Graphics (**SVG**)
+ - ... *developable*
+
+ Used tools:
+
+ * ``dot(1)``: Graphviz (https://www.graphviz.org). If Graphviz is not
+ available, the DOT language is inserted as literal-block.
+
+ * SVG to PDF: To generate PDF, you need at least one of this tools:
+
+ - ``convert(1)``: ImageMagick (https://www.imagemagick.org)
+
+ List of customizations:
+
+ * generate PDF from SVG / used by PDF (LaTeX) builder
+
+ * generate SVG (html-builder) and PDF (latex-builder) from DOT files.
+ DOT: see https://www.graphviz.org/content/dot-language
+
+ """
+
+import os
+from os import path
+import subprocess
+from hashlib import sha1
+import sys
+
+from docutils import nodes
+from docutils.statemachine import ViewList
+from docutils.parsers.rst import directives
+from docutils.parsers.rst.directives import images
+import sphinx
+
+from sphinx.util.nodes import clean_astext
+from six import iteritems
+
+import kernellog
+
+PY3 = sys.version_info[0] == 3
+
+if PY3:
+ _unicode = str
+else:
+ _unicode = unicode
+
+# Get Sphinx version
+major, minor, patch = sphinx.version_info[:3]
+if major == 1 and minor > 3:
+ # patches.Figure only landed in Sphinx 1.4
+ from sphinx.directives.patches import Figure # pylint: disable=C0413
+else:
+ Figure = images.Figure
+
+__version__ = '1.0.0'
+
+# simple helper
+# -------------
+
+def which(cmd):
+ """Searches the ``cmd`` in the ``PATH`` environment.
+
+ This *which* searches the PATH for executable ``cmd`` . First match is
+ returned, if nothing is found, ``None` is returned.
+ """
+ envpath = os.environ.get('PATH', None) or os.defpath
+ for folder in envpath.split(os.pathsep):
+ fname = folder + os.sep + cmd
+ if path.isfile(fname):
+ return fname
+
+def mkdir(folder, mode=0o775):
+ if not path.isdir(folder):
+ os.makedirs(folder, mode)
+
+def file2literal(fname):
+ with open(fname, "r") as src:
+ data = src.read()
+ node = nodes.literal_block(data, data)
+ return node
+
+def isNewer(path1, path2):
+ """Returns True if ``path1`` is newer than ``path2``
+
+ If ``path1`` exists and is newer than ``path2`` the function returns
+ ``True`` is returned otherwise ``False``
+ """
+ return (path.exists(path1)
+ and os.stat(path1).st_ctime > os.stat(path2).st_ctime)
+
+def pass_handle(self, node): # pylint: disable=W0613
+ pass
+
+# setup conversion tools and sphinx extension
+# -------------------------------------------
+
+# Graphviz's dot(1) support
+dot_cmd = None
+
+# ImageMagick' convert(1) support
+convert_cmd = None
+
+
+def setup(app):
+ # check toolchain first
+ app.connect('builder-inited', setupTools)
+
+ # image handling
+ app.add_directive("kernel-image", KernelImage)
+ app.add_node(kernel_image,
+ html = (visit_kernel_image, pass_handle),
+ latex = (visit_kernel_image, pass_handle),
+ texinfo = (visit_kernel_image, pass_handle),
+ text = (visit_kernel_image, pass_handle),
+ man = (visit_kernel_image, pass_handle), )
+
+ # figure handling
+ app.add_directive("kernel-figure", KernelFigure)
+ app.add_node(kernel_figure,
+ html = (visit_kernel_figure, pass_handle),
+ latex = (visit_kernel_figure, pass_handle),
+ texinfo = (visit_kernel_figure, pass_handle),
+ text = (visit_kernel_figure, pass_handle),
+ man = (visit_kernel_figure, pass_handle), )
+
+ # render handling
+ app.add_directive('kernel-render', KernelRender)
+ app.add_node(kernel_render,
+ html = (visit_kernel_render, pass_handle),
+ latex = (visit_kernel_render, pass_handle),
+ texinfo = (visit_kernel_render, pass_handle),
+ text = (visit_kernel_render, pass_handle),
+ man = (visit_kernel_render, pass_handle), )
+
+ app.connect('doctree-read', add_kernel_figure_to_std_domain)
+
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
+
+
+def setupTools(app):
+ u"""
+ Check available build tools and log some *verbose* messages.
+
+ This function is called once, when the builder is initiated.
+ """
+ global dot_cmd, convert_cmd # pylint: disable=W0603
+ kernellog.verbose(app, "kfigure: check installed tools ...")
+
+ dot_cmd = which('dot')
+ convert_cmd = which('convert')
+
+ if dot_cmd:
+ kernellog.verbose(app, "use dot(1) from: " + dot_cmd)
+ else:
+ kernellog.warn(app, "dot(1) not found, for better output quality install "
+ "graphviz from https://www.graphviz.org")
+ if convert_cmd:
+ kernellog.verbose(app, "use convert(1) from: " + convert_cmd)
+ else:
+ kernellog.warn(app,
+ "convert(1) not found, for SVG to PDF conversion install "
+ "ImageMagick (https://www.imagemagick.org)")
+
+
+# integrate conversion tools
+# --------------------------
+
+RENDER_MARKUP_EXT = {
+ # The '.ext' must be handled by convert_image(..) function's *in_ext* input.
+ # <name> : <.ext>
+ 'DOT' : '.dot',
+ 'SVG' : '.svg'
+}
+
+def convert_image(img_node, translator, src_fname=None):
+ """Convert a image node for the builder.
+
+ Different builder prefer different image formats, e.g. *latex* builder
+ prefer PDF while *html* builder prefer SVG format for images.
+
+ This function handles output image formats in dependence of source the
+ format (of the image) and the translator's output format.
+ """
+ app = translator.builder.app
+
+ fname, in_ext = path.splitext(path.basename(img_node['uri']))
+ if src_fname is None:
+ src_fname = path.join(translator.builder.srcdir, img_node['uri'])
+ if not path.exists(src_fname):
+ src_fname = path.join(translator.builder.outdir, img_node['uri'])
+
+ dst_fname = None
+
+ # in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages
+
+ kernellog.verbose(app, 'assert best format for: ' + img_node['uri'])
+
+ if in_ext == '.dot':
+
+ if not dot_cmd:
+ kernellog.verbose(app,
+ "dot from graphviz not available / include DOT raw.")
+ img_node.replace_self(file2literal(src_fname))
+
+ elif translator.builder.format == 'latex':
+ dst_fname = path.join(translator.builder.outdir, fname + '.pdf')
+ img_node['uri'] = fname + '.pdf'
+ img_node['candidates'] = {'*': fname + '.pdf'}
+
+
+ elif translator.builder.format == 'html':
+ dst_fname = path.join(
+ translator.builder.outdir,
+ translator.builder.imagedir,
+ fname + '.svg')
+ img_node['uri'] = path.join(
+ translator.builder.imgpath, fname + '.svg')
+ img_node['candidates'] = {
+ '*': path.join(translator.builder.imgpath, fname + '.svg')}
+
+ else:
+ # all other builder formats will include DOT as raw
+ img_node.replace_self(file2literal(src_fname))
+
+ elif in_ext == '.svg':
+
+ if translator.builder.format == 'latex':
+ if convert_cmd is None:
+ kernellog.verbose(app,
+ "no SVG to PDF conversion available / include SVG raw.")
+ img_node.replace_self(file2literal(src_fname))
+ else:
+ dst_fname = path.join(translator.builder.outdir, fname + '.pdf')
+ img_node['uri'] = fname + '.pdf'
+ img_node['candidates'] = {'*': fname + '.pdf'}
+
+ if dst_fname:
+ # the builder needs not to copy one more time, so pop it if exists.
+ translator.builder.images.pop(img_node['uri'], None)
+ _name = dst_fname[len(translator.builder.outdir) + 1:]
+
+ if isNewer(dst_fname, src_fname):
+ kernellog.verbose(app,
+ "convert: {out}/%s already exists and is newer" % _name)
+
+ else:
+ ok = False
+ mkdir(path.dirname(dst_fname))
+
+ if in_ext == '.dot':
+ kernellog.verbose(app, 'convert DOT to: {out}/' + _name)
+ ok = dot2format(app, src_fname, dst_fname)
+
+ elif in_ext == '.svg':
+ kernellog.verbose(app, 'convert SVG to: {out}/' + _name)
+ ok = svg2pdf(app, src_fname, dst_fname)
+
+ if not ok:
+ img_node.replace_self(file2literal(src_fname))
+
+
+def dot2format(app, dot_fname, out_fname):
+ """Converts DOT file to ``out_fname`` using ``dot(1)``.
+
+ * ``dot_fname`` pathname of the input DOT file, including extension ``.dot``
+ * ``out_fname`` pathname of the output file, including format extension
+
+ The *format extension* depends on the ``dot`` command (see ``man dot``
+ option ``-Txxx``). Normally you will use one of the following extensions:
+
+ - ``.ps`` for PostScript,
+ - ``.svg`` or ``svgz`` for Structured Vector Graphics,
+ - ``.fig`` for XFIG graphics and
+ - ``.png`` or ``gif`` for common bitmap graphics.
+
+ """
+ out_format = path.splitext(out_fname)[1][1:]
+ cmd = [dot_cmd, '-T%s' % out_format, dot_fname]
+ exit_code = 42
+
+ with open(out_fname, "w") as out:
+ exit_code = subprocess.call(cmd, stdout = out)
+ if exit_code != 0:
+ kernellog.warn(app,
+ "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
+ return bool(exit_code == 0)
+
+def svg2pdf(app, svg_fname, pdf_fname):
+ """Converts SVG to PDF with ``convert(1)`` command.
+
+ Uses ``convert(1)`` from ImageMagick (https://www.imagemagick.org) for
+ conversion. Returns ``True`` on success and ``False`` if an error occurred.
+
+ * ``svg_fname`` pathname of the input SVG file with extension (``.svg``)
+ * ``pdf_name`` pathname of the output PDF file with extension (``.pdf``)
+
+ """
+ cmd = [convert_cmd, svg_fname, pdf_fname]
+ # use stdout and stderr from parent
+ exit_code = subprocess.call(cmd)
+ if exit_code != 0:
+ kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
+ return bool(exit_code == 0)
+
+
+# image handling
+# ---------------------
+
+def visit_kernel_image(self, node): # pylint: disable=W0613
+ """Visitor of the ``kernel_image`` Node.
+
+ Handles the ``image`` child-node with the ``convert_image(...)``.
+ """
+ img_node = node[0]
+ convert_image(img_node, self)
+
+class kernel_image(nodes.image):
+ """Node for ``kernel-image`` directive."""
+ pass
+
+class KernelImage(images.Image):
+ u"""KernelImage directive
+
+ Earns everything from ``.. image::`` directive, except *remote URI* and
+ *glob* pattern. The KernelImage wraps a image node into a
+ kernel_image node. See ``visit_kernel_image``.
+ """
+
+ def run(self):
+ uri = self.arguments[0]
+ if uri.endswith('.*') or uri.find('://') != -1:
+ raise self.severe(
+ 'Error in "%s: %s": glob pattern and remote images are not allowed'
+ % (self.name, uri))
+ result = images.Image.run(self)
+ if len(result) == 2 or isinstance(result[0], nodes.system_message):
+ return result
+ (image_node,) = result
+ # wrap image node into a kernel_image node / see visitors
+ node = kernel_image('', image_node)
+ return [node]
+
+# figure handling
+# ---------------------
+
+def visit_kernel_figure(self, node): # pylint: disable=W0613
+ """Visitor of the ``kernel_figure`` Node.
+
+ Handles the ``image`` child-node with the ``convert_image(...)``.
+ """
+ img_node = node[0][0]
+ convert_image(img_node, self)
+
+class kernel_figure(nodes.figure):
+ """Node for ``kernel-figure`` directive."""
+
+class KernelFigure(Figure):
+ u"""KernelImage directive
+
+ Earns everything from ``.. figure::`` directive, except *remote URI* and
+ *glob* pattern. The KernelFigure wraps a figure node into a kernel_figure
+ node. See ``visit_kernel_figure``.
+ """
+
+ def run(self):
+ uri = self.arguments[0]
+ if uri.endswith('.*') or uri.find('://') != -1:
+ raise self.severe(
+ 'Error in "%s: %s":'
+ ' glob pattern and remote images are not allowed'
+ % (self.name, uri))
+ result = Figure.run(self)
+ if len(result) == 2 or isinstance(result[0], nodes.system_message):
+ return result
+ (figure_node,) = result
+ # wrap figure node into a kernel_figure node / see visitors
+ node = kernel_figure('', figure_node)
+ return [node]
+
+
+# render handling
+# ---------------------
+
+def visit_kernel_render(self, node):
+ """Visitor of the ``kernel_render`` Node.
+
+ If rendering tools available, save the markup of the ``literal_block`` child
+ node into a file and replace the ``literal_block`` node with a new created
+ ``image`` node, pointing to the saved markup file. Afterwards, handle the
+ image child-node with the ``convert_image(...)``.
+ """
+ app = self.builder.app
+ srclang = node.get('srclang')
+
+ kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang))
+
+ tmp_ext = RENDER_MARKUP_EXT.get(srclang, None)
+ if tmp_ext is None:
+ kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang))
+ return
+
+ if not dot_cmd and tmp_ext == '.dot':
+ kernellog.verbose(app, "dot from graphviz not available / include raw.")
+ return
+
+ literal_block = node[0]
+
+ code = literal_block.astext()
+ hashobj = code.encode('utf-8') # str(node.attributes)
+ fname = path.join('%s-%s' % (srclang, sha1(hashobj).hexdigest()))
+
+ tmp_fname = path.join(
+ self.builder.outdir, self.builder.imagedir, fname + tmp_ext)
+
+ if not path.isfile(tmp_fname):
+ mkdir(path.dirname(tmp_fname))
+ with open(tmp_fname, "w") as out:
+ out.write(code)
+
+ img_node = nodes.image(node.rawsource, **node.attributes)
+ img_node['uri'] = path.join(self.builder.imgpath, fname + tmp_ext)
+ img_node['candidates'] = {
+ '*': path.join(self.builder.imgpath, fname + tmp_ext)}
+
+ literal_block.replace_self(img_node)
+ convert_image(img_node, self, tmp_fname)
+
+
+class kernel_render(nodes.General, nodes.Inline, nodes.Element):
+ """Node for ``kernel-render`` directive."""
+ pass
+
+class KernelRender(Figure):
+ u"""KernelRender directive
+
+ Render content by external tool. Has all the options known from the
+ *figure* directive, plus option ``caption``. If ``caption`` has a
+ value, a figure node with the *caption* is inserted. If not, a image node is
+ inserted.
+
+ The KernelRender directive wraps the text of the directive into a
+ literal_block node and wraps it into a kernel_render node. See
+ ``visit_kernel_render``.
+ """
+ has_content = True
+ required_arguments = 1
+ optional_arguments = 0
+ final_argument_whitespace = False
+
+ # earn options from 'figure'
+ option_spec = Figure.option_spec.copy()
+ option_spec['caption'] = directives.unchanged
+
+ def run(self):
+ return [self.build_node()]
+
+ def build_node(self):
+
+ srclang = self.arguments[0].strip()
+ if srclang not in RENDER_MARKUP_EXT.keys():
+ return [self.state_machine.reporter.warning(
+ 'Unknown source language "%s", use one of: %s.' % (
+ srclang, ",".join(RENDER_MARKUP_EXT.keys())),
+ line=self.lineno)]
+
+ code = '\n'.join(self.content)
+ if not code.strip():
+ return [self.state_machine.reporter.warning(
+ 'Ignoring "%s" directive without content.' % (
+ self.name),
+ line=self.lineno)]
+
+ node = kernel_render()
+ node['alt'] = self.options.get('alt','')
+ node['srclang'] = srclang
+ literal_node = nodes.literal_block(code, code)
+ node += literal_node
+
+ caption = self.options.get('caption')
+ if caption:
+ # parse caption's content
+ parsed = nodes.Element()
+ self.state.nested_parse(
+ ViewList([caption], source=''), self.content_offset, parsed)
+ caption_node = nodes.caption(
+ parsed[0].rawsource, '', *parsed[0].children)
+ caption_node.source = parsed[0].source
+ caption_node.line = parsed[0].line
+
+ figure_node = nodes.figure('', node)
+ for k,v in self.options.items():
+ figure_node[k] = v
+ figure_node += caption_node
+
+ node = figure_node
+
+ return node
+
+def add_kernel_figure_to_std_domain(app, doctree):
+ """Add kernel-figure anchors to 'std' domain.
+
+ The ``StandardDomain.process_doc(..)`` method does not know how to resolve
+ the caption (label) of ``kernel-figure`` directive (it only knows about
+ standard nodes, e.g. table, figure etc.). Without any additional handling
+ this will result in a 'undefined label' for kernel-figures.
+
+ This handle adds labels of kernel-figure to the 'std' domain labels.
+ """
+
+ std = app.env.domains["std"]
+ docname = app.env.docname
+ labels = std.data["labels"]
+
+ for name, explicit in iteritems(doctree.nametypes):
+ if not explicit:
+ continue
+ labelid = doctree.nameids[name]
+ if labelid is None:
+ continue
+ node = doctree.ids[labelid]
+
+ if node.tagname == 'kernel_figure':
+ for n in node.next_node():
+ if n.tagname == 'caption':
+ sectname = clean_astext(n)
+ # add label to std domain
+ labels[name] = docname, labelid, sectname
+ break
diff --git a/roms/u-boot/doc/sphinx/load_config.py b/roms/u-boot/doc/sphinx/load_config.py
new file mode 100644
index 000000000..eeb394b39
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/load_config.py
@@ -0,0 +1,57 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=R0903, C0330, R0914, R0912, E0401
+
+import os
+import sys
+from sphinx.util.pycompat import execfile_
+
+# ------------------------------------------------------------------------------
+def loadConfig(namespace):
+# ------------------------------------------------------------------------------
+
+ u"""Load an additional configuration file into *namespace*.
+
+ The name of the configuration file is taken from the environment
+ ``SPHINX_CONF``. The external configuration file extends (or overwrites) the
+ configuration values from the origin ``conf.py``. With this you are able to
+ maintain *build themes*. """
+
+ config_file = os.environ.get("SPHINX_CONF", None)
+ if (config_file is not None
+ and os.path.normpath(namespace["__file__"]) != os.path.normpath(config_file) ):
+ config_file = os.path.abspath(config_file)
+
+ # Let's avoid one conf.py file just due to latex_documents
+ start = config_file.find('Documentation/')
+ if start >= 0:
+ start = config_file.find('/', start + 1)
+
+ end = config_file.rfind('/')
+ if start >= 0 and end > 0:
+ dir = config_file[start + 1:end]
+
+ print("source directory: %s" % dir)
+ new_latex_docs = []
+ latex_documents = namespace['latex_documents']
+
+ for l in latex_documents:
+ if l[0].find(dir + '/') == 0:
+ has = True
+ fn = l[0][len(dir) + 1:]
+ new_latex_docs.append((fn, l[1], l[2], l[3], l[4]))
+ break
+
+ namespace['latex_documents'] = new_latex_docs
+
+ # If there is an extra conf.py file, load it
+ if os.path.isfile(config_file):
+ sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
+ config = namespace.copy()
+ config['__file__'] = config_file
+ execfile_(config_file, config)
+ del config['__file__']
+ namespace.update(config)
+ else:
+ config = namespace.copy()
+ config['tags'].add("subproject")
+ namespace.update(config)
diff --git a/roms/u-boot/doc/sphinx/maintainers_include.py b/roms/u-boot/doc/sphinx/maintainers_include.py
new file mode 100755
index 000000000..dc8fed48d
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/maintainers_include.py
@@ -0,0 +1,197 @@
+#!/usr/bin/env python
+# SPDX-License-Identifier: GPL-2.0
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=R0903, C0330, R0914, R0912, E0401
+
+u"""
+ maintainers-include
+ ~~~~~~~~~~~~~~~~~~~
+
+ Implementation of the ``maintainers-include`` reST-directive.
+
+ :copyright: Copyright (C) 2019 Kees Cook <keescook@chromium.org>
+ :license: GPL Version 2, June 1991 see linux/COPYING for details.
+
+ The ``maintainers-include`` reST-directive performs extensive parsing
+ specific to the Linux kernel's standard "MAINTAINERS" file, in an
+ effort to avoid needing to heavily mark up the original plain text.
+"""
+
+import sys
+import re
+import os.path
+
+from docutils import statemachine
+from docutils.utils.error_reporting import ErrorString
+from docutils.parsers.rst import Directive
+from docutils.parsers.rst.directives.misc import Include
+
+__version__ = '1.0'
+
+def setup(app):
+ app.add_directive("maintainers-include", MaintainersInclude)
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
+
+class MaintainersInclude(Include):
+ u"""MaintainersInclude (``maintainers-include``) directive"""
+ required_arguments = 0
+
+ def parse_maintainers(self, path):
+ """Parse all the MAINTAINERS lines into ReST for human-readability"""
+
+ result = list()
+ result.append(".. _maintainers:")
+ result.append("")
+
+ # Poor man's state machine.
+ descriptions = False
+ maintainers = False
+ subsystems = False
+
+ # Field letter to field name mapping.
+ field_letter = None
+ fields = dict()
+
+ prev = None
+ field_prev = ""
+ field_content = ""
+
+ for line in open(path):
+ if sys.version_info.major == 2:
+ line = unicode(line, 'utf-8')
+ # Have we reached the end of the preformatted Descriptions text?
+ if descriptions and line.startswith('Maintainers'):
+ descriptions = False
+ # Ensure a blank line following the last "|"-prefixed line.
+ result.append("")
+
+ # Start subsystem processing? This is to skip processing the text
+ # between the Maintainers heading and the first subsystem name.
+ if maintainers and not subsystems:
+ if re.search('^[A-Z0-9]', line):
+ subsystems = True
+
+ # Drop needless input whitespace.
+ line = line.rstrip()
+
+ # Linkify all non-wildcard refs to ReST files in Documentation/.
+ pat = '(Documentation/([^\s\?\*]*)\.rst)'
+ m = re.search(pat, line)
+ if m:
+ # maintainers.rst is in a subdirectory, so include "../".
+ line = re.sub(pat, ':doc:`%s <../%s>`' % (m.group(2), m.group(2)), line)
+
+ # Check state machine for output rendering behavior.
+ output = None
+ if descriptions:
+ # Escape the escapes in preformatted text.
+ output = "| %s" % (line.replace("\\", "\\\\"))
+ # Look for and record field letter to field name mappings:
+ # R: Designated *reviewer*: FullName <address@domain>
+ m = re.search("\s(\S):\s", line)
+ if m:
+ field_letter = m.group(1)
+ if field_letter and not field_letter in fields:
+ m = re.search("\*([^\*]+)\*", line)
+ if m:
+ fields[field_letter] = m.group(1)
+ elif subsystems:
+ # Skip empty lines: subsystem parser adds them as needed.
+ if len(line) == 0:
+ continue
+ # Subsystem fields are batched into "field_content"
+ if line[1] != ':':
+ # Render a subsystem entry as:
+ # SUBSYSTEM NAME
+ # ~~~~~~~~~~~~~~
+
+ # Flush pending field content.
+ output = field_content + "\n\n"
+ field_content = ""
+
+ # Collapse whitespace in subsystem name.
+ heading = re.sub("\s+", " ", line)
+ output = output + "%s\n%s" % (heading, "~" * len(heading))
+ field_prev = ""
+ else:
+ # Render a subsystem field as:
+ # :Field: entry
+ # entry...
+ field, details = line.split(':', 1)
+ details = details.strip()
+
+ # Mark paths (and regexes) as literal text for improved
+ # readability and to escape any escapes.
+ if field in ['F', 'N', 'X', 'K']:
+ # But only if not already marked :)
+ if not ':doc:' in details:
+ details = '``%s``' % (details)
+
+ # Comma separate email field continuations.
+ if field == field_prev and field_prev in ['M', 'R', 'L']:
+ field_content = field_content + ","
+
+ # Do not repeat field names, so that field entries
+ # will be collapsed together.
+ if field != field_prev:
+ output = field_content + "\n"
+ field_content = ":%s:" % (fields.get(field, field))
+ field_content = field_content + "\n\t%s" % (details)
+ field_prev = field
+ else:
+ output = line
+
+ # Re-split on any added newlines in any above parsing.
+ if output != None:
+ for separated in output.split('\n'):
+ result.append(separated)
+
+ # Update the state machine when we find heading separators.
+ if line.startswith('----------'):
+ if prev.startswith('Descriptions'):
+ descriptions = True
+ if prev.startswith('Maintainers'):
+ maintainers = True
+
+ # Retain previous line for state machine transitions.
+ prev = line
+
+ # Flush pending field contents.
+ if field_content != "":
+ for separated in field_content.split('\n'):
+ result.append(separated)
+
+ output = "\n".join(result)
+ # For debugging the pre-rendered results...
+ #print(output, file=open("/tmp/MAINTAINERS.rst", "w"))
+
+ self.state_machine.insert_input(
+ statemachine.string2lines(output), path)
+
+ def run(self):
+ """Include the MAINTAINERS file as part of this reST file."""
+ if not self.state.document.settings.file_insertion_enabled:
+ raise self.warning('"%s" directive disabled.' % self.name)
+
+ # Walk up source path directories to find Documentation/../
+ path = self.state_machine.document.attributes['source']
+ path = os.path.realpath(path)
+ tail = path
+ while tail != "Documentation" and tail != "":
+ (path, tail) = os.path.split(path)
+
+ # Append "MAINTAINERS"
+ path = os.path.join(path, "MAINTAINERS")
+
+ try:
+ self.state.document.settings.record_dependencies.add(path)
+ lines = self.parse_maintainers(path)
+ except IOError as error:
+ raise self.severe('Problems with "%s" directive path:\n%s.' %
+ (self.name, ErrorString(error)))
+
+ return []
diff --git a/roms/u-boot/doc/sphinx/parallel-wrapper.sh b/roms/u-boot/doc/sphinx/parallel-wrapper.sh
new file mode 100644
index 000000000..e54c44ce1
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/parallel-wrapper.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Figure out if we should follow a specific parallelism from the make
+# environment (as exported by scripts/jobserver-exec), or fall back to
+# the "auto" parallelism when "-jN" is not specified at the top-level
+# "make" invocation.
+
+sphinx="$1"
+shift || true
+
+parallel="$PARALLELISM"
+if [ -z "$parallel" ] ; then
+ # If no parallelism is specified at the top-level make, then
+ # fall back to the expected "-jauto" mode that the "htmldocs"
+ # target has had.
+ auto=$(perl -e 'open IN,"'"$sphinx"' --version 2>&1 |";
+ while (<IN>) {
+ if (m/([\d\.]+)/) {
+ print "auto" if ($1 >= "1.7")
+ }
+ }
+ close IN')
+ if [ -n "$auto" ] ; then
+ parallel="$auto"
+ fi
+fi
+# Only if some parallelism has been determined do we add the -jN option.
+if [ -n "$parallel" ] ; then
+ parallel="-j$parallel"
+fi
+
+exec "$sphinx" $parallel "$@"
diff --git a/roms/u-boot/doc/sphinx/parse-headers.pl b/roms/u-boot/doc/sphinx/parse-headers.pl
new file mode 100755
index 000000000..b063f2f1c
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/parse-headers.pl
@@ -0,0 +1,401 @@
+#!/usr/bin/env perl
+use strict;
+use Text::Tabs;
+use Getopt::Long;
+use Pod::Usage;
+
+my $debug;
+my $help;
+my $man;
+
+GetOptions(
+ "debug" => \$debug,
+ 'usage|?' => \$help,
+ 'help' => \$man
+) or pod2usage(2);
+
+pod2usage(1) if $help;
+pod2usage(-exitstatus => 0, -verbose => 2) if $man;
+pod2usage(2) if (scalar @ARGV < 2 || scalar @ARGV > 3);
+
+my ($file_in, $file_out, $file_exceptions) = @ARGV;
+
+my $data;
+my %ioctls;
+my %defines;
+my %typedefs;
+my %enums;
+my %enum_symbols;
+my %structs;
+
+require Data::Dumper if ($debug);
+
+#
+# read the file and get identifiers
+#
+
+my $is_enum = 0;
+my $is_comment = 0;
+open IN, $file_in or die "Can't open $file_in";
+while (<IN>) {
+ $data .= $_;
+
+ my $ln = $_;
+ if (!$is_comment) {
+ $ln =~ s,/\*.*(\*/),,g;
+
+ $is_comment = 1 if ($ln =~ s,/\*.*,,);
+ } else {
+ if ($ln =~ s,^(.*\*/),,) {
+ $is_comment = 0;
+ } else {
+ next;
+ }
+ }
+
+ if ($is_enum && $ln =~ m/^\s*([_\w][\w\d_]+)\s*[\,=]?/) {
+ my $s = $1;
+ my $n = $1;
+ $n =~ tr/A-Z/a-z/;
+ $n =~ tr/_/-/;
+
+ $enum_symbols{$s} = "\\ :ref:`$s <$n>`\\ ";
+
+ $is_enum = 0 if ($is_enum && m/\}/);
+ next;
+ }
+ $is_enum = 0 if ($is_enum && m/\}/);
+
+ if ($ln =~ m/^\s*#\s*define\s+([_\w][\w\d_]+)\s+_IO/) {
+ my $s = $1;
+ my $n = $1;
+ $n =~ tr/A-Z/a-z/;
+
+ $ioctls{$s} = "\\ :ref:`$s <$n>`\\ ";
+ next;
+ }
+
+ if ($ln =~ m/^\s*#\s*define\s+([_\w][\w\d_]+)\s+/) {
+ my $s = $1;
+ my $n = $1;
+ $n =~ tr/A-Z/a-z/;
+ $n =~ tr/_/-/;
+
+ $defines{$s} = "\\ :ref:`$s <$n>`\\ ";
+ next;
+ }
+
+ if ($ln =~ m/^\s*typedef\s+([_\w][\w\d_]+)\s+(.*)\s+([_\w][\w\d_]+);/) {
+ my $s = $2;
+ my $n = $3;
+
+ $typedefs{$n} = "\\ :c:type:`$n <$s>`\\ ";
+ next;
+ }
+ if ($ln =~ m/^\s*enum\s+([_\w][\w\d_]+)\s+\{/
+ || $ln =~ m/^\s*enum\s+([_\w][\w\d_]+)$/
+ || $ln =~ m/^\s*typedef\s*enum\s+([_\w][\w\d_]+)\s+\{/
+ || $ln =~ m/^\s*typedef\s*enum\s+([_\w][\w\d_]+)$/) {
+ my $s = $1;
+
+ $enums{$s} = "enum :c:type:`$s`\\ ";
+
+ $is_enum = $1;
+ next;
+ }
+ if ($ln =~ m/^\s*struct\s+([_\w][\w\d_]+)\s+\{/
+ || $ln =~ m/^\s*struct\s+([[_\w][\w\d_]+)$/
+ || $ln =~ m/^\s*typedef\s*struct\s+([_\w][\w\d_]+)\s+\{/
+ || $ln =~ m/^\s*typedef\s*struct\s+([[_\w][\w\d_]+)$/
+ ) {
+ my $s = $1;
+
+ $structs{$s} = "struct $s\\ ";
+ next;
+ }
+}
+close IN;
+
+#
+# Handle multi-line typedefs
+#
+
+my @matches = ($data =~ m/typedef\s+struct\s+\S+?\s*\{[^\}]+\}\s*(\S+)\s*\;/g,
+ $data =~ m/typedef\s+enum\s+\S+?\s*\{[^\}]+\}\s*(\S+)\s*\;/g,);
+foreach my $m (@matches) {
+ my $s = $m;
+
+ $typedefs{$s} = "\\ :c:type:`$s`\\ ";
+ next;
+}
+
+#
+# Handle exceptions, if any
+#
+
+my %def_reftype = (
+ "ioctl" => ":ref",
+ "define" => ":ref",
+ "symbol" => ":ref",
+ "typedef" => ":c:type",
+ "enum" => ":c:type",
+ "struct" => ":c:type",
+);
+
+if ($file_exceptions) {
+ open IN, $file_exceptions or die "Can't read $file_exceptions";
+ while (<IN>) {
+ next if (m/^\s*$/ || m/^\s*#/);
+
+ # Parsers to ignore a symbol
+
+ if (m/^ignore\s+ioctl\s+(\S+)/) {
+ delete $ioctls{$1} if (exists($ioctls{$1}));
+ next;
+ }
+ if (m/^ignore\s+define\s+(\S+)/) {
+ delete $defines{$1} if (exists($defines{$1}));
+ next;
+ }
+ if (m/^ignore\s+typedef\s+(\S+)/) {
+ delete $typedefs{$1} if (exists($typedefs{$1}));
+ next;
+ }
+ if (m/^ignore\s+enum\s+(\S+)/) {
+ delete $enums{$1} if (exists($enums{$1}));
+ next;
+ }
+ if (m/^ignore\s+struct\s+(\S+)/) {
+ delete $structs{$1} if (exists($structs{$1}));
+ next;
+ }
+ if (m/^ignore\s+symbol\s+(\S+)/) {
+ delete $enum_symbols{$1} if (exists($enum_symbols{$1}));
+ next;
+ }
+
+ # Parsers to replace a symbol
+ my ($type, $old, $new, $reftype);
+
+ if (m/^replace\s+(\S+)\s+(\S+)\s+(\S+)/) {
+ $type = $1;
+ $old = $2;
+ $new = $3;
+ } else {
+ die "Can't parse $file_exceptions: $_";
+ }
+
+ if ($new =~ m/^\:c\:(data|func|macro|type)\:\`(.+)\`/) {
+ $reftype = ":c:$1";
+ $new = $2;
+ } elsif ($new =~ m/\:ref\:\`(.+)\`/) {
+ $reftype = ":ref";
+ $new = $1;
+ } else {
+ $reftype = $def_reftype{$type};
+ }
+ $new = "$reftype:`$old <$new>`";
+
+ if ($type eq "ioctl") {
+ $ioctls{$old} = $new if (exists($ioctls{$old}));
+ next;
+ }
+ if ($type eq "define") {
+ $defines{$old} = $new if (exists($defines{$old}));
+ next;
+ }
+ if ($type eq "symbol") {
+ $enum_symbols{$old} = $new if (exists($enum_symbols{$old}));
+ next;
+ }
+ if ($type eq "typedef") {
+ $typedefs{$old} = $new if (exists($typedefs{$old}));
+ next;
+ }
+ if ($type eq "enum") {
+ $enums{$old} = $new if (exists($enums{$old}));
+ next;
+ }
+ if ($type eq "struct") {
+ $structs{$old} = $new if (exists($structs{$old}));
+ next;
+ }
+
+ die "Can't parse $file_exceptions: $_";
+ }
+}
+
+if ($debug) {
+ print Data::Dumper->Dump([\%ioctls], [qw(*ioctls)]) if (%ioctls);
+ print Data::Dumper->Dump([\%typedefs], [qw(*typedefs)]) if (%typedefs);
+ print Data::Dumper->Dump([\%enums], [qw(*enums)]) if (%enums);
+ print Data::Dumper->Dump([\%structs], [qw(*structs)]) if (%structs);
+ print Data::Dumper->Dump([\%defines], [qw(*defines)]) if (%defines);
+ print Data::Dumper->Dump([\%enum_symbols], [qw(*enum_symbols)]) if (%enum_symbols);
+}
+
+#
+# Align block
+#
+$data = expand($data);
+$data = " " . $data;
+$data =~ s/\n/\n /g;
+$data =~ s/\n\s+$/\n/g;
+$data =~ s/\n\s+\n/\n\n/g;
+
+#
+# Add escape codes for special characters
+#
+$data =~ s,([\_\`\*\<\>\&\\\\:\/\|\%\$\#\{\}\~\^]),\\$1,g;
+
+$data =~ s,DEPRECATED,**DEPRECATED**,g;
+
+#
+# Add references
+#
+
+my $start_delim = "[ \n\t\(\=\*\@]";
+my $end_delim = "(\\s|,|\\\\=|\\\\:|\\;|\\\)|\\}|\\{)";
+
+foreach my $r (keys %ioctls) {
+ my $s = $ioctls{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+
+ $data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
+}
+
+foreach my $r (keys %defines) {
+ my $s = $defines{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+
+ $data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
+}
+
+foreach my $r (keys %enum_symbols) {
+ my $s = $enum_symbols{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+
+ $data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
+}
+
+foreach my $r (keys %enums) {
+ my $s = $enums{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+
+ $data =~ s/enum\s+($r)$end_delim/$s$2/g;
+}
+
+foreach my $r (keys %structs) {
+ my $s = $structs{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+
+ $data =~ s/struct\s+($r)$end_delim/$s$2/g;
+}
+
+foreach my $r (keys %typedefs) {
+ my $s = $typedefs{$r};
+
+ $r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
+
+ print "$r -> $s\n" if ($debug);
+ $data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
+}
+
+$data =~ s/\\ ([\n\s])/\1/g;
+
+#
+# Generate output file
+#
+
+my $title = $file_in;
+$title =~ s,.*/,,;
+
+open OUT, "> $file_out" or die "Can't open $file_out";
+print OUT ".. -*- coding: utf-8; mode: rst -*-\n\n";
+print OUT "$title\n";
+print OUT "=" x length($title);
+print OUT "\n\n.. parsed-literal::\n\n";
+print OUT $data;
+close OUT;
+
+__END__
+
+=head1 NAME
+
+parse_headers.pl - parse a C file, in order to identify functions, structs,
+enums and defines and create cross-references to a Sphinx book.
+
+=head1 SYNOPSIS
+
+B<parse_headers.pl> [<options>] <C_FILE> <OUT_FILE> [<EXCEPTIONS_FILE>]
+
+Where <options> can be: --debug, --help or --usage.
+
+=head1 OPTIONS
+
+=over 8
+
+=item B<--debug>
+
+Put the script in verbose mode, useful for debugging.
+
+=item B<--usage>
+
+Prints a brief help message and exits.
+
+=item B<--help>
+
+Prints a more detailed help message and exits.
+
+=back
+
+=head1 DESCRIPTION
+
+Convert a C header or source file (C_FILE), into a ReStructured Text
+included via ..parsed-literal block with cross-references for the
+documentation files that describe the API. It accepts an optional
+EXCEPTIONS_FILE with describes what elements will be either ignored or
+be pointed to a non-default reference.
+
+The output is written at the (OUT_FILE).
+
+It is capable of identifying defines, functions, structs, typedefs,
+enums and enum symbols and create cross-references for all of them.
+It is also capable of distinguish #define used for specifying a Linux
+ioctl.
+
+The EXCEPTIONS_FILE contain two rules to allow ignoring a symbol or
+to replace the default references by a custom one.
+
+Please read Documentation/doc-guide/parse-headers.rst at the Kernel's
+tree for more details.
+
+=head1 BUGS
+
+Report bugs to Mauro Carvalho Chehab <mchehab@kernel.org>
+
+=head1 COPYRIGHT
+
+Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab+samsung@kernel.org>.
+
+License GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>.
+
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+=cut
diff --git a/roms/u-boot/doc/sphinx/requirements.txt b/roms/u-boot/doc/sphinx/requirements.txt
new file mode 100644
index 000000000..af79d2c11
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/requirements.txt
@@ -0,0 +1,4 @@
+docutils==0.16
+Sphinx==2.4.4
+sphinx_rtd_theme
+six
diff --git a/roms/u-boot/doc/sphinx/rstFlatTable.py b/roms/u-boot/doc/sphinx/rstFlatTable.py
new file mode 100755
index 000000000..2019a55f6
--- /dev/null
+++ b/roms/u-boot/doc/sphinx/rstFlatTable.py
@@ -0,0 +1,374 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=C0330, R0903, R0912
+
+u"""
+ flat-table
+ ~~~~~~~~~~
+
+ Implementation of the ``flat-table`` reST-directive.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :license: GPL Version 2, June 1991 see linux/COPYING for details.
+
+ The ``flat-table`` (:py:class:`FlatTable`) is a double-stage list similar to
+ the ``list-table`` with some additional features:
+
+ * *column-span*: with the role ``cspan`` a cell can be extended through
+ additional columns
+
+ * *row-span*: with the role ``rspan`` a cell can be extended through
+ additional rows
+
+ * *auto span* rightmost cell of a table row over the missing cells on the
+ right side of that table-row. With Option ``:fill-cells:`` this behavior
+ can changed from *auto span* to *auto fill*, which automaticly inserts
+ (empty) cells instead of spanning the last cell.
+
+ Options:
+
+ * header-rows: [int] count of header rows
+ * stub-columns: [int] count of stub columns
+ * widths: [[int] [int] ... ] widths of columns
+ * fill-cells: instead of autospann missing cells, insert missing cells
+
+ roles:
+
+ * cspan: [int] additionale columns (*morecols*)
+ * rspan: [int] additionale rows (*morerows*)
+"""
+
+# ==============================================================================
+# imports
+# ==============================================================================
+
+import sys
+
+from docutils import nodes
+from docutils.parsers.rst import directives, roles
+from docutils.parsers.rst.directives.tables import Table
+from docutils.utils import SystemMessagePropagation
+
+# ==============================================================================
+# common globals
+# ==============================================================================
+
+__version__ = '1.0'
+
+PY3 = sys.version_info[0] == 3
+PY2 = sys.version_info[0] == 2
+
+if PY3:
+ # pylint: disable=C0103, W0622
+ unicode = str
+ basestring = str
+
+# ==============================================================================
+def setup(app):
+# ==============================================================================
+
+ app.add_directive("flat-table", FlatTable)
+ roles.register_local_role('cspan', c_span)
+ roles.register_local_role('rspan', r_span)
+
+ return dict(
+ version = __version__,
+ parallel_read_safe = True,
+ parallel_write_safe = True
+ )
+
+# ==============================================================================
+def c_span(name, rawtext, text, lineno, inliner, options=None, content=None):
+# ==============================================================================
+ # pylint: disable=W0613
+
+ options = options if options is not None else {}
+ content = content if content is not None else []
+ nodelist = [colSpan(span=int(text))]
+ msglist = []
+ return nodelist, msglist
+
+# ==============================================================================
+def r_span(name, rawtext, text, lineno, inliner, options=None, content=None):
+# ==============================================================================
+ # pylint: disable=W0613
+
+ options = options if options is not None else {}
+ content = content if content is not None else []
+ nodelist = [rowSpan(span=int(text))]
+ msglist = []
+ return nodelist, msglist
+
+
+# ==============================================================================
+class rowSpan(nodes.General, nodes.Element): pass # pylint: disable=C0103,C0321
+class colSpan(nodes.General, nodes.Element): pass # pylint: disable=C0103,C0321
+# ==============================================================================
+
+# ==============================================================================
+class FlatTable(Table):
+# ==============================================================================
+
+ u"""FlatTable (``flat-table``) directive"""
+
+ option_spec = {
+ 'name': directives.unchanged
+ , 'class': directives.class_option
+ , 'header-rows': directives.nonnegative_int
+ , 'stub-columns': directives.nonnegative_int
+ , 'widths': directives.positive_int_list
+ , 'fill-cells' : directives.flag }
+
+ def run(self):
+
+ if not self.content:
+ error = self.state_machine.reporter.error(
+ 'The "%s" directive is empty; content required.' % self.name,
+ nodes.literal_block(self.block_text, self.block_text),
+ line=self.lineno)
+ return [error]
+
+ title, messages = self.make_title()
+ node = nodes.Element() # anonymous container for parsing
+ self.state.nested_parse(self.content, self.content_offset, node)
+
+ tableBuilder = ListTableBuilder(self)
+ tableBuilder.parseFlatTableNode(node)
+ tableNode = tableBuilder.buildTableNode()
+ # SDK.CONSOLE() # print --> tableNode.asdom().toprettyxml()
+ if title:
+ tableNode.insert(0, title)
+ return [tableNode] + messages
+
+
+# ==============================================================================
+class ListTableBuilder(object):
+# ==============================================================================
+
+ u"""Builds a table from a double-stage list"""
+
+ def __init__(self, directive):
+ self.directive = directive
+ self.rows = []
+ self.max_cols = 0
+
+ def buildTableNode(self):
+
+ colwidths = self.directive.get_column_widths(self.max_cols)
+ if isinstance(colwidths, tuple):
+ # Since docutils 0.13, get_column_widths returns a (widths,
+ # colwidths) tuple, where widths is a string (i.e. 'auto').
+ # See https://sourceforge.net/p/docutils/patches/120/.
+ colwidths = colwidths[1]
+ stub_columns = self.directive.options.get('stub-columns', 0)
+ header_rows = self.directive.options.get('header-rows', 0)
+
+ table = nodes.table()
+ tgroup = nodes.tgroup(cols=len(colwidths))
+ table += tgroup
+
+
+ for colwidth in colwidths:
+ colspec = nodes.colspec(colwidth=colwidth)
+ # FIXME: It seems, that the stub method only works well in the
+ # absence of rowspan (observed by the html buidler, the docutils-xml
+ # build seems OK). This is not extraordinary, because there exists
+ # no table directive (except *this* flat-table) which allows to
+ # define coexistent of rowspan and stubs (there was no use-case
+ # before flat-table). This should be reviewed (later).
+ if stub_columns:
+ colspec.attributes['stub'] = 1
+ stub_columns -= 1
+ tgroup += colspec
+ stub_columns = self.directive.options.get('stub-columns', 0)
+
+ if header_rows:
+ thead = nodes.thead()
+ tgroup += thead
+ for row in self.rows[:header_rows]:
+ thead += self.buildTableRowNode(row)
+
+ tbody = nodes.tbody()
+ tgroup += tbody
+
+ for row in self.rows[header_rows:]:
+ tbody += self.buildTableRowNode(row)
+ return table
+
+ def buildTableRowNode(self, row_data, classes=None):
+ classes = [] if classes is None else classes
+ row = nodes.row()
+ for cell in row_data:
+ if cell is None:
+ continue
+ cspan, rspan, cellElements = cell
+
+ attributes = {"classes" : classes}
+ if rspan:
+ attributes['morerows'] = rspan
+ if cspan:
+ attributes['morecols'] = cspan
+ entry = nodes.entry(**attributes)
+ entry.extend(cellElements)
+ row += entry
+ return row
+
+ def raiseError(self, msg):
+ error = self.directive.state_machine.reporter.error(
+ msg
+ , nodes.literal_block(self.directive.block_text
+ , self.directive.block_text)
+ , line = self.directive.lineno )
+ raise SystemMessagePropagation(error)
+
+ def parseFlatTableNode(self, node):
+ u"""parses the node from a :py:class:`FlatTable` directive's body"""
+
+ if len(node) != 1 or not isinstance(node[0], nodes.bullet_list):
+ self.raiseError(
+ 'Error parsing content block for the "%s" directive: '
+ 'exactly one bullet list expected.' % self.directive.name )
+
+ for rowNum, rowItem in enumerate(node[0]):
+ row = self.parseRowItem(rowItem, rowNum)
+ self.rows.append(row)
+ self.roundOffTableDefinition()
+
+ def roundOffTableDefinition(self):
+ u"""Round off the table definition.
+
+ This method rounds off the table definition in :py:member:`rows`.
+
+ * This method inserts the needed ``None`` values for the missing cells
+ arising from spanning cells over rows and/or columns.
+
+ * recount the :py:member:`max_cols`
+
+ * Autospan or fill (option ``fill-cells``) missing cells on the right
+ side of the table-row
+ """
+
+ y = 0
+ while y < len(self.rows):
+ x = 0
+
+ while x < len(self.rows[y]):
+ cell = self.rows[y][x]
+ if cell is None:
+ x += 1
+ continue
+ cspan, rspan = cell[:2]
+ # handle colspan in current row
+ for c in range(cspan):
+ try:
+ self.rows[y].insert(x+c+1, None)
+ except: # pylint: disable=W0702
+ # the user sets ambiguous rowspans
+ pass # SDK.CONSOLE()
+ # handle colspan in spanned rows
+ for r in range(rspan):
+ for c in range(cspan + 1):
+ try:
+ self.rows[y+r+1].insert(x+c, None)
+ except: # pylint: disable=W0702
+ # the user sets ambiguous rowspans
+ pass # SDK.CONSOLE()
+ x += 1
+ y += 1
+
+ # Insert the missing cells on the right side. For this, first
+ # re-calculate the max columns.
+
+ for row in self.rows:
+ if self.max_cols < len(row):
+ self.max_cols = len(row)
+
+ # fill with empty cells or cellspan?
+
+ fill_cells = False
+ if 'fill-cells' in self.directive.options:
+ fill_cells = True
+
+ for row in self.rows:
+ x = self.max_cols - len(row)
+ if x and not fill_cells:
+ if row[-1] is None:
+ row.append( ( x - 1, 0, []) )
+ else:
+ cspan, rspan, content = row[-1]
+ row[-1] = (cspan + x, rspan, content)
+ elif x and fill_cells:
+ for i in range(x):
+ row.append( (0, 0, nodes.comment()) )
+
+ def pprint(self):
+ # for debugging
+ retVal = "[ "
+ for row in self.rows:
+ retVal += "[ "
+ for col in row:
+ if col is None:
+ retVal += ('%r' % col)
+ retVal += "\n , "
+ else:
+ content = col[2][0].astext()
+ if len (content) > 30:
+ content = content[:30] + "..."
+ retVal += ('(cspan=%s, rspan=%s, %r)'
+ % (col[0], col[1], content))
+ retVal += "]\n , "
+ retVal = retVal[:-2]
+ retVal += "]\n , "
+ retVal = retVal[:-2]
+ return retVal + "]"
+
+ def parseRowItem(self, rowItem, rowNum):
+ row = []
+ childNo = 0
+ error = False
+ cell = None
+ target = None
+
+ for child in rowItem:
+ if (isinstance(child , nodes.comment)
+ or isinstance(child, nodes.system_message)):
+ pass
+ elif isinstance(child , nodes.target):
+ target = child
+ elif isinstance(child, nodes.bullet_list):
+ childNo += 1
+ cell = child
+ else:
+ error = True
+ break
+
+ if childNo != 1 or error:
+ self.raiseError(
+ 'Error parsing content block for the "%s" directive: '
+ 'two-level bullet list expected, but row %s does not '
+ 'contain a second-level bullet list.'
+ % (self.directive.name, rowNum + 1))
+
+ for cellItem in cell:
+ cspan, rspan, cellElements = self.parseCellItem(cellItem)
+ if target is not None:
+ cellElements.insert(0, target)
+ row.append( (cspan, rspan, cellElements) )
+ return row
+
+ def parseCellItem(self, cellItem):
+ # search and remove cspan, rspan colspec from the first element in
+ # this listItem (field).
+ cspan = rspan = 0
+ if not len(cellItem):
+ return cspan, rspan, []
+ for elem in cellItem[0]:
+ if isinstance(elem, colSpan):
+ cspan = elem.get("span")
+ elem.parent.remove(elem)
+ continue
+ if isinstance(elem, rowSpan):
+ rspan = elem.get("span")
+ elem.parent.remove(elem)
+ continue
+ return cspan, rspan, cellItem[:]
diff --git a/roms/u-boot/doc/uImage.FIT/beaglebone_vboot.txt b/roms/u-boot/doc/uImage.FIT/beaglebone_vboot.txt
new file mode 100644
index 000000000..ebd2068ed
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/beaglebone_vboot.txt
@@ -0,0 +1,607 @@
+Verified Boot on the Beaglebone Black
+=====================================
+
+Introduction
+------------
+
+Before reading this, please read verified-boot.txt and signature.txt. These
+instructions are for mainline U-Boot from v2014.07 onwards.
+
+There is quite a bit of documentation in this directory describing how
+verified boot works in U-Boot. There is also a test which runs through the
+entire process of signing an image and running U-Boot (sandbox) to check it.
+However, it might be useful to also have an example on a real board.
+
+Beaglebone Black is a fairly common board so seems to be a reasonable choice
+for an example of how to enable verified boot using U-Boot.
+
+First a note that may to help avoid confusion. U-Boot and Linux both use
+device tree. They may use the same device tree source, but it is seldom useful
+for them to use the exact same binary from the same place. More typically,
+U-Boot has its device tree packaged wtih it, and the kernel's device tree is
+packaged with the kernel. In particular this is important with verified boot,
+since U-Boot's device tree must be immutable. If it can be changed then the
+public keys can be changed and verified boot is useless. An attacker can
+simply generate a new key and put his public key into U-Boot so that
+everything verifies. On the other hand the kernel's device tree typically
+changes when the kernel changes, so it is useful to package an updated device
+tree with the kernel binary. U-Boot supports the latter with its flexible FIT
+format (Flat Image Tree).
+
+
+Overview
+--------
+
+The steps are roughly as follows:
+
+1. Build U-Boot for the board, with the verified boot options enabled.
+
+2. Obtain a suitable Linux kernel
+
+3. Create a Image Tree Source file (ITS) file describing how you want the
+kernel to be packaged, compressed and signed.
+
+4. Create a key pair
+
+5. Sign the kernel
+
+6. Put the public key into U-Boot's image
+
+7. Put U-Boot and the kernel onto the board
+
+8. Try it
+
+
+Step 1: Build U-Boot
+--------------------
+
+a. Set up the environment variable to point to your toolchain. You will need
+this for U-Boot and also for the kernel if you build it. For example if you
+installed a Linaro version manually it might be something like:
+
+ export CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-
+
+or if you just installed gcc-arm-linux-gnueabi then it might be
+
+ export CROSS_COMPILE=arm-linux-gnueabi-
+
+b. Configure and build U-Boot with verified boot enabled:
+
+ export UBOOT=/path/to/u-boot
+ cd $UBOOT
+ # You can add -j10 if you have 10 CPUs to make it faster
+ make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
+ export UOUT=$UBOOT/b/am335x_boneblack_vboot
+
+c. You will now have a U-Boot image:
+
+ file b/am335x_boneblack_vboot/u-boot-dtb.img
+b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage, U-Boot 2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image (Not compressed), 395375 bytes, Sat May 31 16:19:04 2014, Load Address: 0x80800000, Entry Point: 0x00000000, Header CRC: 0x0ABD6ACA, Data CRC: 0x36DEF7E4
+
+
+Step 2: Build Linux
+--------------------
+
+a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
+use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
+At the time of writing an SD Boot image can be obtained from here:
+
+ http://www.elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD
+
+You can write this to an SD card and then mount it to extract the kernel and
+device tree files.
+
+You can also build a kernel. Instructions for this are are here:
+
+ http://elinux.org/Building_BBB_Kernel
+
+or you can use your favourite search engine. Following these instructions
+produces a kernel Image and device tree files. For the record the steps were:
+
+ export KERNEL=/path/to/kernel
+ cd $KERNEL
+ git clone git://github.com/beagleboard/kernel.git .
+ git checkout v3.14
+ ./patch.sh
+ cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
+ cd kernel
+ make beaglebone_defconfig
+ make uImage dtbs # -j10 if you have 10 CPUs
+ export OKERNEL=$KERNEL/kernel/arch/arm/boot
+
+c. You now have the 'Image' and 'am335x-boneblack.dtb' files needed to boot.
+
+
+Step 3: Create the ITS
+----------------------
+
+Set up a directory for your work.
+
+ export WORK=/path/to/dir
+ cd $WORK
+
+Put this into a file in that directory called sign.its:
+
+/dts-v1/;
+
+/ {
+ description = "Beaglebone black";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ data = /incbin/("Image.lzo");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ compression = "lzo";
+ load = <0x80008000>;
+ entry = <0x80008000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ fdt-1 {
+ description = "beaglebone-black";
+ data = /incbin/("am335x-boneblack.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel";
+ fdt = "fdt-1";
+ signature-1 {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "fdt", "kernel";
+ };
+ };
+ };
+};
+
+
+The explanation for this is all in the documentation you have already read.
+But briefly it packages a kernel and device tree, and provides a single
+configuration to be signed with a key named 'dev'. The kernel is compressed
+with LZO to make it smaller.
+
+
+Step 4: Create a key pair
+-------------------------
+
+See signature.txt for details on this step.
+
+ cd $WORK
+ mkdir keys
+ openssl genrsa -F4 -out keys/dev.key 2048
+ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+Note: keys/dev.key contains your private key and is very secret. If anyone
+gets access to that file they can sign kernels with it. Keep it secure.
+
+
+Step 5: Sign the kernel
+-----------------------
+
+We need to use mkimage (which was built when you built U-Boot) to package the
+Linux kernel into a FIT (Flat Image Tree, a flexible file format that U-Boot
+can load) using the ITS file you just created.
+
+At the same time we must put the public key into U-Boot device tree, with the
+'required' property, which tells U-Boot that this key must be verified for the
+image to be valid. You will make this key available to U-Boot for booting in
+step 6.
+
+ ln -s $OKERNEL/dts/am335x-boneblack.dtb
+ ln -s $OKERNEL/Image
+ ln -s $UOUT/u-boot-dtb.img
+ cp $UOUT/arch/arm/dts/am335x-boneblack.dtb am335x-boneblack-pubkey.dtb
+ lzop Image
+ $UOUT/tools/mkimage -f sign.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit
+
+You should see something like this:
+
+FIT description: Beaglebone black
+Created: Sun Jun 1 12:50:30 2014
+ Image 0 (kernel)
+ Description: unavailable
+ Created: Sun Jun 1 12:50:30 2014
+ Type: Kernel Image
+ Compression: lzo compressed
+ Data Size: 7790938 Bytes = 7608.34 kB = 7.43 MB
+ Architecture: ARM
+ OS: Linux
+ Load Address: 0x80008000
+ Entry Point: 0x80008000
+ Hash algo: sha1
+ Hash value: c94364646427e10f423837e559898ef02c97b988
+ Image 1 (fdt-1)
+ Description: beaglebone-black
+ Created: Sun Jun 1 12:50:30 2014
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Size: 31547 Bytes = 30.81 kB = 0.03 MB
+ Architecture: ARM
+ Hash algo: sha1
+ Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d
+ Default Configuration: 'conf-1'
+ Configuration 0 (conf-1)
+ Description: unavailable
+ Kernel: kernel
+ FDT: fdt-1
+
+
+Now am335x-boneblack-pubkey.dtb contains the public key and image.fit contains
+the signed kernel. Jump to step 6 if you like, or continue reading to increase
+your understanding.
+
+You can also run fit_check_sign to check it:
+
+ $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+
+which results in:
+
+Verifying Hash Integrity ... sha1,rsa2048:dev+
+## Loading kernel from FIT Image at 7fc6ee469000 ...
+ Using 'conf-1' configuration
+ Verifying Hash Integrity ...
+sha1,rsa2048:dev+
+OK
+
+ Trying 'kernel' kernel subimage
+ Description: unavailable
+ Created: Sun Jun 1 12:50:30 2014
+ Type: Kernel Image
+ Compression: lzo compressed
+ Data Size: 7790938 Bytes = 7608.34 kB = 7.43 MB
+ Architecture: ARM
+ OS: Linux
+ Load Address: 0x80008000
+ Entry Point: 0x80008000
+ Hash algo: sha1
+ Hash value: c94364646427e10f423837e559898ef02c97b988
+ Verifying Hash Integrity ...
+sha1+
+OK
+
+Unimplemented compression type 4
+## Loading fdt from FIT Image at 7fc6ee469000 ...
+ Using 'conf-1' configuration
+ Trying 'fdt-1' fdt subimage
+ Description: beaglebone-black
+ Created: Sun Jun 1 12:50:30 2014
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Size: 31547 Bytes = 30.81 kB = 0.03 MB
+ Architecture: ARM
+ Hash algo: sha1
+ Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d
+ Verifying Hash Integrity ...
+sha1+
+OK
+
+ Loading Flat Device Tree ... OK
+
+## Loading ramdisk from FIT Image at 7fc6ee469000 ...
+ Using 'conf-1' configuration
+Could not find subimage node
+
+Signature check OK
+
+
+At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key
+of size 2048 bits using SHA1 as the hash algorithm. The key name checked was
+'dev' and the '+' means that it verified. If it showed '-' that would be bad.
+
+Once the configuration is verified it is then possible to rely on the hashes
+in each image referenced by that configuration. So fit_check_sign goes on to
+load each of the images. We have a kernel and an FDT but no ramkdisk. In each
+case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1
+hash verified. This means that none of the images has been tampered with.
+
+There is a test in test/vboot which uses U-Boot's sandbox build to verify that
+the above flow works.
+
+But it is fun to do this by hand, so you can load image.fit into a hex editor
+like ghex, and change a byte in the kernel:
+
+ $UOUT/tools/fit_info -f image.fit -n /images/kernel -p data
+NAME: kernel
+LEN: 7790938
+OFF: 168
+
+This tells us that the kernel starts at byte offset 168 (decimal) in image.fit
+and extends for about 7MB. Try changing a byte at 0x2000 (say) and run
+fit_check_sign again. You should see something like:
+
+Verifying Hash Integrity ... sha1,rsa2048:dev+
+## Loading kernel from FIT Image at 7f5a39571000 ...
+ Using 'conf-1' configuration
+ Verifying Hash Integrity ...
+sha1,rsa2048:dev+
+OK
+
+ Trying 'kernel' kernel subimage
+ Description: unavailable
+ Created: Sun Jun 1 13:09:21 2014
+ Type: Kernel Image
+ Compression: lzo compressed
+ Data Size: 7790938 Bytes = 7608.34 kB = 7.43 MB
+ Architecture: ARM
+ OS: Linux
+ Load Address: 0x80008000
+ Entry Point: 0x80008000
+ Hash algo: sha1
+ Hash value: c94364646427e10f423837e559898ef02c97b988
+ Verifying Hash Integrity ...
+sha1 error
+Bad hash value for 'hash-1' hash node in 'kernel' image node
+Bad Data Hash
+
+## Loading fdt from FIT Image at 7f5a39571000 ...
+ Using 'conf-1' configuration
+ Trying 'fdt-1' fdt subimage
+ Description: beaglebone-black
+ Created: Sun Jun 1 13:09:21 2014
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Size: 31547 Bytes = 30.81 kB = 0.03 MB
+ Architecture: ARM
+ Hash algo: sha1
+ Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d
+ Verifying Hash Integrity ...
+sha1+
+OK
+
+ Loading Flat Device Tree ... OK
+
+## Loading ramdisk from FIT Image at 7f5a39571000 ...
+ Using 'conf-1' configuration
+Could not find subimage node
+
+Signature check Bad (error 1)
+
+
+It has detected the change in the kernel.
+
+You can also be sneaky and try to switch images, using the libfdt utilities
+that come with dtc (package name is device-tree-compiler but you will need a
+recent version like 1.4:
+
+ dtc -v
+Version: DTC 1.4.0
+
+First we can check which nodes are actually hashed by the configuration:
+
+ fdtget -l image.fit /
+images
+configurations
+
+ fdtget -l image.fit /configurations
+conf-1
+fdtget -l image.fit /configurations/conf-1
+signature-1
+
+ fdtget -p image.fit /configurations/conf-1/signature-1
+hashed-strings
+hashed-nodes
+timestamp
+signer-version
+signer-name
+value
+algo
+key-name-hint
+sign-images
+
+ fdtget image.fit /configurations/conf-1/signature-1 hashed-nodes
+/ /configurations/conf-1 /images/fdt-1 /images/fdt-1/hash /images/kernel /images/kernel/hash-1
+
+This gives us a bit of a look into the signature that mkimage added. Note you
+can also use fdtdump to list the entire device tree.
+
+Say we want to change the kernel that this configuration uses
+(/images/kernel). We could just put a new kernel in the image, but we will
+need to change the hash to match. Let's simulate that by changing a byte of
+the hash:
+
+ fdtget -tx image.fit /images/kernel/hash-1 value
+c9436464 6427e10f 423837e5 59898ef0 2c97b988
+ fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981
+
+Now check it again:
+
+ $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+rsa_verify_with_keynode: RSA failed to verify: -13
+-
+Failed to verify required signature 'key-dev'
+Signature check Bad (error 1)
+
+This time we don't even get as far as checking the images, since the
+configuration signature doesn't match. We can't change any hashes without the
+signature check noticing. The configuration is essentially locked. U-Boot has
+a public key for which it requires a match, and will not permit the use of any
+configuration that does not match that public key. The only way the
+configuration will match is if it was signed by the matching private key.
+
+It would also be possible to add a new signature node that does match your new
+configuration. But that won't work since you are not allowed to change the
+configuration in any way. Try it with a fresh (valid) image if you like by
+running the mkimage link again. Then:
+
+ fdtput -p image.fit /configurations/conf-1/signature-1 value fred
+ $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
+Verifying Hash Integrity ... -
+sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+rsa_verify_with_keynode: RSA failed to verify: -13
+-
+Failed to verify required signature 'key-dev'
+Signature check Bad (error 1)
+
+
+Of course it would be possible to add an entirely new configuration and boot
+with that, but it still needs to be signed, so it won't help.
+
+
+6. Put the public key into U-Boot's image
+-----------------------------------------
+
+Having confirmed that the signature is doing its job, let's try it out in
+U-Boot on the board. U-Boot needs access to the public key corresponding to
+the private key that you signed with so that it can verify any kernels that
+you sign.
+
+ cd $UBOOT
+ make O=b/am335x_boneblack_vboot EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb
+
+Here we are overriding the normal device tree file with our one, which
+contains the public key.
+
+Now you have a special U-Boot image with the public key. It can verify can
+kernel that you sign with the private key as in step 5.
+
+If you like you can take a look at the public key information that mkimage
+added to U-Boot's device tree:
+
+ fdtget -p am335x-boneblack-pubkey.dtb /signature/key-dev
+required
+algo
+rsa,r-squared
+rsa,modulus
+rsa,n0-inverse
+rsa,num-bits
+key-name-hint
+
+This has information about the key and some pre-processed values which U-Boot
+can use to verify against it. These values are obtained from the public key
+certificate by mkimage, but require quite a bit of code to generate. To save
+code space in U-Boot, the information is extracted and written in raw form for
+U-Boot to easily use. The same mechanism is used in Google's Chrome OS.
+
+Notice the 'required' property. This marks the key as required - U-Boot will
+not boot any image that does not verify against this key.
+
+
+7. Put U-Boot and the kernel onto the board
+-------------------------------------------
+
+The method here varies depending on how you are booting. For this example we
+are booting from an micro-SD card with two partitions, one for U-Boot and one
+for Linux. Put it into your machine and write U-Boot and the kernel to it.
+Here the card is /dev/sde:
+
+ cd $WORK
+ export UDEV=/dev/sde1 # Change thes two lines to the correct device
+ export KDEV=/dev/sde2
+ sudo mount $UDEV /mnt/tmp && sudo cp $UOUT/u-boot-dtb.img /mnt/tmp/u-boot.img && sleep 1 && sudo umount $UDEV
+ sudo mount $KDEV /mnt/tmp && sudo cp $WORK/image.fit /mnt/tmp/boot/image.fit && sleep 1 && sudo umount $KDEV
+
+
+8. Try it
+---------
+
+Boot the board using the commands below:
+
+ setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
+ ext2load mmc 0:2 82000000 /boot/image.fit
+ bootm 82000000
+
+You should then see something like this:
+
+U-Boot# setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
+U-Boot# ext2load mmc 0:2 82000000 /boot/image.fit
+7824930 bytes read in 589 ms (12.7 MiB/s)
+U-Boot# bootm 82000000
+## Loading kernel from FIT Image at 82000000 ...
+ Using 'conf-1' configuration
+ Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
+ Trying 'kernel' kernel subimage
+ Description: unavailable
+ Created: 2014-06-01 19:32:54 UTC
+ Type: Kernel Image
+ Compression: lzo compressed
+ Data Start: 0x820000a8
+ Data Size: 7790938 Bytes = 7.4 MiB
+ Architecture: ARM
+ OS: Linux
+ Load Address: 0x80008000
+ Entry Point: 0x80008000
+ Hash algo: sha1
+ Hash value: c94364646427e10f423837e559898ef02c97b988
+ Verifying Hash Integrity ... sha1+ OK
+## Loading fdt from FIT Image at 82000000 ...
+ Using 'conf-1' configuration
+ Trying 'fdt-1' fdt subimage
+ Description: beaglebone-black
+ Created: 2014-06-01 19:32:54 UTC
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x8276e2ec
+ Data Size: 31547 Bytes = 30.8 KiB
+ Architecture: ARM
+ Hash algo: sha1
+ Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d
+ Verifying Hash Integrity ... sha1+ OK
+ Booting using the fdt blob at 0x8276e2ec
+ Uncompressing Kernel Image ... OK
+ Loading Device Tree to 8fff5000, end 8ffffb3a ... OK
+
+Starting kernel ...
+
+[ 0.582377] omap_init_mbox: hwmod doesn't have valid attrs
+[ 2.589651] musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
+[ 2.595830] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
+[ 2.606470] musb-hdrc musb-hdrc.1.auto: Failed to request rx1.
+[ 2.612723] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
+[ 2.940808] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+[ 7.248889] libphy: PHY 4a101000.mdio:01 not found
+[ 7.253995] net eth0: phy 4a101000.mdio:01 not found on slave 1
+systemd-fsck[83]: Angstrom: clean, 50607/218160 files, 306348/872448 blocks
+
+.---O---.
+| | .-. o o
+| | |-----.-----.-----.| | .----..-----.-----.
+| | | __ | ---'| '--.| .-'| | |
+| | | | | |--- || --'| | | ' | | | |
+'---'---'--'--'--. |-----''----''--' '-----'-'-'-'
+ -' |
+ '---'
+
+The Angstrom Distribution beaglebone ttyO0
+
+Angstrom v2012.12 - Kernel 3.14.1+
+
+beaglebone login:
+
+At this point your kernel has been verified and you can be sure that it is one
+that you signed. As an exercise, try changing image.fit as in step 5 and see
+what happens.
+
+
+Further Improvements
+--------------------
+
+Several of the steps here can be easily automated. In particular it would be
+capital if signing and packaging a kernel were easy, perhaps a simple make
+target in the kernel.
+
+Some mention of how to use multiple .dtb files in a FIT might be useful.
+
+U-Boot's verified boot mechanism has not had a robust and independent security
+review. Such a review should look at the implementation and its resistance to
+attacks.
+
+Perhaps the verified boot feature could could be integrated into the Amstrom
+distribution.
+
+
+Simon Glass
+sjg@chromium.org
+2-June-14
diff --git a/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt b/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
new file mode 100644
index 000000000..6a99089ab
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
@@ -0,0 +1,201 @@
+Command syntax extensions for the new uImage format
+===================================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+With the introduction of the new uImage format, bootm command (and other
+commands as well) have to understand new syntax of the arguments. This is
+necessary in order to specify objects contained in the new uImage, on which
+bootm has to operate. This note attempts to first summarize bootm usage
+scenarios, and then introduces new argument syntax.
+
+
+bootm usage scenarios
+---------------------
+
+Below is a summary of bootm usage scenarios, focused on booting a PowerPC
+Linux kernel. The purpose of the following list is to document a complete list
+of supported bootm usages.
+
+Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
+i.e., without passing the Flattened Device Tree (FDT), and new way, where the
+kernel is passed a pointer to the FDT. The boot method is indicated for each
+scenario.
+
+
+1. bootm boot image at the current address, equivalent to 2,3,8
+
+Old uImage:
+2. bootm <addr1> /* single image at <addr1> */
+3. bootm <addr1> /* multi-image at <addr1> */
+4. bootm <addr1> - /* multi-image at <addr1> */
+5. bootm <addr1> <addr2> /* single image at <addr1> */
+6. bootm <addr1> <addr2> <addr3> /* single image at <addr1> */
+7. bootm <addr1> - <addr3> /* single image at <addr1> */
+
+New uImage:
+8. bootm <addr1>
+9. bootm [<addr1>]:<subimg1>
+10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
+11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
+12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
+13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
+14. bootm [<addr1>]:<subimg1> - [<addr3>]:<subimg3>
+15. bootm [<addr1>]:<subimg1> - <addr3>
+
+
+Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
+the current image address.
+- boot method: see cases 2,3,8
+
+Ad. 2. Boot kernel image located at <addr1>.
+- boot method: non-FDT
+
+Ad. 3. First and second components of the image at <addr1> are assumed to be a
+kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
+with the ramdisk from the image.
+- boot method: depends on the number of components at <addr1>, and on whether
+ U-Boot is compiled with OF support:
+
+ | 2 components | 3 components |
+ | (kernel, initrd) | (kernel, initrd, fdt) |
+---------------------------------------------------------------------
+#ifdef CONFIG_OF_* | non-FDT | FDT |
+#ifndef CONFIG_OF_* | non-FDT | non-FDT |
+
+Ad. 4. Similar to case 3, but the kernel is booted without initrd. Second
+component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
+- boot method: see case 3
+
+Ad. 5. Boot kernel image located at <addr1> with initrd loaded with ramdisk
+from the image at <addr2>.
+- boot method: non-FDT
+
+Ad. 6. <addr1> is the address of a kernel image, <addr2> is the address of a
+ramdisk image, and <addr3> is the address of a FDT binary blob. Kernel is
+booted with initrd loaded with ramdisk from the image at <addr2>.
+- boot method: FDT
+
+Ad. 7. <addr1> is the address of a kernel image and <addr3> is the address of
+a FDT binary blob. Kernel is booted without initrd.
+- boot method: FDT
+
+Ad. 8. Image at <addr1> is assumed to contain a default configuration, which
+is booted.
+- boot method: FDT or non-FDT, depending on whether the default configuration
+ defines FDT
+
+Ad. 9. Similar to case 2: boot kernel stored in <subimg1> from the image at
+address <addr1>.
+- boot method: non-FDT
+
+Ad. 10. Boot configuration <conf> from the image at <addr1>.
+- boot method: FDT or non-FDT, depending on whether the configuration given
+ defines FDT
+
+Ad. 11. Equivalent to case 5: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>.
+- boot method: non-FDT
+
+Ad. 12. Equivalent to case 6: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
+- boot method: FDT
+
+Ad. 13. Similar to case 12, the difference being that <addr3> is the address
+of FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+Ad. 14. Equivalent to case 7: boot kernel stored in <subimg1> from the image
+at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
+<addr3>.
+- boot method: FDT
+
+Ad. 15. Similar to case 14, the difference being that <addr3> is the address
+of the FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+
+New uImage argument syntax
+--------------------------
+
+New uImage support introduces two new forms for bootm arguments, with the
+following syntax:
+
+- new uImage sub-image specification
+<addr>:<sub-image unit_name>
+
+- new uImage configuration specification
+<addr>#<configuration unit_name>
+
+- new uImage configuration specification with extra configuration components
+<addr>#<configuration unit_name>[#<extra configuration unit_name>[#..]]
+
+The extra configuration currently is supported only for additional device tree
+overlays to apply on the base device tree supplied by the first configuration
+unit.
+
+Examples:
+
+- boot kernel "kernel-1" stored in a new uImage located at 200000:
+bootm 200000:kernel-1
+
+- boot configuration "cfg-1" from a new uImage located at 200000:
+bootm 200000#cfg-1
+
+- boot configuration "cfg-1" with extra "cfg-2" from a new uImage located
+ at 200000:
+bootm 200000#cfg-1#cfg-2
+
+- boot "kernel-1" from a new uImage at 200000 with initrd "ramdisk-2" found in
+ some other new uImage stored at address 800000:
+bootm 200000:kernel-1 800000:ramdisk-2
+
+- boot "kernel-2" from a new uImage at 200000, with initrd "ramdisk-1" and FDT
+ "fdt-1", both stored in some other new uImage located at 800000:
+bootm 200000:kernel-1 800000:ramdisk-1 800000:fdt-1
+
+- boot kernel "kernel-2" with initrd "ramdisk-2", both stored in a new uImage
+ at address 200000, with a raw FDT blob stored at address 600000:
+bootm 200000:kernel-2 200000:ramdisk-2 600000
+
+- boot kernel "kernel-2" from new uImage at 200000 with FDT "fdt-1" from the
+ same new uImage:
+bootm 200000:kernel-2 - 200000:fdt-1
+
+
+Note on current image address
+-----------------------------
+
+When bootm is called without arguments, the image at current image address is
+booted. The current image address is the address set most recently by a load
+command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example, consider
+the following commands:
+
+tftp 200000 /tftpboot/kernel
+bootm
+Last command is equivalent to:
+bootm 200000
+
+In case of the new uImage argument syntax, the address portion of any argument
+can be omitted. If <addr3> is omitted, then it is assumed that image at
+<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
+image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
+current image address is to be used. For example, consider the following
+commands:
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel-1
+Last command is equivalent to:
+bootm 200000:kernel-1
+
+tftp 200000 /tftpboot/uImage
+bootm 400000:kernel-1 :ramdisk-1
+Last command is equivalent to:
+bootm 400000:kernel-1 400000:ramdisk-1
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel-1 400000:ramdisk-1 :fdt-1
+Last command is equivalent to:
+bootm 200000:kernel-1 400000:ramdisk-1 400000:fdt-1
diff --git a/roms/u-boot/doc/uImage.FIT/howto.txt b/roms/u-boot/doc/uImage.FIT/howto.txt
new file mode 100644
index 000000000..019dda24a
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/howto.txt
@@ -0,0 +1,405 @@
+How to use images in the new image format
+=========================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+
+Overview
+--------
+
+The new uImage format allows more flexibility in handling images of various
+types (kernel, ramdisk, etc.), it also enhances integrity protection of images
+with sha1 and md5 checksums.
+
+Two auxiliary tools are needed on the development host system in order to
+create an uImage in the new format: mkimage and dtc, although only one
+(mkimage) is invoked directly. dtc is called from within mkimage and operates
+behind the scenes, but needs to be present in the $PATH nevertheless. It is
+important that the dtc used has support for binary includes -- refer to
+
+ git://git.kernel.org/pub/scm/utils/dtc/dtc.git
+
+for its latest version. mkimage (together with dtc) takes as input
+an image source file, which describes the contents of the image and defines
+its various properties used during booting. By convention, image source file
+has the ".its" extension, also, the details of its format are given in
+doc/uImage.FIT/source_file_format.txt. The actual data that is to be included in
+the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
+form of paths to appropriate data files. The outcome of the image creation
+process is a binary file (by convention with the ".itb" extension) that
+contains all the referenced data (kernel, ramdisk, etc.) and other information
+needed by U-Boot to handle the uImage properly. The uImage file is then
+transferred to the target (e.g., via tftp) and booted using the bootm command.
+
+To summarize the prerequisites needed for new uImage creation:
+- mkimage
+- dtc (with support for binary includes)
+- image source file (*.its)
+- image data file(s)
+
+
+Here's a graphical overview of the image creation and booting process:
+
+image source file mkimage + dtc transfer to target
+ + ---------------> image file --------------------> bootm
+image data file(s)
+
+SPL usage
+---------
+
+The SPL can make use of the new image format as well, this traditionally
+is used to ship multiple device tree files within one image. Code in the SPL
+will choose the one matching the current board and append this to the
+U-Boot proper binary to be automatically used up by it.
+Aside from U-Boot proper and one device tree blob the SPL can load multiple,
+arbitrary image files as well. These binaries should be specified in their
+own subnode under the /images node, which should then be referenced from one or
+multiple /configurations subnodes. The required images must be enumerated in
+the "loadables" property as a list of strings.
+
+If a platform specific image source file (.its) is shipped with the U-Boot
+source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol.
+In this case it will be automatically used by U-Boot's Makefile to generate
+the image.
+If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR
+can point to a script which generates this image source file during
+the build process. It gets passed a list of device tree files (taken from the
+CONFIG_OF_LIST symbol).
+
+The SPL also records to a DT all additional images (called loadables) which are
+loaded. The information about loadables locations is passed via the DT node with
+fit-images name.
+
+Loadables Example
+-----------------
+Consider the following case for an ARM64 platform where U-Boot runs in EL2
+started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
+
+/dts-v1/;
+
+/ {
+ description = "Configuration to load ATF before U-Boot";
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ data = /incbin/("u-boot-nodtb.bin");
+ type = "firmware";
+ os = "u-boot";
+ arch = "arm64";
+ compression = "none";
+ load = <0x8 0x8000000>;
+ entry = <0x8 0x8000000>;
+ hash {
+ algo = "md5";
+ };
+ };
+ atf {
+ description = "ARM Trusted Firmware";
+ data = /incbin/("bl31.bin");
+ type = "firmware";
+ os = "arm-trusted-firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0xfffea000>;
+ entry = <0xfffea000>;
+ hash {
+ algo = "md5";
+ };
+ };
+ fdt_1 {
+ description = "zynqmp-zcu102-revA";
+ data = /incbin/("arch/arm/dts/zynqmp-zcu102-revA.dtb");
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ load = <0x100000>;
+ hash {
+ algo = "md5";
+ };
+ };
+ };
+ configurations {
+ default = "config_1";
+
+ config_1 {
+ description = "zynqmp-zcu102-revA";
+ firmware = "atf";
+ loadables = "uboot";
+ fdt = "fdt_1";
+ };
+ };
+};
+
+In this case the SPL records via fit-images DT node the information about
+loadables U-Boot image.
+
+ZynqMP> fdt addr $fdtcontroladdr
+ZynqMP> fdt print /fit-images
+fit-images {
+ uboot {
+ os = "u-boot";
+ type = "firmware";
+ size = <0x001017c8>;
+ entry = <0x00000008 0x08000000>;
+ load = <0x00000008 0x08000000>;
+ };
+};
+
+As you can see entry and load properties are 64bit wide to support loading
+images above 4GB (in past entry and load properties where just 32bit).
+
+
+Example 1 -- old-style (non-FDT) kernel booting
+-----------------------------------------------
+
+Consider a simple scenario, where a PPC Linux kernel built from sources on the
+development host is to be booted old-style (non-FDT) by U-Boot on an embedded
+target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
+contains a gzip-compressed PPC Linux kernel (the only data file in this case).
+The uImage can be produced using the image source file
+doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
+in the current working directory; if desired, an alternative path can be
+specified in the kernel.its file). Here's how to create the image and inspect
+its contents:
+
+[on the host system]
+$ mkimage -f kernel.its kernel.itb
+DTC: dts->dtb on file "kernel.its"
+$
+$ mkimage -l kernel.itb
+FIT description: Simple image with single Linux kernel
+Created: Tue Mar 11 17:26:15 2008
+ Image 0 (kernel)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Size: 943347 Bytes = 921.24 kB = 0.90 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Default Configuration: 'config-1'
+ Configuration 0 (config-1)
+ Description: Boot Linux kernel
+ Kernel: kernel
+
+
+The resulting image file kernel.itb can be now transferred to the target,
+inspected and booted (note that first three U-Boot commands below are shown
+for completeness -- they are part of the standard booting procedure and not
+specific to the new image format).
+
+[on the target system]
+=> print nfsargs
+nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
+=> print addip
+addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
+=> run nfsargs addip
+=> tftp 900000 /path/to/tftp/location/kernel.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel.itb'.
+Load address: 0x900000
+Loading: #################################################################
+done
+Bytes transferred = 944464 (e6950 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+ FIT image found
+ FIT description: Simple image with single Linux kernel
+ Created: 2008-03-11 16:26:15 UTC
+ Image 0 (kernel)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000e0
+ Data Size: 943347 Bytes = 921.2 kB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Default Configuration: 'config-1'
+ Configuration 0 (config-1)
+ Description: Boot Linux kernel
+ Kernel: kernel
+
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+ Using 'config-1' configuration
+ Trying 'kernel' kernel subimage
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000e0
+ Data Size: 943347 Bytes = 921.2 kB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2ae2bb40
+ Hash algo: sha1
+ Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Uncompressing Kernel Image ... OK
+Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
+Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
+On node 0 totalpages: 65536
+zone(0): 65536 pages.
+zone(1): 0 pages.
+zone(2): 0 pages.
+Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
+Calibrating delay loop... 307.20 BogoMIPS
+
+
+Example 2 -- new-style (FDT) kernel booting
+-------------------------------------------
+
+Consider another simple scenario, where a PPC Linux kernel is to be booted
+new-style, i.e., with a FDT blob. In this case there are two prerequisite data
+files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
+be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
+(note again, that both prerequisite data files are assumed to be present in
+the current working directory -- image source file kernel_fdt.its can be
+modified to take the files from some other location if needed):
+
+[on the host system]
+$ mkimage -f kernel_fdt.its kernel_fdt.itb
+DTC: dts->dtb on file "kernel_fdt.its"
+$
+$ mkimage -l kernel_fdt.itb
+FIT description: Simple image with single Linux kernel and FDT blob
+Created: Tue Mar 11 16:29:22 2008
+ Image 0 (kernel)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Size: 1092037 Bytes = 1066.44 kB = 1.04 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Image 1 (fdt-1)
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Size: 16384 Bytes = 16.00 kB = 0.02 MB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Default Configuration: 'conf-1'
+ Configuration 0 (conf-1)
+ Description: Boot Linux kernel with FDT blob
+ Kernel: kernel
+ FDT: fdt-1
+
+
+The resulting image file kernel_fdt.itb can be now transferred to the target,
+inspected and booted:
+
+[on the target system]
+=> tftp 900000 /path/to/tftp/location/kernel_fdt.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel_fdt.itb'.
+Load address: 0x900000
+Loading: #################################################################
+ ###########
+done
+Bytes transferred = 1109776 (10ef10 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+ FIT image found
+ FIT description: Simple image with single Linux kernel and FDT blob
+ Created: 2008-03-11 15:29:22 UTC
+ Image 0 (kernel)
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000ec
+ Data Size: 1092037 Bytes = 1 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Image 1 (fdt-1)
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x00a0abdc
+ Data Size: 16384 Bytes = 16 kB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Default Configuration: 'conf-1'
+ Configuration 0 (conf-1)
+ Description: Boot Linux kernel with FDT blob
+ Kernel: kernel
+ FDT: fdt-1
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+ Using 'conf-1' configuration
+ Trying 'kernel' kernel subimage
+ Description: Vanilla Linux kernel
+ Type: Kernel Image
+ Compression: gzip compressed
+ Data Start: 0x009000ec
+ Data Size: 1092037 Bytes = 1 MB
+ Architecture: PowerPC
+ OS: Linux
+ Load Address: 0x00000000
+ Entry Point: 0x00000000
+ Hash algo: crc32
+ Hash value: 2c0cc807
+ Hash algo: sha1
+ Hash value: 264b59935470e42c418744f83935d44cdf59a3bb
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Uncompressing Kernel Image ... OK
+## Flattened Device Tree from FIT Image at 00900000
+ Using 'conf-1' configuration
+ Trying 'fdt-1' FDT blob subimage
+ Description: Flattened Device Tree blob
+ Type: Flat Device Tree
+ Compression: uncompressed
+ Data Start: 0x00a0abdc
+ Data Size: 16384 Bytes = 16 kB
+ Architecture: PowerPC
+ Hash algo: crc32
+ Hash value: 0d655d71
+ Hash algo: sha1
+ Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def
+ Verifying Hash Integrity ... crc32+ sha1+ OK
+ Booting using the fdt blob at 0xa0abdc
+ Loading Device Tree to 007fc000, end 007fffff ... OK
+[ 0.000000] Using lite5200 machine description
+[ 0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
+
+
+Example 3 -- advanced booting
+-----------------------------
+
+Refer to doc/uImage.FIT/multi.its for an image source file that allows more
+sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).
diff --git a/roms/u-boot/doc/uImage.FIT/kernel.its b/roms/u-boot/doc/uImage.FIT/kernel.its
new file mode 100644
index 000000000..77ddf622d
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/kernel.its
@@ -0,0 +1,91 @@
+/*
+ * Simple U-Boot uImage source file containing a single kernel
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Simple image with single Linux kernel";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "Boot Linux kernel";
+ kernel = "kernel";
+ };
+ };
+};
+
+
+
+For x86 a setup node is also required: see x86-fit-boot.txt.
+
+/dts-v1/;
+
+/ {
+ description = "Simple image with single Linux kernel on x86";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./image.bin.lzo");
+ type = "kernel";
+ arch = "x86";
+ os = "linux";
+ compression = "lzo";
+ load = <0x01000000>;
+ entry = <0x00000000>;
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+
+ setup {
+ description = "Linux setup.bin";
+ data = /incbin/("./setup.bin");
+ type = "x86_setup";
+ arch = "x86";
+ os = "linux";
+ compression = "none";
+ load = <0x00090000>;
+ entry = <0x00090000>;
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "Boot Linux kernel";
+ kernel = "kernel";
+ setup = "setup";
+ };
+ };
+};
+
+Note: the above assumes a 32-bit kernel. To directly boot a 64-bit kernel,
+change both arch values to "x86_64". U-Boot will then change to 64-bit mode
+before booting the kernel (see boot_linux_kernel()).
diff --git a/roms/u-boot/doc/uImage.FIT/kernel_fdt.its b/roms/u-boot/doc/uImage.FIT/kernel_fdt.its
new file mode 100644
index 000000000..000d85b8e
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/kernel_fdt.its
@@ -0,0 +1,51 @@
+/*
+ * Simple U-Boot uImage source file containing a single kernel and FDT blob
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Simple image with single Linux kernel and FDT blob";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ fdt-1 {
+ description = "Flattened Device Tree blob";
+ data = /incbin/("./target.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ description = "Boot Linux kernel with FDT blob";
+ kernel = "kernel";
+ fdt = "fdt-1";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/kernel_fdts_compressed.its b/roms/u-boot/doc/uImage.FIT/kernel_fdts_compressed.its
new file mode 100644
index 000000000..8f81106ef
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/kernel_fdts_compressed.its
@@ -0,0 +1,73 @@
+/*
+ * U-Boot uImage source file with a kernel and multiple compressed FDT blobs.
+ * Since the FDTs are compressed, configurations must provide a compatible
+ * string to match directly.
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Image with single Linux kernel and compressed FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ description = "Vanilla Linux kernel";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ fdt@1 {
+ description = "Flattened Device Tree blob 1";
+ data = /incbin/("./myboard-var1.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "gzip";
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ fdt@2 {
+ description = "Flattened Device Tree blob 2";
+ data = /incbin/("./myboard-var2.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "lzma";
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf@1";
+ conf@1 {
+ description = "Boot Linux kernel with FDT blob 1";
+ kernel = "kernel";
+ fdt = "fdt@1";
+ compatible = "myvendor,myboard-variant1";
+ };
+ conf@2 {
+ description = "Boot Linux kernel with FDT blob 2";
+ kernel = "kernel";
+ fdt = "fdt@2";
+ compatible = "myvendor,myboard-variant2";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/multi-with-fpga.its b/roms/u-boot/doc/uImage.FIT/multi-with-fpga.its
new file mode 100644
index 000000000..021cbc7cf
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/multi-with-fpga.its
@@ -0,0 +1,68 @@
+/*
+ * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ * This example makes use of the 'loadables' field
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Configuration to load fpga before Kernel";
+ #address-cells = <1>;
+
+ images {
+ fdt-1 {
+ description = "zc706";
+ data = /incbin/("/tftpboot/devicetree.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ load = <0x10000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ fpga {
+ description = "FPGA";
+ data = /incbin/("/tftpboot/download.bit");
+ type = "fpga";
+ arch = "arm";
+ compression = "none";
+ load = <0x30000000>;
+ compatible = "u-boot,fpga-legacy"
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ linux_kernel {
+ description = "Linux";
+ data = /incbin/("/tftpboot/zImage");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ compression = "none";
+ load = <0x8000>;
+ entry = <0x8000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-2";
+ config-1 {
+ description = "Linux";
+ kernel = "linux_kernel";
+ fdt = "fdt-1";
+ };
+
+ config-2 {
+ description = "Linux with fpga";
+ kernel = "linux_kernel";
+ fdt = "fdt-1";
+ loadables = "fpga";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/multi-with-loadables.its b/roms/u-boot/doc/uImage.FIT/multi-with-loadables.its
new file mode 100644
index 000000000..4d4909f83
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/multi-with-loadables.its
@@ -0,0 +1,89 @@
+/*
+ * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ * This example makes use of the 'loadables' field
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Configuration to load a Xen Kernel";
+ #address-cells = <1>;
+
+ images {
+ xen_kernel {
+ description = "xen binary";
+ data = /incbin/("./xen");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ compression = "none";
+ load = <0xa0000000>;
+ entry = <0xa0000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ fdt-1 {
+ description = "xexpress-ca15 tree blob";
+ data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ load = <0xb0000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ fdt-2 {
+ description = "xexpress-ca15 tree blob";
+ data = /incbin/("./vexpress-v2p-ca15-tc1.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ load = <0xb0400000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ linux_kernel {
+ description = "Linux Image";
+ data = /incbin/("./Image");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ compression = "none";
+ load = <0xa0000000>;
+ entry = <0xa0000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-2";
+
+ config-1 {
+ description = "Just plain Linux";
+ kernel = "linux_kernel";
+ fdt = "fdt-1";
+ };
+
+ config-2 {
+ description = "Xen one loadable";
+ kernel = "xen_kernel";
+ fdt = "fdt-1";
+ loadables = "linux_kernel";
+ };
+
+ config-3 {
+ description = "Xen two loadables";
+ kernel = "xen_kernel";
+ fdt = "fdt-1";
+ loadables = "linux_kernel", "fdt-2";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/multi.its b/roms/u-boot/doc/uImage.FIT/multi.its
new file mode 100644
index 000000000..26c8dad6a
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/multi.its
@@ -0,0 +1,133 @@
+/*
+ * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Various kernels, ramdisks and FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel-1 {
+ description = "vanilla-2.6.23";
+ data = /incbin/("./vmlinux.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+ };
+
+ kernel-2 {
+ description = "2.6.23-denx";
+ data = /incbin/("./2.6.23-denx.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+
+ kernel-3 {
+ description = "2.4.25-denx";
+ data = /incbin/("./2.4.25-denx.bin.gz");
+ type = "kernel";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "md5";
+ };
+ };
+
+ ramdisk-1 {
+ description = "eldk-4.2-ramdisk";
+ data = /incbin/("./eldk-4.2-ramdisk");
+ type = "ramdisk";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+
+ ramdisk-2 {
+ description = "eldk-3.1-ramdisk";
+ data = /incbin/("./eldk-3.1-ramdisk");
+ type = "ramdisk";
+ arch = "ppc";
+ os = "linux";
+ compression = "gzip";
+ load = <00000000>;
+ entry = <00000000>;
+ hash-1 {
+ algo = "crc32";
+ };
+ };
+
+ fdt-1 {
+ description = "tqm5200-fdt";
+ data = /incbin/("./tqm5200.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ hash-1 {
+ algo = "crc32";
+ };
+ };
+
+ fdt-2 {
+ description = "tqm5200s-fdt";
+ data = /incbin/("./tqm5200s.dtb");
+ type = "flat_dt";
+ arch = "ppc";
+ compression = "none";
+ load = <00700000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+
+ };
+
+ configurations {
+ default = "config-1";
+
+ config-1 {
+ description = "tqm5200 vanilla-2.6.23 configuration";
+ kernel = "kernel-1";
+ ramdisk = "ramdisk-1";
+ fdt = "fdt-1";
+ };
+
+ config-2 {
+ description = "tqm5200s denx-2.6.23 configuration";
+ kernel = "kernel-2";
+ ramdisk = "ramdisk-1";
+ fdt = "fdt-2";
+ };
+
+ config-3 {
+ description = "tqm5200s denx-2.4.25 configuration";
+ kernel = "kernel-3";
+ ramdisk = "ramdisk-2";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/multi_spl.its b/roms/u-boot/doc/uImage.FIT/multi_spl.its
new file mode 100644
index 000000000..594219974
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/multi_spl.its
@@ -0,0 +1,96 @@
+/dts-v1/;
+
+/*
+ * (Bogus) example FIT image description file demonstrating the usage
+ * of multiple images loaded by the SPL.
+ * Several binaries will be loaded at their respective load addresses.
+ *
+ * For booting U-Boot, "firmware" is searched first. If not found, "loadables"
+ * is used to identify images to be loaded into memory. If falcon boot is
+ * enabled, "kernel" is searched first. If not found, it falls back to the
+ * same flow as booting U-Boot. Changing image type will result skipping
+ * specific image.
+ *
+ * Finally the one image specifying an entry point will be entered by the SPL.
+ */
+
+/ {
+ description = "multiple firmware blobs and U-Boot, loaded by SPL";
+ #address-cells = <0x1>;
+
+ images {
+
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = <0x4a000000>;
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x18000>;
+ entry = <0x18000>;
+ };
+
+ mgmt-firmware {
+ description = "arisc management processor firmware";
+ type = "firmware";
+ arch = "or1k";
+ compression = "none";
+ load = <0x40000>;
+ };
+
+ fdt-1 {
+ description = "Pine64+ DT";
+ type = "flat_dt";
+ compression = "none";
+ load = <0x4fa00000>;
+ arch = "arm64";
+ };
+
+ fdt-2 {
+ description = "Pine64 DT";
+ type = "flat_dt";
+ compression = "none";
+ load = <0x4fa00000>;
+ arch = "arm64";
+ };
+
+ kernel {
+ description = "4.7-rc5 kernel";
+ type = "kernel";
+ compression = "none";
+ load = <0x40080000>;
+ arch = "arm64";
+ };
+
+ initrd {
+ description = "Debian installer initrd";
+ type = "ramdisk";
+ compression = "none";
+ load = <0x4fe00000>;
+ arch = "arm64";
+ };
+ };
+
+ configurations {
+ default = "config-1";
+
+ config-1 {
+ description = "sun50i-a64-pine64-plus";
+ loadables = "uboot", "atf", "kernel", "initrd";
+ fdt = "fdt-1";
+ };
+
+ config-2 {
+ description = "sun50i-a64-pine64";
+ loadables = "uboot", "atf", "mgmt-firmware";
+ fdt = "fdt-2";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/overlay-fdt-boot.txt b/roms/u-boot/doc/uImage.FIT/overlay-fdt-boot.txt
new file mode 100644
index 000000000..dddc4db1a
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/overlay-fdt-boot.txt
@@ -0,0 +1,225 @@
+U-Boot FDT Overlay FIT usage
+============================
+
+Introduction
+------------
+In many cases it is desirable to have a single FIT image support a multitude
+of similar boards and their expansion options. The same kernel on DT enabled
+platforms can support this easily enough by providing a DT blob upon boot
+that matches the desired configuration.
+
+This document focuses on specifically using overlays as part of a FIT image.
+General information regarding overlays including its syntax and building it
+can be found in doc/README.fdt-overlays
+
+Configuration without overlays
+------------------------------
+
+Take a hypothetical board named 'foo' where there are different supported
+revisions, reva and revb. Assume that both board revisions can use add a bar
+add-on board, while only the revb board can use a baz add-on board.
+
+Without using overlays the configuration would be as follows for every case.
+
+ /dts-v1/;
+ / {
+ images {
+ kernel {
+ data = /incbin/("./zImage");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ load = <0x82000000>;
+ entry = <0x82000000>;
+ };
+ fdt-1 {
+ data = /incbin/("./foo-reva.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ fdt-2 {
+ data = /incbin/("./foo-revb.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ fdt-3 {
+ data = /incbin/("./foo-reva-bar.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ fdt-4 {
+ data = /incbin/("./foo-revb-bar.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ fdt-5 {
+ data = /incbin/("./foo-revb-baz.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ fdt-6 {
+ data = /incbin/("./foo-revb-bar-baz.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ };
+ };
+
+ configurations {
+ default = "foo-reva.dtb;
+ foo-reva.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1";
+ };
+ foo-revb.dtb {
+ kernel = "kernel";
+ fdt = "fdt-2";
+ };
+ foo-reva-bar.dtb {
+ kernel = "kernel";
+ fdt = "fdt-3";
+ };
+ foo-revb-bar.dtb {
+ kernel = "kernel";
+ fdt = "fdt-4";
+ };
+ foo-revb-baz.dtb {
+ kernel = "kernel";
+ fdt = "fdt-5";
+ };
+ foo-revb-bar-baz.dtb {
+ kernel = "kernel";
+ fdt = "fdt-6";
+ };
+ };
+ };
+
+Note the blob needs to be compiled for each case and the combinatorial explosion of
+configurations. A typical device tree blob is in the low hunderds of kbytes so a
+multitude of configuration grows the image quite a bit.
+
+Booting this image is done by using
+
+ # bootm <addr>#<config>
+
+Where config is one of:
+ foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
+ foo-revb-baz.dtb, foo-revb-bar-baz.dtb
+
+This selects the DTB to use when booting.
+
+Configuration using overlays
+----------------------------
+
+Device tree overlays can be applied to a base DT and result in the same blob
+being passed to the booting kernel. This saves on space and avoid the combinatorial
+explosion problem.
+
+ /dts-v1/;
+ / {
+ images {
+ kernel {
+ data = /incbin/("./zImage");
+ type = "kernel";
+ arch = "arm";
+ os = "linux";
+ load = <0x82000000>;
+ entry = <0x82000000>;
+ };
+ fdt-1 {
+ data = /incbin/("./foo.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ load = <0x87f00000>;
+ };
+ fdt-2 {
+ data = /incbin/("./reva.dtbo");
+ type = "flat_dt";
+ arch = "arm";
+ load = <0x87fc0000>;
+ };
+ fdt-3 {
+ data = /incbin/("./revb.dtbo");
+ type = "flat_dt";
+ arch = "arm";
+ load = <0x87fc0000>;
+ };
+ fdt-4 {
+ data = /incbin/("./bar.dtbo");
+ type = "flat_dt";
+ arch = "arm";
+ load = <0x87fc0000>;
+ };
+ fdt-5 {
+ data = /incbin/("./baz.dtbo");
+ type = "flat_dt";
+ arch = "arm";
+ load = <0x87fc0000>;
+ };
+ };
+
+ configurations {
+ default = "foo-reva.dtb;
+ foo-reva.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-2";
+ };
+ foo-revb.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-3";
+ };
+ foo-reva-bar.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-2", "fdt-4";
+ };
+ foo-revb-bar.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-3", "fdt-4";
+ };
+ foo-revb-baz.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-3", "fdt-5";
+ };
+ foo-revb-bar-baz.dtb {
+ kernel = "kernel";
+ fdt = "fdt-1", "fdt-3", "fdt-4", "fdt-5";
+ };
+ bar {
+ fdt = "fdt-4";
+ };
+ baz {
+ fdt = "fdt-5";
+ };
+ };
+ };
+
+Booting this image is exactly the same as the non-overlay example.
+u-boot will retrieve the base blob and apply the overlays in sequence as
+they are declared in the configuration.
+
+Note the minimum amount of different DT blobs, as well as the requirement for
+the DT blobs to have a load address; the overlay application requires the blobs
+to be writeable.
+
+Configuration using overlays and feature selection
+--------------------------------------------------
+
+Although the configuration in the previous section works is a bit inflexible
+since it requires all possible configuration options to be laid out before
+hand in the FIT image. For the add-on boards the extra config selection method
+might make sense.
+
+Note the two bar & baz configuration nodes. To boot a reva board with
+the bar add-on board enabled simply use:
+
+ # bootm <addr>#foo-reva.dtb#bar
+
+While booting a revb with bar and baz is as follows:
+
+ # bootm <addr>#foo-revb.dtb#bar#baz
+
+The limitation for a feature selection configuration node is that a single
+fdt option is currently supported.
+
+Pantelis Antoniou
+pantelis.antoniou@konsulko.com
+12/6/2017
diff --git a/roms/u-boot/doc/uImage.FIT/sec_firmware_ppa.its b/roms/u-boot/doc/uImage.FIT/sec_firmware_ppa.its
new file mode 100644
index 000000000..a7acde17c
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/sec_firmware_ppa.its
@@ -0,0 +1,49 @@
+/dts-v1/;
+
+/*
+ * Example FIT image description file demonstrating the usage
+ * of SEC Firmware and multiple loadable images loaded by the u-boot.
+ * For booting PPA (SEC Firmware), "firmware" is searched and loaded.
+ *
+ * Multiple binaries will be loaded as "loadables" (if present) at their
+ * respective load offsets from firmware image address.
+ */
+
+/{
+ description = "PPA Firmware";
+ #address-cells = <1>;
+ images {
+ firmware@1 {
+ description = "PPA Firmware: <version>";
+ data = /incbin/("../obj/monitor.bin");
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ };
+ trustedOS@1 {
+ description = "Trusted OS";
+ data = /incbin/("../../tee.bin");
+ type = "OS";
+ arch = "arm64";
+ compression = "none";
+ load = <0x00200000>;
+ };
+ fuse_scr {
+ description = "Fuse Script";
+ data = /incbin/("../../fuse_scr.bin");
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x00180000>;
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "PPA Secure firmware";
+ firmware = "firmware@1";
+ loadables = "trustedOS@1", "fuse_scr";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/sign-configs.its b/roms/u-boot/doc/uImage.FIT/sign-configs.its
new file mode 100644
index 000000000..9e992c198
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/sign-configs.its
@@ -0,0 +1,45 @@
+/dts-v1/;
+
+/ {
+ description = "Chrome OS kernel image with one or more FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ data = /incbin/("test-kernel.bin");
+ type = "kernel_noload";
+ arch = "sandbox";
+ os = "linux";
+ compression = "lzo";
+ load = <0x4>;
+ entry = <0x8>;
+ kernel-version = <1>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ fdt-1 {
+ description = "snow";
+ data = /incbin/("sandbox-kernel.dtb");
+ type = "flat_dt";
+ arch = "sandbox";
+ compression = "none";
+ fdt-version = <1>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel";
+ fdt = "fdt-1";
+ signature {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "fdt", "kernel";
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/sign-images.its b/roms/u-boot/doc/uImage.FIT/sign-images.its
new file mode 100644
index 000000000..18c759e9e
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/sign-images.its
@@ -0,0 +1,42 @@
+/dts-v1/;
+
+/ {
+ description = "Chrome OS kernel image with one or more FDT blobs";
+ #address-cells = <1>;
+
+ images {
+ kernel {
+ data = /incbin/("test-kernel.bin");
+ type = "kernel_noload";
+ arch = "sandbox";
+ os = "linux";
+ compression = "none";
+ load = <0x4>;
+ entry = <0x8>;
+ kernel-version = <1>;
+ signature {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ };
+ };
+ fdt-1 {
+ description = "snow";
+ data = /incbin/("sandbox-kernel.dtb");
+ type = "flat_dt";
+ arch = "sandbox";
+ compression = "none";
+ fdt-version = <1>;
+ signature {
+ algo = "sha1,rsa2048";
+ key-name-hint = "dev";
+ };
+ };
+ };
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel";
+ fdt = "fdt-1";
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/signature.txt b/roms/u-boot/doc/uImage.FIT/signature.txt
new file mode 100644
index 000000000..d9a912119
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/signature.txt
@@ -0,0 +1,682 @@
+U-Boot FIT Signature Verification
+=================================
+
+Introduction
+------------
+FIT supports hashing of images so that these hashes can be checked on
+loading. This protects against corruption of the image. However it does not
+prevent the substitution of one image for another.
+
+The signature feature allows the hash to be signed with a private key such
+that it can be verified using a public key later. Provided that the private
+key is kept secret and the public key is stored in a non-volatile place,
+any image can be verified in this way.
+
+See verified-boot.txt for more general information on verified boot.
+
+
+Concepts
+--------
+Some familiarity with public key cryptography is assumed in this section.
+
+The procedure for signing is as follows:
+
+ - hash an image in the FIT
+ - sign the hash with a private key to produce a signature
+ - store the resulting signature in the FIT
+
+The procedure for verification is:
+
+ - read the FIT
+ - obtain the public key
+ - extract the signature from the FIT
+ - hash the image from the FIT
+ - verify (with the public key) that the extracted signature matches the
+ hash
+
+The signing is generally performed by mkimage, as part of making a firmware
+image for the device. The verification is normally done in U-Boot on the
+device.
+
+
+Algorithms
+----------
+In principle any suitable algorithm can be used to sign and verify a hash.
+At present only one class of algorithms is supported: SHA1 hashing with RSA.
+This works by hashing the image to produce a 20-byte hash.
+
+While it is acceptable to bring in large cryptographic libraries such as
+openssl on the host side (e.g. mkimage), it is not desirable for U-Boot.
+For the run-time verification side, it is important to keep code and data
+size as small as possible.
+
+For this reason the RSA image verification uses pre-processed public keys
+which can be used with a very small amount of code - just some extraction
+of data from the FDT and exponentiation mod n. Code size impact is a little
+under 5KB on Tegra Seaboard, for example.
+
+It is relatively straightforward to add new algorithms if required. If
+another RSA variant is needed, then it can be added to the table in
+image-sig.c. If another algorithm is needed (such as DSA) then it can be
+placed alongside rsa.c, and its functions added to the table in image-sig.c
+also.
+
+
+Creating an RSA key pair and certificate
+----------------------------------------
+To create a new public/private key pair, size 2048 bits:
+
+$ openssl genpkey -algorithm RSA -out keys/dev.key \
+ -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
+
+To create a certificate for this containing the public key:
+
+$ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
+
+If you like you can look at the public key also:
+
+$ openssl rsa -in keys/dev.key -pubout
+
+
+Device Tree Bindings
+--------------------
+The following properties are required in the FIT's signature node(s) to
+allow the signer to operate. These should be added to the .its file.
+Signature nodes sit at the same level as hash nodes and are called
+signature-1, signature-2, etc.
+
+- algo: Algorithm name (e.g. "sha1,rsa2048")
+
+- key-name-hint: Name of key to use for signing. The keys will normally be in
+a single directory (parameter -k to mkimage). For a given key <name>, its
+private key is stored in <name>.key and the certificate is stored in
+<name>.crt.
+
+When the image is signed, the following properties are added (mandatory):
+
+- value: The signature data (e.g. 256 bytes for 2048-bit RSA)
+
+When the image is signed, the following properties are optional:
+
+- timestamp: Time when image was signed (standard Unix time_t format)
+
+- signer-name: Name of the signer (e.g. "mkimage")
+
+- signer-version: Version string of the signer (e.g. "2013.01")
+
+- comment: Additional information about the signer or image
+
+- padding: The padding algorithm, it may be pkcs-1.5 or pss,
+ if no value is provided we assume pkcs-1.5
+
+For config bindings (see Signed Configurations below), the following
+additional properties are optional:
+
+- sign-images: A list of images to sign, each being a property of the conf
+node that contains then. The default is "kernel,fdt" which means that these
+two images will be looked up in the config and signed if present.
+
+For config bindings, these properties are added by the signer:
+
+- hashed-nodes: A list of nodes which were hashed by the signer. Each is
+ a string - the full path to node. A typical value might be:
+
+ hashed-nodes = "/", "/configurations/conf-1", "/images/kernel",
+ "/images/kernel/hash-1", "/images/fdt-1",
+ "/images/fdt-1/hash-1";
+
+- hashed-strings: The start and size of the string region of the FIT that
+ was hashed
+
+Example: See sign-images.its for an example image tree source file and
+sign-configs.its for config signing.
+
+
+Public Key Storage
+------------------
+In order to verify an image that has been signed with a public key we need to
+have a trusted public key. This cannot be stored in the signed image, since
+it would be easy to alter. For this implementation we choose to store the
+public key in U-Boot's control FDT (using CONFIG_OF_CONTROL).
+
+Public keys should be stored as sub-nodes in a /signature node. Required
+properties are:
+
+- algo: Algorithm name (e.g. "sha1,rsa2048" or "sha256,ecdsa256")
+
+Optional properties are:
+
+- key-name-hint: Name of key used for signing. This is only a hint since it
+is possible for the name to be changed. Verification can proceed by checking
+all available signing keys until one matches.
+
+- required: If present this indicates that the key must be verified for the
+image / configuration to be considered valid. Only required keys are
+normally verified by the FIT image booting algorithm. Valid values are
+"image" to force verification of all images, and "conf" to force verification
+of the selected configuration (which then relies on hashes in the images to
+verify those).
+
+Each signing algorithm has its own additional properties.
+
+For RSA the following are mandatory:
+
+- rsa,num-bits: Number of key bits (e.g. 2048)
+- rsa,modulus: Modulus (N) as a big-endian multi-word integer
+- rsa,exponent: Public exponent (E) as a 64 bit unsigned integer
+- rsa,r-squared: (2^num-bits)^2 as a big-endian multi-word integer
+- rsa,n0-inverse: -1 / modulus[0] mod 2^32
+
+For ECDSA the following are mandatory:
+- ecdsa,curve: Name of ECDSA curve (e.g. "prime256v1")
+- ecdsa,x-point: Public key X coordinate as a big-endian multi-word integer
+- ecdsa,y-point: Public key Y coordinate as a big-endian multi-word integer
+
+These parameters can be added to a binary device tree using parameter -K of the
+mkimage command::
+
+ tools/mkimage -f fit.its -K control.dtb -k keys -r image.fit
+
+Here is an example of a generated device tree node::
+
+ signature {
+ key-dev {
+ required = "conf";
+ algo = "sha256,rsa2048";
+ rsa,r-squared = <0xb76d1acf 0xa1763ca5 0xeb2f126
+ 0x742edc80 0xd3f42177 0x9741d9d9
+ 0x35bb476e 0xff41c718 0xd3801430
+ 0xf22537cb 0xa7e79960 0xae32a043
+ 0x7da1427a 0x341d6492 0x3c2762f5
+ 0xaac04726 0x5b262d96 0xf984e86d
+ 0xb99443c7 0x17080c33 0x940f6892
+ 0xd57a95d1 0x6ea7b691 0xc5038fa8
+ 0x6bb48a6e 0x73f1b1ea 0x37160841
+ 0xe05715ce 0xa7c45bbd 0x690d82d5
+ 0x99c2454c 0x6ff117b3 0xd830683b
+ 0x3f81c9cf 0x1ca38a91 0x0c3392e4
+ 0xd817c625 0x7b8e9a24 0x175b89ea
+ 0xad79f3dc 0x4d50d7b4 0x9d4e90f8
+ 0xad9e2939 0xc165d6a4 0x0ada7e1b
+ 0xfb1bf495 0xfc3131c2 0xb8c6e604
+ 0xc2761124 0xf63de4a6 0x0e9565f9
+ 0xc8e53761 0x7e7a37a5 0xe99dcdae
+ 0x9aff7e1e 0xbd44b13d 0x6b0e6aa4
+ 0x038907e4 0x8e0d6850 0xef51bc20
+ 0xf73c94af 0x88bea7b1 0xcbbb1b30
+ 0xd024b7f3>;
+ rsa,modulus = <0xc0711d6cb 0x9e86db7f 0x45986dbe
+ 0x023f1e8c9 0xe1a4c4d0 0x8a0dfdc9
+ 0x023ba0c48 0x06815f6a 0x5caa0654
+ 0x07078c4b7 0x3d154853 0x40729023
+ 0x0b007c8fe 0x5a3647e5 0x23b41e20
+ 0x024720591 0x66915305 0x0e0b29b0
+ 0x0de2ad30d 0x8589430f 0xb1590325
+ 0x0fb9f5d5e 0x9eba752a 0xd88e6de9
+ 0x056b3dcc6 0x9a6b8e61 0x6784f61f
+ 0x000f39c21 0x5eec6b33 0xd78e4f78
+ 0x0921a305f 0xaa2cc27e 0x1ca917af
+ 0x06e1134f4 0xd48cac77 0x4e914d07
+ 0x0f707aa5a 0x0d141f41 0x84677f1d
+ 0x0ad47a049 0x028aedb6 0xd5536fcf
+ 0x03fef1e4f 0x133a03d2 0xfd7a750a
+ 0x0f9159732 0xd207812e 0x6a807375
+ 0x06434230d 0xc8e22dad 0x9f29b3d6
+ 0x07c44ac2b 0xfa2aad88 0xe2429504
+ 0x041febd41 0x85d0d142 0x7b194d65
+ 0x06e5d55ea 0x41116961 0xf3181dde
+ 0x068bf5fbc 0x3dd82047 0x00ee647e
+ 0x0d7a44ab3>;
+ rsa,exponent = <0x00 0x10001>;
+ rsa,n0-inverse = <0xb3928b85>;
+ rsa,num-bits = <0x800>;
+ key-name-hint = "dev";
+ };
+ };
+
+
+Signed 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).
+
+As an example, consider this FIT:
+
+/ {
+ images {
+ kernel-1 {
+ data = <data for kernel1>
+ signature-1 {
+ algo = "sha1,rsa2048";
+ value = <...kernel signature 1...>
+ };
+ };
+ kernel-2 {
+ data = <data for kernel2>
+ signature-1 {
+ algo = "sha1,rsa2048";
+ value = <...kernel signature 2...>
+ };
+ };
+ fdt-1 {
+ data = <data for fdt1>;
+ signature-1 {
+ algo = "sha1,rsa2048";
+ vaue = <...fdt signature 1...>
+ };
+ };
+ fdt-2 {
+ data = <data for fdt2>;
+ signature-1 {
+ algo = "sha1,rsa2048";
+ vaue = <...fdt signature 2...>
+ };
+ };
+ };
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
+ };
+ conf-2 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
+ };
+ };
+};
+
+Since both kernels are signed it is easy for an attacker to add a new
+configuration 3 with kernel 1 and fdt 2:
+
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
+ };
+ conf-2 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
+ };
+ conf-3 {
+ kernel = "kernel-1";
+ fdt = "fdt-2";
+ };
+ };
+
+With signed images, nothing protects against this. Whether it gains an
+advantage for the attacker is debatable, but it is not secure.
+
+To solve this problem, we support signed configurations. In this case it
+is the configurations that are signed, not the image. Each image has its
+own hash, and we include the hash in the configuration signature.
+
+So the above example is adjusted to look like this:
+
+/ {
+ images {
+ kernel-1 {
+ data = <data for kernel1>
+ hash-1 {
+ algo = "sha1";
+ value = <...kernel hash 1...>
+ };
+ };
+ kernel-2 {
+ data = <data for kernel2>
+ hash-1 {
+ algo = "sha1";
+ value = <...kernel hash 2...>
+ };
+ };
+ fdt-1 {
+ data = <data for fdt1>;
+ hash-1 {
+ algo = "sha1";
+ value = <...fdt hash 1...>
+ };
+ };
+ fdt-2 {
+ data = <data for fdt2>;
+ hash-1 {
+ algo = "sha1";
+ value = <...fdt hash 2...>
+ };
+ };
+ };
+ configurations {
+ default = "conf-1";
+ conf-1 {
+ kernel = "kernel-1";
+ fdt = "fdt-1";
+ signature-1 {
+ algo = "sha1,rsa2048";
+ value = <...conf 1 signature...>;
+ };
+ };
+ conf-2 {
+ kernel = "kernel-2";
+ fdt = "fdt-2";
+ signature-1 {
+ algo = "sha1,rsa2048";
+ value = <...conf 1 signature...>;
+ };
+ };
+ };
+};
+
+
+You can see that we have added hashes for all images (since they are no
+longer signed), and a signature to each configuration. In the above example,
+mkimage will sign configurations/conf-1, the kernel and fdt that are
+pointed to by the configuration (/images/kernel-1, /images/kernel-1/hash-1,
+/images/fdt-1, /images/fdt-1/hash-1) and the root structure of the image
+(so that it isn't possible to add or remove root nodes). The signature is
+written into /configurations/conf-1/signature-1/value. It can easily be
+verified later even if the FIT has been signed with other keys in the
+meantime.
+
+
+Verification
+------------
+FITs are verified when loaded. After the configuration is selected a list
+of required images is produced. If there are 'required' public keys, then
+each image must be verified against those keys. This means that every image
+that might be used by the target needs to be signed with 'required' keys.
+
+This happens automatically as part of a bootm command when FITs are used.
+
+For Signed Configurations, the default verification behavior can be changed by
+the following optional property in /signature node in U-Boot's control FDT.
+
+- required-mode: Valid values are "any" to allow verified boot to succeed if
+the selected configuration is signed by any of the 'required' keys, and "all"
+to allow verified boot to succeed if the selected configuration is signed by
+all of the 'required' keys.
+
+This property can be added to a binary device tree using fdtput as shown in
+below examples::
+
+ fdtput -t s control.dtb /signature required-mode any
+ fdtput -t s control.dtb /signature required-mode all
+
+
+Enabling FIT Verification
+-------------------------
+In addition to the options to enable FIT itself, the following CONFIGs must
+be enabled:
+
+CONFIG_FIT_SIGNATURE - enable signing and verification in FITs
+CONFIG_RSA - enable RSA algorithm for signing
+
+WARNING: When relying on signed FIT images with required signature check
+the legacy image format is default disabled by not defining
+CONFIG_LEGACY_IMAGE_FORMAT
+
+
+Testing
+-------
+An easy way to test signing and verification is to use the test script
+provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
+of U-Boot which runs under Linux) to show the operation of a 'bootm'
+command loading and verifying images.
+
+A sample run is show below:
+
+$ make O=sandbox sandbox_config
+$ make O=sandbox
+$ O=sandbox ./test/vboot/vboot_test.sh
+
+
+Simple Verified Boot Test
+=========================
+
+Please see doc/uImage.FIT/verified-boot.txt for more information
+
+/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
+Build keys
+do sha1 test
+Build FIT with signed images
+Test Verified Boot Run: unsigned signatures:: OK
+Sign images
+Test Verified Boot Run: signed images: OK
+Build FIT with signed configuration
+Test Verified Boot Run: unsigned config: OK
+Sign images
+Test Verified Boot Run: signed config: OK
+check signed config on the host
+Signature check OK
+OK
+Test Verified Boot Run: signed config: OK
+Test Verified Boot Run: signed config with bad hash: OK
+do sha256 test
+Build FIT with signed images
+Test Verified Boot Run: unsigned signatures:: OK
+Sign images
+Test Verified Boot Run: signed images: OK
+Build FIT with signed configuration
+Test Verified Boot Run: unsigned config: OK
+Sign images
+Test Verified Boot Run: signed config: OK
+check signed config on the host
+Signature check OK
+OK
+Test Verified Boot Run: signed config: OK
+Test Verified Boot Run: signed config with bad hash: OK
+
+Test passed
+
+
+Software signing: keydir vs keyfile
+-----------------------------------
+
+In the simplest case, signing is done by giving mkimage the 'keyfile'. This is
+the path to a file containing the signing key.
+
+The alternative is to pass the 'keydir' argument. In this case the filename of
+the key is derived from the 'keydir' and the "key-name-hint" property in the
+FIT. In this case the "key-name-hint" property is mandatory, and the key must
+exist in "<keydir>/<key-name-hint>.<ext>" Here the extension "ext" is
+specific to the signing algorithm.
+
+
+Hardware Signing with PKCS#11 or with HSM
+-----------------------------------------
+
+Securely managing private signing keys can challenging, especially when the
+keys are stored on the file system of a computer that is connected to the
+Internet. If an attacker is able to steal the key, they can sign malicious FIT
+images which will appear genuine to your devices.
+
+An alternative solution is to keep your signing key securely stored on hardware
+device like a smartcard, USB token or Hardware Security Module (HSM) and have
+them perform the signing. PKCS#11 is standard for interfacing with these crypto
+device.
+
+Requirements:
+Smartcard/USB token/HSM which can work with some openssl engine
+openssl
+
+For pkcs11 engine usage:
+libp11 (provides pkcs11 engine)
+p11-kit (recommended to simplify setup)
+opensc (for smartcards and smartcard like USB devices)
+gnutls (recommended for key generation, p11tool)
+
+For generic HSMs respective openssl engine must be installed and locateable by
+openssl. This may require setting up LD_LIBRARY_PATH if engine is not installed
+to openssl's default search paths.
+
+PKCS11 engine support forms "key id" based on "keydir" and with
+"key-name-hint". "key-name-hint" is used as "object" name (if not defined in
+keydir). "keydir" (if defined) is used to define (prefix for) which PKCS11 source
+is being used for lookup up for the key.
+
+PKCS11 engine key ids:
+ "pkcs11:<keydir>;object=<key-name-hint>;type=<public|private>"
+or, if keydir contains "object="
+ "pkcs11:<keydir>;type=<public|private>"
+or
+ "pkcs11:object=<key-name-hint>;type=<public|private>",
+
+Generic HSM engine support forms "key id" based on "keydir" and with
+"key-name-hint". If "keydir" is specified for mkimage it is used as a prefix in
+"key id" and is appended with "key-name-hint".
+
+Generic engine key ids:
+ "<keydir><key-name-hint>"
+or
+ "<key-name-hint>"
+
+As mkimage does not at this time support prompting for passwords HSM may need
+key preloading wrapper to be used when invoking mkimage.
+
+The following examples use the Nitrokey Pro using pkcs11 engine. Instructions
+for other devices may vary.
+
+Notes on pkcs11 engine setup:
+
+Make sure p11-kit, opensc are installed and that p11-kit is setup to use opensc.
+/usr/share/p11-kit/modules/opensc.module should be present on your system.
+
+
+Generating Keys On the Nitrokey:
+
+$ gpg --card-edit
+
+Reader ...........: Nitrokey Nitrokey Pro (xxxxxxxx0000000000000000) 00 00
+Application ID ...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+Version ..........: 2.1
+Manufacturer .....: ZeitControl
+Serial number ....: xxxxxxxx
+Name of cardholder: [not set]
+Language prefs ...: de
+Sex ..............: unspecified
+URL of public key : [not set]
+Login data .......: [not set]
+Signature PIN ....: forced
+Key attributes ...: rsa2048 rsa2048 rsa2048
+Max. PIN lengths .: 32 32 32
+PIN retry counter : 3 0 3
+Signature counter : 0
+Signature key ....: [none]
+Encryption key....: [none]
+Authentication key: [none]
+General key info..: [none]
+
+gpg/card> generate
+Make off-card backup of encryption key? (Y/n) n
+
+Please note that the factory settings of the PINs are
+ PIN = '123456' Admin PIN = '12345678'
+You should change them using the command --change-pin
+
+What keysize do you want for the Signature key? (2048) 4096
+The card will now be re-configured to generate a key of 4096 bits
+Note: There is no guarantee that the card supports the requested size.
+ If the key generation does not succeed, please check the
+ documentation of your card to see what sizes are allowed.
+What keysize do you want for the Encryption key? (2048) 4096
+The card will now be re-configured to generate a key of 4096 bits
+What keysize do you want for the Authentication key? (2048) 4096
+The card will now be re-configured to generate a key of 4096 bits
+Please specify how long the key should be valid.
+ 0 = key does not expire
+ <n> = key expires in n days
+ <n>w = key expires in n weeks
+ <n>m = key expires in n months
+ <n>y = key expires in n years
+Key is valid for? (0)
+Key does not expire at all
+Is this correct? (y/N) y
+
+GnuPG needs to construct a user ID to identify your key.
+
+Real name: John Doe
+Email address: john.doe@email.com
+Comment:
+You selected this USER-ID:
+ "John Doe <john.doe@email.com>"
+
+Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
+
+
+Using p11tool to get the token URL:
+
+Depending on system configuration, gpg-agent may need to be killed first.
+
+$ p11tool --provider /usr/lib/opensc-pkcs11.so --list-tokens
+Token 0:
+URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29
+Label: OpenPGP card (User PIN (sig))
+Type: Hardware token
+Manufacturer: ZeitControl
+Model: PKCS#15 emulated
+Serial: 000xxxxxxxxx
+Module: (null)
+
+
+Token 1:
+URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%29
+Label: OpenPGP card (User PIN)
+Type: Hardware token
+Manufacturer: ZeitControl
+Model: PKCS#15 emulated
+Serial: 000xxxxxxxxx
+Module: (null)
+
+Use the portion of the signature token URL after "pkcs11:" as the keydir argument (-k) to mkimage below.
+
+
+Use the URL of the token to list the private keys:
+
+$ p11tool --login --provider /usr/lib/opensc-pkcs11.so --list-privkeys \
+"pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29"
+Token 'OpenPGP card (User PIN (sig))' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29' requires user PIN
+Enter PIN:
+Object 0:
+URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29;id=%01;object=Signature%20key;type=private
+Type: Private key
+Label: Signature key
+Flags: CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE;
+ID: 01
+
+Use the label, in this case "Signature key" as the key-name-hint in your FIT.
+
+Create the fitImage:
+$ ./tools/mkimage -f fit-image.its fitImage
+
+
+Sign the fitImage with the hardware key:
+
+$ ./tools/mkimage -F -k \
+"model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29" \
+-K u-boot.dtb -N pkcs11 -r fitImage
+
+
+Future Work
+-----------
+- Roll-back protection using a TPM is done using the tpm command. This can
+be scripted, but we might consider a default way of doing this, built into
+bootm.
+
+
+Possible Future Work
+--------------------
+- Add support for other RSA/SHA variants, such as rsa4096,sha512.
+- Other algorithms besides RSA
+- More sandbox tests for failure modes
+- Passwords for keys/certificates
+- Perhaps implement OAEP
+- Enhance bootm to permit scripted signature verification (so that a script
+can verify an image but not actually boot it)
+
+
+Simon Glass
+sjg@chromium.org
+1-1-13
diff --git a/roms/u-boot/doc/uImage.FIT/source_file_format.txt b/roms/u-boot/doc/uImage.FIT/source_file_format.txt
new file mode 100644
index 000000000..f93ac6d1c
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/source_file_format.txt
@@ -0,0 +1,311 @@
+U-Boot new uImage source file format (bindings definition)
+==========================================================
+
+Author: Marian Balakowicz <m8@semihalf.com>
+External data additions, 25/1/16 Simon Glass <sjg@chromium.org>
+
+1) Introduction
+---------------
+
+Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
+booting method which requires that hardware description is available to the
+kernel in the form of Flattened Device Tree.
+
+Booting with a Flattened Device Tree is much more flexible and is intended to
+replace direct passing of 'struct bd_info' which was used to boot pre-FDT
+kernels.
+
+However, U-Boot needs to support both techniques to provide backward
+compatibility for platforms which are not FDT ready. Number of elements
+playing role in the booting process has increased and now includes the FDT
+blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
+in the system memory and passed to bootm as a arguments. Some of them may be
+missing: FDT is not present for legacy platforms, ramdisk is always optional.
+Additionally, old uImage format has been extended to support multi sub-images
+but the support is limited by simple format of the legacy uImage structure.
+Single binary header 'struct image_header' is not flexible enough to cover all
+possible scenarios.
+
+All those factors combined clearly show that there is a need for new, more
+flexible, multi component uImage format.
+
+
+2) New uImage format assumptions
+--------------------------------
+
+a) Implementation
+
+Libfdt has been selected for the new uImage format implementation as (1) it
+provides needed functionality, (2) is actively maintained and developed and
+(3) increases code reuse as it is already part of the U-Boot source tree.
+
+b) Terminology
+
+This document defines new uImage structure by providing FDT bindings for new
+uImage internals. Bindings are defined from U-Boot perspective, i.e. describe
+final form of the uImage at the moment when it reaches U-Boot. User
+perspective may be simpler, as some of the properties (like timestamps and
+hashes) will need to be filled in automatically by the U-Boot mkimage tool.
+
+To avoid confusion with the kernel FDT the following naming convention is
+proposed for the new uImage format related terms:
+
+FIT - Flattened uImage Tree
+
+FIT is formally a flattened device tree (in the libfdt meaning), which
+conforms to bindings defined in this document.
+
+.its - image tree source
+.itb - flattened image tree blob
+
+c) Image building procedure
+
+The following picture shows how the new uImage is prepared. Input consists of
+image source file (.its) and a set of data files. Image is created with the
+help of standard U-Boot mkimage tool which in turn uses dtc (device tree
+compiler) to produce image tree blob (.itb). Resulting .itb file is the
+actual binary of a new uImage.
+
+
+tqm5200.its
++
+vmlinux.bin.gz mkimage + dtc xfer to target
+eldk-4.2-ramdisk --------------> tqm5200.itb --------------> bootm
+tqm5200.dtb /|\
+... |
+ 'new uImage'
+
+ - create .its file, automatically filled-in properties are omitted
+ - call mkimage tool on a .its file
+ - mkimage calls dtc to create .itb image and assures that
+ missing properties are added
+ - .itb (new uImage) is uploaded onto the target and used therein
+
+
+d) Unique identifiers
+
+To identify FIT sub-nodes representing images, hashes, configurations (which
+are defined in the following sections), the "unit name" of the given sub-node
+is used as it's identifier as it assures uniqueness without additional
+checking required.
+
+
+3) Root node properties
+-----------------------
+
+Root node of the uImage Tree should have the following layout:
+
+/ o image-tree
+ |- description = "image description"
+ |- timestamp = <12399321>
+ |- #address-cells = <1>
+ |
+ o images
+ | |
+ | o image-1 {...}
+ | o image-2 {...}
+ | ...
+ |
+ o configurations
+ |- default = "conf-1"
+ |
+ o conf-1 {...}
+ o conf-2 {...}
+ ...
+
+
+ Optional property:
+ - description : Textual description of the uImage
+
+ Mandatory property:
+ - timestamp : Last image modification time being counted in seconds since
+ 1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
+
+ Conditionally mandatory property:
+ - #address-cells : Number of 32bit cells required to represent entry and
+ load addresses supplied within sub-image nodes. May be omitted when no
+ entry or load addresses are used.
+
+ Mandatory nodes:
+ - images : This node contains a set of sub-nodes, each of them representing
+ single component sub-image (like kernel, ramdisk, etc.). At least one
+ sub-image is required.
+ - configurations : Contains a set of available configuration nodes and
+ defines a default configuration.
+
+
+4) '/images' node
+-----------------
+
+This node is a container node for component sub-image nodes. Each sub-node of
+the '/images' node should have the following layout:
+
+ o image-1
+ |- description = "component sub-image description"
+ |- data = /incbin/("path/to/data/file.bin")
+ |- type = "sub-image type name"
+ |- arch = "ARCH name"
+ |- os = "OS name"
+ |- compression = "compression name"
+ |- load = <00000000>
+ |- entry = <00000000>
+ |
+ o hash-1 {...}
+ o hash-2 {...}
+ ...
+
+ Mandatory properties:
+ - description : Textual description of the component sub-image
+ - type : Name of component sub-image type, supported types are:
+ "standalone", "kernel", "kernel_noload", "ramdisk", "firmware", "script",
+ "filesystem", "flat_dt" and others (see uimage_type in common/image.c).
+ - data : Path to the external file which contains this node's binary data.
+ - compression : Compression used by included data. Supported compressions
+ are "gzip" and "bzip2". If no compression is used compression property
+ should be set to "none". If the data is compressed but it should not be
+ uncompressed by U-Boot (e.g. compressed ramdisk), this should also be set
+ to "none".
+
+ Conditionally mandatory property:
+ - os : OS name, mandatory for types "kernel". Valid OS names are:
+ "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix",
+ "solaris", "irix", "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx",
+ "u-boot", "rtems", "unity", "integrity".
+ - arch : Architecture name, mandatory for types: "standalone", "kernel",
+ "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
+ "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
+ "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200",
+ "sandbox".
+ - entry : entry point address, address size is determined by
+ '#address-cells' property of the root node.
+ Mandatory for types: "firmware", and "kernel".
+ - load : load address, address size is determined by '#address-cells'
+ property of the root node.
+ Mandatory for types: "firmware", and "kernel".
+ - compatible : compatible method for loading image.
+ Mandatory for types: "fpga", and images that do not specify a load address.
+ To use the generic fpga loading routine, use "u-boot,fpga-legacy".
+
+ Optional nodes:
+ - hash-1 : Each hash sub-node represents separate hash or checksum
+ calculated for node's data according to specified algorithm.
+
+
+5) Hash nodes
+-------------
+
+o hash-1
+ |- algo = "hash or checksum algorithm name"
+ |- value = [hash or checksum value]
+
+ Mandatory properties:
+ - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
+ - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
+ long.
+
+
+6) '/configurations' node
+-------------------------
+
+The 'configurations' node creates convenient, labeled boot configurations,
+which combine together kernel images with their ramdisks and fdt blobs.
+
+The 'configurations' node has has the following structure:
+
+o configurations
+ |- default = "default configuration sub-node unit name"
+ |
+ o config-1 {...}
+ o config-2 {...}
+ ...
+
+
+ Optional property:
+ - default : Selects one of the configuration sub-nodes as a default
+ configuration.
+
+ Mandatory nodes:
+ - configuration-sub-node-unit-name : At least one of the configuration
+ sub-nodes is required.
+
+
+7) Configuration nodes
+----------------------
+
+Each configuration has the following structure:
+
+o config-1
+ |- description = "configuration description"
+ |- kernel = "kernel sub-node unit name"
+ |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
+ |- loadables = "loadables sub-node unit-name"
+ |- compatible = "vendor,board-style device tree compatible string"
+
+
+ Mandatory properties:
+ - description : Textual configuration description.
+ - kernel or firmware: Unit name of the corresponding kernel or firmware
+ (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified,
+ control is passed to the firmware image.
+
+ Optional properties:
+ - fdt : Unit name of the corresponding fdt blob (component image node of a
+ "fdt type"). Additional fdt overlay nodes can be supplied which signify
+ that the resulting device tree blob is generated by the first base fdt
+ blob with all subsequent overlays applied.
+ - fpga : Unit name of the corresponding fpga bitstream blob
+ (component image node of a "fpga type").
+ - loadables : Unit name containing a list of additional binaries to be
+ loaded at their given locations. "loadables" is a comma-separated list
+ of strings. U-Boot will load each binary at its given start-address and
+ may optionally invoke additional post-processing steps on this binary based
+ on its component image node type.
+ - compatible : The root compatible string of the U-Boot device tree that
+ this configuration shall automatically match when CONFIG_FIT_BEST_MATCH is
+ enabled. If this property is not provided, the compatible string will be
+ extracted from the fdt blob instead. This is only possible if the fdt is
+ not compressed, so images with compressed fdts that want to use compatible
+ string matching must always provide this property.
+
+The FDT blob is required to properly boot FDT based kernel, so the minimal
+configuration for 2.6 FDT kernel is (kernel, fdt) pair.
+
+Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
+'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
+not* be specified in a configuration node.
+
+
+8) External data
+----------------
+
+The above format shows a 'data' property which holds the data for each image.
+It is also possible for this data to reside outside the FIT itself. This
+allows the FIT to be quite small, so that it can be loaded and scanned
+without loading a large amount of data. Then when an image is needed it can
+be loaded from an external source.
+
+In this case the 'data' property is omitted. Instead you can use:
+
+ - data-offset : offset of the data in a separate image store. The image
+ store is placed immediately after the last byte of the device tree binary,
+ aligned to a 4-byte boundary.
+ - data-size : size of the data in bytes
+
+The 'data-offset' property can be substituted with 'data-position', which
+defines an absolute position or address as the offset. This is helpful when
+booting U-Boot proper before performing relocation. Pass '-p [offset]' to
+mkimage to enable 'data-position'.
+
+Normal kernel FIT image has data embedded within FIT structure. U-Boot image
+for SPL boot has external data. Existence of 'data-offset' can be used to
+identify which format is used.
+
+For FIT image with external data, it would be better to align each blob of data
+to block(512 byte) for block device, so that we don't need to do the copy when
+read the image data in SPL. Pass '-B 0x200' to mkimage to align the FIT
+structure and data to 512 byte, other values available for other align size.
+
+9) Examples
+-----------
+
+Please see doc/uImage.FIT/*.its for actual image source files.
diff --git a/roms/u-boot/doc/uImage.FIT/uefi.its b/roms/u-boot/doc/uImage.FIT/uefi.its
new file mode 100644
index 000000000..378ca4ed8
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/uefi.its
@@ -0,0 +1,67 @@
+/*
+ * Example FIT image description file demonstrating the usage of the
+ * bootm command to launch UEFI binaries.
+ *
+ * Two boot configurations are available to enable booting GRUB2 on QEMU,
+ * the former uses a FDT blob contained in the FIT image, while the later
+ * relies on the FDT provided by the board emulator.
+ */
+
+/dts-v1/;
+
+/ {
+ description = "GRUB2 EFI and QEMU FDT blob";
+ #address-cells = <1>;
+
+ images {
+ efi-grub {
+ description = "GRUB EFI Firmware";
+ data = /incbin/("bootarm.efi");
+ type = "kernel_noload";
+ arch = "arm";
+ os = "efi";
+ compression = "none";
+ load = <0x0>;
+ entry = <0x0>;
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+
+ fdt-qemu {
+ description = "QEMU DTB";
+ data = /incbin/("qemu-arm.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-grub-fdt";
+
+ config-grub-fdt {
+ description = "GRUB EFI Boot w/ FDT";
+ kernel = "efi-grub";
+ fdt = "fdt-qemu";
+ signature-1 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel", "fdt";
+ };
+ };
+
+ config-grub-nofdt {
+ description = "GRUB EFI Boot w/o FDT";
+ kernel = "efi-grub";
+ signature-1 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel";
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/update3.its b/roms/u-boot/doc/uImage.FIT/update3.its
new file mode 100644
index 000000000..0659f2000
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/update3.its
@@ -0,0 +1,44 @@
+/*
+ * Example Automatic software update file.
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Automatic software updates: kernel, ramdisk, FDT";
+ #address-cells = <1>;
+
+ images {
+ update-1 {
+ description = "Linux kernel binary";
+ data = /incbin/("./vmlinux.bin.gz");
+ compression = "none";
+ type = "firmware";
+ load = <FF700000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ update-2 {
+ description = "Ramdisk image";
+ data = /incbin/("./ramdisk_image.gz");
+ compression = "none";
+ type = "firmware";
+ load = <FF8E0000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+
+ update-3 {
+ description = "FDT blob";
+ data = /incbin/("./blob.fdt");
+ compression = "none";
+ type = "firmware";
+ load = <FFAC0000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/update_uboot.its b/roms/u-boot/doc/uImage.FIT/update_uboot.its
new file mode 100644
index 000000000..aec482600
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/update_uboot.its
@@ -0,0 +1,24 @@
+/*
+ * Automatic software update for U-Boot
+ * Make sure the flashing addresses ('load' prop) is correct for your board!
+ */
+
+/dts-v1/;
+
+/ {
+ description = "Automatic U-Boot update";
+ #address-cells = <1>;
+
+ images {
+ update-1 {
+ description = "U-Boot binary";
+ data = /incbin/("./u-boot.bin");
+ compression = "none";
+ type = "firmware";
+ load = <0xFFFC0000>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+};
diff --git a/roms/u-boot/doc/uImage.FIT/verified-boot.txt b/roms/u-boot/doc/uImage.FIT/verified-boot.txt
new file mode 100644
index 000000000..41c9fa9e0
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/verified-boot.txt
@@ -0,0 +1,104 @@
+U-Boot Verified Boot
+====================
+
+Introduction
+------------
+Verified boot here means the verification of all software loaded into a
+machine during the boot process to ensure that it is authorised and correct
+for that machine.
+
+Verified boot extends from the moment of system reset to as far as you wish
+into the boot process. An example might be loading U-Boot from read-only
+memory, then loading a signed kernel, then using the kernel's dm-verity
+driver to mount a signed root filesystem.
+
+A key point is that it is possible to field-upgrade the software on machines
+which use verified boot. Since the machine will only run software that has
+been correctly signed, it is safe to read software from an updatable medium.
+It is also possible to add a secondary signed firmware image, in read-write
+memory, so that firmware can easily be upgraded in a secure manner.
+
+
+Signing
+-------
+Verified boot uses cryptographic algorithms to 'sign' software images.
+Images are signed using a private key known only to the signer, but can
+be verified using a public key. As its name suggests the public key can be
+made available without risk to the verification process. The private and
+public keys are mathematically related. For more information on how this
+works look up "public key cryptography" and "RSA" (a particular algorithm).
+
+The signing and verification process looks something like this:
+
+
+ Signing Verification
+ ======= ============
+
+ +--------------+ *
+ | RSA key pair | * +---------------+
+ | .key .crt | * | Public key in |
+ +--------------+ +------> public key ----->| trusted place |
+ | | * +---------------+
+ | | * |
+ v | * v
+ +---------+ | * +--------------+
+ | |----------+ * | |
+ | signer | * | U-Boot |
+ | |----------+ * | signature |--> yes/no
+ +---------+ | * | verification |
+ ^ | * | |
+ | | * +--------------+
+ | | * ^
+ +----------+ | * |
+ | Software | +----> signed image -------------+
+ | image | *
+ +----------+ *
+
+
+The signature algorithm relies only on the public key to do its work. Using
+this key it checks the signature that it finds in the image. If it verifies
+then we know that the image is OK.
+
+The public key from the signer allows us to verify and therefore trust
+software from updatable memory.
+
+It is critical that the public key be secure and cannot be tampered with.
+It can be stored in read-only memory, or perhaps protected by other on-chip
+crypto provided by some modern SOCs. If the public key can be changed, then
+the verification is worthless.
+
+
+Chaining Images
+---------------
+The above method works for a signer providing images to a run-time U-Boot.
+It is also possible to extend this scheme to a second level, like this:
+
+1. Master private key is used by the signer to sign a first-stage image.
+2. Master public key is placed in read-only memory.
+2. Secondary private key is created and used to sign second-stage images.
+3. Secondary public key is placed in first stage images
+4. We use the master public key to verify the first-stage image. We then
+use the secondary public key in the first-stage image to verify the second-
+state image.
+5. This chaining process can go on indefinitely. It is recommended to use a
+different key at each stage, so that a compromise in one place will not
+affect the whole change.
+
+
+Flattened Image Tree (FIT)
+--------------------------
+The FIT format is already widely used in U-Boot. It is a flattened device
+tree (FDT) in a particular format, with images contained within. FITs
+include hashes to verify images, so it is relatively straightforward to
+add signatures as well.
+
+The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in
+a standard place. Then when a FIT is loaded it can be verified using that
+public key. Multiple keys and multiple signatures are supported.
+
+See signature.txt for more information.
+
+
+Simon Glass
+sjg@chromium.org
+1-1-13
diff --git a/roms/u-boot/doc/uImage.FIT/x86-fit-boot.txt b/roms/u-boot/doc/uImage.FIT/x86-fit-boot.txt
new file mode 100644
index 000000000..88d3460a8
--- /dev/null
+++ b/roms/u-boot/doc/uImage.FIT/x86-fit-boot.txt
@@ -0,0 +1,272 @@
+Booting Linux on x86 with FIT
+=============================
+
+Background
+----------
+
+(corrections to the text below are welcome)
+
+Generally Linux x86 uses its own very complex booting method. There is a setup
+binary which contains all sorts of parameters and a compressed self-extracting
+binary for the kernel itself, often with a small built-in serial driver to
+display decompression progress.
+
+The x86 CPU has various processor modes. I am no expert on these, but my
+understanding is that an x86 CPU (even a really new one) starts up in a 16-bit
+'real' mode where only 1MB of memory is visible, moves to 32-bit 'protected'
+mode where 4GB is visible (or more with special memory access techniques) and
+then to 64-bit 'long' mode if 64-bit execution is required.
+
+Partly the self-extracting nature of Linux was introduced to cope with boot
+loaders that were barely capable of loading anything. Even changing to 32-bit
+mode was something of a challenge, so putting this logic in the kernel seemed
+to make sense.
+
+Bit by bit more and more logic has been added to this post-boot pre-Linux
+wrapper:
+
+- Changing to 32-bit mode
+- Decompression
+- Serial output (with drivers for various chips)
+- Load address randomisation
+- Elf loader complete with relocation (for the above)
+- Random number generator via 3 methods (again for the above)
+- Some sort of EFI mini-loader (1000+ glorious lines of code)
+- Locating and tacking on a device tree and ramdisk
+
+To my mind, if you sit back and look at things from first principles, this
+doesn't make a huge amount of sense. Any boot loader worth its salts already
+has most of the above features and more besides. The boot loader already knows
+the layout of memory, has a serial driver, can decompress things, includes an
+ELF loader and supports device tree and ramdisks. The decision to duplicate
+all these features in a Linux wrapper caters for the lowest common
+denominator: a boot loader which consists of a BIOS call to load something off
+disk, followed by a jmp instruction.
+
+(Aside: On ARM systems, we worry that the boot loader won't know where to load
+the kernel. It might be easier to just provide that information in the image,
+or in the boot loader rather than adding a self-relocator to put it in the
+right place. Or just use ELF?
+
+As a result, the x86 kernel boot process is needlessly complex. The file
+format is also complex, and obfuscates the contents to a degree that it is
+quite a challenge to extract anything from it. This bzImage format has become
+so prevalent that is actually isn't possible to produce the 'raw' kernel build
+outputs with the standard Makefile (as it is on ARM for example, at least at
+the time of writing).
+
+This document describes an alternative boot process which uses simple raw
+images which are loaded into the right place by the boot loader and then
+executed.
+
+
+Build the kernel
+----------------
+
+Note: these instructions assume a 32-bit kernel. U-Boot also supports directly
+booting a 64-bit kernel by jumping into 64-bit mode first (see below).
+
+You can build the kernel as normal with 'make'. This will create a file called
+'vmlinux'. This is a standard ELF file and you can look at it if you like:
+
+$ objdump -h vmlinux
+
+vmlinux: file format elf32-i386
+
+Sections:
+Idx Name Size VMA LMA File off Algn
+ 0 .text 00416850 81000000 01000000 00001000 2**5
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
+ 1 .notes 00000024 81416850 01416850 00417850 2**2
+ CONTENTS, ALLOC, LOAD, READONLY, CODE
+ 2 __ex_table 00000c50 81416880 01416880 00417880 2**3
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 3 .rodata 00154b9e 81418000 01418000 00419000 2**5
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 4 __bug_table 0000597c 8156cba0 0156cba0 0056dba0 2**0
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 5 .pci_fixup 00001b80 8157251c 0157251c 0057351c 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 6 .tracedata 00000024 8157409c 0157409c 0057509c 2**0
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 7 __ksymtab 00007ec0 815740c0 015740c0 005750c0 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 8 __ksymtab_gpl 00004a28 8157bf80 0157bf80 0057cf80 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 9 __ksymtab_strings 0001d6fc 815809a8 015809a8 005819a8 2**0
+ CONTENTS, ALLOC, LOAD, READONLY, DATA
+ 10 __init_rodata 00001c3c 8159e0a4 0159e0a4 0059f0a4 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 11 __param 00000ff0 8159fce0 0159fce0 005a0ce0 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 12 __modver 00000330 815a0cd0 015a0cd0 005a1cd0 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 13 .data 00063000 815a1000 015a1000 005a2000 2**12
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 14 .init.text 0002f104 81604000 01604000 00605000 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
+ 15 .init.data 00040cdc 81634000 01634000 00635000 2**12
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 16 .x86_cpu_dev.init 0000001c 81674cdc 01674cdc 00675cdc 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 17 .altinstructions 0000267c 81674cf8 01674cf8 00675cf8 2**0
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 18 .altinstr_replacement 00000942 81677374 01677374 00678374 2**0
+ CONTENTS, ALLOC, LOAD, READONLY, CODE
+ 19 .iommu_table 00000014 81677cb8 01677cb8 00678cb8 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 20 .apicdrivers 00000004 81677cd0 01677cd0 00678cd0 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 21 .exit.text 00001a80 81677cd8 01677cd8 00678cd8 2**0
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
+ 22 .data..percpu 00007880 8167a000 0167a000 0067b000 2**12
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 23 .smp_locks 00003000 81682000 01682000 00683000 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
+ 24 .bss 000a1000 81685000 01685000 00686000 2**12
+ ALLOC
+ 25 .brk 00424000 81726000 01726000 00686000 2**0
+ ALLOC
+ 26 .comment 00000049 00000000 00000000 00686000 2**0
+ CONTENTS, READONLY
+ 27 .GCC.command.line 0003e055 00000000 00000000 00686049 2**0
+ CONTENTS, READONLY
+ 28 .debug_aranges 0000f4c8 00000000 00000000 006c40a0 2**3
+ CONTENTS, RELOC, READONLY, DEBUGGING
+ 29 .debug_info 0440b0df 00000000 00000000 006d3568 2**0
+ CONTENTS, RELOC, READONLY, DEBUGGING
+ 30 .debug_abbrev 0022a83b 00000000 00000000 04ade647 2**0
+ CONTENTS, READONLY, DEBUGGING
+ 31 .debug_line 004ead0d 00000000 00000000 04d08e82 2**0
+ CONTENTS, RELOC, READONLY, DEBUGGING
+ 32 .debug_frame 0010a960 00000000 00000000 051f3b90 2**2
+ CONTENTS, RELOC, READONLY, DEBUGGING
+ 33 .debug_str 001b442d 00000000 00000000 052fe4f0 2**0
+ CONTENTS, READONLY, DEBUGGING
+ 34 .debug_loc 007c7fa9 00000000 00000000 054b291d 2**0
+ CONTENTS, RELOC, READONLY, DEBUGGING
+ 35 .debug_ranges 00098828 00000000 00000000 05c7a8c8 2**3
+ CONTENTS, RELOC, READONLY, DEBUGGING
+
+There is also the setup binary mentioned earlier. This is at
+arch/x86/boot/setup.bin and is about 12KB in size. It includes the command
+line and various settings need by the kernel. Arguably the boot loader should
+provide all of this also, but setting it up is some complex that the kernel
+helps by providing a head start.
+
+As you can see the code loads to address 0x01000000 and everything else
+follows after that. We could load this image using the 'bootelf' command but
+we would still need to provide the setup binary. This is not supported by
+U-Boot although I suppose you could mostly script it. This would permit the
+use of a relocatable kernel.
+
+All we need to boot is the vmlinux file and the setup.bin file.
+
+
+Create a FIT
+------------
+
+To create a FIT you will need a source file describing what should go in the
+FIT. See kernel.its for an example for x86 and also instructions on setting
+the 'arch' value for booting 64-bit kernels if desired. Put this into a file
+called image.its.
+
+Note that setup is loaded to the special address of 0x90000 (a special address
+you just have to know) and the kernel is loaded to 0x01000000 (the address you
+saw above). This means that you will need to load your FIT to a different
+address so that U-Boot doesn't overwrite it when decompressing. Something like
+0x02000000 will do so you can set CONFIG_SYS_LOAD_ADDR to that.
+
+In that example the kernel is compressed with lzo. Also we need to provide a
+flat binary, not an ELF. So the steps needed to set things are are:
+
+ # Create a flat binary
+ objcopy -O binary vmlinux vmlinux.bin
+
+ # Compress it into LZO format
+ lzop vmlinux.bin
+
+ # Build a FIT image
+ mkimage -f image.its image.fit
+
+(be careful to run the mkimage from your U-Boot tools directory since it
+will have x86_setup support.)
+
+You can take a look at the resulting fit file if you like:
+
+$ dumpimage -l image.fit
+FIT description: Simple image with single Linux kernel on x86
+Created: Tue Oct 7 10:57:24 2014
+ Image 0 (kernel)
+ Description: Vanilla Linux kernel
+ Created: Tue Oct 7 10:57:24 2014
+ Type: Kernel Image
+ Compression: lzo compressed
+ Data Size: 4591767 Bytes = 4484.15 kB = 4.38 MB
+ Architecture: Intel x86
+ OS: Linux
+ Load Address: 0x01000000
+ Entry Point: 0x00000000
+ Hash algo: sha1
+ Hash value: 446b5163ebfe0fb6ee20cbb7a8501b263cd92392
+ Image 1 (setup)
+ Description: Linux setup.bin
+ Created: Tue Oct 7 10:57:24 2014
+ Type: x86 setup.bin
+ Compression: uncompressed
+ Data Size: 12912 Bytes = 12.61 kB = 0.01 MB
+ Hash algo: sha1
+ Hash value: a1f2099cf47ff9816236cd534c77af86e713faad
+ Default Configuration: 'config-1'
+ Configuration 0 (config-1)
+ Description: Boot Linux kernel
+ Kernel: kernel
+
+
+Booting the FIT
+---------------
+
+To make it boot you need to load it and then use 'bootm' to boot it. A
+suitable script to do this from a network server is:
+
+ bootp
+ tftp image.fit
+ bootm
+
+This will load the image from the network and boot it. The command line (from
+the 'bootargs' environment variable) will be passed to the kernel.
+
+If you want a ramdisk you can add it as normal with FIT. If you want a device
+tree then x86 doesn't normally use those - it has ACPI instead.
+
+
+Why Bother?
+-----------
+
+1. It demystifies the process of booting an x86 kernel
+2. It allows use of the standard U-Boot boot file format
+3. It allows U-Boot to perform decompression - problems will provide an error
+message and you are still in the boot loader. It is possible to investigate.
+4. It avoids all the pre-loader code in the kernel which is quite complex to
+follow
+5. You can use verified/secure boot and other features which haven't yet been
+added to the pre-Linux
+6. It makes x86 more like other architectures in the way it boots a kernel.
+You can potentially use the same file format for the kernel, and the same
+procedure for building and packaging it.
+
+
+References
+----------
+
+In the Linux kernel, Documentation/x86/boot.txt defines the boot protocol for
+the kernel including the setup.bin format. This is handled in U-Boot in
+arch/x86/lib/zimage.c and arch/x86/lib/bootm.c.
+
+Various files in the same directory as this file describe the FIT format.
+
+
+--
+Simon Glass
+sjg@chromium.org
+7-Oct-2014
diff --git a/roms/u-boot/doc/usage/addrmap.rst b/roms/u-boot/doc/usage/addrmap.rst
new file mode 100644
index 000000000..472fd547f
--- /dev/null
+++ b/roms/u-boot/doc/usage/addrmap.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+addrmap command
+===============
+
+Synopsis
+--------
+
+::
+
+ addrmap
+
+Description
+-----------
+
+The addrmap command is used to display non-identity virtual-physical memory
+mappings for 32-bit CPUs.
+
+The output may look like:
+
+::
+
+ => addrmap
+ vaddr paddr size
+ ================ ================ ================
+ e0000000 fe0000000 00100000
+ 00000000 00000000 04000000
+ 04000000 04000000 04000000
+ 80000000 c00000000 10000000
+ 90000000 c10000000 10000000
+ a0000000 fe1000000 00010000
+
+The first column indicates the virtual address.
+The second column indicates the physical address.
+The third column indicates the mapped size.
+
+Configuration
+-------------
+
+To use the addrmap command you must specify CONFIG_CMD_ADDRMAP=y.
+It is automatically turned on when CONFIG_ADDR_MAP is set.
diff --git a/roms/u-boot/doc/usage/askenv.rst b/roms/u-boot/doc/usage/askenv.rst
new file mode 100644
index 000000000..5c4ca35d4
--- /dev/null
+++ b/roms/u-boot/doc/usage/askenv.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+askenv command
+===============
+
+Synopsis
+--------
+
+::
+
+ askenv name [message] [size]
+
+Description
+-----------
+
+Display message and get environment variable name of max size characters
+from stdin.
+
+name
+ name of the environment variable
+
+message
+ message is displayed while the command waits for the value to be
+ entered from stdin.if no message is specified,a default message
+ "Please enter name:" will be displayed.
+
+size
+ maximum number of characters that will be stored in environment
+ variable name.this is in decimal number format (unlike in
+ other commands where size values are in hexa-decimal). Default
+ value of size is 1023 (CONFIG_SYS_CBSIZE - 1).
+
+Example
+-------
+
+Value of a environment variable env1 without message and size parameters:
+
+::
+
+ => askenv env1;echo $?
+ Please enter 'env1': val1
+ 0
+ => printenv env1
+ env1=val1
+
+Value of a environment variable env2 with message and size parameters:
+
+::
+
+ => askenv env2 Please type-in a value for env2: 10;echo $?
+ Please type-in a value for env2: 1234567890123
+ 0
+ => printenv env2
+ env2=1234567890
+
+Value of a environment variable env3 with size parameter only:
+
+::
+
+ => askenv env3 10;echo $?
+ Please enter 'env3': val3
+ 0
+ => printenv env3
+ env3=val3
+
+Return Value of askenv command, when used without any other arguments:
+
+::
+
+ => askenv;echo $?
+ askenv - get environment variables from stdin
+
+ Usage:
+ askenv name [message] [size]
+ - display 'message' and get environment variable 'name' from stdin (max 'size' chars)
+ 1
+
+Configuration
+-------------
+
+The askenv command is only available if CMD_ASKENV=y
+
+Return value
+------------
+
+The return value $? is set to 0 (true).
+If no other arguments are specified (along with askenv), it is set to 1 (false).
diff --git a/roms/u-boot/doc/usage/base.rst b/roms/u-boot/doc/usage/base.rst
new file mode 100644
index 000000000..db9cd4d97
--- /dev/null
+++ b/roms/u-boot/doc/usage/base.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+base command
+============
+
+Synopsis
+--------
+
+::
+
+ base [address]
+
+Description
+-----------
+
+The *base* command sets or displays the address offset used by the memory
+commands *cmp, cp, md, mdc, mm, ms, mw, mwc*.
+
+All other commands ignore the address defined by *base*.
+
+address
+ new base address as hexadecimal number. If no value is provided, the current
+ value is displayed.
diff --git a/roms/u-boot/doc/usage/bootefi.rst b/roms/u-boot/doc/usage/bootefi.rst
new file mode 100644
index 000000000..282f22aac
--- /dev/null
+++ b/roms/u-boot/doc/usage/bootefi.rst
@@ -0,0 +1,135 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2020, Heinrich Schuchardt <xypron.glpk@gmx.de>
+
+bootefi command
+===============
+
+Synopsis
+--------
+
+::
+
+ bootefi [image_addr] [fdt_addr]
+ bootefi bootmgr [fdt_addr]
+ bootefi hello [fdt_addr]
+ bootefi selftest [fdt_addr]
+
+Description
+-----------
+
+The *bootefi* command is used to launch a UEFI binary which can be either of
+
+* UEFI application
+* UEFI boot services driver
+* UEFI run-time services driver
+
+An operating system requires a hardware description which can either be
+presented as ACPI table (CONFIG\_GENERATE\_ACPI\_TABLE=y) or as device-tree
+The load address of the device-tree may be provided as parameter *fdt\_addr*. If
+this address is not specified, the bootefi command will try to fall back in
+sequence to:
+
+* the device-tree specified by environment variable *fdt\_addr*
+* the device-tree specified by environment variable *fdtcontroladdr*
+
+The load address of the binary is specified by parameter *image_address*. A
+command sequence to run a UEFI application might look like
+
+::
+
+ load mmc 0:2 $fdt_addr_r dtb
+ load mmc 0:1 $kernel_addr_r /EFI/grub/grubaa64.efi
+ bootefi $kernel_addr_r $fdt_addr_r
+
+The last file loaded defines the image file path in the loaded image protocol.
+Hence the executable should always be loaded last.
+
+The value of the environment variable *bootargs* is converted from UTF-8 to
+UTF-16 and passed as load options in the loaded image protocol to the UEFI
+binary.
+
+Note
+ UEFI binaries that are contained in FIT images are launched via the
+ *bootm* command.
+
+UEFI boot manager
+'''''''''''''''''
+
+The UEFI boot manager is invoked by the *bootefi bootmgr* sub-command.
+Here boot options are defined by UEFI variables with a name consisting of the
+letters *Boot* followed by a four digit hexadecimal number, e.g. *Boot0001* or
+*BootA03E*. The boot variable defines a label, the device path of the binary to
+execute as well as the load options passed in the loaded image protocol.
+
+If the UEFI variable *BootNext* is defined, it specifies the number of the boot
+option to execute next. If no binary can be loaded via *BootNext* the variable
+*BootOrder* specifies in which sequence boot options shalled be tried.
+
+The values of these variables can be managed using the U-Boot command
+*efidebug*.
+
+UEFI hello world application
+''''''''''''''''''''''''''''
+
+U-Boot can be compiled with a hello world application that can be launched using
+the *bootefi hello* sub-command. A session might look like
+
+::
+
+ => setenv bootargs 'Greetings to the world'
+ => bootefi hello
+ Booting /MemoryMapped(0x0,0x10001000,0x1000)
+ Hello, world!
+ Running on UEFI 2.8
+ Have SMBIOS table
+ Have device tree
+ Load options: Greetings to the world
+
+UEFI selftest
+'''''''''''''
+
+U-Boot can be compiled with UEFI unit tests. These unit tests are invoked using
+the *bootefi selftest* sub-command.
+
+Which unit test is executed is controlled by the environment variable
+*efi\_selftest*. If this variable is not set, all unit tests that are not marked
+as 'on request' are executed.
+
+To show a list of the available unit tests the value *list* can be used
+
+::
+
+ => setenv efi_selftest list
+ => bootefi selftest
+
+ Available tests:
+ 'block image transfer' - on request
+ 'block device'
+ 'configuration tables'
+ ...
+
+A single test is selected for execution by setting the *efi\_selftest*
+environment variable to match one of the listed identifiers
+
+::
+
+ => setenv efi_selftest 'block image transfer'
+ => bootefi selftest
+
+Some of the tests execute the ExitBootServices() UEFI boot service and will not
+return to the command line but require a board reset.
+
+Configuration
+-------------
+
+To use the *bootefi* command you must specify CONFIG\_CMD\_BOOTEFI=y.
+The *bootefi hello* sub-command requries CMD\_BOOTEFI\_HELLO=y.
+The *bootefi selftest* sub-command depends on CMD\_BOOTEFI\_SELFTEST=y.
+
+See also
+--------
+
+* *bootm* for launching UEFI binaries packed in FIT images
+* *booti*, *bootm*, *bootz* for launching a Linux kernel without using the
+ UEFI sub-system
+* *efidebug* for setting UEFI boot variables
diff --git a/roms/u-boot/doc/usage/booti.rst b/roms/u-boot/doc/usage/booti.rst
new file mode 100644
index 000000000..d631fb571
--- /dev/null
+++ b/roms/u-boot/doc/usage/booti.rst
@@ -0,0 +1,114 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+booti command
+=============
+
+Synopsis
+--------
+
+::
+
+ booti [<addr> [<initrd>[:<size>]] [<fdt>]]
+
+Description
+-----------
+
+The booti command is used to boot a Linux kernel in flat or compressed
+'Image' format. Which compressed formats are supported is configurable.
+
+addr
+ address of kernel image, defaults to CONFIG_SYS_LOAD_ADDR.
+
+initrd
+ address of the initial RAM disk. Use '-' to boot a kernel with a device
+ tree but without an initial RAM disk.
+
+size
+ size of the initial RAM disk. This parameter must be specified for raw
+ initial RAM disks.
+
+fdt
+ address of the device tree.
+
+To support compressed Image files the following environment variables must be
+set:
+
+kernel_comp_addr_r
+ start of memory area used for decompression
+
+kernel_comp_size
+ size of the compressed file. The value has to be at least the size of
+ loaded image for decompression to succeed. For the booti command the
+ maximum decompressed size is 10 times this value.
+
+Example
+-------
+
+This is the boot log of an Odroid C2 board:
+
+::
+
+ => load mmc 0:1 $fdt_addr_r dtb-5.10.0-3-arm64
+ 27530 bytes read in 7 ms (3.7 MiB/s)
+ => load mmc 0:1 $kernel_addr_r vmlinuz-5.10.0-3-arm64
+ 26990448 bytes read in 1175 ms (21.9 MiB/s)
+ => load mmc 0:1 $ramdisk_addr_r initrd.img-5.10.0-3-arm64
+ 27421776 bytes read in 1209 ms (21.6 MiB/s)
+ => booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
+ Moving Image from 0x8080000 to 0x8200000, end=9c60000
+ ## Flattened Device Tree blob at 08008000
+ Booting using the fdt blob at 0x8008000
+ Loading Ramdisk to 7a52a000, end 7bf50c50 ... OK
+ Loading Device Tree to 000000007a520000, end 000000007a529b89 ... OK
+
+ Starting kernel ...
+
+The kernel can be compressed with gzip:
+
+.. code-block:: bash
+
+ cd /boot
+ gzip -k vmlinuz-5.10.0-3-arm64
+
+Here is the boot log for the compressed kernel:
+
+::
+
+ => setenv kernel_comp_addr_r 0x50000000
+ => setenv kernel_comp_size 0x04000000
+ => load mmc 0:1 $fdt_addr_r dtb-5.10.0-3-arm64
+ 27530 bytes read in 6 ms (4.4 MiB/s)
+ => load mmc 0:1 $kernel_addr_r vmlinuz-5.10.0-3-arm64.gz
+ 9267730 bytes read in 402 ms (22 MiB/s)
+ => load mmc 0:1 $ramdisk_addr_r initrd.img-5.10.0-3-arm64
+ 27421776 bytes read in 1181 ms (22.1 MiB/s)
+ => booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
+ Uncompressing Kernel Image
+ Moving Image from 0x8080000 to 0x8200000, end=9c60000
+ ## Flattened Device Tree blob at 08008000
+ Booting using the fdt blob at 0x8008000
+ Loading Ramdisk to 7a52a000, end 7bf50c50 ... OK
+ Loading Device Tree to 000000007a520000, end 000000007a529b89 ... OK
+
+ Starting kernel ...
+
+Configuration
+-------------
+
+The booti command is only available if CONFIG_CMD_BOOTI=y.
+
+Which compression types are supported depends on:
+
+* CONFIG_BZIP2
+* CONFIG_GZIP
+* CONFIG_LZ4
+* CONFIG_LZMA
+* CONFIG_LZO
+* CONFIG_ZSTD
+
+Return value
+------------
+
+Normally this command does not return. If an error occurs, the return value $?
+is set to 1 (false). If the operating system returns to U-Boot, the system is
+reset.
diff --git a/roms/u-boot/doc/usage/bootmenu.rst b/roms/u-boot/doc/usage/bootmenu.rst
new file mode 100644
index 000000000..1f094ad6e
--- /dev/null
+++ b/roms/u-boot/doc/usage/bootmenu.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2011-2012 Pali Rohár <pali@kernel.org>
+
+bootmenu command
+================
+
+The "bootmenu" command uses U-Boot menu interfaces and provides
+a simple mechanism for creating menus with different boot items.
+The cursor keys "Up" and "Down" are used for navigation through
+the items. Current active menu item is highlighted and can be
+selected using the "Enter" key. The selection of the highlighted
+menu entry invokes an U-Boot command (or a list of commands)
+associated with this menu entry.
+
+The "bootmenu" command interprets ANSI escape sequencies, so
+an ANSI terminal is required for proper menu rendering and item
+selection.
+
+The assembling of the menu is done via a set of environment variables
+"bootmenu_<num>" and "bootmenu_delay", i.e.::
+
+ bootmenu_delay=<delay>
+ bootmenu_<num>="<title>=<commands>"
+
+<delay>
+ is the autoboot delay in seconds, after which the first
+ menu entry will be selected automatically
+
+<num>
+ is the boot menu entry number, starting from zero
+
+<title>
+ is the text of the menu entry shown on the console
+ or on the boot screen
+
+<commands>
+ are commands which will be executed when a menu
+ entry is selected
+
+Title and commands are separated by the first appearance of a '='
+character in the value of the environment variable.
+
+The first (optional) argument of the "bootmenu" command is a delay specifier
+and it overrides the delay value defined by "bootmenu_delay" environment
+variable. If the environment variable "bootmenu_delay" is not set or if
+the argument of the "bootmenu" command is not specified, the default delay
+will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on
+the console (or on the screen) and the command of the first menu entry will
+be called immediately. If delay is less then 0, bootmenu will be shown and
+autoboot will be disabled.
+
+Bootmenu always adds menu entry "U-Boot console" at the end of all menu
+entries specified by environment variables. When selecting this entry
+the bootmenu terminates and the usual U-Boot command prompt is presented
+to the user.
+
+Example environment::
+
+ setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry
+ setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry
+ setenv bootmenu_2 Reset board=reset # Set third menu entry
+ setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry
+ bootmenu 20 # Run bootmenu with autoboot delay 20s
+
+
+The above example will be rendered as below::
+
+ *** U-Boot Boot Menu ***
+
+ Boot 1. kernel
+ Boot 2. kernel
+ Reset board
+ U-Boot boot order
+ U-Boot console
+
+ Hit any key to stop autoboot: 20
+ Press UP/DOWN to move, ENTER to select
+
+The selected menu entry will be highlighted - it will have inverted
+background and text colors.
+
+The "bootmenu" cammand is enabled by::
+
+ CONFIG_CMD_BOOTMENU=y
+
+To run the bootmenu at startup add these additional settings::
+
+ CONFIG_AUTOBOOT_KEYED=y
+ CONFIG_BOOTDELAY=30
+ CONFIG_AUTOBOOT_MENU_SHOW=y
+
+When you intend to use the bootmenu on a color frame buffer console,
+make sure to additionally define::
+
+ CONFIG_CFB_CONSOLE_ANSI=y
diff --git a/roms/u-boot/doc/usage/button.rst b/roms/u-boot/doc/usage/button.rst
new file mode 100644
index 000000000..ea4176275
--- /dev/null
+++ b/roms/u-boot/doc/usage/button.rst
@@ -0,0 +1,64 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+button command
+==============
+
+Synopsis
+--------
+
+::
+
+ button list
+ button <name>
+
+Description
+-----------
+
+The button command is used to retrieve the status of a button. To show the
+status of a button with name 'button1' you would issue the command
+
+::
+
+ button button1
+
+The status of the button is both written to the console as *ON* or *OFF* and
+set in the return value variable *$?* as 0 (true) or 1 (false). To retrieve
+the status of a button with name *button1* and to write it to environment
+variable *status1* you would execute the commands
+
+::
+
+ button button1
+ setenv status1 $?
+
+A list of all available buttons and their status can be displayed using
+
+::
+
+ button list
+
+If a button device has not been probed yet, its status will be shown as
+*<inactive>* in the list.
+
+Configuration
+-------------
+
+To use the button command you must specify CONFIG_CMD_BUTTON=y and enable a
+button driver. The available buttons are defined in the device-tree.
+
+Return value
+------------
+
+The variable *$?* takes the following values
+
++---+-----------------------------+
+| 0 | ON, the button is pressed |
++---+-----------------------------+
+| 1 | OFF, the button is released |
++---+-----------------------------+
+| 0 | button list was shown |
++---+-----------------------------+
+| 1 | button not found |
++---+-----------------------------+
+| 1 | invalid arguments |
++---+-----------------------------+
diff --git a/roms/u-boot/doc/usage/conitrace.rst b/roms/u-boot/doc/usage/conitrace.rst
new file mode 100644
index 000000000..d9916c865
--- /dev/null
+++ b/roms/u-boot/doc/usage/conitrace.rst
@@ -0,0 +1,54 @@
+conitrace command
+=================
+
+Synopsis
+--------
+
+::
+
+ conitrace
+
+Description
+-----------
+
+The conitrace command is used to test the correct function of the console input
+driver. It is especially valuable for checking the support for special keys like
+<F1> or <POS1>.
+
+To display escape sequences on a single line the output only advances to the
+next line after detecting a pause of a few milliseconds.
+
+The output is hexadecimal.
+
+Examples
+--------
+
+Entering keys <B><SHIFT-B><CTRL-B><X>
+
+::
+
+ => conitrace
+ Waiting for your input
+ To terminate type 'x'
+ 62
+ 42
+ 02
+ =>
+
+Entering keys <F1><POS1><DEL><BACKSPACE><X>
+
+::
+
+ => conitrace
+ Waiting for your input
+ To terminate type 'x'
+ 1b 4f 50
+ 1b 5b 48
+ 1b 5b 33 7e
+ 7f
+ =>
+
+Configuration
+-------------
+
+The conitrace command is only available if CONFIG_CMD_CONITRACE=y.
diff --git a/roms/u-boot/doc/usage/dfu.rst b/roms/u-boot/doc/usage/dfu.rst
new file mode 100644
index 000000000..11c88072b
--- /dev/null
+++ b/roms/u-boot/doc/usage/dfu.rst
@@ -0,0 +1,404 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Device Firmware Upgrade (DFU)
+=============================
+
+Overview
+--------
+
+The Device Firmware Upgrade (DFU) allows to download and upload firmware
+to/from U-Boot connected over USB.
+
+U-boot follows the Universal Serial Bus Device Class Specification for
+Device Firmware Upgrade Version 1.1 the USB forum (DFU v1.1 in www.usb.org).
+
+U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu
+(cmd/dfu.c / CONFIG_CMD_DFU) based on:
+
+- the DFU stack (common/dfu.c and common/spl/spl_dfu.c), based on the
+ USB DFU download gadget (drivers/usb/gadget/f_dfu.c)
+- The access to mediums is done in DFU backends (driver/dfu)
+
+Today the supported DFU backends are:
+
+- MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT)
+- NAND
+- RAM
+- SF (serial flash)
+- MTD (all MTD device: NAND, SPI-NOR, SPI-NAND,...)
+- virtual
+
+These DFU backends are also used by
+
+- the dfutftp (see README.dfutftp)
+- the thordown command (cmd/thordown.c and gadget/f_thor.c)
+
+The "virtual" backend is a generic DFU backend to support a board specific
+target (for example OTP), only based on the weak functions:
+
+- dfu_write_medium_virt
+- dfu_get_medium_size_virt
+- dfu_read_medium_virt
+
+Configuration Options
+---------------------
+
+The following configuration option are relevant for device firmware upgrade:
+
+* CONFIG_DFU
+* CONFIG_DFU_OVER_USB
+* CONFIG_DFU_MMC
+* CONFIG_DFU_MTD
+* CONFIG_DFU_NAND
+* CONFIG_DFU_RAM
+* CONFIG_DFU_SF
+* CONFIG_DFU_SF_PART
+* CONFIG_DFU_TIMEOUT
+* CONFIG_DFU_VIRTUAL
+* CONFIG_CMD_DFU
+
+Environment variables
+---------------------
+
+The dfu command uses 3 environments variables:
+
+dfu_alt_info
+ The DFU setting for the USB download gadget with a semicolon separated
+ string of information on each alternate::
+
+ dfu_alt_info="<alt1>;<alt2>;....;<altN>"
+
+ When several devices are used, the format is:
+
+ - <interface> <dev>'='alternate list (';' separated)
+ - each interface is separated by '&'::
+
+ dfu_alt_info=\
+ "<interface1> <dev1>=<alt1>;....;<altN>&"\
+ "<interface2> <dev2>=<altN+1>;....;<altM>&"\
+ ...\
+ "<interfaceI> <devI>=<altY+1>;....;<altZ>&"
+
+dfu_bufsiz
+ size of the DFU buffer, when absent, defaults to
+ CONFIG_SYS_DFU_DATA_BUF_SIZE (8 MiB by default)
+
+dfu_hash_algo
+ name of the hash algorithm to use
+
+Commands
+--------
+
+dfu <USB_controller> [<interface> <dev>] list
+ list the alternate device defined in *dfu_alt_info*
+
+dfu <USB_controller> [<interface> <dev>] [<timeout>]
+ start the dfu stack on the USB instance with the selected medium
+ backend and use the *dfu_alt_info* variable to configure the
+ alternate setting and link each one with the medium
+ The dfu command continue until receive a ^C in console or
+ a DFU detach transaction from HOST. If CONFIG_DFU_TIMEOUT option
+ is enabled and <timeout> parameter is present in the command line,
+ the DFU operation will be aborted automatically after <timeout>
+ seconds of waiting remote to initiate DFU session.
+
+The possible values of <interface> are (with <USB controller> = 0 in the dfu
+command example)
+
+mmc
+ for eMMC and SD card::
+
+ dfu 0 mmc <dev>
+
+ each element in *dfu_alt_info* being
+
+ * <name> raw <offset> <size> [mmcpart <num>] raw access to mmc device
+ * <name> part <dev> <part_id> [mmcpart <num>] raw access to partition
+ * <name> fat <dev> <part_id> [mmcpart <num>] file in FAT partition
+ * <name> ext4 <dev> <part_id> [mmcpart <num>] file in EXT4 partition
+ * <name> skip 0 0 ignore flashed data
+ * <name> script 0 0 execute commands in shell
+
+ with
+
+ partid
+ being the GPT or DOS partition index,
+ num
+ being the eMMC hardware partition number.
+
+ A value of environment variable *dfu_alt_info* for eMMC could be::
+
+ u-boot raw 0x3e 0x800 mmcpart 1;bl2 raw 0x1e 0x1d mmcpart 1
+
+ A value of environment variable *dfu_alt_info* for SD card could be::
+
+ u-boot raw 0x80 0x800;uImage ext4 0 2
+
+ If don't want to flash given image file to storage, use "skip" type
+ entity.
+
+ - It can be used to protect flashing wrong image for the specific board.
+ - Especailly, this layout will be useful when thor protocol is used,
+ which performs flashing in batch mode, where more than one file is
+ processed.
+
+ For example, if one makes a single tar file with support for the two
+ boards with u-boot-<board1>.bin and u-boot-<board2>.bin files, one
+ can use it to flash a proper u-boot image on both without a failure::
+
+ u-boot-<board1>.bin raw 0x80 0x800; u-boot-<board2>.bin skip 0 0
+
+ When flashing new system image requires do some more complex things
+ than just writing data to the storage medium, one can use 'script'
+ type. Data written to such entity will be executed as a command list
+ in the u-boot's shell. This for example allows to re-create partition
+ layout and even set new *dfu_alt_info* for the newly created paritions.
+ Such script would look like::
+
+ setenv dfu_alt_info ...
+ setenv mbr_parts ...
+ mbr write ...
+
+ Please note that this means that user will be able to execute any
+ arbitrary commands just like in the u-boot's shell.
+
+nand
+ raw slc nand device::
+
+ dfu 0 nand <dev>
+
+ each element in *dfu_alt_info* being either of
+
+ * <name> raw <offset> <size> raw access to mmc device
+ * <name> part <dev> <part_id> raw acces to partition
+ * <name> partubi <dev> <part_id> raw acces to ubi partition
+
+ with
+
+ partid
+ is the MTD partition index
+
+ram
+ raw access to ram::
+
+ dfu 0 ram <dev>
+
+ dev
+ is not used for RAM target
+
+ each element in *dfu_alt_info* being::
+
+ <name> ram <offset> <size> raw access to ram
+
+sf
+ serial flash : NOR::
+
+ cmd: dfu 0 sf <dev>
+
+ each element in *dfu_alt_info* being either of:
+
+ * <name> raw <offset> <size> raw access to sf device
+ * <name> part <dev> <part_id> raw acces to partition
+ * <name> partubi <dev> <part_id> raw acces to ubi partition
+
+ with
+
+ partid
+ is the MTD partition index
+
+mtd
+ all MTD device: NAND, SPI-NOR, SPI-NAND,...::
+
+ cmd: dfu 0 mtd <dev>
+
+ with
+
+ dev
+ the mtd identifier as defined in mtd command
+ (nand0, nor0, spi-nand0,...)
+
+ each element in *dfu_alt_info* being either of:
+
+ * <name> raw <offset> <size> forraw access to mtd device
+ * <name> part <dev> <part_id> for raw acces to partition
+ * <name> partubi <dev> <part_id> for raw acces to ubi partition
+
+ with
+
+ partid
+ is the MTD partition index
+
+virt
+ virtual flash back end for DFU
+
+ ::
+
+ cmd: dfu 0 virt <dev>
+
+ each element in *dfu_alt_info* being:
+
+ * <name>
+
+<interface> and <dev> are absent, the dfu command to use multiple devices::
+
+ cmd: dfu 0 list
+ cmd: dfu 0
+
+*dfu_alt_info* variable provides the list of <interface> <dev> with
+alternate list separated by '&' with the same format for each <alt>::
+
+ mmc <dev>=<alt1>;....;<altN>
+ nand <dev>=<alt1>;....;<altN>
+ ram <dev>=<alt1>;....;<altN>
+ sf <dev>=<alt1>;....;<altN>
+ mtd <dev>=<alt1>;....;<altN>
+ virt <dev>=<alt1>;....;<altN>
+
+Callbacks
+---------
+
+The weak callback functions can be implemented to manage specific behavior
+
+dfu_initiated_callback
+ called when the DFU transaction is started, used to initiase the device
+
+dfu_flush_callback
+ called at the end of the DFU write after DFU manifestation, used to manage
+ the device when DFU transaction is closed
+
+Host tools
+----------
+
+When U-Boot runs the dfu stack, the DFU host tools can be used
+to send/receive firmwares on each configurated alternate.
+
+For example dfu-util is a host side implementation of the DFU 1.1
+specifications(http://dfu-util.sourceforge.net/) which works with U-Boot.
+
+Usage
+-----
+
+Example 1: firmware located in eMMC or SD card, with:
+
+- alternate 1 (alt=1) for SPL partition (GPT partition 1)
+- alternate 2 (alt=2) for U-Boot partition (GPT partition 2)
+
+The U-Boot configuration is::
+
+ U-Boot> env set dfu_alt_info "spl part 0 1;u-boot part 0 2"
+
+ U-Boot> dfu 0 mmc 0 list
+ DFU alt settings list:
+ dev: eMMC alt: 0 name: spl layout: RAW_ADDR
+ dev: eMMC alt: 1 name: u-boot layout: RAW_ADDR
+
+ Boot> dfu 0 mmc 0
+
+On the Host side:
+
+list the available alternate setting::
+
+ $> dfu-util -l
+ dfu-util 0.9
+
+ Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
+ Copyright 2010-2016 Tormod Volden and Stefan Schmidt
+ This program is Free Software and has ABSOLUTELY NO WARRANTY
+ Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
+
+ Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \
+ alt=1, name="u-boot", serial="003A00203438510D36383238"
+ Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \
+ alt=0, name="spl", serial="003A00203438510D36383238"
+
+ To download to U-Boot, use -D option
+
+ $> dfu-util -a 0 -D u-boot-spl.bin
+ $> dfu-util -a 1 -D u-boot.bin
+
+ To upload from U-Boot, use -U option
+
+ $> dfu-util -a 0 -U u-boot-spl.bin
+ $> dfu-util -a 1 -U u-boot.bin
+
+ To request a DFU detach and reset the USB connection:
+ $> dfu-util -a 0 -e -R
+
+
+Example 2: firmware located in NOR (sf) and NAND, with:
+
+- alternate 1 (alt=1) for SPL partition (NOR GPT partition 1)
+- alternate 2 (alt=2) for U-Boot partition (NOR GPT partition 2)
+- alternate 3 (alt=3) for U-Boot-env partition (NOR GPT partition 3)
+- alternate 4 (alt=4) for UBI partition (NAND GPT partition 1)
+
+::
+
+ U-Boot> env set dfu_alt_info \
+ "sf 0:0:10000000:0=spl part 0 1;u-boot part 0 2; \
+ u-boot-env part 0 3&nand 0=UBI partubi 0,1"
+
+ U-Boot> dfu 0 list
+
+ DFU alt settings list:
+ dev: SF alt: 0 name: spl layout: RAW_ADDR
+ dev: SF alt: 1 name: ssbl layout: RAW_ADDR
+ dev: SF alt: 2 name: u-boot-env layout: RAW_ADDR
+ dev: NAND alt: 3 name: UBI layout: RAW_ADDR
+
+ U-Boot> dfu 0
+
+::
+
+ $> dfu-util -l
+ Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
+ intf=0, alt=3, name="UBI", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
+ intf=0, alt=2, name="u-boot-env", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
+ intf=0, alt=1, name="u-boot", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
+ intf=0, alt=0, name="spl", serial="002700333338511934383330"
+
+Same example with MTD backend
+
+::
+
+ U-Boot> env set dfu_alt_info \
+ "mtd nor0=spl part 1;u-boot part 2;u-boot-env part 3&"\
+ "mtd nand0=UBI partubi 1"
+
+ U-Boot> dfu 0 list
+ using id 'nor0,0'
+ using id 'nor0,1'
+ using id 'nor0,2'
+ using id 'nand0,0'
+ DFU alt settings list:
+ dev: MTD alt: 0 name: spl layout: RAW_ADDR
+ dev: MTD alt: 1 name: u-boot layout: RAW_ADDR
+ dev: MTD alt: 2 name: u-boot-env layout: RAW_ADDR
+ dev: MTD alt: 3 name: UBI layout: RAW_ADDR
+
+Example 3
+
+firmware located in SD Card (mmc) and virtual partition on OTP and PMIC not
+volatile memory
+
+- alternate 1 (alt=1) for scard
+- alternate 2 (alt=2) for OTP (virtual)
+- alternate 3 (alt=3) for PMIC NVM (virtual)
+
+::
+
+ U-Boot> env set dfu_alt_info \
+ "mmc 0=sdcard raw 0 0x100000&"\
+ "virt 0=otp" \
+ "virt 1=pmic"
+
+::
+
+ U-Boot> dfu 0 list
+ DFU alt settings list:
+ dev: eMMC alt: 0 name: sdcard layout: RAW_ADDR
+ dev: VIRT alt: 1 name: otp layout: RAW_ADDR
+ dev: VIRT alt: 2 name: pmic layout: RAW_ADDR
diff --git a/roms/u-boot/doc/usage/echo.rst b/roms/u-boot/doc/usage/echo.rst
new file mode 100644
index 000000000..861abdfd1
--- /dev/null
+++ b/roms/u-boot/doc/usage/echo.rst
@@ -0,0 +1,65 @@
+echo command
+============
+
+Synopsis
+--------
+
+::
+
+ echo [-n] [args ...]
+
+Description
+-----------
+
+The echo command prints its arguments to the console separated by spaces.
+
+-n
+ Do not print a line feed after the last argument.
+
+args
+ Arguments to be printed. The arguments are evaluated before being passed to
+ the command.
+
+Examples
+--------
+
+Strings are parsed before the arguments are passed to the echo command:
+
+::
+
+ => echo "a" 'b' c
+ a b c
+ =>
+
+Observe how variables included in strings are handled:
+
+::
+
+ => setenv var X; echo "a)" ${var} 'b)' '${var}' c) ${var}
+ a) X b) ${var} c) X
+ =>
+
+
+-n suppresses the line feed:
+
+::
+
+ => echo -n 1 2 3; echo a b c
+ 1 2 3a b c
+ => echo -n 1 2 3
+ 1 2 3=>
+
+A more complex example:
+
+::
+
+ => for i in a b c; do for j in 1 2 3; do echo -n "${i}${j}, "; done; echo; done;
+ a1, a2, a3,
+ b1, b2, b3,
+ c1, c2, c3,
+ =>
+
+Return value
+------------
+
+The return value $? is always set to 0 (true).
diff --git a/roms/u-boot/doc/usage/exception.rst b/roms/u-boot/doc/usage/exception.rst
new file mode 100644
index 000000000..27df88bd5
--- /dev/null
+++ b/roms/u-boot/doc/usage/exception.rst
@@ -0,0 +1,66 @@
+exception command
+=================
+
+Synopsis
+--------
+
+::
+
+ exception <type>
+
+Description
+-----------
+
+The exception command is used to test the handling of exceptions like undefined
+instructions, segmentation faults or alignment faults.
+
+type
+ type of exception to be generated. The available types are architecture
+ dependent. Use 'help exception' to determine which are available.
+
+ **ARM:**
+
+ breakpoint
+ prefetch abort
+
+ unaligned
+ data abort
+
+ undefined
+ undefined instruction
+
+ **RISC-V:**
+
+ ebreak
+ breakpoint exception
+
+ unaligned
+ load address misaligned
+
+ undefined
+ undefined instruction
+
+ **Sandbox:**
+
+ sigsegv
+ illegal memory access
+
+ undefined
+ undefined instruction
+
+ **x86:**
+
+ undefined
+ undefined instruction
+
+Examples
+--------
+
+::
+
+ => exception undefined
+
+ Illegal instruction
+ pc = 0x56076dd1a0f9, pc_reloc = 0x540f9
+
+ resetting ...
diff --git a/roms/u-boot/doc/usage/exit.rst b/roms/u-boot/doc/usage/exit.rst
new file mode 100644
index 000000000..769223c47
--- /dev/null
+++ b/roms/u-boot/doc/usage/exit.rst
@@ -0,0 +1,40 @@
+exit command
+============
+
+Synopsis
+--------
+
+::
+
+ exit
+
+Description
+-----------
+
+The exit command terminates a script started via the run or source command.
+If scripts are nested, only the innermost script is left.
+
+::
+
+ => setenv inner 'echo entry inner; exit; echo inner done'
+ => setenv outer 'echo entry outer; run inner; echo outer done'
+ => run outer
+ entry outer
+ entry inner
+ outer done
+ =>
+
+When executed outside a script a warning is written. Following commands are not
+executed.
+
+::
+
+ => echo first; exit; echo last
+ first
+ exit not allowed from main input shell.
+ =>
+
+Return value
+------------
+
+$? is always set to 0 (true).
diff --git a/roms/u-boot/doc/usage/extension.rst b/roms/u-boot/doc/usage/extension.rst
new file mode 100644
index 000000000..2b88398b1
--- /dev/null
+++ b/roms/u-boot/doc/usage/extension.rst
@@ -0,0 +1,111 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2021, Kory Maincent <kory.maincent@bootlin.com>
+
+U-Boot extension board usage (CONFIG_EXTENSION)
+===============================================
+
+Synopsis
+--------
+
+::
+
+ extension scan
+ extension list
+ extension apply <extension number|all>
+
+Description
+-----------
+
+The "extension" command proposes a generic U-Boot mechanism to detect
+extension boards connected to the HW platform, and apply the appropriate
+Device Tree overlays depending on the detected extension boards.
+
+The "extension" command comes with three sub-commands:
+
+ - "extension scan" makes the generic code call the board-specific
+ extension_board_scan() function to retrieve the list of detected
+ extension boards.
+
+ - "extension list" allows to list the detected extension boards.
+
+ - "extension apply <number>|all" allows to apply the Device Tree
+ overlay(s) corresponding to one, or all, extension boards
+
+The latter requires two environment variables to exist:
+
+ - extension_overlay_addr: the RAM address where to load the Device
+ Tree overlays
+
+ - extension_overlay_cmd: the U-Boot command to load one overlay.
+ Indeed, the location and mechanism to load DT overlays is very setup
+ specific.
+
+In order to enable this mechanism, board-specific code must implement
+the extension_board_scan() function that fills in a linked list of
+"struct extension", each describing one extension board. In addition,
+the board-specific code must select the SUPPORT_EXTENSION_SCAN Kconfig
+boolean.
+
+Usage example
+-------------
+
+1. Make sure your devicetree is loaded and set as the working fdt tree.
+
+::
+
+ => run loadfdt
+ => fdt addr $fdtaddr
+
+2. Prepare the environment variables
+
+::
+
+ => setenv extension_overlay_addr 0x88080000
+ => setenv extension_overlay_cmd 'load mmc 0:1 ${extension_overlay_addr} /boot/${extension_overlay_name}'
+
+3. Detect the plugged extension board
+
+::
+
+ => extension scan
+
+4. List the plugged extension board information and the devicetree
+ overlay name
+
+::
+
+ => extension list
+
+5. Apply the appropriate devicetree overlay
+
+For apply the selected overlay:
+
+::
+
+ => extension apply 0
+
+For apply all the overlays:
+
+::
+
+ => extension apply all
+
+Simple extension_board_scan function example
+--------------------------------------------
+
+.. code-block:: c
+
+ int extension_board_scan(struct list_head *extension_list)
+ {
+ struct extension *extension;
+
+ extension = calloc(1, sizeof(struct extension));
+ snprintf(extension->overlay, sizeof(extension->overlay), "overlay.dtbo");
+ snprintf(extension->name, sizeof(extension->name), "extension board");
+ snprintf(extension->owner, sizeof(extension->owner), "sandbox");
+ snprintf(extension->version, sizeof(extension->version), "1.1");
+ snprintf(extension->other, sizeof(extension->other), "Extension board information");
+ list_add_tail(&extension->list, extension_list);
+
+ return 1;
+ }
diff --git a/roms/u-boot/doc/usage/false.rst b/roms/u-boot/doc/usage/false.rst
new file mode 100644
index 000000000..a17fe8602
--- /dev/null
+++ b/roms/u-boot/doc/usage/false.rst
@@ -0,0 +1,28 @@
+false command
+=============
+
+Synopsis
+--------
+
+::
+
+ false
+
+Description
+-----------
+
+The false command sets the return value $? to 1 (false).
+
+Example
+-------
+
+::
+
+ => false; echo $?
+ 1
+ =>
+
+Configuration
+-------------
+
+The false command is only available if CONFIG_HUSH_PARSER=y.
diff --git a/roms/u-boot/doc/usage/fatinfo.rst b/roms/u-boot/doc/usage/fatinfo.rst
new file mode 100644
index 000000000..af2eba434
--- /dev/null
+++ b/roms/u-boot/doc/usage/fatinfo.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+fatinfo command
+===============
+
+Synopsis
+--------
+
+::
+
+ fatinfo <interface> <dev[:part]>
+
+Description
+-----------
+
+The fatinfo command displays information about a FAT partition.
+
+interface
+ interface for accessing the block device (mmc, sata, scsi, usb, ....)
+
+dev
+ device number
+
+part
+ partition number, defaults to 1
+
+Example
+-------
+
+Here is the output for a partition on a 32 GB SD-Card:
+
+::
+
+ => fatinfo mmc 0:1
+ Interface: MMC
+ Device 0: Vendor: Man 00001b Snr 97560602 Rev: 13.8 Prod: EB1QT0
+ Type: Removable Hard Disk
+ Capacity: 30528.0 MB = 29.8 GB (62521344 x 512)
+ Filesystem: FAT32 "MYDISK "
+ =>
+
+Configuration
+-------------
+
+The fatinfo command is only available if CONFIG_CMD_FAT=y.
+
+Return value
+------------
+
+The return value $? is set to 0 (true) if the partition is a FAT partition.
+Otherwise it is set to 1 (false).
diff --git a/roms/u-boot/doc/usage/fdt_overlays.rst b/roms/u-boot/doc/usage/fdt_overlays.rst
new file mode 100644
index 000000000..ea3971343
--- /dev/null
+++ b/roms/u-boot/doc/usage/fdt_overlays.rst
@@ -0,0 +1,134 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2017, Pantelis Antoniou <pantelis.antoniou@konsulko.com>
+
+Device Tree Overlays
+====================
+
+Overlay Syntax
+--------------
+
+Device-tree overlays require a slightly different syntax compared to traditional
+device-trees. Please refer to dt-object-internal.txt in the device-tree compiler
+sources for information regarding the internal format of overlays:
+https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
+
+Building Overlays
+-----------------
+
+In a nutshell overlays provides a means to manipulate a symbol a previous
+device-tree or device-tree overlay has defined. It requires both the base
+device-tree and all the overlays to be compiled with the *-@* command line
+switch of the device-tree compiler so that symbol information is included.
+
+Note
+ Support for *-@* option can only be found in dtc version 1.4.4 or newer.
+ Only version 4.14 or higher of the Linux kernel includes a built in version
+ of dtc that meets this requirement.
+
+Building a binary device-tree overlay follows the same process as building a
+traditional binary device-tree. For example:
+
+**base.dts**
+
+::
+
+ /dts-v1/;
+ / {
+ foo: foonode {
+ foo-property;
+ };
+ };
+
+.. code-block:: console
+
+ $ dtc -@ -I dts -O dtb -o base.dtb base.dts
+
+**overlay.dts**
+
+::
+
+ /dts-v1/;
+ /plugin/;
+ / {
+ fragment@1 {
+ target = <&foo>;
+ __overlay__ {
+ overlay-1-property;
+ bar: barnode {
+ bar-property;
+ };
+ };
+ };
+ };
+
+.. code-block:: console
+
+ $ dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dts
+
+Ways to Utilize Overlays in U-Boot
+----------------------------------
+
+There are two ways to apply overlays in U-Boot.
+
+* Include and define overlays within a FIT image and have overlays
+ automatically applied.
+
+* Manually load and apply overlays
+
+The remainder of this document will discuss using overlays via the manual
+approach. For information on using overlays as part of a FIT image please see:
+doc/uImage.FIT/overlay-fdt-boot.txt
+
+Manually Loading and Applying Overlays
+--------------------------------------
+
+1. Figure out where to place both the base device tree blob and the
+ overlay. Make sure you have enough space to grow the base tree without
+ overlapping anything.
+
+::
+
+ => setenv fdtaddr 0x87f00000
+ => setenv fdtovaddr 0x87fc0000
+
+2. Load the base binary device-tree and the binary device-tree overlay.
+
+::
+
+ => load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/base.dtb
+ => load ${devtype} ${bootpart} ${fdtovaddr} ${bootdir}/overlay.dtbo
+
+3. Set the base binary device-tree as the working fdt tree.
+
+::
+
+ => fdtaddr $fdtaddr
+
+4. Grow it enough so it can encompass all applied overlays
+
+::
+
+ => fdt resize 8192
+
+5. You are now ready to apply the overlay.
+
+::
+
+ => fdt apply $fdtovaddr
+
+6. Boot system like you would do with a traditional dtb.
+
+For bootm:
+
+::
+
+ => bootm ${kerneladdr} - ${fdtaddr}
+
+For bootz:
+
+::
+
+ => bootz ${kerneladdr} - ${fdtaddr}
+
+Please note that in case of an error, both the base and overlays are going
+to be invalidated, so keep copies to avoid reloading.
diff --git a/roms/u-boot/doc/usage/fit.rst b/roms/u-boot/doc/usage/fit.rst
new file mode 100644
index 000000000..703743405
--- /dev/null
+++ b/roms/u-boot/doc/usage/fit.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Flat Image Tree (FIT)
+=====================
+
+U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
+images that it it reads and boots. Documentation about FIT is available at
+doc/uImage.FIT
diff --git a/roms/u-boot/doc/usage/for.rst b/roms/u-boot/doc/usage/for.rst
new file mode 100644
index 000000000..f9e504979
--- /dev/null
+++ b/roms/u-boot/doc/usage/for.rst
@@ -0,0 +1,65 @@
+for command
+===========
+
+Synopis
+-------
+
+::
+
+ for <variable> in <items>; do <commands>; done
+
+Description
+-----------
+
+The for command is used to loop over a list of values and execute a series of
+commands for each of these.
+
+The counter variable of the loop is a shell variable. Please, keep in mind that
+an environment variable takes precedence over a shell variable of the same name.
+
+variable
+ name of the counter variable
+
+items
+ space separated item list
+
+commands
+ commands to execute
+
+Example
+-------
+
+::
+
+ => setenv c
+ => for c in 1 2 3; do echo item ${c}; done
+ item 1
+ item 2
+ item 3
+ => echo ${c}
+ 3
+ => setenv c x
+ => for c in 1 2 3; do echo item ${c}; done
+ item x
+ item x
+ item x
+ =>
+
+The first line ensures that there is no environment variable *c*. Hence in the
+first loop the shell variable *c* is printed.
+
+After defining an environment variable of name *c* it takes precedence over the
+shell variable and the environment variable is printed.
+
+Return value
+------------
+
+The return value $? after the done statement is the return value of the last
+statement executed in the loop.
+
+::
+
+ => for i in true false; do ${i}; done; echo $?
+ 1
+ => for i in false true; do ${i}; done; echo $?
+ 0
diff --git a/roms/u-boot/doc/usage/index.rst b/roms/u-boot/doc/usage/index.rst
new file mode 100644
index 000000000..40b796a3a
--- /dev/null
+++ b/roms/u-boot/doc/usage/index.rst
@@ -0,0 +1,48 @@
+Use U-Boot
+==========
+
+.. toctree::
+ :maxdepth: 1
+
+ dfu
+ fdt_overlays
+ fit
+ netconsole
+ partitions
+
+Shell commands
+--------------
+
+.. toctree::
+ :maxdepth: 1
+
+ addrmap
+ askenv
+ base
+ bootefi
+ booti
+ bootmenu
+ button
+ x86/cbsysinfo
+ conitrace
+ echo
+ exception
+ extension
+ exit
+ false
+ fatinfo
+ for
+ load
+ loady
+ mbr
+ md
+ mmc
+ pinmux
+ pstore
+ qfw
+ reset
+ sbi
+ scp03
+ size
+ true
+ ums
diff --git a/roms/u-boot/doc/usage/load.rst b/roms/u-boot/doc/usage/load.rst
new file mode 100644
index 000000000..1efee7731
--- /dev/null
+++ b/roms/u-boot/doc/usage/load.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+load command
+============
+
+Synopsis
+--------
+
+::
+
+ load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
+
+Description
+-----------
+
+The load command is used to read a file from a filesystem into memory.
+
+The number of transferred bytes is saved in the environment variable filesize.
+The load address is saved in the environment variable fileaddr.
+
+interface
+ interface for accessing the block device (mmc, sata, scsi, usb, ....)
+
+dev
+ device number
+
+part
+ partition number, defaults to 0 (whole device)
+
+addr
+ load address, defaults to environment variable loadaddr or if loadaddr is
+ not set to configuration variable CONFIG_SYS_LOAD_ADDR
+
+filename
+ path to file, defaults to environment variable bootfile
+
+bytes
+ maximum number of bytes to load
+
+pos
+ number of bytes to skip
+
+addr, bytes, pos are hexadecimal numbers.
+
+Example
+-------
+
+::
+
+ => load mmc 0:1 ${kernel_addr_r} snp.efi
+ 149280 bytes read in 11 ms (12.9 MiB/s)
+ =>
+ => load mmc 0:1 ${kernel_addr_r} snp.efi 1000000
+ 149280 bytes read in 9 ms (15.8 MiB/s)
+ =>
+ => load mmc 0:1 ${kernel_addr_r} snp.efi 1000000 100
+ 149024 bytes read in 10 ms (14.2 MiB/s)
+ =>
+ => load mmc 0:1 ${kernel_addr_r} snp.efi 10
+ 16 bytes read in 1 ms (15.6 KiB/s)
+ =>
+
+Configuration
+-------------
+
+The load command is only available if CONFIG_CMD_FS_GENERIC=y.
+
+Return value
+------------
+
+The return value $? is set to 0 (true) if the file was successfully loaded
+even if the number of bytes is less then the specified length.
+
+If an error occurs, the return value $? is set to 1 (false).
diff --git a/roms/u-boot/doc/usage/loady.rst b/roms/u-boot/doc/usage/loady.rst
new file mode 100644
index 000000000..2819cc72a
--- /dev/null
+++ b/roms/u-boot/doc/usage/loady.rst
@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+loady command
+=============
+
+Synopsis
+--------
+
+::
+
+ loady [addr [baud]]
+
+Description
+-----------
+
+The loady command is used to transfer a file to the device via the serial line
+using the YMODEM protocol.
+
+The number of transferred bytes is saved in environment variable filesize.
+
+addr
+ load address, defaults to environment variable loadaddr or if loadaddr is
+ not set to configuration variable CONFIG_SYS_LOAD_ADDR
+
+baud
+ baud rate for the ymodem transmission. After the transmission the baud
+ rate is reset to the original value.
+
+Example
+-------
+
+In the example below the terminal emulation program picocom was used to
+transfer a file to the device.
+
+After entering the loady command the key sequence <CTRL-A><CTRL-S> is used to
+let picocom prompt for the file name. Picocom invokes the program sz for the
+file transfer.
+
+::
+
+ => loady 80064000 115200
+ ## Ready for binary (ymodem) download to 0x80064000 at 115200 bps...
+ C
+ *** file: BOOTRISCV64.EFI
+ $ sz -b -vv BOOTRISCV64.EFI
+ Sending: BOOTRISCV64.EFI
+ Bytes Sent: 398976 BPS:7883
+ Sending:
+ Ymodem sectors/kbytes sent: 0/ 0k
+ Transfer complete
+
+ *** exit status: 0 ***
+ /1(CAN) packets, 4 retries
+ ## Total Size = 0x0006165f = 398943 Bytes
+ => echo ${filesize}
+ 6165f
+ =>
+
+Configuration
+-------------
+
+The command is only available if CONFIG_CMD_LOADB=y.
+
+Return value
+------------
+
+The return value $? is always 0 (true).
diff --git a/roms/u-boot/doc/usage/mbr.rst b/roms/u-boot/doc/usage/mbr.rst
new file mode 100644
index 000000000..bddf2f612
--- /dev/null
+++ b/roms/u-boot/doc/usage/mbr.rst
@@ -0,0 +1,94 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+mbr command
+===========
+
+Synopsis
+--------
+
+::
+
+ mbr verify [interface] [device no] [partition list]
+ mbr write [interface] [device no] [partition list]
+
+Description
+-----------
+
+The mbr command lets users create or verify the MBR (Master Boot Record)
+partition layout based on the provided text description. The partition
+layout is alternatively read from the 'mbr_parts' environment variable.
+This can be used in scripts to help system image flashing tools to ensure
+proper partition layout.
+
+The syntax of the text description of the partition list is similar to
+the one used by the 'gpt' command.
+
+Supported partition parameters are:
+
+* name (currently ignored)
+* start (partition start offset in bytes)
+* size (in bytes or '-' to expand it to the whole free area)
+* bootable (boolean flag)
+* id (MBR partition type)
+
+If one wants to create more than 4 partitions, an 'Extended' primary
+partition (with 0x05 ID) has to be explicitly provided as a one of the
+first 4 entries.
+
+Here is an example how to create a 6 partitions (3 on the 'extended
+volume'), some of the predefined sizes:
+
+::
+
+ => setenv mbr_parts 'name=boot,start=4M,size=128M,bootable,id=0x0e;
+ name=rootfs,size=3072M,id=0x83;
+ name=system-data,size=512M,id=0x83;
+ name=[ext],size=-,id=0x05;
+ name=user,size=-,id=0x83;
+ name=modules,size=100M,id=0x83;
+ name=ramdisk,size=8M,id=0x83'
+ => mbr write mmc 0
+
+To check if the layout on the MMC #0 storage device matches the provided
+text description one has to issue following command (assuming that
+mbr_parts environment variable is set):
+
+::
+
+ => mbr verify mmc 0
+
+The verify sub-command is especially useful in the system update scripts:
+
+::
+
+ => if mbr verify mmc 0; then
+ echo MBR layout needs to be updated
+ ...
+ fi
+
+The 'mbr write' command returns 0 on success write or 1 on failure.
+
+The 'mbr verify' returns 0 if the layout matches the one on the storage
+device or 1 if not.
+
+Configuration
+-------------
+
+To use the mbr command you must specify CONFIG_CMD_MBR=y.
+
+Return value
+------------
+
+The variable *$?* takes the following values
+
++---+------------------------------+
+| 0 | mbr write was succesful |
++---+------------------------------+
+| 1 | mbr write failed |
++---+------------------------------+
+| 0 | mbr verify was succesful |
++---+------------------------------+
+| 1 | mbr verify was not succesful |
++---+------------------------------+
+|-1 | invalid arguments |
++---+------------------------------+
diff --git a/roms/u-boot/doc/usage/md.rst b/roms/u-boot/doc/usage/md.rst
new file mode 100644
index 000000000..4c1073ea3
--- /dev/null
+++ b/roms/u-boot/doc/usage/md.rst
@@ -0,0 +1,106 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+md command
+==========
+
+Synopis
+-------
+
+::
+
+ md <address>[<data_size>] [<length>]
+
+Description
+-----------
+
+The md command is used to dump the contents of memory. It uses a standard
+format that includes the address, hex data and ASCII display. It supports
+various data sizes and uses the endianness of the target.
+
+The specified data_size and length become the defaults for future memory
+commands commands.
+
+address
+ start address to display
+
+data_size
+ size of each value to display (defaults to .l):
+
+ ========= ===================
+ data_size Output size
+ ========= ===================
+ .b byte
+ .w word (16 bits)
+ .l long (32 bits)
+ .q quadword (64 bits)
+ ========= ===================
+
+length
+ number of values to dump. Defaults to 40 (0d64). Note that this is not
+ the same as the number of bytes, unless .b is used.
+
+Note that the format of 'md.b' can be emulated from linux with::
+
+ # This works but requires using sed to get the extra spaces
+ # <addr> is the address, <f> is the filename
+ xxd -o <addr> -g1 <f> |sed 's/ / /' >bad
+
+ # This uses a single tool but the offset always starts at 0
+ # <f> is the filename
+ hexdump -v -e '"%08.8_ax: " 16/1 "%02x " " "' -e '16/1 "%_p" "\n" ' <f>
+
+
+Example
+-------
+
+::
+
+ => md 10000
+ 00010000: 00010000 00000000 f0f30f00 00005596 .............U..
+ 00010010: 10011010 00000000 10011010 00000000 ................
+ 00010020: 10011050 00000000 b96d4cd8 00007fff P........Lm.....
+ 00010030: 00000000 00000000 f0f30f18 00005596 .............U..
+ 00010040: 10011040 00000000 10011040 00000000 @.......@.......
+ 00010050: b96d4cd8 00007fff 10011020 00000000 .Lm..... .......
+ 00010060: 00000003 000000c3 00000000 00000000 ................
+ 00010070: 00000000 00000000 f0e892f3 00005596 .............U..
+ 00010080: 00000000 000000a1 00000000 00000000 ................
+ 00010090: 00000000 00000000 f0e38aa6 00005596 .............U..
+ 000100a0: 00000000 000000a6 00000022 00000000 ........".......
+ 000100b0: 00000001 00000000 f0e38aa1 00005596 .............U..
+ 000100c0: 00000000 000000be 00000000 00000000 ................
+ 000100d0: 00000000 00000000 00000000 00000000 ................
+ 000100e0: 00000000 00000000 00000000 00000000 ................
+ 000100f0: 00000000 00000000 00000000 00000000 ................
+ => md.b 10000
+ 00010000: 00 00 01 00 00 00 00 00 00 0f f3 f0 96 55 00 00 .............U..
+ 00010010: 10 10 01 10 00 00 00 00 10 10 01 10 00 00 00 00 ................
+ 00010020: 50 10 01 10 00 00 00 00 d8 4c 6d b9 ff 7f 00 00 P........Lm.....
+ 00010030: 00 00 00 00 00 00 00 00 18 0f f3 f0 96 55 00 00 .............U..
+ => md.b 10000 10
+ 00010000: 00 00 01 00 00 00 00 00 00 0f f3 f0 96 55 00 00 .............U..
+ =>
+ 00010010: 10 10 01 10 00 00 00 00 10 10 01 10 00 00 00 00 ................
+ =>
+ 00010020: 50 10 01 10 00 00 00 00 d8 4c 6d b9 ff 7f 00 00 P........Lm.....
+ =>
+ => md.q 10000
+ 00010000: 0000000000010000 00005596f0f30f00 .............U..
+ 00010010: 0000000010011010 0000000010011010 ................
+ 00010020: 0000000010011050 00007fffb96d4cd8 P........Lm.....
+ 00010030: 0000000000000000 00005596f0f30f18 .............U..
+ 00010040: 0000000010011040 0000000010011040 @.......@.......
+ 00010050: 00007fffb96d4cd8 0000000010011020 .Lm..... .......
+ 00010060: 000000c300000003 0000000000000000 ................
+ 00010070: 0000000000000000 00005596f0e892f3 .............U..
+
+The empty commands cause a 'repeat', so that md shows the next available data
+in the same format as before.
+
+
+Return value
+------------
+
+The return value $? is always 0 (true).
+
+
diff --git a/roms/u-boot/doc/usage/mmc.rst b/roms/u-boot/doc/usage/mmc.rst
new file mode 100644
index 000000000..f20efe3d7
--- /dev/null
+++ b/roms/u-boot/doc/usage/mmc.rst
@@ -0,0 +1,215 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+mmc command
+============
+
+Synopsis
+--------
+
+::
+
+ mmc info
+ mmc read addr blk# cnt
+ mmc write addr blk# cnt
+ mmc erase blk# cnt
+ mmc rescan
+ mmc part
+ mmc dev [dev] [part]
+ mmc list
+ mmc wp
+ mmc bootbus <dev> <boot_bus_width> <reset_boot_bus_width> <boot_mode>
+ mmc bootpart-resize <dev> <dev part size MB> <RPMB part size MB>
+ mmc partconf <dev> [[varname] | [<boot_ack> <boot_partition> <partition_access>]]
+ mmc rst-function <dev> <value>
+
+Description
+-----------
+
+The mmc command is used to control MMC(eMMC/SD) device.
+
+The 'mmc info' command displays information (Manufacturer ID, OEM, Name, Bus Speed, Mode, ...) of MMC device.
+
+The 'mmc read' command reads raw data to memory address from MMC device with block offset and count.
+
+The 'mmc write' command writes raw data to MMC device from memory address with block offset and count.
+
+ addr
+ memory address
+ blk#
+ start block offset
+ cnt
+ block count
+
+The 'mmc erase' command erases *cnt* blocks on the MMC device starting at block *blk#*.
+
+ blk#
+ start block offset
+ cnt
+ block count
+
+The 'mmc rescan' command scans the available MMC device.
+
+The 'mmc part' command displays the list available partition on current mmc device.
+
+The 'mmc dev' command shows or set current mmc device.
+
+ dev
+ device number to change
+ part
+ partition number to change
+
+The 'mmc list' command displays the list available devices.
+
+The 'mmc wp' command enables "power on write protect" function for boot partitions.
+
+The 'mmc bootbus' command sets the BOOT_BUS_WIDTH field. (*Refer to eMMC specification*)
+
+ boot_bus_width
+ 0x0
+ x1 (sdr) or x4(ddr) buswidth in boot operation mode (default)
+ 0x1
+ x4 (sdr/ddr) buswidth in boot operation mode
+ 0x2
+ x8 (sdr/ddr) buswidth in boot operation mode
+ 0x3
+ Reserved
+
+ reset_boot_bus_width
+ 0x0
+ Reset buswidth to x1, Single data reate and backward compatible timing after boot operation (default)
+ 0x1
+ Retain BOOT_BUS_WIDTH and BOOT_MODE value after boot operation. This is relevant to Push-pull mode operation only
+
+ boot_mode
+ 0x0
+ Use single data rate + backward compatible timing in boot operation (default)
+ 0x1
+ Use single data rate + High Speed timing in boot operation mode
+ 0x2
+ Use dual data rate in boot operation
+ 0x3
+ Reserved
+
+The 'mmc partconf' command shows or changes PARTITION_CONFIG field.
+
+ varname
+ When showing the PARTITION_CONFIG, an optional environment variable to store the current boot_partition value into.
+ boot_ack
+ boot acknowledge value
+ boot_partition
+ boot partition to enable for boot
+ 0x0
+ Device not boot enabled(default)
+ 0x1
+ Boot partition1 enabled for boot
+ 0x2
+ Boot partition2 enabled for boot
+ 0x7
+ User area enabled for boot
+ others
+ Reserved
+ partition_access
+ partitions to access
+
+The 'mmc bootpart-resize' command changes sizes of boot and RPMB partitions.
+
+ dev
+ device number
+ boot part size MB
+ target size of boot partition
+ RPMB part size MB
+ target size of RPMB partition
+
+The 'mmc rst-function' command changes the RST_n_FUNCTION field.
+**WARNING** : This is a write-once field. (*Refer to eMMC specification*)
+
+ value
+ 0x0
+ RST_n signal is temporarily disabled (default)
+ 0x1
+ RST_n signal is permanently enabled
+ 0x2
+ RST_n signal is permanently disabled
+ 0x3
+ Reserved
+
+
+Examples
+--------
+
+The 'mmc info' command displays device's capabilities:
+::
+
+ => mmc info
+ Device: EXYNOS DWMMC
+ Manufacturer ID: 45
+ OEM: 100
+ Name: SDW16
+ Bus Speed: 52000000
+ Mode: MMC DDR52 (52MHz)
+ Rd Block Len: 512
+ MMC version 5.0
+ High Capacity: Yes
+ Capacity: 14.7 GiB
+ Bus Width: 8-bit DDR
+ Erase Group Size: 512 KiB
+ HC WP Group Size: 8 MiB
+ User Capacity: 14.7 GiB WRREL
+ Boot Capacity: 4 MiB ENH
+ RPMB Capacity: 4 MiB ENH
+ Boot area 0 is not write protected
+ Boot area 1 is not write protected
+
+The raw data can be read/written via 'mmc read/write' command:
+::
+
+ => mmc read 0x40000000 0x5000 0x100
+ MMC read: dev # 0, block # 20480, count 256 ... 256 blocks read: OK
+
+ => mmc write 0x40000000 0x5000 0x10
+ MMC write: dev # 0, block # 20480, count 256 ... 256 blocks written: OK
+
+The partition list can be shown via 'mmc part' command:
+::
+
+ => mmc part
+ Partition Map for MMC device 0 -- Partition Type: DOS
+
+ Part Start Sector Num Sectors UUID Type
+ 1 8192 131072 dff8751a-01 0e Boot
+ 2 139264 6291456 dff8751a-02 83
+ 3 6430720 1048576 dff8751a-03 83
+ 4 7479296 23298048 dff8751a-04 05 Extd
+ 5 7481344 307200 dff8751a-05 83
+ 6 7790592 65536 dff8751a-06 83
+ 7 7858176 16384 dff8751a-07 83
+ 8 7876608 22900736 dff8751a-08 83
+
+The current device can be shown or set via 'mmc dev' command:
+::
+
+ => mmc dev
+ switch to partitions #0, OK
+ mmc0(part0) is current device
+ => mmc dev 2 0
+ switch to partitions #0, OK
+ mmc2 is current device
+
+The list of available devices can be shown via 'mmc list' command:
+::
+
+ => mmc list
+ mmc list
+ EXYNOS DWMMC: 0 (eMMC)
+ EXYNOS DWMMC: 2 (SD)
+
+Configuration
+-------------
+
+The mmc command is only available if CONFIG_CMD_MMC=y.
+Some commands need to enable more configuration.
+
+write, erase
+ CONFIG_MMC_WRITE
+bootbus, bootpart-resize, partconf, rst-function
+ CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/roms/u-boot/doc/usage/netconsole.rst b/roms/u-boot/doc/usage/netconsole.rst
new file mode 100644
index 000000000..0156f0212
--- /dev/null
+++ b/roms/u-boot/doc/usage/netconsole.rst
@@ -0,0 +1,109 @@
+Network console
+===============
+
+In U-Boot, we implemented the networked console via the standard
+"devices" mechanism, which means that you can switch between the
+serial and network input/output devices by adjusting the 'stdin' and
+'stdout' environment variables. To switch to the networked console,
+set either of these variables to "nc". Input and output can be
+switched independently.
+
+The default buffer size can be overridden by setting
+CONFIG_NETCONSOLE_BUFFER_SIZE.
+
+We use an environment variable 'ncip' to set the IP address and the
+port of the destination. The format is <ip_addr>:<port>. If <port> is
+omitted, the value of 6666 is used. If the env var doesn't exist, the
+broadcast address and port 6666 are used. If it is set to an IP
+address of 0 (or 0.0.0.0) then no messages are sent to the network.
+The source / listening port can be configured separately by setting
+the 'ncinport' environment variable and the destination port can be
+configured by setting the 'ncoutport' environment variable.
+
+For example, if your server IP is 192.168.1.1, you could use::
+
+ => setenv nc 'setenv stdout nc;setenv stdin nc'
+ => setenv ncip 192.168.1.1
+ => saveenv
+ => run nc
+
+On the host side, please use this script to access the console
+
+.. code-block:: bash
+
+ tools/netconsole <ip> [port]
+
+The script uses netcat to talk to the board over UDP. It requires you to
+specify the target IP address (or host name, assuming DNS is working). The
+script can be interrupted by pressing ^T (CTRL-T).
+
+Be aware that in some distributives (Fedora Core 5 at least)
+usage of nc has been changed and -l and -p options are considered
+as mutually exclusive. If nc complains about options provided,
+you can just remove the -p option from the script.
+
+It turns out that 'netcat' cannot be used to listen to broadcast
+packets. We developed our own tool 'ncb' (see tools directory) that
+listens to broadcast packets on a given port and dumps them to the
+standard output. It will be built when compiling for a board which
+has CONFIG_NETCONSOLE defined. If the netconsole script can find it
+in PATH or in the same directory, it will be used instead.
+
+For Linux, the network-based console needs special configuration.
+Minimally, the host IP address needs to be specified. This can be
+done either via the kernel command line, or by passing parameters
+while loading the netconsole.o module (when used in a loadable module
+configuration). Please refer to Documentation/networking/logging.txt
+file for the original Ingo Molnar's documentation on how to pass
+parameters to the loadable module.
+
+The format of the kernel command line parameter (for the static
+configuration) is as follows
+
+.. code-block:: bash
+
+ netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
+
+where
+
+src-port
+ source for UDP packets (defaults to 6665)
+
+src-ip
+ source IP to use (defaults to the interface's address)
+
+dev
+ network interface (defaults to eth0)
+
+tgt-port
+ port for logging agent (defaults to 6666)
+
+tgt-ip
+ IP address for logging agent (this is the required parameter)
+
+tgt-macaddr
+ ethernet MAC address for logging agent (defaults to broadcast)
+
+Examples
+
+.. code-block:: bash
+
+ netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
+ netconsole=@/,@192.168.3.1/
+
+Please note that for the Linux networked console to work, the
+ethernet interface has to be up by the time the netconsole driver is
+initialized. This means that in case of static kernel configuration,
+the respective Ethernet interface has to be brought up using the "IP
+Autoconfiguration" kernel feature, which is usually done by defaults
+in the ELDK-NFS-based environment.
+
+To browse the Linux network console output, use the 'netcat' tool invoked
+as follows:
+
+.. code-block:: bash
+
+ nc -u -l -p 6666
+
+Note that unlike the U-Boot implementation the Linux netconsole is
+unidirectional, i. e. you have console output only in Linux.
diff --git a/roms/u-boot/doc/usage/partitions.rst b/roms/u-boot/doc/usage/partitions.rst
new file mode 100644
index 000000000..2c1a12b6b
--- /dev/null
+++ b/roms/u-boot/doc/usage/partitions.rst
@@ -0,0 +1,80 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. _partitions:
+
+Partitions
+==========
+
+Synopsis
+--------
+
+::
+
+ <command> <interface> [devnum][.hwpartnum][:partnum|#partname]
+
+Description
+-----------
+
+Many U-Boot commands allow specifying partitions (or whole disks) using a
+generic syntax.
+
+interface
+ The interface used to access the partition's device, like ``mmc`` or
+ ``scsi``. For a full list of supported interfaces, consult the
+ ``if_typename_str`` array in ``drivers/block/blk-uclass.c``
+
+devnum
+ The device number. This defaults to 0.
+
+hwpartnum
+ The hardware partition number. All devices have at least one hardware
+ partition. On most devices, hardware partition 0 specifies the whole
+ device. On eMMC devices, hardware partition 0 is the user partition,
+ hardware partitions 1 and 2 are the boot partitions, hardware partition
+ 3 is the RPMB partition, and further partitions are general-purpose
+ user-created partitions. The default hardware partition number is 0.
+
+partnum
+ The partition number, starting from 1. The partition number 0 specifies
+ that the whole device is to be used as one "partition."
+
+partname
+ The partition name. This is the partition label for GPT partitions. For
+ MBR partitions, the following syntax is used::
+
+ <devtype><devletter><partnum>
+
+ devtype
+ A device type like ``mmcsd`` or ``hd``. See the
+ ``part_set_generic_name`` function in ``disk/part.c`` for a
+ complete list.
+
+ devletter
+ The device number as an offset from ``a``. For example, device
+ number 2 would have a device letter of ``c``.
+
+ partnum
+ The partition number. This is the same as above.
+
+If neither ``partname`` nor ``partnum`` is specified and there is a partition
+table, then partition 1 is used. If there is no partition table, then the whole
+device is used as one "partition." If none of ``devnum``, ``hwpartnum``,
+``partnum``, or ``partname`` is specified, or only ``-`` is specified, then
+``devnum`` defaults to the value of the ``bootdevice`` environmental variable.
+
+Examples
+--------
+
+List the root directory contents on MMC device 2, hardware partition 1,
+and partition number 3::
+
+ ls mmc 2.1:3 /
+
+Load ``/kernel.itb`` to address ``0x80000000`` from SCSI device 0, hardware partition
+0, and the partition labeled ``boot``::
+
+ load scsi #boot 0x80000000 /kernel.itb
+
+Print the partition UUID of the SATA device ``$bootdevice``, hardware partition
+0, and partition number 0::
+
+ part uuid sata -
diff --git a/roms/u-boot/doc/usage/pinmux.rst b/roms/u-boot/doc/usage/pinmux.rst
new file mode 100644
index 000000000..9f4392cd0
--- /dev/null
+++ b/roms/u-boot/doc/usage/pinmux.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+pinmux command
+==============
+
+Synopsis
+--------
+
+::
+
+ pinmux list
+ pinmux dev [pincontroller-name]
+ pinmux status [-a | pin-name]
+
+Description
+-----------
+
+The pinmux command is used to show the pin-controller muxing.
+
+The 'pinmux list' command diplays the available pin-controller.
+
+The 'pinmux dev' command selects the pin-controller for next commands.
+
+ pincontroller-name
+ name of the pin-controller to select
+
+The 'pinmux status' command displays the pin muxing information.
+
+ \-a
+ display pin muxing of all pin-controllers.
+ pin-name
+ name of the pin to display
+
+Example
+-------
+
+::
+
+ => pinmux list
+ | Device | Driver | Parent
+ | pinctrl-gpio | sandbox_pinctrl_gpio | root_driver
+ | pinctrl | sandbox_pinctrl | root_driver
+ =>
+ => pinmux dev pinctrl
+ dev: pinctrl
+ =>
+ => pinmux status
+ P0 : UART TX.
+ P1 : UART RX.
+ P2 : I2S SCK.
+ P3 : I2S SD.
+ P4 : I2S WS.
+ P5 : GPIO0 bias-pull-up input-disable.
+ P6 : GPIO1 drive-open-drain.
+ P7 : GPIO2 bias-pull-down input-enable.
+ P8 : GPIO3 bias-disable.
+ =>
+ => pinmux status P0
+ P0 : UART TX.
+ =>
+ => pinmux status -a
+ --------------------------
+ pinctrl-gpio:
+ a0 : gpio input .
+ a1 : gpio input .
+ a2 : gpio input .
+ a3 : gpio input .
+ a4 : gpio input .
+ a5 : gpio output .
+ a6 : gpio output .
+ a7 : gpio input .
+ a8 : gpio input .
+ a9 : gpio input .
+ --------------------------
+ pinctrl:
+ P0 : UART TX.
+ P1 : UART RX.
+ P2 : I2S SCK.
+ P3 : I2S SD.
+ P4 : I2S WS.
+ P5 : GPIO0 bias-pull-up input-disable.
+ P6 : GPIO1 drive-open-drain.
+ P7 : GPIO2 bias-pull-down input-enable.
+ P8 : GPIO3 bias-disable.
+
+Configuration
+-------------
+
+The pinmux command is only available if CONFIG_CMD_PINMUX=y.
+
+Return value
+------------
+
+The return value $? is set to 0 (true) if the command succeded and to 1 (false)
+otherwise.
diff --git a/roms/u-boot/doc/usage/pstore.rst b/roms/u-boot/doc/usage/pstore.rst
new file mode 100644
index 000000000..1c8374513
--- /dev/null
+++ b/roms/u-boot/doc/usage/pstore.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+pstore command
+==============
+
+Synopsis
+--------
+
+::
+
+ pstore set <addr> <len> [record-size] [console-size] [ftrace-size] [pmsg_size] [ecc-size]
+ pstore display [record-type] [nb]
+ pstore save <interface> <dev[:part]> <directory-path>
+
+Design
+------
+
+Linux PStore and Ramoops modules (Linux config options PSTORE and PSTORE_RAM)
+allow to use memory to pass data from the dying breath of a crashing kernel to
+its successor. This command allows to read those records from U-Boot command
+line.
+
+Ramoops is an oops/panic logger that writes its logs to RAM before the system
+crashes. It works by logging oopses and panics in a circular buffer. Ramoops
+needs a system with persistent RAM so that the content of that area can survive
+after a restart.
+
+Ramoops uses a predefined memory area to store the dump.
+
+Ramoops parameters can be passed as kernel parameters or through Device Tree,
+i.e.::
+
+ ramoops.mem_address=0x30000000 ramoops.mem_size=0x100000 ramoops.record_size=0x2000 ramoops.console_size=0x2000 memmap=0x100000$0x30000000
+
+The same values should be set in U-Boot to be able to retrieve the records.
+This values can be set at build time in U-Boot configuration file, or at runtime.
+U-Boot automatically patches the Device Tree to pass the Ramoops parameters to
+the kernel.
+
+The PStore configuration parameters are:
+
+======================= ==========
+ Name Default
+======================= ==========
+CMD_PSTORE_MEM_ADDR
+CMD_PSTORE_MEM_SIZE 0x10000
+CMD_PSTORE_RECORD_SIZE 0x1000
+CMD_PSTORE_CONSOLE_SIZE 0x1000
+CMD_PSTORE_FTRACE_SIZE 0x1000
+CMD_PSTORE_PMSG_SIZE 0x1000
+CMD_PSTORE_ECC_SIZE 0
+======================= ==========
+
+Records sizes should be a power of 2.
+The memory size and the record/console size must be non-zero.
+
+Multiple 'dump' records can be stored in the memory reserved for PStore.
+The memory size has to be larger than the sum of the record sizes, i.e.::
+
+ MEM_SIZE >= RECORD_SIZE * n + CONSOLE_SIZE + FTRACE_SIZE + PMSG_SIZE
+
+Usage
+-----
+
+Generate kernel crash
+~~~~~~~~~~~~~~~~~~~~~
+
+For test purpose, you can generate a kernel crash by setting reboot timeout to
+10 seconds and trigger a panic
+
+.. code-block:: console
+
+ $ sudo sh -c "echo 1 > /proc/sys/kernel/sysrq"
+ $ sudo sh -c "echo 10 > /proc/sys/kernel/panic"
+ $ sudo sh -c "echo c > /proc/sysrq-trigger"
+
+Retrieve logs in U-Boot
+~~~~~~~~~~~~~~~~~~~~~~~
+
+First of all, unless PStore parameters as been set during U-Boot configuration
+and match kernel ramoops parameters, it needs to be set using 'pstore set', e.g.::
+
+ => pstore set 0x30000000 0x100000 0x2000 0x2000
+
+Then all available dumps can be displayed
+using::
+
+ => pstore display
+
+Or saved to an existing directory in an Ext2 or Ext4 partition, e.g. on root
+directory of 1st partition of the 2nd MMC::
+
+ => pstore save mmc 1:1 /
diff --git a/roms/u-boot/doc/usage/qfw.rst b/roms/u-boot/doc/usage/qfw.rst
new file mode 100644
index 000000000..87463e1e5
--- /dev/null
+++ b/roms/u-boot/doc/usage/qfw.rst
@@ -0,0 +1,89 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+qfw command
+===========
+
+Synopsis
+--------
+
+::
+
+ qfw list
+ qfw cpus
+ qfw load [kernel_addr [initrd_addr]]
+
+Description
+-----------
+
+The *qfw* command is used to retrieve information form the QEMU firmware.
+
+The *qfw list* sub-command displays the QEMU firmware files.
+
+The *qfw cpus* sub-command displays the available CPUs.
+
+The *qfw load* command is used to load a kernel and an initial RAM disk.
+
+kernel_addr
+ address to which the file specified by the -kernel parameter of QEMU shall
+ be loaded. Defaults to environment variable *loadaddr* and further to
+ the value of *CONFIG_LOADADDR*.
+
+initrd_addr
+ address to which the file specified by the -initrd parameter of QEMU shall
+ be loaded. Defaults to environment variable *ramdiskaddr* and further to
+ the value of *CONFIG_RAMDISK_ADDR*.
+
+Examples
+--------
+
+QEMU firmware files are listed via the *qfw list* command:
+
+::
+
+ => qfw list
+ etc/boot-fail-wait
+ etc/smbios/smbios-tables
+ etc/smbios/smbios-anchor
+ etc/e820
+ genroms/kvmvapic.bin
+ genroms/linuxboot.bin
+ etc/system-states
+ etc/acpi/tables
+ etc/table-loader
+ etc/tpm/log
+ etc/acpi/rsdp
+ bootorder
+
+The available CPUs can be shown via the *qfw cpus* command:
+
+::
+
+ => qfw cpu
+ 2 cpu(s) online
+
+The *-kernel* and *-initrd* parameters allow to specify a kernel and an
+initial RAM disk for QEMU:
+
+.. code-block:: bash
+
+ $ qemu-system-x86_64 -machine pc-i440fx-2.5 -bios u-boot.rom -m 1G \
+ -nographic -kernel vmlinuz -initrd initrd
+
+Now the kernel and the initial RAM disk can be loaded to the U-Boot memory via
+the *qfw load* command and booted thereafter.
+
+::
+
+ => qfw load ${kernel_addr_r} ${ramdisk_addr_r}
+ loading kernel to address 0000000001000000 size 5048f0 initrd 0000000004000000 size 3c94891
+ => zboot 1000000 5048f0 4000000 3c94891
+ Valid Boot Flag
+ Magic signature found
+ Linux kernel version 4.19.0-14-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 4.19.171-2 (2021-01-30)
+ Building boot_params at 0x00090000
+ Loading bzImage at address 100000 (5260160 bytes)
+
+Configuration
+-------------
+
+The qfw command is only available if CONFIG_CMD_QFW=y.
diff --git a/roms/u-boot/doc/usage/reset.rst b/roms/u-boot/doc/usage/reset.rst
new file mode 100644
index 000000000..384d5d60f
--- /dev/null
+++ b/roms/u-boot/doc/usage/reset.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+reset command
+=============
+
+Synopsis
+--------
+
+::
+
+ reset [-w]
+
+Description
+-----------
+
+Perform reset of the CPU. By default does COLD reset, which resets CPU,
+DDR and peripherals, on some boards also resets external PMIC.
+
+-w
+ Do warm WARM, reset CPU but keep peripheral/DDR/PMIC active.
+
+
+Return value
+------------
+
+The return value $? is always set to 0 (true).
diff --git a/roms/u-boot/doc/usage/sbi.rst b/roms/u-boot/doc/usage/sbi.rst
new file mode 100644
index 000000000..96d886105
--- /dev/null
+++ b/roms/u-boot/doc/usage/sbi.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+sbi command
+===========
+
+Synopsis
+--------
+
+::
+
+ sbi
+
+Description
+-----------
+
+The sbi command is used to display information about the SBI (Supervisor Binary
+Interface) implementation on RISC-V systems.
+
+The output may look like:
+
+::
+
+ => sbi
+ SBI 0.2
+ OpenSBI
+ Extensions:
+ sbi_set_timer
+ sbi_console_putchar
+ sbi_console_getchar
+ sbi_clear_ipi
+ sbi_send_ipi
+ sbi_remote_fence_i
+ sbi_remote_sfence_vma
+ sbi_remote_sfence_vma_asid
+ sbi_shutdown
+ SBI Base Functionality
+ Timer Extension
+ IPI Extension
+ RFENCE Extension
+ Hart State Management Extension
+
+The first line indicates the version of the RISC-V SBI specification.
+The second line indicates the implementation.
+The further lines enumerate the implemented extensions.
+
+Configuration
+-------------
+
+To use the sbi command you must specify CONFIG_CMD_SBI=y.
diff --git a/roms/u-boot/doc/usage/scp03.rst b/roms/u-boot/doc/usage/scp03.rst
new file mode 100644
index 000000000..7ff87ed85
--- /dev/null
+++ b/roms/u-boot/doc/usage/scp03.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+scp03 command
+=============
+
+Synopsis
+--------
+
+::
+
+ scp03 enable
+ scp03 provision
+
+Description
+-----------
+
+The *scp03* command calls into a Trusted Application executing in a
+Trusted Execution Environment to enable (if present) the Secure
+Channel Protocol 03 stablished between the processor and the secure
+element.
+
+This protocol encrypts all the communication between the processor and
+the secure element using a set of pre-defined keys. These keys can be
+rotated (provisioned) using the *provision* request.
+
+See also
+--------
+
+For some information on the internals implemented in the TEE, please
+check the GlobalPlatform documentation on `Secure Channel Protocol '03'`_
+
+.. _Secure Channel Protocol '03':
+ https://globalplatform.org/wp-content/uploads/2014/07/GPC_2.3_D_SCP03_v1.1.2_PublicRelease.pdf
diff --git a/roms/u-boot/doc/usage/size.rst b/roms/u-boot/doc/usage/size.rst
new file mode 100644
index 000000000..f0c35e482
--- /dev/null
+++ b/roms/u-boot/doc/usage/size.rst
@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+size command
+============
+
+Synopsis
+--------
+
+::
+
+ size <interface> <dev[:part]> <filename>
+
+Description
+-----------
+
+The size command determines the size of a file and sets the environment variable
+filesize to this value. If filename points to a directory, the value is set to
+zero.
+
+If the command fails, the filesize environment variable is not changed.
+
+dev
+ device number
+
+part
+ partition number, defaults to 1
+
+filename
+ path to file
+
+Configuration
+-------------
+
+The size command is only available if CONFIG_CMD_FS_GENERIC=y.
+
+Return value
+------------
+
+The return value $? is set to 0 (true) if the command succeded and to 1 (false)
+otherwise.
diff --git a/roms/u-boot/doc/usage/true.rst b/roms/u-boot/doc/usage/true.rst
new file mode 100644
index 000000000..f9ef71b2d
--- /dev/null
+++ b/roms/u-boot/doc/usage/true.rst
@@ -0,0 +1,28 @@
+true command
+============
+
+Synopsis
+--------
+
+::
+
+ true
+
+Description
+-----------
+
+The true command sets the return value $? to 0 (true).
+
+Example
+-------
+
+::
+
+ => true; echo $?
+ 0
+ =>
+
+Configuration
+-------------
+
+The true command is only available if CONFIG_HUSH_PARSER=y.
diff --git a/roms/u-boot/doc/usage/ums.rst b/roms/u-boot/doc/usage/ums.rst
new file mode 100644
index 000000000..3cde5fa1f
--- /dev/null
+++ b/roms/u-boot/doc/usage/ums.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+ums command
+===========
+
+Synopsis
+--------
+
+::
+
+ ums <dev> [<interface>] <devnum[:partnum]>
+
+Description
+-----------
+
+Use the USB Mass Storage class (also known as UMS) to make accessible an U-Boot
+block device (fully or with :ref:`U-Boot's partition syntax <partitions>`)
+to a USB host and to enable file transfers. U-Boot, the USB device, acts as a
+simple external hard drive plugged on the host USB port.
+
+This command "ums" stays in the USB's treatment loop until user enters Ctrl-C.
+
+dev
+ USB gadget device number
+
+interface
+ interface for accessing the block device (mmc, sata, scsi, usb, ....)
+ defaults is "mmc"
+
+devnum
+ device number for selected interface
+
+partnum
+ partition number or 0 to expose all partitions, defaults to 0
+
+Example
+-------
+
+::
+
+ => ums 0 mmc 0
+ => ums 0 usb 1:2
+
+Configuration
+-------------
+
+The ums command is only available if CONFIG_CMD_USB_MASS_STORAGE=y
+and depends on CONFIG_USB_USB_GADGET and CONFIG_BLK.
+
+Return value
+------------
+
+The return value $? is set to 0 (true) when the USB stack was successfully
+started and interrupted, with Ctrl-C or after USB cable issue (detection
+timeout or cable removal).
+
+If an error occurs, the return value $? is set to 1 (false).
diff --git a/roms/u-boot/doc/usage/x86/cbsysinfo.rst b/roms/u-boot/doc/usage/x86/cbsysinfo.rst
new file mode 100644
index 000000000..8c03a8516
--- /dev/null
+++ b/roms/u-boot/doc/usage/x86/cbsysinfo.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+cbsysinfo
+=========
+
+Synopis
+-------
+
+::
+
+ cbsysinfo
+
+
+Description
+-----------
+
+This displays information obtained from the coreboot sysinfo table. It is only
+useful when booting U-Boot from coreboot.
+
+Example
+-------
+
+::
+
+ => cbsysinfo