Skip to content
Snippets Groups Projects
Commit dfd16746 authored by Federico Vaga's avatar Federico Vaga Committed by Alessandro Rubini
Browse files

barebox: complete review an simplification of menus


Signed-off-by: default avatarFederico Vaga <federico.vaga@gmail.com>
parent a417ab0e
Branches
Tags
No related merge requests found
......@@ -80,7 +80,7 @@ granted write access).
* Schematics are Available::
* Older Hardware Releases::
* Installing from Jtag::
* Troubleshooting::
* Bugs and Troubleshooting::
@end menu
@c ##########################################################################
......@@ -626,7 +626,7 @@ You can also flash the image you have build using @ref{Building} by
adding the tag @code{-b|--build}.
Finally you can select a mode using the @code{-m|--mode} flag to choose
to write in dataflash (df), nandflash (nf), both (default) or ddr memories (ddr).
to write in dataflash (df), nandflash (nf), both (default) or ddr memories (ddr). The last option is for developers.
You can also erase the selected memory before write your binaries; to do this
add the option @code{-e}.
......@@ -648,63 +648,107 @@ The script performs the following steps:
@node Booting with Barebox
@chapter Booting with Barebox
After initial installation, you should reach the following menu.
After the initial installation, the boot loader will offer you an
interactive menu, where the first entry is selected by default.
The menu is a simple ASCII interface on the serial port, and looks
like the following:
@example
Welcome on WRSv3 Boot Sequence
1: boot from nand (default)
2: boot from dataflash (failsafe)
3: boot from script
4: edit & save config
5: shell (prompt terminal)
6: reset barebox
Welcome on WRSv3 Boot Sequence
1: boot from nand (default)
2: boot from TFTP script
3: edit config
4: exit to shell
5: reboot
@end example
You have multiple choise to boot your switch. The default is the boot
from NAND memory, but you need to install the Linux kernel and the
file system on it before succesfully boot the switch. Please see
@ref{Install Kernel to NAND} to install the kernel and the file system
on the NAND memory.
You can also boot from the DataFlash; this is the failsafe mode, you can
use it when the NAND memory is corrupted.
@c FIXME how can I install on DataFlash?
If flashing of the whole system was successful, the first entry will
simply work, booting the switch without any network access. Although
a DCHP client runs by default after boot, everything will work even if
you leave the Ethernet port unconnected or you have no DHCP server
when the switch is operational.
Script option requires an active network connection and a
TFTP server, optionally a DHCP server. By defaul it uses a DHCP server to
obtain the IP address to connect to the TFTP server.
If booting from NAND memory fails (for example because you erased the
kernel partition) the menu is re-entered automatically.
However, if you do not want to use DHCP you must edit the configuration and
add the following lines@footnote{replace IP addresses with your local
addressing}:
The other entries are provided to help developers.
@menu
* The Compiler::
@end menu
@example
eth0.ipaddr=192.168.16.9
eth0.serverip=192.168.16.1
@end example
@c ==========================================================================
@node Description of the menus
@section Description of the menus
The individual menu items perform the following actions:
@table @code
The script booting procedure asks to the TFTP server a script named
@file{wrboot}. This file can be placed in the root TFTP directory, or
in its direct sub-directory named with the MAC address of the destination
switch. Once the script is loaded, the switch execute it within barabox
to boot the system. You can use this option to write costum kernel
commandline.
@item 1: boot from nand (default)
Finally in save & edit config you have some parameters to easily fit
the booting process to your need. i.e, Selecting alternative boot method,
forcing alternative boot, etc.
This entry is selected by default after 10 seconds of
inactivity on the serial port. It boots the system from its
own NAND memory. This ``just works''.
@menu
* Booting from NFS::
* Install Kernel to NAND::
@end menu
@item 2: boot from TFTP script
This entry tries to download a @i{barebox} script from your TFTP
server; if successful it then executes it. Developers are
expected to customize the script to support any kind of environment,
from customized kernel command-line to NFS-Root environments.
See @ref{Using wrboot} for details.
@item 3: edit config
This fires the editor on the configuration file, and
saves it to flash when the user is done. This is useful to
change the MAC address of the ARM network port.
@item 4: exit to shell
By choosing this entry, the user can access the shell-like
interface of @i{barebox}. The entry is aimed at developers
who know what they are going to type.
@item 5: reboot
This entry is useful to see and log the exact boot messages.
Since the serial-USB converter is @i{switch-powered} and not
@i{USB-powered}, you won't be able to hook at the serial port
soon enough after power-on. Actually, the menu timeout is
left to 10 seconds and not less for the very same reason.
@end table
@c ==========================================================================
@node Booting from NFS
@section Booting from NFS
@node Using wrboot
@section Using wrboot
If you use the @i{wrboot} script option, you can for example run
an NFS-Root system using a script similar to the one included
in the @file{binaries} directory of this package. Even though
the directory is called @file{binaries} the file
is ASCII anyways).
@c FIXME: wrboot ``binary''
dhcpd: DHCPOFFER on 192.168.16.224 to 02:0b:ad:c0:ff:ee via eth0
atftpd[5623]: Serving wrboot-02:0B:AD:C0:FF:EE to 192.168.16.224:1029
atftpd[5623]: Serving 192.168.16.224/wrboot to 192.168.16.224:1030
atftpd[5623]: Serving wrboot to 192.168.16.224:1031
Assuming you have a known-working NFS-Root installation, a TFTP
The boot loader tries to download three files, in this order:
``@code{wrboot-MA:CA:DD:RR:EE:SS}'',
``@code{192.168.from.dhcp/wrboot}'', ``@code{wrboot}''. If no such
file is found, the menu is re-entered.
Assuming you have a known-working NFS-Root installation, in the
usual directory of your server,
standard a TFTP
server and you don't use the DHCP server; you can write a @file{wrboot}
script to boot the Linux kernel loaded with TFTP and the file system on NFS.
Following an example of a @file{wrboot} script used too boot from NFS.
......@@ -723,19 +767,8 @@ As described above, by using the @i{boot from script} option, barebox
automatically load your @file{wrboot} script @footnote{See
@ref{Booting with Barebox} to know where place your @file{wrboot}}.
@c ==========================================================================
@node Install Kernel to NAND
@section Install Kernel to NAND
In order to boot from NAND memory, you must install the kernel and
the filesystem to NAND memory, so you can have a self-hosted switch.
If you already done this step you can skip this procedure and directly
boot from NAND. Pleae note this is not the production release, as some
shortcuts have been taken.
After a successful NFS-Root (See @ref{Booting from NFS}), you'll notice
the system identified two flash devices, for a total of 3 partitions.
Note however that NAND memory may have bad blocks:
@c FIXME: remove this one
@example
# dmesg | grep -i mtd
......@@ -968,8 +1001,25 @@ If you build using a local @i{git} repository, we suggest to use
@code{git am --whitespace=nowarn} because we have a number of
white space errors, and we apologize for that.
After patching, the build scripts compile with the following commands, where the
cross-compiler is the one built by @i{buildroot}. If you run these
The @i{barebox} boot loader is organized as a small Unix-like
environment, and its own configuration and scripts live in a small
filesystem. To ease modification of such configuration and boot steps
the build script copies over the configuration instead of patching it
in the sources. You can thus edit the files you find in
@file{patches/barebox/env} and rebuild your customized bootloader.
The script that is executed at boot time is @file{env/bin/init} and as
you see it calls the other ones. The menus included in the shipped
configuration are described in @ref{Booting with Barebox}.
Building @i{barebox} relies on a @i{Kconfig} setup, and the
configuration file we use is
@file{patches/barebox/wrs3_defconfig}. Again, this is copied over and
not patched in (see the simple @file{build/scripts/wrs_build_barebox}
for details).
After patching and copying over the files, the following commands
build the boot loader using the
cross-compiler built by @i{buildroot}. If you run these
by hand you can use a different compiler (as shown):
@example
......@@ -977,10 +1027,10 @@ by hand you can use a different compiler (as shown):
export ARCH=arm
make wrs3_defconfig
make
cp barebox.bin /tftpboot/bb.bin
cp barebox.bin images/
@end example
To use the compiler the scripts use, you need this setting (which is split
To use the same compiler the scripts use, you need this setting (which is split
in two lines with a local variable to fit the page with in documentation):
@smallexample
......@@ -989,10 +1039,9 @@ in two lines with a local variable to fit the page with in documentation):
@end smallexample
A pre-built binary is available as @code{binaries/barebox.bin}.
The ELF version is copied to @i{images} as well, as
@code{images/barebox}; this file includes the symbol table and may (or may not) be
useful.
@code{images/barebox}; this file includes the symbol table and may (or
may not) be useful.
@c ==========================================================================
@node The Linux Kernel
......@@ -1017,7 +1066,7 @@ and are currently the following ones:
0006-fiq-support.patch
@end example
The configuration we use to build the kernel is not a patch but a plan
The configuration we use to build the kernel is not a patch but a plain
@code{.config} file, in the same directory as the patches, so you
can change it easily, if needed. As an alternative,
you can also set @code{WRS_KERNEL_CONFIG} to the full pathname of
......@@ -1047,13 +1096,15 @@ becomes dirty with output and intermediate files. The advantage is that
any modification you make to the code is already in the repository
for your to commit.
Currently, the modules build built are @i{wr_vic.ko} (the interrupt
controller) and @i{wr-nic.ko} (the network ``card'' driver). The
@i{wr_rtu.ko} driver is compiled too, but it is not currently used nor
has it been tested.
Currently, the package includes the following modules:
@b{Warning}: I plan to soon rename all modules to have a hyphen
instead of an underscore in the name.
@itemize @bullet
@item @i{wr_vic.ko}: the interrupt controller for in-FPGA devices.
@item @i{wr-nic.ko}: the network ``card'' driver for WR ports.
@item @i{at91_softpwm}: a tool that generates a PWM signal for the fan.
@item @i{wr_rtu.ko}: the routing-table interface between the
switching core and the associated user-space daemon.
@end itemize
@c ==========================================================================
@node PTPd
......@@ -1174,8 +1225,12 @@ with it to avoid requiring an LM32 development environment.
@node The Complete Filesystem
@section The Complete Filesystem
The final step in compiling the filesystem is making the CPIO archive
with the overall filesystem contents. This archive can be used as an
The final step in building the switch software is wrapping together
the filesystem for the switch, also making the archives and the
@i{jffs2} image file.
@c FIXME: all of this
This archive can be used as an
@i{initramfs} or uncompressed to some directory. The build procedure
does not leave a directory tree on disk because that would require
administrator privileges. I think it is best not to call @i{sudo} from
......
#!/bin/sh
# boot kernel from bad block aware partition
cp /dev/nand0.kernel.bb /dev/mem.kernel
bootargs="console=ttyS0,115200 panic=10"
bootargs="$bootargs root=/dev/mtdblock1 rootfstype=jffs2"
bootz /dev/mem.kernel
# If it don't boot, show the menu
echo "Can't boot from NAND"
# Sleep 2 seconds so you can see the message and return to menu
sleep 2
menu -s boot
#!/bin/sh
# This script loads a wrboot script from the TFTP server and runs it.
dhcp 5
if [ "$?" -ne "0" ]; then
echo "Cannot obtain IP from DHCP server"
else
# fetch wrboot-<MAC> script
tftp wrboot-$eth0.ethaddr wrboot
if [ "$?" -ne "0" ]; then
sleep 1
tftp $eth0.ipaddr/wrboot wrboot
fi
if [ "$?" -ne "0" ]; then
sleep 1
tftp wrboot wrboot
fi
if [ "$?" -eq "0" ]; then
./wrboot
fi
fi
# If the script doesn't boot return to menu after some time to read output
sleep 2
menu -s boot
#!/bin/sh
edit /env/config
. /env/config
saveenv
sleep 2
menu -s boot
#!/bin/sh
#
# Init script for WRS barebox
# ========================
# Syntax: Hush shell script
# Authors: Benoit Rat, Tomasz Wlostowski
# Environment variables:
# - autoboot_timeout: number of seconds
# - autoboot_altforced: "1" or "0"
# - default_altmode: i.e "the menu number"
# - ip: dhcp or none (in this case setup by eth0)
#######################################
echo ""
echo "=============================================="
### Default value ": ${VISUAL:=vi}"
autoboot_timeout="10";
autoboot_altforced="0";
autoboot_altmode="2";
error_timeout="60";
net="0"
bootargs="console=ttyS0,115200"
### Override default value using /env/config
. /env/config
......@@ -31,193 +11,39 @@ echo "Starting up barebox [wrs3] (MAC=$eth0.ethaddr)"
PATH=/env/bin
export PATH
if [ x$autoboot_timeout != x ]; then menu_timeout="-A $autoboot_timeout"; fi
if [ x$autoboot_timeout != x ]; then
menu_timeout="-A $autoboot_timeout"
fi
#Set 2nd LED ON (PA2)
gpio_set_value 33 0
gpio_set_value 33 0 #Set 2nd LED ON (PA2)
PS1="wrs-$eth0.ethaddr# "
mode=""
ok="0"
run="1"
### Creating the partitions:
if [ -e /dev/mem.kernel ]; then; else addpart /dev/mem 8M@0x71000000(kernel); fi
if [ -e /dev/nand0.kernel ]; then; else addpart /dev/nand0 256k@0x4000(bareboxenv),8M@0x100000(kernel),-@0x4000000(rootfs); fi
if [ -e /dev/nand0.kernel.bb ]; then; else nand -a /dev/nand0.*; fi
### Create the menu for various boot in case we don't run the autoboot
menu -r -m boot
menu -a -m boot -d "Welcome on WRSv3 Boot Sequence"
menu -e -a -m boot -c 'init -m nand' -d "boot from nand (default)"
menu -e -a -m boot -c 'init -m df' -d "boot from dataflash (failsafe)"
menu -e -a -m boot -c 'init -m script -n' -d "boot from script"
menu -e -a -m boot -c 'init -m ram -r tftp -n' -d "boot from ram"
menu -e -a -m boot -c 'init -m tftp -r nfs -n' -d "boot from nfs"
menu -e -a -m boot -c 'init -m tftp -r nfs -n -x test' -d "boot from nfs (test)"
menu -e -a -m boot -c 'init -m config' -d "edit & save config"
menu -e -a -m boot -c 'exit 0' -d "shell (prompt terminal)"
menu -e -a -m boot -c reset -d "reset barebox"
### Check init arguments
while getopt "m:r:x:n" Option
do
if [ ${Option} = m ]; then
mode=${OPTARG}
elif [ ${Option} = r ]; then
rootfs_loc=${OPTARG}
elif [ ${Option} = n ]; then
net="1"
elif [ ${Option} = x ]; then
xtra="-${OPTARG}"
if [ -e /dev/mem.kernel ]; then
else
addpart /dev/mem 8M@0x71000000(kernel)
fi
done
### In case mode is not set
if [ x$run = x1 -a x$mode = x ]; then ### Check if an alternative mode is on or off
run="0"
gpio_get_value 103 #Obtain value of alternative boot jumper (only for v3.2+)
if [ "$?" -eq "0" ]; then
autoboot_altforced="1" #Force alternative boot if FGPA button is pushed
fi
## Check if there is an alternative boot
if [ "$autoboot_altforced" -eq "1" ]; then
menu -m boot -S -n $autoboot_altmode
ok="1"
else
### If barebox is not already set in NAND (first boot or NAND formatted)
if [ -f /env/this_is_compiled_in ]; then
echo "You might save & edit the config to run from NAND"
menu -m boot -S -n 6 #Select automatic NFS (test) option for next boot
ok="1"
### Otherwise boot from NAND
else
menu -m boot -S -n 1
ok="1"
fi
fi
fi
################################# Boot modes
### Try booting from NAND (default mode)
if [ x$run = x1 -a x$mode = xnand ]; then
echo "booting from NAND"
run="0"
cp /dev/nand0.kernel /dev/mem.kernel
bootargs="$bootargs root=1f01 rootfstype=jffs2 mem=32m init=/init"
bootz /dev/mem.kernel
menu -m boot -S -n $autoboot_altmode #Select the alternative boot
fi
### Edit and save config mode
if [ x$run = x1 -a x$mode = xconfig ]; then
echo "Editing config..."
run="0"
edit /env/config
. /env/config
if [ -f /env/this_is_compiled_in ]; then
echo "No NAND environment..."
rm /env/this_is_compiled_in
fi
saveenv
ok="1"
fi
### Try failsafe boot from DF
if [ x$run = x1 -a x$mode = xdf ]; then
run="0"
echo "not implemented"
fi
### Try booting from RAM
if [ x$run = x1 -a x$mode = xram ]; then
echo "booting from RAM"
run="0"
echo "Kernel+FS must have been set using usb-loader"
addpart /dev/mem 8M@0x72000000(fs)
bootargs="$bootargs initrd=0x72000000,8388608"
bootz /dev/mem.kernel
## Otherwise try to load from TFTP
run="1"
ip=dhcp
mode=tftp
rootfs_loc=tftp
fi
### Obtain DHCP
if [ x$run = x1 -a x$net = x1 -a x$ip = xdhcp ]; then
dhcp 5
if [ "$?" -eq "1" ]; then
echo "Enable to obtain IP from DHCP (Required for $mode)"
run="0"
ok="0"
fi
fi
### Try autoboot from loading script
if [ x$run = x1 -a x$mode = xscript ]; then
echo "booting from Script"
run="0"
### Search customboot based on MAC address
tftp $eth0.ethaddr/wrboot /customboot
if [ "$?" -eq "0" ]; then
echo "We have got a custom boot file for this particular switch."
./customboot
### Load generic script
else
tftp wrboot
if [ "$?" -eq "0" ]; then
./wrboot
fi
fi
if [ -e /dev/nand0.kernel ]; then
else
addpart /dev/nand0 256k@0x4000(bareboxenv),8M@0x100000(kernel),-@0x4000000(rootfs)
fi
### Try booting from TFTP
if [ x$run = x1 -a x$mode = xtftp ]; then
echo "booting from TFTP"
run="0"
#loading the kernel
tftp zImage /dev/mem.kernel
if [ x$rootfs_loc = xnfs ]; then
bootargs="$bootargs ip=${eth0.ipaddr}:${eth0.gateway}:${eth0.netmask}:${eth0.gateway}"
bootargs="$bootargs root=/dev/nfs nfsroot=/tftpboot/rootfs${xtra},tcp mem=32m"
bootz /dev/mem.kernel
elif [ x$rootfs_loc = xtftp ]; then
addpart /dev/mem 8M@0x72000000(fs)
tftp wrs-image.cpio.gz /dev/mem.fs
bootargs="$bootargs initrd=0x72000000,8388608"
bootz /dev/mem.kernel
else
echo "not implemented"
fi
if [ -e /dev/nand0.kernel.bb ]; then
else
nand -a /dev/nand0.*
fi
### Error message and go back to the menu
if [ "$ok" -eq "0" ]; then
echo "Error: Loading kernel+FS from $mode!"
echo -n "hit any key to go to menu..."; timeout -a $error_timeout
menu_timeout=""
fi
# Create the menu
#menu -r -m boot
menu -a -m boot -d "Welcome on WRSv3 Boot Sequence"
menu -e -a -m boot -c 'boot-nand' -d "boot from nand (default)"
menu -e -a -m boot -c 'boot-script' -d "boot from TFTP script"
menu -e -a -m boot -c 'edit-config' -d "edit config"
menu -e -a -m boot -c 'exit 0' -d "exit to shell"
menu -e -a -m boot -c reset -d "reboot"
# allow the user to see previous messages
echo "starting menu in 5 seconds"
sleep 5
menu -s boot $menu_timeout
exit 0
# File to check if we are using environment on NAND or not
#
# It is supposed to be automatically deleted when environment is installed in NAND
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment