diff options
| author |   Yang Zhang <yang.z.zhang@intel.com> | 2015-08-28 09:58:54 +0800 |
|---|---|---|
| committer | Yang Zhang <yang.z.zhang@intel.com> | 2015-09-01 12:44:00 +0800 |
| commit | e44e3482bdb4d0ebde2d8b41830ac2cdb07948fb (patch) | |
| tree | 66b09f592c55df2878107a468a91d21506104d3f /qemu/roms/u-boot/doc | |
| parent | 9ca8dbcc65cfc63d6f5ef3312a33184e1d726e00 (diff) | |
Add qemu 2.4.0
Change-Id: Ic99cbad4b61f8b127b7dc74d04576c0bcbaaf4f5
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Diffstat (limited to 'qemu/roms/u-boot/doc')
189 files changed, 18286 insertions, 0 deletions
diff --git a/qemu/roms/u-boot/doc/DocBook/.gitignore b/qemu/roms/u-boot/doc/DocBook/.gitignore new file mode 100644 index 000000000..7ebd5465d --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/.gitignore @@ -0,0 +1,15 @@ +*.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 new file mode 100644 index 000000000..593237f04 --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/Makefile @@ -0,0 +1,221 @@ +### +# 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 new file mode 100644 index 000000000..7a79ec54b --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/docbook.css @@ -0,0 +1,16 @@ +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 new file mode 100644 index 000000000..f1975165d --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/linker_lists.tmpl @@ -0,0 +1,46 @@ +<?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 new file mode 100644 index 000000000..4783abb0a --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/stdio.tmpl @@ -0,0 +1,46 @@ +<?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 new file mode 100644 index 000000000..85b252751 --- /dev/null +++ b/qemu/roms/u-boot/doc/DocBook/stylesheet.xsl @@ -0,0 +1,10 @@ +<?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 new file mode 100644 index 000000000..f4a996870 --- /dev/null +++ b/qemu/roms/u-boot/doc/I2C_Edge_Conditions @@ -0,0 +1,46 @@ +I2C Edge Conditions: +==================== + + I2C devices may be left in a write state if a read was occuring + and the CPU was reset. This may result in EEPROM data corruption. + + The edge condition is as follows: + 1) A read operation begins. + 2) I2C controller issues a start command. + 3) The I2C writes the device address. + 4) The CPU is reset at this point. + + Once the CPU reinitializes and the read is tried again: + 1) The I2C controller issues a start command. + 2) The I2C controller writes the device address. + 3) The I2C controller writes the offset. + + The EEPROM sees: + 1) START + 2) device address + 3) START "this start is ignored by most EEPROMs" + 4) device address "EEPROM interprets this as offset" + 5) Offset in device, "EEPROM interprets this as data to write" + + The device will interpret this sequence as a WRITE command and + write rubbish into itself, i.e. the "offset" will be interpreted + as data to be written in location "device address". + +Notes +----- +!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A AMCC 4xx BUG!!! + +This reset edge condition could possibly be present in every I2C +controller and device available. For boards where a I2C bus reset +function can be implemented a i2c_init_board() function should be +provided and enabled by #define'ing CONFIG_SYS_I2C_INIT_BOARD in your +board's config file. Note that this is NOT necessary when using the +bit-banging I2C driver (common/soft_i2c.c) as this already includes +the I2C bus reset sequence. + + +Many thanks to Bill Hunter for finding this serious BUG. +email to: <williamhunter@attbi.com> + +Erik Theisen <etheisen@mindspring.com> +Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET) diff --git a/qemu/roms/u-boot/doc/README.440-DDR-performance b/qemu/roms/u-boot/doc/README.440-DDR-performance new file mode 100644 index 000000000..17bc74764 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.440-DDR-performance @@ -0,0 +1,90 @@ +AMCC suggested to set the PMU bit to 0 for best performace on the +PPC440 DDR controller. The 440er common DDR setup files (sdram.c & +spd_sdram.c) are changed accordingly. So all 440er boards using +these setup routines will automatically receive this performance +increase. + +Please see below some benchmarks done by AMCC to demonstrate this +performance changes: + + +---------------------------------------- +SDRAM0_CFG0[PMU] = 1 (U-boot default for Bamboo, Yosemite and Yellowstone) +---------------------------------------- +Stream benchmark results +------------------------------------------------------------- +This system uses 8 bytes per DOUBLE PRECISION word. +------------------------------------------------------------- +Array size = 2000000, Offset = 0 +Total memory required = 45.8 MB. +Each test is run 10 times, but only +the *best* time for each is used. +------------------------------------------------------------- +Your clock granularity/precision appears to be 1 microseconds. +Each test below will take on the order of 112345 microseconds. + (= 112345 clock ticks) +Increase the size of the arrays if this shows that you are not getting +at least 20 clock ticks per test. +------------------------------------------------------------- +WARNING -- The above is only a rough guideline. +For best results, please be sure you know the precision of your system +timer. +------------------------------------------------------------- +Function Rate (MB/s) RMS time Min time Max time +Copy: 256.7683 0.1248 0.1246 0.1250 +Scale: 246.0157 0.1302 0.1301 0.1302 +Add: 255.0316 0.1883 0.1882 0.1885 +Triad: 253.1245 0.1897 0.1896 0.1899 + + +TTCP Benchmark Results +ttcp-t: socket +ttcp-t: connect +ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp -> +localhost +ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++ +ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57 +ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw + +---------------------------------------- +SDRAM0_CFG0[PMU] = 0 (Suggested modification) +Setting PMU = 0 provides a noticeable performance improvement *2% to +5% improvement in memory performance. +*Improves the Mbit/sec for TTCP benchmark by almost 76%. +---------------------------------------- +Stream benchmark results +------------------------------------------------------------- +This system uses 8 bytes per DOUBLE PRECISION word. +------------------------------------------------------------- +Array size = 2000000, Offset = 0 +Total memory required = 45.8 MB. +Each test is run 10 times, but only +the *best* time for each is used. +------------------------------------------------------------- +Your clock granularity/precision appears to be 1 microseconds. +Each test below will take on the order of 120066 microseconds. + (= 120066 clock ticks) +Increase the size of the arrays if this shows that you are not getting +at least 20 clock ticks per test. +------------------------------------------------------------- +WARNING -- The above is only a rough guideline. +For best results, please be sure you know the precision of your system +timer. +------------------------------------------------------------- +Function Rate (MB/s) RMS time Min time Max time +Copy: 262.5167 0.1221 0.1219 0.1223 +Scale: 258.4856 0.1238 0.1238 0.1240 +Add: 262.5404 0.1829 0.1828 0.1831 +Triad: 266.8594 0.1800 0.1799 0.1802 + +TTCP Benchmark Results +ttcp-t: socket +ttcp-t: connect +ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000 tcp -> +localhost +ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++ +ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89 +ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw + + +2006-07-28, Stefan Roese <sr@denx.de> diff --git a/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup b/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup new file mode 100644 index 000000000..901bd875c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.AMCC-eval-boards-cleanup @@ -0,0 +1,31 @@ +--------------------------------------------------------------------- +Cleanup of AMCC eval boards (Walnut/Sycamore, Bubinga, Ebony, Ocotea) +--------------------------------------------------------------------- + +Changes to all AMCC eval boards: +-------------------------------- + +o Changed u-boot image size to 256 kBytes instead of 512 kBytes on most + boards. + +o Use 115200 baud as default console baudrate. + +o Added config option to use redundant environment in flash. This is also + the default setting. Option for environment in nvram is still available + for backward compatibility. + +o Merged board specific flash drivers to common flash driver: + board/amcc/common/flash.c + + +Sycamore/Walnut (one port supporting both eval boards): +------------------------------------------------------- + +o Cleanup to allow easier "cloning" for different (custom) boards: + + o Moved EBC configuration from board specific asm-file "init.S" + using defines in board configuration file. No board specific + asm file needed anymore. + + +August 01 2005, Stefan Roese <sr@denx.de> diff --git a/qemu/roms/u-boot/doc/README.ARC b/qemu/roms/u-boot/doc/README.ARC new file mode 100644 index 000000000..5f414fb2f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ARC @@ -0,0 +1,27 @@ +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 new file mode 100644 index 000000000..d6bd62488 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ARM-SoC @@ -0,0 +1,31 @@ +[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 new file mode 100644 index 000000000..1b120ac3e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ARM-memory-map @@ -0,0 +1,17 @@ +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 new file mode 100644 index 000000000..632cc0546 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.AVR32 @@ -0,0 +1,25 @@ +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 new file mode 100644 index 000000000..8c1718cdc --- /dev/null +++ b/qemu/roms/u-boot/doc/README.AVR32-port-muxing @@ -0,0 +1,208 @@ +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 new file mode 100644 index 000000000..f0e9bc1b3 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.JFFS2 @@ -0,0 +1,74 @@ +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 new file mode 100644 index 000000000..09788d534 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.JFFS2_NAND @@ -0,0 +1,24 @@ +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 new file mode 100644 index 000000000..c3bcb3ac8 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.LED @@ -0,0 +1,78 @@ +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 new file mode 100644 index 000000000..19977ea7e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.LED_display @@ -0,0 +1,26 @@ +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 new file mode 100644 index 000000000..4707cb7df --- /dev/null +++ b/qemu/roms/u-boot/doc/README.MPC866 @@ -0,0 +1,24 @@ +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 new file mode 100644 index 000000000..1613c11ca --- /dev/null +++ b/qemu/roms/u-boot/doc/README.Modem @@ -0,0 +1,72 @@ +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 new file mode 100644 index 000000000..e107166e1 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.N1213 @@ -0,0 +1,55 @@ +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 new file mode 100644 index 000000000..b2b58fc22 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.NDS32 @@ -0,0 +1,41 @@ +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 new file mode 100644 index 000000000..af7fc6043 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.NetConsole @@ -0,0 +1,97 @@ + +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 new file mode 100644 index 000000000..dd1c632bc --- /dev/null +++ b/qemu/roms/u-boot/doc/README.OFT @@ -0,0 +1,28 @@ +Open Firmware Flat Tree and usage. +---------------------------------- + +As part of the ongoing cleanup of the Linux PPC trees, the preferred +way to pass bootloader and board setup information is the open +firmware flat tree. + +Please take a look at the following email discussion for some +background. + + http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html + http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html + +The generated tree is part static and part dynamic. + +There is a static part which is compiled in with DTC and a dynamic +part which is programmatically appended. + +You'll need a fairly recent DTC tool, which is available by git at + + rsync://ozlabs.org/dtc/dtc.git + +The xxd binary dumper is needed too which I got from + + ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz + + +Pantelis Antoniou, 13 Oct 2005 diff --git a/qemu/roms/u-boot/doc/README.POST b/qemu/roms/u-boot/doc/README.POST new file mode 100644 index 000000000..6815d491c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.POST @@ -0,0 +1,743 @@ +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 new file mode 100644 index 000000000..da9ec459a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.SNTP @@ -0,0 +1,17 @@ +To use SNTP support, add define CONFIG_CMD_SNTP to the +configuration file of the board. + +The "sntp" command gets network time from NTP time server and +syncronize RTC of the board. This command needs the command line +parameter of server's IP address or environment variable +"ntpserverip". The network time is sent as UTC. So if you want to +set local time to RTC, set the offset in second from UTC to the +environment variable "time offset". + +If the DHCP server provides time server's IP or time offset, you +don't need to set the above environment variables yourself. + +Current limitations of SNTP support: +1. The roundtrip time is ignored. +2. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will + be used. diff --git a/qemu/roms/u-boot/doc/README.SPL b/qemu/roms/u-boot/doc/README.SPL new file mode 100644 index 000000000..57a39a489 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.SPL @@ -0,0 +1,112 @@ +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 new file mode 100644 index 000000000..980debe77 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.TPL @@ -0,0 +1,45 @@ +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 new file mode 100644 index 000000000..4f86d55ea --- /dev/null +++ b/qemu/roms/u-boot/doc/README.VLAN @@ -0,0 +1,15 @@ +U-Boot has networking support for VLANs (802.1q), and CDP (Cisco +Discovery Protocol). + +You control the sending/receiving of VLAN tagged packets with the +"vlan" environmental variable. When not present no tagging is +performed. + +CDP is used mainly to discover your device VLAN(s) when connected to +a Cisco switch. + +Note: In order to enable CDP support a small change is needed in the +networking driver. You have to enable reception of the +01:00:0c:cc:cc:cc MAC address which is a multicast address. + +Various defines control CDP; see the README section. diff --git a/qemu/roms/u-boot/doc/README.VSC3316-3308 b/qemu/roms/u-boot/doc/README.VSC3316-3308 new file mode 100644 index 000000000..925663ba5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.VSC3316-3308 @@ -0,0 +1,43 @@ +This file contains API information of the initialization code written for +Vitesse cross-point devices, VSC3316 and VSC3308 for board B4860QDS + +Author: Shaveta Leekha <shaveta@freescale.com> + +About Device: +============= +VSC 3316/3308 is a low-power, low-cost asynchronous crosspoint switch capable of data rates upto 11.5Gbps. + +VSC3316 has 16 input and 16 output ports whereas VSC3308 has 8 input and 8 output ports. Programming of these devices are performed by two-wire or four-wire serial interface. + +Initialization: +=============== +On reset, VSC devices are in low-power state with all inputs, outputs and connections in an off state. +First thing required is to program it to interface with either two-wire or four-wire interface. +In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. Also for crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register). + +API Overview: +============= + + vsc_if_enable(u8 vsc_addr): + -------------------------- + This API programs VSC to interface with either two-wire or four-wire interface. In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. + Parameters: + vsc_addr - Address of the VSC device on board. + + + vsc3316_config(u8 vsc_addr, int con_arr[][2], u8 num_con): + --------------------------------------------------------- + This API configures the VSC3316 device for required connections. Connection through the VSC device requires the inputs and outputs to be properly configured. + Connection registers are on page 00. It Configures the selected input and output correctly and join them to make a connection. It also program Input state register, Global input ISE, Global input LOS, Global core control, Output mode register and core control registers etc. + vsc3308_config(u8 vsc_addr, int con_arr[][2], u8 num_con) does the essential configurations for VSC3308. + + Parameters: + vsc_addr - Address of the VSC device on board. + con_arr - connection array + num_con - number of connections to be configured + + vsc_wp_config(u8 vsc_addr): + -------------------------- + For crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register), which is done by this API. + Parameters: + vsc_addr - Address of the VSC device on board. diff --git a/qemu/roms/u-boot/doc/README.ag102 b/qemu/roms/u-boot/doc/README.ag102 new file mode 100644 index 000000000..7d142a70d --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ag102 @@ -0,0 +1,36 @@ +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 new file mode 100644 index 000000000..f6a52e3e3 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.arm-caches @@ -0,0 +1,53 @@ +Disabling I-cache: +- Set CONFIG_SYS_ICACHE_OFF + +Disabling D-cache: +- Set CONFIG_SYS_DCACHE_OFF + +Enabling I-cache: +- Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable(). + +Enabling D-cache: +- Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable(). + +Enabling Caches at System Startup: +- Implement enable_caches() for your platform and enable the I-cache and + D-cache from this function. This function is called immediately + after relocation. + +Guidelines for Working with D-cache: + +Memory to Peripheral DMA: +- Flush the buffer after the MPU writes the data and before the DMA is + initiated. + +Peripheral to Memory DMA: +- Invalidate the buffer before starting the DMA. In case there are any dirty + lines from the DMA buffer in the cache, subsequent cache-line replacements + may corrupt the buffer in memory while the DMA is still going on. Cache-line + replacement can happen if the CPU tries to bring some other memory locations + into the cache while the DMA is going on. +- Invalidate the buffer after the DMA is complete and before the MPU reads + it. This may be needed in addition to the invalidation before the DMA + mentioned above, because in some processors memory contents can spontaneously + come to the cache due to speculative memory access by the CPU. If this + happens with the DMA buffer while DMA is going on we have a coherency problem. + +Buffer Requirements: +- Any buffer that is invalidated(that is, typically the peripheral to + memory DMA buffer) should be aligned to cache-line boundary both at + at the beginning and at the end of the buffer. +- If the buffer is not cache-line aligned invalidation will be restricted + to the aligned part. That is, one cache-line at the respective boundary + may be left out while doing invalidation. +- A suitable buffer can be alloced on the stack using the + ALLOC_CACHE_ALIGN_BUFFER macro. + +Cleanup Before Linux: +- cleanup_before_linux() should flush the D-cache, invalidate I-cache, and + disable MMU and caches. +- The following sequence is advisable while disabling d-cache: + 1. 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 new file mode 100644 index 000000000..645b3746c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.arm-relocation @@ -0,0 +1,193 @@ +To make relocation on arm working, the following changes are done: + +At arch level: add linker flag -pie + + This causes the linker to generate fixup tables .rel.dyn and .dynsym, + which must be applied to the relocated image before transferring + control to it. + + These fixups are described in the ARM ELF documentation as type 23 + (program-base-relative) and 2 (symbol-relative) + +At cpu level: modify linker file and add a relocation and fixup loop + + the linker file must be modified to include the .rel.dyn and .dynsym + tables in the binary image, and to provide symbols for the relocation + code to access these tables + + The relocation and fixup loop must be executed after executing + board_init_f at initial location and before executing board_init_r + at final location. + +At board level: + + dram_init(): bd pointer is now at this point not accessible, so only + detect the real dramsize, and store it in gd->ram_size. Bst detected + with get_ram_size(). + +TODO: move also dram initialization there on boards where it is possible. + + Setup of the 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 new file mode 100644 index 000000000..75586dbaa --- /dev/null +++ b/qemu/roms/u-boot/doc/README.arm64 @@ -0,0 +1,46 @@ +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 new file mode 100644 index 000000000..67412136e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.at91 @@ -0,0 +1,174 @@ +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 new file mode 100644 index 000000000..ab3f71342 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.at91-soc @@ -0,0 +1,48 @@ + 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 new file mode 100644 index 000000000..1ec4465ca --- /dev/null +++ b/qemu/roms/u-boot/doc/README.atmel_mci @@ -0,0 +1,77 @@ +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 new file mode 100644 index 000000000..cf8373b54 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.atmel_pmecc @@ -0,0 +1,29 @@ +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 new file mode 100644 index 000000000..14e3660dd --- /dev/null +++ b/qemu/roms/u-boot/doc/README.autoboot @@ -0,0 +1,157 @@ +/* + * (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 new file mode 100644 index 000000000..eada0c7dd --- /dev/null +++ b/qemu/roms/u-boot/doc/README.b4860qds @@ -0,0 +1,366 @@ +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 new file mode 100644 index 000000000..35e9d2706 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.bedbug @@ -0,0 +1,78 @@ +BEDBUG Support for U-Boot +-------------------------- + +These changes implement the bedbug (emBEDded deBUGger) debugger in U-Boot. +A specific implementation is made for the AMCC 405 processor but other flavors +can be easily implemented. + +##################### +### Modifications ### +##################### + +./common/Makefile + Included cmd_bedbug.c and bedbug.c in the Makefile. + +./common/command.c + Added bedbug commands to command table. + +./common/board.c + Added call to initialize debugger on startup. + +./arch/powerpc/cpu/ppc4xx/Makefile + Added bedbug_405.c to the Makefile. + +./arch/powerpc/cpu/ppc4xx/start.S + Added code to handle the debug exception (0x2000) on the 405. + Also added code to handle critical exceptions since the debug + is treated as critical on the 405. + +./arch/powerpc/cpu/ppc4xx/traps.c + Added more detailed output for the program exception to tell + if it is an illegal instruction, privileged instruction or + a trap. Also added debug trap handler. + +./include/ppc_asm.tmpl + Added code to handle critical exceptions + +################# +### New Stuff ### +################# + +./include/bedbug/ppc.h +./include/bedbug/regs.h +./include/bedbug/bedbug.h +./include/bedbug/elf.h [obsoleted by new include/elf.h] +./include/bedbug/tables.h +./include/cmd_bedbug.h +./common/cmd_bedbug.c +./common/bedbug.c + Bedbug library includes code for assembling and disassembling + PowerPC instructions to/from memory as well as handling + hardware breakpoints and stepping through code. These + routines are common to all PowerPC processors. + +./arch/powerpc/cpu/ppc4xx/bedbug_405.c + AMCC PPC405 specific debugger routines. + + +Bedbug support for the MPC860 +----------------------------- + +Changes: + + common/cmd_bedbug.c + Added call to initialize 860 debugger. + + arch/powerpc/cpu/mpc8xx/Makefile + Added new file "bedbug_860.c" to the makefile + + arch/powerpc/cpu/mpc8xx/start.S + Added handler for InstructionBreakpoint (0xfd00) + + arch/powerpc/cpu/mpc8xx/traps.c + Added new routine DebugException() + +New Files: + + arch/powerpc/cpu/mpc8xx/bedbug_860.c + CPU-specific routines for 860 debug registers. diff --git a/qemu/roms/u-boot/doc/README.bitbangMII b/qemu/roms/u-boot/doc/README.bitbangMII new file mode 100644 index 000000000..0a2fa48a5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.bitbangMII @@ -0,0 +1,56 @@ +This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to +support an arbitrary number of mii buses. This feature is useful when your +board uses different mii buses for different phys and all (or a part) of these +buses are implemented via bit-banging mode. + +The driver requires that the following macros should be defined into the board +configuration file: + +CONFIG_BITBANGMII - Enable the miiphybb driver +CONFIG_BITBANGMII_MULTI - Enable the multi bus support + +If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs +to define at least the following macros: + +MII_INIT - Generic code to enable the MII bus (optional) +MDIO_DECLARE - Declaration needed to access to the MDIO pin (optional) +MDIO_ACTIVE - Activate the MDIO pin as out pin +MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin +MDIO_READ - Read the MDIO pin +MDIO(v) - Write v on the MDIO pin +MDC_DECLARE - Declaration needed to access to the MDC pin (optional) +MDC(v) - Write v on the MDC pin + +The previous macros make the driver compatible with the previous version +(that didn't support the multi-bus). + +When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill +the bb_miiphy_buses[] array with a record for each required bus and declare +the bb_miiphy_buses_num variable with the number of mii buses. +The record (struct bb_miiphy_bus) has the following fields/callbacks (see +miiphy.h for details): + +char name[] - The symbolic name that must be equal to the MII bus + registered name +int (*init)() - Initialization function called at startup time (just + before the Ethernet initialization) +int (*mdio_active)() - Activate the MDIO pin as output +int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin +int (*set_mdio)() - Write the MDIO pin +int (*get_mdio)() - Read the MDIO pin +int (*set_mdc)() - Write the MDC pin +int (*delay)() - Delay function +void *priv - Private data used by board specific code + +The board code will look like: + +struct bb_miiphy_bus bb_miiphy_buses[] = { + { .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... }, + { .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... }, + ... +}; +int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) / + sizeof(bb_miiphy_buses[0]); + +2009 Industrie Dial Face S.p.A. + Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com> diff --git a/qemu/roms/u-boot/doc/README.blackfin b/qemu/roms/u-boot/doc/README.blackfin new file mode 100644 index 000000000..a837d90f2 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.blackfin @@ -0,0 +1,46 @@ +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 new file mode 100644 index 000000000..af22a139c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.bootmenu @@ -0,0 +1,99 @@ +/* + * (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 new file mode 100644 index 000000000..5bd3c652a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.bus_vcxk @@ -0,0 +1,68 @@ +/* + * (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 new file mode 100644 index 000000000..d087ff0d6 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.cfi @@ -0,0 +1,29 @@ +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 new file mode 100644 index 000000000..afd5577b0 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.commands @@ -0,0 +1,36 @@ + +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 new file mode 100644 index 000000000..5e0fe8624 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.commands.itest @@ -0,0 +1,16 @@ +A slow day today so here is a revised itest command with provisional +support for comparing strings as well :-)) + +Now table driven to allow the operators +-eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >= + +Uses the expected command modifier for integer compares of width 1, 2 or +4 bytes of .b, .w, .l and the new modifer of .s for a string compare. +String comparison is over the length of the shorter, this hopefully +avoids missing terminators when using an indirect pointer. + +eg. +if itest.l *40000 == 12345678 then; .... +if itest.w *40000 != 1234 then; .... +if itest.b *40000 >= 12 then; .... +if itest.s *40000 -eq hello then; .... diff --git a/qemu/roms/u-boot/doc/README.commands.spl b/qemu/roms/u-boot/doc/README.commands.spl new file mode 100644 index 000000000..ac332731e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.commands.spl @@ -0,0 +1,31 @@ +The spl command is used to export a boot parameter image to RAM. Later +it may implement more functions connected to the SPL. + +SUBCOMMAND EXPORT +To execute the command everything has to be in place as if bootm should be +used. (kernel image, initrd-image, fdt-image etc.) + +export has two subcommands: + atags: exports the ATAGS + fdt: exports the FDT + +Call is: +spl export <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 new file mode 100644 index 000000000..aadf596a8 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.console @@ -0,0 +1,101 @@ +/* + * (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 new file mode 100644 index 000000000..aa7c85011 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.davinci @@ -0,0 +1,159 @@ +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 new file mode 100644 index 000000000..f46721a00 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.davinci.nand_spl @@ -0,0 +1,141 @@ +With this approach, we don't need the UBL any more on DaVinci boards. +A "make boardname" will compile a u-boot.ubl, with UBL Header, which is +needed for the RBL to find the "UBL", which actually is a UBL-compatible +header, nand spl code and u-boot code. + + +As the RBL uses another read function as the "standard" u-boot, +we need a command, which switches between this two read/write +functions, so we can write the UBL header and the spl +code in a format, which the RBL can read. This is realize +(at the moment in board specific code) in the u-boot command +nandrbl + +nandrbl without arguments returns actual mode (rbl or uboot). +with nandrbl mode (mode = "rbl" or "uboot") you can switch +between the two NAND read/write modes. + + +To set up mkimage you need a config file for mkimage, example: +board/ait/cam_enc_4xx/ublimage.cfg + +For information about the configuration please see: +doc/README.ublimage + +Example for the cam_enc_4xx board: +On the cam_enc_4xx board we have a NAND flash with blocksize = 0x20000 and +pagesize = 0x800, so the u-boot.ubl image (which you get with: +"make cam_enc_4xx") looks like this: + +00000000 00 ed ac a1 20 00 00 00 06 00 00 00 05 00 00 00 |.... ...........| +00000010 00 00 00 00 20 00 00 00 ff ff ff ff ff ff ff ff |.... ...........| +00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| +* +00000800 14 00 00 ea 14 f0 9f e5 10 f0 9f e5 0c f0 9f e5 |................| +00000810 08 f0 9f e5 04 f0 9f e5 00 f0 9f e5 04 f0 1f e5 |................| +00000820 00 01 00 00 78 56 34 12 78 56 34 12 78 56 34 12 |....xV4.xV4.xV4.| +[...] +* +00001fe0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................| +00001ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| +* +00003800 14 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +00003810 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +00003820 80 01 08 81 e0 01 08 81 40 02 08 81 a0 02 08 81 |........@.......| + +In the first "page" of the image, we have the UBL Header, needed for +the RBL to find the spl code. + +The spl code starts in the second "page" of the image, with a size +defined by: + +#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6 + +After the spl code, there comes the "real" u-boot code +@ (6 + 1) * pagesize = 0x3800 + +------------------------------------------------------------------------ +Setting up spl code: + +/* + * RBL searches from Block n (n = 1..24) + * so we can define, how many UBL Headers + * we write before the real spl code + */ +#define CONFIG_SYS_NROF_UBL_HEADER 5 +#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6 + +#define CONFIG_SYS_NAND_U_BOOT_OFFS ((CONFIG_SYS_NROF_UBL_HEADER * \ + CONFIG_SYS_NAND_BLOCK_SIZE) + \ + (CONFIG_SYS_NROF_PAGES_NAND_SPL) * \ + CONFIG_SYS_NAND_PAGE_SIZE) +------------------------------------------------------------------------ + +Burning into NAND: + +step 1: +The RBL searches from Block n ( n = 1..24) on page 0 for valid UBL +Headers, so you have to burn the UBL header page from the u-boot.ubl +image to the blocks, you want to have the UBL header. +!! Don;t forget to switch to rbl nand read/write functions with + "nandrbl rbl" + +step 2: +You need to setup in the ublimage.cfg, where the RBL can find the spl +code, and how big it is. + +!! RBL always starts reading from page 0 !! + +For the AIT board, we have: +PAGES 6 +START_BLOCK 5 + +So we need to copy the spl code to block 5 page 0 +!! Don;t forget to switch to rbl nand read/write functions with + "nandrbl rbl" + +step 3: +You need to copy the u-boot image to the block/page +where the spl code reads it (CONFIG_SYS_NAND_U_BOOT_OFFS) +!! Don;t forget to switch to rbl nand read/write functions with + "nandrbl uboot", which is default. + +On the cam_enc_4xx board it is: +#define CONFIG_SYS_NAND_U_BOOT_OFFS (0xc0000) + +-> this results in following NAND usage on the cam_enc_4xx board: + +addr + +20000 possible UBL Header +40000 possible UBL Header +60000 possible UBL Header +80000 possilbe UBL Header +a0000 spl code +c0000 u-boot code + +The above steps are executeed through the following environment vars: +(using 80000 as address for the UBL header) + +pagesz=800 +uboot=/tftpboot/cam_enc_4xx/u-boot.ubl +load=tftp 80000000 ${uboot} +writeheader nandrbl rbl;nand erase 80000 ${pagesz};nand write 80000000 80000 ${pagesz};nandrbl uboot +writenand_spl nandrbl rbl;nand erase a0000 3000;nand write 80000800 a0000 3000;nandrbl uboot +writeuboot nandrbl uboot;nand erase c0000 5d000;nand write 80003800 c0000 5d000 +update=run load writeheader writenand_spl writeuboot + +If you do a "run load update" u-boot, spl + ubl header +are magically updated ;-) + +Note: +- There seem to be a bug in the RBL code (at least on my HW), + In the UBL block, I can set the page to values != 0, so it + is possible to burn step 1 and step 2 in one step into the + flash, but the RBL ignores the page settings, so I have to + burn the UBL Header to a page 0 and the spl code to + a page 0 ... :-( +- If we make the nand read/write functions in the RBL equal to + the functions in u-boot (as I have no RBL code, it is only + possible in u-boot), we could burn the complete image in + one step ... that would be nice ... diff --git a/qemu/roms/u-boot/doc/README.displaying-bmps b/qemu/roms/u-boot/doc/README.displaying-bmps new file mode 100644 index 000000000..331154166 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.displaying-bmps @@ -0,0 +1,27 @@ +If you are experiencing hangups/data-aborts when trying to display a BMP image, +the following might be relevant to your situation... + +Some architectures cannot handle unaligned memory accesses, and an attempt to +perform one will lead to a data abort. On such architectures it is necessary to +make sure all data is properly aligned, and in many situations simply choosing +a 32 bit aligned address is enough to ensure proper alignment. This is not +always the case when dealing with data that has an internal layout such as a +BMP image: + +BMP images have a header that starts with 2 byte-size fields followed by mostly +32 bit fields. The packed struct that represents this header can be seen below: + +typedef struct bmp_header { + /* Header */ + char signature[2]; + __u32 file_size; + __u32 reserved; + __u32 data_offset; + ... etc +} __attribute__ ((packed)) bmp_header_t; + +When placed in an aligned address such as 0x80a00000, char signature offsets +the __u32 fields into unaligned addresses (in our example 0x80a00002, +0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit +access is generated at a non-32-bit-aligned address, causing a data abort. +The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2. diff --git a/qemu/roms/u-boot/doc/README.dns b/qemu/roms/u-boot/doc/README.dns new file mode 100644 index 000000000..8dff454b1 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.dns @@ -0,0 +1,62 @@ +Domain Name System +------------------------------------------- + +The Domain Name System (DNS) is a hierarchical naming system for computers, +services, or any resource participating in the Internet. It associates various +information with domain names assigned to each of the participants. Most +importantly, it translates domain names meaningful to humans into the numerical +(binary) identifiers associated with networking equipment for the purpose of +locating and addressing these devices world-wide. An often used analogy to +explain the Domain Name System is that it serves as the "phone book" for the +Internet by translating human-friendly computer hostnames into IP addresses. +For example, www.example.com translates to 208.77.188.166. + +For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System + +U-Boot and DNS +------------------------------------------ + +CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it + will send name lookups to the dns server (env var 'dnsip') + Turning this option on will about abou 1k to U-Boot's size. + + Example: + +bfin> print dnsip +dnsip=192.168.0.1 + +bfin> dns www.google.com +66.102.1.104 + + By default, dns does nothing except print the IP number on + the default console - which by itself, would be pretty + useless. Adding a third argument to the dns command will + use that as the environment variable to be set. + + Example: + +bfin> print googleip +## Error: "googleip" not defined +bfin> dns www.google.com googleip +64.233.161.104 +bfin> print googleip +googleip=64.233.161.104 +bfin> ping ${googleip} +Using Blackfin EMAC device +host 64.233.161.104 is alive + + In this way, you can lookup, and set many more meaningful + things. + +bfin> sntp +ntpserverip not set +bfin> dns pool.ntp.org ntpserverip +72.18.205.156 +bfin> sntp +Date: 2009-07-18 Time: 4:06:57 + + For some helpful things that can be related to DNS in U-Boot, + look at the top level README for these config options: + CONFIG_CMD_DHCP + CONFIG_BOOTP_DNS + CONFIG_BOOTP_DNS2 diff --git a/qemu/roms/u-boot/doc/README.drivers.eth b/qemu/roms/u-boot/doc/README.drivers.eth new file mode 100644 index 000000000..eb83038b5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.drivers.eth @@ -0,0 +1,190 @@ +----------------------- + 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 new file mode 100644 index 000000000..1eaeaf941 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.enetaddr @@ -0,0 +1,116 @@ +--------------------------------- + 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 new file mode 100644 index 000000000..9a2de5088 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ext4 @@ -0,0 +1,59 @@ +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 new file mode 100644 index 000000000..82a254b2e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.falcon @@ -0,0 +1,224 @@ +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 new file mode 100644 index 000000000..86bae6816 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fdt-control @@ -0,0 +1,186 @@ +# +# 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 new file mode 100644 index 000000000..72a1d595f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fec_mxc @@ -0,0 +1,27 @@ +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 new file mode 100644 index 000000000..1243a1222 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fsl-ddr @@ -0,0 +1,430 @@ +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 new file mode 100644 index 000000000..e752505da --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fsl-hwconfig @@ -0,0 +1,46 @@ +Freescale-specific 'hwconfig' options. + +This file documents Freescale-specific key:value pairs for the 'hwconfig' +option. See README.hwconfig for general information about 'hwconfig'. + +audclk + Specific to the P1022DS reference board. + + This option specifies which of the two oscillator frequencies should be + routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to + route either a 11.2896MHz or a 12.288MHz clock. The default is + 12.288MHz. This option has two effects. First, the MUX on the board + will be programmed accordingly. Second, the clock-frequency property + in the codec node in the device tree will be updated to the correct + value. + + 'audclk:11' + Select the 11.2896MHz clock + + 'audclk:12' + Select the 12.288MHz clock + +usb + Specific to boards have USB controller + + This option specifies the following for a USB controller: + + - which controller mode to use + - which USB PHY to use + + This is used by generic USB device-tree fixup function to update + modified values of phy type and controller mode. + + Also used for configuring multiple USB controllers such that + 'usbN' (where N is 1, 2, etc. refers to controller no.) + + 'phy_type' + Select USB phy type: 'utmi' OR 'ulpi' + + 'dr_mode' + Select USB controller mode: 'host', 'peripheral' OR 'otg' + + Examples: + usb1:dr_mode=host;usb2:dr_mode=peripheral' + + usb1:dr_mode=host,phy_type=utmi;usb2:dr_mode=host' diff --git a/qemu/roms/u-boot/doc/README.fsl_iim b/qemu/roms/u-boot/doc/README.fsl_iim new file mode 100644 index 000000000..e087f5e0e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fsl_iim @@ -0,0 +1,48 @@ +Driver implementing the fuse API for Freescale's IC Identification Module (IIM) + +This IP can be found on the following SoCs: + - MPC512x, + - i.MX25, + - i.MX27, + - i.MX31, + - i.MX35, + - i.MX51, + - i.MX53. + +The section numbers in this file refer to the i.MX25 Reference Manual. + +A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1. + +A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1. + +Some fuse bit or word slots may not have the corresponding fuses actually +implemented in the fusebox. + +See the README files of the SoCs using this driver in order to know the +conventions used by U-Boot to store some specific data in the fuses, e.g. MAC +addresses. + +Fuse operations: + + Read + Read operations are implemented as read accesses to the shadow registers, + using "Word y of Bank x" from the register summary in 30.3.2. This is + explained in detail in 30.4.5.1. + + Sense + Sense operations are implemented as explained in 30.4.5.2. + + Program + Program operations are implemented as explained in 30.4.5.3. Following + this operation, the shadow registers are reloaded by the hardware (not + immediately, but this does not make any difference for a user reading + these registers). + + Override + Override operations are implemented as write accesses to the shadow + registers, as explained in 30.4.5.4. + +Configuration: + + CONFIG_FSL_IIM + Define this to enable the fsl_iim driver. diff --git a/qemu/roms/u-boot/doc/README.fuse b/qemu/roms/u-boot/doc/README.fuse new file mode 100644 index 000000000..1bc91c44a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.fuse @@ -0,0 +1,67 @@ +Fuse API functions and commands + +The fuse API allows to control a fusebox and how it is used by the upper +hardware layers. + +A fuse corresponds to a single non-volatile memory bit that can be programmed +(i.e. blown, set to 1) only once. The programming operation is irreversible. A +fuse that has not been programmed reads 0. + +Fuses can be used by SoCs to store various permanent configuration and data, +e.g. boot configuration, security configuration, MAC addresses, etc. + +A fuse word is the smallest group of fuses that can be read at once from the +fusebox control IP registers. This is limited to 32 bits with the current API. + +A fuse bank is the smallest group of fuse words having a common ID, as defined +by each SoC. + +Upon startup, the fusebox control IP reads the fuse values and stores them to a +volatile shadow cache. + +See the README files of the drivers implementing this API in order to know the +SoC- and implementation-specific details. + +Functions / commands: + + int fuse_read(u32 bank, u32 word, u32 *val); + fuse read <bank> <word> [<cnt>] + Read fuse words from the shadow cache. + + int fuse_sense(u32 bank, u32 word, u32 *val); + fuse sense <bank> <word> [<cnt>] + Sense - i.e. read directly from the fusebox, skipping the shadow cache - + fuse words. This operation does not update the shadow cache. + + This is useful to know the true value of fuses if an override has been + performed (see below). + + int fuse_prog(u32 bank, u32 word, u32 val); + fuse prog [-y] <bank> <word> <hexval> [<hexval>...] + Program fuse words. This operation directly affects the fusebox and is + irreversible. The shadow cache is updated accordingly or not, depending on + each IP. + + Only the bits to be programmed should be set in the input value (i.e. for + fuse bits that have already been programmed and hence should be left + unchanged by a further programming, it is preferable to clear the + corresponding bits in the input value in order not to perform a new + hardware programming operation on these fuse bits). + + int fuse_override(u32 bank, u32 word, u32 val); + fuse override <bank> <word> <hexval> [<hexval>...] + Override fuse words in the shadow cache. + + The fusebox is unaffected, so following this operation, the shadow cache + may differ from the fusebox values. Read or sense operations can then be + used to get the values from the shadow cache or from the fusebox. + + This is useful to change the behaviors linked to some cached fuse values, + either because this is needed only temporarily, or because some of the + fuses have already been programmed or are locked (if the SoC allows to + override a locked fuse). + +Configuration: + + CONFIG_CMD_FUSE + Define this to enable the fuse commands. diff --git a/qemu/roms/u-boot/doc/README.generic-board b/qemu/roms/u-boot/doc/README.generic-board new file mode 100644 index 000000000..17da0b9f8 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.generic-board @@ -0,0 +1,189 @@ +# +# (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 new file mode 100644 index 000000000..ba7cea83c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.generic_usb_ohci @@ -0,0 +1,63 @@ +Notes on the the generic USB-OHCI driver +======================================== + +This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of +various existing OHCI drivers that were basically identical beside +cpu/board dependant initalization. This initalization has been moved +into cpu/board directories and are called via the hooks below. + +Configuration options +---------------------- + + CONFIG_USB_OHCI_NEW: enable the new OHCI driver + + CONFIG_SYS_USB_OHCI_BOARD_INIT: call the board dependant hooks: + + - extern int 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 new file mode 100644 index 000000000..ec0156d8a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.gpt @@ -0,0 +1,190 @@ +# +# 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 new file mode 100644 index 000000000..b6ddb438c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.hwconfig @@ -0,0 +1,50 @@ +To enable this feature just define CONFIG_HWCONFIG in your board +config file. + +This implements a simple hwconfig infrastructure: an +interface for software knobs to control hardware. + +This a is very simple implementation, i.e. it is implemented +via the `hwconfig' environment variable. Later we could write +some "hwconfig <enable|disable|list>" commands, ncurses +interface for Award BIOS-like interface, and frame-buffer +interface for AMI GUI[1] BIOS-like interface with mouse +support[2]. + +Current implementation details/limitations: + +1. Doesn't support options dependencies and mutual exclusion. + We can implement this by integrating apt-get[3] into Das + U-Boot. But I haven't bothered yet. + +2. Since we don't implement a hwconfig command, i.e. we're working + with the environment directly, there is no way to tell that + toggling a particular option will need a reboot to take + effect. So, for now it's advised to always reboot the + target after modifying the hwconfig variable. + +3. We support hwconfig options with arguments. For example, + + set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi" + + This selects three hwconfig options: + 1. dr_usb - enable Dual-Role USB controller; + 2. dr_usb_mode:peripheral - USB in Function mode; + 3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs. + +The purpose of this simple implementation is to refine the +internal API and then we can continue improving the user +experience by adding more mature interfaces, like a hwconfig +command with bells and whistles. Or not adding, if we feel +that the current interface fits people's needs. + +[1] http://en.wikipedia.org/wiki/American_Megatrends +[2] Regarding ncurses and GUI with mouse support -- I'm just + kidding. +[3] The comment regarding apt-get is also a joke, meaning that + dependency tracking could be non-trivial. For example, for + enabling HW feature X we may need to disable Y, and turn Z + into reduced mode (like RMII-only interface for ethernet, + no MII). + + It's quite trivial to implement simple cases though. diff --git a/qemu/roms/u-boot/doc/README.idma2intr b/qemu/roms/u-boot/doc/README.idma2intr new file mode 100644 index 000000000..1828b5130 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.idma2intr @@ -0,0 +1,10 @@ +(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 new file mode 100644 index 000000000..0ca21b6df --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imx25 @@ -0,0 +1,10 @@ +U-Boot for Freescale i.MX25 + +This file contains information for the port of U-Boot to the Freescale i.MX25 +SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in the words 26 to 31 of fuse bank 0, using the + natural MAC byte order (i.e. MSB first). diff --git a/qemu/roms/u-boot/doc/README.imx27 b/qemu/roms/u-boot/doc/README.imx27 new file mode 100644 index 000000000..6f92cb47c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imx27 @@ -0,0 +1,10 @@ +U-Boot for Freescale i.MX27 + +This file contains information for the port of U-Boot to the Freescale i.MX27 +SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in the words 4 to 9 of fuse bank 0, using the + reversed MAC byte order (i.e. LSB first). diff --git a/qemu/roms/u-boot/doc/README.imx31 b/qemu/roms/u-boot/doc/README.imx31 new file mode 100644 index 000000000..91ef76688 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imx31 @@ -0,0 +1,29 @@ +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 new file mode 100644 index 000000000..c5312b69d --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imx5 @@ -0,0 +1,28 @@ +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 new file mode 100644 index 000000000..437af2fd9 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imx6 @@ -0,0 +1,86 @@ +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 new file mode 100644 index 000000000..dcda2005a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.imximage @@ -0,0 +1,239 @@ +--------------------------------------------- +Imximage Boot Image generation using mkimage +--------------------------------------------- + +This document describes how to set up a U-Boot image that can be booted +by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot +mode. + +These processors can boot directly from NAND, SPI flash and SD card flash +using its internal boot ROM support. MX6 processors additionally support +boot from NOR flash and SATA disks. All processors can boot from an internal +UART, if booting from device media fails. +Booting from NOR flash does not require to use this image type. + +For more details refer Chapter 2 - System Boot and section 2.14 +(flash header description) of the processor's manual. + +Command syntax: +-------------- +./tools/mkimage -l <mx u-boot_file> + to list the imx image file details + +./tools/mkimage -T imximage \ + -n <board specific configuration file> \ + -e <execution address> -d <u-boot binary> <output image file> + +For example, for the mx51evk board: +./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \ + -T imximage -e 0x97800000 \ + -d u-boot.bin u-boot.imx + +You can generate directly the image when you compile u-boot with: + +$ make u-boot.imx + +The output image can be flashed on the board SPI flash or on a SD card. +In both cases, you have to copy the image at the offset required for the +chosen media devices (0x400 for both SPI flash or SD card). + +Please check Freescale documentation for further details. + +Board specific configuration file specifications: +------------------------------------------------- +1. This file must present in the $(BOARDDIR) and the name should be + imximage.cfg (since this is used in Makefile). +2. This file can have empty lines and lines starting with "#" as first + character to put comments. +3. This file can have configuration command lines as mentioned below, + any other information in this file is treated as invalid. + +Configuration command line syntax: +--------------------------------- +1. Each command line is must have two strings, first one command or address + and second one data string +2. Following are the valid command strings and associated data strings:- + Command string data string + -------------- ----------- + IMXIMAGE_VERSION 1/2 + 1 is for mx25/mx35/mx51 compatible, + 2 is for mx53/mx6 compatible, + others is invalid and error is generated. + This command need appear the fist before + other valid commands in configuration file. + + BOOT_OFFSET value + + This command is parallel to BOOT_FROM and + is preferred over BOOT_FROM. + + value: Offset of the image header, this + value shall be set to one of the + values found in the file: + arch/arm/include/asm/\ + 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 new file mode 100644 index 000000000..044240db3 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.iomux @@ -0,0 +1,90 @@ +/* + * (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 new file mode 100644 index 000000000..13f6f92f6 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.kwbimage @@ -0,0 +1,104 @@ +--------------------------------------------- +Kirkwood Boot Image generation using mkimage +--------------------------------------------- + +This document describes the U-Boot feature as it +is implemented for the Kirkwood family of SoCs. + +The Kirkwood SoC's can boot directly from NAND FLASH, +SPI FLASH, SATA etc. using its internal bootRom support. + +for more details refer section 24.2 of Kirkwood functional specifications. +ref: www.marvell.com/products/embedded.../kirkwood/index.jsp + +Command syntax: +-------------- +./tools/mkimage -l <kwboot_file> + to list the kwb image file details + +./tools/mkimage -n <board specific configuration file> \ + -T kwbimage -a <start address> -e <execution address> \ + -d <input_raw_binary> <output_kwboot_file> + +for ex. +./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \ + -T kwbimage -a 0x00600000 -e 0x00600000 \ + -d u-boot.bin u-boot.kwb + + +kwbimage support available with mkimage utility will generate kirkwood boot +image that can be flashed on the board NAND/SPI flash. The make target +which uses mkimage to produce such an image is "u-boot.kwb". For example: + + export 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 new file mode 100644 index 000000000..9586eca26 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.link-local @@ -0,0 +1,75 @@ +------------------------------------------ + Link-local IP address auto-configuration +------------------------------------------ + +Negotiate with other link-local clients on the local network +for an address that doesn't require explicit configuration. +This is especially useful if a DHCP server cannot be guaranteed +to exist in all environments that the device must operate. + +This is an implementation of RFC3927. + +---------- + Commands +---------- + +When CONFIG_CMD_LINK_LOCAL is defined in the board config file, +the "linklocal" command is available. This running this will +take approximately 5 seconds while the address is negotiated. + +------------------------ + Environment interation +------------------------ + +The "llipaddr" variable is set with the most recently +negotiated address and is preferred in future negotiations. + +The "ipaddr", "netmask", and "gatewayip" variables are set +after successful negotiation to enable network access. + +------------- + Limitations +------------- + +RFC3927 requires that addresses are continuously checked to +avoid conflicts, however this can only happen when the 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 new file mode 100644 index 000000000..076f01862 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.lynxkdi @@ -0,0 +1,57 @@ + LYNX KDI SUPPORT + + Last Update: July 20, 2003 +======================================================================= + +This file describes support for LynuxWorks KDI within U-Boot. Support +is enabled by defining CONFIG_LYNXKDI. + + +LYNXOS AND BLUECAT SUPPORTED +============================ +Both LynxOS and BlueCat linux KDIs are supported. The implementation +automatically detects which is being booted. When you use mkimage +you should specify "lynxos" for both (see target-specific notes). + + +SUPPORTED ARCHITECTURE/TARGETS +============================== +The following targets have been tested: + +-PowerPC MPC8260ADS + + +FILES TO LOOK AT +================ +include/lynxkdi.h -defines a simple struct passed to a kdi. +common/lynxkdi.c -implements the call to the kdi. +common/cmd_bootm.c -top-level command implementation ("bootm"). + + +==================================================================== +TARGET SPECIFIC NOTES +==================================================================== + +MPC8260ADS +=========== +The default LynxOS and BlueCat implementations require some +modifications to the config file. + +Edit include/configs/MPC8260ADS.h to use the following: + +#define CONFIG_SYS_IMMR 0xFA200000 +#define CONFIG_SYS_BCSR 0xFA100000 +#define CONFIG_SYS_BR1_PRELIM 0xFA101801 + +When creating a LynxOS or BlueCat u-boot image using mkimage, +you must specify the following: + +Both: -A ppc -O lynxos -T kernel -C none +LynxOS: -a 0x00004000 -e 0x00004020 +BlueCat: -a 0x00500000 -e 0x00507000 + +To pass the MAC address to BlueCat you should define the +"fcc2_ether_addr" parameter in the "bootargs" environment +variable. E.g.: + +==> setenv bootargs fcc2_ether_addr=00:11:22:33:44:55:66 diff --git a/qemu/roms/u-boot/doc/README.m54418twr b/qemu/roms/u-boot/doc/README.m54418twr new file mode 100644 index 000000000..f69ae0191 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.m54418twr @@ -0,0 +1,244 @@ +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 new file mode 100644 index 000000000..c85febc1f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.m68k @@ -0,0 +1,166 @@ + +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 new file mode 100644 index 000000000..c8db8a0c3 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.malta @@ -0,0 +1,16 @@ +MIPS Malta board + +How to flash using a MIPS Navigator Probe: + + - Ensure that your Malta has jumper JP1 fitted. Without this jumper you will + be unable to flash your Malta using a Navigator Probe. + + - Connect Navigator Console to your probe and Malta as usual. + + - Within Navigator Console run the following commands: + + source /path/to/u-boot/board/imgtec/malta/flash-malta-boot.tcl + reset + flash-boot /path/to/u-boot/u-boot.bin + + - You should now be able to reboot your Malta to a U-boot shell. diff --git a/qemu/roms/u-boot/doc/README.marubun-pcmcia b/qemu/roms/u-boot/doc/README.marubun-pcmcia new file mode 100644 index 000000000..d3563a3cd --- /dev/null +++ b/qemu/roms/u-boot/doc/README.marubun-pcmcia @@ -0,0 +1,65 @@ + +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 new file mode 100644 index 000000000..eb60e8d83 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.memory-test @@ -0,0 +1,98 @@ +The most frequent cause of problems when porting U-Boot to new +hardware, or when using a sloppy port on some board, is memory errors. +In most cases these are not caused by failing hardware, but by +incorrect initialization of the memory controller. So it appears to +be a good idea to always test if the memory is working correctly, +before looking for any other potential causes of any problems. + +U-Boot implements 3 different approaches to perform memory tests: + +1. The get_ram_size() function (see "common/memsize.c"). + + This function is supposed to be used in each and every U-Boot port + determine the presence and actual size of each of the potential + memory banks on this piece of hardware. The code is supposed to be + very fast, so running it for each reboot does not hurt. It is a + little known and generally underrated fact that this code will also + catch 99% of hardware related (i. e. reliably reproducible) memory + errors. It is strongly recommended to always use this function, in + each and every port of U-Boot. + +2. The "mtest" command. + + This is probably the best known memory test utility in U-Boot. + Unfortunately, it is also the most problematic, and the most + useless one. + + There are a number of serious problems with this command: + + - It is terribly slow. Running "mtest" on the whole system RAM + takes a _long_ time before there is any significance in the fact + that no errors have been found so far. + + - It is difficult to configure, and to use. And any errors here + will reliably crash or hang your system. "mtest" is dumb and has + no knowledge about memory ranges that may be in use for other + purposes, like exception code, U-Boot code and data, stack, + malloc arena, video buffer, log buffer, etc. If you let it, it + will happily "test" all such areas, which of course will cause + some problems. + + - It is not easy to configure and use, and a large number of + systems are seriously misconfigured. The original idea was to + test basically the whole system RAM, with only exempting the + areas used by U-Boot itself - on most systems these are the areas + used for the exception vectors (usually at the very lower end of + system memory) and for U-Boot (code, data, etc. - see above; + these are usually at the very upper end of system memory). But + experience has shown that a very large number of ports use + pretty much bogus settings of CONFIG_SYS_MEMTEST_START and + CONFIG_SYS_MEMTEST_END; this results in useless tests (because + the ranges is too small and/or badly located) or in critical + failures (system crashes). + + Because of these issues, the "mtest" command is considered depre- + cated. It should not be enabled in most normal ports of U-Boot, + especially not in production. If you really need a memory test, + then see 1. and 3. above resp. below. + +3. The most thorough memory test facility is available as part of the + POST (Power-On Self Test) sub-system, see "post/drivers/memory.c". + + If you really need to perform memory tests (for example, because + it is mandatory part of your requirement specification), then + enable this test which is generic and should work on all archi- + tectures. + +WARNING: + +It should pointed out that _all_ these memory tests have one +fundamental, unfixable design flaw: they are based on the assumption +that memory errors can be found by writing to and reading from memory. +Unfortunately, this is only true for the relatively harmless, usually +static errors like shorts between data or address lines, unconnected +pins, etc. All the really nasty errors which will first turn your +hair gray, only to make you tear it out later, are dynamical errors, +which usually happen not with simple read or write cycles on the bus, +but when performing back-to-back data transfers in burst mode. Such +accesses usually happen only for certain DMA operations, or for heavy +cache use (instruction fetching, cache flushing). So far I am not +aware of any freely available code that implements a generic, and +efficient, memory test like that. The best known test case to stress +a system like that is to boot Linux with root file system mounted over +NFS, and then build some larger software package natively (say, +compile a Linux kernel on the system) - this will cause enough context +switches, network traffic (and thus DMA transfers from the network +controller), varying RAM use, etc. to trigger any weak spots in this +area. + +Note: An attempt was made once to implement such a test to catch +memory problems on a specific board. The code is pretty much board +specific (for example, it includes setting specific GPIO signals to +provide triggers for an attached logic analyzer), but you can get an +idea how it works: see "examples/standalone/test_burst*". + +Note 2: Ironically enough, the "test_burst" did not catch any RAM +errors, not a single one ever. The problems this code was supposed +to catch did not happen when accessing the RAM, but when reading from +NOR flash. diff --git a/qemu/roms/u-boot/doc/README.menu b/qemu/roms/u-boot/doc/README.menu new file mode 100644 index 000000000..ad520ab3a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.menu @@ -0,0 +1,125 @@ +/* + * 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 new file mode 100644 index 000000000..b28f6285c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mips @@ -0,0 +1,54 @@ + +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 new file mode 100644 index 000000000..df51b5cf5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc5xx @@ -0,0 +1,48 @@ + +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 new file mode 100644 index 000000000..f81f1c2e8 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc74xx @@ -0,0 +1,22 @@ +This file contains status information for the port of U-Boot to the +Motorola mpc74xx series of CPUs. + +Author: Josh Huber <huber@mclx.com> + Mission Critical Linux, Inc. + +Currently the support for these CPUs is pretty minimal, but enough to +get things going. (much like the support for the Galileo Eval Board) + +There is a framework in place to enable the L2 cache, and to program +the BATs. Currently, there are still problems with the code which +sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be +anyway). Additionally, there is support for enabling the MMU, which +we also don't do. The BATs are programmed just for the benefit of +jumping into Linux in a sane configuration. + +Most of the code was based on other cpus supported by U-Boot. + +If you find any errors in the CPU setup code, please send us a note. + +Thanks, +Josh diff --git a/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc b/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc new file mode 100644 index 000000000..0029f0875 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc83xx.ddrecc @@ -0,0 +1,154 @@ +Overview +======== + +The overall usage pattern for ECC diagnostic commands is the following: + + * (injecting errors is initially disabled) + + * define inject mask (which tells the DDR controller what type of errors + we'll be injecting: single/multiple bit etc.) + + * enable injecting errors - from now on the controller injects errors as + indicated in the inject mask + +IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially +dangerous as such errors are NOT corrected by the controller. Therefore caution +should be taken when enabling the injection of multiple-bit errors: it is only +safe when used on a carefully selected memory area and used under control of +the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit +Errors' below). In particular, when you simply set the multiple-bit errors in +inject mask and enable injection, U-Boot is very likely to hang quickly as the +errors will be injected when it accesses its code, data etc. + + +Use cases for DDR 'ecc' command: +================================ + +Before executing particular tests reset target board or clear status registers: + +=> ecc captureclear +=> ecc errdetectclr all +=> ecc sbecnt 0 + + +Injecting Single-Bit Errors +--------------------------- + +1. Set 1 bit in Data Path Error Inject Mask + +=> ecc injectdatahi 1 + +2. Run test over some memory region + +=> ecc testdw 200000 10 + +3. Check ECC status + +=> ecc status +... +Memory Data Path Error Injection Mask High/Low: 00000001 00000000 +... +Memory Single-Bit Error Management (0..255): + Single-Bit Error Threshold: 255 + Single Bit Error Counter: 16 +... +Memory Error Detect: + Multiple Memory Errors: 0 + Multiple-Bit Error: 0 + Single-Bit Error: 0 +... + +16 errors were generated, Single-Bit Error flag was not set as Single Bit Error +Counter did not reach Single-Bit Error Threshold. + +4. Make sure used memory region got re-initialized with 0x0123456789abcdef + +=> md 200000 +00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200080: deadbeef deadbeef deadbeef deadbeef ................ +00200090: deadbeef deadbeef deadbeef deadbeef ................ + +Injecting Multiple-Bit Errors +----------------------------- + +1. Set more than 1 bit in Data Path Error Inject Mask + +=> ecc injectdatahi 1 +=> ecc injectdatalo 1 + +2. Run test over some memory region + +=> ecc testword 200000 1 + +3. Check ECC status + +=> ecc status +... +Memory Data Path Error Injection Mask High/Low: 00000001 00000001 +... +Memory Error Detect: + Multiple Memory Errors: 0 + Multiple-Bit Error: 1 + Single-Bit Error: 0 +... + +The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set. + +4. Make sure used memory region got re-initialized with 0x0123456789abcdef + +=> md 200000 +00200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg.... +00200080: deadbeef deadbeef deadbeef deadbeef ................ +00200090: deadbeef deadbeef deadbeef deadbeef ................ + + +Test Single-Bit Error Counter and Threshold +------------------------------------------- + +1. Set 1 bit in Data Path Error Inject Mask + +=> ecc injectdatahi 1 + +2. Enable error injection + +=> ecc inject en + +3. Let u-boot run for a with Single-Bit error injection enabled + +4. Disable error injection + +=> ecc inject dis + +4. Check status + +=> ecc status + +... +Memory Single-Bit Error Management (0..255): + Single-Bit Error Threshold: 255 + Single Bit Error Counter: 199 + +Memory Error Detect: + Multiple Memory Errors: 1 + Multiple-Bit Error: 0 + Single-Bit Error: 1 +... + +Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter +reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that +is Counter reached Threshold more than one time (it wraps back after reaching +Threshold). diff --git a/qemu/roms/u-boot/doc/README.mpc83xxads b/qemu/roms/u-boot/doc/README.mpc83xxads new file mode 100644 index 000000000..d4561034b --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc83xxads @@ -0,0 +1,98 @@ +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 new file mode 100644 index 000000000..f9b023f28 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc85xx @@ -0,0 +1,166 @@ +External Debug Support +---------------------- + +Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some +restrictions on external debugging (JTAG). In particular, for the debugger to +be able to receive control after a single step or breakpoint: + - MSR[DE] must be set + - A valid opcode must be fetchable, through the MMU, from the debug + exception vector (IVPR + IVOR15). + +To maximize the time during which this requirement is met, U-Boot sets MSR[DE] +immediately on entry and keeps it set. It also uses a temporary TLB to keep a +mapping to a valid opcode at the debug exception vector, even if we normally +don't support exception vectors being used that early, and that's not the area +where U-Boot currently executes from. + +Note that there may still be some small windows where debugging will not work, +such as in between updating IVPR and IVOR15. + +Config Switches: +---------------- + +Please refer README section "MPC85xx External Debug Support" + +Major Config Switches during various boot Modes +---------------------------------------------- + +NOR boot + !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SPL) +NOR boot Secure + !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_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 new file mode 100644 index 000000000..d5043ccb6 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc85xx-sd-spi-boot @@ -0,0 +1,81 @@ +---------------------------------------- +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 new file mode 100644 index 000000000..8da768a2a --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc85xx-spin-table @@ -0,0 +1,26 @@ +Spin table in cache +===================================== +As specified by ePAPR v1.1, the spin table needs to be in cached memory. After +DDR is initialized and U-boot relocates itself into DDR, the spin table is +accessible for core 0. It is part of release.S, within 4KB range after +__secondary_start_page. For other cores to use the spin table, the booting +process is described below: + +Core 0 sets up the reset page on the top 4K of memory (or 4GB if total memory +is more than 4GB), and creates a TLB to map it to 0xffff_f000, regardless of +the physical address of this page, with WIMGE=0b01010. Core 0 also enables boot +page translation for secondary cores to use this page of memory. Then 4KB +memory is copied from __secondary_start_page to the boot page, after flusing +cache because this page is mapped as normal DDR. Before copying the reset page, +core 0 puts the physical address of the spin table (which is in release.S and +relocated to the top of mapped memory) into a variable __spin_table_addr so +that secondary cores can see it. + +When secondary cores boot up from 0xffff_f000 page, they only have one default +TLB. While booting, they set up another TLB in AS=1 space and jump into +the new space. The new TLB covers the physical address of the spin table page, +with WIMGE =0b00100. Now secondary cores can keep polling the spin table +without stress DDR bus because both the code and the spin table is in cache. + +For the above to work, DDR has to set the 'M' bit of WIMGE, in order to keep +cache coherence. diff --git a/qemu/roms/u-boot/doc/README.mpc85xxads b/qemu/roms/u-boot/doc/README.mpc85xxads new file mode 100644 index 000000000..28bbcbe09 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc85xxads @@ -0,0 +1,303 @@ +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 new file mode 100644 index 000000000..bc5db0ca8 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mpc85xxcds @@ -0,0 +1,225 @@ +Motorola MPC85xxCDS boards +-------------------------- + +The CDS family of boards consists of a PCI backplane called the +"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot, +and a CPU daughter card that bolts onto the daughter card. + +Much of the content of the README.mpc85xxads for the 85xx ADS boards +applies to the 85xx CDS boards as well. In particular the toolchain, +the switch nomenclature, and the basis for the memory map. There are +some differences, though. + + +Building U-Boot +--------------- + +The Binutils in current ELDK toolchain will not support MPC85xx +chip. You need to use binutils-2.14.tar.bz2 (or newer) from + http://ftp.gnu.org/gnu/binutils. + +The 85xx CDS code base is known to compile using: + gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a) + + +Memory Map +---------- + +The memory map for u-boot and linux has been extended w.r.t. the ADS +platform to allow for utilization of all 85xx CDS devices. The memory +map is setup for linux to operate properly. The linux source when +configured for MPC85xx CDS has been updated to reflect the new memory +map. + +The mapping is: + + 0x0000_0000 0x7fff_ffff DDR 2G + 0x8000_0000 0x9fff_ffff PCI1 MEM 512M + 0xa000_0000 0xbfff_ffff PCI2 MEM 512M + 0xe000_0000 0xe00f_ffff CCSR 1M + 0xe200_0000 0xe2ff_ffff PCI1 IO 16M + 0xe300_0000 0xe3ff_ffff PCI2 IO 16M + 0xf000_0000 0xf7ff_ffff SDRAM 128M + 0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M + 0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M + 0xff80_0000 0xffff_ffff FLASH (boot bank) 8M + + (*) The system control registers (CADMUS) start at offset 0xfdb0_4000 + within the NVRAM/CADMUS region of memory. + + +Using Flash +----------- + +The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000). +There is a switch which allows the boot-bank to be selected. The switch +settings for updating flash are given below. + +The u-boot commands for copying the boot-bank into the secondary bank are +as follows: + + erase ff780000 ff7fffff + cp.b fff80000 ff780000 80000 + + +U-boot/kermit commands for downloading an image, then copying +it into the secondary bank: + + loadb + [Drop to kermit: + ^\c + send <u-boot-bin-image> + c + ] + + erase ff780000 ff7fffff + cp.b $loadaddr ff780000 80000 + + +U-boot commands for downloading an image via tftp and flashing +it into the second bank: + + tftp 10000 <u-boot.bin.image> + erase ff780000 ff7fffff + cp.b 10000 ff780000 80000 + + +After copying the image into the second bank of flash, be sure to toggle +SW2[2] on the carrier card before resetting the board in order to set the +secondary bank as the boot-bank. + + +Carrier Board Switches +---------------------- + +As a reminder, you should read the README.mpc85xxads too. + +Most switches on the carrier board should not be changed. The only +user-settable switches on the carrier board are used to configure +the flash banks and determining the PCI slot. + +The first two bits of SW2 control how flash is used on the board: + + 12345678 + -------- + SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available. + 01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped). + 10XXXXXX FLASH: Boot promjet, bank 1 available + 11XXXXXX FLASH: Boot promjet, bank 2 available + +The boot bank is always mapped to FF80_0000 and listed first by +the "flinfo" command. The secondary bank is always FF00_0000. + +When using PCI, linux needs to know to which slot the CDS carrier is +connected.. By convention, the user-specific bits of SW2 are used to +convey this information: + + 12345678 + -------- + SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia + xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia + xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia + xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia + +These are cleverly, er, clearly silkscreened as Slot 1 through 4, +respectively, on the Arcadia near the support posts. + + +The default setting of all switches on the carrier board is: + + 12345678 + -------- + SW1=01101100 + SW2=0x1111yy x=Flash bank, yy=PCI slot + SW3=11101111 + SW4=10001000 + + +8555/41 CPU Card Switches +------------------------- + +Most switches on the CPU Card should not be changed. However, the +frequency can be changed by setting SW3: + + 12345678 + -------- + SW3=XX00XXXX == CORE:CCB 2:1 + XX01XXXX == CORE:CCB 5:2 + XX10XXXX == CORE:CCB 3:1 + XX11XXXX == CORE:CCB 7:2 + XXXX1000 == CCB:SYSCLK 8:1 + XXXX1010 == CCB:SYSCLK 10:1 + +A safe default setting for all switches on the CPU board is: + + 12345678 + -------- + SW1=10001111 + SW2=01000111 + SW3=00001000 + SW4=11111110 + + +8548 CPU Card Switches +---------------------- +And, just to be confusing, in this set of switches: + + ON = 1 + OFF = 0 + +Default + SW1=11111101 + SW2=10011111 + SW3=11001000 (8X) (2:1) + SW4=11110011 + + SW3=X000XXXX == CORE:CCB 4:1 + X001XXXX == CORE:CCB 9:2 + X010XXXX == CORE:CCB 1:1 + X011XXXX == CORE:CCB 3:2 + X100XXXX == CORE:CCB 2:1 + X101XXXX == CORE:CCB 5:2 + X110XXXX == CORE:CCB 3:1 + X111XXXX == CORE:CCB 7:2 + XXXX0000 == CCB:SYSCLK 16:1 + XXXX0001 == RESERVED + XXXX0010 == CCB:SYSCLK 2:1 + XXXX0011 == CCB:SYSCLK 3:1 + XXXX0100 == CCB:SYSCLK 4:1 + XXXX0101 == CCB:SYSCLK 5:1 + XXXX0110 == CCB:SYSCLK 6:1 + XXXX0111 == RESERVED + XXXX1000 == CCB:SYSCLK 8:1 + XXXX1001 == CCB:SYSCLK 9:1 + XXXX1010 == CCB:SYSCLK 10:1 + XXXX1011 == RESERVED + XXXX1100 == CCB:SYSCLK 12:1 + XXXX1101 == CCB:SYSCLK 20:1 + XXXX1110 == RESERVED + XXXX1111 == RESERVED + + +eDINK Info +---------- + +One bank of flash may contain an eDINK image. + +Memory Map: + + CCSRBAR @ 0xe0000000 + Flash Bank 1 @ 0xfe000000 + Flash Bank 2 @ 0xff000000 + Ram @ 0 + +Commands for downloading a u-boot image to memory from edink: + + env -c + time -s 4/8/2004 4:30p + dl -k -b -o 100000 + [Drop to kermit: + ^\c + transmit /binary <u-boot-bin-image> + c + ] + + fu -l 100000 fe780000 80000 diff --git a/qemu/roms/u-boot/doc/README.mxc_hab b/qemu/roms/u-boot/doc/README.mxc_hab new file mode 100644 index 000000000..43e64a279 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mxc_hab @@ -0,0 +1,48 @@ +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 new file mode 100644 index 000000000..7a2863cfd --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mxc_ocotp @@ -0,0 +1,51 @@ +Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP) +on MXC + +This IP can be found on the following SoCs: + - Vybrid VF610, + - i.MX6. + +Note that this IP is different from albeit similar to the IPs of the same name +that can be found on the following SoCs: + - i.MX23, + - i.MX28, + - i.MX50. + +The section numbers in this file refer to the i.MX6 Reference Manual. + +A fuse word contains 32 fuse bit slots, as explained in 46.2.1. + +A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the +memory map in 46.4. + +Some fuse bit or word slots may not have the corresponding fuses actually +implemented in the fusebox. + +See the README files of the SoCs using this driver in order to know the +conventions used by U-Boot to store some specific data in the fuses, e.g. MAC +addresses. + +Fuse operations: + + Read + Read operations are implemented as read accesses to the shadow registers, + using "Bankx Wordy" from the memory map in 46.4. This is explained in + detail by the first two paragraphs in 46.2.1.2. + + Sense + Sense operations are implemented as the direct fusebox read explained by + the steps in 46.2.1.2. + + Program + Program operations are implemented as explained by the steps in 46.2.1.3. + Following this operation, the shadow registers are not reloaded by the + hardware. + + Override + Override operations are implemented as write accesses to the shadow + registers, as explained by the first paragraph in 46.2.1.3. + +Configuration: + + CONFIG_MXC_OCOTP + Define this to enable the mxc_ocotp driver. diff --git a/qemu/roms/u-boot/doc/README.mxs b/qemu/roms/u-boot/doc/README.mxs new file mode 100644 index 000000000..0235a5aea --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mxs @@ -0,0 +1,264 @@ +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 new file mode 100644 index 000000000..0d31cba1f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.mxsimage @@ -0,0 +1,165 @@ +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 new file mode 100644 index 000000000..b91f1985d --- /dev/null +++ b/qemu/roms/u-boot/doc/README.nand @@ -0,0 +1,303 @@ +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 new file mode 100644 index 000000000..1e9c10264 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.nand-boot-ppc440 @@ -0,0 +1,60 @@ +----------------------------- +NAND boot on PPC440 platforms +----------------------------- + +This document describes the U-Boot NAND boot feature as it +is implemented for the AMCC Sequoia (PPC440EPx) board. + +The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH, +completely without NOR FLASH. This can be done by using the NAND +boot feature of the 440 NAND flash controller (NDFC). + +Here a short description of the different boot stages: + +a) IPL (Initial Program Loader, integrated inside CPU) +------------------------------------------------------ +Will load first 4k from NAND (SPL) into cache and execute it from there. + +b) SPL (Secondary Program Loader) +--------------------------------- +Will load special U-Boot version (NUB) from NAND and execute it. This SPL +has to fit into 4kByte. It sets up the CPU and configures the SDRAM +controller and the NAND controller so that the special U-Boot image can be +loaded from NAND to SDRAM. +This special image is build in the directory "nand_spl". + +c) NUB (NAND U-Boot) +-------------------- +This NAND U-Boot (NUB) is a special U-Boot version which can be started +from RAM. Therefore it mustn't (re-)configure the SDRAM controller. + +On 440EPx the SPL is copied to internal SRAM before the NAND controller +is set up. While still running from cache, I experienced problems accessing +the NAND controller. + + +Example: Build and install NAND boot image for Sequoia (440EPx): + +a) Configure for sequoia with NAND boot support: +# make sequoia_nand_config + +b) Build image(s) +# make + +This will generate the SPL image in the "nand_spl" directory: +nand_spl/u-boot-spl.bin +Also another image is created spanning a whole NAND block (16kBytes): +nand_spl/u-boot-spl-16k.bin +The main NAND U-Boot image is generated in the toplevel directory: +u-boot.bin +A combined image of u-boot-spl-16k.bin and u-boot.bin is also created: +u-boot-nand.bin + +This image should be programmed at offset 0 in the NAND flash: + +# tftp 100000 /tftpboot/sequoia/u-boot-nand.bin +# nand erase 0 60000 +# nand write 100000 0 60000 + + +September 07 2006, Stefan Roese <sr@denx.de> diff --git a/qemu/roms/u-boot/doc/README.ne2000 b/qemu/roms/u-boot/doc/README.ne2000 new file mode 100644 index 000000000..d5ae9a9eb --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ne2000 @@ -0,0 +1,38 @@ +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 new file mode 100644 index 000000000..586ed7c1c --- /dev/null +++ b/qemu/roms/u-boot/doc/README.nokia_rx51 @@ -0,0 +1,104 @@ +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 new file mode 100644 index 000000000..0c974baca --- /dev/null +++ b/qemu/roms/u-boot/doc/README.omap-reset-time @@ -0,0 +1,20 @@ +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 new file mode 100644 index 000000000..a5240b9e2 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.omap-ulpi-viewport @@ -0,0 +1,27 @@ +Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c" + +Contains the ulpi read write api's to perform +any ulpi phy port access on omap platform. + +On omap ehci reg map contains INSNREG05_ULPI +register which offers the ulpi phy access so +any ulpi phy commands should be passsed using this +register. + +omap-ulpi-viewport.c is a low level function +implementation of "drivers/usb/ulpi/ulpi.c" + +To enable and use omap-ulpi-viewport.c +we require CONFIG_USB_ULPI_VIEWPORT_OMAP and +CONFIG_USB_ULPI be enabled in config file. + +Any ulpi ops request can be done with ulpi.c +and soc specific binding and usage is done with +omap-ulpi-viewport implementation. + +Ex: scenario: +omap-ehci driver code requests for ulpi phy reset if +ehci is used in phy mode, which will call ulpi phy reset +the ulpi phy reset does ulpi_read/write from viewport +implementation which will do ulpi reset using the +INSNREG05_ULPI register. diff --git a/qemu/roms/u-boot/doc/README.omap3 b/qemu/roms/u-boot/doc/README.omap3 new file mode 100644 index 000000000..a62c35740 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.omap3 @@ -0,0 +1,220 @@ + +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 new file mode 100644 index 000000000..7fdd26b71 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.pblimage @@ -0,0 +1,111 @@ +------------------------------------------------------------------ +Freescale PBL(pre-boot loader) Boot Image generation using mkimage +------------------------------------------------------------------ + +The CoreNet SoC's can boot directly from eSPI FLASH, SD/MMC and +NAND, etc. These SoCs use PBL to load RCW and/or pre-initialization +instructions. For more details refer section 5 Pre-boot loader +specifications of reference manual P3041RM/P4080RM/P5020RM at link: +http://www.freescale.com/webapp/search/Serp.jsp?Reference+Manuals + +Building PBL Boot Image and boot steps +-------------------------------------- + +1. Building PBL Boot Image. + The default Image is u-boot.pbl. + + For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240): + To build the eSPI boot image: + make <board_name>_SPIFLASH + + For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240): + To build the SD boot image: + make <board_name>_SDCARD + + For Nand boot(available on P2041/P3041/P5020/P5040): + To build the NAND boot image: + make <board_name>_NAND + + +2. pblimage support available with mkimage utility will generate Freescale PBL +boot image that can be flashed on the board eSPI flash, SD/MMC and NAND. +Following steps describe it in detail. + + 1). Boot from eSPI flash + Write u-boot.pbl to eSPI flash from offset 0x0. + for ex in u-boot: + =>tftp 100000 u-boot.pbl + =>sf probe 0 + =>sf erase 0 100000 + =>sf write 100000 0 $filesize + Change SW1[1:5] = off off on off on. + + 2). Boot from SD/MMC + Write u-boot.pbl to SD/MMC from offset 0x1000. + for ex in u-boot: + =>tftp 100000 u-boot.pbl + =>mmcinfo + =>mmc write 100000 8 441 + Change SW1[1:5] = off off on on off. + + 3). Boot from Nand + Write u-boot.pbl to Nand from offset 0x0. + for ex in u-boot: + =>tftp 100000 u-boot.pbl + =>nand info + =>nand erase 0 100000 + =>nand write 100000 0 $filesize + Change SW1[1:5] = off on off off on + Change SW7[1:4] = on off off on + +Board specific configuration file specifications: +------------------------------------------------ +1. Configuration files rcw.cfg and pbi.cfg must present in the +board/freescale/corenet_ds/, rcw.cfg is for RCW, pbi.cfg is for +PBI instructions. File name must not be changed since they are used +in Makefile. +2. These files can have empty lines and lines starting with "#" as first +character to put comments + +Typical example of rcw.cfg file: +----------------------------------- + +#PBL preamble and RCW header +aa55aa55 010e0100 +#64 bytes RCW data +4c580000 00000000 18185218 0000cccc +40464000 3c3c2000 58000000 61000000 +00000000 00000000 00000000 008b6000 +00000000 00000000 00000000 00000000 + +Typical example of pbi.cfg file: +----------------------------------- + +#PBI commands +#Initialize CPC1 +09010000 00200400 +09138000 00000000 +091380c0 00000100 +09010100 00000000 +09010104 fff0000b +09010f00 08000000 +09010000 80000000 +#Configure LAW for CPC1 +09000d00 00000000 +09000d04 fff00000 +09000d08 81000013 +09000010 00000000 +09000014 ff000000 +09000018 81000000 +#Initialize eSPI controller +09110000 80000403 +09110020 2d170008 +09110024 00100008 +09110028 00100008 +0911002c 00100008 +#Flush PBL data +09138000 00000000 +091380c0 00000000 + +------------------------------------------------ +Author: Shaohui Xie<Shaohui.Xie@freescale.com> diff --git a/qemu/roms/u-boot/doc/README.plan9 b/qemu/roms/u-boot/doc/README.plan9 new file mode 100644 index 000000000..2d3d0e0cf --- /dev/null +++ b/qemu/roms/u-boot/doc/README.plan9 @@ -0,0 +1,18 @@ +Plan 9 from Bell Labs kernel images require additional setup to pass +configuration information to the kernel. An environment variable named +confaddr must be defined with the same value as CONFADDR (see mem.h). +Use of this facility is optional, but should be preferable to manual +configuration. + +When booting an image, arguments supplied to the bootm command will be +copied to CONFADDR. If no arguments are specified, the contents of the +bootargs environment variable will be copied. + +If no command line arguments or bootargs are defined, CONFADDR is left +uninitialized to permit manual configuration. For example, PC-style +configuration could be simulated by issuing a fatload in bootcmd: + + # setenv bootcmd fatload mmc 0 $confaddr plan9.ini; ...; bootm + +Steven Stallion +June 2013 diff --git a/qemu/roms/u-boot/doc/README.power-framework b/qemu/roms/u-boot/doc/README.power-framework new file mode 100644 index 000000000..1f6fd4320 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.power-framework @@ -0,0 +1,166 @@ +# +# (C) Copyright 2014 Samsung Electronics +# Lukasz Majewski <l.majewski@samsung.com> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +Introduction +------------ + +This document describes the second version of the u-boot's PMIC (Power +Management IC) framework. As a reference boards please consider Samsungs' Trats +and Trats2. + +Background +---------- + +Boards supported by u-boot are getting increasingly complex. Developers and +designers strive to cut down power consumption. Hence several different types of +devices are now available on the board - namely power managers (PMIC), fuel +gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function +devices (MFD). + +Explanation of key design decisions +----------------------------------- + +One package can integrate PMIC and MUIC with different addresses on the I2C bus. +The same device - e.g. MAX8997 uses two different I2C busses and addresses. + +Power devices use not only I2C for communication, but SPI as well. Additionally +different ICs use different endianess. For this reason struct pmic holds +information about I2C/SPI transmission, which is used with generic +pmic_req_write() function. + +The "flat" hierarchy for power devices works well when each device performs only +one operation - e.g. PMIC enables LDO. + +The problem emerges when we have a device (battery) which conceptually shall be +the master and uses methods exported by other devices. We need to control MUIC +to start charging the battery, use PMIC to reduce board's overall power +consumption (by disabling not needed LDOs, BUCKs) and get current state of +energy on the battery from FG. +Up till now u-boot doesn't support device model, so a simple one had to be +added. + +The directory hierarchy has following structure: +./include/power/<device_name>_<device_function>.h +e.g. ./include/power/max8997_pmic.h + +./drivers/power/pmic/power_{core files}.c +e.g. ./drivers/power/pmic/power_core.c + +./drivers/power/pmic/<device_function>/<device_function>_<device_name>.c +e.g. ./drivers/power/pmic/pmic_max8997.c +e.g. ./drivers/power/battery/trats/bat_trats.c +e.g. ./drivers/power/fuel_gauge/fg_max17042.c + +The framework classifies devices by their function - separate directories should +be maintained for different classes of devices. + +Current design +-------------- + +Everything is a power device described by struct pmic. Even battery is +considered as a valid power device. This helps for better management of those +devices. + +- Block diagram of the hierarchy: + ----------------- + --------| BAT |------------ + | | | | + | ----------------- | + | | | + \|/ \|/ \|/ + ----------- ----------------- --------- + |FG | |MUIC | |CHRG | + | | | | | | + ----------- ----------------- --------- + + +1. When hierarchy is not needed (no complex battery charge): + +Definition of the struct pmic is only required with proper name and parameters +for communication. This is enough to use the "pmic" command in the u-boot +prompt to change values of device's register (enable/disable LDO, BUCK). + +The PG, MUIC and CHRG above are regarded to be in the same level in the +hierarchy. + +2. Complex battery charging. + +To charge a battery, information from several "abstract" power devices is +needed (defined at ./include/power/pmic.h): +- FG device (struct power_fg): + -- *fg_battery_check - check if battery is not above its limits + -- *fg_battery_update - update the pmic framework with current + battery state(voltage and current capacity) + +- Charger device (struct power_chrq): + -- *chrg_type - type/capacity of the charger (including information + about USB cable disconnection) + -- *chrg_bat_present - detection if battery to be charged is + present + -- *chrg_state - status of the charger - if it is enabled or + disabled + +- Battery device (struct power_battery): + -- *battery_init - assign proper callbacks to be used by top + hierarchy battery device + -- *battery_charge - called from "pmic" command, responsible + for performing the charging + +Now two batteries are supported; trats and trats2 [*]. Those differ in the way +how they handle the exact charging. Trats uses polling (MAX8997) and trats2 +relies on the PMIC/MUIC HW completely (MAX77693). + +__Example for trats (this can be very different for other board):__ + -- *fg_battery_check -> FG device (fg_max17042.c) + -- *fg_battery_update -> FG device (fg_max17042.c) + -- *chrg_type -> MUIC device (muic_max8997.c) + -- *chrg_bat_present -> PMIC device (pmic_max8997.c) + -- *chrg_state -> PMIC device (pmic_max8997.c) + -- *battery_init -> BAT device (bat_trats.c) + -- *battery_charge -> BAT device (bat_trats.c) + +Also the struct pmic holds method (*low_power_mode) for reducing board's +power consumption when one calls "pmic BAT_TRATS bat charge" command. + +How to add a new power device +----------------------------- + +1. Simple device should be added with creation of file +<pmic_function>_<pmic_name>.c, <pmic_name>_<pmic_function>.h according to the +proposed and described above scheme. + +Then "pmic" command supports reading/writing/dump of device's internal +registers. + +2. Charging battery with hierarchy +Define devices as listed at 1. + +Define battery file (bat_<board>.c). Please also note that one might need a +corresponding battery model description for FG. + +For points 1 and 2 use a generic function power_init_board() to initialise the +power framework on your board. + +For reference, please look into the trats/trats2 boards. + +TO DO list (for PMICv3) - up till v2014.04 +------------------------------------------ + +1. Description of the devices related to power via device tree is not available. +This is the main problem when a developer tries to build a multi-boot u-boot +binary. The best would be to parse the DTS from Linux kernel. + +2. To support many instances of the same IC, like two MAX8997, one needs to +copy the corresponding pmic_max8997.c file with changed name to "MAX8997_PMICX", +where X is the device number. This problem will be addressed when extended +pmic_core.c will support storing available devices in a list. + +3. Definition of batteries [*] (for trats/trats2) should be excluded from the +code responsible for charging them and since it in fact describes the charging +profile it should be put to a separate file. + +4. Adjust the framework to work with the device model. diff --git a/qemu/roms/u-boot/doc/README.ppc440 b/qemu/roms/u-boot/doc/README.ppc440 new file mode 100644 index 000000000..dd8ccaad0 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ppc440 @@ -0,0 +1,197 @@ + 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 new file mode 100644 index 000000000..f67605cf9 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.pxe @@ -0,0 +1,236 @@ +/* + * 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 new file mode 100644 index 000000000..a192752f4 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.qemu-mips @@ -0,0 +1,195 @@ +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 new file mode 100644 index 000000000..5cc546a36 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ramboot-ppc85xx @@ -0,0 +1,102 @@ + RAMBOOT for MPC85xx Platforms + ============================== + +RAMBOOT literally means boot from DDR. But since DDR is volatile memory some +pre-mechanism is required to load the DDR with the bootloader binary. +- In case of SD and SPI boot this is done by BootROM code inside the chip + itself. +- In case of NAND boot FCM supports loading initial 4K code from NAND flash + which can initialize the DDR and get the complete bootloader copied to DDR. + +In addition to the above there could be some more methods to initialize the DDR +and load it manually. +Two of them are described below.There is also an explanation as to where these +methods could be handy. +1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then + execute the bootloader from DDR. + This may be handy in the following cases: + - In very early stage of platform bringup where other boot options are not + functional because of various reasons. + - In case the support to program the flashes on the board is not available. + +2. Load the RAM based bootloader onto DDR using already existing bootloader on + the board.And then execute the bootloader from DDR. + Some usecases where this may be used: + - While developing some new feature of u-boot, for example USB driver or + SPI driver. + Suppose the board already has a working bootloader on it. And you would + prefer to keep it intact, at the same time want to test your bootloader. + In this case you can get your test bootloader binary into DDR via tftp + for example. Then execute the test bootloader. + - Suppose a platform already has a propreitery bootloader which does not + support for example AMP boot. In this case also RAM boot loader can be + utilized. + + So basically when the original bootloader is required to be kept intact + RAM based bootloader can offer an updated bootloader on the system. + +Both the above Bootloaders are slight variants of SDcard or SPI Flash +bootloader or for that matter even NAND bootloader. +All of them define CONFIG_SYS_RAMBOOT. +The main difference among all of them is the way the pre-environment is getting +configured and who is doing that. +- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself. +- In case of NAND boot SPL/TPL code does it with some support from Si itself. +- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader. + +How to use them: +1. Using JTAG + Boot up in core hold off mode or stop the core after reset using JTAG + interface. + Preconfigure DDR/L2SRAM through JTAG interface. + - setup DDR controller registers. + - setup DDR LAWs + - setup DDR TLB + Load the RAM based boot loader to the proper location in DDR/L2SRAM. + set up IAR (Instruction counter properly) + Enable the core to execute. + +2. Using already existing bootloader. + get the rambased boot loader binary into DDR/L2SRAM via tftp. + execute the RAM based bootloader. + => tftp 11000000 u-boot-ram.bin + => go 1107f000 + +Please note that L2SRAM can also be used instead of DDR if the SOC has +sufficient size of L2SRAM. + +Necessary Code changes Required: +===================================== +Please note that below mentioned changes are for 85xx platforms. +They have been tested on P1020/P2020/P1010 RDB. + +The main difference between the above two methods from technical perspective is +that in 1st case SOC is just out of reset so it is in default configuration. +(CCSRBAR is at 0xff700000). +In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000 + +1. File name-> boards.cfg + There can be added specific Make options for RAMBoot. We can keep different + options for the two cases mentioned above. + for example + P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT. + +2. platform config file + for example include/configs/P1_P2_RDB.h + + #ifdef CONFIG_RAMBOOT + #define CONFIG_SDCARD + #endif + + This will finally use the CONFIG_SYS_RAMBOOT. + +3. 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 new file mode 100644 index 000000000..4fbbcb3ef --- /dev/null +++ b/qemu/roms/u-boot/doc/README.rmobile @@ -0,0 +1,84 @@ +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 new file mode 100644 index 000000000..ab1f02469 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.s5pc1xx @@ -0,0 +1,72 @@ + +Summary +======= + +This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx +family of SoCs (S5PC100 [1] and S5PC110). + +Currently the following board is supported: + +* SMDKC100 [2] + +Toolchain +========= + +While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile +with -march=armv5 to allow more compilers to work. For U-Boot code this has +no performance impact. + +Build +===== + +* SMDKC100 + +make smdkc100_config +make + + +Interfaces +========== + +cpu + +To check SoC: + + if (cpu_is_s5pc100()) + printf("cpu is s5pc100\n"); + + or + + if (cpu_is_s5pc110()) + printf("cpu is s5pc110\n"); + +gpio + + struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE; + + /* GPA[0] pin set to irq */ + gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ); + + /* GPA[0] pin set to input */ + gpio_direction_input(&gpio->gpio_a, 0); + + /* GPA[0] pin set to output/high */ + gpio_direction_output(&gpio->gpio_a, 0, 1); + + /* GPA[0] value set to low */ + gpio_set_value(&gpio->gpio_a, 0, 0); + + /* get GPA[0] value */ + value = gpio_get_value(&gpio->gpio_a, 0); + +Links +===== + +[1] S5PC100: + +http://www.samsung.com/global/business/semiconductor/productInfo.do? +fmly_id=229&partnum=S5PC100 + +[2] SMDKC100: + +http://meritech.co.kr/eng/products/product_view.php?num=28 diff --git a/qemu/roms/u-boot/doc/README.sandbox b/qemu/roms/u-boot/doc/README.sandbox new file mode 100644 index 000000000..529c447a5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sandbox @@ -0,0 +1,299 @@ +/* + * 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 new file mode 100644 index 000000000..d0ce6673b --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sata @@ -0,0 +1,68 @@ +1. SATA usage in U-boot + + There are two ways to operate the hard disk + + * Read/write raw blocks from/to SATA hard disk + * ext2load to read a file from ext2 file system + +1.0 How to read the SATA hard disk's information? + + => sata info + +SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN + Type: Hard Disk + Supports 48-bit addressing + Capacity: 305245.3 MB = 298.0 GB (625142448 x 512) + +1.1 How to raw write the kernel, file system, dtb to a SATA hard disk? + + Notes: Hard disk sectors are normally 512 bytes, so + 0x1000 sectors = 2 MBytes + + write kernel + => tftp 40000 /tftpboot/uImage.837x + => sata write 40000 0 2000 + + write ramdisk + => tftp 40000 /tftpboot/ramdisk.837x + => sata write 40000 2000 8000 + + write dtb + => tftp 40000 /tftpboot/mpc837xemds.dtb + => sata write 40000 a000 1000 + +1.2 How to raw read the kernel, file system, dtb from a SATA hard disk? + + load kernel + => sata read 200000 0 2000 + + load ramdisk + => sata read 1000000 2000 8000 + + load dtb + => sata read 2000000 a000 1000 + + boot + => bootm 200000 1000000 2000000 + +1.3 How to load an image from an ext2 file system in U-boot? + + U-boot doesn't support writing to an ext2 file system, so the + files must be written by other means (e.g. linux). + + => ext2ls sata 0:1 / + <DIR> 4096 . + <DIR> 4096 .. + <DIR> 16384 lost+found + 1352023 uImage.837x + 3646377 ramdisk.837x + 12288 mpc837xemds.dtb + 12 hello.txt + + => ext2load sata 0:1 200000 /uImage.837x + + => ext2load sata 0:1 1000000 /ramdisk.837x + + => ext2load sata 0:1 2000000 /mpc837xemds.dtb + + => bootm 200000 1000000 2000000 diff --git a/qemu/roms/u-boot/doc/README.sched b/qemu/roms/u-boot/doc/README.sched new file mode 100644 index 000000000..3aa89e6d3 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sched @@ -0,0 +1,53 @@ +Notes on the scheduler in sched.c: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + 'sched.c' provides an very simplistic multi-threading scheduler. + See the example, function 'sched(...)', in the same file for its + API usage. + + Until an exhaustive testing can be done, the implementation cannot + qualify as that of production quality. It works with the example + in 'sched.c', it may or may not work in other cases. + + +Limitations: +~~~~~~~~~~~~ + + - There are NO primitives for thread synchronization (locking, + notify etc). + + - Only the GPRs and FPRs context is saved during a thread context + switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx + etc) are NOT saved. + + - The scheduler is NOT transparent to the user. The user + applications must invoke thread_yield() to allow other threads to + scheduler. + + - There are NO priorities, and the scheduling policy is round-robin + based. + + - There are NO capabilities to collect thread CPU usage, scheduler + stats, thread status etc. + + - The semantics are somewhat based on those of pthreads, but NOT + the same. + + - Only seven threads are allowed. These can be easily increased by + changing "#define MAX_THREADS" depending on the available memory. + + - The stack size of each thread is 8KBytes. This can be easily + increased depending on the requirement and the available memory, + by increasing "#define STK_SIZE". + + - Only one master/parent thread is allowed, and it cannot be + stopped or deleted. Any given thread is NOT allowed to stop or + delete itself. + + - There NOT enough safety checks as are probably in the other + threads implementations. + + - There is no parent-child relationship between threads. Only one + thread may thread_join, preferably the master/parent thread. + +(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com> diff --git a/qemu/roms/u-boot/doc/README.scrapyard b/qemu/roms/u-boot/doc/README.scrapyard new file mode 100644 index 000000000..f9742e7d4 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.scrapyard @@ -0,0 +1,128 @@ +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 new file mode 100644 index 000000000..ad61d4261 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.serial_multi @@ -0,0 +1,80 @@ +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 new file mode 100644 index 000000000..6baee089e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sh @@ -0,0 +1,104 @@ + +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 new file mode 100644 index 000000000..c1fb54cdc --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sh7752evb @@ -0,0 +1,67 @@ +======================================== +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 new file mode 100644 index 000000000..5fe178c53 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sh7753evb @@ -0,0 +1,67 @@ +======================================== +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 new file mode 100644 index 000000000..f6cca40d5 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.sha1 @@ -0,0 +1,57 @@ +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 new file mode 100644 index 000000000..6d90a0ec4 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.silent @@ -0,0 +1,28 @@ +The config option CONFIG_SILENT_CONSOLE can be used to quiet messages +on the console. If the option has been enabled, the output can be +silenced by setting the environment variable "silent". + +- CONFIG_SILENT_CONSOLE_UPDATE_ON_SET + When the "silent" variable is changed with env set, the change + will take effect immediately. + +- CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC + Some environments are not available until relocation (e.g. NAND) + so this will make the value in the flash env take effect at + relocation. + +The following actions are taken if "silent" is set at boot time: + + - Until the console devices have been initialized, output has to be + suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags". + + - When the console devices have been initialized, "stdout" and + "stderr" are set to "nulldev", so subsequent messages are + suppressed automatically. Make sure to enable "nulldev" by + #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 new file mode 100644 index 000000000..cfcbbfe37 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.socfpga @@ -0,0 +1,53 @@ + +-------------------------------------------- +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 new file mode 100644 index 000000000..0789b3fd2 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.spear @@ -0,0 +1,74 @@ + +SPEAr (Structured Processor Enhanced Architecture). + +SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic + +The SPEAr SoC family embeds a customizable logic that can be programmed +one-time by a customer at silicon mask level (i.e. not at runtime!). + +U-Boot supports four SoCs: SPEAr600, SPEAr3xx + +All 4 SoCs (SPEAr3xx and SPEAr600) share common peripherals. SPEAr300 and +SPEAr600 do not have EMI. + +1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux) +2. FastEthernet (sp600 has Gbit version, but same controller - GMAC) +3. USB Host +4. USB Device +5. NAND controller (FSMC) +6. Serial NOR ctrl +7. I2C +8. SPI +9. CLCD +10. others .. + +Everything is supported in Linux. +u-boot is currently not supporting all peripeharls (just a few as listed below). +1. USB Device +2. NAND controller (FSMC) +3. Serial Memory Interface +4. EMI (Parallel NOR interface) +4. I2C +5. UART + +Build options + make spear320_config + spear320 build with environment variables placed at default + location i.e. Serial NOR device + make spear320_pnor_config + This option generates a uboot image that supports emi controller + for CFI compliant parallel NOR flash. Environment variables are + placed in Parallel NOR device + make spear320_nand_config + spear320 build with environment variables placed in NAND device + make spear320_usbtty_config + spear320 build with usbtty terminal as default and environment + placed at default location + make spear320_usbtty_pnor_config + spear320 build with usbtty terminal as default and environment + placed in pnor device + make spear320_usbtty_nand_config + Build with usbtty terminal as default and environment placed in + NAND device + make spear300_config + make spear300_nand_config + make spear300_usbtty_config + make spear300_usbtty_nand_config + make spear310_config + make spear310_pnor_config + make spear310_nand_config + make spear310_usbtty_config + make spear310_usbtty_pnor_config + make spear310_usbtty_nand_config + make spear600_config + make spear600_nand_config + make spear600_usbtty_config + make spear600_usbtty_nand_config + +Mac id storage and retrieval in spear platforms + +Please read doc/README.enetaddr for the implementation guidelines for mac id +usage. Basically, environment has precedence over board specific storage. The +ethaddr beeing used for the network interface is always taken only from +environment variables. Although, we can check the mac id programmed in i2c +memory by using chip_config command diff --git a/qemu/roms/u-boot/doc/README.splashprepare b/qemu/roms/u-boot/doc/README.splashprepare new file mode 100644 index 000000000..61b4ec53e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.splashprepare @@ -0,0 +1,8 @@ +--------------------------------------------------------------------- +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 new file mode 100644 index 000000000..2b1f76b8d --- /dev/null +++ b/qemu/roms/u-boot/doc/README.srio-pcie-boot-corenet @@ -0,0 +1,118 @@ +--------------------------------------- +SRIO and PCIE Boot on Corenet Platforms +--------------------------------------- + +For some PowerPC processors with SRIO or PCIE interface, boot location can be +configured to SRIO or PCIE by RCW. The processor booting from SRIO or PCIE can +do without flash for u-boot image, ucode and ENV. All the images can be fetched +from another processor's memory space by SRIO or PCIE link connected between +them. + +This document describes the processes based on an example implemented on P4080DS +platforms and a RCW example with boot from SRIO or PCIE configuration. + +Environment of the SRIO or PCIE boot: + a) Master and slave can be SOCs in one board or SOCs in separate boards. + b) They are connected with SRIO or PCIE links, whether 1x, 2x or 4x, and + directly or through switch system. + c) Only Master has NorFlash for booting, and all the Master's and Slave's + U-Boot images, UCodes will be stored in this flash. + d) Slave has its own EEPROM for RCW and PBI. + e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set + the boot location to SRIO or PCIE, and holdoff all the cores. + + ----------- ----------- ----------- + | | | | | | + | | | | | | + | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM] + | | | |<===========>| | + | | | | | | + ----------- ----------- ----------- + +The example based on P4080DS platform: + Two P4080DS platforms can be used to implement the boot from SRIO or PCIE. + Their SRIO or PCIE ports 1 will be connected directly and will be used for + the boot from SRIO or PCIE. + + 1. Slave's RCW example for boot from SRIO port 1 and all cores in holdoff. + 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000 + 00000010: 1818 1818 0000 8888 7440 4000 0000 2000 + 00000020: f440 0000 0100 0000 0000 0000 0000 0000 + 00000030: 0000 0000 0083 0000 0000 0000 0000 0000 + 00000040: 0000 0000 0000 0000 0813 8040 063c 778f + + 2. Slave's RCW example for boot from PCIE port 1 and all cores in holdoff. + 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000 + 00000010: 1818 1818 0000 8888 1440 4000 0000 2000 + 00000020: f040 0000 0100 0000 0020 0000 0000 0000 + 00000030: 0000 0000 0083 0000 0000 0000 0000 0000 + 00000040: 0000 0000 0000 0000 0813 8040 547e ffc9 + + 3. Sequence in Step by Step. + a) Update RCW for slave with boot from SRIO or PCIE port 1 configuration. + b) Program slave's U-Boot image, UCode, and ENV parameters into master's + NorFlash. + c) Set environment variable "bootmaster" to "SRIO1" or "PCIE1" and save + environment for master. + setenv bootmaster SRIO1 + or + setenv bootmaster PCIE1 + saveenv + d) Restart up master and it will boot up normally from its NorFlash. + Then, it will finish necessary configurations for slave's boot from + SRIO or PCIE port 1. + e) Master will set inbound SRIO or PCIE windows covered slave's U-Boot + image stored in master's NorFlash. + f) Master will set an inbound SRIO or PCIE window covered slave's UCode + and ENV stored in master's NorFlash. + g) Master will set outbound SRIO or PCIE windows in order to configure + slave's registers for the core's releasing. + h) Since all cores of slave in holdoff, slave should be powered on before + all the above master's steps, and wait to be released by master. In the + startup phase of the slave from SRIO or PCIE, it will finish some + necessary configurations. + i) Slave will set a specific TLB entry for the boot process. + j) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for + the boot. + k) Slave will set a specific TLB entry in order to fetch UCode and ENV + from master. + l) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for + UCode and ENV. + +How to use this feature: + To use this feature, you need to focus those points. + + 1. Slave's RCW with SRIO or PCIE boot configurations, and all cores in holdoff + configurations. + Please refer to the examples given above. + + 2. U-Boot image's compilation. + For master, U-Boot image should be generated normally. + + For example, master U-Boot image used on P4080DS should be compiled with + + make P4080DS_config. + + For slave, U-Boot image should be generated specifically by + + make xxxx_SRIO_PCIE_BOOT_config. + + For example, slave U-Boot image used on P4080DS should be compiled with + + make P4080DS_SRIO_PCIE_BOOT_config. + + 3. Necessary modifications based on a specific environment. + For a specific environment, the addresses of the slave's U-Boot image, + UCode, ENV stored in master's NorFlash, and any other configurations + can be modified in the file: + include/configs/corenet_ds.h. + + 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2" + or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to + perform the role as a master for boot from SRIO or PCIE. + +NOTE: When the Slave's ENV parameters are stored in Master's NorFlash, + it can fetch them through PCIE or SRIO interface. But the ENV + parameters can not be modified by "saveenv" or other commands under + the Slave's u-boot environment, because the Slave can not erase, + write Master's NorFlash by PCIE or SRIO link. diff --git a/qemu/roms/u-boot/doc/README.standalone b/qemu/roms/u-boot/doc/README.standalone new file mode 100644 index 000000000..2be5f2769 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.standalone @@ -0,0 +1,100 @@ +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 new file mode 100644 index 000000000..f8903738e --- /dev/null +++ b/qemu/roms/u-boot/doc/README.switch_config @@ -0,0 +1,25 @@ +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 new file mode 100644 index 000000000..ef8c75f3b --- /dev/null +++ b/qemu/roms/u-boot/doc/README.t4240qds @@ -0,0 +1,175 @@ +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 new file mode 100644 index 000000000..f0c969977 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.trace @@ -0,0 +1,348 @@ +# +# 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 new file mode 100644 index 000000000..9efab6cdc --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ubi @@ -0,0 +1,225 @@ +------------------- +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 new file mode 100644 index 000000000..ab25b2615 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.ublimage @@ -0,0 +1,141 @@ +--------------------------------------------- +UBL image Boot Image generation using mkimage +--------------------------------------------- + +This document describes how to set up an U-Boot image that can be directly +booted by a DaVinci processor via NAND boot mode, using an UBL header, +but without need for UBL. + +For more details see section 11.2 "ARM ROM Boot Modes" of +http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf + +Command syntax: +-------------- +./tools/mkimage -l <u-boot_file> + to list the UBL image file details + +./tools/mkimage -T ublimage \ + -n <board specific configuration file> \ + -d <u-boot binary> <output image file> + +For example, for the davinci dm365evm board: +./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg \ + -T ublimage \ + -d u-boot-nand.bin u-boot.ubl + +You can generate the image directly when you compile u-boot with: + +$ make u-boot.ubl + +The output image can be flashed into the NAND. + +Please check the DaVinci documentation for further details. + +Board specific configuration file specifications: +------------------------------------------------- +1. This file must present in the $(BOARDDIR) and the name should be + ublimage.cfg (since this is used in Makefile). +2. This file can have empty lines and lines starting with "#" as first + character to put comments. +3. This file can have configuration command lines as mentioned below, + any other information in this file is treated as invalid. + +Configuration command line syntax: +--------------------------------- +1. Each command line must have two strings, first one command or address + and second one data string +2. Following are the valid command strings and associated data strings:- + Command string data string + -------------- ----------- + MODE UBL special mode, on of: + safe + Example: + MODE safe + + ENTRY Entry point address for the user + bootloader (absolute address) = TEXT_BASE + nand_spl loader. + Example: + ENTRY 0x00000020 + + PAGES Number of pages (size of user bootloader + in number of pages) + Example: + PAGES 27 + + START_BLOCK Block number where user bootloader is present + Example: + START_BLOCK 5 + + START_PAGE Page number where user bootloader is present + (for RBL always 0) + Example: + START_PAGE 0 + +------------------------------------------------ + +Structure of the u-boot.ubl binary: + +compile steps: + +1) nand_spl code compile, with pad_to = (TEXT_BASE + + (CONFIG_SYS_NROF_PAGES_NAND_SPL * pagesize)) + Example: cam_enc_4xx pad_to = 0x20 + (6 * 0x800) = 0x3020 = 12320 + -> u-boot-spl-16k.bin + + !! TEXT_BASE = 0x20, as the RBL starts at 0x20 + +2) compile u-boot.bin ("normal" u-boot) + -> u-boot.bin + +3) create u-boot-nand.bin = u-boot-spl-16k.bin + u-boot.bin + +4) create u-boot.ubl, size = 1 page size NAND + create UBL header and paste it before u-boot.bin + +This steps are done automagically if you do a "make all" + +-> You get an u-boot.ubl binary, which you can flash + into your NAND. + +Structure of this binary (Example for the cam_enc_4xx board with a NAND +page size = 0x800): + +offset : 0x00000 | 0x800 | 0x3800 +content: UBL | nand_spl | u-boot code + Header | code | + +The NAND layout looks for example like this: + +(Example for the cam_enc_4xx board with a NAND page size = 0x800, block +size = 0x20000 and CONFIG_SYS_NROF_UBL_HEADER 5): + +offset : 0x80000 | 0xa0000 | 0xa3000 +content: UBL | nand_spl | u-boot code + Header | code | + ^ ^ + ^ 0xa0000 = CONFIG_SYS_NROF_UBL_HEADER * 0x20000 + ^ + 0x80000 = Block 4 * 0x20000 + +If the cpu starts in NAND boot mode, it checks the UBL descriptor +starting with block 1 (page 0). When a valid UBL signature is found, +the corresponding block number (from 1 to 24) is written to the last 32 +bits of ARM internal memory (0x7ffc-0x8000). This feature is provided +as a basic debug mechanism. If not found, it continues with block 2 +... last possible block is 24 + +If a valid UBL descriptor is found, the UBL descriptor is read and +processed. The descriptor gives the information required for loading +and control transfer to the nand_spl code. The nand_spl code is then +read and processed. + +Once the user-specified start-up conditions are set, the RBL copies the +nand_spl into ARM internal RAM, starting at address 0x0000: 0020. + ^^^^ + +The nand_spl code itself now does necessary intializations, and at least, +copies the u-boot code from NAND into RAM, and jumps to it ... + +------------------------------------------------ +Author: Heiko Schocher <hs@denx.de> diff --git a/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt b/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt new file mode 100644 index 000000000..00529f5da --- /dev/null +++ b/qemu/roms/u-boot/doc/README.unaligned-memory-access.txt @@ -0,0 +1,240 @@ +Editors note: This document is _heavily_ cribbed from the Linux Kernel, with +really only the section about "Alignment vs. Networking" removed. + +UNALIGNED MEMORY ACCESSES +========================= + +Linux runs on a wide variety of architectures which have varying behaviour +when it comes to memory access. This document presents some details about +unaligned accesses, why you need to write code that doesn't cause them, +and how to write such code! + + +The definition of an unaligned access +===================================== + +Unaligned memory accesses occur when you try to read N bytes of data starting +from an address that is not evenly divisible by N (i.e. addr % N != 0). +For example, reading 4 bytes of data from address 0x10004 is fine, but +reading 4 bytes of data from address 0x10005 would be an unaligned memory +access. + +The above may seem a little vague, as memory access can happen in different +ways. The context here is at the machine code level: certain instructions read +or write a number of bytes to or from memory (e.g. movb, movw, movl in x86 +assembly). As will become clear, it is relatively easy to spot C statements +which will compile to multiple-byte memory access instructions, namely when +dealing with types such as u16, u32 and u64. + + +Natural alignment +================= + +The rule mentioned above forms what we refer to as natural alignment: +When accessing N bytes of memory, the base memory address must be evenly +divisible by N, i.e. addr % N == 0. + +When writing code, assume the target architecture has natural alignment +requirements. + +In reality, only a few architectures require natural alignment on all sizes +of memory access. However, we must consider ALL supported architectures; +writing code that satisfies natural alignment requirements is the easiest way +to achieve full portability. + + +Why unaligned access is bad +=========================== + +The effects of performing an unaligned memory access vary from architecture +to architecture. It would be easy to write a whole document on the differences +here; a summary of the common scenarios is presented below: + + - Some architectures are able to perform unaligned memory accesses + transparently, but there is usually a significant performance cost. + - Some architectures raise processor exceptions when unaligned accesses + happen. The exception handler is able to correct the unaligned access, + at significant cost to performance. + - Some architectures raise processor exceptions when unaligned accesses + happen, but the exceptions do not contain enough information for the + unaligned access to be corrected. + - Some architectures are not capable of unaligned memory access, but will + silently perform a different memory access to the one that was requested, + resulting in a subtle code bug that is hard to detect! + +It should be obvious from the above that if your code causes unaligned +memory accesses to happen, your code will not work correctly on certain +platforms and will cause performance problems on others. + + +Code that does not cause unaligned access +========================================= + +At first, the concepts above may seem a little hard to relate to actual +coding practice. After all, you don't have a great deal of control over +memory addresses of certain variables, etc. + +Fortunately things are not too complex, as in most cases, the compiler +ensures that things will work for you. For example, take the following +structure: + + struct foo { + u16 field1; + u32 field2; + u8 field3; + }; + +Let us assume that an instance of the above structure resides in memory +starting at address 0x10000. With a basic level of understanding, it would +not be unreasonable to expect that accessing field2 would cause an unaligned +access. You'd be expecting field2 to be located at offset 2 bytes into the +structure, i.e. address 0x10002, but that address is not evenly divisible +by 4 (remember, we're reading a 4 byte value here). + +Fortunately, the compiler understands the alignment constraints, so in the +above case it would insert 2 bytes of padding in between field1 and field2. +Therefore, for standard structure types you can always rely on the compiler +to pad structures so that accesses to fields are suitably aligned (assuming +you do not cast the field to a type of different length). + +Similarly, you can also rely on the compiler to align variables and function +parameters to a naturally aligned scheme, based on the size of the type of +the variable. + +At this point, it should be clear that accessing a single byte (u8 or char) +will never cause an unaligned access, because all memory addresses are evenly +divisible by one. + +On a related topic, with the above considerations in mind you may observe +that you could reorder the fields in the structure in order to place fields +where padding would otherwise be inserted, and hence reduce the overall +resident memory size of structure instances. The optimal layout of the +above example is: + + struct foo { + u32 field2; + u16 field1; + u8 field3; + }; + +For a natural alignment scheme, the compiler would only have to add a single +byte of padding at the end of the structure. This padding is added in order +to satisfy alignment constraints for arrays of these structures. + +Another point worth mentioning is the use of __attribute__((packed)) on a +structure type. This GCC-specific attribute tells the compiler never to +insert any padding within structures, useful when you want to use a C struct +to represent some data that comes in a fixed arrangement 'off the wire'. + +You might be inclined to believe that usage of this attribute can easily +lead to unaligned accesses when accessing fields that do not satisfy +architectural alignment requirements. However, again, the compiler is aware +of the alignment constraints and will generate extra instructions to perform +the memory access in a way that does not cause unaligned access. Of course, +the extra instructions obviously cause a loss in performance compared to the +non-packed case, so the packed attribute should only be used when avoiding +structure padding is of importance. + + +Code that causes unaligned access +================================= + +With the above in mind, let's move onto a real life example of a function +that can cause an unaligned memory access. The following function taken +from the Linux Kernel's include/linux/etherdevice.h is an optimized routine +to compare two ethernet MAC addresses for equality. + +bool ether_addr_equal(const u8 *addr1, const u8 *addr2) +{ +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) | + ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4))); + + return fold == 0; +#else + const u16 *a = (const u16 *)addr1; + const u16 *b = (const u16 *)addr2; + return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0; +#endif +} + +In the above function, when the hardware has efficient unaligned access +capability, there is no issue with this code. But when the hardware isn't +able to access memory on arbitrary boundaries, the reference to a[0] causes +2 bytes (16 bits) to be read from memory starting at address addr1. + +Think about what would happen if addr1 was an odd address such as 0x10003. +(Hint: it'd be an unaligned access.) + +Despite the potential unaligned access problems with the above function, it +is included in the kernel anyway but is understood to only work normally on +16-bit-aligned addresses. It is up to the caller to ensure this alignment or +not use this function at all. This alignment-unsafe function is still useful +as it is a decent optimization for the cases when you can ensure alignment, +which is true almost all of the time in ethernet networking context. + + +Here is another example of some code that could cause unaligned accesses: + void myfunc(u8 *data, u32 value) + { + [...] + *((u32 *) data) = cpu_to_le32(value); + [...] + } + +This code will cause unaligned accesses every time the data parameter points +to an address that is not evenly divisible by 4. + +In summary, the 2 main scenarios where you may run into unaligned access +problems involve: + 1. Casting variables to types of different lengths + 2. Pointer arithmetic followed by access to at least 2 bytes of data + + +Avoiding unaligned accesses +=========================== + +The easiest way to avoid unaligned access is to use the get_unaligned() and +put_unaligned() macros provided by the <asm/unaligned.h> header file. + +Going back to an earlier example of code that potentially causes unaligned +access: + + void myfunc(u8 *data, u32 value) + { + [...] + *((u32 *) data) = cpu_to_le32(value); + [...] + } + +To avoid the unaligned memory access, you would rewrite it as follows: + + void myfunc(u8 *data, u32 value) + { + [...] + value = cpu_to_le32(value); + put_unaligned(value, (u32 *) data); + [...] + } + +The get_unaligned() macro works similarly. Assuming 'data' is a pointer to +memory and you wish to avoid unaligned access, its usage is as follows: + + u32 value = get_unaligned((u32 *) data); + +These macros work for memory accesses of any length (not just 32 bits as +in the examples above). Be aware that when compared to standard access of +aligned memory, using these macros to access unaligned memory can be costly in +terms of performance. + +If use of such macros is not convenient, another option is to use memcpy(), +where the source or destination (or both) are of type u8* or unsigned char*. +Due to the byte-wise nature of this operation, unaligned accesses are avoided. + +-- +In the Linux Kernel, +Authors: Daniel Drake <dsd@gentoo.org>, + Johannes Berg <johannes@sipsolutions.net> +With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, +Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, +Vadim Lobanov diff --git a/qemu/roms/u-boot/doc/README.update b/qemu/roms/u-boot/doc/README.update new file mode 100644 index 000000000..a7f4d9ebe --- /dev/null +++ b/qemu/roms/u-boot/doc/README.update @@ -0,0 +1,95 @@ +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 new file mode 100644 index 000000000..bc768a385 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.usb @@ -0,0 +1,228 @@ +/* + * (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 new file mode 100644 index 000000000..38cf5cfd2 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.vf610 @@ -0,0 +1,10 @@ +U-Boot for Freescale Vybrid VF610 + +This file contains information for the port of U-Boot to the Freescale Vybrid +VF610 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the + 32 lsbs in word 3. diff --git a/qemu/roms/u-boot/doc/README.video b/qemu/roms/u-boot/doc/README.video new file mode 100644 index 000000000..dadbfcd2f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.video @@ -0,0 +1,31 @@ +/* + * (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 new file mode 100644 index 000000000..4cb302e7f --- /dev/null +++ b/qemu/roms/u-boot/doc/README.vxworks @@ -0,0 +1,19 @@ +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 new file mode 100644 index 000000000..59f306b85 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.watchdog @@ -0,0 +1,35 @@ +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 new file mode 100644 index 000000000..7f237c407 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.zfs @@ -0,0 +1,29 @@ +This patch series adds support for ZFS listing and load to u-boot. + +To Enable zfs ls and load commands, modify the board specific config file with +#define CONFIG_CMD_ZFS + +Steps to test: + +1. After applying the patch, zfs specific commands can be seen + in the boot loader prompt using + UBOOT #help + + zfsload- load binary file from a ZFS file system + zfsls - list files in a directory (default /) + +2. To list the files in zfs pool, device or partition, execute + zfsls <interface> <dev[:part]> [POOL/@/dir/file] + For example: + UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/ + +3. To read and load a file from an ZFS formatted partition to RAM, execute + zfsload <interface> <dev[:part]> [addr] [filename] [bytes] + For example: + UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage + +References : + -- ZFS GRUB sources from Solaris GRUB-0.97 + -- GRUB Bazaar repository + +Jorgen Lundman <lundman at lundman.net> 2012. diff --git a/qemu/roms/u-boot/doc/README.zynq b/qemu/roms/u-boot/doc/README.zynq new file mode 100644 index 000000000..043c97014 --- /dev/null +++ b/qemu/roms/u-boot/doc/README.zynq @@ -0,0 +1,94 @@ +# +# 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 new file mode 100644 index 000000000..6c88d65dd --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.dual-flash @@ -0,0 +1,92 @@ +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 new file mode 100644 index 000000000..1d86f3623 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.ftssp010_spi_test @@ -0,0 +1,41 @@ +SPI Flash test on Faraday A369 EVB: +================================== + +U-Boot 2014.01-rc2-g3444b6f (Dec 20 2013 - 10:58:40) + +CPU: FA626TE 528 MHz +AHB: 132 MHz +APB: 66 MHz +I2C: ready +DRAM: 256 MiB +MMU: on +NAND: 512 MiB +MMC: ftsdc010: 0 +*** Warning - bad CRC, using default environment + +In: serial +Out: serial +Err: serial +Net: FTGMAC100#0 +Hit any key to stop autoboot: 0 +=> sf probe 0:0 +SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB, total 2 MiB +=> sf read 0x10800000 0 0x400 +SF: 1024 bytes @ 0x0 Read: OK +=> md 0x10800000 +10800000: ea000013 e59ff014 e59ff014 e59ff014 ................ +10800010: e59ff014 e59ff014 e59ff014 e59ff014 ................ +10800020: 1ff7b0c0 1ff7b120 1ff7b180 1ff7b1e0 .... ........... +10800030: 1ff7b240 1ff7b2a0 1ff7b300 deadbeef @............... +10800040: 10800000 0002c1f0 0007409c 00032048 .........@..H .. +10800050: 1fd6af40 e10f0000 e3c0001f e38000d3 @............... +10800060: e129f000 eb000001 eb000223 e12fff1e ..).....#...../. +10800070: e3a00000 ee070f1e ee080f17 ee070f15 ................ +10800080: ee070f9a ee110f10 e3c00c03 e3c00087 ................ +10800090: e3c00a02 e3800002 e3800a01 ee010f10 ................ +108000a0: e1a0c00e eb007a68 e1a0e00c e1a0f00e ....hz.......... +108000b0: e1a00000 e1a00000 e1a00000 e1a00000 ................ +108000c0: e51fd078 e58de000 e14fe000 e58de004 x.........O..... +108000d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i......... +108000e0: e24dd048 e88d1fff e51f20a0 e892000c H.M...... ...... +108000f0: e28d0048 e28d5034 e1a0100e e885000f H...4P.......... diff --git a/qemu/roms/u-boot/doc/SPI/README.sandbox-spi b/qemu/roms/u-boot/doc/SPI/README.sandbox-spi new file mode 100644 index 000000000..bb73eaf28 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.sandbox-spi @@ -0,0 +1,64 @@ +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 new file mode 100644 index 000000000..8a33fec32 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.sh_qspi_test @@ -0,0 +1,38 @@ +------------------------------------------------- + Simple steps used to test the SH-QSPI at U-Boot +------------------------------------------------- + +#0, Currently, SH-QSPI is used by lager board (Renesas ARM SoC R8A7790) + and koelsch board (Renesas ARM SoC R8A7791). These boot from SPI ROM + basically. Thus, U-Boot start, SH-QSPI will is operating normally. + +#1, build U-Boot and load u-boot.bin + + => tftpboot 40000000 u-boot.bin + sh_eth Waiting for PHY auto negotiation to complete.. done + sh_eth: 100Base/Half + Using sh_eth device + TFTP from server 192.168.169.1; our IP address is 192.168.169.79 + Filename 'u-boot.bin'. + Load address: 0x40000000 + Loading: ############ + 2.5 MiB/s + done + Bytes transferred = 175364 (2ad04 hex) + +#2, Commands to erase/write u-boot to flash device + + Note: This method is description of the lager board. If you want to use the + other boards, please change the value according to each environment. + + => sf probe 0 + SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 64 KiB, total 64 MiB + => sf erase 80000 40000 + SF: 262144 bytes @ 0x80000 Erased: OK + => sf write 40000000 80000 175364 + SF: 1528676 bytes @ 0x80000 Written: OK + => + +#3, Push reset button. + + If you're written correctly and driver works properly, U-Boot starts. diff --git a/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test new file mode 100644 index 000000000..8fbf10b57 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_am43x_test @@ -0,0 +1,76 @@ +Testing details- +---------------- + +This doc simply illustrated the testing details of qspi flash +driver with Macronix M25L51235 flash device. + +The test includes +- probing the flash device +- erasing the flash device +- Writing to flash +- Reading the contents of the flash. + +Test Log +-------- + +Hit any key to stop autoboot: 0 +U-Boot# sf probe 0 +SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000 +U-Boot# sf erase 0 0x80000 +SF: 524288 bytes @ 0x0 Erased: OK +U-Boot# mw 81000000 0xdededede 0x40000 +U-Boot# sf write 81000000 0 0x40000 +SF: 262144 bytes @ 0x0 Written: OK +U-Boot# sf read 82000000 0 0x40000 +SF: 262144 bytes @ 0x0 Read: OK +U-Boot# md 0x82000000 +82000000: dededede dededede dededede dededede ................ +82000010: dededede dededede dededede dededede ................ +82000020: dededede dededede dededede dededede ................ +82000030: dededede dededede dededede dededede ................ +82000040: dededede dededede dededede dededede ................ +82000050: dededede dededede dededede dededede ................ +82000060: dededede dededede dededede dededede ................ +82000070: dededede dededede dededede dededede ................ +82000080: dededede dededede dededede dededede ................ +82000090: dededede dededede dededede dededede ................ +820000a0: dededede dededede dededede dededede ................ +820000b0: dededede dededede dededede dededede ................ +820000c0: dededede dededede dededede dededede ................ +820000d0: dededede dededede dededede dededede ................ +820000e0: dededede dededede dededede dededede ................ +820000f0: dededede dededede dededede dededede ................ +U-Boot# md 0x82010000 +82010000: dededede dededede dededede dededede ................ +82010010: dededede dededede dededede dededede ................ +82010020: dededede dededede dededede dededede ................ +82010030: dededede dededede dededede dededede ................ +82010040: dededede dededede dededede dededede ................ +82010050: dededede dededede dededede dededede ................ +82010060: dededede dededede dededede dededede ................ +82010070: dededede dededede dededede dededede ................ +82010080: dededede dededede dededede dededede ................ +82010090: dededede dededede dededede dededede ................ +820100a0: dededede dededede dededede dededede ................ +820100b0: dededede dededede dededede dededede ................ +820100c0: dededede dededede dededede dededede ................ +820100d0: dededede dededede dededede dededede ................ +820100e0: dededede dededede dededede dededede ................ +820100f0: dededede dededede dededede dededede ................ +U-Boot# md 0x82030000 +82030000: dededede dededede dededede dededede ................ +82030010: dededede dededede dededede dededede ................ +82030020: dededede dededede dededede dededede ................ +82030030: dededede dededede dededede dededede ................ +82030040: dededede dededede dededede dededede ................ +82030050: dededede dededede dededede dededede ................ +82030060: dededede dededede dededede dededede ................ +82030070: dededede dededede dededede dededede ................ +82030080: dededede dededede dededede dededede ................ +82030090: dededede dededede dededede dededede ................ +820300a0: dededede dededede dededede dededede ................ +820300b0: dededede dededede dededede dededede ................ +820300c0: dededede dededede dededede dededede ................ +820300d0: dededede dededede dededede dededede ................ +820300e0: dededede dededede dededede dededede ................ +820300f0: dededede dededede dededede dededede ................ diff --git a/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test new file mode 100644 index 000000000..fe3785723 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_dra_test @@ -0,0 +1,48 @@ +------------------------------------------------- + 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 new file mode 100644 index 000000000..1b86d01a0 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/README.ti_qspi_flash @@ -0,0 +1,47 @@ +QSPI U-boot support +------------------ + +Host processor is connected to serial flash device via qpsi +interface. QSPI is a kind of spi module that allows single, +dual and quad read access to external spi devices. The module +has a memory mapped interface which provide direct interface +for accessing data form external spi devices. + +The one QSPI in the device is primarily intended for fast booting +from Quad SPI flash devices. + +Usecase +------- + +MLO/u-boot.img will be flashed from SD/MMC to the flash device +using serial flash erase and write commands. Then, switch settings +will be changed to qspi boot. Then, the ROM code will read MLO +from the predefined location in the flash, where it was flashed and +execute it after storing it in SDRAM. Then, the MLO will read +u-boot.img from flash and execute it from SDRAM. + +SPI mode +------- +SPI mode uses mtd spi framework for transfer and reception of data. +Can be used in: +1. Normal mode: use single pin for transfers +2. Dual Mode: use two pins for transfers. +3. Quad mode: use four pin for transfer + +Memory mapped read mode +----------------------- +In this, SPI controller is configured using configuration port and then +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 new file mode 100644 index 000000000..13889f545 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPI/status.txt @@ -0,0 +1,32 @@ +Status on SPI subsystem: +======================= + +SPI COMMAND (common/cmd_sf, cmd_spi): +- + +SPI FLASH (drivers/mtd/spi): +- sf_probe.c: SPI flash probing code. +- sf_ops.c: SPI flash operations code. +- sf.c: SPI flash interface, which interacts controller driver. +- Bank Address Register (Accessing flashes > 16Mbytes in 3-byte addressing) +- Added memory_mapped support for read operations. +- Common probe support for all supported flash vendors except, ramtron. +- Extended read commands support(dual read, dual IO read) +- Quad Page Program support. +- Quad Read support(quad fast read, quad IO read) +- Dual flash connection topology support(accessing two spi flash memories with single cs) +- Banking support on dual flash connection topology. + +SPI DRIVERS (drivers/spi): +- + +TODO: +- Runtime detection of spi_flash params, SFDP(if possible) +- Add support for multibus build/accessing. +- Need proper cleanups on spi_flash and drivers. + +-- +Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> +18-09-2013. +07-10-2013. +08-01-2014. diff --git a/qemu/roms/u-boot/doc/SPL/README.am335x-network b/qemu/roms/u-boot/doc/SPL/README.am335x-network new file mode 100644 index 000000000..9b63791ad --- /dev/null +++ b/qemu/roms/u-boot/doc/SPL/README.am335x-network @@ -0,0 +1,92 @@ +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 new file mode 100644 index 000000000..c77ca4300 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPL/README.omap3 @@ -0,0 +1,52 @@ +Overview of SPL on OMAP3 devices +================================ + +Introduction +------------ + +This document provides an overview of how SPL functions on OMAP3 (and related +such as am35x and am37x) processors. + +Methodology +----------- + +On these platforms the ROM supports trying a sequence of boot devices. Once +one has been used successfully to load SPL this information is stored in memory +and the location stored in a register. We will read this to determine where to +read U-Boot from in turn. + +Memory Map +---------- + +This is an example of a typical setup. See top-level README for documentation +of which CONFIG variables control these values. For a given board and the +amount of DRAM available to it different values may need to be used. +Note that the size of the SPL text rodata and data is enforced with a CONFIG +option and growing over that size results in a link error. The SPL stack +starts at the top of SRAM (which is configurable) and grows downward. The +space between the top of SRAM and the enforced upper bound on the size of the +SPL text, data and rodata is considered the safe stack area. Details on +confirming this behavior are shown below. + +A portion of the system memory map looks as follows: +SRAM: 0x40200000 - 0x4020FFFF +DDR1: 0x80000000 - 0xBFFFFFFF + +Option 1 (SPL only): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x80000000 - 0x8007FFFF: Area for the SPL BSS. +0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot +0x80208000 - 0x80307FFF: malloc() pool available to SPL. + +Option 2 (SPL or X-Loader): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot +0x87000000 - 0x8707FFFF: Area for the SPL BSS. +0x87080000 - 0x870FFFFF: malloc() pool available to SPL. + +For the areas that reside within DDR1 they must not be used prior to s_init() +completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL +uses while running. This is why we have two versions of the memory map that +only vary in where the BSS and malloc pool reside. diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/README b/qemu/roms/u-boot/doc/device-tree-bindings/README new file mode 100644 index 000000000..2ea3439a1 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/README @@ -0,0 +1,17 @@ +Device Tree Bindings Staging Area +================================= + +This directory contains device tree bindings for U-Boot. + +These follow along with Linux kernel bindings, with a few additions. By +adding the files here, U-Boot patches can clearly show thees additions. +This makes it easier for device tree people to review these additions in +patches sent to the U-Boot mailing list. + +The intent IS to commit these files to U-Boot. Hopefully at some point +the files will be stored in another repo (shared with Linux) which is +brought in as needed. Changes here are intended to mirror changes in the +Linux Documentation/devicetree/bindings/ directory. + +sjg@chromium.org +17-Jan-12 diff --git a/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 new file mode 100644 index 000000000..5c07fcaed --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt @@ -0,0 +1,207 @@ +NVIDIA Tegra20 Clock And Reset Controller + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible +for muxing and gating Tegra's clocks, and setting their rates. + +Required properties : +- compatible : Should be "nvidia,tegra20-car" +- reg : Should contain CAR registers location and length +- clocks : Should contain phandle and clock specifiers for two clocks: + the 32 KHz "32k_in", and the board-specific oscillator "osc". +- #clock-cells : Should be 1. + In clock consumers, this cell represents the clock ID exposed by the CAR. + + The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB + registers. These IDs often match those in the CAR's RST_DEVICES registers, + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In + this case, those clocks are assigned IDs above 95 in order to highlight + this issue. Implementations that interpret these clock IDs as bit values + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to + explicitly handle these special cases. + + The balance of the clocks controlled by the CAR are assigned IDs of 96 and + above. + + 0 cpu + 1 unassigned + 2 unassigned + 3 ac97 + 4 rtc + 5 tmr + 6 uart1 + 7 unassigned (register bit affects uart2 and vfir) + 8 gpio + 9 sdmmc2 + 10 unassigned (register bit affects spdif_in and spdif_out) + 11 i2s1 + 12 i2c1 + 13 ndflash + 14 sdmmc1 + 15 sdmmc4 + 16 twc + 17 pwm + 18 i2s2 + 19 epp + 20 unassigned (register bit affects vi and vi_sensor) + 21 2d + 22 usbd + 23 isp + 24 3d + 25 ide + 26 disp2 + 27 disp1 + 28 host1x + 29 vcp + 30 unassigned + 31 cache2 + + 32 mem + 33 ahbdma + 34 apbdma + 35 unassigned + 36 kbc + 37 stat_mon + 38 pmc + 39 fuse + 40 kfuse + 41 sbc1 + 42 snor + 43 spi1 + 44 sbc2 + 45 xio + 46 sbc3 + 47 dvc + 48 dsi + 49 unassigned (register bit affects tvo and cve) + 50 mipi + 51 hdmi + 52 csi + 53 tvdac + 54 i2c2 + 55 uart3 + 56 unassigned + 57 emc + 58 usb2 + 59 usb3 + 60 mpe + 61 vde + 62 bsea + 63 bsev + + 64 speedo + 65 uart4 + 66 uart5 + 67 i2c3 + 68 sbc4 + 69 sdmmc3 + 70 pcie + 71 owr + 72 afi + 73 csite + 74 unassigned + 75 avpucq + 76 la + 77 unassigned + 78 unassigned + 79 unassigned + 80 unassigned + 81 unassigned + 82 unassigned + 83 unassigned + 84 irama + 85 iramb + 86 iramc + 87 iramd + 88 cram2 + 89 audio_2x a/k/a audio_2x_sync_clk + 90 clk_d + 91 unassigned + 92 sus + 93 cdev1 + 94 cdev2 + 95 unassigned + + 96 uart2 + 97 vfir + 98 spdif_in + 99 spdif_out + 100 vi + 101 vi_sensor + 102 tvo + 103 cve + 104 osc + 105 clk_32k a/k/a clk_s + 106 clk_m + 107 sclk + 108 cclk + 109 hclk + 110 pclk + 111 blink + 112 pll_a + 113 pll_a_out0 + 114 pll_c + 115 pll_c_out1 + 116 pll_d + 117 pll_d_out0 + 118 pll_e + 119 pll_m + 120 pll_m_out1 + 121 pll_p + 122 pll_p_out1 + 123 pll_p_out2 + 124 pll_p_out3 + 125 pll_p_out4 + 126 pll_s + 127 pll_u + 128 pll_x + 129 cop a/k/a avp + 130 audio a/k/a audio_sync_clk + +Example SoC include file: + +/ { + tegra_car: clock@60006000 { + compatible = "nvidia,tegra20-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + }; + + usb@c5004000 { + clocks = <&tegra_car 58>; /* usb2 */ + }; +}; + +Example board file: + +/ { + clocks { + #address-cells = <1>; + #size-cells = <0>; + + osc: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <12000000>; + }; + }; + + i2c@7000d000 { + pmic@34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + + clk_32k: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + }; + }; + + &tegra_car { + clocks = <&clk_32k> <&osc>; + }; +}; diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt new file mode 100644 index 000000000..566da3b63 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/dwmmc.txt @@ -0,0 +1,54 @@ +* 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 new file mode 100644 index 000000000..b8086e82b --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/isp-spi.txt @@ -0,0 +1,22 @@ +Exynos ISP SPI Subsystem + +The device node for ISP SPI subsytem. +Since Peripheral id in EXYNOS is decoded based on Interrupts, currently +ISP SPI have no individual interrupts hence we add ad dummy interrupt node +which will have a value beyond the maximum number of interrupts exynos5 can +support. + +Required properties : + - compatible : Should be "samsung,exynos-spi" for spi. + - reg : Base adrress of the the subsystem. + - interrupts : A value which is beyond the maximum number of interrupts +exynos5 can support. + +Example: +spi@131a0000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "samsung,exynos-spi"; + reg = <0x131a0000 0x30>; + interrupts = <0 129 0>; +}; diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt new file mode 100644 index 000000000..98d1798d0 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/sound.txt @@ -0,0 +1,27 @@ +Exynos Sound Subsystem + +The device node for sound subsytem which contains codec and i2s block +that is a part of Exynos5250 + +Required properties : + - compatible : Should be "samsung,exynos-sound" for sound + - samsung,i2s-epll-clock-frequency : epll clock output frequency in Hz + - samsung,i2s-sampling-rate : sampling rate, default is 48000 + - samsung,i2s-bits-per-sample : sample width, defalut is 16 bit + - samsung,i2s-channels : nummber of channels, default is 2 + - samsung,i2s-lr-clk-framesize : lr clock frame size + - samsung,i2s-bit-clk-framesize : bit clock frame size + - samsung,codec-type : sound codec type + +Example: + +sound@12d60000 { + compatible = "samsung,exynos-sound" + samsung,i2s-epll-clock-frequency = <192000000>; + samsung,i2s-sampling-rate = <48000>; + samsung,i2s-bits-per-sample = <16>; + samsung,i2s-channels = <2>; + samsung,i2s-lr-clk-framesize = <256>; + samsung,i2s-bit-clk-framesize = <32>; + samsung,codec-type = "wm8994"; +}; diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt new file mode 100644 index 000000000..89d3bf05f --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/exynos/tmu.txt @@ -0,0 +1,44 @@ +Exynos Thermal management Unit + +Required properties: + + - compatible : Should be "samsung,exynos-tmu" for TMU + - samsung,min-temp : Minimum temperature value (25 degree celsius) + - Current temperature of SoC should be more than this value. + - samsung,max-temp : Maximum temperature value (125 degree celsius) + - Current temperature of SoC should be less than this value. + - samsung,start-warning : Temperature at which TMU starts giving warning (degree celsius) + - samsung,start-tripping : Temperature at which TMU shuts down the system (degree celsius) + - samsung,hw-tripping : Temperature at which hardware tripping should happen + in case TMU fails to power off (degree celsius) + - samsung,efuse-min-value : SOC efuse min value (Constant 40) + - efuse-value should be more than this value. + - samsung,efuse-value : SOC actual efuse value (Literal value) + - This is the data trimming info. + - This value is used to calculate measuring error. + - samsung,efuse-max-value : SoC max efuse value (Constant 100) + - efuse-value should be less than this value. + - samsung,slope : Default value 274761730 (Constant 0x1060_8802). + - This is the default value for TMU_CONTROL register. + - It sets the gain of amplifier to the positive-tc generator block. + - It selects thermal tripping mode and enables thermal tripping. + - samsung,dc-value : Measured data calibration value (Constant 25) + - Used for tempearture calculation. + - This is 25 because temperature measured is always above 25 degrees. + + +Example: + +tmu@10060000 { + compatible = "samsung,exynos-tmu" + samsung,min-temp = <25>; + samsung,max-temp = <125>; + samsung,start-warning = <95>; + samsung,start-tripping = <105>; + samsung,hw-tripping = <110>; + samsung,efuse-min-value = <40>; + samsung,efuse-value = <55>; + samsung,efuse-max-value = <100>; + samsung,slope = <274761730>; + samsung,dc-value = <25>; +}; diff --git a/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 new file mode 100644 index 000000000..72649dffa --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/i2c/tegra20-i2c.txt @@ -0,0 +1,23 @@ +(Placeholder note while we locate the kernel Tegra20 bindings) + +Added in U-Boot: + +Required properties: + - clocks : Two clocks must be given, each as a phandle to the Tegra's + CAR node and the clock number as a parameter: + - the I2C clock to use for the peripheral + - the pll_p_out3 clock, which can be used for fast operation. This + does not change and is the same for all I2C nodes. + +Example: +(TODO: merge with existing example): + + i2c@7000c400 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "nvidia,tegra20-i2c"; + reg = <0x7000C400 0x100>; + interrupts = < 116 >; + /* PERIPH_ID_I2C2, PLL_P_OUT3 */ + clocks = <&tegra_car 54>, <&tegra_car 124>; + }; diff --git a/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 new file mode 100644 index 000000000..311827607 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/input/cros-ec-keyb.txt @@ -0,0 +1,79 @@ +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 new file mode 100644 index 000000000..07ea7cdea --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/misc/cros-ec.txt @@ -0,0 +1,38 @@ +Chrome OS CROS_EC Binding +====================== + +The device tree node which describes the operation of the CROS_EC interface +is as follows: + +Required properties : +- compatible = "google,cros-ec" + +Optional properties : +- spi-max-frequency : Sets the maximum frequency (in Hz) for SPI bus + operation +- i2c-max-frequency : Sets the maximum frequency (in Hz) for I2C bus + operation +- ec-interrupt : Selects the EC interrupt, defined as a GPIO according + to the platform +- optimise-flash-write : Boolean property - if present then flash blocks + containing all 0xff will not be written, since we assume that the EC + uses that pattern for erased blocks + +The CROS_EC node should appear as a subnode of the interrupt that connects it +to the EC (e.g. i2c, spi, lpc). The reg property (as usual) will indicate +the unit address on that bus. + + +Example +======= + + spi@131b0000 { + cros-ec@0 { + reg = <0>; + compatible = "google,cros-ec"; + spi-max-frequency = <5000000>; + ec-interrupt = <&gpio 174 1>; + optimise-flash-write; + status = "disabled"; + }; + }; diff --git a/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 new file mode 100644 index 000000000..86ae4082d --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt @@ -0,0 +1,53 @@ +NAND Flash +---------- + +(there isn't yet a generic binding in Linux, so this describes what is in +U-Boot. There should not be Linux-specific or U-Boot specific binding, just +a binding that describes this hardware. But agreeing a binding in Linux in +the absence of a driver may be beyond my powers.) + +The device node for a NAND flash device is as follows: + +Required properties : + - compatible : Should be "manufacturer,device", "nand-flash" + +This node should sit inside its controller. + + +Nvidia NAND Controller +---------------------- + +The device node for a NAND flash controller is as follows: + +Optional properties: + +nvidia,wp-gpios : GPIO of write-protect line, three cells in the format: + phandle, parameter, flags +nvidia,nand-width : bus width of the NAND device in bits + + - nvidia,nand-timing : Timing parameters for the NAND. Each is in ns. + Order is: MAX_TRP_TREA, TWB, Max(tCS, tCH, tALS, tALH), + TWHR, Max(tCS, tCH, tALS, tALH), TWH, TWP, TRH, TADL + + MAX_TRP_TREA is: + non-EDO mode: Max(tRP, tREA) + 6ns + EDO mode: tRP timing + +The 'reg' property should provide the chip select used by the flash chip. + + +Example +------- + +nand-controller@0x70008000 { + compatible = "nvidia,tegra20-nand"; + #address-cells = <1>; + #size-cells = <0>; + nvidia,wp-gpios = <&gpio 59 0>; /* PH3 */ + nvidia,nand-width = <8>; + nvidia,timing = <26 100 20 80 20 10 12 10 70>; + nand@0 { + reg = <0>; + compatible = "hynix,hy27uf4g2b", "nand-flash"; + }; +}; diff --git a/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 new file mode 100644 index 000000000..01438ecd6 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/pwm/tegra20-pwm.txt @@ -0,0 +1,18 @@ +Tegra SoC PWFM controller + +Required properties: +- compatible: should be one of: + - "nvidia,tegra20-pwm" + - "nvidia,tegra30-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The + first cell specifies the per-chip index of the PWM to use and the second + cell is the period in nanoseconds. + +Example: + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + }; diff --git a/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 new file mode 100644 index 000000000..800dafe5b --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/spi/spi-bus.txt @@ -0,0 +1,92 @@ +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 new file mode 100644 index 000000000..5282d44ac --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/usb/tegra-usb.txt @@ -0,0 +1,25 @@ +Tegra SOC USB controllers + +The device node for a USB controller that is part of a Tegra +SOC is as described in the document "Open Firmware Recommended +Practice : Universal Serial Bus" with the following modifications +and additions : + +Required properties : + - compatible : Should be "nvidia,tegra20-ehci" for USB controllers + used in host mode. + - phy_type : Should be one of "ulpi" or "utmi". + - nvidia,vbus-gpio : If present, specifies a gpio that needs to be + activated for the bus to be powered. + +Optional properties: + - dr_mode : dual role mode. Indicates the working mode for + nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral", + or "otg". Default to "host" if not defined for backward compatibility. + host means this is a host controller + peripheral means it is device controller + otg means it can operate as either ("on the go") + - nvidia,has-legacy-mode : boolean indicates whether this controller can + operate in legacy mode (as APX 2500 / 2600). In legacy mode some + registers are accessed through the APB_MISC base address instead of + the USB controller. diff --git a/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt b/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt new file mode 100644 index 000000000..45ca42db5 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/displaymode.txt @@ -0,0 +1,42 @@ +videomode bindings +================== + +(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html) + +Required properties: + - xres, yres: Display resolution + - left-margin, right-margin, hsync-len: Horizontal Display timing + parameters in pixels + - upper-margin, lower-margin, vsync-len: Vertical display timing + parameters in lines + - clock: display clock in Hz + +Optional properties: + - width-mm, height-mm: Display dimensions in mm + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high + - interlaced (bool): This is an interlaced mode + - doublescan (bool): This is a doublescan mode + +There are different ways of describing a display mode. The devicetree +representation corresponds to the one used by the Linux Framebuffer +framework described here in Documentation/fb/framebuffer.txt. This +representation has been chosen because it's the only format which does +not allow for inconsistent parameters. Unlike the Framebuffer framework +the devicetree has the clock in Hz instead of ps. + +Example: + + display@0 { + /* 1920x1080p24 */ + clock = <52000000>; + xres = <1920>; + yres = <1080>; + left-margin = <25>; + right-margin = <25>; + hsync-len = <25>; + lower-margin = <2>; + upper-margin = <2>; + vsync-len = <2>; + hsync-active-high; + }; diff --git a/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 new file mode 100644 index 000000000..464a85302 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-dp.txt @@ -0,0 +1,69 @@ +Exynos Display port controller +============================== + +Required properties: +SOC specific: + compatible: should be "samsung,exynos5-dp" + reg: Base address of DP IP + +Optional properties: + samsung,h-res: X resolution of the panel + samsung,h-sync-width: hsync value + samsung,h-back-porch: left margin + samsung,h-front-porch right margin + samsung,v-res: Y resolution of the panel + samsung,v-sync-width: vsync value + samsung,v-back-porch: upper margin + samsung,v-front-porch: lower margin + samsung,v-sync-rate: refresh rate + + samsung,lt-status: Link training status + 0(DP_LT_NONE), 1(DP_LT_START), 2(DP_LT_CR), 3(DP_LT_ET), + 4(DP_LT_FINISHED), 5(DP_LT_FAIL) + + samsung,master-mode: 1 if you want to run DP as master, else 0 + samsung,bist-mode: 1 to enable video bist mode, else 0 + samsung,bist-pattern: bist mode pattern type + 0(NO_PATTERN), 1(COLOR_RAMP), 2(BALCK_WHITE_V_LINES), + 3(COLOR_SQUARE), 4(INVALID_PATTERN), 5(COLORBAR_32), + 6(COLORBAR_64),7(WHITE_GRAY_BALCKBAR_32), + 8(WHITE_GRAY_BALCKBAR_64),9(MOBILE_WHITEBAR_32), + 10(MOBILE_WHITEBAR_64) + samsung,h-sync-polarity: Horizontal Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,v-sync-polarity: Vertical Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,interlaced: Progressive if 0, else Interlaced + samsung,color-space: input video data format + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + samsung,dynamic-range: dynamic range for input video data + VESA = 0, CEA = 1 + samsung,ycbcr-coeff: YCbCr co-efficients for input video + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 + samsung,color-depth: number of bits per colour component + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 + +Example: +SOC specific part: + dp@145b0000 { + compatible = "samsung,exynos5-dp"; + reg = <0x145b0000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + }; + +Board(panel) specific part: + dp@145b0000 { + samsung,lt-status = <0>; + + samsung,master-mode = <0>; + samsung,bist-mode = <0>; + samsung,bist-pattern = <0>; + samsung,h-sync-polarity = <0>; + samsung,v-sync-polarity = <0>; + samsung,interlaced = <0>; + samsung,color-space = <0>; + samsung,dynamic-range = <0>; + samsung,ycbcr-coeff = <0>; + samsung,color-depth = <1>; + }; diff --git a/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 new file mode 100644 index 000000000..bb7441cbb --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos-fb.txt @@ -0,0 +1,92 @@ +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 new file mode 100644 index 000000000..4938ea01e --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/exynos_mipi_dsi.txt @@ -0,0 +1,82 @@ +Exynos MIPI-DSIM Controller +========================= + +Required properties: +SOC specific: + compatible: should be "samsung,exynos-mipi-dsi" + reg: Base address of MIPI-DSIM IP. + +Board specific: + samsung,dsim-config-e-interface: interface to be used (RGB interface + for main display or CPU interface for main or sub display). + samsung,dsim-config-e-virtual-ch: virtual channel number that main + or sub display uses. + samsung,dsim-config-e-pixel-format: pixel stream format for main + or sub display. + samsung,dsim-config-e-burst-mode: selects Burst mode in Video mode. + in Non-burst mode, RGB data area is filled with RGB data and + NULL packets, according to input bandwidth of RGB interface. + samsung,dsim-config-e-no-data-lane: data lane count used by Master. + samsung,dsim-config-e-byte-clk: select byte clock source. + It must be DSIM_PLL_OUT_DIV8. + DSIM_EXT_CLK_DIV8 and DSIM_EXT_CLK_BYPASSS are not supported. + samsung,dsim-config-hfp: HFP disable mode. + If set, DSI master ignores HFP area in VIDEO mode. + In command mode, this variable is ignored. + samsung,dsim-config-p: P value for PMS setting. + samsung,dsim-config-m: M value for PMS setting. + samsung,dsim-config-s: S value for PMS setting. + samsung,dsim-config-pll-stable-time: the PLL Timer for stability + of the ganerated clock. + samsung,dsim-config-esc-clk: escape clock frequency for getting + the escape clock prescaler value. + samsung,dsim-config-stop-holding-cnt: the interval value between + transmitting read packet (or write "set_tear_on" command) + and BTA request. After transmitting read packet or write + "set_tear_on" command, BTA requests to D-PHY automatically. + This counter value specifies the interval between them. + samsung,dsim-config-bta-timeout: the timer for BTA. This register + specifies time out from BTA request to change the direction + with respect to Tx escape clock. + samsung,dsim-config-rx-timeout: the timer for LP Rx mode timeout. + this register specifies time out on how long RxValid deasserts, + after RxLpdt asserts with respect to Tx escape clock. + - RxValid specifies Rx data valid indicator. + - RxLpdt specifies an indicator that D-PHY is under RxLpdt mode + - RxValid and RxLpdt specifies signal from D-PHY. + samsung,dsim-device-name: name of the device. + samsung,dsim-device-id: unique device id. + samsung,dsim-device-bus_id: bus id for identifing connected bus + and this bus id should be same as id of mipi_dsim_device. + +Optional properties: + samsung,dsim-device-reverse-panel: reverse panel. + +Example: + mipidsi@11c80000 { + compatible = "samsung,exynos-mipi-dsi"; + reg = <0x11c80000 0x5c>; + + samsung,dsim-config-e-interface = <1>; + samsung,dsim-config-e-virtual-ch = <0>; + samsung,dsim-config-e-pixel-format = <7>; + samsung,dsim-config-e-burst-mode = <1>; + samsung,dsim-config-e-no-data-lane = <3>; + samsung,dsim-config-e-byte-clk = <0>; + samsung,dsim-config-hfp = <1>; + + samsung,dsim-config-p = <3>; + samsung,dsim-config-m = <120>; + samsung,dsim-config-s = <1>; + + samsung,dsim-config-pll-stable-time = <500>; + samsung,dsim-config-esc-clk = <20000000>; + samsung,dsim-config-stop-holding-cnt = <0x7ff>; + samsung,dsim-config-bta-timeout = <0xff>; + samsung,dsim-config-rx-timeout = <0xffff>; + + samsung,dsim-device-id = <0xffffffff>; + samsung,dsim-device-bus-id = <0>; + + samsung,dsim-device-reverse-panel = <1>; + }; diff --git a/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 new file mode 100644 index 000000000..eb91b30e3 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/sandbox-fb.txt @@ -0,0 +1,13 @@ +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 new file mode 100644 index 000000000..3ea460583 --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/simple-framebuffer.txt @@ -0,0 +1,25 @@ +Simple Framebuffer + +A simple frame-buffer describes a raw memory region that may be rendered to, +with the assumption that the display hardware has already been set up to scan +out from that buffer. + +Required properties: +- compatible: "simple-framebuffer" +- reg: Should contain the location and size of the framebuffer memory. +- width: The width of the framebuffer in pixels. +- height: The height of the framebuffer in pixels. +- stride: The number of bytes in each line of the framebuffer. +- format: The format of the framebuffer surface. Valid values are: + - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). + +Example: + + framebuffer { + compatible = "simple-framebuffer"; + reg = <0x1d385000 (1600 * 1200 * 2)>; + width = <1600>; + height = <1200>; + stride = <(1600 * 2)>; + format = "r5g6b5"; + }; diff --git a/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 new file mode 100644 index 000000000..4731c3fba --- /dev/null +++ b/qemu/roms/u-boot/doc/device-tree-bindings/video/tegra20-dc.txt @@ -0,0 +1,85 @@ +Display Controller +------------------ + +(there isn't yet a generic binding in Linux, so this describes what is in +U-Boot, and may change based on Linux activity) + +The device node for a display device is as described in the document +"Open Firmware Recommended Practice : Universal Serial Bus" with the +following modifications and additions : + +Required properties : + - compatible : Should be "nvidia,tegra20-dc" + +Required subnode 'rgb' is as follows: + +Required properties (rgb) : + - nvidia,panel : phandle of LCD panel information + + +The panel node describes the panel itself. This has the properties listed in +displaymode.txt as well as: + +Required properties (panel) : + - nvidia,bits-per-pixel: number of bits per pixel (depth) + - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt) + - nvidia,panel-timings: 4 cells containing required timings in ms: + * delay before asserting panel_vdd + * delay between panel_vdd-rise and data-rise + * delay between data-rise and backlight_vdd-rise + * delay between backlight_vdd and pwm-rise + * delay between pwm-rise and backlight_en-rise + +Optional GPIO properies all have (phandle, GPIO number, flags): + - nvidia,backlight-enable-gpios: backlight enable GPIO + - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO + - nvidia,backlight-vdd-gpios: backlight power GPIO + - nvidia,panel-vdd-gpios: panel power GPIO + +Example: + +host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + status = "okay"; + + ranges = <0x54000000 0x54000000 0x04000000>; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + status = "okay"; + + rgb { + status = "okay"; + nvidia,panel = <&lcd_panel>; + }; + }; +}; + +lcd_panel: panel { + /* Seaboard has 1366x768 */ + clock = <70600000>; + xres = <1366>; + yres = <768>; + left-margin = <58>; + right-margin = <58>; + hsync-len = <58>; + lower-margin = <4>; + upper-margin = <4>; + vsync-len = <4>; + hsync-active-high; + nvidia,bits-per-pixel = <16>; + nvidia,pwm = <&pwm 2 0>; + nvidia,backlight-enable-gpios = <&gpio 28 0>; /* PD4 */ + nvidia,lvds-shutdown-gpios = <&gpio 10 0>; /* PB2 */ + nvidia,backlight-vdd-gpios = <&gpio 176 0>; /* PW0 */ + nvidia,panel-vdd-gpios = <&gpio 22 0>; /* PC6 */ + nvidia,panel-timings = <400 4 203 17 15>; +}; diff --git a/qemu/roms/u-boot/doc/driver-model/README.txt b/qemu/roms/u-boot/doc/driver-model/README.txt new file mode 100644 index 000000000..e0b395a61 --- /dev/null +++ b/qemu/roms/u-boot/doc/driver-model/README.txt @@ -0,0 +1,368 @@ +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 new file mode 100644 index 000000000..16819c775 --- /dev/null +++ b/qemu/roms/u-boot/doc/feature-removal-schedule.txt @@ -0,0 +1,43 @@ +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 new file mode 100644 index 000000000..251586e05 --- /dev/null +++ b/qemu/roms/u-boot/doc/git-mailrc @@ -0,0 +1,112 @@ +# 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 new file mode 100644 index 000000000..6c99b1c15 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/command_syntax_extensions.txt @@ -0,0 +1,191 @@ +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 new file mode 100644 index 000000000..526be55a5 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/howto.txt @@ -0,0 +1,297 @@ +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 new file mode 100644 index 000000000..ef3ab8f72 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/kernel.its @@ -0,0 +1,37 @@ +/* + * 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 new file mode 100644 index 000000000..7e940d2af --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/kernel_fdt.its @@ -0,0 +1,51 @@ +/* + * Simple U-boot uImage source file containing a single kernel and FDT blob + */ + +/dts-v1/; + +/ { + description = "Simple image with single Linux kernel and FDT blob"; + #address-cells = <1>; + + images { + kernel@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 new file mode 100644 index 000000000..881b74952 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/multi.its @@ -0,0 +1,133 @@ +/* + * U-boot uImage source file with multiple kernels, ramdisks and FDT blobs + */ + +/dts-v1/; + +/ { + description = "Various kernels, ramdisks and FDT blobs"; + #address-cells = <1>; + + images { + kernel@1 { + description = "vanilla-2.6.23"; + data = /incbin/("./vmlinux.bin.gz"); + type = "kernel"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash@1 { + algo = "md5"; + }; + hash@2 { + algo = "sha1"; + }; + }; + + kernel@2 { + description = "2.6.23-denx"; + data = /incbin/("./2.6.23-denx.bin.gz"); + type = "kernel"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash@1 { + algo = "sha1"; + }; + }; + + kernel@3 { + description = "2.4.25-denx"; + data = /incbin/("./2.4.25-denx.bin.gz"); + type = "kernel"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash@1 { + algo = "md5"; + }; + }; + + ramdisk@1 { + description = "eldk-4.2-ramdisk"; + data = /incbin/("./eldk-4.2-ramdisk"); + type = "ramdisk"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash@1 { + algo = "sha1"; + }; + }; + + ramdisk@2 { + description = "eldk-3.1-ramdisk"; + data = /incbin/("./eldk-3.1-ramdisk"); + type = "ramdisk"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash@1 { + algo = "crc32"; + }; + }; + + fdt@1 { + description = "tqm5200-fdt"; + data = /incbin/("./tqm5200.dtb"); + type = "flat_dt"; + arch = "ppc"; + compression = "none"; + hash@1 { + algo = "crc32"; + }; + }; + + fdt@2 { + description = "tqm5200s-fdt"; + data = /incbin/("./tqm5200s.dtb"); + type = "flat_dt"; + arch = "ppc"; + compression = "none"; + load = <00700000>; + hash@1 { + algo = "sha1"; + }; + }; + + }; + + configurations { + default = "config@1"; + + config@1 { + description = "tqm5200 vanilla-2.6.23 configuration"; + kernel = "kernel@1"; + ramdisk = "ramdisk@1"; + fdt = "fdt@1"; + }; + + config@2 { + description = "tqm5200s denx-2.6.23 configuration"; + kernel = "kernel@2"; + ramdisk = "ramdisk@1"; + fdt = "fdt@2"; + }; + + config@3 { + description = "tqm5200s denx-2.4.25 configuration"; + kernel = "kernel@3"; + ramdisk = "ramdisk@2"; + }; + }; +}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its b/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its new file mode 100644 index 000000000..3c17f040d --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/sign-configs.its @@ -0,0 +1,45 @@ +/dts-v1/; + +/ { + description = "Chrome OS kernel image with one or more FDT blobs"; + #address-cells = <1>; + + images { + kernel@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 new file mode 100644 index 000000000..f69326a39 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/sign-images.its @@ -0,0 +1,42 @@ +/dts-v1/; + +/ { + description = "Chrome OS kernel image with one or more FDT blobs"; + #address-cells = <1>; + + images { + kernel@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 new file mode 100644 index 000000000..950203770 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/signature.txt @@ -0,0 +1,400 @@ +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 new file mode 100644 index 000000000..9ed6f65e5 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/source_file_format.txt @@ -0,0 +1,261 @@ +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 new file mode 100644 index 000000000..a6eaef691 --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/update3.its @@ -0,0 +1,44 @@ +/* + * Example Automatic software update file. + */ + +/dts-v1/; + +/ { + description = "Automatic software updates: kernel, ramdisk, FDT"; + #address-cells = <1>; + + images { + update@1 { + description = "Linux kernel binary"; + data = /incbin/("./vmlinux.bin.gz"); + compression = "none"; + type = "firmware"; + load = <FF700000>; + hash@1 { + algo = "sha1"; + }; + }; + update@2 { + description = "Ramdisk image"; + data = /incbin/("./ramdisk_image.gz"); + compression = "none"; + type = "firmware"; + load = <FF8E0000>; + hash@1 { + algo = "sha1"; + }; + }; + + update@3 { + description = "FDT blob"; + data = /incbin/("./blob.fdt"); + compression = "none"; + type = "firmware"; + load = <FFAC0000>; + hash@1 { + algo = "sha1"; + }; + }; + }; +}; diff --git a/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its b/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its new file mode 100644 index 000000000..846723e2d --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/update_uboot.its @@ -0,0 +1,24 @@ +/* + * Automatic software update for U-Boot + * Make sure the flashing addresses ('load' prop) is correct for your board! + */ + +/dts-v1/; + +/ { + description = "Automatic U-Boot update"; + #address-cells = <1>; + + images { + update@1 { + description = "U-Boot binary"; + data = /incbin/("./u-boot.bin"); + compression = "none"; + type = "firmware"; + load = <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 new file mode 100644 index 000000000..3c83fbc2c --- /dev/null +++ b/qemu/roms/u-boot/doc/uImage.FIT/verified-boot.txt @@ -0,0 +1,104 @@ +U-Boot Verified Boot +==================== + +Introduction +------------ +Verified boot here means the verification of all software loaded into a +machine during the boot process to ensure that it is authorised and correct +for that machine. + +Verified boot extends from the moment of system reset to as far as you wish +into the boot process. An example might be loading U-Boot from read-only +memory, then loading a signed kernel, then using the kernel's dm-verity +driver to mount a signed root filesystem. + +A key point is that it is possible to field-upgrade the software on machines +which use verified boot. Since the machine will only run software that has +been correctly signed, it is safe to read software from an updatable medium. +It is also possible to add a secondary signed firmware image, in read-write +memory, so that firmware can easily be upgraded in a secure manner. + + +Signing +------- +Verified boot uses cryptographic algorithms to 'sign' software images. +Images are signed using a private key known only to the signer, but can +be verified using a public key. As its name suggests the public key can be +made available without risk to the verification process. The private and +public keys are mathematically related. For more information on how this +works look up "public key cryptography" and "RSA" (a particular algorithm). + +The signing and verification process looks something like this: + + + Signing Verification + ======= ============ + + +--------------+ * + | RSA key pair | * +---------------+ + | .key .crt | * | Public key in | + +--------------+ +------> public key ----->| trusted place | + | | * +---------------+ + | | * | + v | * v + +---------+ | * +--------------+ + | |----------+ * | | + | signer | * | U-Boot | + | |----------+ * | signature |--> yes/no + +---------+ | * | verification | + ^ | * | | + | | * +--------------+ + | | * ^ + +----------+ | * | + | Software | +----> signed image -------------+ + | image | * + +----------+ * + + +The signature algorithm relies only on the public key to do its work. Using +this key it checks the signature that it finds in the image. If it verifies +then we know that the image is OK. + +The public key from the signer allows us to verify and therefore trust +software from updatable memory. + +It is critical that the public key be secure and cannot be tampered with. +It can be stored in read-only memory, or perhaps protected by other on-chip +crypto provided by some modern SOCs. If the public key can 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 |