Kategorien
Linux ViewPad 7e

ViewPad 7e Rettung

Da die Rettung der CLOUD NAS CL-35B2 funktioniert hat, werde ich als nächstes versuchen ein „altes“ ViewPad 7e der STRATO AG (das gab es als giveaway zu HiDrive Verträgen dazu) mit einem Linux Kernel und fedora 12 zu betreiben. 🙂

als erstes, die Dokumentation des ViewPad 7e:
Die Harware:

  • CPU
    • Samsung S5PC111 Exynos 3110
  • RAM
    • 512 MiB
  • NAND
    • 4 GiB
  • Display
    • TFT 600 x 800 Pixel 143 ppi
  • Akku
    • Li-Polymer 3300 mAh
  • Bluetooth
    • 2.1, EDR
  • Wi-Fi
    • 802.11 b, g, n

Die U-Boot Parameter von einem Funktionsfähigen ViewPad 7e:
bootcmd=run bootcmd_android
mtdpart=80000 400000 3000000
bootdelay=1
baudrate=115200
ethaddr=00:40:5c:26:0a:5b
ipaddr=192.168.0.20
serverip=192.168.0.10
gatewayip=192.168.0.1
netmask=255.255.255.0
filesize=0
uboot_addr=30000000
kernel_addr=30008000
kernel_start=30008040
ramdisk_addr=31000000
recovery_addr=31000000
logo_addr=32000000
temp_addr=32200000
charlib_addr=32200300
clear=setenv filesize 0
_prg_bl=fuse uboot1 ${uboot_addr} ${filesize};fuse uboot2 ${uboot_addr} ${filesize}; run clear
_prg_kn=fuse kernel1 ${kernel_addr} ${filesize};fuse kernel2 ${kernel_addr} ${filesize}; run clear
_prg_ramdisk=fuse ramdisk1 ${ramdisk_addr} ${filesize};fuse ramdisk2 ${ramdisk_addr} ${filesize}; run clear
_prg_recovery=fuse recovery1 ${recovery_addr} ${filesize};fuse recovery2 ${recovery_addr} ${filesize};run clear
_prg_logo1=fuse logo1 ${logo_addr} ${filesize}; run clear
_prg_logo2=fuse logo2 ${logo_addr} ${filesize}; run clear
_prg_logo3=fuse logo3 ${logo_addr} ${filesize}; run clear
load_uboot_sd=movi 1 init; fatload mmc 1:1 ${uboot_addr} u-boot.bin
load_bsp_sd=movi 1 init; fatload mmc 1:1 ${temp_addr} bspfuse
load_char_sd=fatload mmc 1:1 ${charlib_addr} char.bin
load_uboot_dnw=dnw ${uboot_addr}
load_uboot=load uboot ${uboot_addr}
load_kernel_sd=movi 1 init; fatload mmc 1:1 ${kernel_addr} uImage
load_kernel_dnw=dnw ${kernel_addr}
load_kernel=load kernel ${kernel_addr}
load_ramdisk_sd=movi 1 init; fatload mmc 1:1 ${ramdisk_addr} ramdisk-uboot.img
load_ramdisk_dnw=dnw ${ramdisk_addr}
load_ramdisk=load ramdisk ${ramdisk_addr}
load_recovery_sd=movi 1 init; fatload mmc 1:1 ${recovery_addr} ramdisk-recovery-uboot.img
load_recovery_dnw=dnw ${recovery_addr}
load_recovery=load recovery ${recovery_addr}
load_logo_sd=movi 1 init; fatload mmc 1:1 ${logo1_addr} logo1.img
load_logo_dnw=dnw ${logo_addr}
prg_uboot_sd=run load_uboot_sd; run _prg_bl
prg_uboot_dnw=run load_uboot_dnw; run _prg_bl
prg_kernel_sd=run load_kernel_sd; run _prg_kn
prg_kernel_dnw=run load_kernel_dnw; run _prg_kn
prg_ramdisk_sd=run load_ramdisk_sd; run _prg_ramdisk
prg_ramdisk_dnw=run load_ramdisk_dnw; run _prg_ramdisk
prg_recovery_sd=movi 1 init; fatload mmc 1:1 ${recovery_addr} ramdisk-recovery-uboot.img; run _prg_recovery
prg_recovery_dnw=dnw ${recovery_addr}; run _prg_recovery
prg_logo1_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo1.img; run _prg_logo1
prg_logo2_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo2.img; run _prg_logo2
prg_logo3_sd=movi 1 init; fatload mmc 1:1 ${logo_addr} logo3.img; run _prg_logo3
prg_logo_sd=run prg_logo1_sd; fatload mmc 1:1 ${logo_addr} logo2.img; run _prg_logo2;fatload mmc 1:1 ${logo_addr} logo3.img; run _prg_logo3
prg_logo1_dnw=dnw ${logo_addr}; run _prg_logo1
format_inand=fatformat mmc 0:1; ext3format mmc 0:2; ext3format mmc 0:3; ext3format mmc 0:4
bootcmd_smt=movi 1 init; movi 0 init; run prg_uboot_sd; run prg_logo1_sd; run prg_kernel_sd; run prg_recovery_sd; reset
bootcmd_recovery=run bootargs_android; run load_kernel; run load_recovery; bootm ${kernel_start} ${recovery_addr}
bootcmd_android=run bootargs_android; run load_kernel; run load_ramdisk; bootm ${kernel_start} ${ramdisk_addr}
bootargs_android=setenv bootargs console=ttySAC2,115200 root=/dev/ram0 rw ramdisk=4608 init=/init androidboot.serialno=SWV113700001

