Hi !

Ich benutze auf meiner 7020hd den Kernel den Dr. Chaos mit dem zusätzlichen mtd4 device ausgestattet hat um auf auf die restlichen 750MB Flash zugreifen zu können.

cat /proc/mtd
dev: size erasesize name
mtd0: 3ff00000 00040000 "complete"
mtd1: 00100000 00040000 "loader"
mtd2: 00700000 00040000 "boot partition"
mtd3: 0f800000 00040000 "root partition"
mtd4: 2ee00000 00040000 "data partition"

Wenn man die schön formatiert (egal ob mit flash_erase oder ubiformat /dev/mtd4) und Ihn dann versucht zu attachen passiert das:

ubiattach /dev/ubi_ctrl -m 4
ubiattach: error!: cannot attach mtd4
error 22 (Invalid argument)

Im dmesg steht das:

[ 3194.859000] UBI: attaching mtd4 to ubi0
[ 3194.859000] UBI error: io_init: bad write buffer size 0 for 4096 min. I/O unit

Es sieht also so aus wie wenn derzeit der mtd Treiber die write buffer size mit 0 befüllt, was ubifs dann nicht akzeptieren mag.

Das ist scheinbar das selbe wie hier beschrieben:

http://comments.gmane.org/gmane.linux.drivers.mtd/39220

http://en.usenet.digipedia.org/thread/18514/2450/

Bevor ich mich jetzt unnötig quäle - ist das Absicht das die writebuffer size nicht befüllt wird damit man ubifs derzeit nicht benutzen kann, oder wäre es bitte möglich das Ihr das im OE fixed das als write buffer size was sinnvolles zurück kommt ?

PS: Das dürfte auch der Grund sein warum ich nur mit dem nandsim Module erfolgreich war ubifs zu mounten und mit mtdblock nicht.

LG
gutemine

Habe nachgesehen, im block2mtd modul (das ja auch dankenswerterweise jetzt fix im kernel ist) fehlt der Patch auch:

http://article.gmane.org/gmane…ch=writebufsize+block2mtd

Bitte das wäre besonders nett wenn Ihr das auch einchecken könntet, weil das würde mir ziemlich sicher das nandsim ersparen, um ubifs images auspacken zu können - siehe hier.

nandsim module auf den Softwarefeed ?

LG
gutemine

Ich wurde von Dr. Chaos drauf aufmerksam gemacht das der write buffer size Patch fürs block2mtd sehr wohl schon drinnen ist, also habe ich es nochmals probiert und ja, es geht:

So macht man ein 30MB großes UBI volume auf in ein ubifs file auf der Harddisk:

dd if=/dev/zero of=myubifs bs=2048 count=16000
losetup /dev/loop5 myubifs
echo "/dev/loop5,0x20000" > /sys/module/block2mtd/parameters/block2mtd
ubiformat /dev/mtd4 -e 0 -O 2048
ubiattach /dev/ubi_ctrl -m 4 -O 2048
ubimkvol /dev/ubi0 -s 30MiB -N test
mkdir /media/ubifs
mount -t ubifs ubi0_0 /media/ubifs

Wenn man es wieder loswerden will:

umount /media/ubifs
ubidetach -m 4

ABER das Problem im mtd Treiber für den Flash ist dadurch immer noch nicht gelöst

Irgendwas ist aber auch beim block2mtd komisch, weil sobald ich bei den geposteten Befehlen die Size auf etwas sinnvolles wie 128MB drehe dann hängt sichdie Box beim ubiformat auf auf wie wenn Ihr das ram ausgehen wurde obwohl es eigentlich das cache File formatieren sollte.

Weil sonst könnte ich testweise die boxen mal vom sata oder usb mit ubifs booten lassen.

Und das lustige ist das der mtdram Treiber das Problem nicht hat, ich kann damit auf der 7020HD die reichlich Memory hat problemlos ein 128MB großes ubifs machen:

