PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,752
- Punkte
- 113
Are you sure, you haven't mixed up something?
According to the support data file from #73 (https://www.ip-phone-forum.de/threads/freetz-für-avm-dvb-c-repeater-verfügbar.307070/post-2440840) - which was from 07.01 firmware due to the contained head lines - this firmware version HAS a NMI vector table; from section "debug Kernel output" (so also from the right place, because this part is from the running system):
(starting from line 7360).
At the file
(line 29).
Where has it gone to? Didn't you prepare the firmware image again with a NMI vector, after you've changed filesystem's content? That's one reason, why I've proposed some scripts to automate those tasks.
If kernel's log buffer is too small to keep all messages until saving them in
It may look a bit annoying to you, if the efforts to get log files are growing - but it's in a matter of the very first actions of kernel, where it's setup will be done.
Meanwhile the data from
We're looking for the parameters/settings used for the LAN-PHY (
is from function
the FDT (FDT (flattened device tree) and DT (device tree) and some other terms are (most times) aliases for the same thing) from address 0x804cbeb0 is used and this is (shown here: https://www.ip-phone-forum.de/threads/freetz-für-avm-dvb-c-repeater-verfügbar.307070/post-2440340) for
Do you grasp, why a comparison of the FDTs could have been so important?
But thinks are even getting weirder - I had a look into
But the (DTS) source files for DVB-C repeater and 1750E are completely different - it's not an option to simply compare those sources. AVM has invented a new approach to control the "human user interface" called
If there's no (sure) difference in hardware layout (Who claimed first to have detected one?), it's not expedient anymore, to modify the kernel. I've started reading (late) about the original problem at the point, where your question regarding the compilation/usage of a different DTS file arised.
Maybe it's a more promising approach to look further, why the WLAN hardware isn't started with the 1750E's firmware - possibly it's sufficient to modify the WLAN configuration (I've mentioned it earlier in the thread, too, it's in the files from
and if I look at those messages, it doesn't look as wrong as expected. Quite the contrary - it looks like the hardware was initialized successfully and even the EEPROM data was found - up to this point the WLAN hardware initialization looks fine in my opinion.
Let's put the last attempts on side (at least yet) and have a look at the "original" problem ... to get a clue, what's going wrong (and when), I want to get the output of
Maybe you've shown this elsewhere already - but please accept, I'll not search (certainly not for old logs), I want to read the most current logs, freshly created and with a description, which firmware was used. And if you create an image file with a modified filesystem (you will do this to get shell access), don't forget to add the NMI table again. Maybe this is absolutely unnecessary - but we don't know this for sure and it's one of the smaller efforts, we're faced with.
According to the support data file from #73 (https://www.ip-phone-forum.de/threads/freetz-für-avm-dvb-c-repeater-verfügbar.307070/post-2440840) - which was from 07.01 firmware due to the contained head lines - this firmware version HAS a NMI vector table; from section "debug Kernel output" (so also from the right place, because this part is from the running system):
Code:
[ 0.330062] no support for hwid 205
[ 0.333511] [avmnet] [avmnet_cfg_init] Driver version: 6.299-maca_jz52433Wed Oct 31 11:51:39 CET 2018
[ 0.343050] [find_nmi_vector] nmi vector found. Firmware length 0xbcef5e bytes (erase block align 0xbd0000) vector gap size 0x1000 bytes.
[ 0.355498] [find_nmi_vector] add 'urlader' size 0x20000 to length
[ 0.361736] [ath_flash] NMI GAP start=0x00c00000 size=0x00001000 end=0x00bf0000At the file
debug_DVB-C.7.01.txt (https://www.ip-phone-forum.de/attachments/debug_dvb-c-7-01-txt.112849/) it looks a bit different - the debug log contains some more messages than kernel log, but the module name in front of the message (find_nmi_vector) assures, it's the same place:
Code:
[ 0.338712] [find_nmi_vector] no nmi vector foundWhere has it gone to? Didn't you prepare the firmware image again with a NMI vector, after you've changed filesystem's content? That's one reason, why I've proposed some scripts to automate those tasks.
If kernel's log buffer is too small to keep all messages until saving them in
rc.net, you can add the command to a script, that's executed earlier - you should make sure only, that /var has been mounted already. One of the very first (shell) scripts run at startup is /etc/boot.d/core/head for systems using systemd and /etc/init.d/S01-head for rc.S approach - it's nearly the same point of initialization, which's reached there. You may append the command on those files - and if it's still too late for a rc.S-based system (systemd-based startup is a bit faster), you may move this command any further to rc.S, somewhere after tmpfs was mounted on /var.It may look a bit annoying to you, if the efforts to get log files are growing - but it's in a matter of the very first actions of kernel, where it's setup will be done.
Meanwhile the data from
/sys/firmware was published - did you try yourself to extract them on a system and compare the trees with diff or something else? Are there really any differences with the "structured" data?We're looking for the parameters/settings used for the LAN-PHY (
ath8033) - a "powerdown" attempt for this part is failing with the modified 07.27 firmware. The error message:
Code:
[ 1.408638] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.setup_phy() in drivers/net/avm_cpmac/phy/avmnet_ar8033.c - it contains an attempt to reset the PHY first (using function reset_phy()), what's done by toggling a GPIO pin. The most probable assumption at this place is, that the wrong GPIO pin gets toggled - either our modifications regarding the FDT are wrong or the automatically selected HWSubrevision from 1750E's firmware uses the same allocations (otherwise it's not explainable, why the unmodified version may initialize the PHY) as the DVB-C model. According to this line from dmesg_1750E_original.txt (https://www.ip-phone-forum.de/attachments/dmesg_1750e_original-txt.112845/):
Code:
[ 0.000000] DT @ 804cbeb0: d0 0d fe ed 00 00 1f 38HWSubrevision 0 of 1750E devices.Do you grasp, why a comparison of the FDTs could have been so important?
But thinks are even getting weirder - I had a look into
arch/mips/boot/dts directory and if there aren't much more missing files, there's no difference in the hardware layout of ALL HWSubrevision - all of them use a shared hardware description from the same file. The only difference is the subrevision member of the avm-hw-revision structure (or section):
Code:
--- Fritz_Box_HW206-0.dts 2021-02-04 18:41:59.000000000 +0100
+++ Fritz_Box_HW206-7.dts 2021-02-04 18:41:59.000000000 +0100
@@ -27,6 +27,6 @@
avm-hw-revision {
compatible = "avm,avm_hw_revision";
revision = "206";
- subrevision = "0";
+ subrevision = "7";
};
};hui (that's at least my interpretation of this name) - it seems to be in charge of all LEDs and buttons (and surely more internal "events" regarding interface actions). This part is completely missing from the (older) DVB-C configuration sources - what makes it impossible, to compile this DTS file simply and to use it instead of the original one for 1750E.If there's no (sure) difference in hardware layout (Who claimed first to have detected one?), it's not expedient anymore, to modify the kernel. I've started reading (late) about the original problem at the point, where your question regarding the compilation/usage of a different DTS file arised.
Maybe it's a more promising approach to look further, why the WLAN hardware isn't started with the 1750E's firmware - possibly it's sufficient to modify the WLAN configuration (I've mentioned it earlier in the thread, too, it's in the files from
/etc/$CONFIG_PRODUKT/$OEM/wlan*) to select the right parameters. We know meanwhile (see a few paragraphs above), that this variant of firmware version and device selects the entries for HWSubrevision 0 (due to a missing sub-revision 2 - what's reported from urlader environment), but the WLAN "configurator" uses further sources:
Rich (BBCode):
[ 16.198414] [wlan_config] Given config is:
[ 16.198435] [wlan_config] hw_interface=0 chip_type=8 (scorpion) offload=1 (non)
[ 16.198447] [wlan_config] hw_interface=1 chip_type=11 (peregrine) offload=1 (non)
[ 16.198486] [avmnet] [link_work_handler] Link changed status 0x7460210
[ 16.203037] avm_net_trace: New net trace device 'WLAN Management Traffic' registered with minor 128.
[ 16.203438] [wlan_config] HWRevision now 205
[ 16.203468] [wlan_config] HWSubRevision now 2
[ 16.203507] [wlan_config] maca now 5c:49:79:4f:a8:8e
[ 16.204065] avm_net_trace: udev device avm_net_trace128 created
[ 16.255627] [wlan_eeprom] EEPROM1: Awaiting calibration data via char dev
[ 16.255798] [wlan_eeprom] New valid EEPROM1 loaded
[ 16.255811] [wlan_eeprom] EEPROM #1, type "AR93xx/AR95xx":
[ 16.255839] [wlan_eeprom] Customer data="DVBC_Repeater_CAL1_V"
[ 16.255880] [wlan_eeprom] MinCCAPwr thresh set to 2GHz:-70,-70,-70 5GHz:-1,0,0
[ 16.255888] [wlan_eeprom] Build with ART2 4.4
[ 16.255984] [wlan_eeprom] EEPROM2: Awaiting calibration data via char dev
[ 16.256053] [wlan_eeprom] New valid EEPROM2 loaded
[ 16.256062] [wlan_eeprom] EEPROM #2, type "QCA98xx":
[ 16.256086] [wlan_eeprom] Customer data="DVBC_Repeater_CAL2_V"
[ 16.256094] [wlan_eeprom] patching regDmnExt to enable ext chan 144 for fccLet's put the last attempts on side (at least yet) and have a look at the "original" problem ... to get a clue, what's going wrong (and when), I want to get the output of
cat /dev/debug after the problem occurred (as mentioned above, it's more than kernel messages only) - it should start (at least) with the lines shown above (to verify, whether the hardware was set up).Maybe you've shown this elsewhere already - but please accept, I'll not search (certainly not for old logs), I want to read the most current logs, freshly created and with a description, which firmware was used. And if you create an image file with a modified filesystem (you will do this to get shell access), don't forget to add the NMI table again. Maybe this is absolutely unnecessary - but we don't know this for sure and it's one of the smaller efforts, we're faced with.
Zuletzt bearbeitet:
Just busy days. I'll try to dig through #101 today if not fall asleep. 