7390 as alien on 7340

Hi all

I was under the impression 7340 uses pretty much the same hardware as the 7390 (same big endian chipset etc), just like the 7240 was very similar to the 7270
So I was a little surprised just now to find there was no 'alien' option in Freetz 1.2

Is that omission with a reason, or is it more that no-one tried it yet?
Can I expect big problems if I try to put 7390 onto 7340 hardware? Will the missing So port cause bootloops?

Thanks

That's OK, I know my way around a serial console/TTL-RS232-USB cables.
Though if you happen to have a link to the pinout/location of the console header...

Mind you, I will only play with this next week, the 7340 is still in use at this moment.

The 7340 is quite common here in NL, one of the big providers is using it as their default box. They used to give out 7390 for a short while, but I guess they bulk ordered the budget model.

Well, it did not work.

I did attach a console, and I used ruKernelTool to do the flashing.
In fact, after a pure 7390 went loopy, I even made 7340 from 7390 5.5X source by tweaking Config.in to allow so.
(after all, if you check config.in, the normal 7340 is also compiled with 7390 5.2X)
But that responded the same as the real 7390 image.

One of the real Freetz developers will have to look into properly making an 7390 on alien 7340 hardware. If they feel like it and have time. But I guess with the 7340 being rare in Germany (though plentyful in NL, at €40 for a box pre-owned) I guess that is not very likely.



Anyway, here is some info I gathered:

Full logs attached below, but here are some sections of the bootlog that I deemed interesting from the broken boot

No NAND device found!!!
[direct_avm_nand_probe] no nand chips found?
.
[module-alloc-by-name] no kseg0-space for module 'opensrc_lkm' (0x1000 bytes) -> use ksseg
[module-alloc-by-name] no kseg0-space for module 'bmedrv' (0x2000 bytes) -> use ksseg
.
modprobe: module nand not found in modules.dep
.
.
.
[module-alloc-by-name] no kseg0-space for module 'Piglet_noemif' (0x8000 bytes) -> use ksseg
[piglet]use gpio-settings for 171
patch_dectfw: c139c000, totallen = 67768(108b8)
patch_dectfw: patch_adress: f00a0 max_len: 26 with Version 2 Len: 17
dect_loader: fast-bootmode
*
*****************************************************************************************system-load 4 curr: busybox runnable: 6
*******************************************
dect144xx_file_process: upload of '/lib/modules/dectfw_secondlevel_488.hex' successfull
[piglet]bitfile '/lib/modules/bitfile.bit'
[piglet] try to preload in progress-context: /lib/modules/bitfile.bit
XBIT_EndONE didn't went high
[piglet] Failed: write data im fastmode - retry slow
XBIT_EndONE didn't went high
[piglet] Failed: write data
Call Trace:
[<80024df8>] dump_stack+0x8/0x34
[<8003eabc>] panic+0x44/0x220
[<c130478c>] init_module+0x78c/0x990 [Piglet_noemif]
[<8001b2bc>] do_one_initcall+0x5c/0x198
[<80064dc8>] sys_init_module+0xb0/0x1bc
[<80012ba4>] stack_done+0x20/0x3c

Kernel panic - not syncing: [piglet]panic: cant' load bitfile /lib/modules/bitfile.bit

Rebooting in 5 seconds..system-load 7 curr: busybox runnable: 6

disabling IRQ's and enabling reset bit in all AP's

Zum Vergrößern anklicken....

The "No NAND device found!!!" seems interesting, but in fact is also on the working factory 7340, so it not so interesting at all.
See the same parts in the real 7340

[NAND] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[NAND] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[NAND] !! MT29F4 erkannt, konnte aber den Hardware-ECC nicht aktivieren -> nutze SW-ECC !!
[NAND] !! -Fallback-Layout wird genutzt, welches ein Lesen der Daten erlaubt !!
[NAND] !! -YAFFS wird trotzdem massenhaft Warnungen auswerfen -> ECC stimmt halt nicht !!
[NAND] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[NAND] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No NAND device found!!!
[direct_avm_nand_probe] no nand chips found?

PigletMode: 0
[piglet]use gpio-settings for 171
patch_dectfw: C1BB9000, totallen = 70047(1119F)
patch_dectfw: patch_adress: F1038 max_len: 26 with Version 2 Len: 17
dect_loader: fast-bootmode
*
****************************************************************************************************************************************
dect144xx_file_process: upload of '/lib/modules/dectfw_secondlevel_488.hex' successfull
[piglet]bitfile for autodetect '/lib/modules/bitfile_isdn.bit'
[piglet] try to preload in progress-context: /lib/modules/bitfile_isdn.bit
[piglet] bitfile 72761 bytes done
[piglet] "wyatt_earp_unload_xilinx" loaded
[piglet]-> POTS-Mode
[piglet] use preload[0] /lib/modules/bitfile_pots.bit
[piglet] bitfile 72761 bytes done
[pcmlink]svn: 1552

Zum Vergrößern anklicken....

Attached the broken boot, the working original boot, and a diff file of Config.in and Config.in.has_avm that I used to generate an image, though it should be stated a factory 7390 responded the same.
Anhang anzeigen 7390_brokenboot.txt
Anhang anzeigen 7340_cleanboot.txt
Anhang anzeigen 7340patch.txt
Anhang anzeigen 7340_05.50-freetz-devel.de_20130130-153837.image.config.txt

Cool.

Sorry, I was sort of waiting for this, but I was expecting the forum to give me a heads up when someone added to this thread. Not sure why it did not, it gives me emails on the other threads I made. So that is why I did not respond right away, but if it works, I would be very pleased. Especially the new 7390 trunking function is what I would like to have.

I will try it out today even.


Edit: Hmm, no kernel recompile and no labor, I guess you want to check the international kernel working first. But I will test and report back, and then patiently wait some more.

Ok, tested, and it works right out of the box, except WiFi.

Also of course, no labor or SIP trunking yet.
But thanks for the work olistudent!


Regarding WiFi

It appears to work from the GUI, but it is not actually transmitting. And while the checkmark is set on the GUI, the LED is not on. Pressing the WiFi button makes the LED flash, but in the end it turns off again.

I think this may be because the 7340 does not have the dual 2.4 & 5 GHz frequencies. So probably another chip. For the rest it works, VDSL2, VoIP, Fax over VoIP, but if I am honest I cannot test actual FXO/FXS ports either, due to lack of analog line or phone.

After reflashing a fresh 7340 non-alien build OS5.51, everyting is normal again.

Some websites claim the 7340 also have both 2.4 and 5 GHz, but to be honest I do not see any control possibilities for the 5GHz one like I see in the 7390 firmware. So either it does not have 5GHz, or it cannot be turned on/off separately.

Let me know olistudent if you want me to try something else, or if you need boot logs or anything.

Thanks

I've always run all my Fritz on German, and I've always done my Annex switches from bootenv.

You need lsmod and dmesg from the original 7340 or the alien 7390? I am currently back on the original 7340 5.51, but I can flash again
(after I am done with work, I am running a remote support session this evening)

Edit:
Which reminds me if I load the German, I probably have to set the urlader to avm instead if avme. I always wondered, is that done automatic if I choose the "Enforce urlader environment" option?

Attached the lsmod and dmesg of the clean 7340 and the 7390-on-alien-7340

Anhang anzeigen logs from 7390-alien.txt Anhang anzeigen logs from 7340.txt

Any other logs you want?

I am travelling for work, so I will not have physical access and cannot reflash, but its still running 7390 at the moment (I do not really need WiFi, I am a 'wired is better' freak)

If you want, I can give you OpenVPN to the box, I got a couple of spare users that I can retract later.

I was stupid. The log you have from the 7390-on-alien-7340, I believe I had earlier that day actually simply turned of WiFi. So the device would not even try to start it anymore. After-all, why make the device go through the trouble if it will only fail. But of course that makes the logs a lot more empty then they should.

So I turned on the WiFi checkmark again, and rebooted, and now the logs do mention "ath" quite a bit more.

Sorry for the mess-up

Anhang anzeigen logs from 7390-alien2.txt

Hi Olistudent

You did not perhaps get some new idea's on this matter?

If we cannot get the 7390 to work on 7340, would it be possible to somehow lift the Fax and Trunking functions and transplant them into the 7340?

Thanks

Sorry man, I did not mean to push. It was just a non-committing 'any news?' inquiry.
I actually maintain firmware for some Chinese Clone Androids, so I know how difficult users can be. And on this forum, I guess I am one of those difficult users, sorry.

---

Anyway, I was not sitting still myself, and I got the WiFi to work on the 7390-on-7340. Its actually not that hard: Copy the /filesystem/etc/default.Fritz_Box_7340/avme/wlan* files from original 7340 to the new clone. So I modded your 100-7340_7390.sh script thus:
(first two lines are yours, the next two I added)


Maybe you can suggest how to clean it up, because as you see above code depends on me first making a safe copy of a clean 7340 build into a build7340 folder. I suspect the files probably do exist already in some ${xxxx} pointed folder, but I could not find it.

The reason WiFi did not work is the 7390 has two Atheros WiFi chips, one 9220 used for 5GHz and one 9223 for 2.4GHz. The 7340 has only the one 9220. It should still work, if the 7390 would address the 9220 for 2.4GHz, but alas, 7390 uses 9223 for 2.4GHz. This is visible if you read the header of wlan_product.cfg file where two chips are declared for the 7390.

After the mod, settings in the web config for 5GHz are best ignored. I was not able to get 5GHz to work. But 2.4GHz does work.
Guest AP also seems to work. Wlan-scan (finding other nearby AP) does not seem to work. I did not test WDS or WPS
Further disclaimer: I did not test ISDN or POTS. I did test DECT and VOIP and FAX and VDSL2 annex A (but not ADSL or annex B)
But with those restrictions, the 7390_on_7340 seems very viable. For me at least.


Small additional note: The current Freetz tree assumes 5.22 source for 7340, but 5.51 is out and 5.22 can not be downloaded anymore. So I had to also change the source and source_md5 in the Config.in:


Thanks !