modprobe mtdram total_size=131072
ubiformat /dev/mtd4 -e 0 -O 2048 -y -s 1
ubiattach /dev/ubi_ctrl -m 4 -O 2048
ubimkvol /dev/ubi0 -m -N test
mkdir /media/ubifs
mount -t ubifs ubi0_0 /media/ubifs

Und es auch wieder loswerden:

umount /media/ubifs
ubidetach -m 4
rmmod mtdram

Insofern wäre es schon sehr nett wenn der mtd Treiber für den Flash gefixed würde, aber mehr als bitte bitte sagen können wir ja nicht.

LG
gutemine

mit jffs2 ist es eher öde weil es solange dauert bis es gemountet ist. Beim ubifs wäre das kein Problem.

ABER ich warte extrem ungern und trinke lieber Kaffee ...

Na gut dann fixen wir es halt selber, muss ich wohl mein OE 2.0 wieder rauskrammen, mal sehen ob es noch funktioniert.

Das Problem ist halt dass der Treiber im kernel steckt womit man jedesmal neuen Kernel bauen muss, was recht zeitaufwendig ist wenn man nicht weis was man tut und mühsam herum probieren muss.

Ist noch alles da, die Frage ist jetzt im generischen drivers/mtd oder im brdcnand sbdirectory auf die Suche gehen ?

opendreambox/tmp/work/dm7020hd-oe-linux/linux-dreambox/linux-dreambox-3.2-r7.11-bsp1/linux-3.2/drivers/mtd/

Hier gibt es ein mtdconcat.c und ein mtdpart.c wo schon ein writebufsize drinnen vorkommt

oder

opendreambox/tmp/work/dm7020hd-oe-linux/linux-dreambox/linux-dreambox-3.2-r7.11-bsp1/linux-3.2/drivers/mtd/brcmnand

Hier gibt es nichts mit writebufsize im code, also dürfte es hier fehlen ... aber wo?

LG
gutemine

in der mtdconcat.c steht das so:

int max_writebufsize = 0;

Die maximale writebuffersize wird also mit 0 initalisiert.

Und dann kommt das:

for (i = 0; i < num_devs; i++)
if (max_writebufsize < subdev->writebufsize)
max_writebufsize = subdev->writebufsize;
concat->mtd.writebufsize = max_writebufsize;

Sprich es wird für alle devices durchsucht ob es eine größere writebufersize gibt und wenn ein device das meldet wird die genommen.

Nachdem der brdcmnan scheinbar nicht meldet bleibt es bei der 0 und damit ist ubifs eben unglücklich.

Ich mache da einfach mal ein int max_writebufsize =4096 rein und wir schauen was passiert ... oder wäre mal 128 besser, weil das ist das was ubifs als default verwendet ?

Im Prinzip steuert das ja in welchen blockgrößen vom ubifs geschrieben werden soll um möglichst wenig Schreibzugriffe zu haben, unsere Dreamboxen haben ja 512,2048 und 4096 als Blocksize im Angebot, bei der 7020hd sind es aber 4096.

Insofern müsste eigentlich jeder Flashchip das korrekte aus dem brdcomnand liefern, tut er aber scheinbar nicht - kann aber nicht sein, wenn die Mitbewerber auch mit dem broadcom nand Treiber auch ubifs in den Flash machen können, aber ich habe wenig Lust in den OE's der Mitbewerber zu suchen was vielleicht dort drinnen steht

Und außerdem mancht ubifs eh nur auf der 8k und der 7020hd Sinn, bei den alten boxen mit den 512 Chips ist der Flash sowieso zu klein für ubifs.

Oder ich bin böse und machen in die for schleife auch noch das rein:

subdev->writebufsize=4096;

Dann setze ich einfach für alle subdevs die size auch gleich mit, sollte ja egal sein, wenn sie sonst eh nicht verwendet und vom device nicht gesetzt aber in der struktur vorgesehe dann sollte man sie ja auch setzen können, auch wenn das sicher nicht so ist wie der Author sich das vorgestellt hat

Interessant ist auch noch wenn man sich die writesize für die Boxen ansieht:

dm8000:

/sys/devices/virtual/mtd# cat */writesize
2048
2048
2048
2048

Bei der dm7020hd steht da überall 4096 (außer wahrscheinlich bei der v2 mit den neuen Flashchips da müsste auch 2048 drinnen stehen)

OK, ich habe mich entschieden wenn schon Holzhammer dann lieber dort wo die Fehlermeldung auftritt.

wenn man im drivers/mtd/ubi directory nach writebufsize in den *.c ein grep macht sieht man das die Fehlermeldung im build.c passiert:

ubi->mtd->writebufsize=4096;
ubi->max_write_size = ubi->mtd->writebufsize;
/*
* Maximum write size has to be greater or equivalent to min. I/O
* size, and be multiple of min. I/O size.
*/
if (ubi->max_write_size < ubi->min_io_size
ubi->max_write_size % ubi->min_io_size
!is_power_of_2(ubi->max_write_size)) {
ubi_err("gutemine: bad write buffer size %d for %d min. I/O unit",
ubi->max_write_size, ubi->min_io_size);
return -EINVAL;
}

Da macht man einfach die 2 roten sachen dazu - erstere damit obwohl der mtd driver 0 gemeldet hat das ubifs 4096 verwendet und zweiteres damit man falls die Fehlermeldung trotzdem noch kommt man sieht das man schuld dran war

Dann löscht man das build.o, ubi.o built-in.o und ein directory höher auch noch das built-in.o und noch ein driectory höher das vmlinix.o und das vmlinux - nur um sicher zu gehen das es neu compiliert wird.

Nach den Änderungen compiliert man sich einen neuen Kernel indem man im build directory der 7020hd folgendes eingibt:

bitbake -f -c compile linux-dreambox

So kontrolliert man ob der codechange im kernel gelandet ist:

strings vmlinux | grep gutemine

Anschließend muss man nur mehr das vmlinux mit gzip in ein vmlinux.gz machen und auf /boot eines frisch geflashten aktuellen OE images machen und rebooten.

Leider habe ich den Patch von Dr. Chaos für das mtd4 device nicht bei mir im OE, also konnte ich nur /boot nehmen um zu testen:

umount /boot
ubiformat /dev/mtd2 -O 2048
ubiattach -m 2

KEINE attach fehler mehr mit dmesg Meldungen über die writebuf size 0 !!!

ubimkvol /dev/ubi0 -m -N boot
mount -t ubifs ubi0_0 /boot

Und dann sieht es so aus:
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock3 248.0M 52.0M 196.0M 21% /
devtmpfs 155.1M 0 155.1M 0% /dev
none 155.2M 868.0K 154.4M 1% /var/volatile
ubi0_0 1.8M 24.0K 1.6M 1% /boot

Nachher muss man halt neuflashen weil das Bios mit ubifs in /boot nichts anfangen kann.

Keine schöne Lösung, ich weis ... aber das war mir schon immer ziemlich egal wenn es dadurch funktioniert hat.

Aber jetzt brauchen wir nur mehr einen kernel für die 7020hd wo das /dev/mtd4 mit den 750MB Flash vorhanden ist und dann können wir endlich mit ubifs im Flash weiterspielen.

PS: Theoretisch kann man die Box auch mit LowFAT booten, /dev/mtd3 zu ubifs machen und da die root reinkopieren, den kernel root parameter in Bios bzw. in der autoexec_dm7020hd.bat umdrehen und auch ohne die 750MB mal mit ubifs booten.

Aber wenn schon so eine schöne Spielwiese im Flash der 7020HD ist will ich sie auch benutzen, bei der 8k wird uns dann eh nichts anderes überbleiben als mit /dev/mtd3 zu testen, den Kernel dafür habe ich jetzt mit 2048 hardcoded schon fertig gemacht.

PPS: Und nein, ich schreibe jetzt KEIN [gelöst] vor den Threadtitel.

