PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Denkbar ... aber in meinen Augen auch unwahrscheinlich. Wozu der gut ist und warum der gerade dort liegt, steht (mehr oder weniger ausführlich und ggf. sogar mehr oder weniger richtig bzw. falsch) in diesem Thread: https://www.ip-phone-forum.de/threads/Übersicht-von-fritz-boxen-mit-junk-bytes-im-squashfs-image.286318/
Die dort verlinkte Dokumentation von Imagination Technologies ist unter dieser Adresse nicht mehr erreichbar, aber unter https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00541-2B-74K-PRG-02.14.pdf findet man sie wieder.
Bei NOR-Flash, der direkt am Bus hängt und in den Adressbereich des Prozessors eingeblendet wird (auch ohne Kopieren von A nach B), wäre das für mich logischer ... solange da nicht ein Controller für das SPI oder irgendwelcher anderer Code etwas in den Bereich bei 0xBFC00000 kopiert (bei NOR-Anbindung an den Memory-Bus wurde der Flash an einer entsprechend hohen Adresse eingeblendet, später kann das dank MMU ja nahezu beliebig umgemappt werden), spielt das wohl nicht wirklich eine Rolle.
Es würde zumindest nicht direkt erklären, warum das System gar nicht erst startet (es sei denn, es verwendet NMIs für den "regulären" Betrieb) ... es könnte sich ggf. bei einem NMI dann aufhängen, weil die Interrupt-Behandlung keinen gültigen Code beinhaltet.
Ich will es nicht vollkommen ausschließen und es ist (ggf. mit den Erläuterungen aus dem oben verlinkten Thread und mit den Sourcen für das Entpacken und Suchen des NMI-Vectors) auch kein großes Kunststück, von Hand ein passendes Image zusammenzuklöppeln für den eigenen Test, aber ich bin erst mal sehr skeptisch und würde deshalb jetzt nicht hingehen (aber ich müßte es ja auch nicht machen) und ein Restaurieren des NMI-Vectors in das Packen eines Images mit "hidden root" einbauen.
Ich bin mir nicht mal sicher, ob der NMI-Vector hier tatsächlich gebraucht würde (wie gesagt, wie kommt der Code bei einem SPI-Flash (Und die 4020 hat doch wohl welchen? "Richtiger" NOR-Flash wäre deutlich teurer.) überhaupt an die richtige Adresse und warum sollte das jemand beim Ummappen genauso machen, als würde es sich um NOR-Flash handeln) oder ob das nicht nur ein Relikt im AVM-Code ist, für das es - bei einem System, welches grundsätzlich mit diesem "hidden root image" arbeitet - einfach keine passenden bedingten Anpassungen dort gibt und das so am Ende sogar noch in ARM-Modellen mit diesem Image-Aufbau zu finden wäre (wo es diese Konstruktion an 0xBFC00000 m.W. gar nicht gibt), weil es vom AVM-Programm zum Packen der Images einfach immer mit eingebaut wird (ggf. noch in der "richtigen" Version, wenn er wirklich von Bedeutung sein sollte).
Dafür spricht in meinen Augen auch, wenn das stur an 0xBE0000 im Image liegt ... diese Verschiebung ergibt sich ja auch daraus, daß da ein Bootloader mit einer Größe von 128 KB vor der Kernel-/Dateisystem-Partition im Flash liegt muß und mit dieser zusätzlichen Verschiebung (diese 128 KB ergeben in Hex dann 0x20000 und wenn man das zu dieser Verschiebung im Image hinzuaddiert, landet man bei 0xC00000 und das ist die Adresse des NMI-Vectors, wenn der betreffende Speicherbereich für den Flash an Adresse 0xBF000000 eingeblendet würde) erst, paßt dann die Adresse auch.
Nun weiß man zwar nichts Genaueres vom Innenleben der 4020 und von deren Flash-Aufbau (zumindest ich nicht) ... aber es erscheint mir auch unwahrscheinlich, daß AVM immer nur Boxen mit 128 KB-Bootloadern (bzw. mit Partitionen für den Bootloader in dieser Größe) unters Volk bringt.
Aber wie gesagt ... ich will es nicht ausschließen, glaube aber bis zum Beweis des Gegenteils eher nicht daran, daß das hier wirklich ein Problem darstellt.
Die dort verlinkte Dokumentation von Imagination Technologies ist unter dieser Adresse nicht mehr erreichbar, aber unter https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00541-2B-74K-PRG-02.14.pdf findet man sie wieder.
Bei NOR-Flash, der direkt am Bus hängt und in den Adressbereich des Prozessors eingeblendet wird (auch ohne Kopieren von A nach B), wäre das für mich logischer ... solange da nicht ein Controller für das SPI oder irgendwelcher anderer Code etwas in den Bereich bei 0xBFC00000 kopiert (bei NOR-Anbindung an den Memory-Bus wurde der Flash an einer entsprechend hohen Adresse eingeblendet, später kann das dank MMU ja nahezu beliebig umgemappt werden), spielt das wohl nicht wirklich eine Rolle.
Es würde zumindest nicht direkt erklären, warum das System gar nicht erst startet (es sei denn, es verwendet NMIs für den "regulären" Betrieb) ... es könnte sich ggf. bei einem NMI dann aufhängen, weil die Interrupt-Behandlung keinen gültigen Code beinhaltet.
Ich will es nicht vollkommen ausschließen und es ist (ggf. mit den Erläuterungen aus dem oben verlinkten Thread und mit den Sourcen für das Entpacken und Suchen des NMI-Vectors) auch kein großes Kunststück, von Hand ein passendes Image zusammenzuklöppeln für den eigenen Test, aber ich bin erst mal sehr skeptisch und würde deshalb jetzt nicht hingehen (aber ich müßte es ja auch nicht machen) und ein Restaurieren des NMI-Vectors in das Packen eines Images mit "hidden root" einbauen.
Ich bin mir nicht mal sicher, ob der NMI-Vector hier tatsächlich gebraucht würde (wie gesagt, wie kommt der Code bei einem SPI-Flash (Und die 4020 hat doch wohl welchen? "Richtiger" NOR-Flash wäre deutlich teurer.) überhaupt an die richtige Adresse und warum sollte das jemand beim Ummappen genauso machen, als würde es sich um NOR-Flash handeln) oder ob das nicht nur ein Relikt im AVM-Code ist, für das es - bei einem System, welches grundsätzlich mit diesem "hidden root image" arbeitet - einfach keine passenden bedingten Anpassungen dort gibt und das so am Ende sogar noch in ARM-Modellen mit diesem Image-Aufbau zu finden wäre (wo es diese Konstruktion an 0xBFC00000 m.W. gar nicht gibt), weil es vom AVM-Programm zum Packen der Images einfach immer mit eingebaut wird (ggf. noch in der "richtigen" Version, wenn er wirklich von Bedeutung sein sollte).
Dafür spricht in meinen Augen auch, wenn das stur an 0xBE0000 im Image liegt ... diese Verschiebung ergibt sich ja auch daraus, daß da ein Bootloader mit einer Größe von 128 KB vor der Kernel-/Dateisystem-Partition im Flash liegt muß und mit dieser zusätzlichen Verschiebung (diese 128 KB ergeben in Hex dann 0x20000 und wenn man das zu dieser Verschiebung im Image hinzuaddiert, landet man bei 0xC00000 und das ist die Adresse des NMI-Vectors, wenn der betreffende Speicherbereich für den Flash an Adresse 0xBF000000 eingeblendet würde) erst, paßt dann die Adresse auch.
Nun weiß man zwar nichts Genaueres vom Innenleben der 4020 und von deren Flash-Aufbau (zumindest ich nicht) ... aber es erscheint mir auch unwahrscheinlich, daß AVM immer nur Boxen mit 128 KB-Bootloadern (bzw. mit Partitionen für den Bootloader in dieser Größe) unters Volk bringt.
Aber wie gesagt ... ich will es nicht ausschließen, glaube aber bis zum Beweis des Gegenteils eher nicht daran, daß das hier wirklich ein Problem darstellt.