Bootmanager und FIT?
fda77 opened this issue · 315 comments
Bootmanager funktioniert nicht mit "FIT" Geräten: Freetz-NG/freetz-ng#465 (comment)
Hast du geplant das zu unterstützen?
Sollten die Eckdaten vorliegen, die zur Unterstützung dieser Modelle benötigt werden, kann/würde ich das einbauen.
Ich bin ohnehin gerade am Boot-Manager dran - gestern kam (im Branch) der Teil hinzu, der die Erkennung, ob der Bootloader die Änderungen am Branding zuläßt oder nicht, bereitstellen soll. Dafür sind auch einige Operationen mit dd, cmp und grep erforderlich - da sollte es dann auch kein echtes Problem sein, einen "flattened (u)image tree" so zu zerlegen (aber eben immer nur mit den Bordmitteln, weil das auch ohne Freetz oder ausgetauschte BusyBox funktionieren soll), daß man die "Stammdaten" für das jeweilige System auslesen kann.
Nach dem, was man bisher über die Modelle mit FIT weiß, speichern die ja das gesamte Image in jeweils einer größeren Partition pro vorhandenes System. Daraus folgt dann für mich auch, daß man zur Analyse, ob da ein funktionsfähiges System installiert ist oder nicht, nicht einfach nur ein SquashFS-Image mounten und darin nach ein paar Infos suchen muß, sondern man muß sich erst einmal auf die Suche nach diesem SquashFS-Image machen und das dann auch noch so mounten, daß dabei möglichst wenig zusätzlicher Ressourcenbedarf entsteht, was dann das "Extrahieren" des SquashFS-Images als gesonderte Datei schon fast wieder verbietet. Also müßte man dabei vermutlich wieder mit Loop-Devices und Offsets hantieren, was auch von vielen Faktoren (bis hin zu "alignment issues") abhängen kann.
Was (für mich zumindest) aber nicht akzeptabel wäre, ist die Notwendigkeit zusätzlicher Pakete (solange sie sich vermeiden lassen, was nicht immer möglich ist, denn Kryptopgrafie in Shell ist natürlich Unsinn - zumindest jenseits von PoC) - da müßte dann also erst mal das Zerlegen eines FIT-Images mit (AVM-)Bordmitteln implementiert werden.
Ansonsten müßte man sich auf das platte Umschalten (wenn das da überhaupt funktionieren sollte - dazu habe ich auch noch nichts gelesen) von linux_fs_start verlegen - das ist bisher zumindest auch noch nicht vorgesehen bei mir, weil mir "blinde" Aktionen (wo ich dann nicht mal weiß, ob das alternative System überhaupt existiert und lauffähig ist) eigentlich widerstreben.
Um das Einbauen zu können, braucht es folgende (Er-)Kenntnisse:
- irgendetwas für die zuverlässige Identifikation des Modells/Prozessors, um daraus die Infos zum Aufbau des Systems abzuleiten
- Ausgabe von /proc/cpuinfo
- Ausgabe von /proc/mtd
- gibt es (analog zu den Puma-Modellen mit ihrem
/proc/avm_partitions) irgendwelche zusätzlichen Pseudo-Files, die nahrhafte Informationen zum laufenden und zum inaktiven System liefern könnten? - irgendwo war mir mal eine neue Environment-Variable für EVA untergekommen (
linux_fs_status), die ich mit Aussagen zu den installierten Systemen in Verbindung gebracht hatte - ist so etwas bei diesen Modellen vorhanden im Environment? - am besten gleich auch noch eine vollständige (ggf. maskierte) Kopie des Urlader-Verzeichnisses aus dem TFFS-Treiber, wenn AVM auch da weiterhin mit
/proc/sys/urladerarbeiten sollte - Was macht eigentlich das
bootslotctlin dem Skript zur Installation aus dem RAM (/etc/init.d/E03-flash_update) genau? Schaltet das schon irgendetwas um oder speichert es nur die Infos für das neue System, was bisher immer infirmware_infobei jedem Start neu gesetzt wurde? - In diesem Skript sieht es auch so aus, als würde in eine Partition mit dem Namen
fit-imageinstalliert ... nur wie heißt dann die Partition für das andere System? Dasgrep, mit dem die ID ermittelt wird, würde die Zeichenkettefit-imageauch dann finden, wenn sie nur ein Teil des Partitionnamens wäre - damit dürften da keine Zusätze wiereservedverwendet werden für das alternative System. Oder dieser Name ist am Ende auch nur derjenige, welcher für das FIT-Image im RAM(!) verwendet wird, wie bei anderen Modellen daskernel_ramundrootfs_ram? - Eigentlich sieht es in diesem Skript sogar so aus, als würde das
bootslotctlletztlich sogar das Schreiben des FIT-Images in die Zielpartitionen übernehmen, denn der ganze Rest darin befaßt sich nur noch mit dem UBI-Layer fürconfig- und NAS-Partition.
Das Installieren an sich mag zwar bei der Umschaltung nicht gebraucht werden, aber man muß auch erst mal erkunden, ob es noch andere Mechanismen gibt, die sich mit einem Umschalten durch Schreiben nach /proc/sys/urlader/environment ins Gehege kommen (auch das /var/install-Skript in den AVM-Images für diese Modelle schreibt ja gar nicht mehr selbst nach linux_fs_start, sondern da ist auch alles nur noch ein Aufruf von bootslotctl) würden oder ob es auch einen direkten Aufruf von bootslotctl gäbe, der anstelle des Schreibens nach /proc/sys/urlader/environment verwendet werden könnte.
Gleichzeitig ist wohl das Binary bootslotctl nur ein Shim für den Aufruf von Funktionen in der libbootslotctl und selbst die ist eher "winzig", auch wenn darin einige interessante Infos zu finden sind, wenn man mal ein strings auf sie losläßt (auszugsweise hierher kopiert):
bootslotctl_get_other
bootslotctl_activate_other
bootslotctl_commit_other
bootslotctl_get_active
bootslotctl_get_committed
bootslotctl_commit_this
bootslotctl_get_fw_version
bootslotctl_on_boot
bootslotctl_program_other
/var/bootedslot
cannot parse currently booted slot
slot%d=
invalid slot
firmware_info
linux_fs_start
linux_fs_status
slot%1d
bootslotctl has already been initialized.
fit%d
invalid slot
/sys/class/mtd
/sys/class/mtd/%s/name
/dev/%s
MTD for slot %d not found.
open mtd
CONFIG_ENVIRONMENT_PATH
CONFIG_ENVIRONMENT_PATH not set
%s/environment
CONFIG_ENVIRONMENT_PATH invalid
Cortex-A9
Das CONFIG_ENVIRONMENT_PATH i.V.m. dem %s/environment würde schon mal darauf hindeuten, daß da tatsächlich auch noch das TFFS-Interface im procfs verwendet wird (und die Library dann Sachen wie get_active oder activate_other auch nur über dieses Interface abwickelt) - gleichzeitig sehen einige Dinge (get_active, get_other, activate_other und get_fw_version) so aus, als gäbe es da schon ein paar Funktionen, die man vielleicht nachnutzen kann, anstatt das alles selbst machen zu wollen.
Denn auch ein Blick in das Binary bootslotctl zeigt ein paar Strings, die durchaus für die hier benötigten Funktionen stehen könnten:
get_committed
get_active
get_other
commit_this
activate_other
commit_other
on_boot
is_committed
is_active
get_fw_version
program_other
und damit vielleicht schon bei AVM eine neue "Abstraktionsschicht" bieten, hinter der Unterschiede der Modelle in der Zukunft mal verschwinden sollen.
Aber das oben Geschriebene zeigt für mich auch deutlich, daß man noch viel zu wenig über den "inneren Aufbau" dieser Boxen weiß (das Zerlegen des AVM-Images ist das eine, das Verstehen der inneren Funktionen etwas anderes), um das mal eben aus dem Handgelenk zu schütteln.
Ich bin auch nicht davon überzeugt, daß man das (in endlicher Zeit) implementieren bzw. erst mal richtig erkunden kann, wenn man keine eigene Box dazu hat. Die Kommunikation gestaltet sich da schon dann schwierig, wenn zwei Seiten in etwa auf demselben Stand der Skills sind - je weiter der auseinander liegt, um so schwieriger wird das am Ende auch.
Aber man könnte es tatsächlich mal versuchen ... nur darf man die Erwartungen an (schnelle) Fortschritte dann auch nicht zu hoch hängen, außer jemand schafft es tatsächlich, das alles weitgehend selbständig zu ermitteln und die Erkenntnisse mit anderen zu teilen.
Falls sich Boxen mit diesem Aufbau bei AVM mehren sollten (bisher sind es m.W. noch nicht soo viele und nach meinem Dafürhalten auch nicht unbedingt Geräte aus dem Mainstream), lohnt sich das sicherlich in jedem Falle, sich damit zu befassen.
BTW ... die "Liste" oben, was man an Infos bräuchte, ist auch nur ein Anfang und erhebt keinerlei Anspruch auf Vollständigkeit - einiges an weiterem "Forschungsbedarf" ergibt sich auch erst aus den ersten Infos, die man dann erhält.
Ohne eigenes Gerät ist es schwer das umzusetzen. Immerhin funktioniert Freetz überhaupt, finde ich überraschend :D Als Identifikation reicht SEPARATE_FILESYSTEM_IMAGE in Freetz, nur dann werden die Bootmanager installiert, aktuell für FIT nicht mehr. Falls das herkömmliche mounten der 2. Partition nicht funktioniert, probiert man einfach die noch nicht vorhandene fit-Methode...
Ich schick dir mal jemanden vorbei.
Wenn ein freetz der BM aktualisiert werden soll, sag bescheid
Wenn ein freetz der BM aktualisiert werden soll, sag bescheid
Ich warte im Moment noch auf positive Rückmeldungen für die Änderungen, damit das auch mit 07.39 funktioniert. Zwar habe ich das so umgesetzt, daß es auch mit früheren OS-Versionen genauso läuft (bei mir auf einer 7490 getestet), aber das sagt mir nur, daß das gewählte Prinzip so funktioniert und noch fehlt die Info, ob das dann auch schon alles war, was geändert werden mußte, damit es mit 07.39 und folgenden Versionen (erst mal) wieder klappt.
Liegt also nur zum Teil in meinen Händen ... außer ich habe irgendwann genug vom Warten und mache auch ohne Feedback ein Merge - eigentlich nicht so ganz meins, wenn ich das nicht doch schon selbst getestet habe.
Laut https://boxmatrix.info/wiki/FRITZ!Repeater_6000 gibt es um Urlader
firmware_info: 253.07.19,slot1=07.19-85142,slot0=07.19-85252
Ich weiß ... aber ich würde gerne die Zusammenhänge verstanden haben, bevor ich da irgendetwas baue.
Ich bin ja auch der Ansicht, daß ein bootslotctl get_fw_version (sofern das funktioniert, wovon ich aber ausgehe) seine Informationen irgendwo her holen wird - vielleicht ist es genau diese Erweiterung der Angaben in firmware_info, aber das wüßte ich eben gerne genau und das kriegt man halt nur heraus, wenn man die Daten mal ändert und dann schaut, ob sich die Ausgabe von bootslotctl ebenfalls ändert.
Wie geschrieben ... ohne passendes Gerät und immer nur aus zweiter Hand ist das einigermaßen schwierig. Mein Problem ist nur, daß ich keinen DSL-Anschluß mehr nutze und da man für schnelle Erfolge beim Untersuchen einer Box am besten auch gleich noch die Serielle bestückt, kann man die auch nicht einfach nur erwerben, mal 2 Wochen untersuchen und dann wieder gebraucht verkaufen (jedenfalls nicht ohne gehörigen Verlust).
Abgesehen davon, sind das im Moment alles ohnehin Mondpreise, die ich schon aus Prinzip nicht zu zahlen bereit bin, nicht mal als Betriebsausgabe und dann müßte man das auch noch passend begründen, daß man mit dem Kauf eine Gewinnerzielungsabsicht hatte und es nicht nur "Hobby" ist, was bei OpenSource-Projekten schon schwierig ist.
cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
model name : ARMv7 Processor rev 4 (v7l)
cpu MHz : 2208.000
BogoMIPS : 51.34
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Generic DT based system
Revision : 0000
Serial : 0000000000000000
cat /proc/mtd
dev: size erasesize name
mtd0: 011fc000 00001000 "rootfs_ram"
mtd1: 01000000 00400000 "nand-tffs"
cat /proc/avm_partitions
cat: can't open '/proc/avm_partitions': No such file or directory
cat /proc/sys/urlader
cat /proc/sys/urlader/environment
DMC SL1
HardwareFeatures cpu=390.2.0,emmc=5.0.17.0.2
HWRevision 253
HWSubRevision 3
ProductID Fritz_Box_HW253
SerialNumber xxxxxxxxxxxxxxxxxxxxx
annex Ohne
autoload yes
bootloaderVersion 1.11317
country 049
crash [0]0,0,0[1]0,0,0[2]1dc7adad,62146a70,6[3]0,0,0
firstfreeaddress 0x50500000
firmware_info 253.07.29,slot1=07.29-93257,slot0=07.29-93257
firmware_version avm
flashsize nor_size=0MB sflash_size=0KB nand_size=0MB emmc_size=1888MB
language de
linux_fs_start 0
maca xx:xx:xx:xx:xx:xx
macb xx:xx:xx:xx:xx:xx
macwlan xx:xx:xx:xx:xx:xx
macwlan2 xx:xx:xx:xx:xx:xx
macwlan3 xx:xx:xx:xx:xx:xx
macdsl xx:xx:xx:xx:xx:xx
memsize 0x40000000
mtd0 0x0,0x0
mtd1 0x3000000,0x8000000
mtd2 0x0,0x2000000
mtd3 0x2000000,0x3000000
mtd4 0x8000000,0xD000000
mtd5 0xD000000,0x75BFC000
my_ipaddress 192.168.178.1
prompt Eva_AVM
ptest
usb_rndis_mac xx:xx:xx:xx:xx:xx
wlan_key xxxxxxxxxxxxxxxxxxxxx
wlan_ssid FRITZ!Repeater#6000
da sind 4 datein drin aber alle leer
Die Preise aktuell sind unmöglich, ich hätte gern noch einen Pi4, bin aber nicht bereit das doppelte wie vor 1 Jahr zu bezahlen. Für einen zb Repeater 6000 braucht man kein DSL ;-)
Und die Ausgabe von "bootslotctl get_fw_version"? Schau mal was dieses Programm noch so hergibt
Wie rufe ich denn genau ab
Schau mal was dieses Programm noch so hergibt
???
Habe ich doch schon ... schließlich gibt's oben u.a. ein strings vom Binary. Ohne System, auf dem man das ausführen kann, ist das aber auch nicht wirklich aussagekräftig.
Einen Repeater brauche ich nicht ... in meine obere Etage führt ein GbE-fähiges UTP-Kabel und da gibt es einen weiteren AP bzw. Ethernet für Fernseher (RPi mit LibreElec) und alles das, was man sonst noch so braucht. Das ist also auch kein Argument gegenüber dem FA, einen Repeater als Betriebsausgabe geltend zu machen, auch wenn der heute noch bei unter 250 EUR liegt und sofort abgeschrieben werden kann. Bei den Boxen wird das dann schon schwerer ... ab 250 EUR netto sind bei manchen Modellen auch drin.
OK, daß in /proc/mtd so wenig steht, ist wieder verständlich ... das ist offenbar alles eMMC und dann finden sich die Partitionen bei den Block-Devices bzw. mit einem blkid, wobei das vielleicht bei den Partitionen für die FIT-Images das installierte FS nicht erkennen könnte (keine Ahnung, ob das zum Standard-Repertoire von blkid gehört oder AVM das aufgebohrt hat). Aber irgendwo wird AVM die Partitionen schon "mit Namen" verwalten (das macht man dort ja praktisch immer so - die /proc/avm_partitions bei dem Puma-Geräten wäre ein Beispiel dafür) ... man muß es jetzt nur irgendwo finden.
Sind bei einem cat /sys/class/mtd/*/name auch nur zwei MTD-Partitionen zu sehen oder emuliert AVM da dann doch noch irgendwelche TFFS-Partitionen über ein MTDRAM-Device, wie bei den Puma7-Geräten (iirc jedenfalls)? Unsinn, das emulierte nand-tffs steht ja oben in der Ausgabe von /proc/mtd schon ... wenn das also eine MTD-(NAND-)Partition sein soll, während das Gerät nur eMMC-Speicher bietet (das ist ja nur noch "cooked MTD" 😁), dann muß das auch eine Emulation sein.
Wobei ich mich hier jetzt erst einmal ausklinke ... für so ein "Ping-Pong" fehlt mir im Moment mal wieder die Zeit (und auch etwas die Geduld, bitte nicht falsch verstehen) - ich muß mal wieder etwas "richtiges" machen.
Korrektur oben bzgl. der Emulation für's TFFS
Und wenn ich mich nicht schwer irre, sind 17 MB des vorhandenen Hauptspeichers schon mal dadurch belegt, daß hier das Wurzeldateisystem für das FRITZ!OS in den Hauptspeicher kopiert wurde (das dürften die etwas mehr als 17 MB in /proc/mtd0 sein) - da wäre dann auch mal die Ausgabe der Kommandos mount und df -h interessant, um sich die Verteilung der Dateien und ggf. auch weitere Mountpunkte (vielleicht sogar mit Overlays?) anzusehen.
/proc/avm_partitions
^^ habe ich nicht
cat /sys/class/mtd/*/name
rootfs_ram
nand-tffs
mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=438452k,nr_inodes=109613,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
none on /sys/kernel/debug type debugfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
df -h
/dev/root 18.0M 18.0M 0 100% /
devtmpfs 428.2M 0 428.2M 0% /dev
tmpfs 428.3M 1.0M 427.3M 0% /var
Danke.
Blieben noch blkid und der Aufruf von bootslotctl mit den Parametern, die vermutlich erst einmal unkritisch sind:
get_active
get_other
is_active
get_fw_version
Mancher Aufruf braucht vermutlich noch einen weiteren Parameter als Angabe des zu verwendenden "slot"s ... da muß man dann etwas probieren, wie das richtig sein könnte (0/1 oder 1/2 oder irgendetwas ganz anderes - das hängt auch etwas vom Ausgabeformat bei get_active und get_other ab).
Wenn man sich einigermaßen mit den Möglichkeiten zum "Recovern" auskennt (das meint mehr den Umgang mit EVA-FTP als das AVM-Programm) oder in beiden Partitionsets eine lauffähige Version installiert hat, könnte man auch noch bootslotctl activate_other probieren. Sollte danach das System nicht direkt neu starten (das also nur die vermutete Umschaltung bewirken und kein Reboot), kann man auch noch einmal in /proc/sys/urlader/environment nachsehen, ob linux_fs_start dadurch umgeschaltet wurde (dazu muß man natürlich auch den vorherigen Wert kennen).
Auch wäre dann interessant, ob ein wiederholter Aufruf immer wieder zwischen 0 und 1 hin und her schaltet oder ob das eine Einbahnstraße vom laufenden zum alternativen System ist, weil die Info, wer nun "other" wäre, irgendwo anders hinterlegt ist (es sollte u.a. eine /var/bootedslot geben, deren Inhalt dabei interessant wäre - wenn der Name auch Programm ist, ändert sich deren Inhalt bis zum nächsten Start ja nicht mehr).
Da man durch diese Verwendung von bootslotctl keine Einzelheiten der Installation mehr sieht, wäre auch ein Dump einer der FIT-Partitionen hilfreich (dazu muß das blkid aber erst mal Infos liefern, welches Block-Device das wäre) ... die Frage dabei ist, ob das Image dort 1:1 hineinkopiert wurde oder ob es irgendwelche Transformationen gab. Dazu kann man dann den eigenen Dump dieser Partition mit der Image-Datei aus einem Firmware-Update (oder auch dem Freetz-Image) vergleichen, ggf. ist der Dump der Partition dabei größer und der Rest nach der Länge des zu vergleichenden Images kann/muß ignoriert werden.
blkid
-sh: blkid: not found
bootslotctl get_active 0/1
0
bootslotctl get_active 1/2
0
bootslotctl get_other
1
bootslotctl is_active
nichts kommt da
bootslotctl get_fw_version
illegal argument
bootslotctl activate_other
nichts kommt da
cat /proc/sys/urlader/environment
linux_fs_start 1
linux_fs_status 1
reboot gemacht
bootslotctl activate_other
cat /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl activate_other
cat /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
also es bleibt so
cat /var/bootedslot
kommt nichts
OK, nochmal danke.
Ein paar Mißverständnisse gilt es auszuräumen ...
bootslotctl get_active 0/1
Das war so natürlich nicht gemeint ... und beim get_active wird sicherlich auch kein Parameter benötigt, denn da gibt es ja nichts "auszuwählen" ... der aktive "slot" ist halt der aktive und der andere nicht.
Aber die Ausgabe mit der 0 dürfte ein sicheres Zeichen dafür sein, daß AVM diese "slots" mit 0 und 1 nummeriert und nicht - wie bei Puma7-Geräten beim pumaglued bzw. avm_uimg_update auch schon gesehen (https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/page-2#post-2451203) - mit 1 und 2.
Damit sollte aber auch die Frage beantwortet sein, was bei get_other ausgegeben wird - halt auch die Nummer des "other slot".
Die könnte man zwar auch wieder "errechnen", aber wenn AVM mal mit drei (gleichrangigen) Systemen im Flash auflaufen sollte, funktioniert solche "Binärarithmetik" ggf. nicht länger, während ein get_other immer noch die Nummer des nächsten zu benutzenden Slots ausgeben könnte. (BTW - ich übernehme jetzt das englische "slot" von AVM auch als deutschen "Slot", das ist einfacher als "Partition-Set").
Beim get_fw_version wird dann sicherlich noch die Angabe der Slot-Nummer erwartet, also bootslotctl get_fw_version <0|1> und auf STDOUT wird es dann vermutlich die Versionsnummer ausgeben. Beim bootslotctl is_active <0|1> wird sicherlich nur der Exit-Code entsprechend gesetzt, also sollte man da noch ein ; echo $? an den Aufruf anhängen und das mit beiden Nummern mal testen (unter Kenntnis, was da gerade im (Urlader-)Environment steht).
Beim activate_other werde ich gerade nicht so richtig schlau aus dem Ablauf ... bitte mal die folgende Sequenz abarbeiten:
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active <=== hier geht es darum, ob nach der Umschaltung, die beim `activate_other` wohl erfolgt, sich auch ohne Reboot schon das Ergebnis von `get_active` ändert
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
bootslotctl get_active
... damit sollte einmal auf das alternative System umgeschaltet werden und einmal zurück - wenn dieses activate_other nicht doch eine Einbahnstraße ist.
Bei der /var/bootedslot wäre eine Anzeige mittels ls -l notwendig - die Frage, die sich mir da stellt, ist die, ob die Datei gar nicht existiert oder doch leer ist (ohne Fehlermeldung sollte man "leer" annehmen), aber ggf. ist das auch ein Symlink irgendwohin o.ä.
Wenn das ein Repeater ist, dann erklärt das ein Fehlen von blkid in der AVM-Firmware (wo es ansonsten für die NAS-Mounts auch benötigt würde) ... aber warum das dann in Freetz-NG nicht eingebaut wird (daß man es immer mal brauchen könnte, zeigt ja dann schon dieser Fall hier und die Größe des Applets (die auch nicht überwältigend ist), sollte hier ja nun auch keine entscheidende Rolle spielen), weiß ich auch nicht.
Zwar könnte man auch zu Fuß durch die Block-Devices ziehen, aber irgendetwas in der Richtung blkid oder auch fdisk ist deutlich einfacher. Wobei hier auch wieder blkid vorzuziehen wäre, denn damit kann man nicht soviel Unsinn anrichten wie mit einem falsch bedienten fdisk - daher würde ich verstehen, wenn es dieses Applet in Freetz-NG auch nicht gibt.
Als ersten Test könnte man noch ein ls -l /dev/mmc* verwenden, um überhaupt erst einmal zu prüfen, daß der eMMC-Speicher tatsächlich als partitioniertes Block-Device genutzt wird. Dem Environment nach zu urteilen, gibt es (mind.) fünf Partitionen im Flash:
mtd0 0x0,0x0
mtd1 0x3000000,0x8000000
mtd2 0x0,0x2000000
mtd3 0x2000000,0x3000000
mtd4 0x8000000,0xD000000
mtd5 0xD000000,0x75BFC000
mtd0 kann man sicherlich ignorieren (von Adresse 0x0 bis 0x0 ist nicht wirklich viel Speicher zu erwarten), ansonsten sind da 32 MB als mtd2, in denen vermutlich - wie bei AVM üblich - wieder der Bootloader EVA stehen wird. mtd1 und mtd4 sind jeweils 60 MB groß und nehmen vermutlich die FIT-Images auf (die Nummerierung ist die Sicht des Bootloaders, bitte nicht mit den Nummern im laufenden System verwechseln). Was sich hinter mtd3 in den dort vorhandenen 16 MB verbirgt, kann man (vorerst) nur raten - und offenbar liegen beim FR6000 dann die knapp 1,7 GB, die oben in mtd5 verwurstet wären, brach, denn bei dem wird auch kein UBI-Layer für diesen Teil verwendet (wie bei der 7530ax) und es fehlt praktisch alles beim udev (inkl. /etc/hotplug), da sonst noch so gebraucht würde.
Mir fällt im Moment auch nichts besseres als blkid ein (von den Applets/Paketen, die m.W. in Freetz enthalten sind), was man zum näheren Erkunden der verwendeten Partitionierung im Flash benutzen könnte - lsblk gibt es m.W. nicht und udisks ebenfalls nicht.
Aber ich habe dann doch noch einmal genauer in die Firmware gesehen ... immerhin gibt es noch den udevadm und mit dem sollte sich - in Kombination mit dem sysfs - dann doch noch eine Liste erstellen lassen und zwar so:
for n in /sys/class/block/mmc*; do echo ">>> $n <<<"; udevadm info -q property -n ${n##*/}; done
Mal sehen, ob man da dann etwas mehr ablesen kann.
Und für die Frage, ob das FIT-Image 1:1 in die Partitionen kopiert wird, gibt es auch noch eine andere Lösung. Dazu muß man allerdings wissen, welche Datei fit-image installiert ist und deren Länge ermitteln. Zusätzlich läßt man dann ein md5sum über diese Datei laufen und merkt sich den Hash.
Danach kann man die beiden FIT-Partitionen dann mit einem dd if=<input_device> bs=256 count=$(( <fit-image-size> / 256 )) | md5sum (in der Annahme, daß die Image-Datei "aligned" ist und eine durch 256 teilbare Größe hat) traktieren ... dabei sollte eine der beiden (bei den Parametern für das dd aufpassen, sonst ist da auch mal schnell Unfug angerichtet) dann einen Hash-Wert liefern, der mit dem der Image-Datei übereinstimmt. Ist das nicht der Fall, kann man eine 1:1-Kopie ausschließen und muß sich näher damit befassen, was da wie von bootslotctl in den eMMC-Speicher geschrieben wird.
Bei AVM ist blkid normal eine binary, und das Applet in Freetz nicht auswählbar weil es weniger Parameter kennt die die AVM Scripte benötigen: https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/generate.sh#L176
Ausser man ersetzt auf altem FOS das mounting komplett mit FREETZMOUNT
Um es aktivierbar zu machen müsste man diese Zeile löschen: https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in.busybox.1_35#L4341 bzw in der 1_34 Datei
Allerdings gibt es in NG mittlerweile einen Mechanismus dass BB-Applets automatisch umbenannt werden falls es die Datei schon gibt: https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1291
https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in#L570
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 1
linux_fs_status 1
bootslotctl get_active
1
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl get_active
0
bootslotctl activate_other
grep linux_fs /proc/sys/urlader/environment
linux_fs_start 0
linux_fs_status 1
bootslotctl get_active
0
ls -l /var/bootedslot
-rw-r--r-- 1 root root 1 Jan 1 1970 /var/bootedslot
ls -l /dev/mmc*
brw------- 1 root root 179, 0 Jan 1 1970 /dev/mmcblk0
brw------- 1 root root 179, 1 Jan 1 1970 /dev/mmcblk0p1
brw------- 1 root root 179, 10 Jan 1 1970 /dev/mmcblk0p10
brw------- 1 root root 179, 11 Jan 1 1970 /dev/mmcblk0p11
brw------- 1 root root 179, 12 Jan 1 1970 /dev/mmcblk0p12
brw------- 1 root root 179, 13 Jan 1 1970 /dev/mmcblk0p13
brw------- 1 root root 179, 14 Jan 1 1970 /dev/mmcblk0p14
brw------- 1 root root 179, 15 Jan 1 1970 /dev/mmcblk0p15
brw------- 1 root root 179, 16 Jan 1 1970 /dev/mmcblk0p16
brw------- 1 root root 179, 17 Jan 1 1970 /dev/mmcblk0p17
brw------- 1 root root 179, 18 Jan 1 1970 /dev/mmcblk0p18
brw------- 1 root root 179, 19 Jan 1 1970 /dev/mmcblk0p19
brw------- 1 root root 179, 2 Jan 1 1970 /dev/mmcblk0p2
brw------- 1 root root 179, 20 Jan 1 1970 /dev/mmcblk0p20
brw------- 1 root root 179, 3 Jan 1 1970 /dev/mmcblk0p3
brw------- 1 root root 179, 4 Jan 1 1970 /dev/mmcblk0p4
brw------- 1 root root 179, 5 Jan 1 1970 /dev/mmcblk0p5
brw------- 1 root root 179, 6 Jan 1 1970 /dev/mmcblk0p6
brw------- 1 root root 179, 7 Jan 1 1970 /dev/mmcblk0p7
brw------- 1 root root 179, 8 Jan 1 1970 /dev/mmcblk0p8
brw------- 1 root root 179, 9 Jan 1 1970 /dev/mmcblk0p9
brw------- 1 root root 179, 32 Jan 1 1970 /dev/mmcblk0rpmb
for n in /sys/class/block/mmc*; do echo ">>>
>>> /sys/class/block/mmcblk0 <<<
DEVNAME=/dev/mmcblk0
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0
DEVTYPE=disk
MAJOR=179
MINOR=0
NPARTS=20
SUBSYSTEM=block
>>> /sys/class/block/mmcblk0p1 <<<
DEVLINKS=/dev/disk/by-partlabel/alignto512
DEVNAME=/dev/mmcblk0p1
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
DEVTYPE=partition
MAJOR=179
MINOR=1
PARTN=1
PARTNAME=alignto512
SUBSYSTEM=block
USEC_INITIALIZED=5066369
>>> /sys/class/block/mmcblk0p10 <<<
DEVLINKS=/dev/disk/by-partlabel/0:RPM_1
DEVNAME=/dev/mmcblk0p10
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p10
DEVTYPE=partition
MAJOR=179
MINOR=10
PARTN=10
PARTNAME=0:RPM_1
SUBSYSTEM=block
USEC_INITIALIZED=5065152
>>> /sys/class/block/mmcblk0p11 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CDT
DEVNAME=/dev/mmcblk0p11
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p11
DEVTYPE=partition
MAJOR=179
MINOR=11
PARTN=11
PARTNAME=0:CDT
SUBSYSTEM=block
USEC_INITIALIZED=5065361
>>> /sys/class/block/mmcblk0p12 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CDT_1
DEVNAME=/dev/mmcblk0p12
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p12
DEVTYPE=partition
MAJOR=179
MINOR=12
PARTN=12
PARTNAME=0:CDT_1
SUBSYSTEM=block
USEC_INITIALIZED=5063198
>>> /sys/class/block/mmcblk0p13 <<<
DEVLINKS=/dev/disk/by-partlabel/0:APPSBL
DEVNAME=/dev/mmcblk0p13
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p13
DEVTYPE=partition
MAJOR=179
MINOR=13
PARTN=13
PARTNAME=0:APPSBL
SUBSYSTEM=block
USEC_INITIALIZED=5062040
>>> /sys/class/block/mmcblk0p14 <<<
DEVLINKS=/dev/disk/by-partlabel/0:APPSBL_1
DEVNAME=/dev/mmcblk0p14
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p14
DEVTYPE=partition
MAJOR=179
MINOR=14
PARTN=14
PARTNAME=0:APPSBL_1
SUBSYSTEM=block
USEC_INITIALIZED=5062039
>>> /sys/class/block/mmcblk0p15 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CONFIG
DEVNAME=/dev/mmcblk0p15
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p15
DEVTYPE=partition
MAJOR=179
MINOR=15
PARTN=15
PARTNAME=0:CONFIG
SUBSYSTEM=block
USEC_INITIALIZED=5062593
>>> /sys/class/block/mmcblk0p16 <<<
DEVLINKS=/dev/disk/by-partlabel/0:CONFIG_1
DEVNAME=/dev/mmcblk0p16
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p16
DEVTYPE=partition
MAJOR=179
MINOR=16
PARTN=16
PARTNAME=0:CONFIG_1
SUBSYSTEM=block
USEC_INITIALIZED=5062099
>>> /sys/class/block/mmcblk0p17 <<<
DEVLINKS=/dev/disk/by-partlabel/fit0
DEVNAME=/dev/mmcblk0p17
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p17
DEVTYPE=partition
MAJOR=179
MINOR=17
PARTN=17
PARTNAME=fit0
SUBSYSTEM=block
USEC_INITIALIZED=5062599
>>> /sys/class/block/mmcblk0p18 <<<
DEVLINKS=/dev/disk/by-partlabel/tffs
DEVNAME=/dev/mmcblk0p18
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p18
DEVTYPE=partition
MAJOR=179
MINOR=18
PARTN=18
PARTNAME=tffs
SUBSYSTEM=block
USEC_INITIALIZED=5062589
>>> /sys/class/block/mmcblk0p19 <<<
DEVLINKS=/dev/disk/by-partlabel/fit1
DEVNAME=/dev/mmcblk0p19
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p19
DEVTYPE=partition
MAJOR=179
MINOR=19
PARTN=19
PARTNAME=fit1
SUBSYSTEM=block
USEC_INITIALIZED=5067733
>>> /sys/class/block/mmcblk0p2 <<<
DEVLINKS=/dev/disk/by-partlabel/0:SBL1
DEVNAME=/dev/mmcblk0p2
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
DEVTYPE=partition
MAJOR=179
MINOR=2
PARTN=2
PARTNAME=0:SBL1
SUBSYSTEM=block
USEC_INITIALIZED=5069494
>>> /sys/class/block/mmcblk0p20 <<<
DEVLINKS=/dev/disk/by-partlabel/data
DEVNAME=/dev/mmcblk0p20
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p20
DEVTYPE=partition
MAJOR=179
MINOR=20
PARTN=20
PARTNAME=data
SUBSYSTEM=block
USEC_INITIALIZED=5066961
>>> /sys/class/block/mmcblk0p3 <<<
DEVLINKS=/dev/disk/by-partlabel/0:BOOTCONFIG
DEVNAME=/dev/mmcblk0p3
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
DEVTYPE=partition
MAJOR=179
MINOR=3
PARTN=3
PARTNAME=0:BOOTCONFIG
SUBSYSTEM=block
USEC_INITIALIZED=5069028
>>> /sys/class/block/mmcblk0p4 <<<
DEVLINKS=/dev/disk/by-partlabel/0:BOOTCONFIG1
DEVNAME=/dev/mmcblk0p4
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
DEVTYPE=partition
MAJOR=179
MINOR=4
PARTN=4
PARTNAME=0:BOOTCONFIG1
SUBSYSTEM=block
USEC_INITIALIZED=5063488
>>> /sys/class/block/mmcblk0p5 <<<
DEVLINKS=/dev/disk/by-partlabel/0:QSEE
DEVNAME=/dev/mmcblk0p5
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p5
DEVTYPE=partition
MAJOR=179
MINOR=5
PARTN=5
PARTNAME=0:QSEE
SUBSYSTEM=block
USEC_INITIALIZED=5063535
>>> /sys/class/block/mmcblk0p6 <<<
DEVLINKS=/dev/disk/by-partlabel/0:QSEE_1
DEVNAME=/dev/mmcblk0p6
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p6
DEVTYPE=partition
MAJOR=179
MINOR=6
PARTN=6
PARTNAME=0:QSEE_1
SUBSYSTEM=block
USEC_INITIALIZED=5063593
>>> /sys/class/block/mmcblk0p7 <<<
DEVLINKS=/dev/disk/by-partlabel/0:DEVCFG
DEVNAME=/dev/mmcblk0p7
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p7
DEVTYPE=partition
MAJOR=179
MINOR=7
PARTN=7
PARTNAME=0:DEVCFG
SUBSYSTEM=block
USEC_INITIALIZED=5063922
>>> /sys/class/block/mmcblk0p8 <<<
DEVLINKS=/dev/disk/by-partlabel/0:DEVCFG_1
DEVNAME=/dev/mmcblk0p8
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p8
DEVTYPE=partition
MAJOR=179
MINOR=8
PARTN=8
PARTNAME=0:DEVCFG_1
SUBSYSTEM=block
USEC_INITIALIZED=5063926
>>> /sys/class/block/mmcblk0p9 <<<
DEVLINKS=/dev/disk/by-partlabel/0:RPM
DEVNAME=/dev/mmcblk0p9
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p9
DEVTYPE=partition
MAJOR=179
MINOR=9
PARTN=9
PARTNAME=0:RPM
SUBSYSTEM=block
USEC_INITIALIZED=5063949
>>> /sys/class/block/mmcblk0rpmb <<<
DEVNAME=/dev/mmcblk0rpmb
DEVPATH=/devices/platform/soc/7824900.sdhci/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0rpmb
DEVTYPE=disk
MAJOR=179
MINOR=32
NPARTS=0
SUBSYSTEM=block
OK, dann fasse ich mal zusammen, was sich an Erkenntnissen für den FR6000 hier ergeben hat.
eMMC-Speicher mit 2 GB Gesamtkapazität unter /dev/mmcblk0, partioniert folgendermaßen:
| part.no. | device | name | start | size |
|---|---|---|---|---|
| 1 | /dev/mmcblk0p1 | alignto512 | ? | ? |
| 2 | /dev/mmcblk0p2 | 0:SBL1 | ? | ? |
| 3 | /dev/mmcblk0p3 | 0:BOOTCONFIG | ? | ? |
| 4 | /dev/mmcblk0p4 | 0:BOOTCONFIG1 | ? | ? |
| 5 | /dev/mmcblk0p5 | 0:QSEE | ? | ? |
| 6 | /dev/mmcblk0p6 | 0:QSEE_1 | ? | ? |
| 7 | /dev/mmcblk0p7 | 0:DEVCFG | ? | ? |
| 8 | /dev/mmcblk0p8 | 0:DEVCFG_1 | ? | ? |
| 9 | /dev/mmcblk0p9 | 0:RPM | ? | ? |
| 10 | /dev/mmcblk0p10 | 0:RPM_1 | ? | ? |
| 11 | /dev/mmcblk0p11 | 0:CDT | ? | ? |
| 12 | /dev/mmcblk0p12 | 0:CDT_1 | ? | ? |
| 13 | /dev/mmcblk0p13 | 0:APPSBL | ? | ? |
| 14 | /dev/mmcblk0p14 | 0:APPSBL_1 | ? | ? |
| 15 | /dev/mmcblk0p15 | 0:CONFIG | ? | ? |
| 16 | /dev/mmcblk0p16 | 0:CONFIG_1 | ? | ? |
| 17 | /dev/mmcblk0p17 | fit0 | ? | ? |
| 18 | /dev/mmcblk0p18 | tffs | ? | ? |
| 19 | /dev/mmcblk0p19 | fit1 | ? | ? |
| 20 | /dev/mmcblk0p20 | data | ? | ? |
Was diese ganzen Partitionen jetzt beinhalten und wie groß sie jeweils sind, muß weiter geprüft werden.
Für die Größen wäre folgendes Kommando notwendig:
for n in /sys/block/mmcblk0/mmcblk0p*; do echo ">>> $n <<<"; cat $n/start; cat $n/size; done
Aber bei den Partitionen 17 und 19 kann man wohl zu Recht davon ausgehen, daß das diejenigen sind, wo die FIT-Images hineinkopiert werden. Nur die Frage, wie genau das geschieht, ist weiterhin offen. Der nächste Schritt wäre also, mit diesen beiden Partitionen mal den oben schon erwähnten Test des Inhalt durch md5sum zu machen (installiertes fit-image ansehen und Größe + MD5-Hash ermitteln, danach in der passenden Länge die Daten aus den beiden Partitionen kopieren und gleich über eine Pipe nach md5sum verwursten).
Das Umschalten des aktiven Systems ist - zumindest wenn man ausschließlich bootslotctl verwendet - dann offenbar doch eine Einbahnstraße, wie die Ergebnisse oben gezeigt haben. Nun wäre es halt noch interessant zu wissen, was beim bootslotctl get_fw_version <0|1> heraus kommt - dann kann man zumindest einschätzen, ob man diese Daten dazu verwenden kann, in der Anzeige eine Unterscheidung zwischen den installierten Systemen zu machen.
Ich würde zwar immer noch versuchen wollen, den Inhalt der SquashFS-Images für das aktuell laufende (das findet man ja unter / gemountet vor) und das "andere" System (das findet man dann in dessen FIT-Image) zu analysieren (weil nur dann die "Quelle" von Modifikationen und die alternativen Formen für das Ändern des Brandings erkannt werden können und das baue ich ja gerade für die bisher unterstützten Modelle ein), aber als "erster Schritt" wäre es ja schon mal hilfreich, wenn man irgendeine Versionsnummer auch ohne Zerlegen des FIT-Images auslesen könnte.
for n in /sys/block/mmcblk0/mmcblk0p*; do echo ">>> $n <<<"; cat $n/start; cat $n/size; done
>>> /sys/block/mmcblk0/mmcblk0p1 <<<
34
990
>>> /sys/block/mmcblk0/mmcblk0p10 <<<
20992
512
>>> /sys/block/mmcblk0/mmcblk0p11 <<<
21504
512
>>> /sys/block/mmcblk0/mmcblk0p12 <<<
22016
512
>>> /sys/block/mmcblk0/mmcblk0p13 <<<
22528
1024
>>> /sys/block/mmcblk0/mmcblk0p14 <<<
23552
1024
>>> /sys/block/mmcblk0/mmcblk0p15 <<<
24576
1024
>>> /sys/block/mmcblk0/mmcblk0p16 <<<
25600
1024
>>> /sys/block/mmcblk0/mmcblk0p17 <<<
98304
163840
>>> /sys/block/mmcblk0/mmcblk0p18 <<<
65536
32768
>>> /sys/block/mmcblk0/mmcblk0p19 <<<
262144
163840
>>> /sys/block/mmcblk0/mmcblk0p2 <<<
1024
1024
>>> /sys/block/mmcblk0/mmcblk0p20 <<<
425984
3432416
>>> /sys/block/mmcblk0/mmcblk0p3 <<<
2048
512
>>> /sys/block/mmcblk0/mmcblk0p4 <<<
2560
512
>>> /sys/block/mmcblk0/mmcblk0p5 <<<
3072
8192
>>> /sys/block/mmcblk0/mmcblk0p6 <<<
11264
8192
>>> /sys/block/mmcblk0/mmcblk0p7 <<<
19456
512
>>> /sys/block/mmcblk0/mmcblk0p8 <<<
19968
512
>>> /sys/block/mmcblk0/mmcblk0p9 <<<
20480
512
Wie schaut dann genau der Befehl aus für 17 und 19 ( dd if=<input_device> bs=256 count=$(( / 256 )) | md5sum )
bootslotctl get_fw_version 1
07.29-93257
get_fw_version 0
07.29-93257
07.29-93257
Ich hoffe mal, das liegt daran, daß da in beiden Slots dieselbe Version installiert ist.
Für den genauen Aufruf zum Testen der FIT-Partitionen müßte ich erst einmal wissen, WELCHES Image da installiert wurde:
ls -l fit-image
md5sum fit-image
Wo genau die Datei fit-image jetzt bei Dir liegt, kann ich nicht sagen. Wenn Du das System über ein (Freetz-NG-)TAR-Image installiert hast (das ginge ja erst ab dem zweiten Update, wenn das erste den passenden Key bereitgestellt hat), dann kannst Du diese Datei beim Entpacken des TAR-Images finden. Wenn Du das System über EVA installiert hast, ist es ja genau diese Datei, die dabei ins RAM geschrieben wurde - das ist praktisch wie beim Recovery-Programm für den FR6000.
Die Tabelle mit den Partitionen mache ich später neu und füge dabei die Angaben zu start und size hinzu. Die Werte stellen jeweils die Nummer des ersten (bei start) bzw. die Anzahl der zugeordneten Blöcke (bei size) dar, wobei ein Block 512 Byte umfaßt. Die Partitionen fit0 und fit1 wären dann jeweils 163.840 * 512 = 83.886.080 Byte groß oder auch 163.840 / 2 = 81.920 KByte bzw. exakt 80 MByte (jeweils mit 1024 als Faktor).
So groß sind aber auch die bisher aufgetauchten FIT-Images nicht und daher muß man auch die Überprüfung des Inhalts der Partitionen auf die Größe der darin gespeicherten Daten begrenzen.
Ja es wurde schon 2 oder 3-mal das Image neu geflasht, weil ja noch Fehler drin waren in freetz-ng die behoben worden und ich es testen sollte. Daher immer Version 07.29-93257
Das erste Mal habe ich es über push geflasht und jetzt kann ich nur noch über die AVM Webseite falshen. Da es über das freetz nicht ging. Daher ist das zurzeit auch deaktiviert
ls -l fit-image
ls: fit-image: No such file or directory
Edit
ls -l /dev/mmcblk0p19
brw------- 1 root root 179, 19 Jan 1 1970 /dev/mmcblk0p19
md5sum /dev/mmcblk0p19
03ff39fcd11c2e3d7d34f497749c5695 /dev/mmcblk0p19
ls -l /dev/mmcblk0p17
brw------- 1 root root 179, 17 Jan 1 1970 /dev/mmcblk0p17
md5sum /dev/mmcblk0p17
b99a762496766b2722994672ed7cdf41 /dev/mmcblk0p17
Aktiv ist zur Zeit linux_fs_start 1 also /dev/mmcblk0p19 sehe ich das richtig
Daher wollte ich mir noch eine weitere Box kaufen zB die 7530AX
jetzt kann ich nur noch über die AVM Webseite falshen.
Ich hoffe mal, daß hier anstelle von "nur noch" eigentlich "auch" gemeint ist - oder spricht irgendetwas dagegen, weiterhin Firmware über den Bootloader zu installieren? Der Mechanismus, das Image in den RAM zu laden und mit einer passenden "kernel command line" (wo hier ja sogar die "Anweisung" zu Installation eingeschlossen wird mit dem avm_fwupdate, was enthalten sein muß) dessen Installation anzustoßen, sollte ja als Alternative auch weiterhin funktionieren.
Damit findest Du aber die gesuchte Datei fit-image auf jeden Fall in der Verzeichnisstruktur Deines Freetz-NG-Builds ... irgendwo unterhalb von <freetz_ng_dir>/build/modified sollte die fertige Image-Datei liegen (und liegen bleiben, wenn das make fertig ist), denn von dort sollte sie in das TAR-File für die Image-Datei (auch wenn da vieles "image" heißt, ist der Inhalt doch jedesmal ein anderer) kopiert werden.
Die Prüfung, ob dieses Image dann 1:1 in die Partition (fit0 oder fit1, Du müßtest beide testen, solange Du nicht genau weißt, wo die Image-Datei vom LETZTEN Freetz-NG-Build installiert wurde) kopiert wurde, braucht die genaue Größe dieser Datei fit-image, weil dann auch nur in genau dieser Länge der Inhalt der Partition herauskopiert und ebenfalls an das md5sum weitergegeben werden kann. Stimmen die Daten (in der angegebenen Länge in der Partition) überein, sollte die Ausgabe von md5sum denselben Wert ergeben.
dd if=/dev/mmcblk0p17 bs=256 count=$(( <hier die Größe von fit-image eintragen> / 256 )) 2>/dev/null | md5sum
Die Zeile dann noch einmal für fit1 (das wäre dann mmcblk0p19 anstelle von mmcblk0p17) ausführen und die Ergebnisse aller Kommandos (beginnend mit denen für fit-image irgendwo unterhalb von Freetz-NG) dann bitte hier einstellen. Damit sollten langsam aber sicher die Angaben beisammen sein, um zumindest eine Umschaltung schon mal zu implementieren, auch wenn die Bedeutung und Verwendung vieler anderer Partitionen (im Bootprozess dieser Geräte) noch unklar ist.
So ich habe ein neues Image gebaut mit Freetz-NG habe dann das fit-image was unter build/modified/firmware/var/tmp dann liegt.
md5sum fit-image
0e5098920d4dccb852c0c8d5c6e0e745 fit-image
Habe nun per push_firmware das Image geflasht und da wird mir ja gesagt das der nächste sttart dann auf linux_fs_start 1 ist. Damit weiß ich ja jetzt das ich mmcblk0p19 benutzen muss.
Zur Sicherheit hab ich noch mal grep linux_fs /proc/sys/urlader/environment gemacht und es kommt linux_fs_start 1
dd if=/dev/mmcblk0p19 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum
8e958a84b94be4c8037fa87dda2f730f
Was aber dann die falsche md5sum Nummer ist.
dd if=/dev/mmcblk0p17 bs=256 count=$(( 22282240 / 256 )) 2>/dev/null | md5sum
0e5098920d4dccb852c0c8d5c6e0e745
Was ja jetzt die gleiche md5sum Nummer ist. Damit wird es dann doch 1zu1 kopiert. Verstehe ich das jetzt richtig.
Was mich aber wundert, wie kommt es, dass ich mmcblk0p17 benutzen muss
fit-image.zip
hat eine neue md5sum
5a983bbbe85db87b2bdac340e7cb841d fit-image
da ich das total überlesen habe das die haben willst. Und ich noch mal ein Image gebaut hatte.
Soll ich die auch noch mal Flashen zur Sicherheit
Was mich aber wundert, wie kommt es, dass ich mmcblk0p17 benutzen muss
Das finde ich jetzt nicht so überraschend, das gehört auch zu dem Teil, den ich verstehen wollte, bevor ich etwas implementiere.
Auf den Boxen ohne bootslotctl wird bei einem Update über AVM-GUI der "andere" Slot verwendet, während bei der Installation über den Bootloader/aus dem Hauptspeicher (das läuft auf dasselbe hinaus, denn über EVA wird das Image ja auch nur ins RAM geladen) der Inhalt von linux_fs_start gar nicht interessiert (zumindest an diesem Punkt nicht mehr, weil das alles schon im Kernel bei der Initialisierung ausgewertet wurde und auf der Basis von linux_fs_start die MTD-Namen entsprechend gesetzt sind) und immer nach kernel und filesystem (also ins aktive System) installiert wird.
Im Gegensatz dazu sieht das bei diesen Modellen hier so aus:
#! /bin/sh
set -e
. /etc/boot.d/msg
bootslotctl on_boot
if grep -q "\( \|^\)avm_fwupdate\( \|\$\)" /proc/cmdline
then
echo "found update request"
if update_mtd=$(grep \"fit-image\" /proc/mtd)
then
update_mtd="/dev/$(echo "$update_mtd" | sed "s/:.*//")"
echo "Updating $update_mtd -> other slot"
. /etc/boot.d/major_nr
modprobe led_module || true
mknod -m 666 /dev/led c "$(major_nr led)" 0 || true
trap /bin/update_led_off EXIT
/bin/update_led_on || true
bootslotctl program_other $update_mtd "${CONFIG_VERSION}-$(/etc/version --project)"
bootslotctl commit_other
_programmed=1
fi
fi
Die Installation erfolgt hier also IMMER in das "andere" System (program_other) und ich würde zunächst mal vermuten (ich schaue jetzt aber nicht nach), daß sich @fda77 bisher damit nicht befaßt hat (irgendetwas in der Richtung hatte ich iirc hier auch gelesen) und daher auch die "Aussage" von push_firmware für diese Modelle so nicht paßt. Das MTD als "Quelle" der Installation (das hat ja dann offenbar den MTD-Namen fit-image) dürfte wieder der Kernel anhand der "command line" einrichten, darum braucht sich das bootslotctl nicht mehr zu kümmern.
Auch beim Update über das GUI (egal ob mit AVM- oder eigener Signatur) erfolgt in der /var/install die Installation dann mit program_other - hier erfolgt dann die Angabe des FIT-Images als Datei und nicht als (character-)MTD:
/sbin/bootslotctl program_other /var/tmp/fit-image "${ver}-$(grep ^Build /var/content | cut -f2 -d=)" || exit 6
/sbin/bootslotctl "$_activate_action" || exit 6
was zwar am Ende zu demselben Ergebnis führt, wie bei anderen Modellen, aber der Weg dorthin unterscheidet sich schon deutlich.
Was mir hier auch zum ersten Mal aufgefallen ist, ist ein Unterschied beim Aufruf von /var/install beim "Downgrade" ... mit der Option -d bleiben die vorhandenen Einstellungen erhalten, während bei der Option -f die Box auf Werkseinstellungen zurückgesetzt wird. Auch die Option -t für /var/install gibt es bei anderen Plattformen nicht, wobei hier offenbar nur eine Umschaltung von linux_fs_start erfolgt, weil anstelle von commit_other dann nur ein activate_other verwendet wird.
Diese Abfolge program_other -> commit_other halte ich für eine transaktionssichere Installation des FIT-Images - vielleicht werden aber auch nur weitere Aktionen wie das Berechnen von Hash-Werten dadurch angestoßen und damit dann die Installation "abgeschlossen". Komisch ist jedenfalls, daß auch bei -t vor dem activate_other noch ein Aufruf von program_other erfolgt - wenn das schon ein Programmieren der Flash-Partition auslösen sollte, aber dann wegen des fehlenden commit_other die Änderungen nicht abgeschlossen werden, wäre das ja eine unnötige Belastung des Flash-Speichers (und würde obendrein die Integrität der anderen Angaben (slotX=... in firmware_version) durcheinander würfeln).
Daher tendiere ich eher dazu, daß sich das bootslotctl beim program_other die Angaben nur merkt (und ggf. eine Kopie des Images irgendwo ablegt) und sie auf Plausibilität/Gültigkeit prüft und erst beim commit_other dann tatsächlich in die Partition (und die anderen Stellen) geschrieben wird. Dann wäre das program_other nur die Vorbereitung des Flashens und Prüfung der Angaben und ohne commit_other ist das nur heiße Luft.
Das hat dann natürlich auch noch Auswirkungen darauf, wie man aus dem laufenden System "von Hand" die Image-Dateien ersetzen kann - ich würde hier (solange man nicht wirklich untersucht und verstanden hat, was das bootslotctl ggf. noch alles an zusätzlichen Schritten unternimmt, wenn es ein commit_other ausführen soll) auf das Kopieren der Datei fit-image von Hand in eine der Partitionen erst einmal verzichten - schließlich kann man ja das AVM-Programm auch gut "nachnutzen" (solange das im Rahmen eines AVM-Images erfolgt, denn ein Herauskopieren und die Verwendung an anderer Stelle, ist sicherlich wieder nicht von der AVM-Lizenz gedeckt).
Aber damit steht dann ja jetzt im Ergebnis auch fest, daß tatsächlich nur das Image 1:1 in die Partition kopiert wird ... das hilft schon mal weiter.
Ich würde mal versuchen (aber erst, wenn ich mit bootmanager 0.8.2 fertig bin), zunächst eine Version zusammen zu klöppeln, bei der zumindest die Anzeige der AVM-Version und die Umschaltung funktioniert, wobei das Ermitteln von Modifikationsdatum und -quelle erst mal unter den Tisch fällt - zumindest für das inaktive System, denn dafür muß man dann ins SquashFS-Image für dieses System schauen und dazu das FIT-Image erst einmal zerlegen. Dasselbe gilt für die Erkennung aller Infos hinsichtlich des Brandings, daher wird das zunächst auch nichts werden.
Wenn ich die vorläufige Version fertig habe, melde ich mich hier wieder ... der erste Test bräuchte ohnehin nur das Kopieren der Skript-Datei und den Aufruf aus einer Shell heraus - dafür muß man nicht jedesmal ein neues Image bauen.
Hier noch der Vollständigkeit halber die Partitionierung des eMMC-Speichers:
| part.no. | device | name | start (block) | size (blocks) | size (kB) |
|---|---|---|---|---|---|
| 1 | /dev/mmcblk0p1 | alignto512 | 34 | 990 | 495 |
| 2 | /dev/mmcblk0p2 | 0:SBL1 | 1024 | 1024 | 512 |
| 3 | /dev/mmcblk0p3 | 0:BOOTCONFIG | 2048 | 512 | 256 |
| 4 | /dev/mmcblk0p4 | 0:BOOTCONFIG1 | 2560 | 512 | 256 |
| 5 | /dev/mmcblk0p5 | 0:QSEE | 3072 | 8192 | 4.096 |
| 6 | /dev/mmcblk0p6 | 0:QSEE_1 | 11264 | 8192 | 4.096 |
| 7 | /dev/mmcblk0p7 | 0:DEVCFG | 19456 | 512 | 256 |
| 8 | /dev/mmcblk0p8 | 0:DEVCFG_1 | 19968 | 512 | 256 |
| 9 | /dev/mmcblk0p9 | 0:RPM | 20480 | 512 | 256 |
| 10 | /dev/mmcblk0p10 | 0:RPM_1 | 20992 | 512 | 256 |
| 11 | /dev/mmcblk0p11 | 0:CDT | 21504 | 512 | 256 |
| 12 | /dev/mmcblk0p12 | 0:CDT_1 | 22016 | 512 | 256 |
| 13 | /dev/mmcblk0p13 | 0:APPSBL | 22528 | 1024 | 512 |
| 14 | /dev/mmcblk0p14 | 0:APPSBL_1 | 23552 | 1024 | 512 |
| 15 | /dev/mmcblk0p15 | 0:CONFIG | 24576 | 1024 | 512 |
| 16 | /dev/mmcblk0p16 | 0:CONFIG_1 | 25600 | 1024 | 512 |
| 17 | /dev/mmcblk0p17 | fit0 | 98304 | 163840 | 81.920 |
| 18 | /dev/mmcblk0p18 | tffs | 65536 | 32768 | 16.384 |
| 19 | /dev/mmcblk0p19 | fit1 | 262144 | 163840 | 81.920 |
| 20 | /dev/mmcblk0p20 | data | 425984 | 3432416 | 1.716.208 |
Einigermaßen "straight forward" und mit einer Lücke von 26624 bis (inkl.) 65535 vor dem von AVM festgelegten Teil, nur bei den FIT-Partitionen und der Partition für die Speicherung der TFFS-Daten geht die Nummerierung etwas durcheinander, denn die TFFS-Partition liegt ja offenbar VOR der Partition fit0.
Nur die Frage, welche dieser Partitionen jetzt den Bootloader von AVM enthält, ist irgendwie noch offen. Dem Namen nach kämen da für mich die Partitionen 2, 13 oder 14 in Frage - das SBL wird vermutlich wieder ein "secondary boot loader" sein. Und da gäbe es ja mehrere Optionen ... entweder SBL1 ist direkt eine einzige Kopie von EVA oder die steht doch in APPSBL oder APPSBL_1 - da wäre dann die nächste Frage, ob tatsächlich zwei Kopien vorliegen und diese 1:1 übereinstimmen. Bei zwei Kopien könnte man ja auch wieder (sichere) Updates des EVA-Codes machen - wobei m.W. bisher noch keines dieser Modelle irgendein urlader_update in den AVM-Images hatte (zumindest die 7530ax nicht).
Wenn Du noch weitermachen willst, könntest Du noch ein grep wlan_key /dev/mmcblk0pX für die Partitionen 2, 13 und 14 machen - da, wo ein Treffer auftritt (das könnten auch mehrere sein), ist mit einiger Wahrscheinlichkeit auch EVA zu finden. Sollten es die beiden Partitionen 13 und 14 sein, kann man die noch einmal mittels cmp -l /dev/mmcblk0p13 /dev/mmcblk0p14 vergleichen, ob es Unterschiede gibt und welche das dann sind bzw. wie umfangreich sie wären.
Auch würde ich Dir durchaus eine Kopie des Bootloaders (einfach mit cat /dev/mmcblk0pX > <output_file>) abnehmen, die aber bitte NICHT hier veröffentlichen (das ist (C) AVM), sondern mir ggf. per E-Mail (Adresse steht im GPG-Key in diesem Repository) schicken. Mich interessiert in erster Linie, ob da auch ein "klassischer" Konfigurationsbereich mit den "Geburtsdaten" der Box existiert und wenn ja, wie man ihn findet und welches Format er genau hat.
Ich gehe zwar ohnehin davon aus, daß auch hier der Wert für firmware_version im nicht-änderbaren Teil der TFFS-Einstellungen abgelegt ist (bzw. genauer in dem, der bei jedem Booten neu aus den hinterlegten Werten erzeugt wird) und damit das Ändern des Brandings auf "klassischem" Weg auch nicht funktionieren wird, aber wenn er sich lokalisieren und prüfen ließe, dann wäre das (für die spätere Implementierung, die auch die Behandlung von Brandings ermöglichen soll) weiterhin eine einheitliche Behandlung aller Modelle und man muß keine Sonderbehandlung auch noch an dieser Stelle einbauen ... der Rest ist schon "absonderlich" genug und verlangt schon eine andere Behandlung als bei anderen Plattformen.
Wenn ich aus dem Bauch heraus raten sollte, würde ich aber auf EINE Kopie in SBL1 tippen - es gibt zwar bei Modellen mit NAND-Speicher für den Bootloader auch mal zwei Kopien (in einer einzigen MTD-Partition), aber die sind 1:1 identisch und bei eMMC-Speicher kümmert sich ja auch dessen Controller um die Behandlung von potentiellen Flash-Fehlern - im Gegensatz zu (dummem) NAND-Speicher.
grep wlan_key /dev/mmcblk0p2
kommt nichts
grep wlan_key /dev/mmcblk0p13
wlan_key
grep wlan_key /dev/mmcblk0p14
wlan_key
cmp -l /dev/mmcblk0p13 /dev/mmcblk0p14
kommt nichts
Mail ist raus
Das sieht nach zwei identischen Kopien des Bootloaders in 13 und 14 aus (wenn's beim cmp keine Unterschiede gibt) - da war mein Bauch dann im Irrtum.
Ich bin gerade mit der Implementierung der nächsten Version des Boot-Managers fertig geworden (a58c174 - noch ohne Unterstützung für IPQ501x, IPQ8074 (Hawkeye) oder PRX300) und teste die jetzt noch ausführlich auf den Boxen, die ich in meiner Reichweite habe (VR9, GRX5 und Puma6) - das dauert also noch ein wenig, weil es mehrere Fälle pro Box zu testen gilt.
Danach geht's an die nächste Version, die dann zumindest IPQ8074-Boxen unterstützen soll.
Wenn noch was brauchst einfach sagen, werde es dann ausführen.
Du bist der Erste, der eine Version für IPQ8074 von mir zum Testen kriegt - da zähle ich dann wieder auf Dich. Bis hierher - nochmal danke.
Hihi danke, werde ich dann auch gerne, machen das Testen.
Ich glaube, ich bin auch der Erste, der eine Fit Box gefreetzt hat.
Kann sein das ich nachher von einem Bekannten noch eine FRITZ!Box 7530AX und ein 1200AX bekomme zum Testen
Mail ist raus
Die habe ich mir jetzt angesehen, da tauchen dann aber noch ein paar Fragen auf.
Bisher war es üblicherweise so, daß der Konfigurationsbereich für den Bootloader auch Bestandteil des Bootloader-Codes und irgendwo in einer der Bootloader-Kopien zu finden war - m.W. galt das auch noch für IPQ4019-Boxen (7520/7530), selbst wenn der da etwas weiter hinten in der Partition stand.
Hier sieht es aber so aus, als wäre dort nur der "Standardblock" als Fallback enthalten (dabei wird als maca immer 00:04:0E:FF:FF:01 verwendet) und damit müßten die anderen Daten der Box (WLAN-Key, Start-SSID, GUI-Kennwort, etc.) an anderer Stelle gespeichert sein.
Nun ist es ja glücklicherweise nicht so, daß es bei diesem Modell an potentiellen Kandidaten in Form von Partitionen unbekannten Inhalts mangelt - irgendwo MUSS AVM die Daten ja gespeichert haben. Da müßtest Du noch einmal nach der korrekten Partition suchen, z.B. so:
for n in $(seq 1 16); do grep -ao "<value>" /dev/mmcblk0p$n && echo "/dev/mmcblk0p$n"; done
Für <value> kannst Du irgendeinen Wert nehmen, der für genau den Gerät spezifisch ist - ein Auswahl denkbarer Merkmale habe ich oben aufgezählt. Da das Gesuchte eigentlich nicht in den letzten vier Partitionen stehen kann (und die auch noch die größten sind, wo die Suche am längsten bräuchte), habe ich die ausgelassen (nur 1 bis 16).
Solltest Du Partitionen mit dem gesuchten Inhalt finden, bräuchte ich davon auch mal einen Dump - wenn Du die Daten des Geräts schützen willst (das Urlader-Environment weiter vorne hast Du ja auch maskiert), dann aber besser wieder per Mail (den Inhalt, nicht unbedingt die Fundstelle - die kann ja ruhig öffentlich bekannt sein, damit andere die Info auch nutzen können).
So ist per Mail raus. Es sind 3 Dumps, und zwar 14, 15 und 16
So, ich habe mal einen Entwurf eingecheckt: https://github.com/PeterPawn/YourFritz/blob/bootmanager_0.8.3/bootmanager/bootmanager
Zum Ausprobieren kann man diese Datei mittels wget auf die Box laden, wobei auch noch das Message-File benötigt wird:
https://raw.githubusercontent.com/PeterPawn/YourFritz/bootmanager_0.8.3/bootmanager/bootmanager
https://raw.githubusercontent.com/PeterPawn/YourFritz/bootmanager_0.8.3/bootmanager/bootmanager.msg
Beide Dateien irgendwo ablegen, wo Du sie wiederfinden kannst - dann zum Test mal sh <path>/bootmanager debug verbose aufrufen und das Ergebnis bitte hier posten - ebenso die Ausgabe von bootmanager get_values.
Anschließend ein ls -l /var/tmp/bootmanager* und für jede dabei gefundene Datei (außer der .boot, das ist nur eine Kopie des Urlader-Environments beim Start des OS) deren Inhalt noch mit cat anzeigen lassen. Die .dev sollte etwas wie immutable=avm enthalten und eine .data sollte die Ausgabe vom get_values-Aufruf anzeigen.
switch_to ist noch nicht implementiert - erst mal sichergehen, daß alle Daten richtig ermittelt werden.
Und "for the records" - beim 6000 (und vermutlich auch bei anderen IPQ8074-basierten Modellen) steht die Urlader-Konfiguration in der eMMC-Partition mit dem Label 0:CONFIG (0:CONFIG_1 ist eine 1:1-Kopie davon), der Bereich hat immer noch die Versionsnummer 3 und beginnt am Offset 0x5e00.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
inactive system is installed = false
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel =
active filesystem =
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system version = 253.07.29
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
inactive kernel =
inactive filesystem =
inactive filesystem could not be mounted
sh /var/mod/root/bootmanager get_values
/var/mod/root/bootmanager: line 1024: get_emmc_partition: not found
ls -l /var/tmp/bootmanager*
-rw-r--r-- 1 root root 906 Feb 28 19:35 /var/tmp/bootmanager.boot
Dämlicher Fehler meinerseits - falscher Name der Funktion.
Neue Version ist eingecheckt, nur der Download für bootmanager muß noch einmal ausgeführt werden.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system version = 07.29-93257
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
inactive system checks skipped
sh /var/mod/root/bootmanager get_values
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
sh: invalid number '/dev/mmcblk0p17'
sh: invalid number '/dev/mmcblk0p19'
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
neue Version - wobei die Ausgabe in bootmanager.data dem vorläufig erwarteten Ergebnis schon recht nahe kommt.
sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
sh /var/mod/root/bootmanager get_values
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=
device_branding_changeable=
switch_branding_support=true
current_switch_value=0
system_is_switched=false
device branding =
device branding is changeable =
Das sollte so nicht aussehen, der Rest gefällt mir schon ganz gut.
Da einige Operationen des Skripts recht aufwändig sind, werden einige Ergebnisse gecacht:
/var/tmp/bootmanager.boot - Kopie des Urlader-Environments beim Systemstart
/var/tmp/bootmanager.dev - hier sollte in Abhängigkeit von der Möglichkeit, da Branding dauerhaft zu ändern, in der Datei ein changeable=<original_value> oder ein immutable=<original_value> stehen
/var/tmp/bootmanager.data - eine Kopie der Ausgabe eines get_values-Aufruf
Die letzte Datei oben kann/muß durch den Aufruf von bootmanager clear_cache gelöscht werden vor weiteren Test, ansonsten werden einfach nur wieder die zuvor dort gespeicherten Daten ausgegeben. Die letzten zwei Dateien werden gelöscht, wenn man hinter das clear_cache noch ein with_eva_config setzt.
Beim nächsten Aufruf - der dann natürlich länger braucht, wenn die Daten erst wieder zusammen gesucht werden müssen - werden diese Dateien dann neu angelegt.
Warum die zwei fehlenden Zeilen oben zustande kommen (da sollte der Inhalt des Konfigurationsbereichs von EVA ausgewertet werden - das ist dann das, was in bootmanager.dev gecacht würde), muß ich mir erst mal genauer ansehen ... ggf. checke ich dann eine Version ein, die ein paar mehr Ausgaben erzeugt, damit ich erkennen kann, wo ein Problem aufgetreten ist.
Bei weiteren Tests dann bitte immer erst bootmanager clear_cache with_eva_config aufrufen, damit nicht nur dieselben (ggf. fehlerhaften) Daten erneut ausgegeben werden.
Um das Problem mit der EVA-Konfiguration einzugrenzen, reicht dann jeweils die Ausgabe von bootmanager debug verbose.
sh /var/mod/root/bootmanager clear_cache with_eva_config
sh /var/mod/root/bootmanager debug verbose
system type = IPQ8074
system selector = 0
system is switched = false
device branding =
device branding is changeable =
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
Das sollte ich nur machen sehe ich das richtig
Ja, das reicht ab jetzt erst einmal. Aber ich muß erst mal schauen, was da beim Zerlegen der EVA-Konfiguration nicht funktioniert für dieses Modell und erst mit einer neuen Version macht ein weiterer Test Sinn. Ich melde mich, kann aber jetzt mal 30 Minuten dauern - erst mal etwas essen.
Lass es dir schmecken. Bis später
Ich habe das hier nicht vergessen, aber der Aufbau des Konfigurationsbereichs ist hier ein anderer und da muß ich erst mal ein paar größere Umbauten vornehmen.
Das ist hier das erste Mal, daß mir ein Konfigurationsbereich in EVA unterkommt, wo die Daten in LE-Byte-Order gespeichert sind. Bisher war ich (mangels Masse bei den untersuchten Daten, jenseits von MIPS- und Puma-Chipsets) der Ansicht, daß die Daten einheitlich gespeichert würden, weil auch die (LE-)Plattform des ATOM-Cores im Puma6 die Daten im BE-Format gespeichert hat. Dabei hatte ich aber nicht bedacht, daß das ja nur mit Rücksicht auf den ebenfalls vorhandenen ARM-Core der Fall sein könnte, denn den betreibt AVM ja wiederum im BE-Modus.
Jetzt muß ich erst mal die Stellen, wo Daten in Abhängigkeit von der Byte-Order anders gespeichert werden müsse, überarbeiten - das betrifft den gesamten Teil in check_urlader_configuration und es sind im Ergebnis sehr umfangreiche Änderungen. Das dauert etwas - ich werde auch in den kommenden Tagen nicht so richtig dafür Zeit haben.
Ich habe es also weiterhin auf dem Zettel, aber es kann gut bis zur nächsten Woche dauern, bis ich da wieder dran bin.
So bin dann wieder am Rechner, wenn also was getestet haben willst einfach melden
Neuer Versuch ... immer noch ohne FIT-Zerlegen, aber beim EVA-Konfigurationsbereich sollte das jetzt klappen.
Mich würde auch mal interessieren, wie lange das Zerlegen des Bootloaders braucht - bitte setze mal ein time vor den Aufruf des Skripts mit dem debug-Parameter. Bei einem weiteren Aufruf desselben Kommandos sollte es dann deutlich schneller gehen, dank der gecachten Infos (die bei diesem zweiten Versuch natürlich nicht gelöscht werden sollten).
time sh /var/mod/root/bootmanager debug verbose
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ8074
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
active system version = 07.29-93257
active system date = 08.12.2021, 16:53:31 Uhr (epoch: 1638978811)
active system modification date = 25.02.2022, 16:40:16 Uhr (epoch: 1645803616)
active system modification source = Freetz-NG
brandings supported on active system = avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive system checks skipped
real 0m 0.34s
user 0m 0.01s
sys 0m 0.00s
sh /var/mod/root/bootmanager get_values
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=avm
device_branding_changeable=false
switch_branding_support=true
current_switch_value=0
system_is_switched=false
ls -l /var/tmp/bootmanager*
-rw-r--r-- 1 root root 906 Mar 3 04:29 /var/tmp/bootmanager.boot
-rw-r--r-- 1 root root 462 Mar 3 04:31 /var/tmp/bootmanager.data
-rw-r--r-- 1 root root 14 Mar 3 04:29 /var/tmp/bootmanager.dev
cat /var/tmp/bootmanager.data
active_version="07.29-93257"
active_date_epoch="1638978811"
active_date="08.12.2021, 16:53:31 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1645803616"
active_modified_at="25.02.2022, 16:40:16 Uhr"
active_brandings="avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="missing"
device_branding=avm
device_branding_changeable=false
switch_branding_support=true
current_switch_value=0
system_is_switched=false
cat /var/tmp/bootmanager.dev
immutable=avm
Danke, die Erkennung der Bootloader-Konfiguration funktioniert jetzt offenbar auch. Da muß ich aber noch nacharbeiten, weil auch die Puma-Modelle (zumindest die 6er, also 6490, 6590 und 6430) auf dem ATOM-Core mit LE-Byte-Order arbeiten und dennoch die Daten im Konfigurationsbereich in BE gespeichert sind.
Danach schaue ich mir das Zerlegen der FIT-Images mal an, Vorlagen habe ich in den AVM-Downloads ja genug dafür.
Das kann dauern, daher ist hier die "akute Phase" dann erst einmal beendet. Wer will, kann derweil ja mal versuchen, den aktuellen Stand des Skripts auch in Verbindung mit dem GUI in einer Box zu benutzen. Je nachdem, ob/wann der akt. Stand des main-Branchs in Freetz-NG verfügbar wird, muß nur das "Haupt-Skript" noch zusätzlich ersetzt werden.
Und auch noch einmal "for the records" ... im Konfigurationsbereich für EVA beim FRITZ!WLAN-Repeater 6000 gibt es NUR NOCH Einträge für Werte, die bei jedem Systemstart auch restauriert werden - die bei anderen Geräten noch vorhandenen Einträge, die nur einen Standardwert festlegen, wenn es noch keine entsprechende Einstellung gibt, fehlen hier bzw. es sind ALLE Einträge im festen Teil der Konfiguration.
Vielleicht baut @fda77 es zum Testen ja ein.
Und @PeterPawn dafür doch nicht, denn wir haben zu danken, dass du dir die Mühe und Arbeit überhaupt machst.
Könntest Du mal bitte bei Gelegenheit dieses Skript: https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/fit-findfs.sh auf das Gerät laden und mit fit-findfs.sh /dev/disk/by-partlabel/fit0 (bzw. fit1) aufrufen? Mich interessiert die Ausgabe, denn das sollten Offset und Größe des SquashFS-Images in der FIT-Image-Partition sein.
Wobei das ein wenig dauern könnte, auf einem x86-System dauert das Zerlegen des AVM-Images für den FR6000 bei mir auch etwas:
vidar:/home/GitHub/YourFritz/eva_tools/fit-images/FR6000 $ time ../../fitdump.sh fit-image.FR6000
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x130ffff (19988479)
// off_dt_struct: 0x38
// off_dt_strings: 0x130fed0
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x12f
// size_dt_struct: 0x130fe98
/ {
description = "FIT for HW253";
timestamp = <0x60ace39e>;
avm,gu-version = <0x00015b1e>;
images {
qcaarmv8_HW253_kernel {
description = "Kernel for qcaarmv8_HW253";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x41208000>;
entry = <0x41208000>;
hash_0 {
algo = "crc32";
value = <0x93dca44b>;
};
avm,kallsyms {
avm,endianess = "LE";
avm,kernel_text_start = <0xc0208000>;
avm,names = <0xc082fc30>;
avm,token_table = <0xc08c4930>;
avm,token_index = <0xc08c4cd0>;
avm,num_syms = <0xc082fc20>;
avm,addresses = <0xc07fd730>;
avm,relative_base;
avm,offsets;
};
};
qcaarmv8_HW253_flat_dt_0 {
description = "Device Tree for qcaarmv8_HW253_0";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin");
type = "flat_dt";
arch = "arm";
compression = "lzma";
load = <0x41c66000>;
hash_0 {
algo = "crc32";
value = <0x2b09b949>;
};
};
qcaarmv8_HW253_flat_dt_2 {
description = "Device Tree for qcaarmv8_HW253_2";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin");
type = "flat_dt";
arch = "arm";
compression = "lzma";
load = <0x41c66000>;
hash_0 {
algo = "crc32";
value = <0x59889986>;
};
};
qcaarmv8_HW253_squashFS_filesystem {
description = "squashFS for qcaarmv8_HW253";
#address-cells = <0x00000001>;
avm,data-align = <0x00001000>;
data = /incbin/("image_004.bin");
type = "filesystem";
compression = "none";
load = <0x43000000>;
avm,kernel-args = "mtdram=ram-filesystem,0x43000000,0x44000000 mtdparts_ext=ram-filesystem:16609280@0x0(rootfs_ram)";
hash_0 {
algo = "crc32";
value = <0xe785947f>;
};
};
};
configurations {
qcaarmv8_HW253_config_0 {
kernel = "qcaarmv8_HW253_kernel";
fdt = "qcaarmv8_HW253_flat_dt_0";
squashFS = "qcaarmv8_HW253_squashFS_filesystem";
};
qcaarmv8_HW253_config_2 {
kernel = "qcaarmv8_HW253_kernel";
fdt = "qcaarmv8_HW253_flat_dt_2";
squashFS = "qcaarmv8_HW253_squashFS_filesystem";
};
};
};
real 0m8.600s
user 0m8.342s
sys 0m3.835s
vidar:/home/GitHub/YourFritz/eva_tools/fit-images/FR6000 $ time ../../fit-findfs.sh fit-image.FR6000
filesystem_offset=3378392 filesystem_size=16609280
real 0m6.810s
user 0m7.054s
sys 0m3.130s
vidar:/home/GitHub/YourFritz/eva_tools/fit-images/FR6000 $
Wenn die angezeigen Daten beim fit-findfs.sh stimmen, sollte auch ein Mounten machbar sein - dazu suchst Du Dir das inaktive System (bootslotctl get_other) und nimmst die Ausgaben des o.a. Skripts für die fitX-Partition mit dieser Nummer. Die Kommando sähen dann z.B. so aus:
mkdir -p /var/media/inactive
mount -o offset=<filesystem_offset> /dev/disk/by-partlabel/fit$(bootslotctl get_other) /var/media/inactive
mount
losetup -a
ls -l /var/media/inactive
umount /var/media/inactive
Klappt das, ist das Erkennen von System und Framework für das inaktive System auch auf Geräten mit FIT-Image wieder einen Schritt näher.
sh fit-findfs.sh /dev/disk/by-partlabel/fit0
fit-findfs.sh: line 8: syntax error: unexpected newline
Auch wenn da noch ein Problem im Skript WAR, lag es bei Dir vermutlich eher am Download:
~ # cd /var
/var # rm fit-findfs.sh
/var # wget https://raw.githubusercontent.com/PeterPawn/YourFritz/main/eva_tools/fit-findfs.sh
Connecting to raw.githubusercontent.com (185.199.108.133:443)
fit-findfs.sh 100% |*************************************| 8502 0:00:00 ETA
/var # time sh ./fit-findfs.sh /var/media/ftp/fit-image.FR6000
filesystem_offset=3378392 filesystem_size=16609280
real 0m 12.78s
user 0m 4.93s
sys 0m 2.16s
/var #
Ausgeführt auf dem ATOM-Core einer 6490, weil im Moment nur LE-Modelle mit FIT-Image bekannt sind und die Daten in den ersten 8 Bytes eines Images in LE-Order gespeichert sind.
root@6000-repeater:/var# sh fit-findfs.sh /dev/disk/by-partlabel/fit1
fit-findfs.sh - find filesystem entries in a FIT image
Usage: fit-findfs.sh [ -d | --debug ] <fit-image>
OK, da habe ich glatt vergessen, daß die Partition ja größer ist ... das macht die Prüfung der Länge an dieser Stelle witzlos. Ich ändere gleich noch etwas und melde mich wieder.
ok
../../mmcblk0p17
ist fit0 Ja habe das auch grade getestet
geändert
sh fit-findfs.sh -d /dev/disk/by-partlabel/fit1
File: /dev/disk/by-partlabel/fit1, size=0
Signature at offset 0x00: 0xfeed000d (LE)
Overall length of data at offset 0x04: 0x01534eef - dec.: 22236911 (LE)
Data at offset 0x08, size 64:
00000000 dc ae 23 7e 7f 3a 7b d6 06 6b bc 74 1e 53 fd e6 |..#~.:{..k.t.S..|
00000010 98 d9 a9 89 6c 90 1c 6e e0 a0 08 b8 96 41 d4 53 |....l..n.....A.S|
00000020 e4 5f c5 d6 83 85 e0 2f ea cb 25 9a 5f 33 17 1c |._...../..%._3..|
00000030 13 3f 5d bf 64 3e 8b c2 e4 d4 e3 c8 d7 1c a8 04 |.?].d>..........|
FDT magic at offset 0x48: 0xd00dfeed (BE)
FDT total size at offset 0x4c: 0x01534eef (dec.: 22236911) (BE)
FDT structure offset: 0x00000038 (dec.: 56) (BE)
FDT strings offset: 0x01534dc0 (dec.: 22236608) (BE)
FDT memory reserve map offset: 0x00000028 (dec.: 40) (BE)
FDT version at offset 0x005c: 0x00000011 (dec.: 17) (BE)
FDT last compatible version at offset 0x0060: 0x00000010 (dec.: 16) (BE)
FDT physical CPU ID while booting at offset 0x0064: 0x00000000 (dec.: 0) (BE)
FDT size of strings block: 0x0000012f (dec.: 303) (BE)
FDT size of structure block: 0x01534d88 (dec.: 22236552) (BE)
Begin node at offset 0x00000080, name=/
Nun muss ich warten ;-)
Versuch's mal ohne das -d - das sollte es nicht brauchen, höchstens noch bei einem anderen Skript (fitdump.sh).
Wenn das da tatsächlich hängen bleibt, stimmt irgendetwas noch nicht.
Es lauft, ja noch sind schon 2 Sachen dazugekommen
Property node at offset 0x00000088, value size=14, name=description
Property node at offset 0x000000a4, value size=4, name=timestamp
Autsch ... das ist dann aber eher ungut. Sooo langsam sollte das auch mit einem Block-Device nicht sein. Mit einer Datei (auf dem NAS-Speicher der 6490) hat es ja auch nur etwas mehr als 12 Sekunden gedauert, siehe oben.
Da bin ich nun
sh fit-findfs.sh -d /dev/disk/by-partlabel/fit1
File: /dev/disk/by-partlabel/fit1, size=0
Signature at offset 0x00: 0xfeed000d (LE)
Overall length of data at offset 0x04: 0x01534eef - dec.: 22236911 (LE)
Data at offset 0x08, size 64:
00000000 dc ae 23 7e 7f 3a 7b d6 06 6b bc 74 1e 53 fd e6 |..#~.:{..k.t.S..|
00000010 98 d9 a9 89 6c 90 1c 6e e0 a0 08 b8 96 41 d4 53 |....l..n.....A.S|
00000020 e4 5f c5 d6 83 85 e0 2f ea cb 25 9a 5f 33 17 1c |._...../..%._3..|
00000030 13 3f 5d bf 64 3e 8b c2 e4 d4 e3 c8 d7 1c a8 04 |.?].d>..........|
FDT magic at offset 0x48: 0xd00dfeed (BE)
FDT total size at offset 0x4c: 0x01534eef (dec.: 22236911) (BE)
FDT structure offset: 0x00000038 (dec.: 56) (BE)
FDT strings offset: 0x01534dc0 (dec.: 22236608) (BE)
FDT memory reserve map offset: 0x00000028 (dec.: 40) (BE)
FDT version at offset 0x005c: 0x00000011 (dec.: 17) (BE)
FDT last compatible version at offset 0x0060: 0x00000010 (dec.: 16) (BE)
FDT physical CPU ID while booting at offset 0x0064: 0x00000000 (dec.: 0) (BE)
FDT size of strings block: 0x0000012f (dec.: 303) (BE)
FDT size of structure block: 0x01534d88 (dec.: 22236552) (BE)
Begin node at offset 0x00000080, name=/
Property node at offset 0x00000088, value size=14, name=description
Property node at offset 0x000000a4, value size=4, name=timestamp
Property node at offset 0x000000b4, value size=4, name=avm,gu-version
Begin node at offset 0x000000c4, name=images
Begin node at offset 0x000000d0, name=qcaarmv8_HW253_kernel
Property node at offset 0x000000ec, value size=26, name=description
Property node at offset 0x00000114, value size=1, name=avm,variants
Ich lasse es einfach mal durchlaufen
Das kann aber dauern ... kannst Du das mal auf Deinem Freetz-Build-System mit der dort erzeugten fit-image-Datei ablaufen lassen?
Oder mal mit dd if=/dev/disk/by-partlabel/fit0 bs=1M count=$(( 22236911 / ( 1024 * 1024 ) + 1 )) of=/tmp/fit-image den tatsächlich genutzten Teil der eMMC-Partition ins tmpfs kopieren und das Skript danach noch einmal auf diese Datei ansetzen - das würde zumindest zeigen, ob es prinzipiell funktioniert. Ich könnte mir sogar vorstellen, daß ich das immer machen müßte - zumindest um den Offset zu finden, danach kann man die Datei aus dem tmpfs ja auch wieder löschen.
sh ./fit-findfs.sh /var/fit-image
Und nun warte ich, denn zurZeit wird noch nichts angezeigt
Habe denn 6000 vorher auch einmal rebootet
Edit
filesystem_offset=3378120 filesystem_size=18857984
Wenn Du möchstest, das Ganze noch einmal mit einem time davor (um mal eine Vorstellung von der Laufzeit zu kriegen) und das weiter oben gezeigte Mounten sollte mit dem angezeigten Offset und dem Block-Device (also nicht der Image-Kopie in /var) auch funktionieren.
Da war ich schon schneller
time sh ./fit-findfs.sh /var/fit-image
filesystem_offset=3378120 filesystem_size=18857984
real 1m 32.81s
user 0m 11.16s
sys 1m 54.83s
Was macht der denn da? Wie kann das auf dem Repeater im tmpfs länger brauchen, als bei einer 6490 aus der NAS-Partition?
Ich verstehe es nicht ...
mount -o offset=<filesystem_offset> /dev/disk/by-partlabel/fit$(bootslotctl get_other) /var/media/inactive
-sh: can't open filesystem_offset: no such file
Du mußt schon den Offset im Aufruf einsetzen ... das wäre dann 3378120 von weiter oben und vielleicht nimmst Du ja anstelle von $(bootslotctl get_other) auch direkt die Nummer des "inaktiven" Systems - obwohl das "Auslesen" auch funktionieren sollte. Nur muß der Wert halt auch zur Quelle des Images passen, was da ins tmpfs kopiert wurde. Die beiden FIT-Partitionen können ja auch unterschiedliche Images enthalten, die dann auch wieder andere Offsets für das SquashFS-Image haben.
So ich mache nun
sh ./fit-findfs.sh /dev/disk/by-partlabel/fit0
damit ich die offset bekomme
danach mache ich dann
mount -o offset=xxxxxxx /dev/disk/by-partlabel/fit0 /var/media/inactive
natürlich mit der richtigen offset aber dafür brauch er ja zeit
denn wenn ich das mache kommt das zur zeit
mount -o offset=3378120 /dev/disk/by-partlabel/fit0 /var/media/inactive
mount: mounting /dev/disk/by-partlabel/fit0 on /var/media/inactive failed: Invalid argument
bootslotctl get_other
0
Rufe mal bitte ein mount --help auf - ich vermute mal, das hat bei Dir andere Parameter. Ich habe noch meinen eigenen Patch für das Mounten mit Offset in der BusyBox, Freetz hatte früher eine Implementierung von @er13 und Freetz-NG wird vermutlich direkt das BusyBox-Applet mit Offset-Option kennen, denn diese Änderung gab es irgendwann auch direkt am Upstream der BusyBox.
Usage: mount [OPTIONS] [-o OPT] DEVICE NODE
Mount a filesystem. Filesystem autodetection requires /proc.
-a Mount all filesystems in fstab
-f Update /etc/mtab, but don't mount
-i Don't run mount helper
-n Don't update /etc/mtab
-v Verbose
-r Read-only mount
-t FSTYPE[,...] Filesystem type(s)
-T FILE Read FILE instead of /etc/fstab
-O OPT Mount only filesystems with option OPT (-a only)
-o OPT:
loop Ignored (loop devices are autodetected)
[a]sync Writes are [a]synchronous
[no]atime Disable/enable updates to inode access times
[no]diratime Disable/enable atime updates to directories
[no]relatime Disable/enable atime updates relative to modification time
[no]dev (Dis)allow use of special device files
[no]exec (Dis)allow use of executable files
[no]suid (Dis)allow set-user-id-root programs
[r]shared Convert [recursively] to a shared subtree
[r]slave Convert [recursively] to a slave subtree
[r]private Convert [recursively] to a private subtree
[un]bindable Make mount point [un]able to be bind mounted
[r]bind Bind a file or directory [recursively] to another location
move Relocate an existing mount point
remount Remount a mounted filesystem, changing flags
ro Same as -r
There are filesystem-specific -o flags.
du hast eine mail bekommen
Habe ich schon gelesen ... würde ich aber nicht über längere Zeit betreiben (zumindest nicht auf dem Standardport) und im Moment bin ich erst mal am Suchen, was da beim Mount nicht stimmen könnte.
Aber zur Suche, warum das so elend lahm ist, macht das sicherlich schon Sinn - aber nur temporär und der Rest ohnehin dann per Mail.
Ich mache hier trotzdem mal weiter, weil es auch ein wenig um das Dokumentieren geht.
Nach dem hier: https://git.busybox.net/busybox/tree/util-linux/mount.c#n2122 sollte die Mount-Option offset= vorhanden sein, wenn die BusyBox nicht eine ältere ist.
So habe ihn mal neu gestartet, nun kannst du machen was du willst.
Habe das nur für dich grade aufgemacht. Mache ich später wieder ZU. Wenn du sagst das du durch bist
Ich komme aber gerade nicht dazu - mach mal bitte erst mal wieder dicht und ich melde mich dann, wenn ich die Zeit habe. Wenn's dann nicht sofort klappt, ist es auch nicht weiter tragisch.
ok mache ich einfach melden
Könnte man die Offsets nicht aus den kernel-args extrahieren?
https://boxmatrix.info/wiki/FIT-Image
[ 0.000000] Kernel command line: mtdram=ram-filesystem,0x43000000,0x44100000 mtdparts_ext=ram-filesystem:16777216@0x0(rootfs_ram) block2mtd.block2mtd=/dev/mmcblk0p18,0x400000,nand-tffs console=ttyMSM0,115200,n8 swiotlb=1 audit=1
Glaube ich kaum ... der Loader (EVA) lädt die Images ins RAM (daher ist das rootfs auch im Speicher: #45 (comment)) und die Angaben in "kernel-args" beziehen sich nur auf die Adressen, wohin das geladen wurde.
Ich sehe jedenfalls keinen Zusammenhang zwischen der kernel-args-Property (#45 (comment)) und dem Offset des SquashFS-Images im FIT-Image ... daß die Länge des FS-Images der Angabe für das in den Speicher geladene Image entspricht, ist ja eher zu erwarten.
Ich sehe keinen anderen Weg, als das Schritt für Schritt zu durchsuchen (so läuft das ja mit dem Skript) - nicht mal irgendwelche Tricks wie "von hinten beginnen mit der Suche" o.ä. sind da erfolgversprechend.
Ich verstehe ohnehin nicht, warum das auch im tmpfs so lange dauert - meine Timings auf einer 6490 sieht man ja weiter oben.
Ich kann mir nur noch vorstellen, daß x86-Code (der ATOM-Core der 6490 wäre ja auch betroffen) beim Suchen (seek()) im Code der Blockgeräte-Treiber irgendwie optimiert ist oder vielleicht ist es ja auch das dd-Kommando (wobei auf der 6490 auch die BusyBox verwendet wird, nur bei der Entwicklung habe ich mein x64-System genutzt), was da bei einem bs=1 skip=nnn optimiert und ein einzelnes seek() draus macht, anstelle von nnn seek()-Aufrufen mit jeweils einem Byte.
Dabei habe ich das schon im Skript optimiert und z.B. für das Lesen von string-Daten (die Namen der Properties werden ja mehrfach verwendet) schon ein Caching eingebaut, damit das nicht jedesmal neu erfolgen muß.
Ich muß mal schauen, wie ich das anders hinbekomme - da die FIT-Images ja max. 80 MB groß werden können (mehr Platz bieten die Partitionen nicht), gehe ich mal davon aus, daß auch für ein dd das Bereitstellen eines Buffers für das gesamte FIT-Image kein echtes Problem sein sollte (zumal der nur kurz benötigt würde) und dann kann man anstelle von bs=1 skip=nnn count=mmm auch ein bs=nnn skip=1 count=1 mit einem weiteren dd dahinter, das den einen zu lesenden Block dann hinten wieder abschneidet auf die Länge von mmm, verwenden.
Wenn's tatsächlich an den vielen kleinen seek()-Aufrufen liegen sollte (auch beim Lesen sind da häufiger Aufrufe von dd für ein einzelnes Byte dabei), dann sollte so ein Kniff diese Aufrufe drastisch verringern können.
Aber das muß ich erst mal implementieren und dann testen. Jedenfalls ist das eine Hürde, mit der ich nun gar nicht gerechnet habe, weil das auch auf der 6490 ausreichend performant war - jedenfalls mit einem "regular file".
Alles bis 15 Sekunden wäre mir egal, weil ich es nur einmal beim Start des OS laufen lassen würde - danach sollte sich das nicht mehr maßgeblich ändern, solange kein neues System installiert wird und das wäre - Stand jetzt - ohnehin immer mit einem Neustart verbunden.
Witzig wäre natürlich noch, wenn der eMMC-Speicher bei diesen Modellen so angebunden ist, daß sich da ein Flaschenhals ergibt. Da dieser ja - nachdem Kernel und SquashFS-Image im Speicher sind - nicht mehr wirklich benötigt wird, würde sich eine extrem langsame Anbindung auch für das OS selbst nicht weiter auswirken - nur NAS-Zugriffe und TFFS-Schreiben wäre ggf. entsprechend langsam. Aber daran kann ich irgendwie auch nicht so richtig glauben - ich gehe mal davon aus, daß der Speicher am PCI-Bus des Prozessors hängt.
Beim Raspberry 3 ist die 1Gbit Anbindung über usb2.0 angebunden, dh LAN wird langsam wenn man was auf eine USB-HDD schreibt...
die Angaben in "kernel-args" beziehen sich nur auf die Adressen, wohin das geladen wurde.
ein Wert davon ist die Größe des squashfs
Kennst du Hippies fitimg tool? Für FRITZ.Repeater_6000-07.29.image:
$ ~/freetz-ng/tools/fitimg -s fit-image
00000080 hunk 1 [8] - string = ''
00000088 hunk 3 #0 [14] - info = 'FIT for HW253'
000000a4 hunk 3 #12 [4] - timestamp = 0x61b0d51d = 1638978845
000000b4 hunk 3 #22 [4] - avm,gu-version = 0x00016c49 = 93257
000000c4 hunk 1 [12] - string = 'images'
000000d0 hunk 1 [28] - string = 'qcaarmv8_HW253_kernel'
000000ec hunk 3 #0 [26] - info = 'Kernel for qcaarmv8_HW253'
00000114 hunk 3 #37 [1] - avm,variants = ''
00000124 hunk 3 #50 [4] - #address-cells = 0x00000001 = 1
00000134 hunk 3 #65 [3345869] - data = <binary blob>
00330f10 hunk 3 #70 [7] - type = 'kernel'
00330f24 hunk 3 #75 [4] - arch = 'arm'
00330f34 hunk 3 #80 [6] - os = 'linux'
00330f48 hunk 3 #83 [5] - compression = 'lzma'
00330f5c hunk 3 #95 [4] - load = 0x41208000
00330f6c hunk 3 #100 [4] - entry = 0x41208000 = 1092648960
00330f7c hunk 1 [12] - string = 'hash_0'
00330f88 hunk 3 #106 [6] - algo = 'crc32'
00330f9c hunk 3 #111 [4] - value = 0xd62a705a
00330fac hunk 2 [24] - string = 'avm,kallsyms'
00330fc4 hunk 3 #117 [3] - avm,endianess = 'LE'
00330fd4 hunk 3 #131 [4] - avm,kernel_text_start = 0xc0208000 = 3223355392
00330fe4 hunk 3 #153 [4] - avm,names = 0xc082fc30 = 3229809712
00330ff4 hunk 3 #163 [4] - avm,token_table = 0xc08c4930 = 3230419248
00331004 hunk 3 #179 [4] - avm,token_index = 0xc08c4cd0 = 3230420176
00331014 hunk 3 #195 [4] - avm,num_syms = 0xc082fc20 = 3229809696
00331024 hunk 3 #208 [4] - avm,addresses = 0xc07fd730 = 3229603632
00331034 hunk 3 #222 [0] - avm,relative_base = <empty>
00331040 hunk 3 #240 [0] - avm,offsets = <empty>
0033104c hunk 2 [40] - string = 'qcaarmv8_HW253_flat_dt_0'
00331074 hunk 3 #0 [33] - info = 'Device Tree for qcaarmv8_HW253_0'
003310a4 hunk 3 #50 [4] - #address-cells = 0x00000001 = 1
003310b4 hunk 3 #65 [15473] - data = <binary blob>
00334d34 hunk 3 #70 [8] - type = 'flat_dt'
00334d48 hunk 3 #75 [4] - arch = 'arm'
00334d58 hunk 3 #83 [5] - compression = 'lzma'
00334d6c hunk 3 #95 [4] - load = 0x41c66000
00334d7c hunk 1 [12] - string = 'hash_0'
00334d88 hunk 3 #106 [6] - algo = 'crc32'
00334d9c hunk 3 #111 [4] - value = 0x17a50f46
00334dac hunk 2 [40] - string = 'qcaarmv8_HW253_flat_dt_2'
00334dd4 hunk 3 #0 [33] - info = 'Device Tree for qcaarmv8_HW253_2'
00334e04 hunk 3 #50 [4] - #address-cells = 0x00000001 = 1
00334e14 hunk 3 #65 [15532] - data = <binary blob>
00338acc hunk 3 #70 [8] - type = 'flat_dt'
00338ae0 hunk 3 #75 [4] - arch = 'arm'
00338af0 hunk 3 #83 [5] - compression = 'lzma'
00338b04 hunk 3 #95 [4] - load = 0x41c66000
00338b14 hunk 1 [12] - string = 'hash_0'
00338b20 hunk 3 #106 [6] - algo = 'crc32'
00338b34 hunk 3 #111 [4] - value = 0xfceeb942
00338b44 hunk 2 [48] - string = 'qcaarmv8_HW253_squashFS_filesystem'
00338b74 hunk 3 #0 [28] - info = 'squashFS for qcaarmv8_HW253'
00338b9c hunk 3 #50 [4] - #address-cells = 0x00000001 = 1
00338bac hunk 3 #252 [4] - avm,data-align = 0x00001000 = 4096
00338bbc hunk 3 #65 [16609280] - data = <binary blob>
0130fbc8 hunk 3 #70 [11] - type = 'filesystem'
0130fbe0 hunk 3 #83 [5] - compression = 'none'
0130fbf4 hunk 3 #95 [4] - load = 0x43000000
0130fc04 hunk 3 #267 [97] - avm,kernel-args = 'mtdram=ram-filesystem,0x43000000,0x44000000 mtdparts_ext=ram-filesystem:16609280@0x0(rootfs_ram)'
>>>>>>>>>>>>>>>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^
0130fc74 hunk 1 [12] - string = 'hash_0'
0130fc80 hunk 3 #106 [6] - algo = 'crc32'
0130fc94 hunk 3 #111 [4] - value = 0x82adcb2f
0130fca4 hunk 2 [32] - string = 'configurations'
0130fcc4 hunk 1 [28] - string = 'qcaarmv8_HW253_config_0'
0130fce0 hunk 3 #283 [22] - kernel = 'qcaarmv8_HW253_kernel'
0130fd04 hunk 3 #290 [25] - fdt = 'qcaarmv8_HW253_flat_dt_0'
0130fd2c hunk 3 #294 [35] - squashFS = 'qcaarmv8_HW253_squashFS_filesystem'
0130fd5c hunk 2 [32] - string = 'qcaarmv8_HW253_config_2'
0130fd7c hunk 3 #283 [22] - kernel = 'qcaarmv8_HW253_kernel'
0130fda0 hunk 3 #290 [25] - fdt = 'qcaarmv8_HW253_flat_dt_2'
0130fdc8 hunk 3 #294 [35] - squashFS = 'qcaarmv8_HW253_squashFS_filesystem'
# Devicetree Blob (DTB) strings
0130fdf8 hunk 2 [28] - string = 'description'
0130fe14 hunk -> [9] - array[] = 'timestamp'
0130fe1e hunk -> [14] - array[] = 'avm,gu-version'
0130fe2d hunk -> [12] - array[] = 'avm,variants'
0130fe3a hunk -> [14] - array[] = '#address-cells'
0130fe49 hunk -> [4] - array[] = 'data'
0130fe4e hunk -> [4] - array[] = 'type'
0130fe53 hunk -> [4] - array[] = 'arch'
0130fe58 hunk -> [2] - array[] = 'os'
0130fe5b hunk -> [11] - array[] = 'compression'
0130fe67 hunk -> [4] - array[] = 'load'
0130fe6c hunk -> [5] - array[] = 'entry'
0130fe72 hunk -> [4] - array[] = 'algo'
0130fe77 hunk -> [5] - array[] = 'value'
0130fe7d hunk -> [13] - array[] = 'avm,endianess'
0130fe8b hunk -> [21] - array[] = 'avm,kernel_text_start'
0130fea1 hunk -> [9] - array[] = 'avm,names'
0130feab hunk -> [15] - array[] = 'avm,token_table'
0130febb hunk -> [15] - array[] = 'avm,token_index'
0130fecb hunk -> [12] - array[] = 'avm,num_syms'
0130fed8 hunk -> [13] - array[] = 'avm,addresses'
0130fee6 hunk -> [17] - array[] = 'avm,relative_base'
0130fef8 hunk -> [11] - array[] = 'avm,offsets'
0130ff04 hunk -> [14] - array[] = 'avm,data-align'
0130ff13 hunk -> [15] - array[] = 'avm,kernel-args'
0130ff23 hunk -> [6] - array[] = 'kernel'
0130ff2a hunk -> [3] - array[] = 'fdt'
0130ff2e hunk -> [8] - array[] = 'squashFS'
0130ff37 hunk 0 [0] - hunk end
Das beantwortet aber immer noch nicht meine Frage, was ich mit der Größe des SquashFS-Images soll. Ich brauche, um das FS zu mounten, den OFFSET und die Größe spielt hier gar keine Rolle (ich WILL das ja nirgendwohin kopieren, sondern direkt aus der eMMC-Partition mounten mit dem gesuchten Offset), weil die Größe des SquashFS-Images auch noch einmal in dessen Superblock steht und da holt sich der FS-Treiber die dann auch her - die muß ich auch nicht angeben. Die ist also ziemlich nutzlos und ich gebe sie selbst auch nur noch einmal aus, falls ich doch irgendwann mal das Image herauskopieren will, weil es nicht anders geht.
Und ja, ich kenne das Tool ... erstens ist es Perl, was mir auf der Box nichts bringt (ich werde deshalb definitiv kein Perl auf eine Box bringen) und zweitens verstehe ich nicht, warum man (zumindest zum Zerlegen) soviel Aufwand betreiben wollte. Die Struktur der Image-Datei ist ziemlich "straight", nur die 64 Byte mit dem, was ich für eine Signatur halte, sind bisher noch "unerklärt". Für den Teil, der danach kommt, gibt (und gab) es aber schon genug Tools - das dtc-Projekt hatte da auch schon ein fdtdump (das in vielen Distros auch in einem dtc-Paket enthalten ist) und mit dem kann man den Teil ab Offset 0x48 dann auch wunderbar zerlegen lassen.
Das ist auch genau das, was ich anderen als Ansatz empfohlen hatte, als es um die 7530ax und Modifikationen auf der Basis von "modfs" ging - https://www.ip-phone-forum.de/threads/wie-modifiziere-ich-die-originale-firmware-vom-hersteller-und-wie-installiere-ich-meine-eigene-dann-auf-der-fritz-box.307161/post-2450432
Da bei fdtdump aber die eingebetteten Images als Hex-Daten in der Struktur mit ausgegeben wurden, habe ich auf der Basis von dessen Quelltext ein weiteres Tool fitdump gebaut, was neben der notwendigen Struktur für ein späteres mkimage die BLOBs für die Images noch in Dateien schreibt und diese Dateien dann über eine /incbin/-Anweisung in der its-Datei wieder einbindet: PeterPawn/dtc@eecbbec
Das sind am Ende nur marginale Änderungen zwischen fdtdump.c und fitdump.c:
--- fdtdump.c 2022-03-06 16:56:53.991042825 +0100
+++ fitdump.c 2022-03-06 16:56:53.991042825 +0100
@@ -3,13 +3,24 @@
* fdtdump.c - Contributed by Pantelis Antoniou <pantelis.antoniou AT gmail.com>
*/
+/*
+ * extended to fitdump.c - a tool to dissect a Flattened uImage Tree
+ *
+ * the main difference to the original code is output of BLOBs to separate files
+ *
+ */
+
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
+#include <errno.h>
#include <inttypes.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
#include <libfdt.h>
#include <libfdt_env.h>
@@ -24,6 +35,12 @@
#define PALIGN(p, a) ((void *)(ALIGN((uintptr_t)(p), (a))))
#define GET_CELL(p) (p += 4, *((const fdt32_t *)(p-4)))
+static char *out_dir = "./fit-dump";
+static char *out_name = "image.its";
+static char *out_file_mask = "image_%03u.bin";
+static int out_file_index = 0;
+static char out_file_name[PATH_MAX];
+
static const char *tagname(uint32_t tag)
{
static const char * const names[] = {
@@ -44,6 +61,29 @@
#define dumpf(fmt, args...) \
do { if (debug) printf("// " fmt, ## args); } while (0)
+static char *get_image_name(void)
+{
+ snprintf(out_file_name, sizeof(out_file_name), out_file_mask, ++out_file_index);
+ return out_file_name;
+}
+
+static void dump_image_data(const char *data, int len, const char *out_file)
+{
+ int fdo;
+ size_t written = 0;
+ size_t outlen;
+
+ printf(" = /incbin/(\"%s\");\n", out_file);
+ if ((fdo = open(out_file, O_WRONLY | O_CREAT)) == -1)
+ return;
+ while ((int) written < len) {
+ outlen = write(fdo, (data + written), (len - written));
+ if (outlen <= 0) break;
+ written += outlen;
+ }
+ close(fdo);
+}
+
static void dump_blob(void *blob, bool debug)
{
uintptr_t blob_off = (uintptr_t)blob;
@@ -144,22 +184,28 @@
dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
printf("%*s%s", depth * shift, "", s);
- utilfdt_print_data(t, sz);
- printf(";\n");
+ if (sz > 512) {
+ dump_image_data(t, sz, get_image_name());
+ }
+ else {
+ utilfdt_print_data(t, sz);
+ printf(";\n");
+ }
}
}
/* Usage related data. */
-static const char usage_synopsis[] = "fdtdump [options] <file>";
-static const char usage_short_opts[] = "ds" USAGE_COMMON_SHORT_OPTS;
+static const char usage_synopsis[] = "fitdump [options] <file>";
+/* static const char usage_short_opts[] = "ds" USAGE_COMMON_SHORT_OPTS; */
+static const char usage_short_opts[] = "d" USAGE_COMMON_SHORT_OPTS;
static struct option const usage_long_opts[] = {
{"debug", no_argument, NULL, 'd'},
- {"scan", no_argument, NULL, 's'},
+/* {"scan", no_argument, NULL, 's'}, */
USAGE_COMMON_LONG_OPTS
};
static const char * const usage_opts_help[] = {
"Dump debug information while decoding the file",
- "Scan for an embedded fdt in file",
+/* "Scan for an embedded fdt in file", */
USAGE_COMMON_OPTS_HELP
};
@@ -183,14 +229,16 @@
const char *file;
char *buf;
bool debug = false;
- bool scan = false;
+/* bool scan = false; */
size_t len;
+ struct stat od;
+ char cwd[PATH_MAX];
- fprintf(stderr, "\n"
+/* fprintf(stderr, "\n"
"**** fdtdump is a low-level debugging tool, not meant for general use.\n"
"**** If you want to decompile a dtb, you probably want\n"
"**** dtc -I dtb -O dts <filename>\n\n"
- );
+ ); */
while ((opt = util_getopt_long()) != EOF) {
switch (opt) {
case_USAGE_COMMON_FLAGS
@@ -198,21 +246,28 @@
case 'd':
debug = true;
break;
- case 's':
- scan = true;
- break;
- }
+/* case 's':
+ * scan = true;
+ * break;
+ */ }
}
if (optind != argc - 1)
usage("missing input filename");
file = argv[optind];
+ if (stat(out_dir, &od) != -1)
+ die("output directory does exist already: %s\n", out_dir);
+
+ if (mkdir(out_dir, S_IRWXU | S_IRWXG | S_IROTH | S_IXOTH) == -1)
+ die("error %u (%s) creating output directory: %s\n", errno, strerror(errno), out_dir);
+
buf = utilfdt_read(file, &len);
if (!buf)
die("could not read: %s\n", file);
/* try and locate an embedded fdt in a bigger blob */
- if (scan) {
+/* if (scan) { */
+ { /* always scan for FDT magic */
unsigned char smagic[FDT_MAGIC_SIZE];
char *p = buf;
char *endp = buf + len;
@@ -237,12 +292,21 @@
}
if (!p || (size_t)(endp - p) < sizeof(struct fdt_header))
die("%s: could not locate fdt magic\n", file);
- printf("%s: found fdt at offset %#tx\n", file, p - buf);
+/* printf("%s: found fdt at offset %#tx\n", file, p - buf); */
buf = p;
- } else if (!valid_header(buf, len))
- die("%s: header is not valid\n", file);
+ } /* else if (!valid_header(buf, len))
+ die("%s: header is not valid\n", file); */
+
+ if (NULL == getcwd(cwd, sizeof(cwd)))
+ die("Unable to get current working directory: %u (%s)\n", errno, strerror(errno));
+ if (chdir(out_dir) == -1)
+ die("Unable to change directory to: %s, error %u (%s)\n", out_dir, errno, strerror(errno));
+ if (NULL == freopen(out_name, "w", stdout))
+ die("Unable to redirect STDOUT to: %s, error %u (%s)\n", out_name, errno, strerror(errno));
dump_blob(buf, debug);
+ chdir(cwd);
+
return 0;
}
und die restlichen Änderungen sind nur "Verwaltung".
Und exakt an der Ausgabe dieses Tools orientiert(e) sich dann auch die Shell-Variante fitdump.sh - nur die Datei-Verwaltung ist etwas anders, weil das Binary fitdump ein Verzeichnis fit-dump anlegt (der zusätzliche Bindestrich, damit das auch im Verzeichnis erfolgen kann, wo das Tool selbst liegt) und seine Daten dort hinein schreibt, während das Shell-Skript das im aktuellen Verzeichnis ablegt (vorhandene Dateien namens image.its und image_nnn.bin werden gnadenlos überschrieben).
Das Shell-Skript dient(e) dann als Vorlage für fit-findfs.sh, was gar keine weiteren Daten ausgibt und dennoch intern den gesamten Baum abläuft. Am Ende wird dann Offset und Größe des größten gefundenen SquashFS-Images ausgegeben (unter der Annahme, daß das Image mit dem GUI das größte sein müßte, wenn es mehrere gibt) und nichts weiter ... mit diesen Angaben sollte sich dann (sofern mount und/oder losetup den Offset berücksichtigen können) das SquashFS-Image auch direkt im FIT-Image (oder im Block-Device, wo dieses Image abgelegt wurde) mounten lassen.
Und das ist das Ziel, zu dem ich will ... und am Ende bitte auch alles - nach Möglichkeit - ohne zusätzliche Programme, sondern bei den verwendeten Shell-Kommandos auf das beschränkt, was schon in der AVM-Firmware enthalten ist.
Ansonsten könnte ich auch problemlos das Ganze mit einem C-Programm regeln (das wäre ja genauso nur ein abgespecktes fitdump), dann habe ich auch keine Performance-Probleme ... aber genau das will ich eben nicht, weil der Boot-Manager bisher in exakt derselben Form (auch wenn's mittlerweile mehr als eine einzelne Datei geworden ist) auf verschiedenen Modellen lauffähig ist - sogar egal, ob da nun LE- oder BE-Order verwendet wird.
Mit einem zusätzlichen Binary müßte man wieder für jede Plattform unterschiedliche Dateien bereitstellen.
Und meine noch einmal geänderte Version des Shell-Codes (vorerst habe ich nur fitdump.sh geändert: 4605424, erst nach Test übernehme ich das dann auch nach fit-findfs.sh) liefert auf x86 (6490) und x64 (MacMini) ziemlich dieselben Ergebnisse wie die vorhergehende Version, während es jetzt deutlich weniger dd-Aufrufe sind. Das läßt mich noch mehr vermuten, daß es auf x86 da bereits Optimierungen gab - mal sehen, wie das jetzt auf dem FR6000 funktioniert. Mittlerweile sind es nur noch 483 dd-Aufrufe mit der AVM-Firmware für den Repeater.
Wenn's das auch nicht bringt, fehlen mir langsam die Ideen und dann kommt doch wieder das Herauskopieren des FIT-Images aus der Partition in Frage, auch wenn ich immer noch rätsele, warum das auf dem Hawkeye-SoC sogar im tmpfs so lahm läuft.
Mehr als eine Minute habe ich jedenfalls nicht mal in der Phase der Implementierung des Shell-Codes gesehen, obwohl da noch alles viel mehr mit Debug-Ausgaben gespickt war und ich die auch jedesmal anzeigen ließ (das Terminal mit dem Scrollen ist ja dabei i.d.R. die größte Bremse).
Vorgewarnt durch die unterschiedlichen Laufzeiten habe ich die aktuelle Implementierung dann auch mal auf einer 7490 laufen lassen (und noch einmal auf einer 6490 zum Vergleich) - jeweils mit identischen Bedingungen (Skript + FIT-Image im tmpfs, STDOUT und STDERR umgeleitet in Dateien im tmpfs und mit --debug-Option, was zu mehr Zugriffen bei der Ausgabe führt) gemessen:
6490
/var # time sh ./fitdump.sh -d fit-image >fitdump.out 2>fitdump.dbg
/var # tail fitdump.dbg
Property node at offset 0x02ad80fc, value size=18, name=kernel
Property node at offset 0x02ad811c, value size=25, name=fdt
Property node at offset 0x02ad8144, value size=31, name=squashFS
End node at offset 0x02ad8170
End node at offset 0x02ad8174
End node at offset 0x02ad8178
FDT end found at offset 0x02ad817c
real 0m 48.56s
user 0m 14.29s
sys 0m 26.61s
/var #
7490
/var # time sh ./fitdump.sh -d fit-image >fitdump.out 2>fitdump.dbg
/var # tail fitdump.dbg
Property node at offset 0x02ad80fc, value size=18, name=kernel
Property node at offset 0x02ad811c, value size=25, name=fdt
Property node at offset 0x02ad8144, value size=31, name=squashFS
End node at offset 0x02ad8170
End node at offset 0x02ad8174
End node at offset 0x02ad8178
FDT end found at offset 0x02ad817c
real 1m 47.35s
user 0m 42.69s
sys 1m 31.39s
/var #
Verwendet wurde die AVM-Datei für die 5590, weil die bisher die meisten BLOBs enthält und deren Kopieren auch einen Faktor darstellen kann, auch wenn ich das durch vier dd-Aufrufe so zusammen setze, daß der größte Teil der BLOBs mit 1K-Blöcken kopiert werden kann, obwohl die Daten nur auf einer 4-Byte-Grenze "aligned" sind.
Dabei hatte die 7490 noch zwei Zugriffe weniger zu bewältigen, weil die ersten 8 Byte nicht gelesen wurden durch eine Änderung im Skript - die wären ohnehin LE, während der MIPS-Prozessor der 7490 BE verwendet.
Der Unterschied zwischen den Modellen (auch wenn sicherlich kein VR9-Gerät bei AVM ein FIT-Image sehen wird) ist schon eklatant ... und durch Benchmarks auch noch einigermaßen zu erklären in diesem Fall, wenn schon die Memory-Bandwidth nur die Hälfte ist.
/var # cat /proc/avm/benchmark/complete
AVM-RAM-Benchmark
=============================================
IRQs: off (alle Tests mit deaktivierten IRQs)
CPU-Clock: 1200052000
RAM-Clock: 100000000 (eff. Datentaktrate)
BUS-Breite (Word=): 32 Bit
Measure-Time: 1 * 1.0s
-- Results --
=============================================================================
type | total read | loops | DDR-Ticks | 32Bit |
| in kb | | /32Bit | Worte/s | kB/s
=============================================================================
read | 530432 | 1 | 0.736 | 135790592 | 530432
| | | | |
Lineares Lesen aus dem RAM
-----------------------------------------------------------------------------
read | 676864 | 1 | 0.577 | 173277184 | 676864
| | | | |
Die gelesenen Werte stehen im Speicher nicht hintereinander.
D.h. die CPU kann den Cache nicht nutzen.
-----------------------------------------------------------------------------
read/write | 269312 | 1 | 1.450 | 68943872 | 269312
| | | | |
Immer schoen im Wechsel 1x Lesen und 1x Schreiben.
-----------------------------------------------------------------------------
write | 776704 | 1 | 0.502 | 198836224 | 776704
| | | | |
Lineares Schreiben in den RAM.
-----------------------------------------------------------------------------
/var #
/var # cat /proc/avm/complete
AVM-RAM-Benchmark
=============================================
IRQs: off (alle Tests mit deaktivierten IRQs)
CPU-Clock: 500000000
RAM-Clock: 500000000 (eff. Datentaktrate)
BUS-Breite (Word=): 16 Bit
Measure-Time: 1 * 1.0s
-- Results --
========================================================================================
type | total read | loops | DDR-Ticks | 16Bit | | Stalls per |
| in kb | | /16Bit | Worte/s | kB/s | Instruction |
========================================================================================
read | 265600 | 1 | 3.676 | 135987200 | 265600 | 4.416 |
Pipeline-friendly | | | | | | |
Lesen aus dem RAM mit optimaler Unterstuetzung der Pipline. | | |
D.h. der Code ist gewaehlt, dass die Pipeline nicht geleert | | |
werden muss und so keine Zeit verschwendet wird. | | |
----------------------------------------------------------------------------------------
read | 248128 | 1 | 3.935 | 127041536 | 248128 | 5.544 |
extrema | | | | | | |
Die gelesenen Werte stehen im Speicher nicht hintereinander. | | |
D.h. die CPU kann den Cache nicht nutzen. | | |
----------------------------------------------------------------------------------------
read/write | 135296 | 1 | 7.218 | 69271552 | 135296 | 3.570 |
| | | | | | |
Immer schoen im Wechsel 1x Lesen und 1x Schreiben. | | |
----------------------------------------------------------------------------------------
write | 353344 | 1 | 2.763 | 180912128 | 353344 | 3. 54 |
| | | | | | |
Einfaches Schreiben. | | |
----------------------------------------------------------------------------------------
/var #
Aber die ARM-Cores im IPQ8074 sollten eigentlich deutlich schneller sein ... deshalb würde ich (solange der AVM-Benchmark den Geräten nicht das Gegenteil nachweist) auch erwarten, daß sich aus Prozessor und RAM kein Nachteil bei der Geschwindigkeit der Ausführung ergibt.
Ich werde jetzt trotzdem mal noch etwas an der 7490 herumdoktern und dabei auf einer USB(2)-HDD eine möglichst schlechte I/O-Performance einbeziehen - zumindest kann ich da mal ein Profiling für die internen Shell-Funktionen einbauen und ermitteln, wo die Zeit wirklich bleibt.
Jedenfalls kann man auf der 7490 auch zusehen, wie jedes einzelne printf für die Ausgabe abgearbeitet wird, weil sich einige Zeilen tatsächlich Stück für Stück aufbauen (Name, dann Gleichheitszeichen, dann erst der Wert) - mal sehen, ob ich die Laufzeit irgendwie noch verringern kann ... zunächst dann eben erst mal auf einem MIPS-System.
@freetz-ng-mod
Solltest Du noch die Zeit findest (ich will erst mal immer noch nicht selbst zugreifen und für das eine Kommando lohnt das auch nicht), könntest Du mal unterhalb von /proc/avm nachsehen (mittels ls -l) ... bei AVM findet sich da fast immer auch ein Benchmark, der schon in den Kernel einkompiliert ist (s.o., die Namen wechseln manchmal, auch bei verschiedenen Plattformen) und den man durch ein einfaches cat (wieder siehe oben) anwerfen kann. Dann hätte man mal eine Vorstellung, wie schnell das SoC im FR6000 tatsächlich sein sollte. Wenn das auch bei der Hälfte der x86-Performance herumgurkt, suche ich vielleicht nur Gespenster und die I/O-Performance spielt nur eine sehr untergeordnete Rolle.
EDIT: Die Gegenprobe unter openSUSE Tumbleweed (x64) ergibt dann zwar eine kürzere Laufzeit, aber wegen der verwendeten Image-Datei immer noch eine, die über der Zeit für das 6000er-Image liegt:
vidar:/home/GitHub/YourFritz/eva_tools $ time sh ./fitdump.sh -d fit-images/FB5590/fit-image >fitdump.out 2>fitdump.dbg
real 0m23.364s
user 0m13.439s
sys 0m13.187s
wobei hier die I/O-Zugriffe alle auf ein BTRFS auf einer rotierenden HD (5400 rpm) erfolgt sind (aber das dürfte nur marginale Unterschiede ergeben).
cat /proc/avm/benchmark/complete
AVM-RAM-Benchmark
=============================================
IRQs: off (alle Tests mit deaktivierten IRQs)
CPU-Clock: 710000000
RAM-Clock: 1075200000 (eff. Datentaktrate)
BUS-Breite (Word=): 16 Bit
Measure-Time: 1 * 1.0s
-- Results --
=============================================================================
type | total read | loops | DDR-Ticks | 16Bit |
| in kByte | | /16Bit | Worte/s | kByte/s
=============================================================================
read | 2248704 | 1 | 0.933 | 1151336448 | 2248704
| | | | |
Burstartiges Lesen aus dem RAM unter Nutzung von load multiple.
-----------------------------------------------------------------------------
read | 16060416 | 1 | 0.661 | 1625863168 | 3175514
| | | | |
Die gelesenen Werte stehen im Speicher nicht hintereinander.
D.h. die CPU kann den Cache nicht nutzen.
-----------------------------------------------------------------------------
read/write | 1468416 | 1 | 1.430 | 751828992 | 1468416
| | | | |
Immer schoen im Wechsel 1x Lesen und 1x Schreiben.
-----------------------------------------------------------------------------
write | 2668544 | 1 | 0.786 | 1366294528 | 2668544
| | | | |
Einfaches Schreiben (Cache-Nutzung).
-----------------------------------------------------------------------------
write | 5433344 | 1 | 1.844 | 582848512 | 1138376
| | | | |
Burst-Schreiben unter Nutzung von store multiple.
-----------------------------------------------------------------------------
cat /proc/avm/benchmark/complete
AVM-RAM-Benchmark
=============================================
IRQs: off (alle Tests mit deaktivierten IRQs)
CPU-Clock: 710000000
RAM-Clock: 1075200000 (eff. Datentaktrate)
BUS-Breite (Word=): 16 Bit
Measure-Time: 1 * 1.0s
-- Results --
=============================================================================
type | total read | loops | DDR-Ticks | 16Bit |
| in kByte | | /16Bit | Worte/s | kByte/s
=============================================================================
read | 2271232 | 1 | 0.924 | 1162870784 | 2271232
| | | | |
Burstartiges Lesen aus dem RAM unter Nutzung von load multiple.
-----------------------------------------------------------------------------
read | 16044032 | 1 | 0.664 | 1617474560 | 3159130
| | | | |
Die gelesenen Werte stehen im Speicher nicht hintereinander.
D.h. die CPU kann den Cache nicht nutzen.
-----------------------------------------------------------------------------
read/write | 1468416 | 1 | 1.430 | 751828992 | 1468416
| | | | |
Immer schoen im Wechsel 1x Lesen und 1x Schreiben.
-----------------------------------------------------------------------------
write | 2670592 | 1 | 0.786 | 1367343104 | 2670592
| | | | |
Einfaches Schreiben (Cache-Nutzung).
-----------------------------------------------------------------------------
write | 5443584 | 1 | 1.828 | 588091392 | 1148616
| | | | |
Burst-Schreiben unter Nutzung von store multiple.
-----------------------------------------------------------------------------
um das FS zu mounten, den OFFSET
Den findet mit den kernel-args nicht :(
Macht ein RAM-Komprimierer die ganze Sache so lahm? Früher nutzt AVM gern RAMZSWAP. Was macht denn "net/mem_manager.ko"? Es scheint auch ein paar "offload" Module zu geben (7590)
build/original/filesystem/lib/modules/4.9.218/extra/offload_qos.ko
build/original/filesystem/lib/modules/4.9.218/extra/offload_pa.ko
build/original/filesystem/lib/modules/4.9.218/extra/offload_util.ko
build/original/filesystem/lib/modules/4.9.218/extra/offload_dp.ko
Wenn ich die 7530 AX dazubekomme freetz zunehmen dann hätte man 2 Geräte zum Testen. Aber zZ will die Box es ja noch nicht nehmen
Hast ja keine Console
So recht raue ich mich das auch nicht. Denn habe da kein Plan wie ich das machen soll
time sh ./fit-findfs.sh /dev/disk/by-partlabel/fit0
filesystem_offset=3378120 filesystem_size=18857984
real 1h 38m 22s
user 11m 46.41s
sys 2h 11m 17s
Auf alle Fälle hat der IPQ8074 einen deutlich höheren (Memory-)Durchsatz, selbst wenn der offenbar auch nur eine Bus-Breite von 16 Bit verwendet - was mich aber schon etwas überrascht. Aber denkbar, daß dann auch I/O-Operationen auf 16 Bit-Übertragungen beschränkt sind - wobei da ja hoffentlich DMA verwendet wird und keine register-basierten Zugriffe. Aber das würde den I/O-Durchsatz dann schon deutlich verringern.
Wenn das mit dem Block-Device als Quelle aber über 1 1/2 Stunden läuft, ist da irgendwo ein Flaschenhals, den ich so gar nicht verstehe - da müssen ja I/O-Operationen auf dem eMMC-Chip so was von lahm sein, daß man sich unwillkürlich fragt, wie wohl die I/O-Performance des NAS-Speichers auf einer 4060 aussehen mag. Dem Repeater fehlen ja die NAS-Funktionen und der größte Teil des eMMC-Flashs liegt brach in der letzten Partition - daher kann man das nur schlecht messen auf dem Repeater.
Was passiert denn bei einem time dd if=/dev/disk/by-partlabel/fit0 of=/dev/null bs=256 - das würde den gesamten Inhalt der Partition (80 MB) nach /dev/null kopieren - eine solche Aktion dauert auf einer 6490 (die hat halt auch den eMMC-Speicher und ist deshalb ein passabler Vergleich) nur wenige Sekunden, im Vergleich zum "Befüllen" davor, wobei hier sicherlich Schreibraten und die Geschwindigkeit des PRNG hinter /dev/urandom eine unheilige Allianz bilden, die für 1 MB etwas über eine Sekunde benötigt:
~ # time dd if=/dev/urandom of=/var/media/ftp/random.data bs=1M count=80
80+0 records in
80+0 records out
83886080 bytes (80.0MB) copied, 78.864825 seconds, 1.0MB/s
real 1m 18.86s
user 0m 0.00s
sys 1m 3.15s
~ # time dd of=/dev/null if=/var/media/ftp/random.data bs=256
327680+0 records in
327680+0 records out
83886080 bytes (80.0MB) copied, 2.967431 seconds, 27.0MB/s
real 0m 2.96s
user 0m 0.33s
sys 0m 1.08s
~ # time dd of=/dev/null if=/var/media/ftp/random.data bs=1
83886080+0 records in
83886080+0 records out
83886080 bytes (80.0MB) copied, 317.045842 seconds, 258.4KB/s
real 5m 17.04s
user 1m 17.26s
sys 3m 53.00s
~ #
Auch bei wiederholten Versuchen bleibt die Leserate (mit 256-Byte-Blöcken) stabil oberhalb von 25 MB/s (immer knapp über 3 Sekunden gesamt) - und selbst wenn man jedes Byte einzeln lesen läßt, ist das nach nicht einmal 5 1/2 Minuten (knapp über 317 Sekunden) fertig (obwohl das 256x soviele Zugriffe sind).
Selbst wenn das auf einem IPQ8074 doppelt so lange dauern sollte, wie auf einem Puma6, wären das immer noch unter 10 Sekunden beim kompletten Kopieren der Partition und die genutzte Größe liegt ja deutlich unterhalb der 80 MB. Das macht dann die Option, das gesamte FIT-Image erst mal aus der Partition ins tmpfs zu kopieren, wieder deutlich attraktiver.
@freetz-ng-mod
Das Skript hat auch die Änderungen mit weniger dd-Aufrufen noch nicht - aber dennoch danke, jetzt ist wenigstens auch klar, wie lange das (in der alten Form) mit dem Block-Device gebraucht hätte. Knapp 100 Minuten sind schon sehr gruselig - wenn Du den Repeater akut nicht anderweitig nutzt, könntest Du noch einmal das fitdump.sh aus dem Repo auf das Block-Device loslassen - das hat die geänderte Implementierung und macht im Prinzip dasselbe wie das fit-findfs.sh, nur werden dabei noch Daten ausgegeben (die aber nicht unbedingt interessieren und die Du auch in Dateien umleiten kannst, wie ich das oben beim Vergleich 6490 <-> 7490 gemacht habe).
Wenn das aber schneller sein sollte (das wird vermutlich auch noch nicht ausreichen), dann könnte man die Verbesserung beurteilen und überlegen, ob man auf diesem Weg überhaupt an sinnvolle Zeiten für die Ausführung herankommen kann (bis zu 2 Minuten habe ich mittlerweile schon fast akzeptiert, zumal das zuvor auch aus dem tmpfs bei Dir ja nicht schneller war) oder ob ich mir etwas anderes einfallen lassen sollte. Ich will ja auch nicht beim Start des FRITZ!OS zu viele Ressourcen belegen und den Start unnötig verzögern ... daher würde ich vermutlich (auf Geräten, wo ein FIT-Image benutzt wird) erst dann mit dem (einmaligen) Zerlegen beginnen, wenn die Auslastung der Box nach dem Start wieder deutlich zurückgegangen ist.
Werde ich heute Nacht durchlaufen lassen. Bin grade dabei noch mal ein neues Image für die 7530 AX zubauen. Denn Freetz-NG/freetz-ng#483 (comment) da bin ich grade dran.
Kannst mir die Block-Device sagen oder den Befehl wie ich das mache. Dann starte ich das im Hintergrund schon
time dd if=/dev/disk/by-partlabel/fit0 of=/dev/null bs=256
/null bs=256
327680+0 records in
327680+0 records out
real 0m 0.93s
user 0m 0.06s
sys 0m 0.36s
Wie ... das dauert jetzt keine ganze Sekunde? (Das Kommando stimmt schon und die erste Zeile der Ausgabe ist vermutlich nur zuviel kopiert, die gehört noch zum Kommando darüber.)
DAS wäre dann auch das erwartete Ergebnis in Anbetracht des Potentials des SoC. Nur warum läuft dann das Zerlegen so unendlich lange? Am Skript kann's auch kaum liegen, das arbeitet ja auf anderen Plattformen auch und wird dort noch in endlichen Zeiträumen fertig.
Was passiert denn, wenn Du die Blocksize (das bs) auf 1 setzt?
EDIT:
Die Block-Devices für die FIT-Images sind IMMER /dev/disk/by-partlabel/fit$(bootslotctl get_other), wobei das mit get_other dann das inaktive und mit get_active das aktive System ist. Wenn Du eines der Shell-Skripte aus meinem Repo geladen hast (egal, ob fit-findfs.sh oder fitdump.sh), kannst Du denen auch immer das Block-Device als Eingabequelle übergeben - oder eben auch eine "reguläre Datei", wenn ein FIT-Image nicht in einer kompletten Partition steht, sondern irgendwo im Filesystem herumliegt (was beim Repeater wieder unwahrscheinlich ist, der hat ja keine "data"-Partition in Benutzung).
time dd if=/dev/disk/by-partlabel/fit0 of=/dev/null bs=256
327680+0 records in
327680+0 records out
real 0m 0.93s
user 0m 0.07s
sys 0m 0.35s
time dd if=/dev/disk/by-partlabel/fit0 of=/dev/null 1=256
BusyBox v1.34.1 (2022-02-20 10:16:55 CET) multi-call binary.
Usage: dd [if=FILE] [of=FILE] [ibs=N obs=N/bs=N] [count=N] [skip=N] [seek=N]
[conv=notrunc|noerror|sync|fsync]
[iflag=skip_bytes|count_bytes|fullblock|direct] [oflag=seek_bytes|append|direct]
Copy a file with converting and formatting
if=FILE Read from FILE instead of stdin
of=FILE Write to FILE instead of stdout
bs=N Read and write N bytes at a time
ibs=N Read N bytes at a time
obs=N Write N bytes at a time
count=N Copy only N input blocks
skip=N Skip N input blocks
seek=N Skip N output blocks
conv=notrunc Don't truncate output file
conv=noerror Continue after read errors
conv=sync Pad blocks with zeros
conv=fsync Physically write data out before finishing
conv=swab Swap every pair of bytes
iflag=skip_bytes skip=N is in bytes
iflag=count_bytes count=N is in bytes
oflag=seek_bytes seek=N is in bytes
iflag=direct O_DIRECT input
oflag=direct O_DIRECT output
iflag=fullblock Read full blocks
oflag=append Open output in append mode
status=noxfer Suppress rate output
status=none Suppress all output
N may be suffixed by c (1), w (2), b (512), kB (1000), k (1024), MB, M, GB, G
Command exited with non-zero status 1
real 0m 0.00s
user 0m 0.00s
sys 0m 0.00s
Mißverständnis ... das muß dann bs=1 heißen anstelle von bs=256.
Ich war weiter oben noch beim Editieren und habe da Text hinzugefügt.
da muss ich nun warten
time sh ./fitdump.sh /dev/disk/by-partlabel/fit$(bootslotctl get_other)
also nachher machen
Edit
time dd if=/dev/disk/by-partlabel/fit0 of=/dev/null bs=1
83886080+0 records in
83886080+0 records out
real 1m 34.32s
user 0m 14.13s
sys 1m 16.75s
Also langsamer, aber immer noch extrem schnell im Vergleich zu 6490 und 7490 - DAS war eigentlich auch zu erwarten. Nur macht es das Verhalten beim Zerlegen um so unverständlicher ... aber zumindest habe ich dann eine Option, wie ich es beschleunigen kann. Wenn die Eingabe ein Block-Device ist, wird halt erst mal in der erforderlichen Länge ins tmpfs kopiert, das macht es dann schon mal schneller (aber auch speicherhungriger).
time sh ./fitdump.sh /dev/disk/by-partlabel/fit$(bootslotctl get_other)
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x130feef (19988207)
// off_dt_struct: 0x38
// off_dt_strings: 0x130fdc0
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x12f
// size_dt_struct: 0x130fd88
/ {
description = "FIT for HW253";
timestamp = <0x61b0d51d>;
avm,gu-version = <0x00016c49>;
images {
qcaarmv8_HW253_kernel {
description = "Kernel for qcaarmv8_HW253";
avm,variants = [00];
#address-cells = <0x00000001>;
data = /incbin/("image_001.bin");
type = "kernel";
arch = "arm";
os = "linux";
compression = "lzma";
load = <0x41208000>;
entry = <0x41208000>;
hash_0 {
algo = "crc32";
value = <0xd62a705a>;
};
avm,kallsyms {
avm,endianess = "LE";
avm,kernel_text_start = <0xc0208000>;
avm,names = <0xc082fc30>;
avm,token_table = <0xc08c4930>;
avm,token_index = <0xc08c4cd0>;
avm,num_syms = <0xc082fc20>;
avm,addresses = <0xc07fd730>;
avm,relative_base;
avm,offsets;
};
};
qcaarmv8_HW253_flat_dt_0 {
description = "Device Tree for qcaarmv8_HW253_0";
#address-cells = <0x00000001>;
data = /incbin/("image_002.bin");
type = "flat_dt";
arch = "arm";
compression = "lzma";
load = <0x41c66000>;
hash_0 {
algo = "crc32";
value = <0x17a50f46>;
};
};
qcaarmv8_HW253_flat_dt_2 {
description = "Device Tree for qcaarmv8_HW253_2";
#address-cells = <0x00000001>;
data = /incbin/("image_003.bin");
type = "flat_dt";
arch = "arm";
compression = "lzma";
load = <0x41c66000>;
hash_0 {
algo = "crc32";
value = <0xfceeb942>;
};
};
qcaarmv8_HW253_squashFS_filesystem {
description = "squashFS for qcaarmv8_HW253";
#address-cells = <0x00000001>;
avm,data-align = <0x00001000>;
data = /incbin/("image_004.bin");
type = "filesystem";
compression = "none";
load = <0x43000000>;
avm,kernel-args = "mtdram=ram-filesystem,0x43000000,0x44000000 mtdparts_ext=ram-filesystem:16609280@0x0(rootfs_ram)";
hash_0 {
algo = "crc32";
value = <0x82adcb2f>;
};
};
};
configurations {
qcaarmv8_HW253_config_0 {
kernel = "qcaarmv8_HW253_kernel";
fdt = "qcaarmv8_HW253_flat_dt_0";
squashFS = "qcaarmv8_HW253_squashFS_filesystem";
};
qcaarmv8_HW253_config_2 {
kernel = "qcaarmv8_HW253_kernel";
fdt = "qcaarmv8_HW253_flat_dt_2";
squashFS = "qcaarmv8_HW253_squashFS_filesystem";
};
};
};
real 0m 49.21s
user 0m 0.49s
sys 0m 4.12s
Edit
time sh ./fit-findfs.sh /dev/disk/by-partlabel/fit$(bootslotctl get_other)
filesystem_offset=3378120 filesystem_size=16609280
real 0m 5.56s
user 0m 0.13s
sys 0m 0.12s
Jetzt verstehe ich gar nichts mehr ... das fit-findfs.sh ist ja gar nicht geändert - das ist noch dasselbe (https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/fit-findfs.sh), was vor ca. 3 Stunden erst nach 1 1/2 Stunden fertig war mit der Arbeit.
Und das ist jetzt - auch direkt auf dem Block-Device - nach nicht mal 6 Sekunden fertig? Wie geht das denn genau? Es ist zwar in etwa das, was ich erwartet hätte, aber irgendwo ist da der Wurm drin. Beim direkten Zugriff auf das Device sollten nicht mal die vorherigen Zugriffe für das fitdump.sh die Daten schon in OS-Buffern bereitstellen und damit das Ergebnis verfälschen ... wobei ich auch mit den 50 Sekunden leben könnte, die das fitdump.sh (und das hat tatsächlich schon die Optimierungen) gebraucht hat. Nur wo kommen dann die knapp 100 Minuten hier (https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/fit-findfs.sh) her, die ja auch zu den Beobachtungen gestern passen, daß das quälend langsam lief, was man an der Anzeige Stück für Stück im Terminal sehen konnte.
Ich bin jedenfalls erst mal ausreichend verwirrt - und suche mal nach einer Möglichkeit, das Buffering im OS als "Beschleuniger" auszuschließen - irgendwie sieht mir der zweite Versuch mit dem fit-findfs.sh doch zu sehr nach OS-Caching aus und dann wäre ja doch wieder das Lesen vom Device (was das fitdump.sh davor noch machen mußte) der Flaschenhals. Immerhin hat das Gerät ja genug Hauptspeicher, um auch mal 35 MB FIT-Image in seinen OS-Buffern zu halten, zumal auf einem Repeater ja ohnehin weniger Prozesse laufen.