OT Linux Frage: wie Flash Part schreiben / Kernel updaten?

[starbright]

Eine Frage an die echten Kenner hier:
Ich hab ein Linux System mit div Partitionen, u.a. eine für uboot, kernel und eine fürs system.
Wie kann ich denn aus dem laufenden (Linux)System das flash wo der Kernel steht neu beschreiben?
Bisher hab ich das aus dem u-boot gemacht, das hat entsprechende Befehle, aber wie macht man das aus einem laufenden System?
Die Partition mit dem Kernel ist ja roh, kein Filesystem.
Das System wird normalerweise gestartet in dem mit nand read das Flash ins Ram kopiert wird und dann mit bootm gestartet.

Hoffe, jemand weiß eine Antwort.

[seife]

"fcp" ist die IMHO die beste und sicherste Lösung dafür.
Ist jetzt auch in der busybox mit drin

[starbright]

Guter Tip, danke!
Ist in der mir vorliegenden busybox unter dem Namen flashcp drin

[seife]

ja, anderer Name, selbe funktion. Ich wollte mich mit Denys nicht auch noch wegen dem Namen rumstreiten

[starbright]

Wollte mal Kernel neu flashen, bekomme aber Meldung:

Code: Alles auswählen

flashcp -v uImage /dev/mtd3
Erasing blocks: 12/12 (100%)
Writing data: 1416k/1416k (100%nand_write: Attempt to write not page aligned data
)
While writing data to 0x00160800-0x00162150 on /dev/mtd3: Invalid argument

Nach ein bisschen Suche liegt der Verdacht nah, dass das zu flashende File ein Vielfaches von 0x20000 bytes sein sollte. Gibts nen einfachen Trick auf der Kommandozeile ein File mit 0xff auf eine Größe zu erweitern?

Bis jetzt hab ich noch keine Weg gefunden, das file (möglichst mit ff zu erweitern).
Hatte erst auf ein dd Option gehofft aber nicht gefunden. Oder ein File mit ffs erzeugen, mit cat anhängen und dann mit head -c Kürzen ? Aber wie ein File mit laufter ff erzeugen? Es gibt /dev/zero aber kein /dev/ff?
Wahrscheinlich gibts ne ganz einfach Lösung, die ich nicht kenne/sehe ...

[seife]

kannst du mal versuchen, ob sich das flashcp von mtd-utils anders verhält? Das würde auf einen bug in busybox-flashcp hindeuten (ein bug ist es auf jeden Fall, aber die Frage ist, ob er nur in der busybox-conversion entstanden ist).

Es wäre trivial, flashcp so zu erweitern, dass es auf die erasesize padded (mit 0x00 oder 0xff).

1234 0xff erzeugen:

Code: Alles auswählen

for i in `seq 1 1234`; do
    printf "\777"
done

[starbright]

Äm, ich bastel hier grad an ner ganz anderen Kiste: Also das nicht gepadded wird bezieht sich mal nur auf die busybox hier - das kann in der dbox schon wieder ganz anders sein.
Ich hab auch nen ganz andern Proc (ARM), da müßt ich das alles erst crosscomp (horror).
Immerhin hats mit den ffs erzeugen, dann cat und dann head und flashen geklappt, wenns auch tierisch umständlich ist. Nem eingefleischten Linuxer würden sich wahrscheinlich alle Nackenhaare streuen ...
Nochmal vielen Dank für die goldenen tips, steh manchmal wie ochs vorm berg!

[seife]

Ich gehe davon aus, dass es vom flash-treiber abhängt, ob er padding braucht oder das intern selber macht.

Bauen war ganz einfach:

Code: Alles auswählen

/opt/cross/bin/arm-linux-gnueabi-gcc -g0 -Os -W -Wall -static -o /tmp/flashcp flashcp.c

Raus kam dabei:
flashcp-arm-static

Wäre interessant, wenn du das mal testen könntest.

[starbright]

Auch dein compilat padded nicht und bringt "Attempt to write not page aligned data".
Aber lass mal gut sein, ich muß mit der busybox hier auskommen. Da muß ich wohl eher das padden scripten ...

Hab das fw_printenv und fw_setenv hinbekommen - jetzt kann ich bootparams auch aus linux ändern. Genial.
Wenn mir jetzt noch der Kram mit dem OTP gelingen würde ...

Code: Alles auswählen

flash_otp_info -f /dev/mtd0
OTPSELECT: Inappropriate ioctl for device

[Striper]

Auch dein compilat padded nicht und bringt "Attempt to write not page aligned data".

Vielleicht hilft dieser Workaround weiter:

I was actually trying something very similar with the NAND on the 9260
and got a very similar result. When I actually poked around the mounted
filesystem, I found that it was incomplete. I haven't tracked down why,
but I did find an alternate set of commands that created a useable root
filesystem that I was able to boot into. I use the -j to flash_eraseall
to create an empty jffs2 filesystem. Then I mount the (empty)
filesystem. Instead of creating a jffs2 image of the root filesystem, I
create a tar. Then I untar it into the mounted flash and unmount the
filesystem. Something like this:

flash_eraseall -j /dev/mtd0
mount -t jffs2 /dev/mtdblock0 /tmp/mnt
tar xzf root-fs.tgz -C /tmp/mnt
umount /tmp/mnt

I've used the approach that you described on other flash devices (on
other boards), and I'm not sure why it didn't work on this one.
However, hopefully this alternate procedure will let you continue your
work.

https://linuxlink.timesys.com/forum/1299#comment-2453

[seife]

oder die erste Option benutzen, die beim mkfs.jffs2 helptext ausgegeben wird:

Code: Alles auswählen

mkfs.jffs2: Usage: mkfs.jffs2 [OPTIONS]
Make a JFFS2 file system image from an existing directory tree

Options:
  -p, --pad[=SIZE]        Pad output to SIZE bytes with 0xFF. If SIZE is
                          not specified, the output is padded to the end of
                          the final erase block

[Liontamer]

Ist zwar etwas spät die Antwort, aber ein File kann man wie folgt mit 0xff padden:

Code: Alles auswählen

dd if=file.unaligned of=file.aligned bs=$BLOCKSIZE count=$COUNT conv=sync

[starbright]

spät - aber keinesfalls zu spät
Danke an alle für die Tips!

@ striper und seife
Das geht für das fs, aber nicht für den Kernel oder uboot.

@Liontamer

bei mir padded dd aber mit 0x00 ?!
Damit kann ich dann zwar auch flashen, aber schöner wärs, die nichtbenutzen Bytes blieben in ihrer Default-Lage bei 0xff