Wie versprochen geht es weiter mit Artikeln zum DockStar
Um einen eigenen uBoot zu übersetzen bedarf es nicht viel…
- Crosscompiler/Toolchain für Arm
- uBoot-Quellen
- patches für uBoot für den Dockstar
- meine Anpassungen für Speicher und LEDs
Wer das alles nicht möchte, kann auch einfach das fertige Binary laden, muss dann aber mit den Standardoptionen leben oder die Optionen im Flash anpassen. Meine Version des u-Boot gibt es hier. Vorsicht: Es scheint nicht jeder Kernel damit zu booten. Bitte vorher testen!
Die Toolchain bekommt man nach der Anleitung hier und dann geht es bei ahsoftware weiter mit dem uBoot.
Am Ende gibt es dann noch die Anpassungen für LED’s und Speicher von mir:
In der Datei board/Marvell/sheevaplug/sheevaplug.h kann man sich aussuchen, wie man die LED’s beim Einschalten gesetzt haben will. Folgende Zeilen schalten einfach die orange LED ein, um den Bootvorgang zu signalisieren:
#define SHEEVAPLUG_OE_LOW (~(0)) /* This is for DockStar: */
#define SHEEVAPLUG_OE_HIGH (~( (1 << 15) )) /* output enable gpio47 (32+15) = orange, */
/* gpio46 (32+14) = green led */
#define SHEEVAPLUG_OE_VAL_LOW (1 << 29) /* USB_PWEN low */
#define SHEEVAPLUG_OE_VAL_HIGH 0 /* output low => led on - thus we switch on */
/* the yellow one above. */
Viel wichtiger ist jedoch das korrekte Konfigurieren des Speichers, damit das später startende Linux nicht versucht, auf den nicht vorhandenen Speicher zuzugreifen.
Die Option hierzu findet sich in der Definition des Konfigurationsabbilds der CPU in der Datei board/Marvell/sheevaplug/kwbimage.cfg. Dort gilt es die DATA-Definition an der Adresse 0xFFD01504 zu ändern:
DATA 0xFFD01504 0x07FFFFF1 # CS[0]n Size Register - 07=128MB for DockStar
Wer nun noch eine komfortable Eingabeaufforderung im Bootloader haben will, editiert noch schnell die Datei include/configs/sheevaplug.h und fügt die folgenden Zeilen ein:
#define CONFIG_SYS_HUSH_PARSER #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " #define CONFIG_CMDLINE_EDITING
Schliesslich wollte ich noch die Standard-Boot-Optionen anpassen:
#define CONFIG_BOOTCOMMAND \
"${x_bootcmd_usb}; " \
"setenv bootargs ${x_bootargs} ${x_bootargs_root}; echo cmdline: ${bootargs} ; " \
"run x_bootload_kernel m_usb_boot;" \
"reset" /* If loading from USB failed we just reset, my experience was that the second time the device will be found */
[...]
#define CONFIG_EXTRA_ENV_SETTINGS \
"x_bootargs=console=ttyS0,115200 mtdparts="CONFIG_MTDPARTS \
"x_bootargs_root=root=/dev/sda1 ro rootdelay=5\0" \
"x_bootload_kernel=ext2load usb 0:1 0x800000 /boot/uImage\0" \
"m_usb_boot=if ext2load usb 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;\0" \
"x_bootcmd_usb=usb start\0"
Damit sucht der u-Boot auf dem usb-stick nach einem uImage und uInitrd und bootet, falls vorhanden, auch mit Initrd.
Flashen des uBoot
Die heikelste Operation ist das Flashen des uBoot. Zum Testen empfiehlt es sich, mit dem vorhandenen Bootloader den neuen uBoot per Netz oder usb-Stick in den Speicher zu laden und direkt anzuspringen (Dazu das bin-file benutzen). Wer seinen eigenen uBoot flashen will sollte unbedingt daran denken, nicht versehentlich das binary sondern immer das Bootfile (kwb) zu flashen.
Ich erledige das bequem mit der seriellen Konsole und einem tftp-Server:
setenv ipaddr 10.1.1.17 ; setenv serverip 10.1.1.1 ; tftp 0x6400000 u-boot.kwb nand erase 0x0 0x40000 nand write 0x6400000 0x0 0x40000 reset
Und wenn man Glück hatte, braucht man nicht so wie ich einen JTAG-Adapter…