CVS U-BOOT und boot.conf

[flasher]

Hallo

Keine Ahnung ob das nur bei mir so ist oder ob es noch niemanden aufgefallen ist.
Kann es sein, dass die Einträge ignoriert oder nicht weitergegeben werden?

Meine boot.conf sieht so aus:
console=ttyS0
baudrate=9600
lcd_inverse=0
lcd_contrast=15
dbox_duplex=1

Ich bin nun hingegangen und habe in Neutrino den Kontrast auf 24 gestellt.
Box vom Strom genommen und neu gestartet. Der Frontprozessor scheint sich dann die 24 zu merken denn beim Boot ist das LCD weiterhin zu hell.
Jetzt sollte doch zumindest durch lcd_contrast=15 der Kontrast beim Booten wieder OK sein und erst beim LCDD Start wieder auf 24 gesetzt werden.

dbox_duplex=1 kommt auch nicht beim Kernelmodul an.

Irgendwie bin ich etwas verwirrt. Ok, dass ist bei mir Normalzustand.

Gruß

[seife]

Ein u-boot aus einem einigermassen aktuellen CVS zeigt dir die gefundenen optionen an:

Code: Alles auswählen

Requesting system reboot
[41069.047689] Restarting system.
nv: found "lcd_inverse"
env: found "lcd_contrast"
FB:    ready
LCD:   ready
In:    serial
Out:   serial
Err:   serial
Net:   SCC ETHERNET

(bei mir fehlt was, weil erst wieder was kommt, nachdem auf 115200 baud umgeschaltet wurde).
Der u-boot muss die Parameter alle kennen, deswegen geht "dbox_duplex" nicht.
Man könnte einen "append"-Parameter in die boot.conf machen, damit man beliebige Parameter anhängen kann, für Profis. Ich denk mal drüber nach, wenn du allerdings schneller bist und einen Patch lieferst, wäre das nicht schlecht ;-)

[flasher]

Achso ich vergass:

Bootlog:

Code: Alles auswählen

env: found "console"
env: found "baudrate"
env: found "lcd_inverse"
env: found "lcd_contrast"
env: found "dbox_duplex"

Demnach kennt U-Boot die Parameter.

Aber wie geschrieben wird weder das LCD auf Kontrast 15 gestellt noch der Wert für dbox_duplex weitergereicht.

CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
half-duplex mode enabled
eth0: CPM ENET Version 0.2.dbox2 on SCC2, 00:00:12:34:56:78

Dort sollte ja full duplex stehen, egal ob ich die Hardware nun verändert habe oder nicht.

Gepatcht habe ich das ganze übrigens mit den Patches aus dem "FDX" Thread.

[mohousch]

habe auch noch ein kömisches Effekt mit dem U-boot und zwar habe das logo-fb getauscht mit einem wo die Groesse des Bilds war kleiner (_zufall_)und beim booten sieht man das neue Bildschen und als Hintergründ noch das alte Bild das gar nicht auf die Box existiert:

[seife]

u-boot kennt dbox_duplex nicht und weiss damit nichts anzufangen.

u-boot-append-kernelparameter.diff

Damit kannst du dann in die boot.conf eintragen:

Code: Alles auswählen

append=dbox_duplex=4711 quiet panic=5

Alles hinter "append=" wird hinten an die Kernel commandline angehängt.

Ich habe das nur auf kernel 2.6 / squashfs / newmake getestet, wenn Erfolgsmeldungen mit anderen Konfigurationen kommen, dann checke ichs ein (und passe neutrino an)

[flasher]

Ist schon seltsam wenn es einen weiteren Patch geben muss desswegen.
In FDX Thread waren doch einige Leute bei dennen das angeblich funktionierte. Oder haben die das nur mit einem reinen FDX Treiber probiert?
Nun ja, ich werde das mal probieren.

[flasher]

Ich hohle Frucht, ja ich muss das mal zugeben...

Hier ist der Fehler...

Code: Alles auswählen

#define	CONFIG_BOOTCOMMAND							  \
	"setenv bootargs console=$(console),$(baudrate) root=/dev/mtdblock2 ifelse(rootfstype, `jffs2', `rw ')`rootfstype'=rootfstype;\
		     fsload; protect off 10020000 107fffff; bootm"

