AVM infolab.txt schrieb:
Die Update-Datei "FRITZ.Box_7580_LTE.153.xx.xx.image" auf ftp.avm.de enthält das aktuelle FRITZ!OS (Firmware) für die FRITZ!Box 7580.
:gruebel:
Long
Term
Evaluation?
Long
Time
Evaluation?
Let-down
Timely
Expected?
Long
Time
Evaded?
Lost
Time
Expected?
Oder bin ich in der falschen Sprache unterwegs (ohnehin schwer, da die passenden Worte zu finden) und es ist am Ende doch Deutsch?
- - - Aktualisiert - - -
Für ein paar erste Eindrücke taugt aber auch schon das Recovery-Programm.
Jedenfalls kann man schon sehen, daß offenbar bei der 7580 die (low level-)Gerätekonfiguration tatsächlich in den Bootloader gewandert ist und von dort das System gleich mit dem richtigen FDT gestartet wird (also so richtig OpenFirmware-konform) - damit wird es die Probleme beim Start eines eigenen Kernels auf der 7580 wohl schon mal nicht geben. Der Bootloader (bootcore) hat aber auch mächtig zugelegt bei der Reservierung von Platz ... ich würde auf 8 MB nur für "bootcore" tippen anhand einiger Angaben in /etc/init.d ... wobei die tatsächliche Nutzung im Moment wohl doch noch ein Nummer kleiner ist (der Bootloader besteht event. aus zwei Teilen, den Nachrichten im Loader selbst nach zu urteilen - hier könnte man ja vermuten, daß der OpenFirmware-Teil mit dem FDT extra ist, weil modellspezifisch). In der Folge steht dann wohl auch die Hardware-Konfiguration im laufenden System unter /proc/device-tree zum Auslesen bereit.
WLAN lt. Firmware wäre der QCA9984 - keine Ahnung, ob das schon bekannt ist (@qwertz.asdfgh?).
Bringe ich jetzt etwas durcheinander oder habe ich irgendwo mal gelesen, daß die 7580 den GRX550 von Intel verwenden soll? Das ist aber kein x86-Prozessor in der 7580 - ich finde aber auch keine belastbare Quelle, was der GRX550 nun genau ist - mit Ausnahme des Schildes vor der Box auf dem Foto in diesem Artikel: http://www.golem.de/news/anywan-grx750-soc-intel-sucht-fuer-seinen-atom-einen-platz-in-routern-1606-121291.html
Ist der GRX550 also doch "nur" ein MIPS-Prozessor? Beim GRX750 handelt es sich dann - nach dem
hier - aber um einen komplett anderen Prozessor, da steht etwas von "ATOM core" und "x86/64" ... das irritiert mich jetzt schon. Ich hatte das so verstanden, daß Intel die zugekaufte Lantiq-Sparte mit den MIPS-basierten Chipsets für "Media Gateways" als "XWAY" ins Portfolio aufgenommen hat: http://ark.intel.com/products/family/70322/Intel-Media-Gateways und der GRX550 firmiert ja wohl unter "ANYWAY" - sehr verwirrend (zumindest für mich).
Aber auch an anderen Stellen in den Treiberdateien sieht es so aus, als wäre das tatsächlich ein "Lantiq GRX500" oder zumindest, als würden einige Funktionen entsprechend benannt sein und auch bei den Programmierern läuft der Prozessor wohl unter dem Kürzel "grx5". Damit würde ich jetzt trotzdem nicht so einen riesigen Performance-Sprung beim Prozessor erwarten ... aber ich lasse mich gerne (positiv) überraschen. Alle anderen Spekulationen, was man mit einem ATOM-Prozessor noch so alles anfangen könnte, haben sich dann aber wohl doch zerschlagen.
Die Kernelversion ist nebenbei bemerkt eine ältere als in den anderen 06.5x-Versionen für VR9-Prozessoren ... hier ist es ein 3.10.12-Kernel. Für die Fans des "codel"-Schedulers beim QoS ist es vielleicht eine gute Nachricht, daß der als LKM in der AVM-Firmware enthalten ist ... keine Ahnung, ob er auch benutzt wird (das sieht ohnehin anders aus als bei bisher bekannten Modellen).
Die BusyBox ist weiterhin eine 1.22.1 mit folgenden Applets:
Code:
[
[[
arp
arping
ash
basename
brctl
bunzip2
bzcat
bzip2
cat
chgrp
chmod
chown
chroot
cmp
cp
cut
date
dd
df
dirname
dmesg
dnsdomainname
du
echo
egrep
env
ether-wake
expr
false
fgconsole
fgrep
find
flock
free
fstrim
ftpget
ftpput
getopt
grep
groups
gunzip
gzip
halt
hostname
id
ifconfig
ifdown
ifup
inetd
init
insmod
iostat
kill
killall
killall5
ln
login
logname
ls
lsmod
lsof
md5sum
mkdir
mkfifo
mknod
mkswap
modprobe
more
mount
mpstat
mv
nbd-client
netstat
nice
nohup
nslookup
passwd
pidof
ping
ping6
pivot_root
pmap
poweroff
printenv
printf
ps
pstree
pwd
pwdx
readlink
realpath
reboot
renice
reset
rm
rmdir
rmmod
route
sed
seq
setconsole
setserial
sh
sha3sum
sleep
smemcap
sort
stat
stty
swapoff
swapon
switch_root
sync
sysctl
tail
tar
tee
telnetd
test
tftp
time
top
touch
tr
traceroute
true
tty
ubiattach
ubidetach
ubimkvol
ubirmvol
ubirsvol
ubiupdatevol
umount
uname
uniq
unxz
unzip
uptime
vconfig
vi
wc
wget
whois
xargs
xz
xzcat
zcat
Es ist also auch hier tatsächlich ein telnetd in der BusyBox, der Symlink (wenn man mal unterstellt, daß auch da der AVM-Patch eingebaut ist) fehlt aber natürlich. Allerdings könnte es hier (kommen wir gleich zu) noch viel einfacher und "angenehmer" funktionieren, den einfach wieder hinzuzufügen.
Zwei Brandings sind enthalten ... logischerweise "avm" und eben auch "1und1" - bei der Vermarktung als 1&1-Business-Server sicherlich wenig überraschend.
Es sieht ein wenig so aus, als wäre da tatsächlich ein ubifs-Layer beim Flash dazugekommen, jedenfalls für ausgewählte MTD-Devices (filesystem (2x 44 MB) + config (2 MB) + "userdata" (der "Rest" vom NAND, wie üblich als /var/media/ftp gemountet)) ... das würde dann ein komprimierendes NAND-Filesystem sein, was die Vorteile (mehr Daten passen rein und trotzdem ist es read/write-able) kombiniert - aber das muß man wohl erst mal am lebenden Objekt sehen, es wäre ja nicht der erste Blinddarm in der Firmware.
Wenn dem so wäre, würde aber das SquashFS-Format in der FRITZ!Box wieder entfallen - das Dateisystem im Recovery-Programm ist aber ein SquashFS-Image und das Installieren in die ubifs-Partition erfolgt direkt durch das Schreiben des zuvor gesicherten Inhalts eines mtdram-Devices in das (auf ein ubi-Volume abgebildete) MTD-Device für das Dateisystem.
Wenn man hier die Kernelversion beim Spekulieren zugrunde legt, könnte man fast auf die Idee kommen, daß AVM bei der 7580 (dem Kernel nach ja schon wesentlich älter als die derzeitigen VR9-Modelle) mal mit ubifs experimentiert hat und damit aber nicht zufrieden war und deshalb bei den VR9-Modellen doch beim alten Schema geblieben ist oder der VR9 war dann doch zu lahm, um im laufenden Betrieb zu komprimieren - wobei letzteres eigentlich Quatsch sein sollte, denn erstens wird da fast nie geschrieben (obwohl so ein ubifs eben auch teilweise Updates von einzelnen Komponenten ermöglicht hätte) und zweitens kenne ich ganz andere Geräte (in erster Linie Linux-STBs), die das auch schaffen und die haben meist noch schwächere Prozessoren, weil der ganze DVB-Kram in Hardware erledigt wird.
Auf alle Fälle wird hier "modfs" erst einmal nicht auf Anhieb funktionieren ... bei ubifs gäbe es auch ganz andere Möglichkeiten der Modifikation - vielleicht wurde es ja bei den VR9-Modellen auch deshalb wieder verworfen.
Aus /dev/ttyS0 wurde /dev/ttyLTQ0 (zumindest in der inittab) ... ob es dieselbe Major- und Minor-ID ist, muß man wieder im laufenden System sehen, komischerweise gibt es in /dev kein ttyLTQ0 - da fragt man sich schon, wo das herkommen soll.
Wie es aussieht, gibt es ein Kommando "ppacmd", mit dem man das Verhalten des Packet-Accelerators in vielen Aspekten beeinflussen kann ... das könnte ja mal richtig interessant werden. Auch für den Packet-Classifier beim QoS scheint es ein Programm zur Steuerung zu geben (das nennt sich "cli") - vielleicht ist es mit weiteren zusätzlichen Programmen ja wirklich mal möglich, da ein flexibleres QoS-Management aufzubauen, zumindest gibt es dafür jetzt einen Daemon (qosd) in der Firmware, während es vorher und nachher (beim VR9 mit 3.10.73) wohl alles im dsld/kdsld enthalten ist.
Mit "switch_cli" ist hier wohl auch das Lantiq-Utility in der Firmware enthalten, was man schon länger in den Beispielen für die Switch-Treiber sehen konnte und mit dem man fast jeden Aspekt des Switches auch konfigurieren kann ... vorausgesetzt, die Device-Treiber für den Switch (/dev/switch/n und /dev/switch_api) sind auch im Kernel enthalten (als LKM gibt es sie wohl nicht oder sie heißen komisch). Wenn das aber klappen sollte, dann müßte man endlich auch (Hardware-)VLAN auf den Switch-Ports realisieren können und dann klappt es ja vielleicht auch mit bis zu vier (per VLAN) getrennten lokalen Netzen.