Bei einem Defekten ViewPad 7e versucht Windows einen Treiber für die Hardware „SEC S5PC110 Text B/D“ zu installieren.

Die Ausgabe via TTL:
SD checksum Error

SD Init Error
ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª
Uart negotiation Error

Insert an OTG cable into the connector!

Laut Dokumentation des SOC S5PC111 kann dieser von einer SD Karte, via TTL und vom NAND booten, leider sind auf anhieb kein entsprechendes UBoot Image im Internet zu finden.

Die TTL-Pads sind abgebrochen, die Hardware ist somit nicht mehr der Rettung wert…

Kategorien
CL-35B2 Linux

CL-35B2 Rettungssystem (final)

Dieser Artikel enthält meine lange versprochene Anleitung wie ein Rettungssystem für die fantec CL-35B2 erstellt werden kann. In dieser Anleitung zeige ich wie „auf die Schnelle“ ein bereits fertiges Rettungssystem für die fantec CL-35B2 auf eine Festplatte geschrieben wird um die NAS von dieser Festplatte zu starten. ☺

Leider enthält das Rettungssystem aktuell noch keine Unterstützung für die Netzwerkhardware der NAS. Dies bedeutet das Du dieses Rettungssystem über das TTL Interface der CL-35B2 bedienen musst!
(Alternativ versuche eine USB-Netzwerkkarte, von dem verwendeten Linux Kernel werden einige USB Netzwerkkarten unterstützt.)

Für die Verwendung dieses Rettungssystems benötigst Du eine SATA-Festplatte. Alle Daten auf dieser Festplatte gehen bei der Installation des Rettungssystems verloren.

In der folgenden Download Datei ist ein Installations-Script enthalten, das die beim Aufruf angegebene Festplatte überschreibt. Die auf der Festplatte gespeicherten Daten gehen durch diesen Vorgang unwiederruflich verloren. Im Anschluss wird das RescueSystem für die fantec CL-35B2 auf dieser Festplatte hinterlegt.

Download: fantec Rescue-System

Der Download ist sowohl über den Obenstehenden Link als auch via wget möglich.:

wget https://loteks.de/wp-content/uploads/2013/06/fantec_CL-35B2_rescue.tar.gz

Die im Download enthaltene Datei fantec_CL-35B2_rescue.tar.gz kann mit dem Befehl tar, mit den Optionen „xzf“, entpackt werden.

tar xzf fantec_CL-35B2_rescue.tar.gz

Das Script wird nach dem entpacken via ./install.sh /dev/sdx aufgerufen, wobei /dev/sdx die Festplatte ist auf welche das Rettungssystem geschrieben werden soll.
(☠Alle auf der Festplatte gespeicherten Daten gehen unwiederruflich verloren!☠)

Ich habe das Linux Image aus den gleichen „Fedora ARM 12″[1] Quellen zusammengestellt, welche von fantec verwendet wurden um das System der fantec CL-35B2 zusammen zu stellen.
In der Distribution, so wie sie im .tar.gz Archive enthalten ist, ist „unnötiger weise“ Samba, SSH und ddclient enthalten da ich dieses Image für Experimente mit einer meiner CL-35B2 verwendet habe.