LG
gutemine

Doch doch, mir wird schon geholfen, aber wie schon im Eingangspost steht bin ich nicht sicher ob das im Moment nicht absichtlich 'vergessen' wurde. Und selbst wenn keiner Zeit oder Lust hat zu helfen (ist ja Wochenende und damit eigentlich jeder entschuldigt) kommt ja erschreckend oft trotzdem was raus - im Gutem wie im Schlechten.

Außerdem ist das für mich auch nur ein Test wie gut andere Leute sind (und damit sind nicht die Entwickler bei DMM gemeint), wenn ich das kann (als bekennender Dil(l)etant) dann heisst das nichts Gutes.

Außerdem bediene ich ein anderes Publikum

Noch ein kleiner Beitrag zu diesem Monolog bevor ich ins Bett muss.

Der Patch für den Bug von hier ist in unserem mkfs.ubifs binary auch noch nicht drinnen:

http://lists.infradead.org/pip…/2012-October/044477.html

Musste mir erst ein aktuelles selber compilieren

Aber jetzt kann ich die root der dm7020hd als ubifs Sichern, fehlt nur mehr der passende Kernel

LG
gutemine

Vielen Dank, insbesondere für den fertigen Kernel!

Das Badblock Handling ist nützlich, weil /boot muss ja als jffs2 bleiben damit der SSL damit zurecht kommt den Kernel zu booten der sich dann sein ubifs mountet, also werden wir erstmal jffs2 und ubifs gleichzeitig haben müssen.

Das Marsu Plugin um ein Flashimage mit der root als ubifs zu sichern ist eh schon fast fertig, aber im Moment sind noch alle Parameter für die 7020HD hardcoded, ich muss erst einbauen das es sich mit mdinfo -a -u alles selber ausliest, weil dann kann es auch mit alten und neuen Flashchips der 7020hd umgehen und läuft wahrscheinlich auch auf den anderen boxen. Damit sollten die Leute das bis zum Wochenende auch schon ausprobiert haben ob man das so einchecken sollte.

Bezüglich dem freien Flash noch eine kleine Anregung - die Mitbewerber haben eine 2. redundante root Partition mit nochmals 256MB Memory, damit kann man eine schöne Recovery Partition machen und von der im Notfall booten oder root zurückkopieren (also so eine Art Snapshot Funktion wie im Windows - mit nandread und nandwrite dauer da ien backup nur wenige sekunden), und 512MB für den Rest würden auch reichen, aber mit mehreren UBI Volumes geht das natürlich auch so, aber falls man jffs2 behalten will wären nochmal 256MB in mtd4 und ein mtd5 für den Rest noch besser.

Und was auch überlegenswert wäre auch die LZO compression für usbifs und jffs2 im kernel zusätzlich zum zlib aufzudrehen, weil wenn ich in ubifs mit zlib sichere kommt fast der selbe Patzbedarf im Flash raus, womit die kleinen Boxen nicht gleich komplett rausfliegen beim Thema ubifs und auf der 7020HD ist lzo sicher die bessere Wahl weil das bisschen mehr Platzbedarf nicht wehtut und die box noch agiler wird (ich habe auch mal testweise mit none gesichert, aber dann sind die 256MB für die root plötzlich ziemlich wenig).

LG
gutemine

Wer schon vorher spielen will und wissen will wie man sich die Parameter holt, so sieht es bei der 7020hd aus:

mtdinfo /dev/mtd3 -u
mtd3
Name: root partition
Type: nand
Eraseblock size: 262144 bytes, 256.0 KiB
Amount of eraseblocks: 992 (260046848 bytes, 248.0 MiB)
Minimum input/output unit size: 4096 bytes
Sub-page size: 4096 bytes
OOB size: 128 bytes
Character device major/minor: 90:6
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 4096
Default UBI data offset: 8192
Default UBI LEB size: 253952 bytes, 248.0 KiB
Maximum UBI volumes count: 128