/data vergrössern

[RalfFriedl]

In welcher(n) Dateien soll man da suchen

In allen Dateien der Firmware. Gut möglich, dass ein AVM Programm die Partition mountet.

wie soll dann so ein Befehl mit mount bind aussehen

mount -o bind /data /Ziel

 

[emil70]

Die Frage wäre jetzt, wo muss dieser Eintrag genau hin

 

[crashlog]

Unter build/original/filesystem kann man ja den Ordner data umbenennen. Nach dem Imgebau und einspielen ist dann der Ordner data auch weg und es wird der angezeigt den ich umbenannt habe. Dieser hat dann aber keine jffs2-Partition.

Hallo zusammen,

wie soll Freetz oder egal welche Firmware/Programme/OS auch immer wissen das Du einen Ordner anlegst und da gerne die jffs2 gemountet haben möchtest? Wenn Du willst das in deinem Ordner die jffs2 gemountet wird dann würde Ich vorschlagen im Verzeichnis "/etc/init.d" zu suchen.
Durch eine ganz kleine Änderung wird Freetz Dir die jffs2 unter deinem erstellten Ordner mounten, getestet und geht.

Um die Größe der jffs2 zu ändern bei den neueren Firmwares wirst Du wohl etwas mehr Aufwand treiben müssen und Dich mit mtd und dem ganzen Zeug beschäftigen müssen.

Mit

cat /proc/partitions

cat /proc/mtd

kannst Du sehen was deine jffs2 so an max. Size hat und wenn da nur 1 MB angezeigt wird bekommst Du auch nur diesen 1nen MB.

[email protected]:/var/mod/root# cat /proc/partitions
major minor  #blocks  name

  31        0      14320 mtdblock0
  31        1       1423 mtdblock1
  31        2        128 mtdblock2
  31        3        256 mtdblock3
  31        4        256 mtdblock4
  31        5       3200 mtdblock5
[email protected]:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00dfc100 00020000 "rootfs"
mtd1: 00163f00 00020000 "kernel"
mtd2: 00020000 00020000 "urlader"
mtd3: 00040000 00020000 "tffs (1)"
mtd4: 00040000 00020000 "tffs (2)"
mtd5: 00320000 00020000 "jffs2"
[email protected]:/var/mod/root#

Das ist aus meiner 7240 mit 73.05.05 Firm und da ist die jffs2 3,2 MB und für meine Bedürfnisse Perfekt.

Es ist auch Schade das diese Möglichkeit an Freetz kompl. vorbei geht denn Ich brauche ja nicht zu erwähnen was alles geht mit dieser jffs2.

 

[emil70]

Hallo zusammen,

wie soll Freetz oder egal welche Firmware/Programme/OS auch immer wissen das Du einen Ordner anlegst und da gerne die jffs2 gemountet haben möchtest? Wenn Du willst das in deinem Ordner die jffs2 gemountet wird dann würde Ich vorschlagen im Verzeichnis "/etc/init.d" zu suchen.
Durch eine ganz kleine Änderung wird Freetz Dir die jffs2 unter deinem erstellten Ordner mounten, getestet und geht.

Könntest du mir die Änderung zeigen. Ich finde da nicht wirklich was.In "/etc/init.d" sind mehere Dateien, wo ich aber leider nicht sehe. In welcher ich was ändern soll

Danke

 

[crashlog]

Bei den älteren sollte es die rc.S sein sonst guck Dir mal die >S15-filesys< an dort musste die Änderung vornehmen.