Das sollte so aussehen und dann klappt es auch mit dem FDX.

Code: Alles auswählen

#define	CONFIG_BOOTCOMMAND							  \
	"setenv bootargs console=$(console),$(baudrate) dbox_duplex=$(dbox_duplex) root=/dev/mtdblock2 ifelse(rootfstype, `jffs2', `rw ')`rootfstype'=rootfstype;\
		     fsload; protect off 10020000 107fffff; bootm"

Zumindest sagt es das Bootlog:

ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
full-duplex mode enabled

[seife]

Das ist dann ein dreckeffekt, da u-boot die Variable "dbox_duplex" nicht kennt und drum auch nicht setzen wird.

Schau mal mit "cat /proc/cmdline", was dein kernel tatsächlich für eine Kommandozeile abbekommen hat.

Mein Patch erlaubt, beliebige Parameter zu übergeben, was praktisch sein kann, aber nur wenn es auch funktiniert... ;-)

[flasher]

Also ich verstehe jetzt nicht ganz warum U-Boot diesen Parameter nicht kennen oder das ein Dreckeffekt sein soll.

Ich habe ja nichts anderes gemacht als das was Du mit Deinem Patch gemacht hasst.
Bei mir ist es lediglich so, dass nur ein Parameter übergeben/eingetragen wird.

Ich weiss jetzt nicht ob Du das überlesen hasst aber ich habe u-boot vorher gepatcht mit den Patchen die man im FDX Thread findet.
Dort liegen drei Patches. Kernel, U-Boot und Neutrino.

Hier die CMDLINE

/var # cat /proc/cmdline
console=ttyS0,9600 dbox_duplex=1 root=/dev/mtdblock2 rootfstype=squashfs
/var#

Dreckeffekt würde ich das dann nennen wenn ich versuchen würde den Parameter irgendwie zum Kernelmodul zu bekommen.
Nun ist es ja so, dass U-BOOT die boot.conf auswertet, den dbox_duplex Wert findet und diesen dann in die cmdline schreibt.

[seife]

Also ich verstehe jetzt nicht ganz warum U-Boot diesen Parameter nicht kennen oder das ein Dreckeffekt sein soll.

Ich habe ja nichts anderes gemacht als das was Du mit Deinem Patch gemacht hasst.
Bei mir ist es lediglich so, dass nur ein Parameter übergeben/eingetragen wird.

Ok, das hatte ich anders verstanden. Ich hatte verstanden, dass du nur das CONFIG_BOOTCOMMAND define geändert hattest, so das da dbox_duplex=$(dbox_duplex) drinsteht. Das würde mit einem ungepatchten u-boot aber genau zu garnichts führen, da dort "$(dbox_duplex)" zu "" expandiert

Dreckeffekt würde ich das dann nennen wenn ich versuchen würde den Parameter irgendwie zum Kernelmodul zu bekommen.
Nun ist es ja so, dass U-BOOT die boot.conf auswertet, den dbox_duplex Wert findet und diesen dann in die cmdline schreibt.

Ja, aber nicht der "original" u-boot . So ist ja alles gut.

[Therket]

Welchen Grund hat es eigentlich, dass die Key/Value Paare der boot.conf nicht 1:1 im u-boot übernommen werden?

Im Moment werden nur die Schlüssel, die hart codiert in boot/u-boot-tuxbox/board/dbox2/dbox2.c hinterlegt sind, verwendet, alle anderen werden mit einer Warnmeldung verworfen:

Code: Alles auswählen

