.titleBar { margin-bottom: 5px!important; }

FRITZ!OS7 openvpn auf 7590 => kein tun Modul

Dieses Thema im Forum "Freetz" wurde erstellt von CKone, 4 Aug. 2018.

  1. CKone

    CKone Neuer User

    Registriert seit:
    1 Nov. 2005
    Beiträge:
    21
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hallo

    versuche ich ein freetz aus dem Trunc mit openvpn zu bauen warnt er in der menuconfig das er es mangels vorhandenem Kernelsource nicht hinbekommt das tun Modul zu bauen.

    Gibt es hier irgendwie Abhilfe, weil beim letzten Labor gehts ja auch. Und warum kann ich kein statisch verlinktes binary wählen, bei der 7490 mit 6.30 gabs ja seinerzeit auch nicht die Notwendigkeit eines modularen Aufbaus?

    Jemand ne Idee wie man das hinbekommt?

    Danke
    CKone
     
  2. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    943
    Zustimmungen:
    12
    Punkte für Erfolge:
    18
    Weder in den letzten Labors noch in der 07.XX-Release-Version ist es möglich das tun-Modul zu bauen (die Aussage gilt für alle GRX5-Boxen). Daher kann ich Deine Aussage "beim letzten Labor gehts ja auch" nicht nachvollziehen.

    Auch das statische Linken von OpenVPN ist weiterhin möglich. Oder andersrum auch diese Aussage kann ich nicht nachvolziehen.
     
  3. Whoopie

    Whoopie Aktives Mitglied

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    812
    Zustimmungen:
    3
    Punkte für Erfolge:
    18
  4. f666

    f666 Neuer User

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    135
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    Ich habe mir die Änderungen noch nicht im Kontext des ganzen Moduls angesehen, aber kann man die beiden BUG_ON Zeilen nicht wieder löschen (versuchen)?
     
  5. Whoopie

    Whoopie Aktives Mitglied

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    812
    Zustimmungen:
    3
    Punkte für Erfolge:
    18
    Ja, hatte ich auch schon überlegt. Wir brauchen aber erst einmal "replace kernel", dann kann man das testen.
     
  6. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    10,674
    Zustimmungen:
    456
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Was genau verhindert das? Die Quellen für die 7590 sind doch verfügbar ...

    Meines Erachtens sollte man stattdessen aber ohnehin erkunden, wie da ein "sk_buff" ohne passenden Socket (also ohne "Besitzer") auftauchen kann, als "so empfangen" (ja, in welchem Kontext denn bitte?) ... das ganze Recycling von "sk_buff"-Strukturen ist ja auch eine Lantiq-Spezialität (FAST_SKB und SKB_RECYCLE), die AVM m.E. gar nicht nutzt und da wäre für mich dann doch wieder die Frage, warum vom "tun"-Device eine solche Struktur ohne "sk"-Member überhaupt übergeben wird oder ob die nicht bei irgendeinem PA-Hook in der weiteren Verarbeitung einfach nur falsch interpretiert wurde (die werden ja teilweise auch rein zum Zählen von Paketen aufgerufen) und als "beschleunigt, damit bereits erledigt" abgehakt wird, woraufhin dann der Buffer fälschlicherweise "orphaned" wird und hier aber trotzdem weiterhin in den Mühlen der Verarbeitung verbleibt.

    Ansonsten wird in "tun.c" ein solcher "sk_buff" ja nur dann "orphaned" (und zwar absichtlich), wenn er erfolgreich gesendet wurde und da wäre dann die Frage, wie der es wieder in irgendeine Receive-Queue geschafft haben soll mit seinem Socket == NULL.

    Was man mal testen könnte (zur Eingrenzung des Fehlers), wäre die Reaktion des Systems mit unterschiedlichen Stufen der Paket-Beschleunigung ... bei den neuen Versionen ist die ja über die Support-Seite zu steuern. Tritt das Problem dann nicht auf, liegt es vermutlich wirklich an irgendeinem der AVM-Hooks, die da alle mit "avm_pa_irgendwas" beginnen.

    Wenn das dann doch keinen Hinweis liefert, bräuchte man mal einen echten Stack-Trace und vielleicht noch ein paar printk-Erweiterungen vor diesem "BUG_ON", damit man z.B. einen Hex-Dump des "sk_buff" mal sieht und erkennen kann, woher der kommt (AVM packt ja zusätzlich noch das Source-Device in den Header) und wohin er eigentlich gehen sollte ... dann kann man auch besser verfolgen (in Kombination mit dem Stack-Trace), wo hier der eigentliche Fehler liegt.

    Was nutzt es einem, wenn man die "BUG_ON"s von AVM wieder entfernt und dann stürzt es irgendwo dahinter ab, weil "sk_buff->sk" der Pointer auf die "sock"-Struktur sein soll (und nicht noch einmal geprüft wird, z.B. bei irgendwelchen Konstrukten, die dann über mehrfache Pointer-Referenzen auf "sock"-Member zugreifen wollen - ein "grep" mit "->sk->" über die Sourcen zeigt schnell, daß es solche Stellen gibt - auch wenn natürlich damit nicht auf den ersten Blick geklärt ist, ob da nicht noch eine Abfrage davor erfolgt ist) und es aber nicht ist ... so ganz aus Jux und Tollerei wird AVM das da vorne nicht eingebaut haben, immerhin kann man dann anhand des Stack-Traces noch sehen, wie dieser "sk_buff" seinen Weg zu der Stelle fand.
     
  7. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    943
    Zustimmungen:
    12
    Punkte für Erfolge:
    18
    #7 er13, 14 Aug. 2018 um 19:36 Uhr
    Zuletzt bearbeitet: 14 Aug. 2018 um 19:52 Uhr
    Peter, Du hast da a bisserl was missverstanden.

    AVM hat an 2 Stellen die Zeile
    Code:
    BUG_ON(skb->sk);
    
    eingebaut (BUG_ON Doku). D.h. sie erwarten, dass der Socket eben nicht gesetzt ist.

    An einer anderen Stelle haben sie die Zeilen eingebaut
    Code:
    if (unlikely(skb->sk))
            goto drop;
    
    (s. LikelyUnlikely Doku). D.h., wenn der Socket gesetzt ist, dann soll sowas nicht weiter geforwarded, sondern gedropped werden.

    Der BUG_ON ist definitiv völliger Schwachsinn, aber scheinbar schlägt die Assertion beim AVM-Code nicht fehl, da eben alles mit AVM_PA am eigentlichen Network-Stack vorbei geschleust wird.

    Edit: es ist für mich echt ein Rätsel, wie man diese Missgeburt namens AVM_PA überhaupt ernsthaft der IT-Welt zeigen kann und dabei auch noch als eine Optimierung verkaufen kann. Denn die Optimierung von AVM_PA bestünde darin, dass alle Daten (von irgendeinem Device) direkt an die diese Daten verarbeitentenden "Empfänger" weitergereicht werden. Und direkt heißt an der Stelle - an dem gesamten Network-Stack vorbei. Grüße Richtung OSI-Modell, auch, wenn man dieses in seiner reinen Form nie umgesetzt hat.
     
  8. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    10,674
    Zustimmungen:
    456
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @er13:
    Stimmt, ich Rindvieh habe die Berichte über die Assertion genau falsch herum interpretiert und gar nicht nach dem konkreten "BUG_ON"-Statement geschaut, sondern mich nur mit den denkbaren Folgen befaßt, wenn so ein "sk_buff" tatsächlich "orphaned" wäre und das nicht richtig geprüft wird beim Zugriff.

    Das macht es ja noch rätselhafter ... dann müßte ja auch bei abgeschalteter Paketbeschleunigung so ein Paket (beim Empfang der Daten) immer noch irgendwie durch den PA-Code, damit die Assertion auch bei AVM-Code nicht greift.

    Der Witz am TUN-Device ist es ja, daß da eigentlich keine PA-Session mit verbunden sein kann (zumindest nicht beim unverschlüsselten Traffic), denn die Pakete müssen ja über die CPU gehen und entsprechend verschlüsselt werden ... was hat so eine Verbindung dann mit dem PA überhaupt zu tun?

    Ich schaue mir das noch mal an, diesmal aber etwas gründlicher als zuvor ... das ist ja reichlich blamabel, was ich mir da als "Fehltritt" geleistet habe.
     
  9. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    943
    Zustimmungen:
    12
    Punkte für Erfolge:
    18
    Nur die Ruhe, kann jedem passieren ;)

    Und auf die Frage, warum es denn immer noch kein Replace-Kernel für die GRX5-Boxen gibt (obwohl die Sources ja verfügbar wären), folgende Antwort:

    Das kernel.image hat bei den GRX5-Boxen ein neues (EVA-)Format, welches lzma2eva noch nicht beherrscht. Bzw. ich würde es gar nicht lzma2eva beibringen wollen, sondern ein neues Tool dafür schreiben, so wie f-666 es für die Kabel-Boxen gemacht hat (s. r14809).

    In dem kernel.image von GRX5-Boxen sind 2 Kernels enthalten:
    • der erste ist der, der uns eigentlich interessiert und den wir hoffentlich (insbesondere im Sinne der avm_kernel_config_area) bauen können.
    • und der zweite (wo ich schon vergessen habe, wofür er überhaupt da ist, aber Peter kann mir bestimmt auf die Sprünge helfen), für den wir keine Quellen haben. Der denkbare Ansatz bei diesem wäre es diesen 1-zu-1 aus AVM's kernel.image zu übernehmen. Dafür müssten wir ihn extrahieren können. Das unpack-kernel Script kann es schon.

    Es fehlt also nur das Tool, welches den selbstgebauten 1.ten Kernel und den extrahierten 2.ten Kernel in dem richtigen Format wieder "zusammenpackt".

    Das neue "2-Kernel-Format" ist, soweit ich mich erinnern kann, nirgends vernünftig dokumentiert, kann aber dem unpack-kernel abgelesen werden.
     
  10. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    10,674
    Zustimmungen:
    456
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Der zweite Kernel ist (meiner Theorie zufolge und auf der Basis der Tatsache, daß er wohl bei allen drei GRX-Boxen exakt derselbe ist) wohl so etwas wie der "Hypervisor" für die Virtualisierung des GRX500, der dann erst den zweiten Kernel startet (auspacken wird ihn vermutlich der Bootloader, aber auch das könnte theoretisch der erste Kernel übernehmen). In den Quellen hört das Ganze m.W. auf den Namen "BOOTCORE" (man kann wohl sogar die serielle Console zwischen beiden "Systemen" hin- und herschalten, dem Code nach zu urteilen) und es sollte sich - rein theoretisch - sogar mit diesem Symbol ein passender Kernel übersetzen lassen, denn das hatte ich sogar irgendwo in einem Makefile als Target (mit entsprechend weniger Modulen beim Linken) gesehen - alles ohne Gewähr und aus dem Kopf.
    Code:
    user@host:/tmp/GPL/linux$ grep -r BOOTCORE
    init/main.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/main.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/initramfs.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/initramfs.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/boot/dts/Fritz_Box_HW0225-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0239.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0221-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0225.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226-100.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/easy350_anywan_bootcore.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Makefile:ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/boot/dts/Fritz_Box_HW0221-255.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0221.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0239-255.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/lantiq/Platform:      ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Platform:              ifdef CONFIG_BOOTCORE_LOAD_ADDR
    arch/mips/lantiq/Platform:                      load-$(CONFIG_LANTIQ)           = $(CONFIG_BOOTCORE_LOAD_ADDR)
    arch/mips/lantiq/Platform:cflags-$(CONFIG_SOC_GRX500_BOOTCORE)           += -I$(srctree)/arch/mips/include/asm/mach-lantiq/grx500
    arch/mips/lantiq/Kconfig.grx5:if GRX5 || SOC_GRX500_BOOTCORE # == SOC_GRX500 (?)
    arch/mips/lantiq/avm_switch_console.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Kconfig:config SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Kconfig:       bool "GRX500_BOOTCORE"
    arch/mips/lantiq/Kconfig:       depends on SOC_GRX500_BOOTCORE
    arch/mips/lantiq/grx500_bootcore/timer.c:       if (irq == GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX)
    arch/mips/lantiq/grx500_bootcore/timer.c:       else if (irq == GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX)
    arch/mips/lantiq/grx500_bootcore/timer.c:       grx500_bootcore_register_static_irq(GRX500_BOOTCORE_GPTC2_TIMER2_IN_INDEX,
    arch/mips/lantiq/grx500_bootcore/timer.c:                                               GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX, &gptc2_timer2_irqaction,
    arch/mips/lantiq/grx500_bootcore/timer.c:       grx500_bootcore_register_static_irq(GRX500_BOOTCORE_GPTC2_TIMER1_IN_INDEX,
    arch/mips/lantiq/grx500_bootcore/timer.c:                                               GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX,
    arch/mips/lantiq/grx500_bootcore/irq.c:        irq_mask = (1<<GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_TIMER_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:#ifdef GRX500_BOOTCORE_DEBUG_UART
    arch/mips/lantiq/grx500_bootcore/irq.c:#ifdef GRX500_BOOTCORE_DEBUG_UART
    arch/mips/lantiq/grx500_bootcore/irq.c:        .name     = "Lantiq GRX500_BOOTCORE Ext IRQ Controller",
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX/*0x1*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX/*0x3*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX/*0x4*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:                 do_IRQ(GRX500_BOOTCORE_MPS2_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:                if ((irq!= GRX500_BOOTCORE_SYNOP_ETHER_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                        (irq!= GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                            (irq!= GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                                (irq!= GRX500_BOOTCORE_WIRELESS_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                                    (irq!= GRX500_BOOTCORE_TIMER_IRQ_IN_INDEX))
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#undef GRX500_BOOTCORE_DEBUG_EARLY
    arch/mips/lantiq/grx500_bootcore/early_printk.c:        divisor = ((GRX500_BOOTCORE_SYSTEM_CLK) / (UART_BAUD_RATIO_DIV*baud)) - 1;
    arch/mips/lantiq/grx500_bootcore/early_printk.c:                divisor = ((GRX500_BOOTCORE_SYSTEM_CLK/10) / (UART_BAUD_RATIO_DIV*baud)) - 1;
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#ifdef GRX500_BOOTCORE_DEBUG_EARLY
    arch/mips/lantiq/Makefile:obj-$(CONFIG_SOC_GRX500_BOOTCORE) += grx500_bootcore/
    arch/mips/lantiq/Makefile:obj-$(CONFIG_SOC_GRX500_BOOTCORE) += avm_switch_console.o avm_hw_config.o
    arch/mips/Kconfig:        select CPU_MIPSR2_IRQ_VI if SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:        select CPU_MIPSR2_IRQ_EI if SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:        select SYS_SUPPORTS_LITTLE_ENDIAN if SOC_GRX500 || SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      select SYS_SUPPORTS_MULTITHREADING if !SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      select SYS_HAS_EARLY_PRINTK if !SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      depends on SOC_GRX500 || SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      depends on SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:config BOOTCORE_LOAD_ADDR
    arch/mips/Kconfig:      depends on SOC_GRX500_BOOTCORE
    arch/mips/kernel/head.S:#if defined(CONFIG_SOC_GRX500)||defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/kernel/setup.c:#if !defined(CONFIG_OF_AVM_DT_ENV) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/Makefile:ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/Makefile:cflags-$(CONFIG_SOC_GRX500_BOOTCORE) += -mno-dsp
    arch/mips/include/asm/mach_avm.h:#if !defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/include/asm/mach_avm.h:#if defined(CONFIG_SOC_GRX500) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/include/asm/mach-lantiq/cpu-feature-overrides.h:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET       0x001c0000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SYS_RESET_REG_OFFSET         0x00000008
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SPI_MODE_ADDR                (MT_LOCAL_MIPS_BASE_ADDRESS+0x130)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SPI_MODE_SW_BIT              (0x400) //When this bit is set, FLASH is accessed in SW mode
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_RESET_OFFSET                 8
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_RESET_ADDR                   (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_RESET_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_REBOOT_DATA                  0
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_REBOOT_BIT_MASK_NOT          0xfffeffff
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SHARED_GMAC_BASE_ADDR        (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_REG_OFFSET         0x68
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_REG_ADDR           (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_GMAC_MODE_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_2_REG_OFFSET       0x80
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_2_REG_ADDR         (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_GMAC_MODE_2_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_DLY_PGM_REG_OFFSET           0x64
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_DLY_PGM_REG_ADDR             (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_DLY_PGM_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_OFFSET  0x90
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_ADDR    (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#ifndef __GRX500_BOOTCORE_TIME_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define __GRX500_BOOTCORE_TIME_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:/*for real system undefine GRX500_BOOTCORE_SCALE_DOWN*/
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_DOWN
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#ifdef GRX500_BOOTCORE_SCALE_DOWN
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_VAL 10
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_VAL 1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK  6000000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     6000000; //480000000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK CLOCK_300M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK    CLOCK_300M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK  (24000000*GRX500_BOOTCORE_SCALE_VAL)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     (48000000*GRX500_BOOTCORE_SCALE_VAL)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     (GRX500_BOOTCORE_SYSTEM_CLK *system_to_cpu_multiplier)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:/* Note - the timer used is GRX500_BOOTCORE, run 24000000M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:* If we use the MIPS timer, change to  GRX500_BOOTCORE_CPU_CLK
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h://#define TICK_DIV (GRX500_BOOTCORE_CPU_CLK/HZ)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define TICK_DIV (GRX500_BOOTCORE_SYSTEM_CLK/HZ)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#endif /* __GRX500_BOOTCORE_TIME_H__ */
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#ifndef __GRX500_BOOTCORE_INTERRUPT_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define __GRX500_BOOTCORE_INTERRUPT_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX       28
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_TIMER_IRQ_IN_INDEX        28
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_IN_INDEX  1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_IN_INDEX  3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_WIRELESS_IRQ_IN_INDEX     9
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX      8
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_TIMER_IRQ_OUT_INDEX       2
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX 3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX 3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX 4
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX    5
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER2_IN_INDEX      1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX     9
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER1_IN_INDEX      3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX     10
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_MPS2_OUT_INDEX  11
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#endif /* __GRX500_BOOTCORE_INTERRUPT_H__ */
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define PORT_GRX500_BOOTCORE    82
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define GRX500_BOOTCORE_BASE_BAUD (GRX500_BOOTCORE_SYSTEM_CLK / UART_BAUD_RATIO_DIV)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define GRX500_BOOTCORE_UART_IRQ        1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h://GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:        { 0, GRX500_BOOTCORE_BASE_BAUD, UART_BASE, GRX500_BOOTCORE_UART_IRQ, STD_COM_FLAGS },   /* ttyS0 */
    arch/mips/lib/avm_membench.c:#elif defined(CONFIG_SOC_GRX500_BOOTCORE)
    avm/conf/linux-3.10.grxB5:CONFIG_SOC_GRX500_BOOTCORE=y
    avm/conf/linux-3.10.grxB5:CONFIG_BOOTCORE_LOAD_ADDR=0xFFFFFFFF8E000000
    avm/conf/linux-3.10.grxB5:CONFIG_SERIAL_GRX500_BOOTCORE_CONSOLE=y
    avm/conf/linux-3.10.grx5:# CONFIG_SOC_GRX500_BOOTCORE is not set
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    drivers/crypto/Kconfig.grx500:   depends on LANTIQ && SOC_GRX500_BOOTCORE
    drivers/tty/serial/Kconfig:config SERIAL_GRX500_BOOTCORE_CONSOLE
    drivers/tty/serial/Kconfig:     depends on LANTIQ && SOC_GRX500_BOOTCORE
    drivers/tty/serial/Makefile:obj-$(CONFIG_SERIAL_GRX500_BOOTCORE_CONSOLE) += grx500_bootcore-uart.o
    drivers/tty/serial/grx500_bootcore-uart.c:              divisor = ((GRX500_BOOTCORE_SYSTEM_CLK) / (16*baud)) - 1;
    drivers/tty/serial/grx500_bootcore-uart.c:        divisor = ((GRX500_BOOTCORE_SYSTEM_CLK/GRX500_BOOTCORE_SCALE_VAL) / (16*baud)) - 1;
    drivers/tty/serial/grx500_bootcore-uart.c:      grx500_bootcore_register_static_irq(GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX, GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX, &uart_irqaction, grx500_bootcore_uart_irq);
    drivers/tty/serial/grx500_bootcore-uart.c:    //grx500_bootcore_enable_irq(GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX); huanx
    drivers/tty/serial/grx500_bootcore-uart.c:#define GRX500_BOOTCORE_CONSOLE       &grx500_bootcore_console
    drivers/tty/serial/grx500_bootcore-uart.c:   .type       = PORT_GRX500_BOOTCORE,
    drivers/tty/serial/grx500_bootcore-uart.c:      .cons                   = GRX500_BOOTCORE_CONSOLE,
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_BOOTCORE "avm_cpunet_tep"
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_SELF MPS_MEMPOOL_NAME_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_OTHER MPS_MEMPOOL_NAME_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:                                        GRX500_BOOTCORE_MPS2_OUT_INDEX,
    drivers/char/Kconfig:        depends on SOC_GRX500 || SOC_GRX500_BOOTCORE
    drivers/char/Makefile:ifeq ($(CONFIG_SOC_GRX500_BOOTCORE),y)
    drivers/watchdog/Kconfig:config GRX500_BOOTCORE_WDT
    drivers/watchdog/Kconfig:        depends on SOC_GRX500_BOOTCORE
    drivers/watchdog/Makefile:obj-$(CONFIG_GRX500_BOOTCORE_WDT) += bootcore_wdt.o
    drivers/watchdog/bootcore_wdt.c:        .identity = "Hardware Watchdog for BOOTCORE",
    drivers/watchdog/bootcore_wdt.c:MODULE_DESCRIPTION("GRX500 BOOTCORE Watchdog Driver");
    kernel/printk.c:#if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    kernel/printk.c:#endif/*--- #if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE) --- */
    kernel/printk.c:#if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    kernel/printk.c:#endif/*--- #if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE) --- */
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    
    Dieser "boot core" arbeitet auch mit einer "avm_kernel_config", aber mit einer statischen, die offenbar bei allen Modellen und in allen Versionen (vor 07.00, weil sich mit dem Linux-Kernel sicherlich auch das Image geändert hat) dieselbe war.

    Wenn ich mich richtig erinnere, gibt es doch noch so etwas wie einen "äußeren Header" mit einer Signatur, der die beiden Kerne in der "kernel.image" von AVM "umschließt"? M.E. müßte es (für erste Tests per Hand) schon ausreichen, den "echten" Kernel auszutauschen bzw. dem "lzma2eva" eine Kombination aus dem gepackten, eigenen Kernel und dem zweiten Image anzubieten und dann diesen Header entsprechend anzupassen (ist halt von Hand etwas Rechnerei).

    Irgendwo hier müßte es nach meiner Erinnerung auch noch einen Thread geben, wo das Thema war, nachdem @er13 den zweiten Header in den Daten gefunden hatte und die Länge im ersten Header nicht mit der Gesamtgröße des Images übereinstimmen wollte.
     
  11. f666

    f666 Neuer User

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    135
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
  12. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    10,674
    Zustimmungen:
    456
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin