summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/DocBook/.gitignore1
-rw-r--r--doc/DocBook/Makefile28
-rw-r--r--doc/README.b4860qds36
-rw-r--r--doc/README.console3
-rw-r--r--doc/README.generic-board189
-rw-r--r--doc/README.power-framework166
-rw-r--r--doc/README.scrapyard38
-rw-r--r--doc/README.t4240qds53
-rw-r--r--doc/README.video2
-rw-r--r--doc/uImage.FIT/signature.txt20
10 files changed, 499 insertions, 37 deletions
diff --git a/doc/DocBook/.gitignore b/doc/DocBook/.gitignore
index 720f245ceb..7ebd5465d9 100644
--- a/doc/DocBook/.gitignore
+++ b/doc/DocBook/.gitignore
@@ -10,5 +10,6 @@
*.out
*.png
*.gif
+*.svg
media-indices.tmpl
media-entities.tmpl
diff --git a/doc/DocBook/Makefile b/doc/DocBook/Makefile
index 9b4a9b6762..593237f04a 100644
--- a/doc/DocBook/Makefile
+++ b/doc/DocBook/Makefile
@@ -26,6 +26,7 @@ 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
@@ -44,17 +45,18 @@ htmldocs: $(HTML)
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 doc/DocBook/man/*.9.gz /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)/doc/DocBook/stylesheet.xsl
+XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation
###
@@ -76,21 +78,9 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd
endef
-%.xml: %.tmpl FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
$(call if_changed_rule,docproc)
-###
-#Read in all saved dependency files
-cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
-
-ifneq ($(cmd_files),)
- include $(cmd_files)
-endif
-
-###
-# Changes in kernel-doc force a rebuild of all documentation
-$(BOOKS): $(KERNELDOC)
-
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -128,16 +118,16 @@ quiet_cmd_db2pdf = PDF $@
index = index.html
-main_idx = doc/DocBook/$(index)
+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 xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
+ cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
- $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+ $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
%.html: %.xml
@(which xmlto > /dev/null 2>&1) || \
@@ -149,7 +139,7 @@ quiet_cmd_db2html = HTML $@
cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
quiet_cmd_db2man = MAN $@
- cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
+ 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 ***"; \
diff --git a/doc/README.b4860qds b/doc/README.b4860qds
index 3da77d9f0f..eada0c7dd8 100644
--- a/doc/README.b4860qds
+++ b/doc/README.b4860qds
@@ -328,3 +328,39 @@ The below commands apply to both B4860QDS and B4420QDS.
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/doc/README.console b/doc/README.console
index c9ef59e9a5..aadf596a8a 100644
--- a/doc/README.console
+++ b/doc/README.console
@@ -25,7 +25,7 @@ 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 wl_kbd <- To use the wireless keyboard
+ 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
@@ -99,4 +99,3 @@ 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
-- GENIETV with AD7177 on a PAL TV (YCbYCr) - arsenio@tin.it
diff --git a/doc/README.generic-board b/doc/README.generic-board
new file mode 100644
index 0000000000..50d3a26849
--- /dev/null
+++ b/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 tranditionally 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/doc/README.power-framework b/doc/README.power-framework
new file mode 100644
index 0000000000..1f6fd43203
--- /dev/null
+++ b/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/doc/README.scrapyard b/doc/README.scrapyard
index 7d670339dd..f9742e7d49 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -11,8 +11,17 @@ easily if here is something they might want to dig for...
Board Arch CPU Commit Removed Last known maintainer/contact
=================================================================================================
-idmr m68k mcf52x2 - 2014-01-28
-M5271EVB m68k mcf52x2 - 2014-01-28
+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>
@@ -26,11 +35,15 @@ pdnb3 arm ixp 304db0b 2013-09-24 Stefan Roese
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
@@ -40,15 +53,17 @@ LANTEC powerpc mpc850 1b0757e 2012-10-28 Wolfgang Den
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 c746cdd 2011-25-11
-pleb2 arm pxa b185a1c 2011-25-11
-cradle arm pxa 4e24f8a 2011-25-11 Kyle Harris <kharris@nexus-tech.net>
-cerf250 arm pxa a3f1241 2011-25-11 Prakash Kumar <prakash@embedx.com>
+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>
@@ -87,13 +102,13 @@ B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian
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>
-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
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>
@@ -110,7 +125,4 @@ MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwar
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>
-PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de>
-PCIPPC6 powerpc MPC740/MPC750 - - Wolfgang Denk <wd@denx.de>
-omap2420h4 arm omap24xx - 2013-06-04 Richard Woodruff <r-woodruff2@ti.com>
-eNET x86 x86 7e8c53d 2013-02-14 Graeme Russ <graeme.russ@gmail.com>
+incaip mips mips32 - 2014-04-17 Wolfgang Denk <wd@denx.de>
diff --git a/doc/README.t4240qds b/doc/README.t4240qds
index a9841fb5f7..ef8c75f3b2 100644
--- a/doc/README.t4240qds
+++ b/doc/README.t4240qds
@@ -120,3 +120,56 @@ 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/doc/README.video b/doc/README.video
index f09d5f9f6b..dadbfcd2fd 100644
--- a/doc/README.video
+++ b/doc/README.video
@@ -11,8 +11,6 @@ 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
-- GENIETV with AD7177 on a PAL TV (YCbYCr) - arsenio@tin.it
-
"video-mode" environment variable
===============================
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index bc9f3fa6e1..9502037705 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -346,7 +346,9 @@ 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
@@ -355,10 +357,26 @@ 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
generated by cgit (git 2.34.1) at 2024-12-30 20:03:21 +0000