printf ("env: found %s with value %s\n", &buf[namestart], &buf[valuestart]);
		if (!strcmp (&buf[namestart], "bootcmd"))
			setenv ("bootcmd", &buf[valuestart]);
		else if (!strcmp (&buf[namestart], "console"))
			setenv ("console", &buf[valuestart]);
		else if (!strcmp (&buf[namestart], "lcd_contrast")) 
			setenv ("lcd_contrast", &buf[valuestart]); 
		else if (!strcmp (&buf[namestart], "lcd_inverse")) 
			setenv ("lcd_inverse", &buf[valuestart]); 
		else if (!strcmp (&buf[namestart], "lcd_bias")) 
			setenv ("lcd_bias", &buf[valuestart]); 
		else if (!strcmp (&buf[namestart], "baudrate"))
			setenv ("baudrate_now", &buf[valuestart]);
		else if (!strcmp (&buf[namestart], "dbox_duplex")) 
			setenv ("dbox_duplex", &buf[valuestart]);
		else
			printf ("env: can't set \"%s\"\n", &buf[namestart]);

Was spricht dagegen, die Werte der boot.conf 1:1 zu übernehmen?

Code: Alles auswählen

printf ("env: found %s with value %s\n", &buf[namestart], &buf[valuestart]);
setenv (&buf[namestart], &buf[valuestart]);

Das würde es erlauben, ohne Änderungen am Code weitere Parameter frei definieren zu können (z.B. serverip, ipaddr, etc...). In diesem Fall könnte man gar einige Scripte anlegen, die das Booten eines Yadd, bei dem nur ein NFS-Server bereitgestellt wird, erheblich erleichtern.

Das einzig aktuelle Problem wäre die Key-Änderung von "baudrate" auf "baudrate_new".

Gruß
Jens

[abraXXl]

Hallo,

ich habe basierend auf CVS Stand vom 19.9. den Patch damit das Flash-Uboot auch IDE kennt mal angepasst.
d.h Anpassungen fuer den derzeit im CVS benutzten Uboot 2009.8

Da das mkflfs aber dann gemosert hat, dass der Bootloader zu groß wurde habe ich ihn mit der "Hilti" runtergeschrumpft.
mkflfs konnte den uboot.stripped nur auf ca 134000 Bytes runtschrumpfen. Ca 3 KB zu gross.

Zunächst habe ich den RARP-Support kastriert, den brauch hoffentlich eh keiner, es sei denn er möchte mit dem Betanova-Zeug rumfuchteln.
Leider reichte dies noch nicht. Danach habe ich U-Boot um den XYZ-Modem-Support zum Laden von OS-Images via serieller Konsole kastriert.

Getestet habe ich den resultierenden Uboot. Er läd Files via JFFS2 und EXT2. Da ich noch keinen Kernel mit IDE-Kernel habe konnte ich aber nur das Booten via JFFS2 testen.

Ich habe vorher in meinem JFFS2 Image mit tuxbox -C 16 getestet ob ein IDE Interface vorhanden ist, die fällt jetzt auf die Nase wrum erschliesst sich mir noch nicht.

Was noch toll wäre ist eine UBOOT-Umgebungsvariable, welche den den Alternative IRQ6 an den Kernel weiter reicht.

Damit der Patch hier im Text nicht kaputt geht liegt er hier.

:wq

[rhabarber1848]

In der U-Boot-config im CVS gibt es bereits Vorbereitungen
für IDE-Support in U-Boot, nur noch keine make targets.
Das habe ich nun geändert:
http://article.gmane.org/gmane.comp.vid ... x.scm/1150

Das neue make target "ide-u-boot" baut

Code: Alles auswählen

-rw-r--r-- 1 root root 131072 20. Sep 15:59 ide.flfs1x
-rw-r--r-- 1 root root 131072 20. Sep 15:59 ide.flfs2x

normal_size 176512 lzo_size 120222

Allerdings ohne JFFS2 und Squashfs, nur ext2.

Das ganze hat eher vorbereitenden Charakter und soll
hauptsächlich dazu dienen, Zeilen dieser Art

Code: Alles auswählen

-#if (UBOOT_TYPE == UBOOT_TYPE_IDE)

im obigen Patch überflüssig zu machen.

Was dann genau in einem IDE-U-Boot enthalten sein soll,
ob es verschiedene Kombinationen (IDE+Squashfs, IDE+JFFS2,
IDE+ext2) geben soll, bleibt erstmal offen und wird sich im
weiteren Entwicklungsprozess ergeben. Ich kann dazu nicht
beitragen, da ich kein IDE-Interface habe(n will).