[1]http://ftp.linux.org.uk/pub/linux/arm/fedora/pub/fedora/linux/releases/12/Everything/arm/os/Packages/

Kategorien
CL-35B2 Linux

Boot CL-35B2 from SATA

Ich habe einen ersten Erfolg erzielt, die CL-35B2 von einer SATA Festplatte zu starten. In der Dokumentation des SOC ist ein folgend erklärter Bootcode angegeben der auf die SATA Festplatte geschrieben werden muss um von der Festplatte zu starten.

Erstellen der Festplatte:
– Welche Festplatte soll überschrieben werden

export disk=/dev/sdc

– Festplatte leeren

dd if=/dev/zero of=$disk bs=512

– Bootcode auf die Platte schreiben (Perl Magic 🙂

perl < print "\x00" x 0x1a4;
print "\x00\x5f\x01\x00";
print "\x00\xdf\x00\x00";
print "\x00\x80\x00\x00";
print "\x00" x (0x1b0 -0x1a4 -12 );
print "\x22\x80\x00\x00";
print "\x22\x00\x00\x00";
print "\x00\x80\x00\x00";
EOF

– Bootblock auf die Platte schreiben

dd if=./resource/stage1.wrapped of="$disk" bs=512 seek=34

– das U-Boot auf die Festplatte schreiben (Quellcode folgt!)

dd if=./resource/u-boot.wrapped_from-ox820source of="$disk" bs=512 seek=154

Wenn die Festplatte in slot 1 der CL-35B2 eingebaut wird bootet die NAS den U-Boot Bootloader von der Festplatte.
UBoot Dateien

Kategorien
CL-35B2 Linux

Netzwerkkonsole für Das UBoot konfigurieren

Um auf einen Das UBoot Bootloader ohne serielles Kabel zugreifen zu können kann Das UBoot als Konsolenserver konfiguriert werden.

Ich gehe hier der Einfachheit halber von meinem eigenen Privaten Netzwerk aus. Mein Router ist unter der Adresse 192.168.1.1 zu erreichen, die „Server“ 192.168.1.2-192.168.1.10 und die bekannten Computer sind zwischen 192.168.1.100-192.168.1.150. Mein Linux Computer, von dem aus meine NAS ansprechen soll ist 192.168.1.111, die NAS ist 192.168.1.7

Im Auf der Shell lässt sich „Das UBoot“ mit fw_setenv, innerhalb von „Das UBoot“ mit setenv konfigurieren. Auf der Shell lautet für die „Das UBoot“ Konfiguration:

setenv serverip 192.168.1.111
setenv ipaddr 192.168.1.7
setenv if_netconsole 'ping $serverip'
setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;'
setenv preboot 'run if_netconsole start_netconsole'
saveenv

Der Befehl saveenv in der Letzten Zeile sichert die zuvor getätigten Einstellungen, so das bei jedem erneuten Restart der NAS 10 Sekunden lang gewartet wird ob eine Eingabe von 192.168.1.111 erfolgt um den Bootvorgang zu unterbrechen. Auf der Shell lautet der Befehl, wenig überraschend fw_saveenv.

Auf dem Computer brauche ich vor dem Booten nur im Hintergrund via nc auf port 6666 zu lauschen und eine Weitere nc Instanz für die Eingaben zu starten.

nc -l -u -p 6666 &
nc -u 192.168.1.100 6666

Zum beenden der „Chat-Session“ mit der NAS muss, nach [Strg]+c noch über killall nc die lauschende NC Session beendet werden.

Kategorien
CL-35B2 Linux

CL-35B2: Linux vom USB-Stick

Um die CL-35B2 von einem USB-Stick zu Booten benötige ich die TTL Konsole und auf dem NAS ein funktionsfähiges UBoot. Beim Testen dieses Tutorials hatte ich aus die nach dem letzten Punkt auf den NAND-Speicher geschrieben und dadurch das UBoot überschrieben. !Also! nach dem Booten den NAND Speicher in ruhe lassen. (Ich teste Später noch wie ich die CL-35B2 anderweitig booten kann)

zuerst die beiden neuen mount-Ziele anlegen.
mkdir /mnt/{source,system}

Zum Mounten des root-Systems die Datei /etc/fstab durch die Folgende Zeile ergänzen:
ubi0 /mnt/source ubifs ro,noatime,nodev,noexec 0 0
Das Gerät ubi0, die Systempartition von dem NAS, soll zusätzlich noch unter /mnt/source eingebunden werden. Auf dieses mount-Ziel soll nur lesend zugegriffen werden(ro), es sollen keine Zugriffszeiten gespeichert (noatime) werden devices sollen nicht interpretiert werden (nodev) und ausführbare Dateien nicht ausgeführt werden(noexec).

Anschließend den USB-Stick Partitionieren und Formatieren, mounten und mit rsync das gesamte System kopieren.
cfdisk /dev/sdc
mkfs.ext2 -m 1 /dev/sdc1 -L fc12arm5tel

mount /dev/sdc1 /mnt/system && mount /mnt/source
rsync -aAXv /mnt/source/ /mnt/system/

Jetzt die Festplatten UUID auslesen und die /mnt/system/etc/fstab korrigieren.
blkid /dev/sdc1
vi /mnt/system/etc/fstab

Bei meinem Dateisystem ist die Ausgabe von blkid die folgende:
/dev/sdc1: UUID="06cf0015-40d5-412f-ba18-a464689a154b" TYPE="ext2" LABEL="fc12arm5tel"

somit wird die erste Zeile in der fstab:
UUID=06cf0015-40d5-412f-ba18-a464689a154b / ext2 defaults 1 1

nach dem abbrechen des Startvorgangs über die Serielle Konsole, es muss nur eine Taste beim U-Boot gedrückt werden, gebe ich folgendes an um vom USB Stick zu booten.:
setenv bootargs 'root=/dev/sda1 console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes ip=dhcp devfs=only raid=noautodetect'

Anschließend wird der Bootvorgang über die folgende Zeile in vom USB Stick gebootet.
run load_nand boot

Der Linux Kernel wird weiterhin via nboot vom NAND geladen und gestartet, Leider noch ein Linux 2.6.31.
(Der Linux Kernel enthält den Netzwerkkarten Treiber gmac_copro_firmware.sdk300 der scheinbar eine separat erthältliche Firmware benötigt. Dem muss ich noch nachgehen!)

!VORSICHT! BRICK!!!
Beim Schreiben auf das ubi nach dem holen der Partition mit ubiattach /dev/ubi_ctrl -m 0 und mounten der Partition, überschreibt Ihr den UBoot und Brickt die CL-35B2 solltet ihr eine Datei auf den NAND schreiben!
Lasst das Dateisystem auf dem NAND so wie es ist! Beschreibt es nicht!

Kategorien
CL-35B2 Linux

CL-35B2: die U-Boot Umgebung

Als Merkblatt, die Ausgabe der CL-35B2 bis zum U-Boot[1] Bootmanager über die Serielle Konsole.

Attempting to set PLLA to 750MHz ...
plla_ctrl0 : 0x0000000A
plla_ctrl1 : 0x000F0000
plla_ctrl2 : 0x001D01A0
plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing, Image 0
Hdr len: 0x0001AC3C
Hdr CRC: 0x9B812E38
OK

U-Boot 1.1.2 (Oct 28 2011 – 10:57:48)

U-Boot code: 60D00000 -> 60D1AC3C BSS: -> 60D1F2F4
RAM Configuration:
Bank #0: 60000000 128 MB
SRAM Configuration:
64KB at 0x50000000
NAND:256 MiB
*** Warning – bad CRC, using default environment

In: serial
Out: serial
Err: serial
Setting Linux mem= boot arg value
Reading upgrade flag from NAND address 0x01ec0000 : 0
Hit any key to stop autoboot: 2

Und hier die Umgebungsvariablen des U-Boot:

$ printenv

bootcmd=run extinguishled boot_nand
bootdelay=2
baudrate=115200
ethaddr=00:30:e0:00:00:01
ipaddr=192.168.50.100
serverip=192.168.50.59
autoload=n
netmask=255.255.0.0
bootfile=“uImage“
load_nand=nboot 60500000 0 440000
load_nand2=nboot 60500000 0 A40000
lightled=ledfail 1
extinguishled=ledfail 0
boot=bootm 60500000
boot_nand=run load_nand boot || run load_nand2 boot || run lightled
stdin=serial
stdout=serial
stderr=serial
bootargs=root=ubi0:rootfs ubi.mtd=2,512 rootfstype=ubifs console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes

Environment size: 579/8188 bytes

[1] Das U-Boot