Seite 2 von 3
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 11:12
von BrechREiZ
BPanther hat geschrieben:...sowie hinzufügen einer fehlenden Datei ein erstes, bootfähiges Image hinbekommen. So wie es im GIT vorhanden ist, ist es jedenfalls nicht lauffähig...
Die dummy.h enthält ein array dass du als Binärdatei ausgeben musst. Einfach per fwrite() in eine mit binärattribut geöffnete Datei blasen.
Aber läuft ja auch so

Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 12:13
von BPanther
Es gab mehrere Probleme, warum das mit dem Script bei der AV7500 nicht funktioniert hat.
Die Datei dummy.squash.signed.padded fehlte und das Script hat /boot komplett leergeräumt, so daß die Firmware-Dateien weg waren, somit konnten die nicht mehr gefunden und geladen werden. Das bootlogo wurde in der rcS auf /var/etc gelegt, aber nur dort, die Datei bootlogo selbst war jedoch nicht in /var/etc vorhanden.
Nachdem ich mir die fehlende Datei gesucht hatte, habe ich einfach das verschieben der Firmware-Dateien (/boot blieb dann so wie es war) und die Änderung zwecks bootlogo in der rcS unterbunden - und nun funktioniert es, wenn auch nur mit dem "extended" Script. Mit dem "normalen" kam leider auch nichts lauffähiges bei raus.
Bin aber erstmal weg zur Spätschicht...
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 13:43
von Schischu
Das was Ihr hier erzählt simmt vorn und hinten nicht,
Ich baue alle meine Images als Flash images und es ist immer nur
cd /tdt/cvs/cdk/
./make.sh
./make yaud-engima2-nightly
cd /tdt/flash/ufs912
./ufs912.sh - Prepare E2 - Build Image with Kernel FW and Root
oder
cd /tdt/flash/at7500
./at7500_extended.sh - Prepare E2 - Build Image with Kernel FW and Root
Da muss man nix manuell machen, das geht "out of the box"
Und das /boot leer ist ist auch absolut richtig weil nach /boot die FW Partition gemounted wird.
Und das man eine dummy.signed.pad braucht halte ich für ein gerücht, das war vlt. vor 6 Monaten so.
Ach und die Aussage mit den Bootargs ist auch total Schwachfug
Der Kernel schaut ob die Org Bootargs gesetzt sind und wenn ja Ändert er sie selbständig so um das E2 durchbootet.
Ohne das man jemals die Bootargs anfassen musste.
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 14:43
von konfetti
Ich kann bestätigen das es für die AT7500 (diverse Male schon gemacht) und für die ufs912 (zweimal bisher gemacht) so einfach läuft wie Schischu es geschrieben hat.
Auf jedenfall mit Standardgit-Images (ufs912 ->neutrino; AT7500 ->e2 bei mir).
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 20:43
von BPanther
Tjo, dann bin ich wohl zu blöd dazu. Es ging nur so wie ich es beschrieben hatte bei der AV7500, /boot blieb beim Neustart leer, da wurde nichts gemountet. Naja, egal, hauptsache es geht nun.

Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 21:23
von vISIOn
Naja... ich würde den Mund mal net zu voll nehmen ... da ich das gestern selber mit dem gleichen Image probiert habe,kann ich nur bestätigen das einiges von Hand gemacht werden musste... also mal net so Aggro... sondern mal sachlich bitte...
Ich kann bestätigen das einiger Müll dabei rum kam. Und die Images "nicht gelaufen sind"
Ich mache das alles auch net erst seit gestern ... und es waren einige Anpassungen nötig um den standart in dem Skript anzupassen...
Gruß
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:20
von Schischu
Na dann mal auf, beschreib doch mal was du anpassen musstest.
Weil solche Ausagen wie:
"Ich kann bestätigen das einiger Müll dabei rum kam. Und die Images "nicht gelaufen sind""
Und was hier alles auf der letzten Seite stand finde ich ohne Fehlerbeschreibung absolut frech und unverschämt, das hat nichts mit produktives Arbeiten zu tun sondern ist einfach nur dumes runterreden der Arbeit anderer.
Den wenn es nicht geht, warum ist nimand auf mich zugekommen und hat mir das gesagt?
Oder Verbesserungsvorschläge genannt ?
Aber nein es wird lieber Hinter meiner Hand darüber gelästert.
Also überlege dir bitte wer hier AGGRO ist.
GEHTS NOCH HALLLLLLO.
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:34
von BPanther
Bitte keinen Streit. Das das Script bei mir noch nie funktionierte habe ich im AAF-Forum mehrmals erwähnt und auch im Dev-Chat, da schon mal auch dort die Frage kam, warum kein IRD. Und da es nie funktionierte habe ich es auch nicht benutzt. Zugegeben, ich habe mich erst gestern mal mit befasst, weil ich auch etwas mehr Zeit hatte und Vision sich zum testen bereit erklärt hat.
Vorgegangen bin ich wie folgt:
- Datei dummy.squash.signed.padded im Netz besorgt, da das Script diese als fehlend deklariert hat.
- Datei dev_at7500.tar.gz neu erstellt, da Devices fehlten (Fernbedienung funktionierte nicht).
Dann habe ich folgende Sachen geändert:
Code: Alles auswählen
diff --git a/tdt/flash/at7500/scripts/prepare_root.sh b/tdt/flash/at7500/scripts/prepare_root.sh
index cc4b219..fe522e7 100755
--- a/tdt/flash/at7500/scripts/prepare_root.sh
+++ b/tdt/flash/at7500/scripts/prepare_root.sh
@@ -11,13 +11,13 @@ cp -a $RELEASEDIR/* $TMPROOTDIR
mv $TMPROOTDIR/boot/uImage $TMPKERNELDIR/uImage
-mv $TMPROOTDIR/boot/audio.elf $TMPFWDIR/audio.elf
-mv $TMPROOTDIR/boot/video.elf $TMPFWDIR/video.elf
+cp $TMPROOTDIR/boot/audio.elf $TMPFWDIR/audio.elf
+cp $TMPROOTDIR/boot/video.elf $TMPFWDIR/video.elf
mv $TMPROOTDIR/boot/bootlogo.mvi $TMPROOTDIR/etc/bootlogo.mvi
-sed -i "s/\/boot\/bootlogo.mvi/\/etc\/bootlogo.mvi/g" $TMPROOTDIR/etc/init.d/rcS
+#sed -i "s/\/boot\/bootlogo.mvi/\/etc\/bootlogo.mvi/g" $TMPROOTDIR/etc/init.d/rcS
-rm -f $TMPROOTDIR/boot/*
+#rm -f $TMPROOTDIR/boot/*
echo "/dev/mtdblock2 /boot jffs2 defaults 0 0" >> $TMPROOTDIR/etc/fstab
#echo "/dev/mtdblock5 /root jffs2 defaults 0 0" >> $TMPROOTDIR/etc/fstab
diff --git a/tdt/flash/at7500/scripts_extended/prepare_root.sh b/tdt/flash/at7500/scripts_extended/prepare_root.sh
index 31c6c07..f707dce 100755
--- a/tdt/flash/at7500/scripts_extended/prepare_root.sh
+++ b/tdt/flash/at7500/scripts_extended/prepare_root.sh
@@ -18,13 +18,13 @@ ln -s /var/usr/lib/enigma2 $TMPROOTDIR/usr/lib/
mv $TMPROOTDIR/boot/uImage $TMPKERNELDIR/uImage
-mv $TMPROOTDIR/boot/audio.elf $TMPFWDIR/audio.elf
-mv $TMPROOTDIR/boot/video.elf $TMPFWDIR/video.elf
+cp $TMPROOTDIR/boot/audio.elf $TMPFWDIR/audio.elf
+cp $TMPROOTDIR/boot/video.elf $TMPFWDIR/video.elf
mv $TMPROOTDIR/boot/bootlogo.mvi $TMPROOTDIR/etc/bootlogo.mvi
-sed -i "s/\/boot\/bootlogo.mvi/\/etc\/bootlogo.mvi/g" $TMPROOTDIR/etc/init.d/rcS
+#sed -i "s/\/boot\/bootlogo.mvi/\/etc\/bootlogo.mvi/g" $TMPROOTDIR/etc/init.d/rcS
-rm -f $TMPROOTDIR/boot/*
+#rm -f $TMPROOTDIR/boot/*
echo "/dev/mtdblock2 /boot jffs2 defaults 0 0" >> $TMPROOTDIR/etc/fstab
echo "/dev/mtdblock3 /var jffs2 defaults 0 0" >> $TMPROOTDIR/etc/fstab
/boot bleibt durch kopieren statt verschieben erhalten, löschen von /boot/* deaktiviert. Da das bootlogo nicht nach /var/etc kopiert wurde (Warum eigentlich dahin, wäre /var/boot wenn dann nicht besser?) habe ich auch die Änderung in der rcS deaktiviert. Sind nur Kleinigkeiten, aber damit lief es dann. Wie gesagt, ein mounten von /boot von "woanders her" fand nicht statt, weswegen /boot leer blieb und die FW-Dateien fehlten.
EDIT: Durch die Änderungen von mir im /boot wurde das Image auch die 2.5MB wieder größer, da vorher anscheinend wirklich die FW-Dateien nicht mit bei waren. Benutzt wurde Extended mit 2, 2 (Neutrino, Kernel+Root+FW).
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:47
von konfetti
vISIOn hat geschrieben:Naja... ich würde den Mund mal net zu voll nehmen ... da ich das gestern selber mit dem gleichen Image probiert habe,kann ich nur bestätigen das einiges von Hand gemacht werden musste... also mal net so Aggro... sondern mal sachlich bitte...
Ich kann bestätigen das einiger Müll dabei rum kam. Und die Images "nicht gelaufen sind"
Ich mache das alles auch net erst seit gestern ... und es waren einige Anpassungen nötig um den standart in dem Skript anzupassen...
Gruß
Verstehe ich nicht, dann muss ich irgendwas falsch gemacht haben. Denn ich hab mein ganz normales Images genommen (make.sh - make yaud-Blub). Diese hab ich vorab per NFS getestet und dann hab ich mir mit den Flash Skripten jeweils halt das flashbare Image erstellen lassen. Bei der AT7500 musste man es noch umbenenen und auf den Stick kopieren. That's it. Bei der ufs912 musste man es nur auf den Stick kopieren und wenn es das erste mal war musste man vorher noch das updateskript flashen.
Das hab ich jetzt ca 10 mal so gemacht und nie Probleme gehabt. Ich werde es nächstes WE nochmal mit nem stm24 Image für AT7500 probieren, dann kann ich ja mal testen ob sich was verschlechtert hat.
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:49
von BPanther
Ich kann jetzt nur von der 7500 sprechen, die 912 habe ich noch nicht probiert - die kommt erst noch wenn das USB komplett läuft. Und leider mußte ich das obige so machen damit es mit dem extended lief, das "normale" läuft weiterhin nicht, das ist um die 20k kleiner. Und bei dem Script kann man ja auch nichts falsch machen, ist ja schön einfach gehalten. Gebaut hatte ich Neutrino, stm23-0123, p191, noDebug.
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:54
von konfetti
BPanther hat geschrieben:Ich kann jetzt nur von der 7500 sprechen, die 912 habe ich noch nicht probiert - die kommt erst noch wenn das USB komplett läuft. Und leider mußte ich das obige so machen damit es mit dem extended lief, das "normale" läuft weiterhin nicht, das ist um die 20k kleiner. Und bei dem Script kann man ja auch nichts falsch machen, ist ja schön einfach gehalten. Gebaut hatte ich Neutrino, stm23-0123, p191, noDebug.
Wie gesagt ich werde vermutlich am WE (versuche vorher noch nen plugin einzubauen) ein stm24 at7500 flashen. Dann kann ich nochmal berichten...vielleicht ist mir ja auch irgendwas entfallen was ich gemacht habe.
Re: BP Neutrino für die UFS912
Verfasst: Di 19. Jul 2011, 23:56
von BPanther
Ich habe "ausnahmsweise"

auch mal am WE frei, kein Problem. Ich will mir eh mal das mit dem fakeroot bezüglich /dev mal anschauen, denn das mit den fertigen /dev im tar.gz halte ich persönlich nicht gerade für gut. Das läßt sich bestimmt auch anders lösen und automatisch generieren.
Re: BP Neutrino für die UFS912
Verfasst: Mi 20. Jul 2011, 00:20
von Schischu
Ja natürlich lässt sich die devs einfacher lösen, sogar viel viel einfacher.
mkjffs2 hat eine Option wo man dem eine Liste von DevFiles übergeben kann die es in der jffs2 Partition erzeugen soll.
Siehe
http://linux.die.net/man/1/mkfs.jffs2
-D, --devtable=FILE
Use the named FILE as a device table file, for including devices and changing permissions in the created image when the user does not have appropriate permissions to create them on the file system used as source.
Das mit dem Tar ging aber einfach schneller, weil einfach nur einpacken und beim anderen müsste man erstmal eine Liste erstellen.
Davon abgesehen kann ich den Fehler mit das die RC nicht geht nicht nachvollziehen.
Deinen oberen Patch zu Folge ist alles daraufhin rückzuführen das die FW Partition nicht gemountet wird.
Hast du evtl die rcS startk angepasst oder die mountall skripte und was es alles gibt modifiziert ?
Das mit dummy kann ich auch nicht nachvollziehen weil das dummy file vom fup tool erzeugt wird, siehe
http://dev.duckbox.info/cgi-bin/gitweb. ... =HEAD#l530
Re: BP Neutrino für die UFS912
Verfasst: Mi 20. Jul 2011, 00:44
von BPanther
Zum /dev: Nunja, so eine Liste gibts ja im Grunde schon (in cvs/cdk/root/sbin). Das benutzt das fakeroot soweit ich mitbekommen habe. Es fehlten in der tar.gz, mal aus dem Stehgreif heraus: rc, sci0, sci1. Dadurch das rc fehlte keine FB, und ohne die sciX keine Kartenleser. Das mit dem mkfs.jffs2 klingt auch recht interessant, man braucht so nur die Tabellen für die einzelnen Boxen aktuell halten.
Ein dokumentiertes Beispiel dafür habe ich auch gefunden, scheint nur am Anfang evtl. etwas aufwändiger zu sein.
Code: Alles auswählen
# This is a sample device table file for use with mkfs.jffs2.* You can
# do all sorts of interesting things with a device table file.* For
# example, if you want to adjust the permissions on a particular file
# you can just add an entry like:
# /sbin/foobar f 2755 0 0 - - - - -
# and (assuming the file /sbin/foobar exists) it will be made setuid
# root (regardless of what its permissions are on the host filesystem.
#
# Device table entries take the form of:
# <name>* <type> <mode> <uid> <gid> <major> <minor> <start> <inc> <count>
# where name is the file name,* type can be one of:
# f A regular file
# d Directory
# c Character special device file
# b Block special device file
# p Fifo (named pipe)
# uid is the user id for the target file, gid is the group id for the
# target file.* The rest of the entried apply only to device special
# file.
# When building a target filesystem, it is desirable to not have to
# become root and then run mknod a thousand times.* Using a device
# table you can create device nodes and directories "on the fly".
# Furthermore, you can use a single table entry to create a many device
# minors.* For example, if I wanted to create /dev/hda and /dev/hda[0-15]
# I could just use the following two table entries:
# /dev/hda b 640 0 0 3 0 0 0 -
# /dev/hda b 640 0 0 3 1 1 1 16
#
# Have fun
# -Erik Andersen <andersen@codepoet.org>
#
#<name>* <type> <mode> <uid> <gid> <major> <minor> <start> <inc> <count>
#/dev* d 755 0 0 - - - - -
/dev/mem c 640 0 0 1 1 0 0 -
/dev/kmem c 640 0 0 1 2 0 0 -
/dev/null c 640 0 0 1 3 0 0 -
/dev/zero c 640 0 0 1 5 0 0 -
/dev/random c 640 0 0 1 8 0 0 -
/dev/urandom c 640 0 0 1 9 0 0 -
/dev/tty c 640 0 0 5 0 0 0 -
/dev/tty c 640 0 0 4 0 0 1 6
/dev/console c 640 0 0 5 1 0 0 -
/dev/ram b 640 0 0 1 1 0 0 -
/dev/ram b 640 0 0 1 0 0 1 4
/dev/loop b 640 0 0 7 0 0 1 2
/dev/ttyS c 640 0 0 4 64 0 1 4
Zum Patch: Ich nutze meine eigene rcS, da die ja auf USB-Img und auf spezielle Zusätze bei mir ausgelegt ist. Ich mag z.B. auch nicht den Reboot der kompletten Box nur weil Neutrino/E2 mal eben abstürzen, sowas muß meist nicht unbedingt sein. Ebensowenig mag ich die seltsame mknod-Verwendung, da zum einen ein Teil direkt von MAKEDEV selbst generiert wird (z.B. bpamem) und zum anderen wenn man auch dev.static neben dev (beim USB) einmalig beim ersten Start benutzt, muß man das entsprechende Dev nicht bei jedem Neustart neu erstellen (z.B. bei rc, was im MAKEDEV fehlt und daher wohl in der rcS ist). Im Falle der stm23-rcS der 7500er wird übrigens "mountall" und "hostname" 2x gestartet wie ich gerade gesehen habe. Ansonsten ist aber das Grundprinzip natürlich das gleiche in der rcS.
Zum Dummy: Wurde bei mir nicht erzeugt. Soll das Script das selbstständig machen oder muß ich das vorher von Hand machen? Oder wird die temporär vielleicht doch erstellt und das Script sucht nur im falschen Verzeichnis (fup.src)?
Re: BP Neutrino für die UFS912
Verfasst: Mi 20. Jul 2011, 10:14
von Schischu
Naja Bzgl Dev Nodes sollte man eh mal auf UDEV wechseln, dann hat man überhaupt keine Probleme.