#! /bin/sh
##########################################################################################
##########################################################################################
##########################################################################################
## be sure only root is allowed to write to /var/media/ftp (per default)
##########################################################################################
mkdir -p "/var/media/ftp"
chmod 755 /var/media/ftp
##########################################################################################
## keine interner Speicher (NAND)
## Nutzung des verbleibenden Speichers im Flash (nach dem squashfs image)
##########################################################################################
JFFS2LINE=`grep '"jffs2"' /proc/mtd`
if [ -n "$JFFS2LINE" ]; then
JFFS2SIZE=`echo ${JFFS2LINE} | cut -d' ' -f2`
JFFS2SIZE="0x${JFFS2SIZE}"
JFFS2SIZE=$((${JFFS2SIZE}))
JFFS2MTD=${JFFS2LINE%%:*}
JFFS2MTD=${JFFS2MTD##mtd}
jffs2_ok=1
jffs2_blks=$((${JFFS2SIZE} / (2**16)))
if [ -n "${JFFS2MTD}" ] && [ "$JFFS2SIZE" -le 4194304 ] ; then
## limit is 4194304 (4M) otherwise there was an error (prevents overwriting other areas).
if cat /proc/filesystems | grep -q 'jffs2' || modprobe jffs2; then
if mount -t jffs2 /dev/mtdblock${JFFS2MTD} /data ; then
echo "[jffs2] Mount /data success (mtd${JFFS2MTD} size ${JFFS2SIZE})"
jffs2_ok=0
else
echo "[jffs2] 1st mount /data failed, erasing mtd ${JFFS2MTD} ..."
echo "mtd $JFFS2MTD erase all" >/proc/mtd
echo "[jffs2] try 2nd mount ... "
mount -t jffs2 /dev/mtdblock${JFFS2MTD} /data
if [ $? -ne 0 ] ; then
echo "[jffs2] ERROR: 2nd mount /data failed, give up." ;
else
echo "[jffs2] 2nd Mount /data success (mtd${JFFS2MTD} size ${JFFS2SIZE})"
jffs2_ok=0
fi
fi
if [ $jffs2_ok -eq 0 ]; then
echo "[jffs2] write env variable jffs2_size to $jffs2_blks"
echo "jffs2_size $jffs2_blks" >/proc/sys/urlader/environment
fi
fi
fi
fi

Hier siehst Du jetzt in welchem Ordner die jffs2 gemounted wird /data und der Reste sollte selbsterklärend sein.

 

[marquito]

Ich habe beim Freetz Image (Fritzbox 3270, welche HW ähnlich zu 7270 ist) bauen etwa 3MB frei und würde die gerne für dir JFFS2 /data Partition nutzen. Dazu folgende Fragen:

1) Kann die Partition durch die Freetz Firmware angelegt werden, wenn ja, wo wird jffs2_size definiert? Muss dazu die boot env Variable jffs2_size (urloader) gelöscht werden?
Hat noch jemand den Patch https://freetz.github.io/attachment/ticket/619/kernel_jffs2_maxsize.patch oder wenigstens eine kleine Beschreibung, in welchen Dateien ich nach der jffs2_size suchen muss?

2) Wenn nein, würde der Bootloader eine grössere Partition anlegen, wenn man die boot env Variable vergrössert?

3) Ich habe 1 MB, die Partition ist leer (ls -la /data), durch Freetz flashen mit der Option "jffs2 löschen" gelöscht und trotzdem sind bereits etwa 360 kB belegt. Was kann die Ursache sein? Wie kann man das herausfinden?

 

[PeterPawn]

Die "Partition" wird (mittlerweile) üblicherweise vom Kernel als MTD angelegt und zwar auf der Basis der anderen "Pseudo-Partitionen", denn der Flash-Speicher wird (nach dem Bootloader) einfach fortlaufend mit dem Firmware-Image, das ja aus einem Kernel und direkt danach (an einer integralen Grenze) einem SquashFS-Dateisystem besteht, beschrieben und erst der Kernel generiert daraus dann die passenden MTD-Definitionen für genau diese Aufteilung.

Auf der Basis dieser Definitionen wird dann in der /etc/init.d/S15-filesys das JFFS2-FS initialisiert - wenn sich die Größe des Images geändert hat, funktioniert das Mounten halt nicht und die Partition wird neu initialisiert, ansonsten klappt das (erste) Mounten:

##########################################################################################
## keine interner Speicher (NAND)
## Nutzung des verbleibenden Speichers im Flash (nach dem squashfs image)
##########################################################################################
JFFS2LINE=`grep '"jffs2"' /proc/mtd`
if [ -n "$JFFS2LINE" ]; then
JFFS2SIZE=`echo ${JFFS2LINE} | cut -d' ' -f2`
JFFS2SIZE="0x${JFFS2SIZE}"
JFFS2SIZE=$((${JFFS2SIZE}))
JFFS2MTD=${JFFS2LINE%%:*}
JFFS2MTD=${JFFS2MTD##mtd}
jffs2_ok=1
jffs2_blks=$((${JFFS2SIZE} / (2**16)))
if [ -n "${JFFS2MTD}" ] && [ "$JFFS2SIZE" -le 4194304 ] ; then
## limit is 4194304 (4M) otherwise there was an error (prevents overwriting other areas).
if cat /proc/filesystems | grep -q 'jffs2' || modprobe jffs2; then
if mount -t jffs2 /dev/mtdblock${JFFS2MTD} /data ; then
echo "[jffs2] Mount /data success (mtd${JFFS2MTD} size ${JFFS2SIZE})"
jffs2_ok=0
else
echo "[jffs2] 1st mount /data failed, erasing mtd ${JFFS2MTD} ..."
echo "mtd $JFFS2MTD erase all" >/proc/mtd
echo "[jffs2] try 2nd mount ... "
mount -t jffs2 /dev/mtdblock${JFFS2MTD} /data
if [ $? -ne 0 ] ; then
echo "[jffs2] ERROR: 2nd mount /data failed, give up." ;
else
echo "[jffs2] 2nd Mount /data success (mtd${JFFS2MTD} size ${JFFS2SIZE})"
jffs2_ok=0
fi
fi
if [ $jffs2_ok -eq 0 ]; then
echo "[jffs2] write env variable jffs2_size to $jffs2_blks"
echo "jffs2_size $jffs2_blks" >/proc/sys/urlader/environment
fi
fi
fi
fi

Gleichzeitig kann man dort sehen, daß es KEINEN Sinn ergibt, jffs2_size irgendwie selbst zu setzen ... wenn eine plausible JFFS2-Größe erkannt wurde (jffs2_ok == 0), überschreibt der o.a. Code den Wert im (Urlader-)Environment wieder (EDIT: und zwar mit der Anzahl der BLÖCKE und nicht der "richtigen Größe").

Solange nicht die Beschränkung der JFFS2-Größe auf max. 4 MB zum Problem wird (if [ -n "${JFFS2MTD}" ] && [ "$JFFS2SIZE" -le 4194304 ] ; then), braucht man auch nichts weiter patchen zu lassen.

Allerdings stammt der o.a. Code aus der Version 06.06 für die 7270v3 ... und ich habe keine Ahnung, ob/wie sich die Firmware für eine 3270 (ohne Versionsangabe bzw. mit, dann als v3) davon unterscheidet. Denn wie es aussieht, gibt/gab es für die 3270 gar keine Version 06.xx mehr (https://ftp.avm.de/archive/fritz.box/fritzbox.wlan_3270_v3/firmware/deutsch/) - im Gegensatz zur 7270.

Du solltest jedenfalls erst mal in Deinem(!) Image nachsehen, wie dort die Initialisierung des JFFS2-FS aussieht - das läßt sich ja z.B. mit einem grep -r jffs2_ im Build-Verzeichnis (build/{original,modified}/filesystem) leicht finden.

Zusammengefaßt:

1. Nein (nein) / nein / nein / siehe oben.
2. Nein.
3. Siehe unten / einfach an der richtigen Stelle suchen.

JFFS2 (https://www.sourceware.org/jffs2/jffs2-html/node3.html) ist nun mal nicht so richtig gut geeignet für "sehr kleine" Partitionen (https://www.sourceware.org/jffs2/jffs2-html/node4.html):

A major annoyance for users is the amount of space currently required to be left spare for garbage collection. It is hoped that a formal proof of the amount of required space can be produced, but in the meantime a very conservative approach is taken -- five full erase blocks must be available for writing before new writes will be permitted from user space.

und bei einer (Erase-)Blocksize von 64 KB (2 ** 16) sind das nun mal 5 * 64 KB = 320 KB alleine für die "garbage collection" und da kommen dann noch die eigenen Verwaltungsinformationen des JFFS2 dazu.

EDIT: Den Code für das Parsen des Flash-Inhalts und das Anlegen der MTD-Definitionen in der richtigen Größe, findet man - nebenbei bemerkt - dann in der Datei arch/mips/ur8/ur8_mtd.c in den Kernel-Quellen (der 7270 für die Version 06.06 - aber das dürfte sich (nach dem Umstieg von Kernel 2.4 auf 2.6) nicht groß geändert haben).

 

[marquito]

Ich habe die FB 3270v3 mit der FW Version 05.54. Die /etc/init.d/S15-filesys ist die gleiche. Ausgangspunkt: jffs2_size = 16, /data ist auf /dev/mtdblock5 gemountet.

Wenn ich folgendes ausführe:
echo "jffs2_size 32" >/proc/sys/urlader/environment
reboot

dann ist nach dem reboot die Variable wieder auf 16. ABER

echo "mtd 5 erase all" >/proc/mtd
echo "jffs2_size 32" >/proc/sys/urlader/environment
reboot

führt zum gewünschten Ergebnis. Die Partition ist 32 Blocks (geht auch mit 48) gross, bei 64kb Grösse also 2MB.

Was genau machen die 2 Commands?
Das erase scheint wohl erst nach dem Reboot zu wirken, vor dem Reboot sind in /data angelegte Dateien noch da. Wird die jffs Partition damit gelöscht?
/proc/sys/urlader/environment - ist dies auf die urloader Variablen verlinkt oder eine Kopie mit der nun veränderten Variable jffs2_size=32. D.h. wird mit dem echo die urloader Variable verändert oder eine Kopie davon?

Das S15-filesys verwendet /proc/mtd und da steht meine gesetzte Grösse drin:
cat /proc/mtd
dev: size erasesize name
mtd0: 00e1d500 00020000 "rootfs"
mtd1: 00142b00 00020000 "kernel"
mtd2: 00020000 00020000 "urlader"
mtd3: 00040000 00020000 "tffs (1)"
mtd4: 00040000 00020000 "tffs (2)"
mtd5: 00200000 00020000 "jffs2"

Interessant ist noch, wenn ich später doch mal ein Image bauen sollte, was grösser ist - kommt es dann wegen des fehlenden Platzes zu einem Fehler oder wird die /data Partition gelöscht und verkleinert?

 

[PeterPawn]

Ich habe ja oben noch den Namen der Datei mit dem Parser ergänzt - da findet man dann (s)eine Antwort auf die neu aufgeworfenen Fragen.

Und ohne verstanden zu haben, was da wie genau funktioniert, sollte man nicht einfach "drauf los probieren" ... ansonsten riskiert man Probleme.

Die 3270v3 hat zwar wohl 16 MB NOR-Flash, aber am Beginn dieses Speichers liegt der Bootloader (Größe 0x20000 Bytes = 128 KB) und AM ENDE (also noch HINTER dem freien Bereich, der ggf. für eine JFFS2-Partition verwendet werden kann) liegen dann die zwei TFFS-Kopien.

Die Box verfügt also über 0x01000000 Bytes Flash-Speicher, davon gehen 0x020000 für den Bootloader und 2x 0x040000 für die TFFS-Partitionen ab. Bleiben also noch 0x00F60000 Bytes übrig ... und die sind (nach dem, was bei Dir in /proc/mtd steht) auch durch den Kernel (0x00142b00 Bytes) und das Dateisystem (0x00e1d500 Bytes) belegt.

WENN da also noch weitere 0x00200000 Bytes für mtd5 verfügbar sein sollten, dann kann das nur durch ein Überlappen von Partitionen realisiert sein - insofern macht auch alleine der Inhalt der /proc/mtd nur wenig Sinn, solange man dazu nicht auch noch die Start-Adressen ermittelt/anzeigt, was in diesem Pseudo-File ja nicht der Fall ist. Ich weiß nicht mehr genau, wie das bei der 2.6.irgendwas des Linux-Kernels war ... sollte es damals schon ein (ausgewachsenes) procfs oder sysfs oder debugfs gegeben haben, kann man dort sicherlich nähere Informationen zu den MTD-Einträgen erhalten.

Die oben angezeigte Aufteilung würde jedenfalls nur dann wirklich einen Sinn ergeben, wenn die Start-Adresse für mtd5 max. bei 0x00d60000 läge - das Dateisystem also tatsächlich nur 0x00e1d500 - 0x00200000 = 0x00c1d500 Bytes (also ca. 12 MB, denn es wird ja auf "erase block size" ausgerichtet) belegen würde. Bei 48 Blöcken wären das dann nur noch 11 MB - und ich habe mir den Code im o.a. Parser nicht so genau angesehen, daher würde ich NICHT die Hand dafür ins Feuer legen, daß dieser (denn da wird auch noch einmal jffs2_size aus dem (Urlader-)Environment gelesen und was DAS nun wieder ist, kannst Du hier auch oft genug schon nachlesen, wenn Du mit den Stichworten TFFS und Urlader-Environment auf die Suche gehst) auch korrekt damit umgeht, wenn da (manuell) irgendein Wert eingetragen wird, der dann DOCH bereits belegte Blöcke (entweder VOR der JFFS2-Partition, wo dann das SquashFS-Image liegt oder NACH der JFFS2-Partition, wo die beiden TFFS-Partitionen liegen) umfassen würde ... und manche "Löschungen" im Flash-Speicher kriegt ein bereits laufendes System auch nicht unbedingt automatisch mit.

Ich würde mir jedenfalls (solange ich die Grenzen nicht WIRKLICH geprüft habe) ein echo "mtd5 erase all" > /proc/mtd verkneifen ... jedenfalls solange ich die Funktionsweise und das Zusammenspiel zwischen dem Kernel-Parser und der Initialisierung in /etc/init.d/S15-filesys nicht auch WIRKLICH verstanden habe. Aber ich bin eben auch ein "Schisser" ... und irgendwelche Versuche "auf gut Glück" sind mir einigermaßen zuwider, wenn deren Ergebnisse permanente Auswirkungen auf ein Gerät haben können.

 

[marquito]

Auf die Idee mit echo "mtd5 erase all" > /proc/mtd bin ich gekommen, als ich das S15-filesys anschaute. Ich trage mal zusammen, was ich herausbekommen habe:

Insgesamt: 16 MB NOR Flash = 16.777.216

[email protected]:/var/mod/root# cat /proc/mtd
dev: size erasesize name
mtd0: 00e1d500 00020000 "rootfs" - size: 14.800.128
mtd1: 00142b00 00020000 "kernel" - size: 1.321.728
mtd2: 00020000 00020000 "urlader" - size: 131.072
mtd3: 00040000 00020000 "tffs (1)" - size: 262.144
mtd4: 00040000 00020000 "tffs (2)" - size: 262.144
mtd5: 00300000 00020000 "jffs2"

Ohne mtd5 sind das genau 16.777216 Byte in der Summe, selbst die Standardmässigen 1 MB (von der Original FW angelegt) hätten darin keinen freien Platz mehr. Ich stimme zu, mtd5 macht so keinen Sinn und kann nur durch überlappen entstehen.

Vom Freetz Build weiss ich, dass mein Image 11,9 MB gross ist. Also 16 MB - 11,9 MB = 4,1 MB, d.h. es müsste genügend Platz für Bootloader + 2xTFFS + 3 MB JFFS2 sein.
Freetz muss beim image bauen wissen, dass von den 16 MB bereits ein Teil für urloader und 2xTFFS belegt sind, also 16.777.216 - 2 * 262.144 - 131.072 = 16.121.856 ist die max Grösse des Images. So ist es denn auch im Image steht unter /var/install: kernel_size=16121856 (Beim Image Bauen weiss Freetz noch nichts davon, dass ich 3 MB jffs2 haben möchte.)

Beim Flashen des Freetz Images wird folgendes ausgegeben:

flash_startadress 268435456
kernel_update_start 268566528
bootloader_size 0x00020000
jffs2_size 0x00300000
Kernel_without_jffs2_size 12976128
kernel_image_size 11893512
kernel_mtd_size 16121856
Kernel_Start_Add = 268566528
Kernel_End_Addr = 268566528 + 11893512
Kernel_without_jffs2_End_Addr = 268566528 + 12976128
install: -----------------------------------------------------
install: kernel_size=16121856
install: kernel_update_start=268566528
install: kernel_update_len=16121856
install: 2.6.32 setting files to install...
install: /var/tmp/kernel.image to start(268566528) size(16121856)
install: check for old settings ...

Und da finden wir wieder: kernel.image to start(268566528) size(16121856).
kernel_image_size 11893512 entspricht der Info aus dem Freetz build (11,9 MB). Danach kommt etwas ungenutzter Speicher bis
Kernel_without_jffs2_size 12976128 und dann nehmen wir die 3 MB jffs hinzu und kommen auf
kernel_mtd_size 16121856 - Differenz: 16121856 - 12976128 = 3 MB jffs

So, ich würde sagen alles sieht gut bzw besser save aus. wie läuft aber nun der Freetz-Flash Vorgang ab? Geflasht wird wohl kernel.image aber wie teilt sich der Content dann auf mtd0 und mtd1 bzw mtd5 auf?

 

[PeterPawn]

aber wie teilt sich der Content dann auf mtd0 und mtd1 bzw mtd5 auf?

Gar nicht bzw. nicht zum Zeitpunkt der Installation.

Den Parser im Kernel hast Du verstanden? Selbst wenn man von C keine Ahnung hat (ich habe meinerseits ja keine Ahnung, wie das bei Dir aussieht), sollten einem die Kommentare dort eine Idee verschaffen können, wie das beim Start des Kernels (dynamisch) in die MTD-Partitionen "zerlegt" wird.

 

[marquito]

Als Nachtrag, das /var/install Script im Freetz Image berechnet die max. mögliche JFFS2 Partition, vergleicht mit der angelegten aus der Urloader jffs2_size Variable UND gibt eine overlap Warnung aus und löscht diese, wenn die JFFS2 Partition nicht in den Speicher passt. Ob nach dem Reboot automatisch eine kleinere angelegt wird, weiss ich nicht. (Aber ich vermute es, da ich auf einer anderen Fritzbox mit nur 8 MB Gesamtspeicher knapp mit meinem Image war und zu meiner Überraschung ein 600 KB JFFS2 vorfand, was nicht die Werksconfig war.)
Ja, ich kenne mich mit C ganz gut aus und schau mir jetzt den Kernel Parser an, vielen Dank.

 

[PeterPawn]

das /var/install Script im Freetz Image

Weil Du das (nach meinem Empfinden) so betonst (wie ich es oben durch "bold" getan habe) ... das Shell-Skript /var/install wird von Freetz gar nicht weiter angepaßt, soweit ich weiß (und ich finde in fwmod auch nichts, wo diese Datei geändert würde) - das ist also alles schon "AVM-Code".

Lediglich die max. mögliche Größe des Images wird aus dieser Datei ausgelesen (https://github.com/Freetz/freetz/blob/75984884e4353db3b45b04cd37707c6e929ca0ec/fwmod#L1613 - das Image ist ja eine Kombination aus Kernel und Dateisystem) und für die Prüfung, ob der Platz ausreicht, verwendet.

Darauf basiert dann auch die Berechnung (es ist eher eine Schätzung), wieviel Platz für TAM noch bleiben würde: https://github.com/Freetz/freetz/blob/75984884e4353db3b45b04cd37707c6e929ca0ec/fwmod#L1694

 

[marquito]

Alles gut, ich hatte nur zum ggf. Nachvollziehen erwähnt, was ich analysiert habe - mehr nicht. Zurück zur Kernel Analyse:
Wie oben beschrieben ein Gesamtimage zum Flashen von 16121856 Byte. Darin muss nun irgendwie mtd0, mtd1 und mtd5 liegen.
cat /proc/mtd
dev: size erasesize name
mtd0: 00e1d500 00020000 "rootfs"
mtd1: 00142b00 00020000 "kernel"
mtd5: 00300000 00020000 "jffs2"

Kleine Bestätigung dazu, das urloader Env teilt uns mit (cat /proc/sys/urlader/environment):
mtd0 0x90000000,0x90000000
mtd1 0x90020000,0x90F80000 ---> entspricht 16121856 Byte
mtd2 0x90000000,0x90020000 ---> Bootloader
mtd3 0x90F80000,0x90FC0000 ---> TFFS
mtd4 0x90FC0000,0x91000000 ---> TFFS
(die Urloader mdt Bezeichnung ist nicht gleich mit der Kernel mtd Zuordnung)

Wir wissen, dass alles von der Größe passt, aber ob der Kernel es auch so macht, wollen wir bestätigt wissen. Also schauen wir uns ./source/kernel/ref-ur8-7270_05.51/linux-2.6.32/arch/mips/ur8 an.

|-----Kernel-------|-------SquashFS--|------- JFFS2-----|
+---------------------+-----------------------+--------------------+
|<-------mtd1--->|<---------------mtd0------------------>|

> Zeile 247: Wenn noch kein MTD5 mit JFFS2 existiert wird dieses innerhalb von MTD0 angelegt
Wir hatten beim Flashen die gesamte size=16121856 mit dem kernel.image beschrieben und innerhalb von MTD0 ist auch unsere Erwartungshaltung.

/* Für 7270v3 mit vergeigter Produktion (ohne JFFS_SIZE im Urlader-Env.) die Größe
* auf 50 begrenzen und nach hinten schieben, damit nicht bei jedem FW Update das
* JFFS überschrieben wird */
if (jffs2_size > JFFS2_MAX_SIZE) {
jffs2_start = jffs2_earliest_start + (jffs2_size - JFFS2_MAX_SIZE) * 0x10000;
jffs2_size = JFFS2_MAX_SIZE;
} else {
jffs2_start = jffs2_earliest_start;
}
}
ur8_partitions[5].offset = jffs2_start;
ur8_partitions[5].size = jffs2_size * 0x10000;
ur8_partitions[5].name = "jffs2";

Das irritiert dann doch. Laut Beschreibung soll die Grösse auf 50 beschränkt werden, aber #define JFFS2_MAX_SIZE 16 am Anfang spricht für 16 Begrenzung.

Weiter oben schreibt OliStudent: Sieht aus als würde der Bootloader das jffs2 selbst anlegen, wenn es nicht existiert. Damit findet der Kernel ein vorhandenes jffs2 und ändert die Größe nicht...

Wenn das stimmt, dann würde ich es verstehen. Was auch richtig ist, dass bei einen Freetz Update mit Haken bei JFFS2 löschen, die Partition UND die Variable auf 16 zurückgesetzt werden. Dies würde auch den Code bestätigen.

 

[marquito]

Weiterer Test, ich lag mit meinen Vermutungen/ Irritiationen richtig:

Habe in u8_mtd.c geändert
#define JFFS2_MAX_SIZE 50

Freetz FW geflasht mit Haken bei jffs2 löschen und JFFS2 ist 50 Blocks gross. Der Kernel berechnet die maximale JFFS2 size:
jffs2_size = ((*p_mtd_pat)[0].offset + (*p_mtd_pat)[0].size - jffs2_earliest_start) >> 16;

Bei mir grössser als 50 und begrenzt damit korrekt auf die 50.
Die jffs2_size=48 (aus dem urloader Environment) wird nicht genommen. Die Urloader Variable wird überschrieben - wahrscheinlich mit dem S15-filesys Script.

 

[PeterPawn]

die Urloader mdt Bezeichnung ist nicht gleich mit der Kernel mtd Zuordnung

Hmm ... ich sehe da keine (großen) Unterschiede, außer daß MTD0 in der Bootloader-Definition erst einmal eine Größe von 0 Bytes hat (die Angaben im Urlader-Environment sind ja jeweils Start- und Ende-Adresse) und daß MTD5 (für die JFFS2-Partition) NICHT existiert (was ja auch Sinn macht, denn die Art und Weise, wie diese Angaben zu den Partitionen im Bootloader gespeichert sind, läßt keine Veränderungen zu - außer durch ein Update des Konfigurationsbereichs im Bootloader, was aber mit einem hohen Risiko fürs "Bricken" verbunden ist, denn der liegt (bei UR8) am Offset 0x580 und damit INNERHALB des ersten Erase-Blocks), ist schon fast logisch - das ist praktisch ein "virtuelles MTD", wobei ALLE internen MTD-Strukturen natürlich erst bei der Kernel-Initialisierung angelegt werden. Alle anderen Angaben für MTD1 bis MTD4 sind aber 1:1 zwischen FRITZ!OS und EVA identisch - da gibt es Modelle, wo die Unterschiede noch VIEL größer sind und da stimmt dann die Nummerierung TATSÄCHLICH nicht überein.

---

Was auch richtig ist, dass bei einen Freetz Update mit Haken bei JFFS2 löschen, die Partition UND die Variable auf 16 zurückgesetzt werden.

Für mich (wenn ich Deine Aussagen richtig verstehe) ein typischer Fall von "confirmation bias": https://github.com/Freetz/freetz/bl...es/root/usr/lib/mww/do_update_handler.sh#L171 - das mag zwar "am Ende der Kette" dann so aussehen, aber bei der Installation aus Freetz heraus wird lediglich "die volle Größe" der Kernel-/Dateisystem-Partition (MTD1) für das Flashen verwendet (was ja aus je einem "erase"- und einem "write"-Zyklus besteht und wenn für einen Block keine Daten vorliegen, bleibt der eben gelöscht), indem kernel_update_len auf diesen Wert gesetzt wird und zusätzlich wird dabei die Variable jffs2_size aus dem Urlader-Environment gelöscht (ein Schreibvorgang OHNE Wert löscht die betreffende ID im TFFS). Das alles geschieht VOR dem Aufruf von /var/install (nicht zu verwechseln mit "bereits beim Image-Build", da wird die /var/install nicht angefaßt) und der gesamte Rest wird wieder vom AVM-Code erledigt.

---

Der Kernel berechnet die maximale JFFS2 size

Viel wichtiger wäre (auch für eine "Zusammenfassung" der Erkenntnisse) ja die Frage gewesen, woher wohl jffs2_earliest_start stammt und siehe da, das wird dem SquashFS-Superblock (denn da steht die Größe des SquashFS-Images drin) entnommen (und danach dann "aligned", wenn nötig) und das ganze Lesen von jffs2_size aus dem Environment ist hier nur Show, denn p wird zwar in Zeile 264 zugewiesen (wenn der Wert existiert, ansonsten gibt prom_getenv() auch mal NULL zurück) und danach aber (innerhalb des Scope) gar nicht mehr verwendet:

264                     p = prom_getenv((char*)"jffs2_size");
265                     /*--- printk("jffs2_size not set\n"); ---*/
266                     mtd->read(mtd, (loff_t)pos, sizeof(struct squashfs_super_block), &readlen, (u_char*)&squashfs_sb);
267                     jffs2_earliest_start = (u_int32_t)pos + (u_int32_t)squashfs_sb.bytes_used;
268                     /*--- printk("squashfs pos: %x\n", (u_int32_t)pos); ---*/
269                     /*--- printk("squashfs size: %x\n", (u_int32_t)squashfs_sb.bytes_used); ---*/
270                     /*--- printk("jffs2_start (squashfs pos + len) = %x\n", (u_int32_t)jffs2_earliest_start); ---*/
271                     if (jffs2_earliest_start & (mtd->erasesize-1)) {
272                         /*--- printk("align jffs: start: %x\n", jffs2_earliest_start); ---*/
273                         jffs2_earliest_start = (jffs2_earliest_start & ~(mtd->erasesize-1)) + mtd->erasesize;
274                     }
275                     /*--- printk("jffs2_earliest_start (aligned) = %x\n", jffs2_earliest_start); ---*/
276                     jffs2_size = ((*p_mtd_pat)[0].offset + (*p_mtd_pat)[0].size - jffs2_earliest_start) >> 16;
277                     /* jffs2_size in 64k Blöcken. Muss ggf. um 1 veringert werden für 128k Block Flash */
278                     /*--- printk("jffs2_size = %x\n", jffs2_size); ---*/
279                     jffs2_size = jffs2_size & ~((mtd->erasesize / 0x10000)-1);
280                     /*--- printk("jffs2_size = %x\n", jffs2_size); ---*/
281                     if (jffs2_size < (JFFS2_MIN_SIZE * (mtd->erasesize/0x10000))) {
282                         printk(KERN_WARNING "[ur8_squashfs_parser_function]: not enough space for JFFS2!\n");
283                     } else {

Damit ist jffs2_size (in diesem Code-Abschnitt) also am Ende IMMER irgendein Wert zwischen JFFS2_MIN_SIZE und JFFS2_MAX_SIZE und wird durch den Parser auch nicht neu gesetzt im Urlader-Environment, sondern erst durch die Abarbeitung der S15-filesys (s. #47) neu geschrieben ... allerdings immer unter der Voraussetzung, daß noch mindestens JFFS2_MIN_SIZE Blöcke verfügbar sind, ansonsten entfällt das MTD für jffs2 einfach bzw. behält seinen (ursprünglichen) Namen reserved, woraufhin es auch der Code in der S15-filesys nicht finden kann und daher dort gar nichts mountet.

Konnte das aber initialisiert werden, findet dann auch der Parser beim nächsten Start zuerst die JFFS2-Partition (siehe Kommentar in Zeile 76: * Zuerst wird das JFFS2 gesucht, dann das Squash-FS! - wobei der JFFS2-Parser ohnehin größere Schritte macht (nämlich in der Größe eines "erase blocks") und nicht die kleinen (256 Bytes), wie der SquashFS-Parser auf der Suche nach dem SquashFS-Magic) und damit wird das ganze Geraffel mit der neuen Berechnung der Größe auch nicht erneut ausgeführt und der (alte) Inhalt der JFFS2-formatierten Flash-Blöcke bleibt erhalten.

Wenn Du das tatsächlich oben auch so beschrieben haben solltest (bzw. es zumindest so gemeint war), dann habe ich das wohl nicht richtig verstanden.

 

[marquito]

Mmh, ich glaube, wir haben verschiedene Blickwinkel, aber im Großen und Ganzen meinen wir das gleiche. Ich fasse mich gerne kurz und vielleicht dann nicht so präzise. Ich kenne Deinen Background nicht, aber ein Fritzbox/ Freetz Urgestein bin ich nicht (also begrenztes Wissen), eher ein embedded Urgestein Richtung ARM/ Smartphone ua - eher ein Praktiker, der eine Lösung für ein Problem sucht.
> die Urloader mdt Bezeichnung ist nicht gleich mit der Kernel mtd Zuordnung
war nur ein Hinweis, dass die EVA und Fritz!OS mtd Definitionen nicht immer gleich sind und entsprechend gemappt werden müssen. Bei manchen Boxen mehr, bei manchen weniger. Also gleiche Aussage.
> Was auch richtig ist, dass bei einen Freetz Update mit Haken bei JFFS2 löschen, die Partition UND die Variable auf 16 zurückgesetzt werden.
Was meinst mit Confirmation Bias? Genau, "am Ende sieht es so aus", mehr wollte ich auch nicht sagen. Das do_update_handler.sh#L171 script kannte ich nicht (Danke für die Info). "jffs2_size aus dem Urlader-Environment gelöscht" wusste ich in diesem Moment nicht, aber einen Thread #55 später schon, also gleiches Verständnis.
> Der Kernel berechnet die maximale JFFS2 size.
Genau, "jffs2_size aus dem Environment ist hier nur Show" - absolut, ich meine mit "berechnen" exakt das gleiche wie Du - steht in dem Thread #55 - auch mit dem S15-filesys.
Also, nun haben wir beide das Problem auf verschiedene Art beschrieben, hoffen wir, dass auch andere damit was anfangen können. Auf jeden Fall hast du mir mit Deinen Hinweisen weiter geholfen, wofür ich mich bedanke.

 

[marquito]

Ich versuche das gleiche für die FB 7360v2 mit 32 MB, also /data zu vergrössern - etwa 12 MB sind frei.
Kernel: 7490_06.83-release_kernel
Im install script steht explizit:
echo install: Info: do not resize jffs2 on default-size 1M or 2M - even if there is unused space.

Was ist der Grund dafür? Warum sollte man jffs2 nicht vergössern bzw was spricht dagegen?