diff options
Diffstat (limited to 'qemu/roms/u-boot/doc')
189 files changed, 0 insertions, 18286 deletions
diff --git a/qemu/roms/u-boot/doc/DocBook/.gitignore b/qemu/roms/u-boot/doc/DocBook/.gitignore deleted file mode 100644 index 7ebd5465d..000000000 --- a/qemu/roms/u-boot/doc/DocBook/.gitignore +++ /dev/null @@ -1,15 +0,0 @@ -*.xml -*.ps -*.pdf -*.html -*.9.gz -*.9 -*.aux -*.dvi -*.log -*.out -*.png -*.gif -*.svg -media-indices.tmpl -media-entities.tmpl diff --git a/qemu/roms/u-boot/doc/DocBook/Makefile b/qemu/roms/u-boot/doc/DocBook/Makefile deleted file mode 100644 index 593237f04..000000000 --- a/qemu/roms/u-boot/doc/DocBook/Makefile +++ /dev/null @@ -1,221 +0,0 @@ -### -# This makefile is used to generate the kernel documentation, -# primarily based on in-line comments in various source files. -# See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how -# to document the SRC - and how to read it. -# To add a new book the only step required is to add the book to the -# list of DOCBOOKS. - -DOCBOOKS := linker_lists.xml stdio.xml - -### -# The build process is as follows (targets): -# (xmldocs) [by docproc] -# file.tmpl --> file.xml +--> file.ps (psdocs) [by db2ps or xmlto] -# +--> file.pdf (pdfdocs) [by db2pdf or xmlto] -# +--> DIR=file (htmldocs) [by xmlto] -# +--> man/ (mandocs) [by xmlto] - - -# for PDF and PS output you can choose between xmlto and docbook-utils tools -PDF_METHOD = $(prefer-db2x) -PS_METHOD = $(prefer-db2x) - - -### -# The targets that may be used. -PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs - -targets += $(DOCBOOKS) -BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) -xmldocs: $(BOOKS) -sgmldocs: xmldocs - -PS := $(patsubst %.xml, %.ps, $(BOOKS)) -psdocs: $(PS) - -PDF := $(patsubst %.xml, %.pdf, $(BOOKS)) -pdfdocs: $(PDF) - -HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) -htmldocs: $(HTML) - $(call build_main_index) - $(call build_images) - $(call install_media_images) - -MAN := $(patsubst %.xml, %.9, $(BOOKS)) -mandocs: $(MAN) - $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9) - -installmandocs: mandocs - mkdir -p /usr/local/man/man9/ - install $(obj)/man/*.9.gz /usr/local/man/man9/ - -### -#External programs used -KERNELDOC = $(srctree)/scripts/kernel-doc -DOCPROC = $(objtree)/scripts/docproc - -XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl -XMLTOFLAGS += --skip-validation - -### -# DOCPROC is used for two purposes: -# 1) To generate a dependency list for a .tmpl file -# 2) To preprocess a .tmpl file and call kernel-doc with -# appropriate parameters. -# The following rules are used to generate the .xml documentation -# required to generate the final targets. (ps, pdf, html). -quiet_cmd_docproc = DOCPROC $@ - cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@ -define rule_docproc - set -e; \ - $(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';) \ - $(cmd_$(1)); \ - ( \ - echo 'cmd_$@ := $(cmd_$(1))'; \ - echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`; \ - ) > $(dir $@).$(notdir $@).cmd -endef - -%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE - $(call if_changed_rule,docproc) - -# Tell kbuild to always build the programs -always := $(hostprogs-y) - -notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \ - exit 1 -db2xtemplate = db2TYPE -o $(dir $@) $< -xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $< - -# determine which methods are available -ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found) - use-db2x = db2x - prefer-db2x = db2x -else - use-db2x = notfound - prefer-db2x = $(use-xmlto) -endif -ifeq ($(shell which xmlto >/dev/null 2>&1 && echo found),found) - use-xmlto = xmlto - prefer-xmlto = xmlto -else - use-xmlto = notfound - prefer-xmlto = $(use-db2x) -endif - -# the commands, generated from the chosen template -quiet_cmd_db2ps = PS $@ - cmd_db2ps = $(subst TYPE,ps, $($(PS_METHOD)template)) -%.ps : %.xml - $(call cmd,db2ps) - -quiet_cmd_db2pdf = PDF $@ - cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template)) -%.pdf : %.xml - $(call cmd,db2pdf) - - -index = index.html -main_idx = $(obj)/$(index) -build_main_index = rm -rf $(main_idx); \ - echo '<h1>U-Boot Bootloader HTML Documentation</h1>' >> $(main_idx) && \ - echo '<h2>U-Boot Version: $(UBOOTVERSION)</h2>' >> $(main_idx) && \ - cat $(HTML) >> $(main_idx) - -quiet_cmd_db2html = HTML $@ - cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ - echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \ - $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ - -%.html: %.xml - @(which xmlto > /dev/null 2>&1) || \ - (echo "*** You need to install xmlto ***"; \ - exit 1) - @rm -rf $@ $(patsubst %.html,%,$@) - $(call cmd,db2html) - @if [ ! -z "$(PNG-$(basename $(notdir $@)))" ]; then \ - cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi - -quiet_cmd_db2man = MAN $@ - cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi -%.9 : %.xml - @(which xmlto > /dev/null 2>&1) || \ - (echo "*** You need to install xmlto ***"; \ - exit 1) - $(Q)mkdir -p $(obj)/man - $(call cmd,db2man) - @touch $@ - -### -# Rules to generate postscripts and PNG images from .fig format files -quiet_cmd_fig2eps = FIG2EPS $@ - cmd_fig2eps = fig2dev -Leps $< $@ - -%.eps: %.fig - @(which fig2dev > /dev/null 2>&1) || \ - (echo "*** You need to install transfig ***"; \ - exit 1) - $(call cmd,fig2eps) - -quiet_cmd_fig2png = FIG2PNG $@ - cmd_fig2png = fig2dev -Lpng $< $@ - -%.png: %.fig - @(which fig2dev > /dev/null 2>&1) || \ - (echo "*** You need to install transfig ***"; \ - exit 1) - $(call cmd,fig2png) - -### -# Rule to convert a .c file to inline XML documentation - gen_xml = : - quiet_gen_xml = echo ' GEN $@' -silent_gen_xml = : -%.xml: %.c - @$($(quiet)gen_xml) - @( \ - echo "<programlisting>"; \ - expand --tabs=8 < $< | \ - sed -e "s/&/\\&/g" \ - -e "s/</\\</g" \ - -e "s/>/\\>/g"; \ - echo "</programlisting>") > $@ - -### -# Help targets as used by the top-level makefile -dochelp: - @echo ' U-Boot bootloader internal documentation in different formats:' - @echo ' htmldocs - HTML' - @echo ' pdfdocs - PDF' - @echo ' psdocs - Postscript' - @echo ' xmldocs - XML DocBook' - @echo ' mandocs - man pages' - @echo ' installmandocs - install man pages generated by mandocs' - @echo ' cleandocs - clean all generated DocBook files' - -### -# Temporary files left by various tools -clean-files := $(DOCBOOKS) \ - $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ - $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ - $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ - $(patsubst %.xml, %.log, $(DOCBOOKS)) \ - $(patsubst %.xml, %.out, $(DOCBOOKS)) \ - $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ - $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ - $(patsubst %.xml, %.html, $(DOCBOOKS)) \ - $(patsubst %.xml, %.9, $(DOCBOOKS)) \ - $(index) - -clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man - -cleandocs: - $(Q)rm -f $(call objectify, $(clean-files)) - $(Q)rm -rf $(call objectify, $(clean-dirs)) - -# Declare the contents of the .PHONY variable as phony. We keep that -# information in a variable se we can use it in if_changed and friends. - -.PHONY: $(PHONY) diff --git a/qemu/roms/u-boot/doc/DocBook/docbook.css b/qemu/roms/u-boot/doc/DocBook/docbook.css deleted file mode 100644 index 7a79ec54b..000000000 --- a/qemu/roms/u-boot/doc/DocBook/docbook.css +++ /dev/null @@ -1,16 +0,0 @@ -body { - font-family: sans-serif; -} - -.programlisting { - font-family: monospace; - font-size: 1em; - display: block; - padding: 10px; - border: 1px solid #aaa; - color: #000; - background-color: #eee; - overflow: auto; - margin: 1em 0em; - border-radius: 6px; -} diff --git a/qemu/roms/u-boot/doc/DocBook/linker_lists.tmpl b/qemu/roms/u-boot/doc/DocBook/linker_lists.tmpl deleted file mode 100644 index f1975165d..000000000 --- a/qemu/roms/u-boot/doc/DocBook/linker_lists.tmpl +++ /dev/null @@ -1,46 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> - -<book id="UBootLGArrays"> - <bookinfo> - <title>The U-Boot Linker-Generated Arrays</title> - - <legalnotice> - <para> - This documentation is free software; you can redistribute - it and/or modify it under the terms of the GNU General Public - License as published by the Free Software Foundation; either - version 2 of the License, or (at your option) any later - version. - </para> - - <para> - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details. - </para> - - <para> - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - </para> - - <para> - For more details see the file COPYING in the source - distribution of U-Boot Bootloader. - </para> - </legalnotice> - </bookinfo> - -<toc></toc> - - <chapter id="adt"> - <title>Linker-Generated Arrays</title> -!Iinclude/linker_lists.h - </chapter> - -</book> diff --git a/qemu/roms/u-boot/doc/DocBook/stdio.tmpl b/qemu/roms/u-boot/doc/DocBook/stdio.tmpl deleted file mode 100644 index 4783abb0a..000000000 --- a/qemu/roms/u-boot/doc/DocBook/stdio.tmpl +++ /dev/null @@ -1,46 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> - -<book id="UBootSTDIO"> - <bookinfo> - <title>The U-Boot STDIO subsystem</title> - - <legalnotice> - <para> - This documentation is free software; you can redistribute - it and/or modify it under the terms of the GNU General Public - License as published by the Free Software Foundation; either - version 2 of the License, or (at your option) any later - version. - </para> - - <para> - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - See the GNU General Public License for more details. - </para> - - <para> - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - </para> - - <para> - For more details see the file COPYING in the source - distribution of U-Boot Bootloader. - </para> - </legalnotice> - </bookinfo> - -<toc></toc> - - <chapter id="adt"> - <title>U-Boot Serial subsystem</title> -!Idrivers/serial/serial.c - </chapter> - -</book> diff --git a/qemu/roms/u-boot/doc/DocBook/stylesheet.xsl b/qemu/roms/u-boot/doc/DocBook/stylesheet.xsl deleted file mode 100644 index 85b252751..000000000 --- a/qemu/roms/u-boot/doc/DocBook/stylesheet.xsl +++ /dev/null @@ -1,10 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0"> -<param name="chunk.quietly">1</param> -<param name="funcsynopsis.style">ansi</param> -<param name="funcsynopsis.tabular.threshold">80</param> -<param name="callout.graphics">0</param> -<!-- <param name="paper.type">A4</param> --> -<param name="generate.section.toc.level">2</param> -<param name="use.id.as.filename">1</param> -</stylesheet> diff --git a/qemu/roms/u-boot/doc/I2C_Edge_Conditions b/qemu/roms/u-boot/doc/I2C_Edge_Conditions deleted file mode 100644 index f4a996870..000000000 --- a/qemu/roms/u-boot/doc/I2C_Edge_Conditions +++ /dev/null @@ -1,46 +0,0 @@ -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/qemu/roms/u-boot/doc/README.440-DDR-performance b/qemu/roms/u-boot/doc/README.440-DDR-performance deleted file mode 100644 index 17bc74764..000000000 --- a/qemu/roms/u-boot/doc/README.440-DDR-performance +++ /dev/null @@ -1,90 +0,0 @@ -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/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup b/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup deleted file mode 100644 index 901bd875c..000000000 --- a/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup +++ /dev/null @@ -1,31 +0,0 @@ ---------------------------------------------------------------------- -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/qemu/roms/u-boot/doc/README.ARC b/qemu/roms/u-boot/doc/README.ARC deleted file mode 100644 index 5f414fb2f..000000000 --- a/qemu/roms/u-boot/doc/README.ARC +++ /dev/null @@ -1,27 +0,0 @@ -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/qemu/roms/u-boot/doc/README.ARM-SoC b/qemu/roms/u-boot/doc/README.ARM-SoC deleted file mode 100644 index d6bd62488..000000000 --- a/qemu/roms/u-boot/doc/README.ARM-SoC +++ /dev/null @@ -1,31 +0,0 @@ -[By Steven Scholz <steven.scholz@imc-berlin.de>, 16 Aug 2004] - -Since the cpu/ directory gets clobbered with peripheral driver code I -started cleaning up arch/arm/cpu/arm920t. - -I introduced the concept of Soc (system on a chip) into the ./cpu -directory. That means that code that is cpu (i.e. core) specific -resides in - - $(CPUDIR)/ - -and code that is specific to some SoC (i.e. vendor specific -peripherals around the core) is moved into - - $(CPUDIR)/$(SOC)/ - -Thus a library/archive "$(CPUDIR)/$(SOC)/lib$(SOC).a" will be build -and linked. Examples will be - - arch/arm/cpu/arm920t/imx/ - arch/arm/cpu/arm920t/s3c24x0 - -One can select an SoC by passing the name of it to ./mkconfig just -like - - @./mkconfig $(@:_config=) arm arm920t vcma9 mpl s3c24x0 - -If there's no VENDOR field (like "mpl" in the above line) one has to -pass NULL instead: - - @./mkconfig $(@:_config=) arm arm920t mx1ads NULL imx diff --git a/qemu/roms/u-boot/doc/README.ARM-memory-map b/qemu/roms/u-boot/doc/README.ARM-memory-map deleted file mode 100644 index 1b120ac3e..000000000 --- a/qemu/roms/u-boot/doc/README.ARM-memory-map +++ /dev/null @@ -1,17 +0,0 @@ -Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour -From: "Anders Larsen" <alarsen@rea.de> -Date: Thu, 18 Sep 2003 14:15:21 +0200 -To: Wolfgang Denk <wd@denx.de> - -... ->I still see references to _armboot_start, _armboot_end_data, and ->_armboot_end - which role do these play now? Can we get rid of them? -> ->How are they (should they be) set in your memory map above? - -_armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E0000); it seems -CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in -different parts of the (ARM) code. -Furthermore, the startup code (cpu/<arm>/start.S) internally uses -another variable (_TEXT_BASE) with the same content as _armboot_start. -I agree that this mess should be cleaned up. diff --git a/qemu/roms/u-boot/doc/README.AVR32 b/qemu/roms/u-boot/doc/README.AVR32 deleted file mode 100644 index 632cc0546..000000000 --- a/qemu/roms/u-boot/doc/README.AVR32 +++ /dev/null @@ -1,25 +0,0 @@ -AVR32 is a new high-performance 32-bit RISC microprocessor core, -designed for cost-sensitive embedded applications, with particular -emphasis on low power consumption and high code density. The AVR32 -architecture is not binary compatible with earlier 8-bit AVR -architectures. - -The AVR32 architecture, including the instruction set, is described -by the AVR32 Architecture Manual, available from - -http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf - -A GNU toolchain with support for AVR32, along with non-GNU programming -and debugging support, can be downloaded from - -http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118 - -A full set of u-boot, kernel and filesystem images can be built using -buildroot. This will also produce a working toolchain which can be -used instead of the official GNU toolchain above. A customized version -of buildroot for AVR32 can be downloaded here: - -http://www.atmel.no/buildroot/ - -The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and -other associated software are actively supported by Atmel Corporation. diff --git a/qemu/roms/u-boot/doc/README.AVR32-port-muxing b/qemu/roms/u-boot/doc/README.AVR32-port-muxing deleted file mode 100644 index 8c1718cdc..000000000 --- a/qemu/roms/u-boot/doc/README.AVR32-port-muxing +++ /dev/null @@ -1,208 +0,0 @@ -AVR32 Port multiplexer configuration -==================================== - -On AVR32 chips, most external I/O pins are routed through a port -multiplexer. There are currently two kinds of port multiplexer -hardware around with different register interfaces: - - * PIO (AT32AP700x; this is also used on ARM AT91 chips) - * GPIO (all other AVR32 chips) - -The "PIO" variant supports multiplexing up to two peripherals per pin -in addition to GPIO (software control). Each pin has configurable -pull-up, glitch filter, interrupt and multi-drive capabilities. - -The "GPIO" variant supports multiplexing up to four peripherals per -pin in addition to GPIO. Each pin has configurable -pull-up/pull-down/buskeeper, glitch filter, interrupt, open-drain and -schmitt-trigger capabilities, as well as configurable drive strength -and slew rate control. - -Both controllers are configured using the same API, but the functions -may accept different values for some parameters depending on the -actual portmux implementation, and some parameters may be ignored by -one of the implementation (e.g. the "PIO" implementation will ignore -the drive strength flags since the hardware doesn't support -configurable drive strength.) - -Selecting the portmux implementation ------------------------------------- -Since u-boot is lacking a Kconfig-style configuration engine, the -portmux implementation must be selected manually by defining one of -the following symbols: - - CONFIG_PORTMUX_PIO - CONFIG_PORTMUX_GPIO - -depending on which implementation the chip in question uses. - -Identifying pins ----------------- -The portmux configuration functions described below identify the pins -to act on based on two parameters: A "port" (i.e. a block of pins -that somehow belong together) and a pin mask. Both are defined in an -implementation-specific manner. - -The available ports are defined on the form - - #define PORTMUX_PORT_A (something) - -where "A" matches the identifier given in the chip's data sheet, and -"something" is whatever the portmux implementation needs to identify -the port (usually a memory address). - -The pin mask is a bitmask where each '1' bit indicates a pin to apply -the current operation to. The width of the bitmask may vary from port -to port, but it is never wider than 32 bits (which is the width of -'unsigned long' on avr32). - -Selecting functions -------------------- -Each pin can either be assigned to one of a predefined set of on-chip -peripherals, or it can be set up to be controlled by software. For the -former case, the portmux implementation defines an enum containing all -the possible peripheral functions that can be selected. For example, -the PIO implementation, which allows multiplexing two peripherals per -pin, defines it like this: - - enum portmux_function { - PORTMUX_FUNC_A, - PORTMUX_FUNC_B, - }; - -To configure a set of pins to be connected to a given peripheral -function, the following function is used. - - void portmux_select_peripheral(void *port, unsigned long pin_mask, - enum portmux_function func, unsigned long flags); - -To configure a set of pins to be controlled by software (GPIO), the -following function is used. In this case, no "function" argument is -required since "GPIO" is a function in its own right. - - void portmux_select_gpio(void *port, unsigned int pin_mask, - unsigned long flags); - -Both of these functions take a "flags" parameter which may be used to -alter the default configuration of the pin. This is a bitmask of -various flags defined in an implementation-specific way, but the names -of the flags are the same on all implementations. - - PORTMUX_DIR_OUTPUT - PORTMUX_DIR_INPUT - -These mutually-exclusive flags configure the initial direction of the -pins. PORTMUX_DIR_OUTPUT means that the pins are driven by the CPU, -while PORTMUX_DIR_INPUT means that the pins are tristated by the CPU. -These flags are ignored by portmux_select_peripheral(). - - PORTMUX_INIT_HIGH - PORTMUX_INIT_LOW - -These mutually-exclusive flags configure the initial state of the -pins: High (Vdd) or low (Vss). They are only effective when -portmux_select_gpio() is called with the PORTMUX_DIR_OUTPUT flag set. - - PORTMUX_PULL_UP - PORTMUX_PULL_DOWN - PORTMUX_BUSKEEPER - -These mutually-exclusive flags are used to enable any on-chip CMOS -resistors connected to the pins. PORTMUX_PULL_UP causes the pins to be -pulled up to Vdd, PORTMUX_PULL_DOWN causes the pins to be pulled down -to Vss, and PORTMUX_BUSKEEPER will keep the pins in whatever state -they were left in by whatever was driving them last. If none of the -flags are specified, the pins are left floating if no one are driving -them; this is only recommended for always-output pins (e.g. extern -address and control lines driven by the CPU.) - -Note that the "PIO" implementation will silently ignore the -PORTMUX_PULL_DOWN flag and interpret PORTMUX_BUSKEEPER as -PORTMUX_PULL_UP. - - PORTMUX_DRIVE_MIN - PORTMUX_DRIVE_LOW - PORTMUX_DRIVE_HIGH - PORTMUX_DRIVE_MAX - -These mutually-exclusive flags determine the drive strength of the -pins. PORTMUX_DRIVE_MIN will give low power-consumption, but may cause -corruption of high-speed signals. PORTMUX_DRIVE_MAX will give high -power-consumption, but may be necessary on pins toggling at very high -speeds. PORTMUX_DRIVE_LOW and PORTMUX_DRIVE_HIGH specify something in -between the other two. - -Note that setting the drive strength too high may cause excessive -overshoot and EMI problems, which may in turn cause signal corruption. -Also note that the "PIO" implementation will silently ignore these -flags. - - PORTMUX_OPEN_DRAIN - -This flag will configure the pins as "open drain", i.e. setting the -pin state to 0 will drive it low, while setting it to 1 will leave it -floating (or, in most cases, let it be pulled high by an internal or -external pull-up resistor.) In the data sheet for chips using the -"PIO" variant, this mode is called "multi-driver". - -Enabling specific peripherals ------------------------------ -In addition to the above functions, each chip provides a set of -functions for setting up the port multiplexer to use a given -peripheral. The following are some of the functions available. - -All the functions below take a "drive_strength" parameter, which must -be one of the PORTMUX_DRIVE_x flags specified above. Any other -portmux flags will be silently filtered out. - -To set up the External Bus Interface (EBI), call - - void portmux_enable_ebi(unsigned int bus_width, - unsigned long flags, unsigned long drive_strength) - -where "bus_width" must be either 16 or 32. "flags" can be any -combination of the following flags. - - PORTMUX_EBI_CS(x) /* Enable chip select x */ - PORTMUX_EBI_NAND /* Enable NAND flash interface */ - PORTMUX_EBI_CF(x) /* Enable CompactFlash interface x */ - PORTMUX_EBI_NWAIT /* Enable NWAIT signal */ - -To set up a USART, call - - void portmux_enable_usartX(unsigned long drive_strength); - -where X is replaced by the USART instance to be configured. - -To set up an ethernet MAC: - - void portmux_enable_macbX(unsigned long flags, - unsigned long drive_strength); - -where X is replaced by the MACB instance to be configured. "flags" can -be any combination of the following flags. - - PORTMUX_MACB_RMII /* Just set up the RMII interface */ - PORTMUX_MACB_MII /* Set up full MII interface */ - PORTMUX_MACB_SPEED /* Enable the SPEED pin */ - -To set up the MMC controller: - - void portmux_enable_mmci(unsigned long slot, unsigned long flags - unsigned long drive_strength); - -where "slot" identifies which of the alternative SD card slots to -enable. "flags" can be any combination of the following flags: - - PORTMUX_MMCI_4BIT /* Enable 4-bit SD card interface */ - PORTMUX_MMCI_8BIT /* Enable 8-bit MMC+ interface */ - PORTMUX_MMCI_EXT_PULLUP /* Board has external pull-ups */ - -To set up a SPI controller: - - void portmux_enable_spiX(unsigned long cs_mask, - unsigned long drive_strength); - -where X is replaced by the SPI instance to be configured. "cs_mask" is -a 4-bit bitmask specifying which of the four standard chip select -lines to set up as GPIOs. diff --git a/qemu/roms/u-boot/doc/README.JFFS2 b/qemu/roms/u-boot/doc/README.JFFS2 deleted file mode 100644 index f0e9bc1b3..000000000 --- a/qemu/roms/u-boot/doc/README.JFFS2 +++ /dev/null @@ -1,74 +0,0 @@ -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 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 is two ways for JFFS2 to find the disk. The default way 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 - - -The second way is to define CONFIG_SYS_JFFS_CUSTOM_PART and implement the -jffs2_part_info(int part_num) function in your board specific files. -In this mode CONFIG_SYS_JFFS2_FIRST_BANK and CONFIG_SYS_JFFS2_FIRST_SECTOR is not -used. - -The input is a partition number starting with 0. -Return a pointer to struct part_info or NULL for error; - -Ex jffs2_part_info() for one partition. ---- -#if defined CONFIG_SYS_JFFS_CUSTOM_PART -#include <jffs2/jffs2.h> - -static struct part_info part; - -struct part_info* -jffs2_part_info(int part_num) -{ - if(part_num==0){ - if(part.usr_priv==(void*)1) - return ∂ - - memset(&part, 0, sizeof(part)); - part.offset=(char*)0xFF800000; - part.size=1024*1024*8; - - /* Mark the struct as ready */ - part.usr_priv=(void*)1; - - return ∂ - } - return 0; -} -#endif ---- - -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/qemu/roms/u-boot/doc/README.JFFS2_NAND b/qemu/roms/u-boot/doc/README.JFFS2_NAND deleted file mode 100644 index 09788d534..000000000 --- a/qemu/roms/u-boot/doc/README.JFFS2_NAND +++ /dev/null @@ -1,24 +0,0 @@ -JFFS2 NAND support: - -To enable, use the following #define in the board configuration file: - -#define CONFIG_JFFS2_NAND 1 - -Configuration of partitions is similar to how this is done in U-Boot -for JFFS2 on top NOR flash. If a single partition is used, it can be -configured using the following #defines in the configuration file: - -#define CONFIG_JFFS2_NAND_DEV 0 /* nand device jffs2 lives on */ -#define CONFIG_JFFS2_NAND_OFF 0 /* start of jffs2 partition */ -#define CONFIG_JFFS2_NAND_SIZE 2*1024*1024 /* size of jffs2 partition */ - -If more than a single partition is desired, the user can define a -CONFIG_SYS_JFFS_CUSTOM_PART macro and implement a - - struct part_info* jffs2_part_info(int part_num) - -function in a board-specific module. An example of such function is -available in common/cmd_jffs2.c - -The default configuration for the DAVE board has a single JFFS2 -partition of 2 MB size. diff --git a/qemu/roms/u-boot/doc/README.LED b/qemu/roms/u-boot/doc/README.LED deleted file mode 100644 index c3bcb3ac8..000000000 --- a/qemu/roms/u-boot/doc/README.LED +++ /dev/null @@ -1,78 +0,0 @@ -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 define CONFIG_STATUS_LED in the board config file. - -If the LED support is only for a single board, define CONFIG_BOARD_SPECIFIC_LED -in the board config file. - -At a minimum, these macros must be defined at -STATUS_LED_BIT -STATUS_LED_STATE -STATUS_LED_PERIOD - -If there are multiple status LED's define -STATUS_LED_BIT<n> -STATUS_LED_STATE<n> -STATUS_LED_PERIOD<n> - -Where <n> can a integer 1 through 3. - -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 STATUS_LED_BIT's. Mapping the value to a physical LED is the -reponsiblity of the __led_* function. - -STATUS_LED_STATE is the initial state of the LED. It should be set to one of -these values: STATUS_LED_OFF or STATUS_LED_ON. - -STATUS_LED_PERIOD is how long is the LED blink period. This usually set to -(CONFIG_SYS_HZ / <N>) where <N> is the frequency of the blink. Typical values -range from 2 to 10. - -Some other LED macros - -STATUS_LED_BOOT is the LED to light when the board is booting. This must be a -valid STATUS_LED_BIT value. - -STATUS_LED_RED is the red LED. It is used signal errors. This must be a valid -STATUS_LED_BIT value. Other similar color LED's are STATUS_LED_YELLOW and -STATUS_LED_BLUE. - -These board must define these functions - -__led_init is called once to initialize the LED to 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 -CONFIG_TQM8xxL. - -TBD : Describe general support via asm/status_led.h diff --git a/qemu/roms/u-boot/doc/README.LED_display b/qemu/roms/u-boot/doc/README.LED_display deleted file mode 100644 index 19977ea7e..000000000 --- a/qemu/roms/u-boot/doc/README.LED_display +++ /dev/null @@ -1,26 +0,0 @@ -LED display internal API -======================================= - -This README describes the LED display API. - -The API is defined by the include file include/led-display.h - -The first step in to define CONFIG_CMD_DISPLAY in the board config file. -Then you need to provide the following functions to access LED display: - -void display_set(int cmd); - -This function should control the state of the LED display. Argument is -an ORed combination of the following values: - DISPLAY_CLEAR -- clear the display - DISPLAY_HOME -- set the position to the beginning of display - -int display_putc(char c); - -This function should display it's parameter on the LED display in the -current position. Returns the displayed character on success or -1 in -case of failure. - -With this functions defined 'display' command will display it's -arguments on the LED display (or clear the display if called without -arguments). diff --git a/qemu/roms/u-boot/doc/README.MPC866 b/qemu/roms/u-boot/doc/README.MPC866 deleted file mode 100644 index 4707cb7df..000000000 --- a/qemu/roms/u-boot/doc/README.MPC866 +++ /dev/null @@ -1,24 +0,0 @@ -The current implementation allows the user to specify the desired CPU -clock value, in MHz, via an environment variable "cpuclk". - -Four compile-time constants are used: - - CONFIG_8xx_OSCLK - input quartz clock - CONFIG_SYS_8xx_CPUCLK_MIN - minimum allowed CPU clock - CONFIG_SYS_8xx_CPUCLK_MAX - maximum allowed CPU clock - CONFIG_8xx_CPUCLK_DEFAULT - default CPU clock value - -If the "cpuclk" environment variable value is within the CPUCLK_MIN / -CPUCLK_MAX limits, the specified value is used. Otherwise, the -default CPU clock value is set. - -Please make sure you understand what you are doing, and understand -the restrictions of your hardware (board, processor). For example, -ethernet will stop working for CPU clock frequencies below 25 MHz. - -Please note that the new clock-handling code is enabled if -CONFIG_8xx_CPUCLK_DEFAULT is defined. Since this mechanism supports -only MPC866 and newer CPUs, this constant MUST NOT be defined for -MPC823/850/860/862 series. The clock generation algorithm for older -chips is different and has not been implemented yet. If you need it, -your patch is welcome. diff --git a/qemu/roms/u-boot/doc/README.Modem b/qemu/roms/u-boot/doc/README.Modem deleted file mode 100644 index 1613c11ca..000000000 --- a/qemu/roms/u-boot/doc/README.Modem +++ /dev/null @@ -1,72 +0,0 @@ -How to configure modem support in U-Boot : - -1. Define modem initialization strings: ---------------------------------------- - -The modem initialization strings have following format: - - mdm_init1=<AT-command> - mdm_init2=<AT-command> - ... - -Turning off modem verbose responses with ATV0 or ATQ1 is not allowed; -U-Boot analyzes only verbose (not numeric) result codes. Modem local -command echo can be turned off (ATE0). - -2. RTS/CTS hardware flow control: ---------------------------------- - -You may wish to enable RTS/CTS hardware flow control, if the board's -UART driver supports it (see CONFIG_HWFLOW compile-time flag in -config/<board>.h). This is controlled by the 'mdm_flow_control' -environment variable: - - 'mdm_flow_control=rts/cts' - to enable RTS/CTS flow control. - 'mdm_flow_control=none ' - to disable. - - -The following are the examples using a Rockwell OEM modem -configuration: - -SAMSUNG # setenv mdm_init1 ATZ - reset the modem to - the factory defaults. -SAMSUNG # setenv mdm_init2 ATS0=1 - set modem into - answer mode. -SAMSUNG # setenv mdm_flow_control rts/cts - enable serial port - flow control -SAMSUNG # saveenv - -The example above initializes modem into answer mode to wait for the -incoming call. RTS/CTS flow control is enabled for the serial port. -(The RTS/CTS flow control is enabled by default on the modem). - - -SAMSUNG # setenv mdm_init1 ATZ -SAMSUNG # setenv mdm_init2 ATS39=0+IFC=0,0 - disable modem - RTS/CTS flow control -SAMSUNG # setenv mdm_init3 ATDT1643973 - dial out the number -SAMSUNG # setenv mdm_flow_control none -SAMSUNG # saveenv - -The example above initializes modem to dial-up connection on the -number 1643973. Flow control is disabled. - -Note that flow control must be turned both off or both on for the -board serial port and for the modem. - - -If the connection was set up successfully, the U-Boot prompt appears -on the terminal console. If not (U-Boot modem was configured for -originating the call and connection was not established) - the board -should be reset for another dial-up try. - - -Note on the SMDK2400 board: ---------------------------- - -Since the board serial ports does not have DTR signal wired, modem -should be told to ignore port DTR setting prior to connection to the -SMDK board, and this setting should be stored in modem NVRAM. For the -Rockwell OEM modem this can to be done with the following command: - -AT&D0&W diff --git a/qemu/roms/u-boot/doc/README.N1213 b/qemu/roms/u-boot/doc/README.N1213 deleted file mode 100644 index e107166e1..000000000 --- a/qemu/roms/u-boot/doc/README.N1213 +++ /dev/null @@ -1,55 +0,0 @@ -N1213 is a configurable hard/soft core of NDS32's N12 CPU family. - -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. diff --git a/qemu/roms/u-boot/doc/README.NDS32 b/qemu/roms/u-boot/doc/README.NDS32 deleted file mode 100644 index b2b58fc22..000000000 --- a/qemu/roms/u-boot/doc/README.NDS32 +++ /dev/null @@ -1,41 +0,0 @@ -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 doc/README.N1213. - -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/qemu/roms/u-boot/doc/README.NetConsole b/qemu/roms/u-boot/doc/README.NetConsole deleted file mode 100644 index af7fc6043..000000000 --- a/qemu/roms/u-boot/doc/README.NetConsole +++ /dev/null @@ -1,97 +0,0 @@ - -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. - -CONFIG_NETCONSOLE_BUFFER_SIZE - Override the default 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: - - 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: - - 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: - - netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc - -or - - 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: - - 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/qemu/roms/u-boot/doc/README.OFT b/qemu/roms/u-boot/doc/README.OFT deleted file mode 100644 index dd1c632bc..000000000 --- a/qemu/roms/u-boot/doc/README.OFT +++ /dev/null @@ -1,28 +0,0 @@ -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/qemu/roms/u-boot/doc/README.POST b/qemu/roms/u-boot/doc/README.POST deleted file mode 100644 index 6815d491c..000000000 --- a/qemu/roms/u-boot/doc/README.POST +++ /dev/null @@ -1,743 +0,0 @@ -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(bd_t *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 board_power_mode(void) - - This routine will return the mode the system is running in - (POST_POWERON, POST_NORMAL or POST_SHUTDOWN). - - o) void board_poweroff(void) - - This routine will turn off the power supply of the board. It - will be called on power-fail booting after running all POST - tests. - - 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)(bd_t *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(bd_t *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 transfered 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/qemu/roms/u-boot/doc/README.SNTP b/qemu/roms/u-boot/doc/README.SNTP deleted file mode 100644 index da9ec459a..000000000 --- a/qemu/roms/u-boot/doc/README.SNTP +++ /dev/null @@ -1,17 +0,0 @@ -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/qemu/roms/u-boot/doc/README.SPL b/qemu/roms/u-boot/doc/README.SPL deleted file mode 100644 index 57a39a489..000000000 --- a/qemu/roms/u-boot/doc/README.SPL +++ /dev/null @@ -1,112 +0,0 @@ -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 ------------- - -There is a new directory $(srctree)/spl which contains only a Makefile. -The object files are built separately for SPL and placed in this directory. -The final binaries which are generated are u-boot-spl, u-boot-spl.bin and -u-boot-spl.map. - -During the SPL build a variable named CONFIG_SPL_BUILD is exported -in the make environment and also appended to CPPFLAGS with -DCONFIG_SPL_BUILD. -Source files can therefore be compiled for SPL with different settings. -ARM-based boards have previously used the option CONFIG_PRELOADER for it. - -For example: - -ifeq ($(CONFIG_SPL_BUILD),y) -COBJS-y += board_spl.o -else -COBJS-y += board.o -endif - -COBJS-$(CONFIG_SPL_BUILD) += foo.o - -#ifdef CONFIG_SPL_BUILD - foo(); -#endif - - -The building of SPL images can be with: - -#define CONFIG_SPL - -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_FAT_SUPPORT (fs/fat/libfat.o) -CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) -CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) -CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) -CONFIG_SPL_DRIVERS_MISC_SUPPORT (drivers/misc) -CONFIG_SPL_DMA_SUPPORT (drivers/dma/libdma.o) -CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o) -CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/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) - -Normally CPU is assumed to be the same between the SPL and normal -u-boot build. However it is possible to specify a different CPU for -the SPL build for cases where the SPL is expected to run on a -different CPU model from the main u-boot. This is done by specifying -an SPL CPU in boards.cfg as follows: - - normal_cpu:spl_cpu - -This case CPU will be set to "normal_cpu" during the main u-boot -build and "spl_cpu" during the SPL build. - - -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/qemu/roms/u-boot/doc/README.TPL b/qemu/roms/u-boot/doc/README.TPL deleted file mode 100644 index 980debe77..000000000 --- a/qemu/roms/u-boot/doc/README.TPL +++ /dev/null @@ -1,45 +0,0 @@ -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 choosed in the -board config file. - -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/qemu/roms/u-boot/doc/README.VLAN b/qemu/roms/u-boot/doc/README.VLAN deleted file mode 100644 index 4f86d55ea..000000000 --- a/qemu/roms/u-boot/doc/README.VLAN +++ /dev/null @@ -1,15 +0,0 @@ -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/qemu/roms/u-boot/doc/README.VSC3316-3308 b/qemu/roms/u-boot/doc/README.VSC3316-3308 deleted file mode 100644 index 925663ba5..000000000 --- a/qemu/roms/u-boot/doc/README.VSC3316-3308 +++ /dev/null @@ -1,43 +0,0 @@ -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/qemu/roms/u-boot/doc/README.ag102 b/qemu/roms/u-boot/doc/README.ag102 deleted file mode 100644 index 7d142a70d..000000000 --- a/qemu/roms/u-boot/doc/README.ag102 +++ /dev/null @@ -1,36 +0,0 @@ -Andes Technology SoC AG102 -========================== - -AG102 is the second SoC produced by Andes Technology using N1213 CPU core -with FPU and DDR contoller support. -AG102 has integrated both AHB and APB bus and many periphals for application -and product development. - -ADP-AG102 -========= - -ADP-AG102 is the SoC with AG102 hardcore CPU. - -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-ag102.h". - -Build and boot steps -==================== - -build: -1. Prepare the toolchains and make sure the $PATH to toolchains is correct. -2. Use `make adp-ag102` in u-boot root to build the image. - -Burn u-boot to SPI ROM: -==================== - -This section will be added later. diff --git a/qemu/roms/u-boot/doc/README.arm-caches b/qemu/roms/u-boot/doc/README.arm-caches deleted file mode 100644 index f6a52e3e3..000000000 --- a/qemu/roms/u-boot/doc/README.arm-caches +++ /dev/null @@ -1,53 +0,0 @@ -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. disable_dcache() - 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/qemu/roms/u-boot/doc/README.arm-relocation b/qemu/roms/u-boot/doc/README.arm-relocation deleted file mode 100644 index 645b3746c..000000000 --- a/qemu/roms/u-boot/doc/README.arm-relocation +++ /dev/null @@ -1,193 +0,0 @@ -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 the bd_t 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 bd_t 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/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/qemu/roms/u-boot/doc/README.arm64 b/qemu/roms/u-boot/doc/README.arm64 deleted file mode 100644 index 75586dbaa..000000000 --- a/qemu/roms/u-boot/doc/README.arm64 +++ /dev/null @@ -1,46 +0,0 @@ -U-boot for arm64 - -Summary -======= -No hardware platform of arm64 is available now. The u-boot is -simulated on Foundation Model and Fast Model for ARMv8. - -Notes -===== - -1. Currenly, u-boot run at the highest exception level processor - supported and jump to EL2 or optionally EL1 before enter 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. Fdt should be placed at a 2-megabyte boundary and within the first 512 - megabytes from the start of the kernel image. So, fdt_high should be - defined specially. - 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. - -Contributor -=========== - 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> diff --git a/qemu/roms/u-boot/doc/README.at91 b/qemu/roms/u-boot/doc/README.at91 deleted file mode 100644 index 67412136e..000000000 --- a/qemu/roms/u-boot/doc/README.at91 +++ /dev/null @@ -1,174 +0,0 @@ -Atmel AT91 Evaluation kits - -Index - - I. Board mapping & boot media - - II. NAND partition table - - III. watchdog support - -I. 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 - - -II. 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) - -III. 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_AT91SAM9_WATCHDOG and CONFIG_HW_WATCHDOG options. diff --git a/qemu/roms/u-boot/doc/README.at91-soc b/qemu/roms/u-boot/doc/README.at91-soc deleted file mode 100644 index ab3f71342..000000000 --- a/qemu/roms/u-boot/doc/README.at91-soc +++ /dev/null @@ -1,48 +0,0 @@ - New C structure AT91 SoC access -================================= - -The goal --------- - -Currently the at91 arch uses hundreds of address defines and special -at91_xxxx_write/read functions to access the SOC. -The u-boot project perferred method is to access memory mapped hw -regisister via a c structure. - -e.g. old - - *AT91C_PIOA_IDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - *AT91C_PIOC_PUDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - *AT91C_PIOC_PER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - *AT91C_PIOC_OER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - *AT91C_PIOC_PIO = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - - at91_sys_write(AT91_RSTC_CR, - AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST); - -e.g new - pin = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK; - writel(pin, &pio->pioa.idr); - writel(pin, &pio->pioa.pudr); - writel(pin, &pio->pioa.per); - writel(pin, &pio->pioa.oer); - writel(pin, &pio->pioa.sodr); - - writel(AT91_RSTC_KEY | AT91_RSTC_CR_PROCRST | - AT91_RSTC_CR_PERRST, &rstc->cr); - -The method for updating ------------------------- - -1. add's the temporary CONFIG_AT91_LEGACY to all at91 board configs -2. Display a compile time warning, if the board has not been converted -3. add new structures for SoC access -4. Convert arch, driver and boards file to new SoC -5. remove legacy code, if all boards and drives are ready - -2013-10-30 Andreas Bießmann <andreas.devel@googlemail.com>: - -The goal is almost reached, we could remove the CONFIG_AT91_LEGACY switch but -remain the CONFIG_ATMEL_LEGACY switch until the GPIO disaster is fixed. The -AT91 spi driver has also some CONFIG_ATMEL_LEGACY stuff left, so another point -to fix until this README can be removed. diff --git a/qemu/roms/u-boot/doc/README.atmel_mci b/qemu/roms/u-boot/doc/README.atmel_mci deleted file mode 100644 index 1ec4465ca..000000000 --- a/qemu/roms/u-boot/doc/README.atmel_mci +++ /dev/null @@ -1,77 +0,0 @@ -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, -including AVR32. - -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(bd_t *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_MMC 1 -#define CONFIG_GENERIC_MMC 1 -#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/qemu/roms/u-boot/doc/README.atmel_pmecc b/qemu/roms/u-boot/doc/README.atmel_pmecc deleted file mode 100644 index cf8373b54..000000000 --- a/qemu/roms/u-boot/doc/README.atmel_pmecc +++ /dev/null @@ -1,29 +0,0 @@ -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 AT91SAM9X5EK as an example, the board definition file likes: - -/* PMECC & PMERRLOC */ -#define CONFIG_ATMEL_NAND_HWECC 1 -#define CONFIG_ATMEL_NAND_HW_PMECC 1 -#define CONFIG_PMECC_CAP 2 -#define CONFIG_PMECC_SECTOR_SIZE 512 diff --git a/qemu/roms/u-boot/doc/README.autoboot b/qemu/roms/u-boot/doc/README.autoboot deleted file mode 100644 index 14e3660dd..000000000 --- a/qemu/roms/u-boot/doc/README.autoboot +++ /dev/null @@ -1,157 +0,0 @@ -/* - * (C) Copyright 2001 - * Dave Ellis, SIXNET, dge@sixnetio.com - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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 - CONFIG_AUTOBOOT_DELAY_STR2 - CONFIG_AUTOBOOT_STOP_STR2 - - "bootdelaykey" environment variable - "bootstopkey" environment variable - "bootdelaykey2" environment variable - "bootstopkey2" 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. - - Using the CONFIG_AUTOBOOT_DELAY_STR2 #define or the - "bootdelaykey2" environment variable and/or the - CONFIG_AUTOBOOT_STOP_STR2 #define or the "bootstopkey" - environment variable you can specify a second, alternate - string (which allows you to have two "password" strings). - - 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_ZERO_BOOTDELAY_CHECK - - If this option is defined, you can stop the autoboot process - by hitting a key even in that case when "bootdelay" has been - set to 0. You can set "bootdelay" to a negative value to - prevent the check for console input. - - 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. diff --git a/qemu/roms/u-boot/doc/README.b4860qds b/qemu/roms/u-boot/doc/README.b4860qds deleted file mode 100644 index eada0c7dd..000000000 --- a/qemu/roms/u-boot/doc/README.b4860qds +++ /dev/null @@ -1,366 +0,0 @@ -Overview --------- -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 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 ----------------- - -SW1 OFF [0] OFF [1] OFF [1] OFF [0] OFF [1] OFF [0] OFF [1] OFF [1] -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. -Note: 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 - -a) NAND boot - SW1 [1.1] = 0 - SW2 [1.1] = 1 - SW3 [1:4] = 0001 -b) NOR boot - SW1 [1.1] = 1 - SW2 [1.1] = 0 - SW3 [1:4] = 1000. - -B4420QDS Default Settings -------------------------- - -Switch Settings ----------------- -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. -Note: 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 - -a) NAND boot - SW1 [1.1] = 0 - SW2 [1.1] = 1 - SW3 [1:4] = 0001 -b) 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. - -1. U-boot environment variable hwconfig - The default hwconfig is: - 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" - -2. FMAN Ucode versions - fsl_fman_ucode_B4860_106_3_6.bin - -3. Switching to alternate bank - Commands for switching to alternate bank. - - 1. To change from vbank0 to vbank2 - => qixis_reset altbank (it will boot using vbank2) - - 2.To change from vbank2 to vbank0 - => qixis reset (it will boot using vbank0) - -4. 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 - => 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. - Note: 0xffdf0000 is the address of the QIXIS FPGA. - -5. 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 - => 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: - => 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. - Note: 0xffdf0000 is the address of the QIXIS FPGA. - -6. 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 - -7. 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/qemu/roms/u-boot/doc/README.bedbug b/qemu/roms/u-boot/doc/README.bedbug deleted file mode 100644 index 35e9d2706..000000000 --- a/qemu/roms/u-boot/doc/README.bedbug +++ /dev/null @@ -1,78 +0,0 @@ -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/qemu/roms/u-boot/doc/README.bitbangMII b/qemu/roms/u-boot/doc/README.bitbangMII deleted file mode 100644 index 0a2fa48a5..000000000 --- a/qemu/roms/u-boot/doc/README.bitbangMII +++ /dev/null @@ -1,56 +0,0 @@ -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/qemu/roms/u-boot/doc/README.blackfin b/qemu/roms/u-boot/doc/README.blackfin deleted file mode 100644 index a837d90f2..000000000 --- a/qemu/roms/u-boot/doc/README.blackfin +++ /dev/null @@ -1,46 +0,0 @@ -Notes for the Blackfin architecture port of Das U-Boot - - ========= - ! ABOUT ! - ========= - -<marketing blurb> -Blackfin Processors embody a new breed of 16/32-bit embedded processor, ideally -suited for products where a convergence of capabilities are necessary - -multi-format audio, video, voice and image processing; multi-mode baseband and -packet processing; control processing; and real-time security. The Blackfin's -unique combination of software flexibility and scalability has gained it -widespread adoption in convergent applications. -</marketing blurb> - -The Blackfin processor is wholly developed by Analog Devices Inc. - - =========== - ! SUPPORT ! - =========== - -All open source code for the Blackfin processors are being handled via our -collaborative website: -http://blackfin.uclinux.org/ - -In particular, bug reports, feature requests, help etc... for Das U-Boot are -handled in the Das U-Boot sub project: -http://blackfin.uclinux.org/gf/project/u-boot - -This website is backed both by an open source community as well as a dedicated -team from Analog Devices Inc. - - ============= - ! TOOLCHAIN ! - ============= - -To compile the Blackfin aspects, you'll need the GNU toolchain configured for -the Blackfin processor. You can obtain such a cross-compiler here: -http://blackfin.uclinux.org/gf/project/toolchain - - ================= - ! DOCUMENTATION ! - ================= - -For Blackfin specific documentation, you can visit our dedicated doc wiki: -http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot diff --git a/qemu/roms/u-boot/doc/README.bootmenu b/qemu/roms/u-boot/doc/README.bootmenu deleted file mode 100644 index af22a139c..000000000 --- a/qemu/roms/u-boot/doc/README.bootmenu +++ /dev/null @@ -1,99 +0,0 @@ -/* - * (C) Copyright 2011-2012 Pali Rohár <pali.rohar@gmail.com> - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -ANSI terminal 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 first appearance of '=' - character in the environment variable) - -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 -(without decorating rectangle): - -┌──────────────────────────────────────────┐ -│ │ -│ *** 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 │ -│ │ -└──────────────────────────────────────────┘ - -Selected menu entry will be highlighted - it will have inverted -background and text colors. - -To enable the "bootmenu" command add following definitions to the -board config file: - - #define CONFIG_CMD_BOOTMENU - #define CONFIG_MENU - -To run the bootmenu at startup add these additional definitions: - - #define CONFIG_AUTOBOOT_KEYED - #define CONFIG_BOOTDELAY 30 - #define CONFIG_MENU_SHOW - -When you intend to use the bootmenu on color frame buffer console, -make sure to additionally define CONFIG_CFB_CONSOLE_ANSI in the -board config file. diff --git a/qemu/roms/u-boot/doc/README.bus_vcxk b/qemu/roms/u-boot/doc/README.bus_vcxk deleted file mode 100644 index 5bd3c652a..000000000 --- a/qemu/roms/u-boot/doc/README.bus_vcxk +++ /dev/null @@ -1,68 +0,0 @@ -/* - * (C) Copyright 2008-2009 - * BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de> - * Jens Scharsig <esw@bus-elektronik.de> - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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/qemu/roms/u-boot/doc/README.cfi b/qemu/roms/u-boot/doc/README.cfi deleted file mode 100644 index d087ff0d6..000000000 --- a/qemu/roms/u-boot/doc/README.cfi +++ /dev/null @@ -1,29 +0,0 @@ -The common CFI driver provides this weak default implementation for -flash_cmd_reset(): - -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); - 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 seems to have trouble with this reset sequence. In this case -the board specific code can override this weak default version with a board -specific function. For example 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); -} - -see also: -http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html diff --git a/qemu/roms/u-boot/doc/README.commands b/qemu/roms/u-boot/doc/README.commands deleted file mode 100644 index afd5577b0..000000000 --- a/qemu/roms/u-boot/doc/README.commands +++ /dev/null @@ -1,36 +0,0 @@ - -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() macro -to fill in a cmd_tbl_t struct. - -U_BOOT_CMD(name,maxargs,repeatable,command,"usage","help") - -name: is the name of the commad. THIS IS NOT a string. -maxargs: the maximum number of arguments this function takes -repeatable: either 0 or 1 to indicate if autorepeat is allowed -command: Function pointer (*cmd)(struct cmd_tbl_s *, int, int, char *[]); -usage: Short description. This is a string -help: Long description. This is a string - - -**** 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: - - .u_boot_list : { - KEEP(*(SORT(.u_boot_list*))); - } diff --git a/qemu/roms/u-boot/doc/README.commands.itest b/qemu/roms/u-boot/doc/README.commands.itest deleted file mode 100644 index 5e0fe8624..000000000 --- a/qemu/roms/u-boot/doc/README.commands.itest +++ /dev/null @@ -1,16 +0,0 @@ -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/qemu/roms/u-boot/doc/README.commands.spl b/qemu/roms/u-boot/doc/README.commands.spl deleted file mode 100644 index ac332731e..000000000 --- a/qemu/roms/u-boot/doc/README.commands.spl +++ /dev/null @@ -1,31 +0,0 @@ -The spl command is used to export a boot parameter image to RAM. Later -it may implement more functions connected to the SPL. - -SUBCOMMAND EXPORT -To execute the command everything has to be in place as if bootm should be -used. (kernel image, initrd-image, fdt-image etc.) - -export has two subcommands: - atags: exports the ATAGS - fdt: exports the FDT - -Call is: -spl export <ftd|atags> [kernel_addr] [initrd_addr] [fdt_addr if fdt] - - -TYPICAL CALL - -on OMAP3: -nandecc hw -nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ -spl export atags /* export ATAGS */ -nand erase 0x680000 0x20000 /* erase - one page */ -nand write 0x80000100 0x680000 0x20000 /* write the image - one page */ - -call with FDT: -nandecc hw -nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/ -tftpboot 0x80000100 devkit8000.dtb /* Read fdt */ -spl export fdt 0x82000000 - 0x80000100 /* export FDT */ -nand erase 0x680000 0x20000 /* erase - one page */ -nand write <adress shown by spl export> 0x680000 0x20000 diff --git a/qemu/roms/u-boot/doc/README.console b/qemu/roms/u-boot/doc/README.console deleted file mode 100644 index aadf596a8..000000000 --- a/qemu/roms/u-boot/doc/README.console +++ /dev/null @@ -1,101 +0,0 @@ -/* - * (C) Copyright 2000 - * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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_t 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/qemu/roms/u-boot/doc/README.davinci b/qemu/roms/u-boot/doc/README.davinci deleted file mode 100644 index aa7c85011..000000000 --- a/qemu/roms/u-boot/doc/README.davinci +++ /dev/null @@ -1,159 +0,0 @@ -Summary -======= - -This README is about U-Boot support for TI's ARM 926EJS based family of SoCs. -These SOCs are used for cameras, video security and surveillance, DVR's, etc. -DaVinci SOC's comprise of DM644x, DM646x, DM35x and DM36x series of SOC's -Additionally there are some SOCs meant for the audio market which though have -an OMAP part number are very similar to the DaVinci series of SOC's -Additionally, some family members contain a TI DSP and/or graphics -co processors along with a host of other peripherals. - -Currently the following boards are supported: - -* TI DaVinci DM644x EVM - -* TI DaVinci DM646x EVM - -* TI DaVinci DM355 EVM - -* TI DaVinci DM365 EVM - -* TI DA830 EVM - -* TI DA850 EVM - -* DM355 based Leopard board - -* DM644x based schmoogie board - -* DM644x based sffsdr board - -* DM644x based sonata board - -Build -===== - -* TI DaVinci DM644x EVM: - -make davinci_dvevm_config -make - -* TI DaVinci DM646x EVM: - -make davinci_dm6467evm_config -make - -* TI DaVinci DM355 EVM: - -make davinci_dm355evm_config -make - -* TI DaVinci DM365 EVM: - -make davinci_dm365evm_config -make - -* TI DA830 EVM: - -make da830evm_config -make - -* TI DA850 EVM: - -make da850evm_config -make - -* DM355 based Leopard board: - -make davinci_dm355leopard_config -make - -* DM644x based schmoogie board: - -make davinci_schmoogie_config -make - -* DM644x based sffsdr board: - -make davinci_sffsdr_config -make - -* DM644x based sonata board: - -make davinci_sonata_config -make - -Bootloaders -=============== - -The DaVinci SOC's use 2 bootloaders. The low level initialization -is done by a UBL(user boot loader). The UBL is written to a NAND/NOR/SPI flash -by a programmer. During initial bootup, the ROM Bootloader reads the UBL -from a storage device and loads it into the IRAM. The UBL then loads the U-Boot -into the RAM. -The programmers and UBL are always released as part of any standard TI -software release associated with an SOC. - -Alternative boot method (DA850 EVM only): -For the DA850 EVM an SPL (secondary program loader, see doc/README.SPL) -is provided to load U-Boot directly from SPI flash. In this case, the -SPL does the low level initialization that is otherwise done by the SPL. -To build U-Boot with this SPL, do -make da850evm_config -make u-boot.ais -and program the resulting u-boot.ais file to the SPI flash of the DA850 EVM. - -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 DaVinci DM355 EVM: -http://focus.ti.com/docs/prod/folders/print/tms320dm355.html -http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=203&osCsid=c499af6087317f11b3da19b4e8f1af32 - -2) TI DaVinci DM365 EVM: -http://focus.ti.com/docs/prod/folders/print/tms320dm365.html?247SEM= -http://support.spectrumdigital.com/boards/evmdm365/revc/ - -3) DaVinci DM355 based leopard board -http://designsomething.org/leopardboard/default.aspx -http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=192&osCsid=67c20335668ffc57cb35727106eb24b1 - -4) TI DaVinci DM6467 EVM: -http://focus.ti.com/docs/prod/folders/print/tms320dm6467.html -http://support.spectrumdigital.com/boards/evmdm6467/revf/ - -5) TI DaVinci DM6446 EVM: -http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html -http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=222 - -6) TI DA830 EVM -http://focus.ti.com/apps/docs/gencontent.tsp?appId=1&contentId=52385 -http://www.spectrumdigital.com/product_info.php?cPath=37&products_id=214 - -7) 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 - -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/qemu/roms/u-boot/doc/README.davinci.nand_spl b/qemu/roms/u-boot/doc/README.davinci.nand_spl deleted file mode 100644 index f46721a00..000000000 --- a/qemu/roms/u-boot/doc/README.davinci.nand_spl +++ /dev/null @@ -1,141 +0,0 @@ -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/qemu/roms/u-boot/doc/README.displaying-bmps b/qemu/roms/u-boot/doc/README.displaying-bmps deleted file mode 100644 index 331154166..000000000 --- a/qemu/roms/u-boot/doc/README.displaying-bmps +++ /dev/null @@ -1,27 +0,0 @@ -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/qemu/roms/u-boot/doc/README.dns b/qemu/roms/u-boot/doc/README.dns deleted file mode 100644 index 8dff454b1..000000000 --- a/qemu/roms/u-boot/doc/README.dns +++ /dev/null @@ -1,62 +0,0 @@ -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/qemu/roms/u-boot/doc/README.drivers.eth b/qemu/roms/u-boot/doc/README.drivers.eth deleted file mode 100644 index eb83038b5..000000000 --- a/qemu/roms/u-boot/doc/README.drivers.eth +++ /dev/null @@ -1,190 +0,0 @@ ------------------------ - 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. - ------------------- - Driver Functions ------------------- - -All functions you will be implementing in this document have the return value -meaning of 0 for success and non-zero for failure. - - ---------- - Register - ---------- - -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: -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: -int ape_register(bd_t *bis, int iobase) -{ - struct ape_priv *priv; - struct eth_device *dev; - - priv = malloc(sizeof(*priv)); - if (priv == NULL) - return 1; - - dev = malloc(sizeof(*dev)); - if (dev == NULL) { - free(priv); - return 1; - } - - /* 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_CMD_MII) - miiphy_register(dev->name, ape_mii_read, ape_mii_write); -#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. - - ----------- - Callbacks - ----------- - -Now that we've registered with the ethernet layer, we can start getting some -real work done. You will need five functions: - int ape_init(struct eth_device *dev, bd_t *bis); - int ape_send(struct eth_device *dev, volatile void *packet, int length); - int ape_recv(struct eth_device *dev); - int ape_halt(struct eth_device *dev); - int ape_write_hwaddr(struct eth_device *dev); - -The init function checks the hardware (probing/identifying) 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 dev->enetaddr -member. 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). You should not return until the -transmission is complete, and you should leave the state such that the send -function can be called multiple times in a row. - -The recv function should process packets as long as the hardware has them -readily available before returning. i.e. you should drain the hardware fifo. -For each packet you receive, you should call the NetReceive() function on it -along with the packet length. The common code sets up packet buffers for you -already in the .bss (NetRxPackets), so there should be no need to allocate your -own. This doesn't mean you must use the NetRxPackets array however; you're -free to call the NetReceive() function with any buffer you wish. So the pseudo -code here would look something like: -int ape_recv(struct eth_device *dev) -{ - int length, i = 0; - ... - while (packets_are_available()) { - ... - length = ape_get_packet(&NetRxPackets[i]); - ... - NetReceive(&NetRxPackets[i], length); - ... - if (++i >= PKTBUFSRX) - i = 0; - ... - } - ... - return 0; -} - -The halt 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 -init function), so make sure it can handle this sort of thing. - -The write_hwaddr function should program the MAC address stored in dev->enetaddr -into the Ethernet controller. - -So the call graph at this stage would look something like: -some net operation (ping / tftp / whatever...) - eth_init() - dev->init() - eth_send() - dev->send() - eth_rx() - dev->recv() - eth_halt() - dev->halt() - ------------------------------ - CONFIG_MII / 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. - -After you have called eth_register() in your driver's register function, add -a call to miiphy_register() like so: -#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) - miiphy_register(dev->name, mii_read, mii_write); -#endif - -And then define the mii_read and mii_write functions if you haven't already. -Their syntax is straightforward: - int mii_read(char *devname, uchar addr, uchar reg, ushort *val); - int mii_write(char *devname, uchar addr, uchar reg, ushort val); - -The read function should read the register 'reg' from the phy at address 'addr' -and store the result in the pointer 'val'. The implementation for the write -function should logically follow. diff --git a/qemu/roms/u-boot/doc/README.enetaddr b/qemu/roms/u-boot/doc/README.enetaddr deleted file mode 100644 index 1eaeaf941..000000000 --- a/qemu/roms/u-boot/doc/README.enetaddr +++ /dev/null @@ -1,116 +0,0 @@ ---------------------------------- - 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", ...) (see CONFIG_ETHADDR) - 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. -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 eth_parse_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]; -eth_parse_enetaddr(addr, enetaddr); -/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */ - - * int eth_getenv_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_ether_addr() is used -to determine address validity. -uchar enetaddr[6]; -if (!eth_getenv_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_setenv_enetaddr(char *name, const uchar *enetaddr); - -Store the MAC address into the named environment variable. The return value is -the same as the setenv() function. -uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 }; -eth_setenv_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/qemu/roms/u-boot/doc/README.ext4 b/qemu/roms/u-boot/doc/README.ext4 deleted file mode 100644 index 9a2de5088..000000000 --- a/qemu/roms/u-boot/doc/README.ext4 +++ /dev/null @@ -1,59 +0,0 @@ -This patch series adds support for ext4 ls,load and write features in uboot -Journaling is supported for write feature. - -To enable support for the ext4 (and ext2) filesystem implementation, -#define CONFIG_FS_EXT4 - -If you want write support, -#define CONFIG_EXT4_WRITE - -To Enable ext2 ls and load commands, modify the board specific config file with -#define CONFIG_CMD_EXT2 -This automatically defines CONFIG_FS_EXT4 for you. - -To Enable ext4 ls and load commands, modify the board specific config file with -#define CONFIG_CMD_EXT4 -This automatically defines CONFIG_FS_EXT4 for you. - -To enable ext4 write command, modify the board specific config file with -#define CONFIG_CMD_EXT4 -#define CONFIG_CMD_EXT4_WRITE -These automatically define CONFIG_FS_EXT4 and CONFIG_EXT4_WRITE for you. - -Also relevant are the generic filesystem commands, -#define CONFIG_CMD_FS_GENERIC -This does not automatically enable EXT4 support for you. - -Steps to test: - -1. After applying the patch, ext4 specific commands can be seen - in the boot loader prompt using - UBOOT #help - - ext4load- load binary file from a Ext4 file system - ext4ls - list files in a directory (default /) - ext4write- create a file in ext4 formatted partition - -2. To list the files in ext4 formatted partition, execute - 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, execute - ext4load <interface> <dev[:part]> [addr] [filename] [bytes] - For example: - UBOOT #ext4load mmc 2:2 0x30007fc0 uImage - -4. To write a file to a 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/qemu/roms/u-boot/doc/README.falcon b/qemu/roms/u-boot/doc/README.falcon deleted file mode 100644 index 82a254b2e..000000000 --- a/qemu/roms/u-boot/doc/README.falcon +++ /dev/null @@ -1,224 +0,0 @@ -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. -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_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. -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/qemu/roms/u-boot/doc/README.fdt-control b/qemu/roms/u-boot/doc/README.fdt-control deleted file mode 100644 index 86bae6816..000000000 --- a/qemu/roms/u-boot/doc/README.fdt-control +++ /dev/null @@ -1,186 +0,0 @@ -# -# Copyright (c) 2011 The Chromium OS Authors. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -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. -It is currently supported on ARM, x86 and Microblaze - other architectures -will need to add code to their arch/xxx/lib/board.c file to locate the -FDT. Alternatively you can enable generic board support on your board -(with CONFIG_SYS_GENERIC_BOARD) if this is available (as it is for -PowerPC). For ARM, Tegra and Exynos5 have device trees available for -common devices. - - -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 here: - - git://jdl.com/software/dtc.git - -For example: - - $ git clone git://jdl.com/software/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). - -If CONFIG_OF_SEPARATE is defined, then it will be built and placed in -a u-boot.dtb file alongside u-boot.bin. A common approach is then to -join the two: - - cat u-boot.bin u-boot.dtb >image.bin - -and then flash image.bin onto your board. - -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. - -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). - -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> - - -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/qemu/roms/u-boot/doc/README.fec_mxc b/qemu/roms/u-boot/doc/README.fec_mxc deleted file mode 100644 index 72a1d595f..000000000 --- a/qemu/roms/u-boot/doc/README.fec_mxc +++ /dev/null @@ -1,27 +0,0 @@ -U-boot config options used in fec_mxc.c - -CONFIG_FEC_MXC - Selects fec_mxc.c to be compiled into u-boot. - -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. diff --git a/qemu/roms/u-boot/doc/README.fsl-ddr b/qemu/roms/u-boot/doc/README.fsl-ddr deleted file mode 100644 index 1243a1222..000000000 --- a/qemu/roms/u-boot/doc/README.fsl-ddr +++ /dev/null @@ -1,430 +0,0 @@ -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 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/qemu/roms/u-boot/doc/README.fsl-hwconfig b/qemu/roms/u-boot/doc/README.fsl-hwconfig deleted file mode 100644 index e752505da..000000000 --- a/qemu/roms/u-boot/doc/README.fsl-hwconfig +++ /dev/null @@ -1,46 +0,0 @@ -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/qemu/roms/u-boot/doc/README.fsl_iim b/qemu/roms/u-boot/doc/README.fsl_iim deleted file mode 100644 index e087f5e0e..000000000 --- a/qemu/roms/u-boot/doc/README.fsl_iim +++ /dev/null @@ -1,48 +0,0 @@ -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/qemu/roms/u-boot/doc/README.fuse b/qemu/roms/u-boot/doc/README.fuse deleted file mode 100644 index 1bc91c44a..000000000 --- a/qemu/roms/u-boot/doc/README.fuse +++ /dev/null @@ -1,67 +0,0 @@ -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/qemu/roms/u-boot/doc/README.generic-board b/qemu/roms/u-boot/doc/README.generic-board deleted file mode 100644 index 17da0b9f8..000000000 --- a/qemu/roms/u-boot/doc/README.generic-board +++ /dev/null @@ -1,189 +0,0 @@ -# -# (C) Copyright 2014 Google, Inc -# Simon Glass <sjg@chromium.org> -# -# SPDX-License-Identifier: GPL-2.0+ -# - -DEPRECATION NOTICE FOR arch/<arch>/lib/board.c - -For board maintainers: Please submit patches for boards you maintain before -July 2014, to make them use generic board. - -For architecture maintainers: Please submit patches to remove your -architecture-specific board.c file before October 2014. - - -Background ----------- - -U-Boot has traditionally had a board.c file for each architecture. This has -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 a year ago in March 2013 (further motivation is -provided in the cover letter below). - - -What has changed? ------------------ - -The main change is that the arch/<arch>/lib/board.c file is being 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_t structures now have a core set of -fields which are common to all architectures. Architecture-specific fields -have been moved to separate structures. - - -Supported Arcthitectures ------------------------- - -If you are unlucky then your architecture may not support generic board. -The following architectures are supported at the time of writing: - - arc - arm - powerpc - sandbox - x86 - -If your architecture is not supported, you need to adjust your -arch/<arch>/config.mk file to include: - - __HAVE_ARCH_GENERIC_BOARD := y - -and test it with a suitable board, as follows. - - -Adding Support for your Board ------------------------------ - -To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in -your board config header file. - -Test that U-Boot still functions correctly on your board, and fix any -problems you find. Don't be surprised if there are no problems - generic -board has had a reasonable amount of testing with common boards. - - -DeadLine --------- - -Please don't take this the wrong way - there is no intent to make your life -miserable, and we have the greatest respect and admiration for U-Boot users. -However, with any migration there has to be a period where the old way is -deprecated and removed. Every patch to the deprecated code introduces a -potential breakage in the new unused code. Therefore: - -Boards or architectures not converted over to general board by the -end of 2014 may be forcibly changed over (potentially causing run-time -breakage) or removed. - - - -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 naturely diverge since there is limited -pressure to compare features or even CONFIG options against simiilar things -in other board.c files. - -4. New architectures must implement all the features all over again, and -sometimes in subtley 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 diff --git a/qemu/roms/u-boot/doc/README.generic_usb_ohci b/qemu/roms/u-boot/doc/README.generic_usb_ohci deleted file mode 100644 index ba7cea83c..000000000 --- a/qemu/roms/u-boot/doc/README.generic_usb_ohci +++ /dev/null @@ -1,63 +0,0 @@ -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 usb_board_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 and -mpc5xxx. 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/qemu/roms/u-boot/doc/README.gpt b/qemu/roms/u-boot/doc/README.gpt deleted file mode 100644 index ec0156d8a..000000000 --- a/qemu/roms/u-boot/doc/README.gpt +++ /dev/null @@ -1,190 +0,0 @@ -# -# Copyright (C) 2012 Samsung Electronics -# -# Lukasz Majewski <l.majewski@samsung.com> -# -# -# SPDX-License-Identifier: GPL-2.0+ - -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 Linux data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 - -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 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: - "partitions=uuid_disk=...;name=u-boot,size=60MiB,uuid=...; - name=kernel,size=60MiB,uuid=...;" - or - "partitions=uuid_disk=${uuid_gpt_disk};name=${uboot_name}, - size=${uboot_size},uuid=${uboot_uuid};" - - Fields 'name', 'size' and 'uuid' are mandatory for every partition. - The field 'start' is optional. - - option: CONFIG_RANDOM_UUID - If any partition "UUID" no exists then it is randomly generated. - -2. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT' - -2. From u-boot prompt type: - gpt write mmc 0 $partitions - -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/qemu/roms/u-boot/doc/README.hwconfig b/qemu/roms/u-boot/doc/README.hwconfig deleted file mode 100644 index b6ddb438c..000000000 --- a/qemu/roms/u-boot/doc/README.hwconfig +++ /dev/null @@ -1,50 +0,0 @@ -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/qemu/roms/u-boot/doc/README.idma2intr b/qemu/roms/u-boot/doc/README.idma2intr deleted file mode 100644 index 1828b5130..000000000 --- a/qemu/roms/u-boot/doc/README.idma2intr +++ /dev/null @@ -1,10 +0,0 @@ -(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com> - -Attached is an IDMA example code for MPC8260/PPCBoot. I had tried to -search around and could not find any for implementing IDMA, so -implemented one. Its not coded in the best way, but works. - -Also, I was able to test the IDMA specific code under Linux also -(with modifications). My requirement was to implement it for -CompactFlash implemented in memory mode, and it works for it under -PPCBoot and Linux. diff --git a/qemu/roms/u-boot/doc/README.imx25 b/qemu/roms/u-boot/doc/README.imx25 deleted file mode 100644 index 0ca21b6df..000000000 --- a/qemu/roms/u-boot/doc/README.imx25 +++ /dev/null @@ -1,10 +0,0 @@ -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/qemu/roms/u-boot/doc/README.imx27 b/qemu/roms/u-boot/doc/README.imx27 deleted file mode 100644 index 6f92cb47c..000000000 --- a/qemu/roms/u-boot/doc/README.imx27 +++ /dev/null @@ -1,10 +0,0 @@ -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/qemu/roms/u-boot/doc/README.imx31 b/qemu/roms/u-boot/doc/README.imx31 deleted file mode 100644 index 91ef76688..000000000 --- a/qemu/roms/u-boot/doc/README.imx31 +++ /dev/null @@ -1,29 +0,0 @@ -U-Boot for Freescale i.MX31 - -This file contains information for the port of U-Boot to the Freescale -i.MX31 SoC. - -1. CONFIGURATION OPTIONS/SETTINGS ---------------------------------- - -1.1 Configuration of MC13783 SPI bus ------------------------------------- - The power management companion chip MC13783 is connected to the - i.MX31 via an SPI bus. Use the following configuration options - to setup the bus and chip select used for a particular board. - - CONFIG_MC13783_SPI_BUS -- defines the SPI bus the MC13783 is connected to. - Note that 0 is CSPI1, 1 is CSPI2 and 2 is CSPI3. - CONFIG_MC13783_SPI_CS -- define the chip select the MC13783 s connected to. - -1.2 Timer precision -------------------- - CONFIG_MX31_TIMER_HIGH_PRECISION - - Enable higher precision timer. The low-precision timer - (default) provides approximately 4% error, whereas the - high-precision timer is about 0.4% accurate. The extra - accuracy is achieved at the cost of higher computational - overhead, which, in places where time is measured, should - not be critical, so, it should be safe to enable this - option. diff --git a/qemu/roms/u-boot/doc/README.imx5 b/qemu/roms/u-boot/doc/README.imx5 deleted file mode 100644 index c5312b69d..000000000 --- a/qemu/roms/u-boot/doc/README.imx5 +++ /dev/null @@ -1,28 +0,0 @@ -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). diff --git a/qemu/roms/u-boot/doc/README.imx6 b/qemu/roms/u-boot/doc/README.imx6 deleted file mode 100644 index 437af2fd9..000000000 --- a/qemu/roms/u-boot/doc/README.imx6 +++ /dev/null @@ -1,86 +0,0 @@ -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. - -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 diff --git a/qemu/roms/u-boot/doc/README.imximage b/qemu/roms/u-boot/doc/README.imximage deleted file mode 100644 index dcda2005a..000000000 --- a/qemu/roms/u-boot/doc/README.imximage +++ /dev/null @@ -1,239 +0,0 @@ ---------------------------------------------- -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/\ - imx-common/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 121 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: - - cilynder = <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/qemu/roms/u-boot/doc/README.iomux b/qemu/roms/u-boot/doc/README.iomux deleted file mode 100644 index 044240db3..000000000 --- a/qemu/roms/u-boot/doc/README.iomux +++ /dev/null @@ -1,90 +0,0 @@ -/* - * (C) Copyright 2008 - * Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de> - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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/qemu/roms/u-boot/doc/README.kwbimage b/qemu/roms/u-boot/doc/README.kwbimage deleted file mode 100644 index 13f6f92f6..000000000 --- a/qemu/roms/u-boot/doc/README.kwbimage +++ /dev/null @@ -1,104 +0,0 @@ ---------------------------------------------- -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 BUILD_DIR=/tmp/build - make distclean - make yourboard_config - make $BUILD_DIR/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/qemu/roms/u-boot/doc/README.link-local b/qemu/roms/u-boot/doc/README.link-local deleted file mode 100644 index 9586eca26..000000000 --- a/qemu/roms/u-boot/doc/README.link-local +++ /dev/null @@ -1,75 +0,0 @@ ------------------------------------------- - 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 NetLoop -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 NetLoop 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/qemu/roms/u-boot/doc/README.lynxkdi b/qemu/roms/u-boot/doc/README.lynxkdi deleted file mode 100644 index 076f01862..000000000 --- a/qemu/roms/u-boot/doc/README.lynxkdi +++ /dev/null @@ -1,57 +0,0 @@ - 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/qemu/roms/u-boot/doc/README.m54418twr b/qemu/roms/u-boot/doc/README.m54418twr deleted file mode 100644 index f69ae0191..000000000 --- a/qemu/roms/u-boot/doc/README.m54418twr +++ /dev/null @@ -1,244 +0,0 @@ -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 - -- 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_M54418TWR -- define for M54418TWR board - -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/qemu/roms/u-boot/doc/README.m68k b/qemu/roms/u-boot/doc/README.m68k deleted file mode 100644 index c85febc1f..000000000 --- a/qemu/roms/u-boot/doc/README.m68k +++ /dev/null @@ -1,166 +0,0 @@ - -U-Boot for Motorola M68K - -==================================================================== -History - -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 M68K series of CPUs. - -1. OVERVIEW ------------ -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. - -Although this port is intended to cover all M68k processors, only -the parts for the Motorola Coldfire MCF5272 and MCF5282 are -implemented at the moment. Additional CPUs and boards will be -hopefully added soon! - - -2. SUPPORTED CPUs ------------------ - -2.1 Motorola Coldfire MCF5272 ------------------------------ -CPU specific code is located in: arch/m68k/cpu/mcf52x2 - - -2.1 Motorola Coldfire MCF5282 ------------------------------ -CPU specific code is located in: arch/m68k/cpu/mcf52x2 - -The MCF5282 Port no longer needs a preloader and can place in external or -internal FLASH. - - -3. SUPPORTED BOARDs -------------------- - -3.1 Motorola M5272C3 EVB ------------------------- -Board specific code is located in: board/m5272c3 - -To configure the board, type: make M5272C3_config - -U-Boot Memory Map: ------------------- -0xffe00000 - 0xffe3ffff u-boot -0xffe04000 - 0xffe05fff environment (embedded in u-boot!) -0xffe40000 - 0xffffffff free for linux/applications - - -3.2 Motorola M5282 EVB ------------------------- -Board specific code is located in: board/m5282evb - -To configure the board, type: make M5272C3_config - -At the moment the code isn't fully implemented and still needs a pre-loader! -The preloader must initialize the processor and then start u-boot. The board -must be configured for a pre-loader (see 4.1) - -For the preloader, please see -http://mailman.uclinux.org/pipermail/uclinux-dev/2003-December/023384.html - -U-boot is configured to run at 0x20000 at default. This can be configured by -change CONFIG_SYS_TEXT_BASE in board/m5282evb/config.mk and CONFIG_SYS_MONITOR_BASE in -include/configs/M5282EVB.h. - -3.2 BuS EB+MCF-EV123 ---------------------- - -Board specific code is located in: board/bus/EB+MCF-EV123 - -To configure the board, type: - -make EB+MCF-EV123_config for external FLASH -make EB+MCF-EV123_internal_config for internal FLASH - - -4. CONFIGURATION OPTIONS/SETTINGS ----------------------------------- - -4.1 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. - -4.1 MCF5272 specific Options/Settings -------------------------------------- - -CONFIG_MCF52x2 -- defined for all MCF52x2 CPUs -CONFIG_M5272 -- defined for all Motorola MCF5272 CPUs - -CONFIG_MONITOR_IS_IN_RAM - -- defined if u-boot is loaded by a pre-loader - -CONFIG_SYS_MBAR -- defines the base address of the MCF5272 configuration registers -CONFIG_SYS_INIT_RAM_ADDR - -- defines the base address of the MCF5272 internal SRAM -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_BRx_PRELIM -- defines the contents of the Chip Select Base Registers -CONFIG_SYS_ORx_PRELIM -- defines the contents of the Chip Select Option Registers - -CONFIG_SYS_PxDDR -- defines the contents of the Data Direction Registers -CONFIG_SYS_PxDAT -- defines the contents of the Data Registers -CONFIG_SYS_PXCNT -- defines the contents of the Port Configuration Registers - - -4.2 MCF5282 specific Options/Settings -------------------------------------- - -CONFIG_MCF52x2 -- defined for all MCF52x2 CPUs -CONFIG_M5282 -- defined for all Motorola MCF5282 CPUs - -CONFIG_MONITOR_IS_IN_RAM - -- defined if u-boot is loaded by a pre-loader - -CONFIG_SYS_MBAR -- defines the base address of the MCF5282 internal register space -CONFIG_SYS_INIT_RAM_ADDR - -- defines the base address of the MCF5282 internal SRAM -CONFIG_SYS_INT_FLASH_BASE - -- defines the base address of the MCF5282 internal Flash memory -CONFIG_SYS_ENET_BD_BASE - -- defines the base address of the FEC buffer descriptors - -CONFIG_SYS_MFD - -- defines the PLL Multiplication Factor Devider - (see table 9-4 of MCF user manual) -CONFIG_SYS_RFD -- defines the PLL Reduce Frecuency 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_RO -- if set to 0 chip select x is read/wirte - else chipselct is read only -CONFIG_SYS_CSx_WS -- defines the number of wait states of chip select x - -CONFIG_SYS_PxDDR -- defines the contents of the Data Direction Registers -CONFIG_SYS_PxDAT -- defines the contents of the Data Registers -CONFIG_SYS_PXCNT -- defines the contents of the Port Configuration Registers - -CONFIG_SYS_PxPAR -- defines the function of ports - - -5. COMPILER ------------ -To create U-Boot the gcc-2.95.3 compiler set (m68k-elf-20030314) from uClinux.org was used. -You can download it from: http://www.uclinux.org/pub/uClinux/m68k-elf-tools/ diff --git a/qemu/roms/u-boot/doc/README.malta b/qemu/roms/u-boot/doc/README.malta deleted file mode 100644 index c8db8a0c3..000000000 --- a/qemu/roms/u-boot/doc/README.malta +++ /dev/null @@ -1,16 +0,0 @@ -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/qemu/roms/u-boot/doc/README.marubun-pcmcia b/qemu/roms/u-boot/doc/README.marubun-pcmcia deleted file mode 100644 index d3563a3cd..000000000 --- a/qemu/roms/u-boot/doc/README.marubun-pcmcia +++ /dev/null @@ -1,65 +0,0 @@ - -U-Boot MARUBUN MR-SHPC-01 PCMCIA controller driver - Last update 21/11/2007 by Nobuhiro Iwamatsu - -======================================================================================== - -0. What's this? - This driver supports MARUBUN MR-SHPC-01. - url: http://www.marubun.co.jp/product/semicon/devices/qgc18e0000002n2z.html - (Sorry Japanese only.) - - This chip is used with SuperH well, and adopted by the - reference board. - ex. * MS7750SE01 - * MS7722SE01 - * other - - This chip doesn't support CardBus. - -1. base source code - The code is based on sources from the Linux kernel - ( arch/sh/kernel/cf-enabler.c ). - -2. How to use - The options you have to specify in the config file are (with the - value for my board as an example): - - * CONFIG_MARUBUN_PCCARD - If you want to use this device driver, should define CONFIG_MARUBUN_PCCARD. - ex. #define CONFIG_MARUBUN_PCCARD - - * CONFIG_PCMCIA_SLOT_A - Most devices have only one slot. You should define CONFIG_PCMCIA_SLOT_A . - ex. #define CONFIG_PCMCIA_SLOT_A 1 - - * CONFIG_SYS_MARUBUN_MRSHPC - This is MR-SHPC-01 PCMCIA controler base address. - You should do the setting matched to your environment. - ex. #define CONFIG_SYS_MARUBUN_MRSHPC 0xb03fffe0 - ( for MS7722SE01 environment ) - - * CONFIG_SYS_MARUBUN_MW1 - This is MR-SHPC-01 memory window base address. - You should do the setting matched to your environment. - ex. #define CONFIG_SYS_MARUBUN_MW1 0xb0400000 - ( for MS7722SE01 environment ) - - * CONFIG_SYS_MARUBUN_MW1 - This is MR-SHPC-01 attribute window base address. - You should do the setting matched to your environment. - ex. #define CONFIG_SYS_MARUBUN_MW2 0xb0500000 - ( for MS7722SE01 environment ) - - * CONFIG_SYS_MARUBUN_MW1 - This is MR-SHPC-01 I/O window base address. - You should do the setting matched to your environment. - ex. #define CONFIG_SYS_MARUBUN_IO 0xb0600000 - ( for MS7722SE01 environment ) - -3. Other - * Check Compact Flash only. - * Maybe, NE2000 compatible NIC is sure to move. - -Copyright (c) 2007 - Nobuhiro Iwamatsu <iwamatsu@nigaur.org> diff --git a/qemu/roms/u-boot/doc/README.memory-test b/qemu/roms/u-boot/doc/README.memory-test deleted file mode 100644 index eb60e8d83..000000000 --- a/qemu/roms/u-boot/doc/README.memory-test +++ /dev/null @@ -1,98 +0,0 @@ -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/qemu/roms/u-boot/doc/README.menu b/qemu/roms/u-boot/doc/README.menu deleted file mode 100644 index ad520ab3a..000000000 --- a/qemu/roms/u-boot/doc/README.menu +++ /dev/null @@ -1,125 +0,0 @@ -/* - * Copyright 2010-2011 Calxeda, Inc. - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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_MENU_SHOW. You have to code the int menu_show(int bootdelay) -function, which handle your menu. This function returns the remaining -bootdelay. - -Interfaces ----------- -#include "menu.h" - -/* - * 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. - -#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/qemu/roms/u-boot/doc/README.mips b/qemu/roms/u-boot/doc/README.mips deleted file mode 100644 index b28f6285c..000000000 --- a/qemu/roms/u-boot/doc/README.mips +++ /dev/null @@ -1,54 +0,0 @@ - -Notes for the MIPS architecture port of U-Boot - -Toolchains ----------- - - http://www.denx.de/wiki/DULG/ELDK - ELDK < DULG < DENX - - http://www.emdebian.org/crosstools.html - Embedded Debian -- Cross-development toolchains - - http://buildroot.uclibc.org/ - Buildroot - -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, - 1) insert flush_cache(all) before calling dcache_disable(), or - 2) 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/qemu/roms/u-boot/doc/README.mpc5xx b/qemu/roms/u-boot/doc/README.mpc5xx deleted file mode 100644 index df51b5cf5..000000000 --- a/qemu/roms/u-boot/doc/README.mpc5xx +++ /dev/null @@ -1,48 +0,0 @@ - -Summary: -======== - -This file contains information about the port of U-Boot to the -Motorola mpc5xx series of CPUs. Most of this code is taken from -existing code mainly from the mpc8xx port. In contrast to mpc8xx, -the mpc5xx has no CPM, MMU and cache facilities. - -The implemented features have been tested on the cmi board, a -customer specific board (see README.cmi). - -Hence this port is only tested on the cmi board further possible -tests on other boards will be very valuable. - -Not Tested Features: -==================== - -* System calls -* Interrupts - -Added or Changed Files: -======================= - -u-boot-0.2.0/common/cmd_boot.c -u-boot-0.2.0/common/cmd_reginfo.c -u-boot-0.2.0/common/environment.c -u-boot-0.2.0/arch/powerpc/cpu/mpc5xx/* -u-boot-0.2.0/include/cmd_reginfo.h -u-boot-0.2.0/include/common.h -u-boot-0.2.0/include/ppc_asm.tmpl -u-boot-0.2.0/include/watchdog.h -u-boot-0.2.0/include/mpc5xx.h -u-boot-0.2.0/include/status_led.h -u-boot-0.2.0/include/asm-ppc/u-boot.h -u-boot-0.2.0/include/asm-ppc/5xx_immap.h -u-boot-0.2.0/arch/powerpc/lib/board.c -u-boot-0.2.0/arch/powerpc/lib/cache.c -u-boot-0.2.0/arch/powerpc/lib/time.c -u-boot-0.2.0/Makefile -u-boot-0.2.0/CREDITS -u-boot-0.2.0/doc/README.mpc5xx -u-boot-0.2.0/doc/README.cmi -u-boot-0.2.0/README -u-boot-0.2.0/MAKEALL - -Regards, -Martin diff --git a/qemu/roms/u-boot/doc/README.mpc74xx b/qemu/roms/u-boot/doc/README.mpc74xx deleted file mode 100644 index f81f1c2e8..000000000 --- a/qemu/roms/u-boot/doc/README.mpc74xx +++ /dev/null @@ -1,22 +0,0 @@ -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/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc b/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc deleted file mode 100644 index 0029f0875..000000000 --- a/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc +++ /dev/null @@ -1,154 +0,0 @@ -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/qemu/roms/u-boot/doc/README.mpc83xxads b/qemu/roms/u-boot/doc/README.mpc83xxads deleted file mode 100644 index d4561034b..000000000 --- a/qemu/roms/u-boot/doc/README.mpc83xxads +++ /dev/null @@ -1,98 +0,0 @@ -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_MPC8349ADS MPC8349ADS board 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/qemu/roms/u-boot/doc/README.mpc85xx b/qemu/roms/u-boot/doc/README.mpc85xx deleted file mode 100644 index f9b023f28..000000000 --- a/qemu/roms/u-boot/doc/README.mpc85xx +++ /dev/null @@ -1,166 +0,0 @@ -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_SECURE_BOOT) -RAMBOOT(SD, SPI & NAND boot) - defined(CONFIG_SYS_RAMBOOT) -RAMBOOT Secure (SD, SPI & NAND) - defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) -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_SECURE_BOOT) - 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_SECURE_BOOT) - 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 -> init_func_ram -> initdram - 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/qemu/roms/u-boot/doc/README.mpc85xx-sd-spi-boot b/qemu/roms/u-boot/doc/README.mpc85xx-sd-spi-boot deleted file mode 100644 index d5043ccb6..000000000 --- a/qemu/roms/u-boot/doc/README.mpc85xx-sd-spi-boot +++ /dev/null @@ -1,81 +0,0 @@ ----------------------------------------- -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 -P2010DS 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 -P2010RDB 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 -P1014RDB config_ddr3_1gb_p1014rdb_800M.dat -P1021RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat -P1012RDB config_ddr3_1gb_p1_p2_rdb_pc_800M.dat -P1022DS config_ddr3_2gb_p1022ds.dat -P1013DS config_ddr3_2gb_p1022ds.dat -P1024RDB config_ddr3_1gb_p1_p2_rdb_pc_667M.dat -P1013RDB 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/qemu/roms/u-boot/doc/README.mpc85xx-spin-table b/qemu/roms/u-boot/doc/README.mpc85xx-spin-table deleted file mode 100644 index 8da768a2a..000000000 --- a/qemu/roms/u-boot/doc/README.mpc85xx-spin-table +++ /dev/null @@ -1,26 +0,0 @@ -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/qemu/roms/u-boot/doc/README.mpc85xxads b/qemu/roms/u-boot/doc/README.mpc85xxads deleted file mode 100644 index 28bbcbe09..000000000 --- a/qemu/roms/u-boot/doc/README.mpc85xxads +++ /dev/null @@ -1,303 +0,0 @@ -Motorola MPC8540ADS and MPC8560ADS board - -Created 10/15/03 Xianghua Xiao -Updated 13-July-2004 Jon Loeliger ------------------------------------------ - -0. Toolchain - - 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 8540/8560 ADS code base is known to compile using: - gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a) - - -1. SWITCH SETTINGS & JUMPERS - -1.0 Nomenclature - - For some reason, the HW designers describe the switch settings - in terms of 0 and 1, and then map that to physical switches where - the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1. - Luckily, we're SW types and virtual settings are handled daily. - - The switches for the Rev A board are numbered differently than - for the Pilot board. Oh yeah. - - Switch bits are numbered 1 through, like, 4 6 8 or 10, but the - bits may contribute to signals that are numbered based at 0, - and some of those signals may be high-bit-number-0 too. Heed - well the names and labels and do not get confused. - - "Off" == 1 - "On" == 0 - - SW18 is switch 18 as silk-screened onto the board. - SW4[8] is the bit labeled 8 on Switch 4. - SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2 - SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3 - -1.1 For the MPC85xxADS Pilot Board - - First, make sure the board default setting is consistent with the document - shipped with your board. Then apply the following changes: - SW3[1-6]="all OFF" (boot from 32bit flash, no boot sequence is used) - SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560) - SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode) - SW11[7]='ON' (rev2), 'OFF' (rev1) - SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector) - SW22[1-4]="OFF OFF ON OFF" - SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF" - J1 = "Enable Prog" (Make sure your flash is programmable for development) - - If you want to test PCI functionality with a 33Mhz PCI card, you will - have to change the system clock from the default 66Mhz to 33Mhz by - setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need - double your platform clock(SW6) because the system clock is now only - half of its original value. For example, if at 66MHz your system - clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10. - - SW17[8] ------+ SW6 - SW15[1] ----+ | [0:1] - V V V V - 33MHz 1 1 1 0 - 66MHz 0 0 0 1 - - Hmmm... That SW6 setting description is incomplete but it works. - - -1.3 For the MPC85xxADS Rev A Board - - As shipped, the board should be a 33MHz PCI bus with a CPU Clock - rate of 825 +/- fuzz: - - Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz - - For 33MHz PCI, the switch settings should be like this: - - SW18[7:1] = 0100001 = M==33 => 33MHz - SW18[8] = 1 => PWD Divider == 16 - SW16[1:2] = 11 => N == 16 as PWD==1 - - Use the magical formula: - Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz - - SW7[1:4] = 1010 = 10 => 10 x 33 = 330 CCB Sysclk - SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock - - - For 66MHz PCI, the switch settings should be like this: - - SW18[7:1] = 0100001 = M==33 => 33MHz - SW18[8] = 0 => PWD Divider == 1 - SW16[1:2] = 01 => N == 8 as PWD == 0 - - Use the magical formula: - Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz - - SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB Sysclk - SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock - - In order to use PCI-X (only in the first PCI slot. The one with - the RIO connector), you need to set SW1[4] (config) to 1 (off). - Also, configure the board to run PCI at 66 MHz. - -2. MEMORY MAP TO WORK WITH LINUX KERNEL - -2.1. For the initial bringup, we adopted a consistent memory scheme - between u-boot and linux kernel, you can customize it based on your - system requirements: - - 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 - 0xff00_0000 0xffff_ffff FLASH (boot bank) 16M - -2.2 We are submitting Linux kernel patches for MPC8540 and MPC8560. You - can download them from linuxppc-2.4 public source. Please make sure the - kernel's ppcboot.h is consistent with U-Boot's u-boot.h. You can use two - default configuration files as your starting points to configure the - kernel: - arch/powerpc/configs/mpc8540_ads_defconfig - arch/powerpc/configs/mpc8560_ads_defconfig - -3. DEFINITIONS AND COMPILATION - -3.1 Explanation on NEW definitions in: - include/configs/MPC8540ADS.h - include/configs/MPC8560ADS.h - - CONFIG_BOOKE BOOKE(e.g. Motorola MPC85xx, AMCC 440, etc) - CONFIG_E500 BOOKE e500 family(Motorola) - CONFIG_MPC85xx MPC8540,MPC8560 and their derivatives - CONFIG_MPC8540 MPC8540 specific - CONFIG_MPC8540ADS MPC8540ADS board specific - CONFIG_MPC8560ADS MPC8560ADS board specific - CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet for networking - CONFIG_SPD_EEPROM Use SPD EEPROM for DDR auto configuration, you can - also manual config the DDR after undef this - definition. - CONFIG_DDR_ECC only for ECC DDR module - CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN DLL fix on some ADS boards needed - for more stability. - CONFIG_HAS_FEC If an FEC is on chip, set to 1, else 0. - -Other than the above definitions, the rest in the config files are -straightforward. - - -3.2 Compilation - - Assuming you're using BASH shell: - - export CROSS_COMPILE=your-cross-compile-prefix - cd u-boot - make distclean - make MPC8560ADS_config (or make MPC8540ADS_config) - make - -4. Notes: - -4.1 When connecting with kermit, the following commands must be present.in - your .kermrc file. These are especially important when booting as - MPC8560, as the serial console will not work without them: - - set speed 115200 - set carrier-watch off - set handshake none - set flow-control none - robust - - -4.2 Sometimes after U-Boot is up, the 'tftp' won't work well with TSEC - ethernet. If that happens, you can try the following steps to make - network work: - - MPC8560ADS>tftp 1000000 pImage - (if it hangs, use Ctrl-C to quit) - MPC8560ADS>nm fdf24524 - >0 - >1 - >. (to quit this memory operation) - MPC8560ADS>tftp 1000000 pImage - -4.3 If you're one of the early developers using the Rev1 8540/8560 chips, - please use U-Boot 1.0.0, as the newer silicon will only support Rev2 - and future revisions of 8540/8560. - - -4.4 Reflash U-boot Image using U-boot - - tftp 10000 u-boot.bin - protect off fff80000 ffffffff - erase fff80000 ffffffff - cp.b 10000 fff80000 80000 - - -4.5 Reflash U-Boot with a BDI-2000 - - BDI> erase 0xFFF80000 0x4000 0x20 - BDI> prog 0xfff80000 u-boot.bin.8560ads - BDI> verify - - -5. Screen dump MPC8540ADS board - -U-Boot 1.1.2(pq3-20040707-0) (Jul 6 2004 - 17:34:25) - -Freescale PowerPC - Core: E500, Version: 2.0, (0x80200020) - System: 8540, Version: 2.0, (0x80300020) - Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz - L1 D-cache 32KB, L1 I-cache 32KB enabled. -Board: ADS - PCI1: 32 bit, 66 MHz (compiled) -I2C: ready -DRAM: Initializing - SDRAM: 64 MB - DDR: 256 MB -FLASH: 16 MB -L2 cache enabled: 256KB -*** Warning - bad CRC, using default environment - -In: serial -Out: serial -Err: serial -Net: MOTO ENET0: PHY is Marvell 88E1011S (1410c62) -MOTO ENET1: PHY is Marvell 88E1011S (1410c62) -MOTO ENET2: PHY is Davicom DM9161E (181b881) -MOTO ENET0, MOTO ENET1, MOTO ENET2 -Hit any key to stop autoboot: 0 -=> -=> fli - -Bank # 1: Intel 28F640J3A (64 Mbit, 64 x 128K) - Size: 16 MB in 64 Sectors - Sector Start Addresses: - FF000000 FF040000 FF080000 FF0C0000 FF100000 - FF140000 FF180000 FF1C0000 FF200000 FF240000 - FF280000 FF2C0000 FF300000 FF340000 FF380000 - FF3C0000 FF400000 FF440000 FF480000 FF4C0000 - FF500000 FF540000 FF580000 FF5C0000 FF600000 - FF640000 FF680000 FF6C0000 FF700000 FF740000 - FF780000 FF7C0000 FF800000 FF840000 FF880000 - FF8C0000 FF900000 FF940000 FF980000 FF9C0000 - FFA00000 FFA40000 FFA80000 FFAC0000 FFB00000 - FFB40000 FFB80000 FFBC0000 FFC00000 FFC40000 - FFC80000 FFCC0000 FFD00000 FFD40000 FFD80000 - FFDC0000 FFE00000 FFE40000 FFE80000 FFEC0000 - FFF00000 FFF40000 FFF80000 (RO) FFFC0000 (RO) - -=> bdinfo -memstart = 0x00000000 -memsize = 0x10000000 -flashstart = 0xFF000000 -flashsize = 0x01000000 -flashoffset = 0x00000000 -sramstart = 0x00000000 -sramsize = 0x00000000 -immr_base = 0xE0000000 -bootflags = 0xE4013F80 -intfreq = 825 MHz -busfreq = 330 MHz -ethaddr = 00:E0:0C:00:00:FD -eth1addr = 00:E0:0C:00:01:FD -eth2addr = 00:E0:0C:00:02:FD -IP addr = 192.168.1.253 -baudrate = 115200 bps - - -=> printenv -bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr -ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;bootm $loadaddr $ramdiskaddr -nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr -bootdelay=10 -baudrate=115200 -loads_echo=1 -ethaddr=00:E0:0C:00:00:FD -eth1addr=00:E0:0C:00:01:FD -eth2addr=00:E0:0C:00:02:FD -ipaddr=192.168.1.253 -serverip=192.168.1.1 -rootpath=/nfsroot -gatewayip=192.168.1.1 -netmask=255.255.255.0 -hostname=unknown -bootfile=your.uImage -loadaddr=200000 -netdev=eth0 -consoledev=ttyS0 -ramdiskaddr=400000 -ramdiskfile=your.ramdisk.u-boot -stdin=serial -stdout=serial -stderr=serial -ethact=MOTO ENET0 - -Environment size: 1020/8188 bytes diff --git a/qemu/roms/u-boot/doc/README.mpc85xxcds b/qemu/roms/u-boot/doc/README.mpc85xxcds deleted file mode 100644 index bc5db0ca8..000000000 --- a/qemu/roms/u-boot/doc/README.mpc85xxcds +++ /dev/null @@ -1,225 +0,0 @@ -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/qemu/roms/u-boot/doc/README.mxc_hab b/qemu/roms/u-boot/doc/README.mxc_hab deleted file mode 100644 index 43e64a279..000000000 --- a/qemu/roms/u-boot/doc/README.mxc_hab +++ /dev/null @@ -1,48 +0,0 @@ -High Assurance Boot (HAB) for i.MX6 CPUs - -To authenticate U-Boot only by the CPU there is no code required in -U-Boot itself. However, 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 Initial Vector Table contains a pointer to the CSF. Please see -doc/README.imximage for how to prepare u-boot.imx. - -The CSF itself is being generated by Freescale HAB tools. - -mkimage will output additional information about "HAB Blocks" -which can be used in the Freescale tooling to authenticate U-Boot -(entries in the CSF file). - -Image Type: Freescale IMX Boot Image -Image Ver: 2 (i.MX53/6 compatible) -Data Size: 327680 Bytes = 320.00 kB = 0.31 MB -Load Address: 177ff420 -Entry Point: 17800000 -HAB Blocks: 177ff400 00000000 0004dc00 - ^^^^^^^^ ^^^^^^^^ ^^^^^^^^ - | | | - | | -------- (1) - | | - | ------------------- (2) - | - --------------------------- (3) - -(1) Size of area in file u-boot.imx to sign - This area should include the IVT, the Boot Data the DCD - and U-Boot itself. -(2) Start of area in u-boot.imx to sign -(3) Start of area in RAM to authenticate - -CONFIG_SECURE_BOOT currently enables only an additional command -'hab_status' in U-Boot to retrieve the HAB status and events. This -can be useful while developing and testing HAB. - -Commands to generate a signed U-Boot using Freescale HAB tools: -cst --o U-Boot_CSF.bin < U-Boot.CSF -objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 \ - U-Boot_CSF.bin U-Boot_CSF_pad.bin -cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx - -NOTE: U-Boot_CSF.bin needs to be padded to the value specified in -the imximage.cfg file. diff --git a/qemu/roms/u-boot/doc/README.mxc_ocotp b/qemu/roms/u-boot/doc/README.mxc_ocotp deleted file mode 100644 index 7a2863cfd..000000000 --- a/qemu/roms/u-boot/doc/README.mxc_ocotp +++ /dev/null @@ -1,51 +0,0 @@ -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/qemu/roms/u-boot/doc/README.mxs b/qemu/roms/u-boot/doc/README.mxs deleted file mode 100644 index 0235a5aea..000000000 --- a/qemu/roms/u-boot/doc/README.mxs +++ /dev/null @@ -1,264 +0,0 @@ -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 - -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 ftp://ftp.denx.de/pub/tools/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 Denx 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" varible. - - 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" varible. - - 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. diff --git a/qemu/roms/u-boot/doc/README.mxsimage b/qemu/roms/u-boot/doc/README.mxsimage deleted file mode 100644 index 0d31cba1f..000000000 --- a/qemu/roms/u-boot/doc/README.mxsimage +++ /dev/null @@ -1,165 +0,0 @@ -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). - - 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" unstruction, 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. - -- If the verbose 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 verbose 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/qemu/roms/u-boot/doc/README.nand b/qemu/roms/u-boot/doc/README.nand deleted file mode 100644 index b91f1985d..000000000 --- a/qemu/roms/u-boot/doc/README.nand +++ /dev/null @@ -1,303 +0,0 @@ -NAND FLASH commands and notes - -See NOTE below!!! - -# (C) Copyright 2003 -# Dave Ellis, SIXNET, dge@sixnetio.com -# -# SPDX-License-Identifier: GPL-2.0+ - -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_CMD_NAND - Enables NAND support and commmands. - - CONFIG_CMD_NAND_TORTURE - Enables the torture command (see description of this command below). - - CONFIG_MTD_NAND_ECC_JFFS2 - Define this if you want the Error Correction Code information in - the out-of-band data to be formatted to match the JFFS2 file system. - CONFIG_MTD_NAND_ECC_YAFFS would be another useful choice for - someone to implement. - - 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/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/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: - - /* - * devnum is the device number to be used in nand commands - * and in mtd->name. Must be less than - * CONFIG_SYS_NAND_MAX_DEVICE. - */ - mtd = &nand_info[devnum]; - - /* chip is struct nand_chip, and is now provided by the driver. */ - mtd->priv = &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 - - if (nand_register(devnum)) - 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. - - CONFIG_BCH - Enables software based BCH ECC algorithm present in lib/bch.c - This is used by SoC platforms which do not have built-in ELM - hardware engine required for BCH ECC correction. - - -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_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. - -NOTE: -===== - -The current NAND implementation is based on what is in recent -Linux kernels. The old legacy implementation has been removed. - -If you have board code which used CONFIG_NAND_LEGACY, you'll need -to convert to the current NAND interface for it to continue to work. - -The Disk On Chip driver is currently broken and has been for some time. -There is a driver in drivers/mtd/nand, 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" - 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. - - -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/qemu/roms/u-boot/doc/README.nand-boot-ppc440 b/qemu/roms/u-boot/doc/README.nand-boot-ppc440 deleted file mode 100644 index 1e9c10264..000000000 --- a/qemu/roms/u-boot/doc/README.nand-boot-ppc440 +++ /dev/null @@ -1,60 +0,0 @@ ------------------------------ -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/qemu/roms/u-boot/doc/README.ne2000 b/qemu/roms/u-boot/doc/README.ne2000 deleted file mode 100644 index d5ae9a9eb..000000000 --- a/qemu/roms/u-boot/doc/README.ne2000 +++ /dev/null @@ -1,38 +0,0 @@ -This driver supports NE2000 compatible cards (those based on DP8390, -DP83902 and similar). It can be used with PCMCIA/CF cards provided -that the CCR is correctly initialized. - -The code is based on sources from the Linux kernel (pcnet_cs.c, -8390.h) and eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 -wonderful world are GPL, so this is, of course, GPL. - -I developed and tested this driver on a custom PXA255 based system and -with a billionton CF network card connected to the PCMCIA interface of -the micro (have a look at README.PXA_CF for the support of this port). - -The options you have to specify in the config file are (with the -value for my board as an example): - -#define CONFIG_DRIVER_NE2000 - -- Enables the driver - -#define CONFIG_DRIVER_NE2000_BASE (0x20000000+0x300) - -- Address where the board is mapped - -#define CONFIG_DRIVER_NE2000_CCR (0x28000000+0x3f8) - -- Address of the CCR (card configuration register). It could be found -by enabling DEBUG in cmd_pcmcia.c. If this is not defined nothing is -done as far as PCMCIA support is concerned. - -#define CONFIG_DRIVER_NE2000_VAL (0x20) - -- The value to be written in the CCR. It selects among different I/O -spaces that could be used by the card. - - -Enjoy! - -Christian Pellegrin <chri@ascensit.com> diff --git a/qemu/roms/u-boot/doc/README.nokia_rx51 b/qemu/roms/u-boot/doc/README.nokia_rx51 deleted file mode 100644 index 586ed7c1c..000000000 --- a/qemu/roms/u-boot/doc/README.nokia_rx51 +++ /dev/null @@ -1,104 +0,0 @@ -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). - -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 espace codes and the N900 HW keyboard input. USB tty works -but is disabled because it prevents the current Maemo kernel from booting. - -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 parition - * 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 sercon - Use serial port for control - * run usbcon - Use usbtty for control - * run vgacon - Use framebuffer and HW keyboard for control (default) - - * 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) - -Additional varuables 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 - -USB TTY: - - Maemo kernel 2.6.28 will crash if u-boot enable usb tty. So USB TTY is disabled. - For enabling USB TTY just add this line to file include/configs/nokia_rx51.h - - #define CONFIG_USB_TTY - - -ONENAND support: - - ONENAND support is disabled because not working yet and cause linux kernel to - crash or no access to mtd. For enabling ONENAND support add this line at begin - of file include/configs/nokia_rx51.h - - #define ONENAND_SUPPORT - - -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 first enable ONENAND support and then add this line at begin of file - include/configs/nokia_rx51.h - - #define UBIFS_SUPPORT diff --git a/qemu/roms/u-boot/doc/README.omap-reset-time b/qemu/roms/u-boot/doc/README.omap-reset-time deleted file mode 100644 index 0c974baca..000000000 --- a/qemu/roms/u-boot/doc/README.omap-reset-time +++ /dev/null @@ -1,20 +0,0 @@ -README on how reset time on OMAPs should be calculated - -CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC: -Most OMAPs' provide a way to specify the time for -which the reset should be held low while the voltages -and Oscillator outputs stabilize. - -This time is mostly board and PMIC dependent. Hence the -boards are expected to specify a pre-computed time -using the above option, (the details on how to compute -the value are given below) without which a default time -as specified by CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC -is used. - -The value for CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC -can be computed using a summation of the below 3 parameters --1- Time taken by the Osciallator to stop and restart --2- PMIC OTP time --3- Voltage ramp time, which can be derived using the -PMIC slew rate and value of voltage ramp needed. diff --git a/qemu/roms/u-boot/doc/README.omap-ulpi-viewport b/qemu/roms/u-boot/doc/README.omap-ulpi-viewport deleted file mode 100644 index a5240b9e2..000000000 --- a/qemu/roms/u-boot/doc/README.omap-ulpi-viewport +++ /dev/null @@ -1,27 +0,0 @@ -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/qemu/roms/u-boot/doc/README.omap3 b/qemu/roms/u-boot/doc/README.omap3 deleted file mode 100644 index a62c35740..000000000 --- a/qemu/roms/u-boot/doc/README.omap3 +++ /dev/null @@ -1,220 +0,0 @@ - -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] - -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 -===== - -* BeagleBoard: - -make omap3_beagle_config -make - -* Gumstix Overo: - -make omap3_overo_config -make - -* TI EVM: - -make omap3_evm_config -make - -* Pandora: - -make omap3_pandora_config -make - -* Zoom MDK: - -make omap3_zoom1_config -make - -* Zoom 2: - -make omap3_zoom2_config -make - -* CM-T35: - -make cm_t35_config -make - -* BlueLYNX-X: - -make omap3_mvblx_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/qemu/roms/u-boot/doc/README.pblimage b/qemu/roms/u-boot/doc/README.pblimage deleted file mode 100644 index 7fdd26b71..000000000 --- a/qemu/roms/u-boot/doc/README.pblimage +++ /dev/null @@ -1,111 +0,0 @@ ------------------------------------------------------------------- -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/qemu/roms/u-boot/doc/README.plan9 b/qemu/roms/u-boot/doc/README.plan9 deleted file mode 100644 index 2d3d0e0cf..000000000 --- a/qemu/roms/u-boot/doc/README.plan9 +++ /dev/null @@ -1,18 +0,0 @@ -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/qemu/roms/u-boot/doc/README.power-framework b/qemu/roms/u-boot/doc/README.power-framework deleted file mode 100644 index 1f6fd4320..000000000 --- a/qemu/roms/u-boot/doc/README.power-framework +++ /dev/null @@ -1,166 +0,0 @@ -# -# (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/qemu/roms/u-boot/doc/README.ppc440 b/qemu/roms/u-boot/doc/README.ppc440 deleted file mode 100644 index dd8ccaad0..000000000 --- a/qemu/roms/u-boot/doc/README.ppc440 +++ /dev/null @@ -1,197 +0,0 @@ - PowerPC 440 - - Last Update: September 11, 2002 -======================================================================= - - -OVERVIEW -============ - -Support for the ppc440 is contained in the cpu/ppc44x directory -and enabled via the CONFIG_440 flag. It is largely based on the -405gp code. A sample board support implementation is contained -in the board/ebony directory. - -All testing was performed using the AMCC Ebony board using both -Rev B and Rev C silicon. However, since the Rev B. silicon has -extensive errata, support for Rev B. is minimal (it boots, and -features such as i2c, pci, tftpboot, etc. seem to work ok). -The expectation is that all new board designs will be using -Rev C or later parts -- if not, you may be in for a rough ride ;-) - -The ppc440 port does a fair job of keeping "board-specific" code -out of the "cpu-specific" source. The goal of course was to -provide mechanisms for each board to customize without having -to clutter the cpu-specific source with a lot of ifdefs. Most -of these mechanisms are described in the following sections. - - -MEMORY MANAGEMENT -================= - -The ppc440 doesn't run in "real mode". The MMU must be active -at all times. Additionally, the 440 implements a 36-bit physical -memory space that gets mapped into the PowerPC 32-bit virtual -address space. So things like memory-mapped peripherals, etc must -all be mapped in. Once this is done, the 32-bit virtual address -space is then viewed as though it were physical memory. - -However, this means that memory, peripherals, etc can be configured -to appear (mostly) anywhere in the virtual address space. Each board -must define its own mappings using the tlbtab (see board/ebony/init.S). -The actual TLB setup is performed by the cpu-specific code. - -Although each board is free to define its own mappings, there are -several definitions to be aware of. These definitions may be used in -the cpu-specific code (vs. board-specific code), so you should -at least review these before deciding to make any changes ... it -will probably save you some headaches ;-) - -CONFIG_SYS_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0) - -CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped. - -CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped. - This mapping provides access to PCI-bus memory. - -CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped - peripherals are mapped. (e.g. -- UART registers, IIC registers, etc). - -CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is - mapped. The internal SRAM is equivalent to 405gp OCM and is used - for the initial stack. - -CONFIG_SYS_PCI_BASE - The virtual address where the 440 PCI-x bridge config - registers are mapped. - -CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address - defined by CONFIG_SYS_PCI_MEMBASE. - - -UART / SERIAL -================= - -The UART port works fine when an external serial clock is provided -(like the one on the Ebony board) and when using internal clocking. -This is controlled with the CONFIG_SYS_EXT_SERIAL_CLOCK flag. When using -internal clocking, the "ideal baud rate" settings in the 440GP -user manual are automatically calculated. - - -I2C -================= - -The i2c utilities have been tested on both Rev B. and Rev C. and -look good. The 'i2c probe' command implementation has been updated to -allow for 'skipped' addresses. Some i2c slaves are write only and -cause problems when a probe (read) is performed (for example the -CDCV850 clock controller at address 0x69 on the ebony board). - -To prevent probing certain addresses you can define the -CONFIG_SYS_I2C_NOPROBES macro in your board-specific header file. When -defined, all specified addresses are skipped during a probe. -The addresses that are skipped will be displayed in the output -of the 'i2c probe' command. - -For example, to prevent probing address 0x69, define the macro as -follows: - -#define CONFIG_SYS_I2C_NOPROBES {0x69} - -Similarly, to prevent probing addresses 0x69 and 0x70, define the -macro a: - -#define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70} - - -DDR SDRAM CONTROLLER -==================== - -SDRAM controller intialization using Serial Presence Detect (SPD) is -now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM. -The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro. - -NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other -processors. Traditionally, it defined a single address. For the 440 it -defines an array of addresses to support multiple banks. Address order -is significant: the addresses are used in order to program the BankN -registers. For example, two banks with i2c addresses of 0x53 (bank 0) -and 0x52 (bank 1) would be defined as follows: - -#define SPD_EEPROM_ADDRESS {0x53,0x52} - - -PCI-X BRIDGE -==================== - -PCI is an area that requires lots of flexibility since every board has -its own set of constraints and configuration. This section describes the -440 implementation. - -CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init -is aborted and an indication is printed. This is NOT considered an -error -- only an indication that PCI shouldn't be initialized. This -gives you a chance to edit the i2c bootstrap eeproms using the i2c -utilities once you get to the U-Boot command prompt. NOTE: the default -440 bootstrap options (not using i2c eeprom) negates this bit. - -The cpu-specific code sets up a default pci_controller structure -that maps in a single PCI I/O space and PCI memory space. The I/O -space begins at PCI I/O address 0 and the PCI memory space is -256 MB starting at PCI address CONFIG_SYS_PCI_TARGBASE. After the -pci_controller structure is initialized, the cpu-specific code will -call the routine pci_pre_init(). This routine is implemented by -board-specific code & is where the board can over-ride/extend the -default pci_controller structure settings and exspecially provide -a routine to map the PCI interrupts and do other pre-initialization -tasks. If pci_pre_init() returns a value of zero, PCI initialization -is aborted; otherwise the controller structure is registered and -initialization continues. - -The default 440GP PCI target configuration is minimal -- it assumes that -the strapping registers are set as necessary. Since the strapping bits -provide very limited flexibility, you may want to customize the boards -target configuration. If CONFIG_SYS_PCI_TARGET_INIT is defined, the cpu-specific -code will call the routine pci_target_init() which you must implement -in your board-specific code. - -Target initialization is completed by the cpu-specific code by -initializing the subsystem id and subsystem vendor id, and then ensuring -that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set. - -The default PCI master initialization maps in 256 MB of pci memory -starting at PCI address CONFIG_SYS_PCI_MEMBASE. To customize this, define -PCI_MASTER_INIT. This will call the routine pci_master_init() in your -board-specific code rather than performing the default master -initialization. - -The decision to perform PCI host configuration must often be determined -at run time. The ppc440 port differs from most other implementations in -that it requires the board to determine its host configuration at run -time rather than by using compile-time flags. This shouldn't create a -large impact on the board-specific code since the board only needs to -implement a single routine that returns a zero or non-zero value: -is_pci_host(). - -Justification for this becomes clear when considering systems running -in a cPCI environment: - -1. Arbiter strapping: Many cPCI boards provide an external arbiter (often -part of the PCI-to-PCI bridge). Even though the arbiter is external (the -arbiter strapping is negated), the CPU may still be required to perform -local PCI bus configuration. - -2. Host only: PPMC boards must sample the MONARCH# signal at run-time. -Depending on the configuration of the carrier boar, the PPMC board must -determine if it should configure the PCI bus at run-time. And in most -cases, access to the MONARCH# signal is board-specific (e.g. via -board-specific FPGA registers, etc). - -In any event, the is_pci_host() routine gives each board the opportunity -to decide at run-time. If your board is always configured a certain way, -then just hardcode a return of 1 or 0 as appropriate. - - -Regards, ---Scott -<smcnutt@artesyncp.com> diff --git a/qemu/roms/u-boot/doc/README.pxe b/qemu/roms/u-boot/doc/README.pxe deleted file mode 100644 index f67605cf9..000000000 --- a/qemu/roms/u-boot/doc/README.pxe +++ /dev/null @@ -1,236 +0,0 @@ -/* - * Copyright 2010-2011 Calxeda, Inc. - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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 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. - -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 - 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. - -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. - -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/linux.list---------- -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/qemu/roms/u-boot/doc/README.qemu-mips b/qemu/roms/u-boot/doc/README.qemu-mips deleted file mode 100644 index a192752f4..000000000 --- a/qemu/roms/u-boot/doc/README.qemu-mips +++ /dev/null @@ -1,195 +0,0 @@ -By Vlad Lungu vlad.lungu@windriver.com 2007-Oct-01 ----------------------------------------- -Qemu is a full system emulator. See - -http://www.nongnu.org/qemu/ - -Limitations & comments ----------------------- -Supports the "-M mips" configuration of qemu: serial,NE2000,IDE. -Supports little and big endian as well as 32 bit and 64 bit. -Derived from au1x00 with a lot of things cut out. - -Supports emulated flash (patch Jean-Christophe PLAGNIOL-VILLARD) with -recent qemu versions. When using emulated flash, launch with --pflash <filename> and erase mips_bios.bin. - - -Notes for the Qemu MIPS port ----------------------------- - -I) Example usage: - -Using u-boot.bin as ROM (replaces Qemu monitor): - -32 bit, big endian: -# make qemu_mips -# qemu-system-mips -M mips -bios u-boot.bin -nographic - -32 bit, little endian: -# make qemu_mipsel -# qemu-system-mipsel -M mips -bios u-boot.bin -nographic - -64 bit, big endian: -# make qemu_mips64 -# qemu-system-mips64 -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic - -64 bit, little endian: -# make qemu_mips64el -# qemu-system-mips64el -cpu MIPS64R2-generic -M mips -bios u-boot.bin -nographic - -or using u-boot.bin from emulated flash: - -if you use a qemu version after commit 4224 - -create image: -# dd of=flash bs=1k count=4k if=/dev/zero -# dd of=flash bs=1k conv=notrunc if=u-boot.bin -start it (see above): -# qemu-system-mips[64][el] [-cpu MIPS64R2-generic] -M mips -pflash flash -nographic - -2) Download kernel + initrd - -On ftp://ftp.denx.de/pub/contrib/Jean-Christophe_Plagniol-Villard/qemu_mips/ -you can downland - -#config to build the kernel -qemu_mips_defconfig -#patch to fix mips interrupt init on 2.6.24.y kernel -qemu_mips_kernel.patch -initrd.gz -vmlinux -vmlinux.bin -System.map - -4) Generate uImage - -# tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x80010000 -e 0x80245650 -n "Linux 2.6.24.y" -d vmlinux.bin.gz uImage - -5) Copy uImage to Flash -# dd if=uImage bs=1k conv=notrunc seek=224 of=flash - -6) Generate Ide Disk - -# dd of=ide bs=1k cout=100k if=/dev/zero - -# sfdisk -C 261 -d ide -# partition table of ide -unit: sectors - - ide1 : start= 63, size= 32067, Id=83 - ide2 : start= 32130, size= 32130, Id=83 - ide3 : start= 64260, size= 4128705, Id=83 - ide4 : start= 0, size= 0, Id= 0 - -7) Copy to ide - -# dd if=uImage bs=512 conv=notrunc seek=63 of=ide - -8) Generate ext2 on part 2 on Copy uImage and initrd.gz - -# Attached as loop device ide offset = 32130 * 512 -# losetup -o 16450560 -f ide -# Format as ext2 ( arg2 : nb blocks) -# mke2fs /dev/loop0 16065 -# losetup -d /dev/loop0 -# Mount and copy uImage and initrd.gz to it -# mount -o loop,offset=16450560 -t ext2 ide /mnt -# mkdir /mnt/boot -# cp {initrd.gz,uImage} /mnt/boot/ -# Umount it -# umount /mnt - -9) Set Environment - -setenv rd_start 0x80800000 -setenv rd_size 2663940 -setenv kernel BFC38000 -setenv oad_addr 80500000 -setenv load_addr2 80F00000 -setenv kernel_flash BFC38000 -setenv load_addr_hello 80200000 -setenv bootargs 'root=/dev/ram0 init=/bin/sh' -setenv load_rd_ext2 'ide res; ext2load ide 0:2 ${rd_start} /boot/initrd.gz' -setenv load_rd_tftp 'tftp ${rd_start} /initrd.gz' -setenv load_kernel_hda 'ide res; diskboot ${load_addr} 0:2' -setenv load_kernel_ext2 'ide res; ext2load ide 0:2 ${load_addr} /boot/uImage' -setenv load_kernel_tftp 'tftp ${load_addr} /qemu_mips/uImage' -setenv boot_ext2_ext2 'run load_rd_ext2; run load_kernel_ext2; run addmisc; bootm ${load_addr}' -setenv boot_ext2_flash 'run load_rd_ext2; run addmisc; bootm ${kernel_flash}' -setenv boot_ext2_hda 'run load_rd_ext2; run load_kernel_hda; run addmisc; bootm ${load_addr}' -setenv boot_ext2_tftp 'run load_rd_ext2; run load_kernel_tftp; run addmisc; bootm ${load_addr}' -setenv boot_tftp_hda 'run load_rd_tftp; run load_kernel_hda; run addmisc; bootm ${load_addr}' -setenv boot_tftp_ext2 'run load_rd_tftp; run load_kernel_ext2; run addmisc; bootm ${load_addr}' -setenv boot_tftp_flash 'run load_rd_tftp; run addmisc; bootm ${kernel_flash}' -setenv boot_tftp_tftp 'run load_rd_tftp; run load_kernel_tftp; run addmisc; bootm ${load_addr}' -setenv load_hello_tftp 'tftp ${load_addr_hello} /examples/hello_world.bin' -setenv go_tftp 'run load_hello_tftp; go ${load_addr_hello}' -setenv addmisc 'setenv bootargs ${bootargs} console=ttyS0,${baudrate} rd_start=${rd_start} rd_size=${rd_size} ethaddr=${ethaddr}' -setenv bootcmd 'run boot_tftp_flash' - -10) Now you can boot from flash, ide, ide+ext2 and tfp - -# qemu-system-mips -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide - -II) 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) - -# qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide - -in an other console you start gdb - -1) Debugging of U-Boot Before Relocation - -Before relocation, the addresses in the ELF file can be used without any problems -by connecting to the gdb server localhost:1234 - -# mipsel-unknown-linux-gnu-gdb u-boot -GNU gdb 6.6 -Copyright (C) 2006 Free Software Foundation, Inc. -GDB is free software, covered by the GNU General Public License, and you are -welcome to change it and/or distribute copies of it under certain conditions. -Type "show copying" to see the conditions. -There is absolutely no warranty for GDB. Type "show warranty" for details. -This GDB was configured as "--host=i486-linux-gnu --target=mipsel-unknown-linux-gnu"... -(gdb) target remote localhost:1234 -Remote debugging using localhost:1234 -_start () at start.S:64 -64 RVECENT(reset,0) /* U-boot entry point */ -Current language: auto; currently asm -(gdb) b board.c:289 -Breakpoint 1 at 0xbfc00cc8: file board.c, line 289. -(gdb) c -Continuing. - -Breakpoint 1, board_init_f (bootflag=<value optimized out>) at board.c:290 -290 relocate_code (addr_sp, id, addr); -Current language: auto; currently c -(gdb) p/x addr -$1 = 0x87fa0000 - -2) Debugging of U-Boot After Relocation - -For debugging U-Boot after relocation we need to know the address to which -U-Boot relocates itself to 0x87fa0000 by default. -And replace the symbol table to this offset. - -(gdb) symbol-file -Discard symbol table from `/private/u-boot-arm/u-boot'? (y or n) y -Error in re-setting breakpoint 1: -No symbol table is loaded. Use the "file" command. -No symbol file now. -(gdb) add-symbol-file u-boot 0x87fa0000 -add symbol table from file "u-boot" at - .text_addr = 0x87fa0000 -(y or n) y -Reading symbols from /private/u-boot-arm/u-boot...done. -Breakpoint 1 at 0x87fa0cc8: file board.c, line 289. -(gdb) c -Continuing. - -Program received signal SIGINT, Interrupt. -0xffffffff87fa0de4 in udelay (usec=<value optimized out>) at time.c:78 -78 while ((tmo - read_c0_count()) < 0x7fffffff) diff --git a/qemu/roms/u-boot/doc/README.ramboot-ppc85xx b/qemu/roms/u-boot/doc/README.ramboot-ppc85xx deleted file mode 100644 index 5cc546a36..000000000 --- a/qemu/roms/u-boot/doc/README.ramboot-ppc85xx +++ /dev/null @@ -1,102 +0,0 @@ - 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. File name-> arch/powerpc/include/asm/config_mpc85xx.h - In the section of the particular SOC, for example P1020, - - #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/qemu/roms/u-boot/doc/README.rmobile b/qemu/roms/u-boot/doc/README.rmobile deleted file mode 100644 index 4fbbcb3ef..000000000 --- a/qemu/roms/u-boot/doc/README.rmobile +++ /dev/null @@ -1,84 +0,0 @@ -Summary -======= - -This README is about U-Boot support for Renesas's ARM Cortex-A9 based RMOBILE[1] -and R-Car[2]family of SoCs. Renesas's RMOBILE/R-Car SoC family contains an ARM -Cortex-A9. - -Currently the following boards are supported: - -* KMC KZM-A9-GT [3] -* Atmark-Techno Armadillo-800-EVA [4] -* Renesas Electronics Lager -* Renesas Electronics Koelsch - -Toolchain -========= - -ARM Cortex-A9 support ARM v7 instruction set (-march=armv7a). -But currently we compile with -march=armv5 to allow more compilers to work. -(For U-Boot code this has no performance impact.) -Because there was no compiler which is supporting armv7a not much before. -Currently, ELDK[5], Linaro[6], CodeSourcey[7] and Emdebian[8] supports -march=armv7a -and you can get. - -Build -===== - -* KZM-A9-GT - - make kzm9g_config - make - -* Armadillo-800-EVA - - make armadillo-800eva_config - make - - Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only. - Please see "B.2 Appendix B Boot Specifications" in hardware manual. - -* Lager - - make lager_config - make - -* Koelsch - - make koelsch_config - make - -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/qemu/roms/u-boot/doc/README.s5pc1xx b/qemu/roms/u-boot/doc/README.s5pc1xx deleted file mode 100644 index ab1f02469..000000000 --- a/qemu/roms/u-boot/doc/README.s5pc1xx +++ /dev/null @@ -1,72 +0,0 @@ - -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/qemu/roms/u-boot/doc/README.sandbox b/qemu/roms/u-boot/doc/README.sandbox deleted file mode 100644 index 529c447a5..000000000 --- a/qemu/roms/u-boot/doc/README.sandbox +++ /dev/null @@ -1,299 +0,0 @@ -/* - * Copyright (c) 2014 The Chromium OS Authors. - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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. - -CONFIG_SANDBOX is defined when building a native board. - -The chosen vendor and board names are also 'sandbox', so there is a single -board in board/sandbox/sandbox. - -CONFIG_SANDBOX_BIG_ENDIAN should be defined when running on big-endian -machines. - -Note that standalone/API support is not available at present. - - -Basic Operation ---------------- - -To run sandbox U-Boot use something like: - - make sandbox_config all - ./u-boot - -Note: - If you get errors about 'sdl-config: Command not found' you may need to - install libsdl1.2-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_config 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 'reset' 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. - -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). - -As mentioned above, -l causes the LCD emulation window to be shown. - -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. - -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 shall will normally process and -swallow quotes. When -c is used, U-Boot exists after the command is complete, -but you can force it to go to interactive mode instead with -i. - - -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) -- Keyboard (Chrome OS) -- LCD -- Serial (for console only) -- Sound (incomplete - see sandbox_sdl_sound_init() for details) -- SPI -- SPI flash -- TPM (Trusted Platform Module) - -Notable omissions are networking and I2C. - -A wide range of commands is implemented. Filesystems which use a block -device are supported. - -Also sandbox uses generic board (CONFIG_SYS_GENERIC_BOARD) and supports -driver model (CONFIG_DM) and associated commands. - - -SPI Emulation -------------- - -Sandbox supports SPI and SPI flash emulation. - -This is controlled by the spi_sf argument, the format of which is: - - bus:cs:device:file - - bus - SPI bus number - cs - SPI chip select number - device - SPI device emulation name - file - File on disk containing the data - -For example: - - dd if=/dev/zero of=spi.bin bs=1M count=4 - ./u-boot --spi_sf 0:0:M25P16:spi.bin - -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). - -Drivers are connected to a particular bus/cs using sandbox's state -structure (see the 'spi' member). A set of operations must be provided -for each driver. - - -Configuration settings for the curious are: - -CONFIG_SANDBOX_SPI_MAX_BUS - The maximum number of SPI buses supported by the driver (default 1). - -CONFIG_SANDBOX_SPI_MAX_CS - The maximum number of chip selects supported by the driver - (default 10). - -CONFIG_SPI_IDLE_VAL - The idle value on the SPI bus - - -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. - - -Testing -------- - -U-Boot sandbox can be used to run various tests, mostly in the test/ -directory. These include: - - 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. - driver model - - test/dm/test-dm.sh to run these. - image - - Unit tests for images: - test/image/test-imagetools.sh - multi-file images - test/image/test-fit.py - FIT images - tracing - - test/trace/test-trace.sh tests the tracing system (see README.trace) - verified boot - - See test/vboot/vboot_test.sh for this - -If you change or enhance any of the above subsystems, you shold write or -expand a test and include it with your patch series submission. Test -coverage in U-Boot is limited, as 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). - -It would be useful to have a central script to run all of these. - --- -Simon Glass <sjg@chromium.org> -Updated 22-Mar-14 diff --git a/qemu/roms/u-boot/doc/README.sata b/qemu/roms/u-boot/doc/README.sata deleted file mode 100644 index d0ce6673b..000000000 --- a/qemu/roms/u-boot/doc/README.sata +++ /dev/null @@ -1,68 +0,0 @@ -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/qemu/roms/u-boot/doc/README.sched b/qemu/roms/u-boot/doc/README.sched deleted file mode 100644 index 3aa89e6d3..000000000 --- a/qemu/roms/u-boot/doc/README.sched +++ /dev/null @@ -1,53 +0,0 @@ -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/qemu/roms/u-boot/doc/README.scrapyard b/qemu/roms/u-boot/doc/README.scrapyard deleted file mode 100644 index f9742e7d4..000000000 --- a/qemu/roms/u-boot/doc/README.scrapyard +++ /dev/null @@ -1,128 +0,0 @@ -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 piece -in the imperishable depths of the git history. This document tries to -maintain a list of such former fellows, so archeologists can check -easily if here is something they might want to dig for... - - -Board Arch CPU Commit Removed Last known maintainer/contact -================================================================================================= -lubbock arm pxa - 2014-04-04 Kyle Harris <kharris@nexus-tech.net> -MOUSSE powerpc mpc824x - 2014-04-04 -rsdproto powerpc mpc8260 - 2014-04-04 -RPXsuper powerpc mpc8260 - 2014-04-04 -RPXClassic powerpc mpc8xx - 2014-04-04 -RPXlite powerpc mpc8xx - 2014-04-04 -genietv powerpc mpc8xx - 2014-04-04 -mbx8xx powerpc mpc8xx - 2014-04-04 -nx823 powerpc mpc8xx - 2014-04-04 -idmr m68k mcf52x2 ba650e9b 2014-01-28 -M5271EVB m68k mcf52x2 ba650e9b 2014-01-28 -dvl_host arm ixp e317de6b 2014-01-28 Michael Schwingen <michael@schwingen.org> -actux4 arm ixp 6ff7aafa 2014-01-28 Michael Schwingen <michael@schwingen.org> -actux3 arm ixp 38da33f3 2014-01-28 Michael Schwingen <michael@schwingen.org> -actux2 arm ixp 13e0ee7f 2014-01-28 Michael Schwingen <michael@schwingen.org> -actux1 arm ixp 373ee048 2014-01-28 Michael Schwingen <michael@schwingen.org> -mx1ads arm arm920t e570aca9 2014-01-13 -mini2440 arm arm920t af5b9b1f 2014-01-13 Gabriel Huau <contact@huau-gabriel.fr> -omap730p2 arm arm926ejs 79c5c08d 2013-11-11 -pn62 powerpc mpc824x 649acfe1 2013-11-11 Wolfgang Grandegger <wg@grandegger.com> -pdnb3 arm ixp 304db0b 2013-09-24 Stefan Roese <sr@denx.de> -scpu arm ixp 304db0b 2013-09-24 Stefan Roese <sr@denx.de> -omap1510inn arm arm925t 0610a16 2013-09-23 Kshitij Gupta <kshitij@ti.com> -CANBT powerpc 405CR fb8f4fd 2013-08-07 Matthias Fuchs <matthias.fuchs@esd.eu> -omap2420h4 arm omap24xx 7f5eef9 2013-06-04 Richard Woodruff <r-woodruff2@ti.com> -Alaska8220 powerpc mpc8220 d6ed322 2013-05-11 -Yukon8220 powerpc mpc8220 d6ed322 2013-05-11 -sorcery powerpc mpc8220 d6ed322 2013-05-11 -smdk6400 arm arm1176 52587f1 2013-04-12 Zhong Hongbo <bocui107@gmail.com> -ns9750dev arm arm926ejs 4cfc611 2013-02-28 Markus Pietrek <mpietrek@fsforth.de> -eNET x86 x86 7e8c53d 2013-02-14 Graeme Russ <graeme.russ@gmail.com> -PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de> -PCIPPC6 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de> -AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> -c2mon powerpc mpc855 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> -EP88x powerpc mpc885 1b0757e 2012-10-28 -ETX094 powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> -IAD210 powerpc mpc860 1b0757e 2012-10-28 - -LANTEC powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> -SCM powerpc mpc8260 1b0757e 2012-10-28 Wolfgang Grandegger <wg@denx.de> -SX1 arm arm925t 53c4154 2012-10-26 -TQM85xx powerpc MPC85xx d923a5d 2012-10-04 Stefan Roese <sr@denx.de> -ADCIOP powerpc ppc4xx 99bcad1 2012-09-19 Matthias Fuchs <matthias.fuchs@esd-electronics.com> -DASA_SIM powerpc ppc4xx 99bcad1 2012-09-19 Matthias Fuchs <matthias.fuchs@esd-electronics.com> -apollon arm omap24xx 535c74f 2012-09-18 Kyungmin Park <kyungmin.park@samsung.com> -tb0229 mips mips32 3f3110d 2011-12-12 -rmu powerpc MPC850 fb82fd7 2011-12-07 Wolfgang Denk <wd@denx.de> -OXC powerpc MPC8240 309a292 2011-12-07 -BAB7xx powerpc MPC740/MPC750 c53043b 2011-12-07 Frank Gottschling <fgottschling@eltec.de> -xm250 arm pxa c477d72 2011-11-25 -pleb2 arm pxa d299173 2011-11-25 -cradle arm pxa 00c4aca 2011-11-25 Kyle Harris <kharris@nexus-tech.net> -cerf250 arm pxa f13eba6 2011-11-25 Prakash Kumar <prakash@embedx.com> -mpq101 powerpc mpc85xx e877fab 2011-10-23 Alex Dubov <oakad@yahoo.com> -ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr@denx.de> -ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris@nexus-tech.net> -zylonite arm pxa b66521a 2011-09-05 -shannon arm sa1100 5df092d 2011-09-05 Rolf Offermanns <rof@sysgo.de> -modnet50 arm arm720t 9c62815 2011-09-05 Thomas Elste <info@elste.org> -lpc2292sodimm arm arm720t d1a067a 2011-09-05 -lart arm sa1100 3d57573 2011-09-05 Alex Züpke <azu@sysgo.de> -impa7 arm arm720t c1f8750 2011-09-05 Marius Gröger <mag@sysgo.de> -gcplus arm sa1100 2c650e2 2011-09-05 George G. Davis <gdavis@mvista.com> -evb4510 arm arm720t 26e670e 2011-09-05 Curt Brune <curt@cucy.com> -ep7312 arm arm720t c8f63b4 2011-09-05 Marius Gröger <mag@sysgo.de> -dnp1110 arm sa1100 fc5e5ce 2011-09-05 Alex Züpke <azu@sysgo.de> -SMN42 arm arm720t 6aac646 2011-09-05 -at91rm9200dk arm arm920t 1c85752 2011-07-17 -m501sk arm arm920t b1a2bd4 2011-07-17 -kb9202 arm arm920t 5bd3814 2011-07-17 -csb637 arm arm920t d14af08 2011-07-17 -cmc_pu2 arm arm920t 37a9b4d 2011-07-17 -at91cap9adk arm arm926ejs b550834 2011-07-17 Stelian Pop <stelian@popies.net> -voiceblue arm arm925t 1b793a4 2011-07-17 -smdk2400 arm arm920t ad218a8 2011-07-17 Gary Jennejohn <garyj@denx.de> -sbc2410x arm arm920t 1f7f0ed 2011-07-17 -netstar arm arm925t 6ea2405 2011-07-17 -mx1fs2 arm arm920t 6962419 2011-07-17 -lpd7a404 arm lh7a40x 957731e 2011-07-17 -edb9301 arm arm920t 716f7ad 2011-07-17 -edb9302 arm arm920t 716f7ad 2011-07-17 -edb9302a arm arm920t 716f7ad 2011-07-17 -edb9307 arm arm920t 716f7ad 2011-07-17 -edb9307a arm arm920t 716f7ad 2011-07-17 -edb9312 arm arm920t 716f7ad 2011-07-17 -edb9315 arm arm920t 716f7ad 2011-07-17 -edb9315a arm arm920t 716f7ad 2011-07-17 -B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian <andrea.scian@dave-tech.it> -armadillo arm arm720t be28857 2011-07-16 Rowel Atienza <rowel@diwalabs.com> -assabet arm sa1100 c91e90d 2011-07-16 George G. Davis <gdavis@mvista.com> -trab arm S3C2400 566e5cf 2011-05-01 Gary Jennejohn <garyj@denx.de> -mp2usb ARM AT91RM2900 ee986e2 2011-01-25 Eric Bénard <eric@eukrea.com> -barco powerpc MPC8245 afaa27b 2010-11-23 Marc Leeman <marc.leeman@barco.com> -ERIC powerpc 405GP d9ba451 2010-11-21 Swen Anderson <sand@peppercon.de> -VoVPN-GW_100MHz powerpc MPC8260 26fe3d2 2010-10-24 Juergen Selent <j.selent@elmeg.de> -xsengine ARM PXA2xx 4262a7c 2010-10-20 -wepep250 ARM PXA2xx 7369478 2010-10-20 Peter Figuli <peposh@etc.sk> -delta ARM PXA2xx 75e2035 2010-10-20 -NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de> -CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de> -logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl@gmx.at> -CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg@denx.de> -PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd@denx.de> -spieval powerpc MPC5200 69434e4 2010-09-19 -smmaco4 powerpc MPC5200 9ddc3af 2010-09-19 -HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd@denx.de> -GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas@corelatus.se> -AmigaOneG3SE powerpc 74xx_7xx 953b7e6 2010-06-23 -suzaku microblaze - 4f18060 2009-10-03 Yasushi Shoji <yashi@atmark-techno.com> -XUPV2P microblaze - 8fab49e 2008-12-10 Michal Simek <monstr@monstr.eu> -MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz@matrix-vision.de> -adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com> -R5200 ColdFire - 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com> -CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com> -incaip mips mips32 - 2014-04-17 Wolfgang Denk <wd@denx.de> diff --git a/qemu/roms/u-boot/doc/README.serial_multi b/qemu/roms/u-boot/doc/README.serial_multi deleted file mode 100644 index ad61d4261..000000000 --- a/qemu/roms/u-boot/doc/README.serial_multi +++ /dev/null @@ -1,80 +0,0 @@ -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 - -MPC5xxx Specific -================ - -Up to two PSCs can be used as console. - -Support for hardware handshake has not been implemented yet. - -*) The first (default) console port is defined by: - #define CONFIG_PSC_CONSOLE <PSC number> - -*) The second (alternative) console port is defined by: - #define CONFIG_PSC_CONSOLE2 <PSC number> - -*) Commands to switch to the second console: - setenv stdout serial1 - setenv stderr serial1 - setenv stdin serial1 - -*) Commands to switch to the first console: - setenv stdout serial0 - setenv stderr serial0 - setenv stdin serial0 - -*) If a file descriptor is set to "serial" then the - current serial device will be used. diff --git a/qemu/roms/u-boot/doc/README.sh b/qemu/roms/u-boot/doc/README.sh deleted file mode 100644 index 6baee089e..000000000 --- a/qemu/roms/u-boot/doc/README.sh +++ /dev/null @@ -1,104 +0,0 @@ - -U-Boot for Renesas SuperH - Last update 01/18/2008 by Nobuhiro Iwamatsu - -================================================================================ -0. What's this? - This file contains status information for the port of U-Boot to the - Renesas SuperH series of CPUs. - -================================================================================ -1. 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. - -================================================================================ -2. Supported CPUs - - 2.1. Renesas SH7750/SH7750R - This CPU has the SH4 core. - - 2.2. Renesas SH7722 - This CPU has the SH4AL-DSP core. - - 2.3. Renesas SH7720 - This CPU has the SH3 core. - - 2.4. Renesas SH7710/SH7712 - This CPU has the SH3-DSP core and Ethernet controller. - - 2.5. Renesas SH7780 - This CPU has the SH4A core. - -================================================================================ -3. Supported Boards - - 3.1. 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 - - 3.2. 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 - - 3.2. 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 - - 3.3. Renesas R7780MP - Board specific code is in board/r7780mp - To use this board, type "make r7780mp_config". - Support devices are : - - SCIF - - DDR-SDRAM - - NOR Flash - - Compact Flash - - ASIX ethernet - - SH7780 PCI bridge - - RTL8110 ethernet - - ** README ** - 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 - -================================================================================ -4. 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/ - -================================================================================ -5. Future - I plan to support the following CPUs and boards. - 5.1. CPUs - - SH7751R(SH4) - - SH7785(SH4) - - 5.2. Boards - - Many boards ;-) - -================================================================================ -Copyright (c) 2007,2008 - Nobuhiro Iwamatsu <iwamatsu@nigaur.org> diff --git a/qemu/roms/u-boot/doc/README.sh7752evb b/qemu/roms/u-boot/doc/README.sh7752evb deleted file mode 100644 index c1fb54cdc..000000000 --- a/qemu/roms/u-boot/doc/README.sh7752evb +++ /dev/null @@ -1,67 +0,0 @@ -======================================== -Renesas R0P7752C00000RZ board -======================================== - -This board specification: -========================= - -The R0P7752C00000RZ(board config name:sh7752evb) has the following device: - - - SH7752 (SH-4A) - - DDR3-SDRAM 512MB - - SPI ROM 8MB - - Gigabit Ethernet controllers - - eMMC 4GB - - -Configuration for This board: -============================= - -You can select the configuration as follows: - - - make sh7752evb_config - - -This board specific command: -============================ - -This board has the following its specific command: - - - write_mac - - -1. write_mac - -You can write MAC address to SPI ROM. - - Usage 1) Write MAC address - - write_mac [GETHERC ch0] [GETHERC ch1] - - For example) - => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f - *) We have to input the command as a single line - (without carriage return) - *) We have to reset after input the command. - - Usage 2) Show current data - - write_mac - - For example) - => write_mac - GETHERC ch0 = 74:90:50:00:33:9e - GETHERC ch1 = 74:90:50:00:33:9f - - -Update SPI ROM: -============================ - -1. Copy u-boot image to RAM area. -2. Probe SPI device. - => sf probe 0 - SF: Detected MX25L6405D with page size 64KiB, total 8 MiB -3. Erase SPI ROM. - => sf erase 0 80000 -4. Write u-boot image to SPI ROM. - => sf write 0x48000000 0 80000 diff --git a/qemu/roms/u-boot/doc/README.sh7753evb b/qemu/roms/u-boot/doc/README.sh7753evb deleted file mode 100644 index 5fe178c53..000000000 --- a/qemu/roms/u-boot/doc/README.sh7753evb +++ /dev/null @@ -1,67 +0,0 @@ -======================================== -Renesas SH7753 EVB board -======================================== - -This board specification: -========================= - -The SH7753 EVB (board config name:sh7753evb) has the following device: - - - SH7753 (SH-4A) - - DDR3-SDRAM 512MB - - SPI ROM 8MB - - Gigabit Ethernet controllers - - eMMC 4GB - - -Configuration for This board: -============================= - -You can select the configuration as follows: - - - make sh7753evb_config - - -This board specific command: -============================ - -This board has the following its specific command: - - - write_mac - - -1. write_mac - -You can write MAC address to SPI ROM. - - Usage 1) Write MAC address - - write_mac [GETHERC ch0] [GETHERC ch1] - - For example) - => write_mac 74:90:50:00:33:9e 74:90:50:00:33:9f - *) We have to input the command as a single line - (without carriage return) - *) We have to reset after input the command. - - Usage 2) Show current data - - write_mac - - For example) - => write_mac - GETHERC ch0 = 74:90:50:00:33:9e - GETHERC ch1 = 74:90:50:00:33:9f - - -Update SPI ROM: -============================ - -1. Copy u-boot image to RAM area. -2. Probe SPI device. - => sf probe 0 - SF: Detected MX25L6405D with page size 64KiB, total 8 MiB -3. Erase SPI ROM. - => sf erase 0 80000 -4. Write u-boot image to SPI ROM. - => sf write 0x48000000 0 80000 diff --git a/qemu/roms/u-boot/doc/README.sha1 b/qemu/roms/u-boot/doc/README.sha1 deleted file mode 100644 index f6cca40d5..000000000 --- a/qemu/roms/u-boot/doc/README.sha1 +++ /dev/null @@ -1,57 +0,0 @@ -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 "./MAKEALL pcs440ep" or a "make all" to get the U-Boot image, -the correct SHA1 sum will be automagically included in the U-Boot image. - -Heiko Schocher, 11 Jul 2007 diff --git a/qemu/roms/u-boot/doc/README.silent b/qemu/roms/u-boot/doc/README.silent deleted file mode 100644 index 6d90a0ec4..000000000 --- a/qemu/roms/u-boot/doc/README.silent +++ /dev/null @@ -1,28 +0,0 @@ -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 - #defining CONFIG_SYS_DEVICE_NULLDEV in your board config 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/qemu/roms/u-boot/doc/README.socfpga b/qemu/roms/u-boot/doc/README.socfpga deleted file mode 100644 index cfcbbfe37..000000000 --- a/qemu/roms/u-boot/doc/README.socfpga +++ /dev/null @@ -1,53 +0,0 @@ - --------------------------------------------- -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_MMC --> To enable the SD MMC framework support - -#define CONFIG_SDMMC_BASE (SOCFPGA_SDMMC_ADDRESS) --> The base address of CSR register for DesignWare SDMMC controller - -#define CONFIG_GENERIC_MMC --> Enable the generic MMC driver - -#define CONFIG_SYS_MMC_MAX_BLK_COUNT 256 --> Using smaller max blk cnt to avoid flooding the limited stack in OCRAM - -#define CONFIG_DWMMC --> Enable the common DesignWare SDMMC controller framework - -#define CONFIG_SOCFPGA_DWMMC --> Enable the SOCFPGA specific driver for DesignWare SDMMC controller - -#define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH 1024 --> The FIFO depth for SOCFPGA DesignWare SDMMC controller - -#define CONFIG_SOCFPGA_DWMMC_DRVSEL 3 --> Phase-shifted clock of sdmmc_clk for controller to drive command and data to -the card to meet hold time requirements. SD clock is running at 50MHz and -drvsel is set to shift 135 degrees (3 * 45 degrees). With that, the hold time -is 135 / 360 * 20ns = 7.5ns. - -#define CONFIG_SOCFPGA_DWMMC_SMPSEL 0 --> Phase-shifted clock of sdmmc_clk used to sample the command and data from -the card - -#define CONFIG_SOCFPGA_DWMMC_BUS_WIDTH 4 --> Bus width of data line which either 1, 4 or 8 and based on board routing. - -#define CONFIG_SOCFPGA_DWMMC_BUS_HZ 50000000 --> The clock rate to controller. Do note the controller have a wrapper which -divide the clock from PLL by 4. diff --git a/qemu/roms/u-boot/doc/README.spear b/qemu/roms/u-boot/doc/README.spear deleted file mode 100644 index 0789b3fd2..000000000 --- a/qemu/roms/u-boot/doc/README.spear +++ /dev/null @@ -1,74 +0,0 @@ - -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/qemu/roms/u-boot/doc/README.splashprepare b/qemu/roms/u-boot/doc/README.splashprepare deleted file mode 100644 index 61b4ec53e..000000000 --- a/qemu/roms/u-boot/doc/README.splashprepare +++ /dev/null @@ -1,8 +0,0 @@ ---------------------------------------------------------------------- -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. diff --git a/qemu/roms/u-boot/doc/README.srio-pcie-boot-corenet b/qemu/roms/u-boot/doc/README.srio-pcie-boot-corenet deleted file mode 100644 index 2b1f76b8d..000000000 --- a/qemu/roms/u-boot/doc/README.srio-pcie-boot-corenet +++ /dev/null @@ -1,118 +0,0 @@ ---------------------------------------- -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/qemu/roms/u-boot/doc/README.standalone b/qemu/roms/u-boot/doc/README.standalone deleted file mode 100644 index 2be5f2769..000000000 --- a/qemu/roms/u-boot/doc/README.standalone +++ /dev/null @@ -1,100 +0,0 @@ -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 slot numbers 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[XF_malloc] = my_malloc; - gd->jt[XF_free] = my_free; - - Note that the pointers to the functions all have 'void *' type and - thus the compiler cannot 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, r8 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 - - 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 foobar(), the following steps - should be undertaken: - - - Append the following line at the end of the include/_exports.h - file: - - EXPORT_FUNC(foobar) - - - Add the prototype for this function to the include/exports.h - file: - - void foobar(void); - - - Add the initialization of the jump table slot wherever - appropriate (most likely, to the jumptable_init() function): - - gd->jt[XF_foobar] = foobar; - - - Increase the XF_VERSION value by one in the include/exports.h - file - -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/qemu/roms/u-boot/doc/README.switch_config b/qemu/roms/u-boot/doc/README.switch_config deleted file mode 100644 index f8903738e..000000000 --- a/qemu/roms/u-boot/doc/README.switch_config +++ /dev/null @@ -1,25 +0,0 @@ -On the enbw_cmc board is a KSZ8864RMN switch which needs -configured through spi before working. This is done on -startup from u-boot through a config file stored at an -address specified in the "hwconfig" environment variable, -subcommand "config". - -For example on the enbw_cmc board: - -hwconfig=switch:lan=on,pwl=off,config=0x60160000 - -The file has the following structure: - -- a comment starts with a '#' or a ';' and ends with a newline -- The switch needs for its config a reg/value pair, so we - have two columns in the file: - reg : contains the register address - value: contains a 8 bit register value - This 2 columns are seperated through space or tab. - -example (minimal configuration on the enbw_cmc board): - -;reg value comment -;----------------------------------------- -0x01 0x00 -0x01 0x01 ; Start Switch with this configuration diff --git a/qemu/roms/u-boot/doc/README.t4240qds b/qemu/roms/u-boot/doc/README.t4240qds deleted file mode 100644 index ef8c75f3b..000000000 --- a/qemu/roms/u-boot/doc/README.t4240qds +++ /dev/null @@ -1,175 +0,0 @@ -Overview --------- -The T4240QDS is a high-performance computing evaluation, development and test -platform supporting the T4240 QorIQ™ Power Architecture™ processor. T4240QDS is -optimized to support the high-bandwidth DDR3 memory ports, as well as the -highly-configurable SerDes ports. The system is lead-free and RoHS-compliant. - -Board Features - SERDES Connections - 32 lanes grouped into four 8-lane banks - Two “front side” banks dedicated to Ethernet - - High-speed crosspoint switch fabric on selected lanes - - Two PCI Express slots with side-band connector supporting - - SGMII - - XAUI - - HiGig - - I-pass connectors allow board-to-board and loopback support - Two “back side” banks dedicated to other protocols - - High-speed crosspoint switch fabric on all lanes - - Four PCI Express slots with side-band connector supporting - - PCI Express 3.0 - - SATA 2.0 - - SRIO 2.0 - - Supports 4X Aurora debug with two connectors - DDR Controllers - Three independant 64-bit DDR3 controllers - Supports rates of 1866 up to 2133 MHz data-rate - Supports two DDR3/DDR3LP UDIMM/RDIMMs per controller - DDR power supplies 1.5V to all devices with automatic tracking of VTT. - Power software-switchable to 1.35V if software detects all DDR3LP devices. - MT9JSF25672AZ-2G1KZESZF has been tested at 1333, 1600, 1867, 2000 and - 2133MT/s speeds. For 1867MT/s and above, read-to-write turnaround time - increases by 1 clock. - - IFC/Local Bus - NAND flash: 8-bit, async or sync, up to 2GB. - NOR: 16-bit, Address/Data Multiplexed (ADM), up to 128 MB - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB - - NOR devices support 16 virtual banks - GASIC: Minimal target within Qixis FPGA - PromJET rapid memory download support - Address demultiplexing handled within FPGA. - - Flexible demux allows 8 or 16 bit evaluation. - IFC Debug/Development card - - Support for 32-bit devices - Ethernet - Support two on-board RGMII 10/100/1G ethernet ports. - SGMII and XAUI support via SERDES block (see above). - 1588 support via Symmetricom board. - QIXIS System Logic FPGA - Manages system power and reset sequencing - Manages DUT, board, clock, etc. configuration for dynamic shmoo - Collects V-I-T data in background for code/power profiling. - Supports legacy TMT test features (POSt, IRS, SYSCLK-synchronous assertion) - General fault monitoring and logging - Runs from ATX “hot” power rails allowing operation while system is off. - Clocks - System and DDR clock (SYSCLK, “DDRCLK”) - - Switch selectable to one of 16 common settings in the interval 33MHz-166MHz. - - Software selectable in 1MHz increments from 1-200MHz. - SERDES clocks - - Provides clocks to all SerDes blocks and slots - - 100, 125 and 156.25 MHz - Power Supplies - Dedicated regulators for VDD - - Adjustable from (0.7V to 1.3V at 80A - - Regulators can be controlled by VID and/or software - Dedicated regulator for GVDD_PL: 1.35/1.5V at 22A - - VTT/MVREF automatically track operating voltage - Dedicated regulators/filters for AVDD supplies - Dedicated regulators for other supplies: OVDD, BVDD, DVDD, LVDD, POVDD, etc. - USB - Supports two USB 2.0 ports with integrated PHYs - - One type A, one type micro-AB with 1.0A power per port. - Other IO - eSDHC/MMC - - SDHC card slot - eSPI port - - High-speed serial flash - Two Serial port - Four I2C ports - -Memory map ----------- -The addresses in brackets are physical addresses. - -0x0_0000_0000 (0x0_0000_0000) - 0x0_7fff_ffff 2GB DDR (more than 2GB is initialized but not mapped under with TLB) -0x0_8000_0000 (0xc_0000_0000) - 0x0_dfff_ffff 1.5GB PCIE memory -0x0_f000_0000 (0xf_0000_0000) - 0x0_f1ff_ffff 32MB DCSR (includes trace buffers) -0x0_f400_0000 (0xf_f400_0000) - 0x0_f5ff_ffff 32MB BMan -0x0_f600_0000 (0xf_f600_0000) - 0x0_f7ff_ffff 32MB QMan -0x0_f800_0000 (0xf_f800_0000) - 0x0_f803_ffff 256KB PCIE IO -0x0_e000_0000 (0xf_e000_0000) - 0x0_efff_ffff 256MB NOR flash -0x0_fe00_0000 (0xf_fe00_0000) - 0x0_feff_ffff 16MB CCSR -0x0_ffdf_0000 (0xf_ffdf_0000) - 0x0_ffdf_03ff 4KB QIXIS -0x0_ffff_f000 (0x0_7fff_fff0) - 0x0_ffff_ffff 4KB Boot page translation for secondary cores - -The physical address of the last (boot page translation) varies with the actual DDR size. - -Voltage ID and VDD override --------------------- -T4240 has a VID feature. U-boot reads the VID efuses and adjust the voltage -accordingly. The voltage can also be override by command vdd_override. The -syntax is - -vdd_override <voltage in mV>, eg. 1050 is for 1.050v. - -Upon success, the actual voltage will be read back. The value is checked -for safety and any invalid value will not adjust the voltage. - -Another way to override VDD is to use environmental variable, in case of using -command is too late for some debugging. The syntax is - -setenv t4240qds_vdd_mv <voltage in mV> -saveenv -reset - -The override voltage takes effect when booting. - -Note: voltage adjustment needs to be done step by step. Changing voltage too -rapidly may cause current surge. The voltage stepping is done by software. -Users can set the final voltage directly. - -2-stage NAND/SD boot loader -------------------------------- -PBL initializes the internal SRAM and copy SPL(160K) in SRAM. -SPL further initialise DDR using SPD and environment variables -and copy u-boot(768 KB) from NAND/SD device to DDR. -Finally SPL transers control to u-boot for futher booting. - -SPL has following features: - - Executes within 256K - - No relocation required - -Run time view of SPL framework -------------------------------------------------- -|Area | Address | -------------------------------------------------- -|SecureBoot header | 0xFFFC0000 (32KB) | -------------------------------------------------- -|GD, BD | 0xFFFC8000 (4KB) | -------------------------------------------------- -|ENV | 0xFFFC9000 (8KB) | -------------------------------------------------- -|HEAP | 0xFFFCB000 (50KB) | -------------------------------------------------- -|STACK | 0xFFFD8000 (22KB) | -------------------------------------------------- -|U-boot SPL | 0xFFFD8000 (160KB) | -------------------------------------------------- - -NAND Flash memory Map on T4QDS --------------------------------------------------------------- -Start End Definition Size -0x000000 0x0FFFFF u-boot img 1MB -0x140000 0x15FFFF u-boot env 128KB -0x160000 0x17FFFF FMAN Ucode 128KB - -Micro SD Card memory Map on T4QDS ----------------------------------------------------- -Block #blocks Definition Size -0x008 2048 u-boot img 1MB -0x800 0016 u-boot env 8KB -0x820 0128 FMAN ucode 64KB - -Switch Settings: (ON is 1, OFF is 0) -=============== -NAND boot SW setting: -SW1[1:8] = 10000010 -SW2[1.1] = 0 -SW6[1:4] = 1001 - -SD boot SW setting: -SW1[1:8] = 00100000 -SW2[1.1] = 0 diff --git a/qemu/roms/u-boot/doc/README.trace b/qemu/roms/u-boot/doc/README.trace deleted file mode 100644 index f0c969977..000000000 --- a/qemu/roms/u-boot/doc/README.trace +++ /dev/null @@ -1,348 +0,0 @@ -# -# Copyright (c) 2013 The Chromium OS Authors. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -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) - -#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: - -$ 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: - -$ ./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 -=>sb 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. - -$ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt - -Finally run pytimechart to display it: - -$ 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/qemu/roms/u-boot/doc/README.ubi b/qemu/roms/u-boot/doc/README.ubi deleted file mode 100644 index 9efab6cdc..000000000 --- a/qemu/roms/u-boot/doc/README.ubi +++ /dev/null @@ -1,225 +0,0 @@ -------------------- -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! diff --git a/qemu/roms/u-boot/doc/README.ublimage b/qemu/roms/u-boot/doc/README.ublimage deleted file mode 100644 index ab25b2615..000000000 --- a/qemu/roms/u-boot/doc/README.ublimage +++ /dev/null @@ -1,141 +0,0 @@ ---------------------------------------------- -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/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt b/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt deleted file mode 100644 index 00529f5da..000000000 --- a/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt +++ /dev/null @@ -1,240 +0,0 @@ -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/qemu/roms/u-boot/doc/README.update b/qemu/roms/u-boot/doc/README.update deleted file mode 100644 index a7f4d9ebe..000000000 --- a/qemu/roms/u-boot/doc/README.update +++ /dev/null @@ -1,95 +0,0 @@ -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. - -This mechanism can be also triggered by the commmand "fitupd". -If an optional, non-zero address is provided as argument, the TFTP transfer -is skipped and the image at this address is used. -The fitupd command is enabled by CONFIG_CMD_FITUPD. - - -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. diff --git a/qemu/roms/u-boot/doc/README.usb b/qemu/roms/u-boot/doc/README.usb deleted file mode 100644 index bc768a385..000000000 --- a/qemu/roms/u-boot/doc/README.usb +++ /dev/null @@ -1,228 +0,0 @@ -/* - * (C) Copyright 2001 - * Denis Peter, MPL AG Switzerland - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -USB Support for PIP405 and MIP405 (UHCI) -======================================== - -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 header file: - -#define CONFIG_CMD_USB /* the 'usb' interactive command */ -#define CONFIG_USB_HOST_ETHER /* Enable USB Ethernet adapters */ - -and one or more of the following for individual adapter hardware: - -#define CONFIG_USB_ETHER_ASIX -#define CONFIG_USB_ETHER_MCS7830 -#define CONFIG_USB_ETHER_SMSC95XX - -As with built-in networking, you will also want to enable some network -commands, for example: - -#define CONFIG_CMD_NET -#define CONFIG_CMD_PING -#define CONFIG_CMD_DHCP - -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/qemu/roms/u-boot/doc/README.vf610 b/qemu/roms/u-boot/doc/README.vf610 deleted file mode 100644 index 38cf5cfd2..000000000 --- a/qemu/roms/u-boot/doc/README.vf610 +++ /dev/null @@ -1,10 +0,0 @@ -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/qemu/roms/u-boot/doc/README.video b/qemu/roms/u-boot/doc/README.video deleted file mode 100644 index dadbfcd2f..000000000 --- a/qemu/roms/u-boot/doc/README.video +++ /dev/null @@ -1,31 +0,0 @@ -/* - * (C) Copyright 2000 - * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -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 - -"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 - -Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi diff --git a/qemu/roms/u-boot/doc/README.vxworks b/qemu/roms/u-boot/doc/README.vxworks deleted file mode 100644 index 4cb302e7f..000000000 --- a/qemu/roms/u-boot/doc/README.vxworks +++ /dev/null @@ -1,19 +0,0 @@ -From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware -decription mechansim (for PowerPC and ARM), thus requiring boot interface changes. -This section will describe the new interface. - -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 show below: - - void (*kernel_entry)(void *fdt_addr) - -When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below: - - bootm <kernel image address> - <device tree address> - -The do_bootvx command still works as it was for older VxWorks kernels. diff --git a/qemu/roms/u-boot/doc/README.watchdog b/qemu/roms/u-boot/doc/README.watchdog deleted file mode 100644 index 59f306b85..000000000 --- a/qemu/roms/u-boot/doc/README.watchdog +++ /dev/null @@ -1,35 +0,0 @@ -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_AT91SAM9_WATCHDOG - 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. - -CONFIG_XILINX_TB_WATCHDOG - Available for Xilinx Axi platforms to service timebase watchdog timer. - -CONFIG_BFIN_WATCHDOG - Available for bf5xx and bf6xx to service the watchdog. diff --git a/qemu/roms/u-boot/doc/README.zfs b/qemu/roms/u-boot/doc/README.zfs deleted file mode 100644 index 7f237c407..000000000 --- a/qemu/roms/u-boot/doc/README.zfs +++ /dev/null @@ -1,29 +0,0 @@ -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/qemu/roms/u-boot/doc/README.zynq b/qemu/roms/u-boot/doc/README.zynq deleted file mode 100644 index 043c97014..000000000 --- a/qemu/roms/u-boot/doc/README.zynq +++ /dev/null @@ -1,94 +0,0 @@ -# -# Xilinx ZYNQ U-Boot -# -# (C) Copyright 2013 Xilinx, Inc. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -1. About this - -This document describes the information about Xilinx Zynq U-Boot - -like supported boards, ML status and TODO list. - -2. Zynq boards - -Xilinx Zynq-7000 All Programmable SoCs enable extensive system level -differentiation, integration, and flexibility through hardware, software, -and I/O programmability. - -* zc70x - - 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) - -3. Building - - # Configure for zc70x board - $ make zynq_zc70x_config - Configuring for zynq_zc70x board... - - # Building default dts for zc702 board - $ make - - # Building specified dts for zc706 board - $ make DEVICE_TREE=zynq-zc706 - -4. 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 -#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. - -5. Mainline status - -- Added basic board configurations support. -- Added zynq u-boot bsp code - arch/arm/cpu/armv7/zynq -- Added zynq boards named - zc70x, zed, microzed, zc770_xm010, zc770_xm012, zc770_xm013 -- Added zynq drivers: - serial - drivers/serial/serial_zynq.c - net - drivers/net/zynq_gem.c - mmc - drivers/mmc/zynq_sdhci.c - mmc - drivers/mmc/zynq_sdhci.c - spi- drivers/spi/zynq_spi.c - i2c - drivers/i2c/zynq_i2c.c -- Done proper cleanups on board configurations -- Added basic FDT support for zynq boards -- d-cache support for zynq_gem.c - -6. TODO - -- Add zynq boards support - zc770_xm011 -- Add zynq qspi controller driver -- Add zynq nand controller driver -- Add FDT support on individual drivers - -[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/qemu/roms/u-boot/doc/SPI/README.dual-flash b/qemu/roms/u-boot/doc/SPI/README.dual-flash deleted file mode 100644 index 6c88d65dd..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.dual-flash +++ /dev/null @@ -1,92 +0,0 @@ -SPI/QSPI Dual flash connection modes: -===================================== - -This describes how SPI/QSPI flash memories are connected to a given -controller in a single chip select line. - -Current spi_flash framework supports, single flash memory connected -to a given controller with single chip select line, but there are some -hw logics(ex: xilinx zynq qspi) that describes two/dual memories are -connected with a single chip select line from a controller. - -"dual_flash" from include/spi.h describes these types of connection mode - -Possible connections: --------------------- -SF_SINGLE_FLASH: - - single spi flash memory connected with single chip select line. - - +------------+ CS +---------------+ - | |----------------------->| | - | Controller | I0[3:0] | Flash memory | - | SPI/QSPI |<======================>| (SPI/QSPI) | - | | CLK | | - | |----------------------->| | - +------------+ +---------------+ - -SF_DUAL_STACKED_FLASH: - - dual spi/qspi flash memories are connected with a single chipselect - line and these two memories are operating stacked fasion with shared buses. - - xilinx zynq qspi controller has implemented this feature [1] - - +------------+ CS +---------------+ - | |---------------------->| | - | | I0[3:0] | Upper Flash | - | | +=========>| memory | - | | | CLK | (SPI/QSPI) | - | | | +---->| | - | Controller | CS | | +---------------+ - | SPI/QSPI |------------|----|---->| | - | | I0[3:0] | | | Lower Flash | - | |<===========+====|====>| memory | - | | CLK | | (SPI/QSPI) | - | |-----------------+---->| | - +------------+ +---------------+ - - - two memory flash devices should has same hw part attributes (like size, - vendor..etc) - - Configurations: - on LQSPI_CFG register, Enable TWO_MEM[BIT:30] on LQSPI_CFG - Enable U_PAGE[BIT:28] if U_PAGE flag set - upper memory - Disable U_PAGE[BIT:28] if U_PAGE flag unset - lower memory - - Operation: - accessing memories serially like one after another. - by default, if U_PAGE is unset lower memory should accessible, - once user wants to access upper memory need to set U_PAGE. - -SPI_FLASH_CONN_DUALPARALLEL: - - dual spi/qspi flash memories are connected with a single chipselect - line and these two memories are operating parallel with separate buses. - - xilinx zynq qspi controller has implemented this feature [1] - - +-------------+ CS +---------------+ - | |---------------------->| | - | | I0[3:0] | Upper Flash | - | |<=====================>| memory | - | | CLK | (SPI/QSPI) | - | |---------------------->| | - | Controller | CS +---------------+ - | SPI/QSPI |---------------------->| | - | | I0[3:0] | Lower Flash | - | |<=====================>| memory | - | | CLK | (SPI/QSPI) | - | |---------------------->| | - +-------------+ +---------------+ - - - two memory flash devices should has same hw part attributes (like size, - vendor..etc) - - Configurations: - Need to enable SEP_BUS[BIT:29],TWO_MEM[BIT:30] on LQSPI_CFG register. - - Operation: - Even bits, i.e. bit 0, 2, 4 ., of a data word is located in the lower memory - and odd bits, i.e. bit 1, 3, 5, ., of a data word is located in the upper memory. - -Note: Technically there is only one CS line from the controller, but -zynq qspi controller has an internal hw logic to enable additional CS -when controller is configured for dual memories. - -[1] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf - --- -Jagannadha Sutradharudu Teki <jaganna@xilinx.com> -05-01-2014. diff --git a/qemu/roms/u-boot/doc/SPI/README.ftssp010_spi_test b/qemu/roms/u-boot/doc/SPI/README.ftssp010_spi_test deleted file mode 100644 index 1d86f3623..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.ftssp010_spi_test +++ /dev/null @@ -1,41 +0,0 @@ -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/qemu/roms/u-boot/doc/SPI/README.sandbox-spi b/qemu/roms/u-boot/doc/SPI/README.sandbox-spi deleted file mode 100644 index bb73eaf28..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.sandbox-spi +++ /dev/null @@ -1,64 +0,0 @@ -Sandbox SPI/SPI Flash Implementation -==================================== - -U-Boot supports SPI and SPI flash emuation in sandbox. This must be enabled -using the --spi_sf paramter when starting U-Boot. - -For example: - -$ make O=sandbox sandbox_config -$ make O=sandbox -$ ./sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin - -The four parameters to spi_sf are: - - SPI bus number (typically 0) - SPI chip select number (typically 0) - SPI chip to emulate - File containing emulated data - -Supported chips are W25Q16 (2MB), W25Q32 (4MB) and W25Q128 (16MB). Once -U-Boot it started you can use 'sf' commands as normal. For example: - -$ ./b/sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin \ - -c "sf probe; sf test 0 100000; sf read 0 1000 1000; \ - sf erase 1000 1000; sf write 0 1000 1000" - - -U-Boot 2013.10-00237-gd4e0fdb (Nov 07 2013 - 20:08:15) - -DRAM: 128 MiB -Using default environment - -In: serial -Out: serial -Err: serial -SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB -SPI flash test: -0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps -1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps -2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps -3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps -Test passed -0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps -1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps -2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps -3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps -SF: 4096 bytes @ 0x1000 Read: OK -SF: 4096 bytes @ 0x1000 Erased: OK -SF: 4096 bytes @ 0x1000 Written: OK - - -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 -FFEF4018 - - -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/qemu/roms/u-boot/doc/SPI/README.sh_qspi_test b/qemu/roms/u-boot/doc/SPI/README.sh_qspi_test deleted file mode 100644 index 8a33fec32..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.sh_qspi_test +++ /dev/null @@ -1,38 +0,0 @@ -------------------------------------------------- - 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/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test deleted file mode 100644 index 8fbf10b57..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test +++ /dev/null @@ -1,76 +0,0 @@ -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/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test deleted file mode 100644 index fe3785723..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test +++ /dev/null @@ -1,48 +0,0 @@ -------------------------------------------------- - 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 -SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR -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/qemu/roms/u-boot/doc/SPI/README.ti_qspi_flash b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_flash deleted file mode 100644 index 1b86d01a0..000000000 --- a/qemu/roms/u-boot/doc/SPI/README.ti_qspi_flash +++ /dev/null @@ -1,47 +0,0 @@ -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 -controler 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/qemu/roms/u-boot/doc/SPI/status.txt b/qemu/roms/u-boot/doc/SPI/status.txt deleted file mode 100644 index 13889f545..000000000 --- a/qemu/roms/u-boot/doc/SPI/status.txt +++ /dev/null @@ -1,32 +0,0 @@ -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/qemu/roms/u-boot/doc/SPL/README.am335x-network b/qemu/roms/u-boot/doc/SPL/README.am335x-network deleted file mode 100644 index 9b63791ad..000000000 --- a/qemu/roms/u-boot/doc/SPL/README.am335x-network +++ /dev/null @@ -1,92 +0,0 @@ -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"; - } -} - - 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/qemu/roms/u-boot/doc/SPL/README.omap3 b/qemu/roms/u-boot/doc/SPL/README.omap3 deleted file mode 100644 index c77ca4300..000000000 --- a/qemu/roms/u-boot/doc/SPL/README.omap3 +++ /dev/null @@ -1,52 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/README b/qemu/roms/u-boot/doc/device-tree-bindings/README deleted file mode 100644 index 2ea3439a1..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/README +++ /dev/null @@ -1,17 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt b/qemu/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt deleted file mode 100644 index 5c07fcaed..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt +++ /dev/null @@ -1,207 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt deleted file mode 100644 index 566da3b63..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt +++ /dev/null @@ -1,54 +0,0 @@ -* Exynos 5250 DWC_mobile_storage - -The Exynos 5250 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 5250 DWC_mobile_storage provides four channels. -SOC specific and Board specific properties are channel specific. - -Required SoC Specific Properties: - -- compatible: should be - - samsung,exynos5250-dwmmc: for exynos5250 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/qemu/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt deleted file mode 100644 index b8086e82b..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt +++ /dev/null @@ -1,22 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt deleted file mode 100644 index 98d1798d0..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt +++ /dev/null @@ -1,27 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt deleted file mode 100644 index 89d3bf05f..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt +++ /dev/null @@ -1,44 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt b/qemu/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt deleted file mode 100644 index 72649dffa..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt +++ /dev/null @@ -1,23 +0,0 @@ -(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/qemu/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt b/qemu/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt deleted file mode 100644 index 311827607..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt +++ /dev/null @@ -1,79 +0,0 @@ -CROS_EC Keyboard - -The CROS_EC (Matrix Keyboard Protocol) allows communcation with a secondary -micro used for keyboard, and possible other features. - -The CROS_EC keyboard uses this protocol to receive key scans and produce input -in U-Boot. - -Required properties : -- compatible : "google,cros-ec-keyb" -- google,key-rows : Number of key rows -- google,key-columns : Number of key columns - -Optional properties, in addition to those specified by the shared -matrix-keyboard bindings: - -- linux,fn-keymap: a second keymap, same specification as the - matrix-keyboard-controller spec but to be used when the KEY_FN modifier - key is pressed. -- google,repeat-delay-ms : delay in milliseconds before repeat starts -- google,repeat-rate-ms : delay between each subsequent key press -- google,ghost-filter : enable ghost filtering for this device - -Example, taken from daisy: - -cros-ec-keyb { - compatible = "google,cros-ec-keyb"; - google,key-rows = <8>; - google,key-columns = <13>; - google,ghost-filter; - google,repeat-delay-ms = <240>; - google,repeat-rate-ms = <30>; - /* - * 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 0x0002003c 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/qemu/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt b/qemu/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt deleted file mode 100644 index 07ea7cdea..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt +++ /dev/null @@ -1,38 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt b/qemu/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt deleted file mode 100644 index 86ae4082d..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt +++ /dev/null @@ -1,53 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt b/qemu/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt deleted file mode 100644 index 01438ecd6..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt +++ /dev/null @@ -1,18 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt b/qemu/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt deleted file mode 100644 index 800dafe5b..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt +++ /dev/null @@ -1,92 +0,0 @@ -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. - -Some SPI controllers and devices support Dual and Quad SPI transfer mode. -It allows data in SPI system transfered 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/qemu/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt b/qemu/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt deleted file mode 100644 index 5282d44ac..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt +++ /dev/null @@ -1,25 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt deleted file mode 100644 index 45ca42db5..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt +++ /dev/null @@ -1,42 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt deleted file mode 100644 index 464a85302..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt +++ /dev/null @@ -1,69 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt deleted file mode 100644 index bb7441cbb..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt +++ /dev/null @@ -1,92 +0,0 @@ -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 - -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/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt deleted file mode 100644 index 4938ea01e..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt +++ /dev/null @@ -1,82 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt deleted file mode 100644 index eb91b30e3..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt +++ /dev/null @@ -1,13 +0,0 @@ -Sandbox LCD -=========== - -This uses the displaymode.txt binding except that only xres and yres are -required properties. - -Example: - - lcd { - compatible = "sandbox,lcd-sdl"; - xres = <800>; - yres = <600>; - }; diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt deleted file mode 100644 index 3ea460583..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt +++ /dev/null @@ -1,25 +0,0 @@ -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/qemu/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt deleted file mode 100644 index 4731c3fba..000000000 --- a/qemu/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt +++ /dev/null @@ -1,85 +0,0 @@ -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/qemu/roms/u-boot/doc/driver-model/README.txt b/qemu/roms/u-boot/doc/driver-model/README.txt deleted file mode 100644 index e0b395a61..000000000 --- a/qemu/roms/u-boot/doc/driver-model/README.txt +++ /dev/null @@ -1,368 +0,0 @@ -Driver Model -============ - -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 invidual 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_config - make - ./u-boot - - (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 platdata (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/dm/test-dm.sh - -You should see something like this: - - <...U-Boot banner...> - Running 12 driver model tests - Test: dm_test_autobind - Test: dm_test_autoprobe - Test: dm_test_children - Test: dm_test_fdt - Test: dm_test_gpio - sandbox_gpio: sb_gpio_get_value: error: offset 4 not reserved - Test: dm_test_leak - Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c - Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c - Test: dm_test_lifecycle - Test: dm_test_operations - Test: dm_test_ordering - Test: dm_test_platdata - Test: dm_test_remove - Test: dm_test_uclass - Failures: 0 - -(You can add '#define DEBUG' as suggested to check for memory leaks) - - -What is going on? ------------------ - -Let's start at the top. The demo command is in common/cmd_demo.c. It does -the usual command procesing and then: - - struct device *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: - - 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: - -int demo_hello(struct device *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: - -static int simple_hello(struct device *dev, int ch) -{ - const struct dm_demo_pdata *pdata = dev_get_platdata(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): - -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 - ofdata_to_platdata - convert device tree data to platdata - 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, ofdata_to_platdata (if using -device tree) and probe. - - -Platform Data -------------- - -Where does the platform data come from? 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 acceess their data via dev->info->platdata. Here is -the declaration for the platform data, which would normally appear -in the board file. - - static const struct dm_demo_cdata red_square = { - .colour = "red", - .sides = 4. - }; - static const struct driver_info info[] = { - { - .name = "demo_shape_drv", - .platdata = &red_square, - }, - }; - - demo1 = driver_bind(root, &info[0]); - - -Device Tree ------------ - -While platdata is useful, a more flexible way of providing device data is -by using device tree. With device tree we replace the above code with the -following device tree fragment: - - red-square { - compatible = "demo-shape"; - colour = "red"; - sides = <4>; - }; - - -The easiest way to make this work it to add a few members to the driver: - - .platdata_auto_alloc_size = sizeof(struct dm_test_pdata), - .ofdata_to_platdata = testfdt_ofdata_to_platdata, - .probe = testfdt_drv_probe, - -The 'auto_alloc' feature allowed space for the platdata to be allocated -and zeroed before the driver's ofdata_to_platdata method is called. This -method reads the information out of the device tree and puts it in -dev->platdata. Then the probe method is called to set up the device. - -Note that both methods are optional. If you provide an ofdata_to_platdata -method then it wlil be called first (after bind). If you provide a probe -method it will be called next. - -If you don't want to have the platdata automatically allocated then you -can leave out platdata_auto_alloc_size. In this case you can use malloc -in your ofdata_to_platdata (or probe) method to allocate the required memory, -and you should free it in the remove method. - - -Declaring Uclasses ------------------- - -The demo uclass is declared like this: - -U_BOOT_CLASS(demo) = { - .id = UCLASS_DEMO, -}; - -It is also possible to specify special methods for probe, etc. The uclass -numbering comes from include/dm/uclass.h. To add a new uclass, add to the -end of the enum there, then declare your uclass as above. - - -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 agressively 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 device -instead of struct instance, struct platdata, 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 device'. -This removes a level of indirection that doesn't seem necessary. -- Built in device tree support, to avoid the need for platdata -- 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 - - -Things to punt for later ------------------------- - -- SPL support - this will have to be present before many drivers can be -converted, but it seems like we can add it once we are happy with the -core implementation. -- Pre-relocation support - similar story - -That is not to say that no thinking has gone into these - in fact there -is quite a lot there. However, getting these right is non-trivial and -there is a high cost associated with going down the wrong path. - -For SPL, it may be possible to fit in a simplified driver model with only -bind and probe methods, to reduce size. - -For pre-relocation we can simply call the driver model init function. 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. - -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. - - -Simon Glass -sjg@chromium.org -April 2013 -Updated 7-May-13 -Updated 14-Jun-13 -Updated 18-Oct-13 -Updated 5-Nov-13 diff --git a/qemu/roms/u-boot/doc/feature-removal-schedule.txt b/qemu/roms/u-boot/doc/feature-removal-schedule.txt deleted file mode 100644 index 16819c775..000000000 --- a/qemu/roms/u-boot/doc/feature-removal-schedule.txt +++ /dev/null @@ -1,43 +0,0 @@ -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: Remove unused CONFIG_SYS_MEMTEST_START/END -When: Release v2013.10 - -Why: As the 'mtest' command is no longer default, a number of platforms - have not opted to turn the command back on and thus provide unused - defines (which are likely to be propogated to new platforms from - copy/paste). Remove these defines when unused. - -Who: Tom Rini <trini@ti.com> - ---------------------------- - -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@freescale.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/qemu/roms/u-boot/doc/git-mailrc b/qemu/roms/u-boot/doc/git-mailrc deleted file mode 100644 index 251586e05..000000000 --- a/qemu/roms/u-boot/doc/git-mailrc +++ /dev/null @@ -1,112 +0,0 @@ -# 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 aaribaud Albert Aribaud <albert.u.boot@aribaud.net> -alias abiessmann Andreas Bießmann <andreas.devel@googlemail.com> -alias afleming Andy Fleming <afleming@freescale.com> -alias ag Anatolij Gustschin <agust@denx.de> -alias galak Kumar Gala <galak@kernel.crashing.org> -alias gruss Graeme Russ <graeme.russ@gmail.com> -alias hs Heiko Schocher <hs@denx.de> -alias iwamatsu Nobuhiro Iwamatsu <iwamatsu@nigauri.org> -alias jagan Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> -alias jasonjin Jason Jin <jason.jin@freescale.com> -alias jhersh Joe Hershberger <joe.hershberger@gmail.com> -alias kimphill Kim Phillips <kim.phillips@freescale.com> -alias macpaul Macpaul Lin <macpaul@andestech.com> -alias marex Marek Vasut <marex@denx.de> -alias monstr Michal Simek <monstr@monstr.eu> -alias panto Pantelis Antoniou <panto@antoniou-consulting.com> -alias prafulla Prafulla Wadaskar <prafulla@marvell.com> -alias prom Minkyu Kang <mk7.kang@samsung.com> -alias rbohmer Remy Bohmer <linux@bohmer.net> -alias reinhardm Reinhard Meyer <u-boot@emk-elektronik.de> -alias sbabic Stefano Babic <sbabic@denx.de> -alias scottwood Scott Wood <scottwood@freescale.com> -alias sjg Simon Glass <sjg@chromium.org> -alias smcnutt Scott McNutt <smcnutt@psyent.com> -alias sonic Sonic Zhang <sonic.adi@gmail.com> -alias stroese Stefan Roese <sr@denx.de> -alias trini Tom Rini <trini@ti.com> -alias vapier Mike Frysinger <vapier@gentoo.org> -alias wd Wolfgang Denk <wd@denx.de> - -# Architecture aliases -alias arch arm, avr32, bfin, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, sparc, x86 -alias arches arch - -alias arm uboot, aaribaud -alias at91 uboot, abiessmann -alias davinci ti -alias imx uboot, sbabic -alias kirkwood uboot, prafulla -alias omap ti -alias pxa uboot, marex -alias rmobile uboot, iwamatsu -alias s3c samsung -alias s5pc samsung -alias samsung uboot, prom -alias tegra uboot, sjg, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com> -alias tegra2 tegra -alias ti uboot, trini - -alias avr32 uboot, abiessmann - -alias bfin uboot, vapier, sonic -alias blackfin bfin - -alias m68k uboot, jasonjin -alias coldfire m68k - -alias microblaze uboot, monstr -alias mb microblaze - -alias mips uboot, Shinya Kuribayashi <skuribay@pobox.com> - -alias nds32 uboot, macpaul - -alias nios uboot, Thomas Chou <thomas@wytron.com.tw>, smcnutt -alias nios2 nios - -alias powerpc uboot, afleming, kimphill, galak, stroese, wd -alias ppc powerpc -alias mpc5xxx uboot, wd -alias mpc8xx uboot, wd -alias mpc82xx uboot, wd -alias mpc83xx uboot, kimphill -alias mpc85xx uboot, afleming, galak -alias mpc86xx uboot, afleming, galak -alias ppc4xx uboot, stroese -alias ppc7xx uboot, wd -alias ppc74xx uboot, wd - -alias sandbox sjg -alias sb sandbox - -alias sparc uboot, Daniel Hellstrom <daniel@gaisler.com> - -alias superh uboot, iwamatsu -alias sh superh - -alias x86 uboot, sjg, gruss - -# Subsystem aliases -alias cfi uboot, stroese -alias kerneldoc uboot, marex -alias fdt uboot, Jerry Van Baren <vanbaren@cideas.com> -alias i2c uboot, hs -alias mmc uboot, panto -alias nand uboot, scottwood -alias net uboot, jhersh -alias spi uboot, jagan -alias usb uboot, marex -alias video uboot, ag diff --git a/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt b/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt deleted file mode 100644 index 6c99b1c15..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt +++ /dev/null @@ -1,191 +0,0 @@ -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> -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> - - -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 "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/qemu/roms/u-boot/doc/uImage.FIT/howto.txt b/qemu/roms/u-boot/doc/uImage.FIT/howto.txt deleted file mode 100644 index 526be55a5..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/howto.txt +++ /dev/null @@ -1,297 +0,0 @@ -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 -www.jdl.com 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) - - -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@1) - 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@1 - - -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@1) - 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@1 - -=> bootm -## Booting kernel from FIT Image at 00900000 ... - Using 'config@1' configuration - Trying 'kernel@1' 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@1) - 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@1 - 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@1) - 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@1 - FDT: fdt@1 -=> bootm -## Booting kernel from FIT Image at 00900000 ... - Using 'conf@1' configuration - Trying 'kernel@1' 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/qemu/roms/u-boot/doc/uImage.FIT/kernel.its b/qemu/roms/u-boot/doc/uImage.FIT/kernel.its deleted file mode 100644 index ef3ab8f72..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/kernel.its +++ /dev/null @@ -1,37 +0,0 @@ -/* - * Simple U-boot uImage source file containing a single kernel - */ - -/dts-v1/; - -/ { - description = "Simple image with single Linux kernel"; - #address-cells = <1>; - - images { - kernel@1 { - 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@1"; - }; - }; -}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its b/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its deleted file mode 100644 index 7e940d2af..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its +++ /dev/null @@ -1,51 +0,0 @@ -/* - * 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@1 { - 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@1"; - fdt = "fdt@1"; - }; - }; -}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/multi.its b/qemu/roms/u-boot/doc/uImage.FIT/multi.its deleted file mode 100644 index 881b74952..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/multi.its +++ /dev/null @@ -1,133 +0,0 @@ -/* - * 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/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its b/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its deleted file mode 100644 index 3c17f040d..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its +++ /dev/null @@ -1,45 +0,0 @@ -/dts-v1/; - -/ { - description = "Chrome OS kernel image with one or more FDT blobs"; - #address-cells = <1>; - - images { - kernel@1 { - 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@1"; - fdt = "fdt@1"; - signature@1 { - algo = "sha1,rsa2048"; - key-name-hint = "dev"; - sign-images = "fdt", "kernel"; - }; - }; - }; -}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its b/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its deleted file mode 100644 index f69326a39..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its +++ /dev/null @@ -1,42 +0,0 @@ -/dts-v1/; - -/ { - description = "Chrome OS kernel image with one or more FDT blobs"; - #address-cells = <1>; - - images { - kernel@1 { - data = /incbin/("test-kernel.bin"); - type = "kernel_noload"; - arch = "sandbox"; - os = "linux"; - compression = "none"; - load = <0x4>; - entry = <0x8>; - kernel-version = <1>; - signature@1 { - 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@1 { - algo = "sha1,rsa2048"; - key-name-hint = "dev"; - }; - }; - }; - configurations { - default = "conf@1"; - conf@1 { - kernel = "kernel@1"; - fdt = "fdt@1"; - }; - }; -}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/signature.txt b/qemu/roms/u-boot/doc/uImage.FIT/signature.txt deleted file mode 100644 index 950203770..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/signature.txt +++ /dev/null @@ -1,400 +0,0 @@ -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 and certificate ------------------------------------ -To create a new public key, size 2048 bits: - -$ openssl genrsa -F4 -out keys/dev.key 2048 - -To create a certificate for this: - -$ 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 thes 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,rs2048") - -- 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 - -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@1", - "/images/kernel@1/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,rs2048") - -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 verfication -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,r-squared: (2^num-bits)^2 as a big-endian multi-word integer -- rsa,n0-inverse: -1 / modulus[0] mod 2^32 - - -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@1 { - 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@1 { - 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 solved 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. - - -Enabling FIT Verification -------------------------- -In addition to the options to enable FIT itself, the following CONFIGs must -be enabled: - -CONFIG_FIT_SIGNATURE - enable signing and verfication in FITs -CONFIG_RSA - enable RSA algorithm for signing - - -Testing -------- -An easy way to test signing and verfication 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 -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 -OK -Test Verified Boot Run: signed config: OK -Test Verified Boot Run: signed config with bad hash: OK - -Test passed - -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/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt b/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt deleted file mode 100644 index 9ed6f65e5..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt +++ /dev/null @@ -1,261 +0,0 @@ -U-boot new uImage source file format (bindings definition) -========================================================== - -Author: Marian Balakowicz <m8@semihalf.com> - -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 - 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 img@1 {...} - | o img@2 {...} - | ... - | - o configurations - |- default = "cfg@1" - | - o cfg@1 {...} - o cfg@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 node: - - 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. - - Optional node: - - 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", "ramdisk", "firmware", "script", "filesystem", - "flat_dt". - - 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". - - Conditionally mandatory property: - - os : OS name, mandatory for type="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". - - entry : entry point address, address size is determined by - '#address-cells' property of the root node. Mandatory for for types: - "standalone" and "kernel". - - load : load address, address size is determined by '#address-cells' - property of the root node. Mandatory for types: "standalone" and "kernel". - - 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 is optional. If present, it allows to create a -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" - |- ramdisk = "ramdisk sub-node unit name" - |- fdt = "fdt sub-node unit-name" - - - Mandatory properties: - - description : Textual configuration description. - - kernel : Unit name of the corresponding kernel image (image sub-node of a - "kernel" type). - - Optional properties: - - ramdisk : Unit name of the corresponding ramdisk image (component image - node of a "ramdisk" type). - - fdt : Unit name of the corresponding fdt blob (component image node of a - "fdt type"). - -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) Examples ------------ - -Please see doc/uImage.FIT/*.its for actual image source files. diff --git a/qemu/roms/u-boot/doc/uImage.FIT/update3.its b/qemu/roms/u-boot/doc/uImage.FIT/update3.its deleted file mode 100644 index a6eaef691..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/update3.its +++ /dev/null @@ -1,44 +0,0 @@ -/* - * 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/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its b/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its deleted file mode 100644 index 846723e2d..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its +++ /dev/null @@ -1,24 +0,0 @@ -/* - * 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 = <FFFC0000>; - hash@1 { - algo = "sha1"; - }; - }; - }; -}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt b/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt deleted file mode 100644 index 3c83fbc2c..000000000 --- a/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt +++ /dev/null @@ -1,104 +0,0 @@ -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 ben 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 alreay 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 it 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 |