From bc2ad9f04dd9d15e7134f7e1b6386d1995772d69 Mon Sep 17 00:00:00 2001
From: Michael Walle <michael@walle.cc>
Date: Sun, 8 Feb 2015 20:06:05 +0100
Subject: [PATCH 1/4] lsxl: use default load addresses for legacy boot
The load addresses for the bootcmd_legacy script were taken from the
original bootloader from Buffalo. But newer kernels are too big and the
uncompressing will overwrite parts of the initial ramdisk. Therefore,
we switch to the load addresses which are also used by the other boot
script.
Signed-off-by: Michael Walle <michael@walle.cc>
---
include/configs/lsxl.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
index a14bfe3a85..6c8e369861 100644
--- a/include/configs/lsxl.h
+++ b/include/configs/lsxl.h
@@ -127,9 +127,9 @@
"ramdisk_addr=0x01000000\0" \
"fdt_addr=0x01ff0000\0" \
"bootcmd_legacy=ide reset " \
- "&& load ide ${hdpart} 0x00100000 /uImage.buffalo " \
- "&& load ide ${hdpart} 0x00800000 /initrd.buffalo " \
- "&& bootm 0x00100000 0x00800000\0" \
+ "&& load ide ${hdpart} ${kernel_addr} /uImage.buffalo " \
+ "&& load ide ${hdpart} ${ramdisk_addr} /initrd.buffalo "\
+ "&& bootm ${kernel_addr} ${ramdisk_addr}\0" \
"bootcmd_net=bootp ${kernel_addr} uImage " \
"&& tftpboot ${ramdisk_addr} uInitrd " \
"&& tftpboot ${fdt_addr} " CONFIG_FDTFILE " " \
From 145df6fe2a5897cfda0ca2992d0e08cdb9cc0cde Mon Sep 17 00:00:00 2001
From: Michael Walle <michael@walle.cc>
Date: Sun, 8 Feb 2015 20:06:06 +0100
Subject: [PATCH 2/4] lsxl: place the dtb below the inital ramdisk
The dtb was loaded at a memory address after the initial ramdisk. Thus a
large ramdisk would overwrite the dtb. Move it to "ramdisk_start - 64k".
64k should be enough for the device tree blob. Also the kernel
documentation arm/Booting suggests to put the dtb before the initial
ramdisk.
Signed-off-by: Michael Walle <michael@walle.cc>
---
include/configs/lsxl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
index 6c8e369861..dff90250a0 100644
--- a/include/configs/lsxl.h
+++ b/include/configs/lsxl.h
@@ -125,7 +125,7 @@
"hdpart=0:1\0" \
"kernel_addr=0x00800000\0" \
"ramdisk_addr=0x01000000\0" \
- "fdt_addr=0x01ff0000\0" \
+ "fdt_addr=0x00ff0000\0" \
"bootcmd_legacy=ide reset " \
"&& load ide ${hdpart} ${kernel_addr} /uImage.buffalo " \
"&& load ide ${hdpart} ${ramdisk_addr} /initrd.buffalo "\
From 4fe49d7becc2dfb7288f8b265e0976428b64323c Mon Sep 17 00:00:00 2001
From: Michael Walle <michael@walle.cc>
Date: Sun, 8 Feb 2015 20:06:07 +0100
Subject: [PATCH 3/4] lsxl: switch from bootm to bootz for boot commands
Use the bootz command to load zImages in case of any new boot scripts. Only
the legacy one will still use bootm. Apart form the fact, that this will
simplify the image generation process, it saves one copy of the kernel
image: Common practice is to generate an uImage with a loading address of
0x8000. This uImage contains a compressed zImage, which will unpack the
kernel image to the beginning of the RAM. But because there is already the
compressed image the uncompressor first relocates the compressed image to a
higher location. The load address is encoded into the uImage which is
generated by the distributions and thus cannot be easily changed. By using
the bootz command we can load the compressed image to a higher memory
address and the decompressor doesn't have to reloacte the image.
Signed-off-by: Michael Walle <michael@walle.cc>
---
include/configs/lsxl.h | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
index dff90250a0..c354c29296 100644
--- a/include/configs/lsxl.h
+++ b/include/configs/lsxl.h
@@ -56,6 +56,7 @@
* Commands configuration
*/
#include <config_cmd_default.h>
+#define CONFIG_CMD_BOOTZ
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_ELF
#define CONFIG_CMD_ENV
@@ -78,6 +79,9 @@
*/
#include "mv-common.h"
+/* loading initramfs images without uimage header */
+#define CONFIG_SUPPORT_RAW_INITRD
+
/* ST M25P40 */
#undef CONFIG_SPI_FLASH_MACRONIX
#define CONFIG_SPI_FLASH_STMICRO
@@ -130,22 +134,26 @@
"&& load ide ${hdpart} ${kernel_addr} /uImage.buffalo " \
"&& load ide ${hdpart} ${ramdisk_addr} /initrd.buffalo "\
"&& bootm ${kernel_addr} ${ramdisk_addr}\0" \
- "bootcmd_net=bootp ${kernel_addr} uImage " \
- "&& tftpboot ${ramdisk_addr} uInitrd " \
+ "bootcmd_net=bootp ${kernel_addr} vmlinuz " \
+ "&& tftpboot ${ramdisk_addr} initrd.img " \
+ "&& setenv ramdisk_len ${filesize} " \
"&& tftpboot ${fdt_addr} " CONFIG_FDTFILE " " \
- "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \
+ "&& bootz ${kernel_addr} " \
+ "${ramdisk_addr}:${ramdisk_len} ${fdt_addr}\0" \
"bootcmd_hdd=ide reset " \
- "&& load ide ${hdpart} ${kernel_addr} /uImage " \
- "&& load ide ${hdpart} ${ramdisk_addr} /uInitrd " \
- "&& load ide ${hdpart} ${fdt_addr} " \
- "/" CONFIG_FDTFILE " " \
- "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \
+ "&& load ide ${hdpart} ${kernel_addr} /vmlinuz " \
+ "&& load ide ${hdpart} ${ramdisk_addr} /initrd.img " \
+ "&& setenv ramdisk_len ${filesize} " \
+ "&& load ide ${hdpart} ${fdt_addr} /dtb " \
+ "&& bootz ${kernel_addr} " \
+ "${ramdisk_addr}:${ramdisk_len} ${fdt_addr}\0" \
"bootcmd_usb=usb start " \
- "&& load usb 0:1 ${kernel_addr} /uImage " \
- "&& load usb 0:1 ${ramdisk_addr} /uInitrd " \
- "&& load usb 0:1 ${fdt_addr} " \
- "/" CONFIG_FDTFILE " " \
- "&& bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0" \
+ "&& load usb 0:1 ${kernel_addr} /vmlinuz " \
+ "&& load usb 0:1 ${ramdisk_addr} /initrd.img " \
+ "&& setenv ramdisk_len ${filesize} " \
+ "&& load usb 0:1 ${fdt_addr} " CONFIG_FDTFILE " " \
+ "&& bootz ${kernel_addr} " \
+ "${ramdisk_addr}:${ramdisk_len} ${fdt_addr}\0" \
"bootcmd_rescue=run config_nc_dhcp; run nc\0" \
"eraseenv=sf probe 0 " \
"&& sf erase " __stringify(CONFIG_ENV_OFFSET) \
From 43730ba72c176ffc4d9858249475f458203d9757 Mon Sep 17 00:00:00 2001
From: Michael Walle <michael@walle.cc>
Date: Fri, 13 Feb 2015 18:45:57 +0100
Subject: [PATCH 4/4] lsxl: add a README file
The README describes the recovery method which can be used if the NAS box
is not reachable anymore. Addionally, it describes the different boot
scripts.
Signed-off-by: Michael Walle <michael@walle.cc>
---
board/buffalo/lsxl/README | 139 ++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
create mode 100644 board/buffalo/lsxl/README
diff --git a/board/buffalo/lsxl/README b/board/buffalo/lsxl/README
new file mode 100644
index 0000000000..ef5ed42880
--- /dev/null
+++ b/board/buffalo/lsxl/README
@@ -0,0 +1,139 @@
+Intro
+-----
+The Buffalo Linkstation Pro/Live, codename LS-XHL and LS-CHLv2, is a single
+disk NAS server. The PCBs of the LS-XHL and LS-CHLv2 are almost the same.
+The LS-XHL has a faster CPU and more RAM with a wider data bus, therefore
+the LS-XHL PCB has two SDRAM chips. Both have a Kirkwood CPU (Marvell
+88F6281). The only on-board storage is a 4 Mbit SPI flash which stores the
+bootloader and its environment. The linux kernel and the initial ramdisk
+are loaded from the hard disk.
+
+
+Rescue Mode
+-----------
+These linkstations don't have a populated serial port. There is no way to
+access an (unmodified) board other than using the netconsole. If you want
+to recover from a bad environment setting or an empty environment, you can
+do this only with a working network connection.
+
+Therefore, on entering the resuce mode, a random ethernet address is
+generated if no valid address could be loaded from the environment variable
+'ethaddr' and a DHCP request is sent. After a successful DHCP response is
+received, the network settings are configured and the ncip is unset. Thus
+all netconsole packets are broadcasted and you can use the netconsole to
+access board from any host within the network segment. To determine the IP
+address assigned to the board, you either have to sniff the traffic or
+check the logs/leases of your DHCP server.
+
+The resuce mode is selected by holding the push button for at least one
+second, while powering-on the device. The status LED turns solid amber if
+the resuce mode is enabled, thus providing a visual feedback.
+
+Pressing the same button for at least 10 seconds on power-up will erase the
+environment and reset the board. In this case the visual indication will
+be:
+- blinking blue, for about one second
+- solid amber, for about nine seconds
+- blinking amber, until you release the button
+
+This ensures, that you still can recover a device with a broken
+environment by first erasing the environment and then entering the rescue
+mode.
+
+Once the rescue mode is started, use the ncb binary from the tools/
+directory to access your board. There is a helper script named
+'restore_env' to save your changes. It unsets all the network variables
+which were set by the rescue mode, saves your changes and then resets the
+board.
+
+The common use case for this is setting a MAC address. Let us assume you
+have an empty environment, the board comes up with the amber LED blinking.
+Then you enter the rescue mode, connect to the board with the ncb tool and
+use the following commands to set your MAC address:
+
+ setenv ethaddr 00:00:00:00:00:00
+ run restore_env
+
+Of course you need to replace the 00:00:00:00:00:00 with your valid MAC
+address, which can be found on a sticker on the bottom of your box.
+
+
+Status LED
+----------
+blinking blue
+ Bootloader is running normally.
+
+blinking amber
+ No ethaddr set. Use the `Rescue Mode` to set one.
+
+blinking red
+ Something bad happend during loading the operating system.
+
+The default behavior of the linux kernel is to turn on the blue LED. So if
+the blinking blue LED changes to solid blue the kernel was loaded
+successfully.
+
+
+Power-on Switch
+---------------
+The power-on switch is a software switch. If it is not in ON position when
+the bootloader starts, the bootloader will disable the HDD and USB power
+and stop the fan. Then it loops until the switch is in ON position again,
+enables the power and fan again and continue booting.
+
+
+Boot sources
+------------
+The environment defines several different boot sources:
+
+legacy
+ This is the default boot source. It loads the kernel and ramdisk from the
+ attached HDD using the original filenames. The load addresses were
+ modified to support loading larger kernels. But it should behave the same
+ as the original bootloader.
+
+hdd
+ Use this for new-style booting. Loads three files /vmlinuz, /initrd.img
+ and /dtb from the boot partition. This should work out of the box if you
+ have debian and the flash-kernel package installed.
+
+usb
+ Same as hdd expect, that the files are loaded from an attached USB mass
+ storage device and the filename for the device tree is kirkwood-lsxhl.dtb
+ (or kirkwood-lschlv2.dtb).
+
+net
+ Same as usb expect, that the file are loaded from the network.
+
+rescue
+ Automatically activated if the push button is pressed for at least one
+ second on power-up. Does a DHCP request and enables the network console.
+ See `Rescue Mode` for more information.
+
+You can change the boot source by setting the 'bootsource' variable to the
+corresponding value. Please note, that the restore_env script will the the
+bootsource back to 'legacy'.
+
+
+Flash map
+---------
+00000 - 5ffff u-boot
+60000 - 6ffff reserved, may be used to store dtb
+70000 - 7ffff u-boot environment
+
+
+Compiling
+---------
+make lsxhl_config (or lschlv2_config)
+make u-boot.kwb
+
+
+Update your board
+-----------------
+Just flash the resulting u-boot.kwb to the beginning of the SPI flash. If
+you already have a bootloader CLI, you can use the following commands:
+
+ sf probe 0
+ bootp ${loadaddr} u-boot.kwb
+ sf erase 0 +${filelen}
+ sf write 0 ${fileaddr} ${filesize}