@chips:
Bei der 7590 (incl. AX) kannst Du damit recht haben, da hat AVM die Power-LED tatsächlich als "low active" implementiert (vermutlich bei allen GRX-Boxen, denn die nehmen alle dieselbe Definition für den FDT):
Rich (BBCode):
/* LEDs & Buttons für die 7590 und verwandte Boxen */
&ssoled {
status = "okay";
avm_led_ambientbrightness: led0 {
label = "avm:none:ambientbrightness";
led-gpio = <&ssogpio 0 GPIO_ACTIVE_HIGH>;
intel,led-pin = <0>;
};
avm_led_info_green: led2 {
label = "avm:green:info";
led-gpio = <&ssogpio 2 GPIO_ACTIVE_HIGH>;
intel,led-pin = <2>;
};
avm_led_info_red: led3 {
label = "avm:red:info";
led-gpio = <&ssogpio 3 GPIO_ACTIVE_HIGH>;
intel,led-pin = <3>;
};
avm_led_box_wlan: led4 {
label = "avm:green:wlan";
led-gpio = <&ssogpio 4 GPIO_ACTIVE_HIGH>;
intel,led-pin = <4>;
};
avm_led_box_fon: led5 {
label = "avm:green:fon";
led-gpio = <&ssogpio 5 GPIO_ACTIVE_HIGH>;
intel,led-pin = <5>;
};
avm_led_connect: led6 {
label = "avm:green:connect";
led-gpio = <&ssogpio 6 GPIO_ACTIVE_HIGH>;
intel,led-pin = <6>;
};
avm_led_box_power: led7 {
label = "avm:green:power";
led-gpio = <&ssogpio 7 GPIO_ACTIVE_LOW>;
intel,led-pin = <7>;
};
};
Jedoch startet (afaik) nicht jeder Prozessor automatisch mit Low-Pegel an den GPIO-Pins - ansonsten müßten bei anderen Modellen (hier beispielhaft eine 7490, die ja ebenfalls MIPS-basiert ist - das SoC ist praktisch der Vorgänger der GRX-Chips:
Rich (BBCode):
/ {
avm-hw-revision{
compatible = "avm,avm_hw_revision";
revision = "185";
};
avm-gpio{
compatible = "avm,avm_gpio_generic";
gpio_avm_led_power{
value = <45>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
gpio_avm_led_internet{
value = <47>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
gpio_avm_led_festnetz{
value = <36>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
gpio_avm_led_wlan{
value = <35>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
gpio_avm_led_info{
value = <33>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
gpio_avm_led_info_red{
value = <46>;
param = <AVM_DEF_HW_PARAM_GPIO_OUT_ACTIVE_LOW>;
config = <IFX_GPIO_IOCTL_PIN_CONFIG_DIR_OUT IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL0_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_ALTSEL1_CLEAR IFX_GPIO_IOCTL_PIN_CONFIG_OUTPUT_SET>;
module_id = <DEF_IFX_GPIO_MODULE_LED>;
};
) ALLE LEDs leuchten, wenn der Bootloader nicht gestartet werden kann (was iirc nicht der Fall ist, aber ich bin auch schon wieder länger raus aus dem Spiel). Bei anderen Modellen (z.B. der 4080, auch wenn die wohl nur ein Phantom war) ist hingegen auch die Power-LED "high active", damit dürfte die auch nicht leuchten, wenn nur die Stromversorgung anliegt.
Ich verstehe trotzdem nicht, was so schwer daran sein soll, einfach ein kurzes Video vom "Startvorgang" (egal wie weit der nun funktioniert oder nicht) hier einzustellen - es gibt eben neben der Möglichkeit, daß der Bootloader gar nicht mehr geht, noch genug andere "Fallen", die den Zugriff auf EVA verhindern können, selbst wenn der zuvor mal geklappt hat. Die meisten Leute verstehen nämlich auch nicht, warum es einen Unterschied macht, ob man versucht, auf eine zuvor funktionierende FRITZ!Box (bzw. deren Bootloader) zuzugreifen oder nunmehr auf eine Box, die eben nicht mehr startet. Was für den Laien so aussehen mag, als gäbe es gar keine Unterschiede, ist aus Sicht der Netzwerk-Konfiguration (gerade auch bei Windows-PCs, aber das gilt ebenso für einige Linux-Derivate, die versuchen, eigene Intelligenz im Netzwerk zu simulieren) etwas vollkommen anderes ... und da ist eine gewisse Vorsicht bei allzu eilfertigen Feststellungen, der Bootloader wäre gar nicht mehr erreichbar, durchaus angebracht - erst recht dann, wenn derjenige mit dem Problem von sich selbst behauptet, sich damit nicht so genau auszukennen.
Ich habe jedenfalls gerade mal spaßeshalber versucht, eine alte 7590 (eine ohne AX, aber die sollten tatsächlich an dieser Stelle identisch sein), die ohnehin defekt ist, dazu zu überreden, eine der beiden Partitionen, von denen hier berichtet wurde, zu überschreiben und damit den Bootloader (es ist die Version 1.3258) zu killen - mir ist das nicht geglückt (auch nicht, wenn ich versuche nach MTD2 zu schreiben).
Wenn hier die Serielle bestückt wird, sollte dann aber auch nichts mehr von dem, was da hinter "Detected ..." steht im Screenshot in #31, erscheinen - das ist definitiv alles Preloader/Urlader (EVA) und steht in den jeweiligen Kopien in der Bootloader-Partition. Wobei es möglicherweise sogar auch zwei Kopien des Preloaders sein könnten (ich habe mir den Inhalt der Loader-Partition der verwendeten Box noch einmal kurz angesehen) - eine an 0x0000000 und eine weitere an 0x00040000, die jeweils den Code für EVA von 0x00080000 bzw. 0x000C0000 versuchen zu laden.
Zumindest durch gekippte Bits im NAND-Flash sollte also eine solche Box nicht am Booten gehindert werden - vielleicht hat(te) der Bootloader-Code beim STOR-Kommando ja tatsächlich bei irgendwelchen Versionen einen Bug und hat gleich die gesamten ersten 44 MB im NAND-Flash gelöscht (meine Version hat diesen Bug dann aber wohl nicht), denn die Definition für MTD0 in der EVA-Konfiguration umfaßt tatsächlich den Bereich von 0x0 bis 0x2c00000, was natürlich das erste MB mit der Bootloader-Partition einschließt (die ist noch einmal als MTD2 definiert, von 0x0 bis 0x100000).
Ich habe mal nach anderen Berichten, daß sich jemand den Bootloader durch Schreiben nach MTD0 und/oder MTD1 zerstört hätte, gesucht - allerdings nur hier im IPPF (vielleicht habe ich ja auch etwas übersehen). Was ich gefunden habe, waren Berichte (bei früheren Boxen, vor 2019), daß das beim Schreiben nach MTD2 passiert wäre (deshalb habe ich ja extra einen zusätzlichen Parameter in mein PS-Skript eingebaut, wenn jemand WIRKLICH nach MTD2 schreiben will) - für MTD0 bzw. MTD1 habe ich solche Berichte nicht gefunden.
Andererseits haben auch schon genug andere Leute ähnlichen Unsinn (
@elyar01: nicht persönlich nehmen, das war nun mal objektiv Blödsinn) verzapft und da war garantiert auch schon jemand dabei, der ebenfalls MTD0 und MTD1 beschreiben wollte bei einer GRX-Box. Es ist also zumindest "verwunderlich", wenn hier genau bei jemandem, der seinerseits gar nicht geübt ist im Umgang mit dem Bootloader von AVM, ein derartiges Problem auftritt und bei einer (doch vergleichsweise neuen Box, die sicherlich auch den jeweils aktuellen Bootloader hat) einfach so der Bootloader gelöscht werden kann. Man stelle sich nur mal vor, das würde jemand absichtlich machen, wenn das Ende der freiwilligen Herstellergarantie naht - AVM bliebe ja kaum etwas anderes übrig, als die Box immer wieder zu tauschen, denn das (absichtliche) Löschen ist praktisch nicht nachweisbar.
Zumal - wie schon mal erwähnt: der Bootloader (zumindest so weit ich weiß und das aus Dumps rekonstruieren konnte ... allerdings habe ich auch nicht alle Versionen untersuchen können) hat eigentlich gar keinen Grund, selbst irgendetwas in die NAND-Partitionen zu schreiben (das OS wird aus dem RAM gestartet und installiert sich dann selbst im Flash) ... mit Ausnahme eines TFFS-Images. Aber das wird im NAND-Flash auch in einem speziellen Format gespeichert, während es dem Bootloader im "legacy format" angeboten werden kann (bzw. muß), was dann auch nicht direkt in irgendein MTDx geschrieben wird, sondern nach MTDNAND. Dabei wird es auch gleich noch passend in das Format für die TFFS-Speicherung im NAND-Flash konvertiert - das ist also eine "Spezialbehandlung", die eben nur ein neues TFFS-Image erfährt.
Es gibt zwar auch Reste, die auf die Möglichkeit eines Urlader-Updates über den Bootloader hindeuten:
Rich (BBCode):
vidar:~/._github/YourFritz/eva_tools/local/urlader/7590 # strings mtd.dmp | grep -i "urlader.*update"
Booting from UART. Only Urlader-Update supported!!!
553 Urlader_Update failed.
Booting from UART. Only Urlader-Update supported!!!
553 Urlader_Update failed.
vidar:~/._github/YourFritz/eva_tools/local/urlader/7590 #
aber wohl eher nicht über (Netzwerk-)FTP.
Daher irritiert es mich sehr, wenn hier ein GRX-Urlader (wie geschrieben, kenne ich allerdings nicht jede Version und da ändert AVM ja auch ab und an mal etwas - gerade wenn es um die Übergabe eines FDT an den startenden Kernel geht, die ja mit den GRX-Chips und deren neuem Kernel Einzug hielt) in irgendwelche Flash-Partitionen schreiben sollte/wollte ... und eigentlich käme da ja (wenn man nicht doch direkt MTD2 adressiert und die EVA-Version da tatsächlich etwas schreiben will) auch nur MTD0 in Frage, denn nur die überlappt mit der Bootloader-Partition und m.W. gehen die EVA-Definitionen bei den GRX-Boxen auch nur bis MTD5 ... also sollte auch alles, was nach MTD6/MTD7 und MTD11 bis MTD14 schreiben will (was bei einer 6490 denkbar wäre und vielleicht auch Bestandteil der verwendeten "Anleitung" war), gar nicht erst funktionieren und auch nichts "zerstören".
Abseits vom NAND-Format für das TFFS ist die Behandlung von NAND-Flash (mit und ohne ECC) durchaus komplex, bis hin zur Verwaltung einer "bad block table" ... es verwundert mich schon etwas, wenn AVM da die ganze notwendige Logik ZUSÄTZLICH im Urlader implementiert haben sollte (wenn der tatsächlich selbst in den NAND-Flash schreiben kann) und dann dennoch selbst hingeht und die Installation des OS (und da kommt bei den GRX-Boxen ja noch der UBI-Layer dazu, der für die Filesystem-Partition verwendet wird, auch wenn der Kernel "plain" im Flash landet) über den Start aus dem RAM vornimmt ... wobei letzteres natürlich den Vorteil hat, daß dabei bereits der komplette Kernel mit allen notwendigen Treibern - auch für die verschiedenen Flash-Typen - zur Verfügung steht.
Ich habe jedenfalls im Urlader-Dump nichts gefunden, was darauf hindeuten würde, daß der tatsächlich weiß, wie er mit dem NAND-Flash für Kernel und Filesystem umzugehen hätte (so, daß das später der Kernel auch noch parallel kann - für das TFFS übernimmt das dann ja der Treiber von AVM) - alles, was da irgendwie mit "write" zu tun hat, ist entweder TFFS-bezogen (dafür hat AVM tatsächlich etwas eingebaut) oder hat mit anderen Ports zu tun, aber nicht mit NAND-Flash.
Aber mir soll es letztlich auch egal sein ... wenn da tatsächlich die Bootloader-Partition "leer" sein sollte, hätte ich aber schon gerne GENAU gewußt, wie man das anstellen kann/muß. Mir ist es eben nicht gelungen, auch wenn die Power-LED bei den GRX-Boxen (und die verwenden offenbar alle dasselbe LED-Schema, außer vielleicht die 7583) tatsächlich auch dann leuchten kann, wenn der GPIO-Port beim Start des SoC auf "low" geht - das hatte ich vorher so nicht auf dem Schirm, daß diese LED bei den Boxen anders "verkabelt" ist, als die anderen LEDs.
Wenn jemand jetzt noch eine (bessere/passende) Erklärung für das Phänomen hat, daß andere Modelle für ALLE LEDs "low active" verwenden und die dennoch nicht alle direkt beim Herstellen der Stromversorgung leuchten (auch wenn sie nicht durch den startenden Bootloader gleich wieder ausgeknipst werden, weil eben auch dort kein Bootloader mehr vorhanden ist - was bei einer 7490 und deren SPI-Flash für die Speicherung des Urladers deutlich leichter zu realisieren/provozieren ist), würde ich die gerne
hören lesen.
EDIT:
per put in mtd1 bzw. mtd2
DAS macht mich eben so stutzig ... welches Youtube-Video behauptet denn, man solle irgendetwas per EVA nach MTD2 schreiben? Nach dem, was er da verlinkt hatte, dürfte eben nur MTD0/MTD1 plus MTD6/MTD7 "angegriffen" werden, ggf. noch MTD11 bis MTD14 für ein vermutetes "inaktives" System. Aber MTD2? Das wäre ja nachgerade fahrlässiges bis vorsätzliches Zerstören einer Box (wenn EVA da schreiben sollte, wobei es auch schon reicht, wenn sie da versucht zu löschen).
