summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorUwe Kleine-König <u.kleine-koenig@pengutronix.de>2016-10-04 21:13:06 +0200
committerSascha Hauer <s.hauer@pengutronix.de>2016-10-07 10:18:19 +0200
commitd66e242213320a4fed9960eee0ecc870a9e4c616 (patch)
tree572b8fbaec7659d08f3b4475da23f05e3e13bc81
parent81cabf127479e1bc8ce0cc294a19ce78d416c3ec (diff)
downloadbarebox-d66e242213320a4fed9960eee0ecc870a9e4c616.tar.gz
barebox-d66e242213320a4fed9960eee0ecc870a9e4c616.tar.xz
ARM: mvebu: document some general mvebu stuff and the rn2120 board
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
-rw-r--r--Documentation/boards/mvebu.rst50
-rw-r--r--Documentation/boards/mvebu/Netgear-ReadyNAS-2120.rst19
2 files changed, 69 insertions, 0 deletions
diff --git a/Documentation/boards/mvebu.rst b/Documentation/boards/mvebu.rst
new file mode 100644
index 000000000..b4f8e6043
--- /dev/null
+++ b/Documentation/boards/mvebu.rst
@@ -0,0 +1,50 @@
+Marvell Embedded Business Unit (mvebu)
+======================================
+
+Move of the Register Window
+---------------------------
+
+When an mvebu SoC comes up the internal registers are mapped at 0xd0000000 in
+the address space. To make it possible to have more than 3.25 GiB of continuous
+RAM in Linux this window is moved to 0xf1000000.
+Unfortunately the register to configure the location of the registers is located
+in this window, so there is no way to determine the location afterwards.
+
+RAM initialisation
+------------------
+
+Traditionally the RAM initialisation happens with a binary blob that have to be
+extracted from the vendor U-Boot::
+
+ scripts/kwbimage -x -i /dev/mtdblock0 -o .
+
+This creates among others a file "binary.0" that has to be put into the board
+directory. For license reasons this is usually not included in the barebox
+repository.
+
+Note that in the meantime U-Boot has open source code to do the RAM
+initialisation that could be taken.
+
+Booting second stage
+--------------------
+
+This is currently not possible because barebox assumes the registers are mapped
+at 0xd0000000 as is the case when the boot ROM gives control to the bootloader.
+
+Booting from UART
+-----------------
+
+The mvebu SoCs support booting from UART. For this there is a tool available in
+barebox called kwboot.
+
+mvebu boards
+------------
+
+Not all supported boards have a description here.
+
+.. toctree::
+ :glob:
+ :numbered:
+ :maxdepth: 1
+
+ mvebu/*
diff --git a/Documentation/boards/mvebu/Netgear-ReadyNAS-2120.rst b/Documentation/boards/mvebu/Netgear-ReadyNAS-2120.rst
new file mode 100644
index 000000000..5bee03af9
--- /dev/null
+++ b/Documentation/boards/mvebu/Netgear-ReadyNAS-2120.rst
@@ -0,0 +1,19 @@
+Netgear ReadyNAS 2120
+=====================
+
+This is a rack mountable 4 bay NAS using an Armada XP dual-core processor.
+
+UART booting
+------------
+
+The first UART hides behind a sticker on 4 pins.
+
+The machine seems to do two resets at power on which makes UART booting hard. A
+trick to work around this is::
+
+ scripts/kwboot -d /dev/ttyUSB0; kwboot -b images/barebox-netgear-rn2120.img -t /dev/ttyUSB0
+
+This way the first window in which the CPU accepts the magic string is taken by
+the first invokation which blocks until the second reset happens. The second
+window is then hit with the image to boot. This is not 100% reliable but works
+most of the time.