Hallo, ich würde gerne eure Einschätzung zum generellen Vorgehen in Bezug auf ein beliebiges Device haben, also von einem beliebigen Hersteller, sagen wir ein WLAN Access Point oder, wie in einem anderen Beitrag von mir, der sich allerdings ein wenig unterscheidet, einem SFP GPON Module. Das Device hat (noch) keiner angerührt, ggf. sind Fuse-Bits gesetzt und es ist kein Image auf OpenWRT für dieses Device zu finden. Sagen wir ich habe zum Experimentieren ein solches Device vor mir, öffne es, kann mir den Chip anschauen. Wenn ich ihn auslesen kann und die Chip-Art kenne, dann kann ich sicherlich prüfen ob ein Fuse-Bit gesetzt ist und ob es überhaupt möglich ist auf den Chip eine andere Software aufzuspielen. Bei Devices, die standardmäßig ein Software-Update anbieten, wird es ein flash-Bereich sein, den man überschreiben kann. Gibt es ggf. andere Bereiche, die gesperrt sein könnten und wo ein "Bootloader" überprüft, ob das auch ein verifiziertes Betriebssystem ist? In einem anderen Beitrag, den ich in meinem Beitrag zum SFP GPON Modul verlinkt habe, ist folgendes zu finden: root@SFP:~# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00010000 "uboot" mtd1: 00080000 00010000 "uboot_env" mtd2: 00740000 00010000 "linux" mtd3: 006191d8 00010000 "rootfs" mtd4: 00400000 00010000 "rootfs_data" mtd5: 00800000 00010000 "image1" Hier wurden also Speicherbereiche eindeutigen Linux-Funktionen zugewiesen. Bei jedem Chip wird es einen Bereich geben, ab dem, Design-seitig alles los geht und da sitzt der Bootloader. Kann man diesen Bereich überhaupt mit einem Fuse-Bit sperren? (Die Konsequenz wäre, dass ich mir den selben Chip besorgen, den alten aus und einen "frischen", mit meinem Bootloader, einlöten müsste. Für mich sieht das obige Beispiel aus wie einzelne Partitionen, könnt Ihr mir das bestätigen? Wenn ich OpenWRT konfiguriere, so müsste ich anhand der Komponenten auf dem Board doch eigentlich genau festlegen können, welcher I/O Pin des Prozessors welche Funktion übernimmt und z.B. Ethernet oder die LEDs ansteuert. Wenn ich OpenWRT vom Aufbau richtig verstanden habe, dann sind Module verfügbar, die man konfigurieren muss. Einen Treiber für die einzelnen Komponenten zu schreiben dürfte dann eigentlich leicht sein; "eigentlich" nur im Sinne der LEDs vielleicht, aber z.B. den Laser korrekt anzusteuern dürfte etwas schwieriger werden und ich habe gehört, dass man da großen Schaden anrichten kann, bzw. habe ich das auf einer Seite zum Thema gelesen. Da hätte ich auch gerne nähere Infos zu. Und mit Bezug zu dem GPON Modul habe ich sogar eine Version gesehen, in der man sich auf dem GPON Modul per Webbrowser, über die IP einloggen konnte, um selbige zu ändern, aber auch den PLOAM Code und Ähnliches - so möchte ich es haben. Vielen Dank schon einmal. Freewarehookie
:
Bearbeitet durch User
Christian schrieb: > Vielleicht hilft dir dieser Vortrag weiter: > https://www.youtube.com/watch?v=EQtqSXCSJZM 1000 Dank!
Christian schrieb: > Vielleicht hilft dir dieser Vortrag weiter: > https://www.youtube.com/watch?v=EQtqSXCSJZM Frage zum Video: Warum hat er die beiden Partitionen "konkartiniert" und nicht eine neue geschrieben, um nur eine zu haben, in der er OpenWRT installiert? (ab 19:30) Im weiteren Verlauf referenziert er auch immer wieder andere Partitionen, auf denen z.B. die Mac-Adresse definiert wird. Will er diese nicht anfassen und nur die beiden virtualisieren, damit er sein OpenWRT in das bestehende System integriert? MfG
:
Bearbeitet durch User
Kai S. schrieb: > Hallo, > > ich würde gerne eure Einschätzung zum generellen Vorgehen in Bezug auf > ein beliebiges Device haben, also von einem beliebigen Hersteller, Es gibt kein generelles Vorgehen, weil es keine Version von OpenWRT fuer ein "beliebiges" Device gibt. Damit verlieren alle deine weiteren Fragen ihren Sinn. Grunsaetzlich versucht OpenWRT einen bereits vorhandenen Bootlader weiterzubenutzen. Und es gibt deutlich mehr Bootlader als uboot. Schon das sorgt dafuer, dass eine Installation geraetetypisch ist. > root@SFP:~# cat /proc/mtd > dev: size erasesize name > mtd0: 00040000 00010000 "uboot" > mtd1: 00080000 00010000 "uboot_env" > mtd2: 00740000 00010000 "linux" > mtd3: 006191d8 00010000 "rootfs" > mtd4: 00400000 00010000 "rootfs_data" > mtd5: 00800000 00010000 "image1" > Für mich sieht das obige Beispiel aus wie einzelne Partitionen, könnt > Ihr mir das bestätigen? Es sind im UNIX® Sprachgebrauch "Slices". Bei x86/x64 liegen Slices, wenn nicht auf dem Blockdevice selbst, dann in einer oder mehreren Partitionen. Was nicht ausschliesst, dass ein UNIX innerhalb eines Slices selbst wieder Partitionen anlegt. Die sind dann natuerlich nur innerhalb dieses Systems sichtbar.
Motopick schrieb: > Es gibt kein generelles Vorgehen, weil es keine Version von OpenWRT > fuer ein "beliebiges" Device gibt. > Damit verlieren alle deine weiteren Fragen ihren Sinn. Der Sinn deiner Worte erschließt sich mir jetzt leider auch nicht - wieso sollen die anderen Fragen ihren Sinn verlieren, wenn es kein generelles Vorgehen gibt? Hä? Christian schrieb: > Vielleicht hilft dir dieser Vortrag weiter: > https://www.youtube.com/watch?v=EQtqSXCSJZM Dieser Vortrag gibt ein generelles Vorgehen vor; so etwas habe ich gesucht! Motopick schrieb: > Grunsaetzlich versucht OpenWRT einen bereits vorhandenen Bootlader > weiterzubenutzen. Und es gibt deutlich mehr Bootlader als uboot. > Schon das sorgt dafuer, dass eine Installation geraetetypisch ist. [...] > Es sind im UNIX® Sprachgebrauch "Slices". > Bei x86/x64 liegen Slices, wenn nicht auf dem Blockdevice selbst, > dann in einer oder mehreren Partitionen. > Was nicht ausschliesst, dass ein UNIX innerhalb eines Slices > selbst wieder Partitionen anlegt. Die sind dann natuerlich nur > innerhalb dieses Systems sichtbar. Dafür danke ich recht herzlich, denn das hilft dann doch sehr! MfG Kai Siebner
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.