stm24 207

[Oxygen-1]

Ok thx, nachdem das die orig fw auch sagt nehm ich das jetzt mal als richtig hin.

Was geht eigentlich mit der neue busybox nicht? cifs ist ja ein kernelmodul und hat mit der ja nix zu tun ausser dass vl die mount syntax anders sein koennte

[BPanther]

Letzteres ist wohl der Grund wie es scheint, denn mit der neuen BB kann man von Hand wohl mounten, Neutrino mountet aber anscheinend falsch. Sehe ich aber nicht als Problem, denn ich sehe keine wirklichen Vorteile der neuen BB. flashcp habe ich eh nie gebraucht, Neutrino soll intern flashen, und das geht inzwischen zu 99% problemlos auch mit dem vollen Image. Die einzel-Parts sollten immer gehen.

[Oxygen-1]

stimmt, die busybox ist ja nicht sonderlich wichtig fuers fernsehen. vielleicht findest ja was.

[BPanther]

Jo, bin eh am rumbasteln.

[BPanther]

Anbei mal nen komplettes Verzeichnislisting mit ls -alR erstellt.

[cb0]

Irgendwie komm ich mitm Flashimage nicht weiter. Das Skript in flash/ufs910 macht mir ja ein schönes .img aber sollte das nicht 16515072 Bytes groß sein? Bei mir is das immer größer.

[BPanther]

Ja, 16.515.072 Bytes wäre die richtige Größe. Klappt bei mir auch nur wenn ich es arg abspecke. Ist aber erst seit dem neuen GCC so schlimm geworden (nochmal um ~550kB größer dadurch), deswegen habe ich wieder auf den alten GCC umgestellt. Passt zwar bei mir immernoch nicht ganz weil immernoch größer als vorher (bräuchte für root 10.403.840 Bytes), aber bin schon etwas dichter an der alten Größe dran. Immerhin hat root bei mir früher mal locker in 0x009a0000 gepasst, was 10.092.544 Bytes entspricht - ähnlich wie das stm22 (root da bei mir derzeit ~8.8MB).
Irgendwas muß sich auch auf auf das (echte) Flash-Kernel ausgewirkt haben (bauen mit 2, FLASH_UFS910), denn das zickt weiterhin rum. Wenn garnicht anders muß ich stufenweise bestimmte ältere Revisionen auschecken und testen.
Das Kernel-Problem konnte ich nun beheben, läuft wieder normal. Wird also demnächst wieder ein stm24 geben nach "alter Art" mit ro/rw-Bereichen, wenn ich root noch etwas kleiner bekomme ohne was wichtiges zu löschen (derzeit mußte sdparm dran glauben, somit kein HDD-Standby mehr).

[cb0]

Nagut Danke,
Dann schreibt das Skript von Schischu anscheinend doch nicht wenn der Kernel zu groß ist, denn bei mir is das img genau um die 0.2MB zu groß wie der gzip Kernel im Vergleich zum lzma Kernel größer ist.

Kann eigentlich das maxiboot lzma und boot via nfs?

[BPanther]

Dann schreibt das Skript von Schischu anscheinend doch nicht wenn der Kernel zu groß ist, denn bei mir is das img genau um die 0.2MB zu groß wie der gzip Kernel im Vergleich zum lzma Kernel größer ist.

Warum ist bei Dir das Kernel zu groß? Das sollte doch nur 1.4MB in etwa haben als LZMA-Kernel und es ist sogar noch etwas Platz.

Kann eigentlich das maxiboot lzma und boot via nfs?

LZMA ja (bei mini 1.3r benutzen), sonst würde das bei mir nicht starten, nfs unbekannt (habe ich nicht).

[cb0]

Weils ein gzip Kernel ist, der ist bei mir 1.6MB groß. Da ich meine Testimages via nfs boote hab ich MINI1.2 auf der Box und das kann kein lzma. Und ab MINI1.3 is nfs nicht mehr dabei, deswegen meine Frage wegen Maxiboot.
Muss ich halt schauen wie ich den Kernel abspecken kann.

[BPanther]

Na dann viel glück beim abspecken, das dürfte nicht einfach werden, sind immerhin ~200k...

[DboxOldie]

/linux-sh4/drivers/stm/stx7100_hispeed.c

Hier taucht der cut zu sata auf:



/* SATA resources --------------------------------------------------------- */
static struct stm_plat_sata_data stx7100_sata_platform_data = {
/* filled in stx7100_configure_sata() */
.device_config = &(struct stm_device_config){},
};

static struct platform_device stx7100_sata_device = {
.name = "sata-stm",
.id = -1,
.dev.platform_data = &stx7100_sata_platform_data,
.num_resources = 2,
.resource = (struct resource[]) {
STM_PLAT_RESOURCE_MEM(0x19209000, 0x1000),
STM_PLAT_RESOURCE_IRQ(170, -1),
},
};

void __init stx7100_configure_sata(void)
{
static int configured;

BUG_ON(configured);
configured = 1;

if (cpu_data->type == CPU_STX7100 && cpu_data->cut_major == 1) {
/* 7100 cut 1.x */
stx7100_sata_platform_data.phy_init = 0x0013704A;
} else {
/* 7100 cut 2.x and cut 3.x and 7109 */
stx7100_sata_platform_data.phy_init = 0x388fc;
}

if ((cpu_data->type == CPU_STX7109 && cpu_data->cut_major == 1) ||
cpu_data->type == CPU_STX7100) {
stx7100_sata_platform_data.only_32bit = 1;
stx7100_sata_platform_data.pc_glue_logic_init = 0x1ff;
} else {
stx7100_sata_platform_data.only_32bit = 0;
stx7100_sata_platform_data.pc_glue_logic_init = 0x100ff;
}

platform_device_register(&stx7100_sata_device);
}

[cb0]

Na dann viel glück beim abspecken, das dürfte nicht einfach werden, sind immerhin ~200k...

Danke, muss ich aber doch nicht. Maxiboot kann lzma und boot via nfs!

[BPanther]

Gut zu wissen und Kurzübersicht MINI/MAXI/BA entsprechend angepasst. Danke.

[cb0]

Wie lauft das mit mini_fo eigentlich?
Wenn ich mir im release_neutrino Ordner z.B in /var schon ein paar Sachen zurecht lege und dann das Flash Image baue, dann hab ich im Flash die Sachen nicht in /var sondern in /root_ro/var.
Kann mir mal bitte einer auf die Sprünge helfen wie das ablauft mit dem root_ro root_rw.