Freetz für AVM DVB-C Repeater verfügbar?

PeterPawn · 11 Aug 2021

You've used the 7z format to create this file - nothing what an "usual" zip decoder may extract:

Rich (BBCode):

peh@vidar:/tmp/freetz-ng> unzip -l akc.zip
Archive:  akc.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
note:  akc.zip may be a plain executable, not an archive
unzip:  cannot find zipfile directory in one of akc.zip or
        akc.zip.zip, and cannot find akc.zip.ZIP, period.
peh@vidar:/tmp/freetz-ng>

The 7z programs can also create "real" zip archives (use -tzip as option).

EDIT;:
@baribal
As far as I can see, the changes are looking good - I would try to pack the kernel, copy kernel and filesystem together and flash the result ... if it will not work, you may reinstall any older firmware version. But I'd think, that the different hardware layout isn't a problem anymore - but surely without any warranty, that WLAN will work now.

@baribal:
And by the way ... mentioning someone while editing an already saved post again, doesn't create any new notification.

baribal · 11 Aug 2021

@PeterPawn

Unfortunately doesn't work: ( After flashing I see constant restarts.

I packed the kernel.image as following:

Code:

tools/lzma e ~/kernel.raw.unpacked.patched ~/kernel.raw.patched
tools/lzma2eva 0x80060000 0x80064870 ~/kernel.raw.patched ~/kernel.raw.patched.eva
cat ~/kernel.raw.patched.eva FRITZ.Repeater_1750E-07.27.image.unpacked/original/kernel/kernelsquashfs.raw >kernel.image

Original patched unpacked kernel:

Code:

-rw-r--r-- 1 freetz freetz 4988755 Aug 11 20:03 /home/freetz/kernel.raw.unpacked.patched

After lzma:

Code:

-rw-r--r-- 1 freetz freetz 1566096 Aug 11 20:16 /home/freetz/kernel.raw.patched

After lzma2eva:

Code:

-rw-r--r-- 1 freetz freetz 1566131 Aug 11 20:22 /home/freetz/kernel.raw.patched.eva

So added the required bytes for EVA to handle the kernel loading (https://freetz.github.io/wiki/help/howtos/development/flash.html#Kernel).

Then I padded the compressed kernel to 256 bytes:

Doing tests:

Code:

freetz@freetz:~/freetz-ng$ ~/YourFritz/avm_kernel_config/extract_avm_kernel_config -s 96 kernel.image.unpacked >1750E-07.27_avm_kernel_config.bin
freetz@freetz:~/freetz-ng$ ~/YourFritz/avm_kernel_config/gen_avm_kernel_config 1750E-07.27_avm_kernel_config.bin > avm_kernel_config_area.1750E-07.27_patched

This how it looks in the original compressed kernel:

Unpacking the kernel from the final kernel.image and doing diff to the original patched unpacked kernel (no difference):

Code:

freetz@freetz:~/freetz-ng$ tools/unpack-kernel -u kernel.image
TI_AR7.LoadAddress=0x80060000
TI_AR7.EntryAddress=0x80064870
TI_AR7.RecordLength=0x0017E59B
TI_AR7.RecordChecksum=0x73FC11B1
WARNING: calculated TI-record checksum (0x7FEDD1B1) does not match the saved one (0x73FC11B1)
TI_AR7.LzmaCompressedStreamLength=0x0017E583
TI_AR7.LzmaUncompressedStreamLength=0x004C1F53
TI_AR7.LzmaCompressedStreamChecksum=0xEE8A19D9

freetz@freetz:~/freetz-ng$ diff ~/kernel.raw.unpacked.patched kernel.image.unpacked
freetz@freetz:~/freetz-ng$

Doing test:

Code:

freetz@freetz:~/freetz-ng$ ~/YourFritz/avm_kernel_config/extract_avm_kernel_config -s 96 kernel.image.unpacked >1750E-07.27_avm_kernel_config.bin
freetz@freetz:~/freetz-ng$ ~/YourFritz/avm_kernel_config/gen_avm_kernel_config 1750E-07.27_avm_kernel_config.bin > avm_kernel_config_area.1750E-07.27_patched

Please see both files archived as zip (this time, and apologies for 7z with the ".zip" extension last time

)

The full kernel.image just in case:

UPLOAD.EE - File does not exist

File does not exist. Upload.ee

www.upload.ee

PeterPawn · 11 Aug 2021

You have access to the serial console, don't you? I would think, I've read about this in the GitHub issue?

What's happening there? Any logs?

If not, it's possible that EVA isn't able to uncompress the kernel. It's a pity, that your pictures of the used hex-editor aren't really helpful ... if there're no infos from the serial console, please use the hexdump command (with option -C) for the first 512 and the last 512 byte of the packed kernel file each - calculating with decimal offsets (as from your hex-editor) is a bit confusing and the visible area from your pictures is too small.

baribal · 11 Aug 2021

PeterPawn schrieb:
You have access to the serial console, don't you? I would think, I've read about this in the GitHub issue?

Unfortunately this was the proposal from the fda77 to connect the console and I don't have it.

Please find attached first and last bytes of the packed firmware.

hexdump if you prefer:

Code:

freetz@freetz:~/freetz-ng$ hexdump -n512 -C kernel.image
00000000  81 12 ed fe 9b e5 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  83 e5 17 00 53 1f 4c 00  d9 19 8a ee 5d 00 00 80  |....S.L.....]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040  db d1 9c 8c ed f2 b8 19  b1 85 b8 05 bf bc ba 8d  |................|
00000050  e3 44 bf 70 57 ed 9f 1b  f7 88 87 00 1a 3e e8 9e  |.D.pW........>..|
00000060  8c 84 e3 94 34 2a 50 a8  04 6d 59 02 35 56 d4 e4  |....4*P..mY.5V..|
00000070  04 be 44 37 c7 83 b7 37  42 55 2c 4f 45 71 bd 22  |..D7...7BU,OEq."|
00000080  26 c9 04 3f 78 18 b0 dc  8b 2f 38 3d 32 97 e4 42  |&..?x..../8=2..B|
00000090  c9 8b 6a 19 f8 dc db fc  f7 33 37 0b 95 ce d3 fb  |..j......37.....|
000000a0  8d f7 40 43 e0 24 5d 1a  4e aa 1d 8f 41 14 68 0d  |..@C.$].N...A.h.|
000000b0  bb 4b 11 ab 94 1e 61 75  9a b5 5f 88 a2 be 4f a9  |.K....au.._...O.|
000000c0  74 ab f0 5c 69 0d 58 8b  77 3e c1 7f ca ae 09 76  |t..\i.X.w>.....v|
000000d0  49 6c 9f 63 83 fd 38 25  34 77 3b 27 67 93 b5 9b  |Il.c..8%4w;'g...|
000000e0  c3 15 d7 62 86 38 e6 d4  19 7b 03 82 bd 59 97 ed  |...b.8...{...Y..|
000000f0  fa 21 ce ae 0d 25 5d 19  36 5f fc 8f f6 25 32 a1  |.!...%].6_...%2.|
00000100  11 c3 94 03 4b 48 22 2d  36 b1 f7 ae 62 15 eb a6  |....KH"-6...b...|
00000110  77 f7 e7 8a ad ff 15 3b  cf a8 25 fa ab b9 36 d2  |w......;..%...6.|
00000120  8a 47 33 41 54 fe d4 a5  9f a0 d4 dd 5b a8 b0 ef  |.G3AT.......[...|
00000130  ab 43 7f e7 3d 57 00 8e  4c 4f 6a b2 f5 c8 b9 af  |.C..=W..LOj.....|
00000140  d0 94 c4 67 09 f2 bc 91  c7 61 08 f8 77 a3 f2 1b  |...g.....a..w...|
00000150  fb d3 a7 52 cc 21 4e b1  eb fa 97 de fd 56 7b e0  |...R.!N......V{.|
00000160  61 a5 9e f9 8c 02 98 7d  d4 e0 f7 0b a3 14 d7 af  |a......}........|
00000170  2e b3 15 5f e5 39 4c 16  f8 5b d9 ba 5f d6 85 8a  |..._.9L..[.._...|
00000180  81 02 46 1d ad 17 7e 02  3e e5 b3 9e 3d 7c fa 69  |..F...~.>...=|.i|
00000190  4f 18 cd 43 ea d6 de 8c  da 38 5e 86 b2 a1 9b 8f  |O..C.....8^.....|
000001a0  2f eb 7f 06 fe a5 dd 46  5a 03 5d 12 62 cc 9f 48  |/......FZ.].b..H|
000001b0  bc 3c 61 ce 00 bf fe 1c  c3 01 aa fe 51 ed 88 2c  |.<a.........Q..,|
000001c0  61 a2 e9 ea 86 42 22 bc  aa f1 d1 ed 64 09 c3 a6  |a....B".....d...|
000001d0  cd 3c ee 5b a3 d0 1b 66  3f 03 df bb bd 14 24 c9  |.<.[...f?.....$.|
000001e0  fd 2e 4f 11 98 0f c7 81  99 49 2d 4e aa a7 60 f0  |..O......I-N..`.|
000001f0  a7 78 bf 99 08 1b c9 fc  94 5a 7d e3 2e 67 a0 65  |.x.......Z}..g.e|
00000200

Code:

freetz@freetz:~/freetz-ng$ hexdump -s 0x0017e410 -n512 -C kernel.image
0017e410  02 fd b8 79 55 3a 2e b1  ff 42 1a 3f 39 68 7d 3e  |...yU:...B.?9h}>|
0017e420  48 88 35 7a 30 67 e1 7a  27 4d a1 0c 2e bf 45 a4  |H.5z0g.z'M....E.|
0017e430  68 1a f5 51 70 77 19 ff  fb f3 0e 48 88 f1 57 23  |h..Qpw.....H..W#|
0017e440  ef ef f2 e5 c5 aa 7e 6d  4e c4 69 ee ee f1 f4 b1  |......~mN.i.....|
0017e450  ec 24 8f 5e ba 8b fb fe  b0 7d 49 a2 1e e3 2c 57  |.$.^.....}I...,W|
0017e460  1a 4a 48 73 49 f8 90 ed  15 ef cd 48 55 a5 01 fc  |.JHsI......HU...|
0017e470  64 69 c1 f9 d3 24 fb ae  cc 94 d1 ef 99 b6 3c 08  |di...$........<.|
0017e480  bc 4d 98 c7 35 40 8f e5  6f 35 f7 1e 36 98 80 0e  |[email protected]...|
0017e490  91 c1 e9 21 71 b8 1d 86  24 12 29 f2 57 5c 9f f4  |...!q...$.).W\..|
0017e4a0  1b 59 15 51 20 0f b8 c0  c3 6e 8a e6 8c 62 40 8b  |.Y.Q ....n...b@.|
0017e4b0  3f 0d 69 ef 96 5a 6e 67  df 47 59 52 bf 83 18 a3  |?.i..Zng.GYR....|
0017e4c0  26 35 d0 b1 72 be 33 93  de 77 6c ef 6d 2d a5 56  |&5..r.3..wl.m-.V|
0017e4d0  7c 2d 83 52 f4 39 3e cc  a8 19 c6 0c e1 3c e6 01  ||-.R.9>......<..|
0017e4e0  5b e4 f5 c6 1a d0 d3 ec  92 6e 4b 87 58 62 84 38  |[........nK.Xb.8|
0017e4f0  5c dd f0 8a 84 18 22 d5  4d 26 af bf 76 ef f9 39  |\.....".M&..v..9|
0017e500  c1 7d b4 33 59 65 a0 3b  e2 59 4a 02 d8 68 f1 ef  |.}.3Ye.;.YJ..h..|
0017e510  33 ee 5b ff d3 3b 9c e5  95 1b 25 d2 48 ee 71 3a  |3.[..;....%.H.q:|
0017e520  a1 3a dd 95 75 ad 24 0e  d2 28 fc 88 dd dc e5 1e  |.:..u.$..(......|
0017e530  f5 a0 7d 3d 3e ec 48 ab  58 c5 07 de 17 5f de b8  |..}=>.H.X...._..|
0017e540  31 9c 67 01 a6 df 0f 86  9c 10 fd 5a 9d c1 25 81  |1.g........Z..%.|
0017e550  4d 04 fc f8 f3 a0 93 7f  91 2c e0 be df 4c f1 fa  |M........,...L..|
0017e560  b6 e5 54 c9 25 16 e4 f2  c3 0a 20 d6 26 27 7d ff  |..T.%..... .&'}.|
0017e570  24 55 9e 48 b7 98 b9 b6  28 99 1b 06 20 73 e3 45  |$U.H....(... s.E|
0017e580  e0 07 91 42 68 c6 c3 80  a9 ab 90 05 30 24 0d c9  |...Bh.......0$..|
0017e590  88 63 4d f9 a1 57 6d d9  58 3b 99 f7 1d 9f dd 44  |.cM..Wm.X;.....D|
0017e5a0  99 b9 31 ca c7 7f 00 b1  11 fc 73 00 00 00 00 70  |..1.......s....p|
0017e5b0  48 06 80 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |H...............|
0017e5c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0017e600  73 71 73 68 00 00 0e 1b  00 c5 e9 22 00 01 00 00  |sqsh......."....|
0017e610

kernel itself:

Code:

freetz@freetz:~/freetz-ng$ hexdump -n512 -C ~/kernel.raw.patched.eva_256.eva
00000000  81 12 ed fe 9b e5 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  83 e5 17 00 53 1f 4c 00  d9 19 8a ee 5d 00 00 80  |....S.L.....]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040  db d1 9c 8c ed f2 b8 19  b1 85 b8 05 bf bc ba 8d  |................|
00000050  e3 44 bf 70 57 ed 9f 1b  f7 88 87 00 1a 3e e8 9e  |.D.pW........>..|
00000060  8c 84 e3 94 34 2a 50 a8  04 6d 59 02 35 56 d4 e4  |....4*P..mY.5V..|
00000070  04 be 44 37 c7 83 b7 37  42 55 2c 4f 45 71 bd 22  |..D7...7BU,OEq."|
00000080  26 c9 04 3f 78 18 b0 dc  8b 2f 38 3d 32 97 e4 42  |&..?x..../8=2..B|
00000090  c9 8b 6a 19 f8 dc db fc  f7 33 37 0b 95 ce d3 fb  |..j......37.....|
000000a0  8d f7 40 43 e0 24 5d 1a  4e aa 1d 8f 41 14 68 0d  |..@C.$].N...A.h.|
000000b0  bb 4b 11 ab 94 1e 61 75  9a b5 5f 88 a2 be 4f a9  |.K....au.._...O.|
000000c0  74 ab f0 5c 69 0d 58 8b  77 3e c1 7f ca ae 09 76  |t..\i.X.w>.....v|
000000d0  49 6c 9f 63 83 fd 38 25  34 77 3b 27 67 93 b5 9b  |Il.c..8%4w;'g...|
000000e0  c3 15 d7 62 86 38 e6 d4  19 7b 03 82 bd 59 97 ed  |...b.8...{...Y..|
000000f0  fa 21 ce ae 0d 25 5d 19  36 5f fc 8f f6 25 32 a1  |.!...%].6_...%2.|
00000100  11 c3 94 03 4b 48 22 2d  36 b1 f7 ae 62 15 eb a6  |....KH"-6...b...|
00000110  77 f7 e7 8a ad ff 15 3b  cf a8 25 fa ab b9 36 d2  |w......;..%...6.|
00000120  8a 47 33 41 54 fe d4 a5  9f a0 d4 dd 5b a8 b0 ef  |.G3AT.......[...|
00000130  ab 43 7f e7 3d 57 00 8e  4c 4f 6a b2 f5 c8 b9 af  |.C..=W..LOj.....|
00000140  d0 94 c4 67 09 f2 bc 91  c7 61 08 f8 77 a3 f2 1b  |...g.....a..w...|
00000150  fb d3 a7 52 cc 21 4e b1  eb fa 97 de fd 56 7b e0  |...R.!N......V{.|
00000160  61 a5 9e f9 8c 02 98 7d  d4 e0 f7 0b a3 14 d7 af  |a......}........|
00000170  2e b3 15 5f e5 39 4c 16  f8 5b d9 ba 5f d6 85 8a  |..._.9L..[.._...|
00000180  81 02 46 1d ad 17 7e 02  3e e5 b3 9e 3d 7c fa 69  |..F...~.>...=|.i|
00000190  4f 18 cd 43 ea d6 de 8c  da 38 5e 86 b2 a1 9b 8f  |O..C.....8^.....|
000001a0  2f eb 7f 06 fe a5 dd 46  5a 03 5d 12 62 cc 9f 48  |/......FZ.].b..H|
000001b0  bc 3c 61 ce 00 bf fe 1c  c3 01 aa fe 51 ed 88 2c  |.<a.........Q..,|
000001c0  61 a2 e9 ea 86 42 22 bc  aa f1 d1 ed 64 09 c3 a6  |a....B".....d...|
000001d0  cd 3c ee 5b a3 d0 1b 66  3f 03 df bb bd 14 24 c9  |.<.[...f?.....$.|
000001e0  fd 2e 4f 11 98 0f c7 81  99 49 2d 4e aa a7 60 f0  |..O......I-N..`.|
000001f0  a7 78 bf 99 08 1b c9 fc  94 5a 7d e3 2e 67 a0 65  |.x.......Z}..g.e|
00000200

Code:

freetz@freetz:~/freetz-ng$ hexdump -s 0x0017e410 -n512 -C ~/kernel.raw.patched.eva_256.eva
0017e410  02 fd b8 79 55 3a 2e b1  ff 42 1a 3f 39 68 7d 3e  |...yU:...B.?9h}>|
0017e420  48 88 35 7a 30 67 e1 7a  27 4d a1 0c 2e bf 45 a4  |H.5z0g.z'M....E.|
0017e430  68 1a f5 51 70 77 19 ff  fb f3 0e 48 88 f1 57 23  |h..Qpw.....H..W#|
0017e440  ef ef f2 e5 c5 aa 7e 6d  4e c4 69 ee ee f1 f4 b1  |......~mN.i.....|
0017e450  ec 24 8f 5e ba 8b fb fe  b0 7d 49 a2 1e e3 2c 57  |.$.^.....}I...,W|
0017e460  1a 4a 48 73 49 f8 90 ed  15 ef cd 48 55 a5 01 fc  |.JHsI......HU...|
0017e470  64 69 c1 f9 d3 24 fb ae  cc 94 d1 ef 99 b6 3c 08  |di...$........<.|
0017e480  bc 4d 98 c7 35 40 8f e5  6f 35 f7 1e 36 98 80 0e  |[email protected]...|
0017e490  91 c1 e9 21 71 b8 1d 86  24 12 29 f2 57 5c 9f f4  |...!q...$.).W\..|
0017e4a0  1b 59 15 51 20 0f b8 c0  c3 6e 8a e6 8c 62 40 8b  |.Y.Q ....n...b@.|
0017e4b0  3f 0d 69 ef 96 5a 6e 67  df 47 59 52 bf 83 18 a3  |?.i..Zng.GYR....|
0017e4c0  26 35 d0 b1 72 be 33 93  de 77 6c ef 6d 2d a5 56  |&5..r.3..wl.m-.V|
0017e4d0  7c 2d 83 52 f4 39 3e cc  a8 19 c6 0c e1 3c e6 01  ||-.R.9>......<..|
0017e4e0  5b e4 f5 c6 1a d0 d3 ec  92 6e 4b 87 58 62 84 38  |[........nK.Xb.8|
0017e4f0  5c dd f0 8a 84 18 22 d5  4d 26 af bf 76 ef f9 39  |\.....".M&..v..9|
0017e500  c1 7d b4 33 59 65 a0 3b  e2 59 4a 02 d8 68 f1 ef  |.}.3Ye.;.YJ..h..|
0017e510  33 ee 5b ff d3 3b 9c e5  95 1b 25 d2 48 ee 71 3a  |3.[..;....%.H.q:|
0017e520  a1 3a dd 95 75 ad 24 0e  d2 28 fc 88 dd dc e5 1e  |.:..u.$..(......|
0017e530  f5 a0 7d 3d 3e ec 48 ab  58 c5 07 de 17 5f de b8  |..}=>.H.X...._..|
0017e540  31 9c 67 01 a6 df 0f 86  9c 10 fd 5a 9d c1 25 81  |1.g........Z..%.|
0017e550  4d 04 fc f8 f3 a0 93 7f  91 2c e0 be df 4c f1 fa  |M........,...L..|
0017e560  b6 e5 54 c9 25 16 e4 f2  c3 0a 20 d6 26 27 7d ff  |..T.%..... .&'}.|
0017e570  24 55 9e 48 b7 98 b9 b6  28 99 1b 06 20 73 e3 45  |$U.H....(... s.E|
0017e580  e0 07 91 42 68 c6 c3 80  a9 ab 90 05 30 24 0d c9  |...Bh.......0$..|
0017e590  88 63 4d f9 a1 57 6d d9  58 3b 99 f7 1d 9f dd 44  |.cM..Wm.X;.....D|
0017e5a0  99 b9 31 ca c7 7f 00 b1  11 fc 73 00 00 00 00 70  |..1.......s....p|
0017e5b0  48 06 80 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |H...............|
0017e5c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0017e600

PeterPawn · 12 Aug 2021

baribal schrieb:
0017e5b0 48 06 80 73 71 73 68 00 00 0e 1b 00 c5 e9 22 00 |H..sqsh.......".|

Your filesystem image doesn't start at a 256-byte boundary - the filesystem parser from kernel only searches in 256-byte steps:

C:

282                         mtd_start = offset;
283                         offset = (offset + tmp_word + 256) & ~0xFF;  /* 256 byte align */
284
285                         /* squashfs magic suchen ... zumindest bis 1 JFFS block vor Ende */
286                         tmp_word = 0;
287                         while (offset < ((next_offs - 0x10000) & ~0xFFFF)) {
288                                 if (mtd_read(mtd, offset, sizeof(tmp_word), &n, (u_char *)&tmp_word) == -EINVAL || n != sizeof(tmp_word)) break;
289                                 if (itsmagic(tmp_word)) {
290                                         /* So weit so gut: Squashfs-Größe? */
291                                         offset += sizeof(unsigned int) * 2;
292                                         if (mtd_read(mtd, offset, sizeof(tmp_word), &n, (u_char *)&tmp_word) == -EINVAL || n != sizeof(tmp_word)) {
293                                                 pr_err("mtd read error @ offs=0x%08x for squashfs size\n",
294                                                                 offset);
295                                                 tmp_word = 0;
296                                                 break;
297                                         }
298                                         if (tmp_word < 0x10000) {
299                                                 pr_warn("weird small squashfs size 0x%08x - smells fishy!\n",
300                                                                 tmp_word);
301                                         } else {
302                                                 found_rootfs = true;
303                                                 /*pr_denbug*/pr_info("fond_rootfs\n");
304                                                 break;
305                                         }
306                                 }
307                                 offset = (offset + 256) & ~0xFF;
308                         }

(from drivers/mtd/avm/partparse.c)

So your filesystem will never be found and the kernel reboots in panic.

I have no clue, why your packed kernel ends on such an odd offset - but you've made a failure while combining the image obviously.

The filesystem image has to start with the magic sqsh at offset 0 - if this has been proved, your packed kernel image has a wrong size. It has to be padded to a 256-byte boundary AFTER the EVA headers have been added - but you may simply use dd again to fill the last block (using a block-size of 256 and conv=sync) with zeros. Any 0xff is only needed to treat some flash cells with care - they can keep their "erased" state, if no bit has to be cleared - it doesn't matter here and using 0x00 instead makes it more readable.

But now we (better you) have to double-check the data ... first make sure, that the used filesystem.image starts with the magic sqsh - then it's sure, that the offset doesn't come from this file.

Next we may look at the beginning of the packed (original) kernel (1750E, 07.27) - it looks like this:

Rich (BBCode):

00000000  81 12 ed fe fe e3 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  e6 e3 17 00 53 1f 4c 00  2b 90 05 10 5d 00 00 80  |....S.L.+...]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|

The red value is the size of packed payload - it may be used to locate the position of the load address after the packed payload. The green value is the size of the unpacked data - it should be compared to the length of the unpacked kernel file to make sure, that there's no missing or additional data at the end.

I would waive using any files, I've not created myself - only with self-made files we can verify, whether splitting and recombining had the proper result. After extracting the file kernel.image from AVM's TAR file, the next steps are as follows:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> grep -abo sqsh kernel_1750E_07.27.image
1565952:sqsh
#
# This is the spot, where the file has to be splitted. Everything in front of this byte is the packed kernel image and everything behind is the SquashFS image with the filesystem.
# Let's check, whether this is a 256-byte boundary.
#
peh@vidar:/tmp/YourFritz> printf "%08X\n" 1565952
0017E500
#
# Two digits of 0 at the end -> it's a multiple of 2^8 (=256).
#
peh@vidar:/tmp/YourFritz> dd if=kernel_1750E_07.27.image of=kernel.image bs=256 count=$(( 1565952 / 256 ))
6117+0 records in
6117+0 records out
1565952 bytes (1.6 MB, 1.5 MiB) copied, 0.0561441 s, 27.9 MB/s
peh@vidar:/tmp/YourFritz> dd if=kernel_1750E_07.27.image of=filesystem.image bs=256 skip=$(( 1565952 / 256 ))
50688+1 records in
50688+1 records out
12976136 bytes (13 MB, 12 MiB) copied, 0.366459 s, 35.4 MB/s
#
# Another check (needs the unsquashfs utility, it's found by PATH on my system), whether filesystem.image has the right format.
#
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -s filesystem.image
Found TI checksum (0xD015B9E2) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on filesystem.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12666.28 Kbytes (12.37 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 157
Number of inodes 3611
Number of ids 1
peh@vidar:/tmp/YourFritz> bash avm_kernel_config/unpack_kernel.sh < kernel.image > kernel.unpacked
peh@vidar:/tmp/YourFritz> ls -l kernel.image kernel.unpacked
-rw-r--r-- 1 peh users 1565952 Aug 12 00:34 kernel.image
-rw-r--r-- 1 peh users 4988755 Aug 12 00:48 kernel.unpacked
#
# The file size of the packed kernel matches the location of SquashFS magic from original (combined) image.
# The red value should match the unpacked size from the packed image.
#
peh@vidar:/tmp/YourFritz> hexdump -C -n 64 kernel.image
00000000  81 12 ed fe fe e3 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  e6 e3 17 00 53 1f 4c 00  2b 90 05 10 5d 00 00 80  |....S.L.+...]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040
peh@vidar:/tmp/YourFritz> printf "%u\n" "$(( 0x4c1f53 ))"
4988755
#
# A perfect match - see above.
#

So far, so good. Patching the unpacked kernel with the new configuration area doesn't change the (unpacked) size - no matter, whether it's done using a hex-editor or if the complete configuration area (this means, the whole 96 KB) will be overwritten with the (binary) data (extracted earlier after patching - your file from the 7z attachment looks still good). So the unpacked file has to keep its size of 4988755 byte:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> 7z l akc.zip
[...]
Scanning the drive for archives:
1 file, 7769 bytes (8 KiB)

Listing archive: akc.zip

--
Path = akc.zip
Open WARNING: Can not open the file as [zip] archive
Type = 7z
Physical Size = 7769
Headers Size = 231
Method = LZMA:192k
Solid = +
Blocks = 1

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2021-08-11 13:33:14 ....A        98304         7538  1750E-07.27_patched_avm_kernel_config.bin
2021-08-11 13:32:53 ....A        41453               avm_kernel_config_area.1750E-07.27_patched
------------------- ----- ------------ ------------  ------------------------
2021-08-11 13:33:14             139757         7538  2 files

Warnings: 1
peh@vidar:/tmp/YourFritz> 7z e akc.zip 1750E-07.27_patched_avm_kernel_config.bin
[...]
Scanning the drive for archives:
1 file, 7769 bytes (8 KiB)

Extracting archive: akc.zip
WARNING:
akc.zip
Can not open the file as [zip] archive
The file is open as [7z] archive

--
Path = akc.zip
Open WARNING: Can not open the file as [zip] archive
Type = 7z
Physical Size = 7769
Headers Size = 231
Method = LZMA:192k
Solid = +
Blocks = 1

Everything is Ok

Archives with Warnings: 1
Size:       98304
Compressed: 7769
peh@vidar:/tmp/YourFritz> printf "%u\n" "$(( 96 * 1024 ))"
98304
#
# Configuration area file size is 96 KB as expected, we may use dd to overwrite it in the unpacked kernel.
#
peh@vidar:/tmp/YourFritz> dd if=1750E-07.27_patched_avm_kernel_config.bin of=kernel.unpacked bs=1024 seek=$(( 0x468000 / 1024 )) conv=notrunc
96+0 records in
96+0 records out
98304 bytes (98 kB, 96 KiB) copied, 0.00102909 s, 95.5 MB/s
peh@vidar:/tmp/YourFritz> ls -l kernel.unpacked
-rw-r--r-- 1 peh users 4988755 Aug 12 01:06 kernel.unpacked
#
# File size didn't change.
# Don't use STDIN for lzma or the unpacked size will be missing in the headers.
#
peh@vidar:/tmp/YourFritz> ../freetz-ng/tools/lzma e -so kernel.unpacked > kernel.packed

LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03
peh@vidar:/tmp/YourFritz> ls -l kernel.packed kernel.eva
-rw-r--r-- 1 peh users 1566131 Aug 12 01:18 kernel.eva
-rw-r--r-- 1 peh users 1566096 Aug 12 01:16 kernel.packed
#
# EVA file is 35 byte larger as expected.
#
peh@vidar:/tmp/YourFritz> hexdump -C -n 64 kernel.eva
00000000  81 12 ed fe 9b e5 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  83 e5 17 00 53 1f 4c 00  d9 19 8a ee 5d 00 00 80  |....S.L.....]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040
#
# Unpacked size is still the same, the packed size may differ - it doesn't matter.
# But the EVA file doesn't have the needed size yet, it must be padded.
#
peh@vidar:/tmp/YourFritz> dd if=kernel.eva of=kernel.padded bs=256 conv=sync
6117+1 records in
6118+0 records out
1566208 bytes (1.6 MB, 1.5 MiB) copied, 0.0516275 s, 30.3 MB/s
peh@vidar:/tmp/YourFritz> ls -l kernel.padded kernel.eva
-rw-r--r-- 1 peh users 1566131 Aug 12 01:18 kernel.eva
-rw-r--r-- 1 peh users 1566208 Aug 12 01:23 kernel.padded
peh@vidar:/tmp/YourFritz> printf "%08X\n" 1566208
0017E600
#
# Now file size is a multiple of 256.
#
peh@vidar:/tmp/YourFritz> cat kernel.padded filesystem.image > alien.image
peh@vidar:/tmp/YourFritz> ls -l kernel.padded filesystem.image alien.image
-rw-r--r-- 1 peh users 14542344 Aug 12 01:26 alien.image
-rw-r--r-- 1 peh users 12976136 Aug 12 00:35 filesystem.image
-rw-r--r-- 1 peh users  1566208 Aug 12 01:23 kernel.padded
peh@vidar:/tmp/YourFritz> printf "%u\n" "$(( 1566208 + 12976136 ))"
14542344
#
# Combined file size looks good.
#
peh@vidar:/tmp/YourFritz> grep -abo sqsh alien.image
1566208:sqsh
#
# Filesystem starts a the correct offset.
#
peh@vidar:/tmp/YourFritz>

As mentioned above - I've no clue, WHAT you did wrong (it's the result of missing logs) ... but if I follow my own instructions/hints, I get another file.

baribal · 12 Aug 2021

@PeterPawn

Apologies, I did a mistake and attached the data from the non-padded kernel yesterday and replaced my images and hexdumps in #64 also yesterday but I guess you didn't notice it. As you see now it looks like the image you've built via your procedure looks similar to the one I've built (just used FF instead of 00). I've also completely rebuilt the image now via your procedure and it looks correct from what I see:

Code:

freetz@freetz:~/freetz-ng$ grep -abo sqsh alien.image
1566208:sqsh
freetz@freetz:~/freetz-ng$ ll kernel.padded
-rw-r--r-- 1 freetz freetz 1566208 Aug 12 09:55 kernel.padded
freetz@freetz:~/freetz-ng$ hexdump -C alien.image -n64
00000000  81 12 ed fe 9b e5 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  83 e5 17 00 53 1f 4c 00  d9 19 8a ee 5d 00 00 80  |....S.L.....]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040

freetz@freetz:~/freetz-ng$ hexdump -s 0x0017e5a0 -n128 -C alien.image
0017e5a0  99 b9 31 ca c7 7f 00 b1  11 fc 73 00 00 00 00 70  |..1.......s....p|
0017e5b0  48 06 80 00 00 00 00 00  00 00 00 00 00 00 00 00  |H...............|
0017e5c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0017e600  73 71 73 68 00 00 0e 1b  00 c5 e9 22 00 01 00 00  |sqsh......."....|
0017e610  00 00 00 9d 00 04 00 10  02 c0 00 01 00 04 00 00  |................|
0017e620

Still during startup it is blinking Power led for some time, then Power led lights constantly for some time and then device rebooted.

PeterPawn · 12 Aug 2021

baribal schrieb:
Still during startup it is blinking Power led for some time, then Power led lights constantly for some time and then device rebooted.

To get any clue, what's happening while booting, it's necessary to know the duration of each phase better.

It starts with a short on-phase (~ 100 ms or even lower) of all visible LEDs - it's the initialization of the GPIO hardware/pins during EVA startup.

Shortly later the Power LED starts blinking for something between 5 and 10 seconds - that's the time, EVA's awaiting any incoming FTP connection.

If no connection request arrived (and the serial console doesn't recognize any input), the kernel from flash memory is unpacked to RAM - the time needed depends on size of kernel and CPU power of the used chipset. But it should never take more than around 10 seconds - I'm unsure, whether the DVB-C repeater (or the 1750E even) changes to a steady lighted Power LED at the very beginnnig of this phase or after the kernel was unpacked.

But at the latest the Power LED gets lid for a longer time span, when EVA transfers control to the unpacked kernel. And now starts the kernel initialization ... and also without any knowledge of the special timings for a Scorpion chipset it's possible to conclude roughly, how far the kernel setup came in front of a reboot - even if it's not an exact science.

Depending on the duration of this phase it's possible, that the TFFS was initialized already ... in this case a "panic log" would be written to flash memory, that can be read out at next boot sequence. But that's only one possible next step ... the first task is now to use a stop-watch and record the (reasonably exact) time span for each phase (in a single cycle).

But the very best solution would be a working serial console now ... if you(!) could decide to make this functioning, there's no need for exact timings anymore, because the needed info (and much more) is shown there.

baribal · 12 Aug 2021

@PeterPawn

I've just did two short tests to ensure our procedure works:

1. repacked the original kernel.image from 1750E with our procedure w/o patching FDT

I got the same padded kernel size as inside the original image:

Code:

freetz@freetz:~/freetz-ng$ hexdump -C -n 64 kernel_original.packed.eva
00000000  81 12 ed fe fe e3 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  e6 e3 17 00 53 1f 4c 00  2b 90 05 10 5d 00 00 80  |....S.L.+...]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
00000040
freetz@freetz:~/freetz-ng$ ll kernel_original.packed.eva
-rw-r--r-- 1 freetz freetz 1565718 Aug 12 11:59 kernel_original.packed.eva
freetz@freetz:~/freetz-ng$ ll kernel_original.padded
-rw-r--r-- 1 freetz freetz 1565952 Aug 12 12:04 kernel_original.padded

And device has booted after flashing firmware

2. repacked the original kernel.image from 1750E with our procedure w/o patching FDT AND used the low compression option "-a0" for lzma command.

I got different kernel packed and padded sizes and device is not booting:

Code:

freetz@freetz:~/freetz-ng$ hexdump -C -n 64 kern.padded
00000000  81 12 ed fe 40 5a 1a 00  00 00 06 80 01 02 5a 07  |[email protected].|
00000010  28 5a 1a 00 53 1f 4c 00  47 1d 12 66 5d 00 00 80  |(Z..S.L.G..f]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 44 34 79 28 7c 3c 8c  5c 53 fd 96 08 93 1b 71  |yD4y(|<.\S.....q|
00000040
freetz@freetz:~/freetz-ng$ ll kern.*
-rw-r--r-- 1 freetz freetz 1727029 Aug 12 12:37 kern.lzma
-rw-r--r-- 1 freetz freetz 1727064 Aug 12 12:38 kern.lzma.eva
-rw-r--r-- 1 freetz freetz 1727232 Aug 12 12:39 kern.padded

Any ideas what might cause it? Seems to be smth with different padded size for kernel.

PeterPawn · 12 Aug 2021

OK - this could be my fault in a former "visualization" ... I've called lzma with wrong options (possibly).

The ("native") LZMA headers are crippled a bit (up to "missing/cutted off") in EVA format. It's the reason, why such headers have to be reconstructed and prepended to the packed payload, prior to calling [un]lzma in my unpack_kernel.sh script: https://github.com/PeterPawn/YourFr...b5de9/avm_kernel_config/unpack_kernel.sh#L183 - I've tried to describe this in the header of script file.

Maybe EVA expects special (and/or fixed) settings to be used for compression - and possibly assumes fixed values for decompression, too ... ignoring any remaining settiings from LZMA stream. But that's only my assumption, too - there weren't any needs in the past to repack a kernel myself (means: in my avm_kernel_config implementation).

You should try again to pack the kernel payload using: lzma e -lc1 -lp2 -pb2 (defaults are different) with the lzma tool from your Freetz-NG/tools folder. Other LZMA encoders use different options - so if you want to use another one with a different options set, you have to "translate" the options accordingly.

baribal · 12 Aug 2021

@PeterPawn

I tried to "tools/lzma e -lc1 -lp2 -pb2" for both kernels patched and original and both are not working atm.

The only time the original repacked kernel is working is when I am using "lzma e" w/o any switches and this time the padded kernel size is equal to the original untouched kernel extracted from the image: 1565952 bytes long.

Each time the padded size of the kernel is different the device is not booting.

For the original kernel when device is booting the Power blinks 4 times until passed FTP phase and then it is constantly lighting for ~16sec and then all leds are lighting for a sec and then restart.

For the patched kernel the Power blinks 4 times, then it is constantly lighting for ~8sec, then all leds are switched off for ~19sec and then all led are lighting for a sec and then restart.

PeterPawn schrieb:
The red value is the size of packed payload - it may be used to locate the position of the load address after the packed payload.

PeterPawn schrieb:
00000000 81 12 ed fe fe e3 17 00 00 00 06 80 01 02 5a 07 |..............Z.| 00000010 e6 e3 17 00 53 1f 4c 00 2b 90 05 10 5d 00 00 80 |....S.L.+...]...| 00000020 00 00 00 00 00 00 6f fd ff ff a3 b7 7f 4c 35 19 |......o......L5.|

This is somehow related to the size of the packed firmware? lzma2eva manages it? Cause it is not equal to the size of the packed firmware when translated to the decimal form.

PeterPawn · 12 Aug 2021

baribal schrieb:
Cause it is not equal to the size of the packed firmware when translated to the decimal form.

What do you mean and what is not equal?

The size of the packed payload MAY differ (and WILL differ at the most cases), because it depends on the unpacked CONTENT. If the content changes, usually the packed size will change, too.

The value (in red) is the size of the packed payload ... as mentioned before, there are data in front of this payload and after it. In front are 24 bytes (signature/magic, overall length of packed payload and additional data, memory load address (the address, where to uncompress data to), LZMA compression signature, size of packed payload, size of unpacked payload - each as a 32-bit value).

But let's retry this with the original 1750E kernel for FRITZ!OS version 07.27 to check my statements and my understanding, too:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> hexdump -C kernel.image
00000000  81 12 ed fe fe e3 17 00  00 00 06 80 01 02 5a 07  |..............Z.|
00000010  e6 e3 17 00 53 1f 4c 00 2b 90 05 10 5d 00 00 80  |....S.L.+...]...|
00000020  00 00 00 00 00 00 6f fd  ff ff a3 b7 7f 4c 35 19  |......o......L5.|
00000030  79 56 f2 10 e8 06 1a a7  90 86 88 eb 1f 6f b5 e5  |yV...........o..|
[...]
0017e3e0  26 b4 1d 53 77 01 f2 94  e2 41 33 b1 7f 1a 78 30  |&..Sw....A3...x0|
0017e3f0  a7 f4 35 f2 a9 d1 cf a2  54 1c b6 e0 f5 6d 6a 20  |..5.....T....mj |
0017e400  99 c0 54 bf 20 58 c8 99  24 ff 97 5a fc 73 00 00  |..T. X..$..Z.s..|
0017e410  00 00 70 48 06 80 ff ff  ff ff ff ff ff ff ff ff  |..pH............|
0017e420  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
0017e500

Let's walk us from inner to outer values ... the purple values are the "real" LZMA compressed data. They're prepended by 8 bytes LZMA settings (format description: https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt) + fillers - 0x5d (at offset 0x1c) are the LZMA model properties, computed as: ( ( pb * 5 + lp ) * 9 ) + lc. A value of 0x5d stands for lc=3, lp=0 and pb=2 - and this are the defaults for the lzma tool from the Freetz toolchain (according to its help screen) - so it's really unnecessary to specify those parameters.

The red value of 0x00800000 (at 0x1d) is the used dictionary size - representing 8 MB (1 << 23), which is the default, too. The next three bytes (yellow) are fillers - at their end starts the "real" compressed payload with a size of 0x17e3e6 bytes (the proof is the working unpack script: https://github.com/PeterPawn/YourFr...fb5de9/avm_kernel_config/unpack_kernel.sh#L69).

Consequently it should end at offset 0x24 (where it starts) + 0x17e3e6 (its size) = 0x17e40a - the next 4 bytes (green) are a checksum (byte-wise addition) of content from offset 0x04 to 0x17e40a. The following red bytes are a marker (for the next value) and after this, the kernel entry address (where to jump to start it) can be found. Between the unpacked data size and the LZMA model properties a CRC32 checksum value of the LZMA-encoded payload (from 0x1c to 0x17e40a) is stored (marked with green above).

The (red) value at offset 0x04 is the size of data after the load address (green, at offset 0x08 with 4 bytes size) up to the checksum after LZMA payload (at offset 0x17e40a) - it's the "compressed size" of kernel data and LZMA control structures (0x17e40a - 0x0c = 0x17e3fe).

Now we know the used LZMA properties (from original kernel) for sure (they're really all defaults of lzma from Freetz toolchain) - after using lzma2eva the new EVA image should contain the data from the (LZMA-)packed kernel, starting at offset 0x0D from file. The first 13 bytes of the lzma-encoded file contain the LZMA properties (1 byte, see above), the dictionary size as 32-bit integer and (optionally by format description, but required by lzma2eva, I'd guess) a 64-bit integer with the size of uncompressed data - this gives us such an "odd" offset for start of encoded payload.

Round about 27 seconds after the waiting for FTP connections was stopped by EVA (when Power LED wents steady) are a long time - even the first 8 seconds should be enough to uncompress and start the kernel (but that's only guessed). The 16 seconds, when all LEDs are unlit, may be the time needed to save the "panic log" mentioned above ... with a bit of luck.

You could try to retrieve this log from the flash ... you have to install a (functioning) firmware only and to extract the support file (I think, you know this already) from the last run. But because the 1750E has only space for a single OS, you have to flash the (runnable) firmware over your alien image - WITHOUT to use a recovery program by AVM, because this would create a new TFFS image, too, and overwrite any logged data from last reboot.

It's possible, that really the kernel setup fails already ... it looks for a FDT first and starts to initialize the hardware (according to the description from FDT) afterwards. If the FDT content is wrong for some reason, this could crash immediately - but in this case the TFFS wasn't (most likely) initialized already and there was no further data recorded, why the crash/reboot occured.

The steps we've taken to modify the firmware (if your actions were the same as I've showed), should be correct - the only difference to the original firmware is the changed configuration area. To check, whether any action was faulty, you could try to repeat all the steps, but use the 1750E configuration area to overwrite the original kernel (even if the content should be the same before and after this replacement). If this kernel may run (after all the other steps to create a flashable image), it's obviously the content of the changed configuration area and we have to look deeper into those binary data. Another approach could be, to use the FDT from 07.01 firmware (for the DVB-C device) and try this one - one more idea is the "decompilation" of both versions and their comparison. The decompiled FDT may be compared to the DTS (source) file for DVB-C model, too.

But no other idea could have the same effect, as a functioning serial console ... I can only repeat this once more. If you can't prepare this yourself ... don't you know somebody, who may do this for you?

baribal · 13 Aug 2021

@PeterPawn

Please find the support log file attached. I see kernel panic in there.

Code:

BEGIN SECTION '/proc/avm/log_sd/crash'
----------
1970-01-01 01:03:11(1) [Bus error] notifyd([590]) watchdog expired at epoll_wait+0x40 (/lib/libc.so.1 at 0000d5d0)
SIGNO 10 ERRNO 62 CODE 3
Version: 07.08-65621
ze: 00000000 at: 7ff24d68 v0: 00000001 v1: 00000000
a0: 00000003 a1: 561db280 a2: 0000000d a3: 00000000
t0: 00000000 t1: 80531870 t2: 00000000 t3: 80531870
t4: 00000000 t5: 0243d583 t6: 00000000 t7: 00000000
s0: 561db280 s1: 561e3010 s2: 7fbd5728 s3: 77232ffc
s4: 00000000 s5: 00000000 s6: 00000000 s7: 00000000
t8: 00000000 t9: 778285b0 k0: 000003e8 k1: 00000000
gp: 7787a3a0 sp: 7ff24e88 fp: 7fbd56c0 ra: 561c7ff9
FA ebadebad (stack overflow)
PC 777e15d0 epoll_wait+0x40 (/lib/libc.so.1 at 0000d5d0)
PC Code: 8f998044 2402109a 0000000c <10e00022> 8fbf002c 7c03e83b 00602021 8f838980 00641821
RA 561c7ff9 main+0xa88 (/usr/bin/boxnotifyd at 00001ff9)
RA Code: 6e0d ea40 653a <9604> 5200 d215 659e 61e0 4047
[bt]  777e15d0 epoll_wait+0x40 (/lib/libc.so.1 at 0000d590/0xd5d0)
                        Code: 8f998044 2402109a 0000000c <10e00022> 8fbf002c 7c03e83b 00602021 8f838980 00641821
[bt] *561c7ff4 [561c7581] <main+0x10>+0xa74 (/usr/bin/boxnotifyd at 00001581/0x1ff5)
                        Code: f190 9948 6e0d <ea40> 653a 9604 5200 d215 659e
[bt]  77828b2c __uClibc_main+0x1fc (/lib/libc.so.1 at 00054930/0x54b2c)
                        Code: 27a30018 ac438c20 8f828938 <0320f809> 8c460000 1000001c 8fbc0010 8f90885c 8e1900c8
[bt] finished.

-----
crashreport: read crash-variable '[0]3fa0613a,61162a91,1[1]0,0,0[2]58259de,6114fd97,1[3]0,0,0'
crashreport: old parsed checksum[2].cs = 058259de new_sum=058259de (new_len=1411)
crashreport: crash-variable set to '[0]3fa0613a,61162a91,1[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0'
(first) sent on: Thu Aug 12 10:53:11 2021 UTC by crash report
----------
END SECTION '/proc/avm/log_sd/crash'

BEGIN SECTION '/proc/avm/log_sd/crash2'
----------
cat: can't open '/proc/avm/log_sd/crash2': No data available
/proc/avm/log_sd/crash2 no data
----------
END SECTION '/proc/avm/log_sd/crash2'
==========
##### END SECTION CRASHLOG

##### BEGIN SECTION PANICLOG /proc/avm/log_sd
==========

BEGIN SECTION '/proc/avm/log_sd/panic'
----------
UPTIME: 2
(0 d 0 h 0 min 2 s - panic on Thu Jan 01 00:00:02 1970 UTC )
Irregular Reboots: SUM(56) - KCRASH(56) (since last regular reboot/power-cut)
HW: 205.2
FW: 07.27
Bootloader: 1.2349
PANIC LOG VERSION 2.1
[    0.000000] Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.000000] bootconsole [early0] enabled
[    0.000000] DT @ 804cbeb0: d0 0d fe ed 00 00 1f 38
[    0.000000] MIPS: machine is AVM FritzRepeater 1750E
[    0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[    0.000000] Set Port base
[    0.000000] detect_sys_type
[    0.000000] SoC: Qualcomm Atheros QCA9556 ver 1 rev 0
[    0.000000] [plat_mem_setup] memsize 0x4000000, memstart 0x00000000
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] On node 0 totalpages: 16384
[    0.000000] free_area_init_node: node 0, pgdat 804993b0, node_mem_map 810062c0
[    0.000000]   Normal zone: 128 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 16384 pages, LIFO batch:3
[    0.000000] [fw-info] Version 07.27
[    0.000000] [module-mem] Use 0x01087000-0x0141efff (mapped at 81087000-8141efff) for 24 modules
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line:  gocommand console=ttyS0,115200n8r nor_size=0 sflash_size=16MB nand_size=0MB ethaddr=5C:49:79:4F:A8:8E
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] [mips_nmi_setup] setup NMI vector to base 0x80000380
[    0.000000] Memory: 55152K/65536K available (3602K kernel code, 337K rwdata, 636K rodata, 312K init, 732K bss, 10384K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:91
[    0.000000] Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, Ref:40.000MHz
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 5309056796 ns
[    0.000008] sched_clock: 32 bits at 360MHz, resolution 2ns, wraps every 5965232126ns
[    0.008315] console [ttyS0] enabled
[    0.015728] bootconsole [early0] disabled
[    0.024244] Calibrating delay loop... 359.42 BogoMIPS (lpj=718848)
[    0.054857] pid_max: default: 32768 minimum: 301
[    0.059616] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.066252] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.074288] Performance counters: mips/74K PMU enabled, 4 32-bit counters available to each CPU, irq 21
[    0.084850] devtmpfs: initialized
[    0.089144] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.098982] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.105770] NET: Registered protocol family 16
[    0.110570] console [avm0] enabled
[    0.114123] cpuidle: using governor ladder
[    0.118228] cpuidle: using governor menu
[    0.122149] Creating Config Table
[    0.125691] Enabling UART-Input for Pin 9
[    0.131747] MIPS: machine is AVM FritzRepeater DVB-C
[    0.148778] Can't analyze schedule() prologue at 80066bc8
[    0.154217] avm_check_cpu_features: mips-options: 0x40006d638b icache.flags 0x00000000 dcache.flags 0x00000004 isa_level 0x00000031 ases 00000051
[    0.167529] avm_alloc_page_extension node_extension_table[0] entries=16384 (size=65536)  alloced
[    0.176442] Reboot Status is: Soft-Reboot(KCRASH) Irregular Reboots: SUM(55) - KCRASH(55)
[    0.184756] no support for hwid 205
[    0.188204] [avmnet] [avmnet_cfg_init] initializing
[    0.193388] [find_nmi_vector] no nmi vector found
[    0.460218] <Warning : PCIe WLAN Module not found !!!>
[    0.465358] ar724x-pci 14000000.pci: PCIe link is down
[    0.470548] registering PCI controller with io_map_base unset
[    0.476469] PCI host bridge to bus 0000:00
[    0.480563] pci_bus 0000:00: root bus resource [mem 0x10000000-0x11ffffff]
[    0.487498] pci_bus 0000:00: root bus resource [io  0x0000]
[    0.493130] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[    0.499994] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    0.508024] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    0.508489] AVM PA for Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.508489]  (early init)
[    0.524120] clocksource: Switched to clocksource MIPS
[    0.530576] NET: Registered protocol family 2
[    0.535754] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    0.542799] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.549187] TCP: Hash tables configured (established 1024 bind 1024)
[    0.555681] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.561565] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.568110] avm_pa: try to activate hw accelaration for pid 3 (ipv4) called from 0x802f2bfc
[    0.576564] NET: Registered protocol family 1
[    0.580972] PCI: CLS 0 bytes, default 32
[    0.582233] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.588135] yaffs: yaffs Installing.
[    0.588487] io scheduler noop registered
[    0.592421] io scheduler deadline registered (default)
[    0.601272] ttyS0 at MMIO 0x18020000 (irq = 19, base_baud = 2500000) is a PORT_16550A
[    0.609775] [loadcontrol] set auto - scale=1
[    0.614065] [avm] configured: watchdog event debug
[    0.618945] AVM_WATCHDOG: Watchdog Driver for AR7 Hardware (Version 1.0)
[    0.626075] Register push button event to receive the set_factory_kernel event
[    0.633887] AVM Simple Profiling enabled Version 3.0
[    0.638882] [simple-profiling]:4 performance counters implemented, OLD_34K
[    0.646190] avm_net_trace: Up and running.
[    0.657117] loop: module loaded
[    0.660603] Registering ATH-flash-driver...
[    0.664859] [ath_flash] Use 3 byte addressing
[    0.692111] 6 avm_squashfs partitions found on MTD device ath-nor
[    0.698229] [TFFS3_Register_Panic_CB] registering panic callback for mtd ath-nor
[    0.705710] Creating 6 MTD partitions on "ath-nor":
[    0.710647] 0x000000199900-0x000000f00000 : "rootfs"
[    0.716714] [rootfs] use mtd0 (rootfs) as root
[    0.721208] mtdsplit: no squashfs found in "rootfs"
[    0.726097] 0x000000020000-0x000000199900 : "kernel"
[    0.732107] 0x000000000000-0x000000020000 : "urlader"
[    0.738164] 0x000000f00000-0x000000f80000 : "tffs (1)"
[    0.744413] 0x000000f80000-0x000001000000 : "tffs (2)"
[    0.750559] 0x000000000000-0x000001000000 : "reserved-kernel"
[    0.757346] Atheros on-chip NAND FLash Controller Driver, Version 1.0 (c) 2014 AVM GmbH, 2010 Atheros Communications, Ltd.
[    0.768604] tun: Universal TUN/TAP device driver, 1.6
[    0.773666] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[    0.780107] i2c /dev entries driver
[    0.783637] AVM PA for Linux Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.783637]  (late init)
[    0.799956] gre: GRE over IPv4 demultiplexor driver
[    0.804931] NET: Registered protocol family 10
[    0.810289] avm_pa: try to activate hw accelaration for pid 4 (ipv6) called from 0x802f2bfc
[    0.818825] NET: Registered protocol family 17
[    0.823305] Bridge broadcast ratelimiter registered
[    0.828188] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[    0.840969] Bridge firewalling registered
[    0.845046] l2tp_core: L2TP core driver, V2.0
[    0.849390] l2tp_ip: L2TP IP encapsulation support (L2TPv3)
[    0.855037] l2tp_netlink: L2TP netlink interface
[    0.859724] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
[    0.865673] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
[    0.872206] 8021q: 802.1Q VLAN Support v1.8
[    0.877317] [TFFS3_Init] Called.
[    0.880559] [TFFS3_Init] No storage module registered, trying legacy fallback
[    0.887741] [TFFS3_CACHE_Configure] Setting up caching for backend legacy
[    0.894600] [TFFS3-CACHE] Caching module for TFFS 3.x
[    0.899711] [TFFS3_LGCY_Setup] using mtd3(tffs (1)), mtd4(tffs (2))
[    0.906050] [TFFS3_LGCY_Setup] mtd "tffs (1)": segment value 4
[    0.911943] [TFFS3_LGCY_Setup] mtd "tffs (2)": segment value 5
[    0.917833] [TFFS3_LGCY_Setup] Using segment 5 (avail: 4 + 5)
[    0.923640] [TFFS3_LGCY_Setup] mtd4 size=0x80000
[    0.929033] TFFS: tiny flash file system driver. GPL (c) AVM Berlin (Version 3.0)
[    0.936605] Adam2 environment variables API installed.
[    0.943204] {avmnet_cfg_netinit}
[    0.946442] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    0.956440] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    2.392078] [avmnet] [avmnet_ar8033_powerdown] Called for module ar8033
[    2.398763] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e
[    2.410050] squashfs: SQUASHFS error: unable to read id index table
[    2.416621] yaffs: dev is 32505856 name is "mtdblock0" ro
[    2.422055] yaffs: passed flags ""
[    2.425460] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    2.425470] yaffs: MTD device does not support have the right page sizes
[    2.425557] yaffs: dev is 32505856 name is "mtdblock0" ro
[    2.430977] yaffs: passed flags ""
[    2.434392] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    2.434401] yaffs: auto selecting inband tags
[    2.469371] yaffs: 214 blocks to be sorted...
[    2.469570] yaffs: **>> yaffs: get_block_info block 215 is not valid
[    2.469599] [kernel-breakpoint] pc=0x80196ed8(0x80196ed8) addr=0x83c2f99c task=swapper pid=1 ra=0x80196ed8(0x80196ed8)
[    2.480379] Code(0x80196ed0): 0x0c02ae2c 0x248433e8 <0x000c000d> 0x1000ffff 0x00000000
[    2.488367] PCI: int=00000000 aer=00000000 uer=00000000 cer=00000000 debug=00004000 mac_phy=008859c4 phy_mac=0127fefe err_cnt=00000000
[    2.500634] set_reboot_status: Soft-Reboot(KCRASH)  - KCRASH(56)SUM(56)UP(2)UTC(2)FW(07.27)HW(205)HWS(2)BV(1.2349)
[    2.511188] BUG() at function 'yaffs_get_block_info' line: 30 file: /GU/KERNEL_scrpn_build/linux/fs/yaffs2/yaffs_getblockinfo.h
[    2.522753] PCI: int=00000000 aer=00000000 uer=00000000 cer=00000000 debug=00004000 mac_phy=00888ae5 phy_mac=0127fefe err_cnt=00000000
[    2.535006] Kernel bug detected[#1]:
[    2.538589] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.60 #1
[    2.544393] task: 83c28000 ti: 83c2c000 task.ti: 83c2c000
[    2.549844] $ 0   : 00000000 00000001 00000038 8049f4fc
[    2.555112] $ 4   : 0000009d 00000000 00000000 00000000
[    2.560392] $ 8   : 00000064 00000000 00000000 0000009d
[    2.565672] $12   : 80540000 80540000 00000000 0000009c
[    2.570952] $16   : 00d70000 83f36000 83c2fa40 83f053c0
[    2.576244] $20   : 83f36000 000c0000 00d70000 83600000
[    2.581513] $24   : 00000003 00000000               
[    2.586792] $28   : 83c2c000 83c2f998 02400000 80196ed8
[    2.592073] Hi    : 0000002e
[    2.594988] Lo    : f33333ef
[    2.597891] Status: 1100dc03    KERNEL EXL IE
[    2.602107] Cause : 00800024 exc_code:9
[    2.606083] epc   : 80196ed8 0x80196ed8
[    2.609953] ra    : 80196ed8 0x80196ed8
[    2.613821]     Not tainted
[    2.616637] PrId  : 00019750 (MIPS 74Kc)
[    2.620621] Classified pointer on registers:
[    2.624910]  $ 3 : 8049f4fc 0x8049f4fc
[    2.628746]  $12 : 80540000 0x80540000
[    2.632480]  $13 : 80540000 0x80540000
[    2.636295]  $17 : 83f36000 [slab: type:kmalloc-4096 size:4096 start:0x83f36000+0x0]
[    2.644101]  $18 : 83c2fa40 [stack(swapper): 83c2c000+0x3a40]
[    2.649916]  $19 : 83f053c0 [slab: type:kmalloc-32 size:32 start:0x83f053c0+0x0]
[    2.657396]  $20 : 83f36000 [slab: type:kmalloc-4096 size:4096 start:0x83f36000+0x0]
[    2.665240]  $23 : 83600000 [page: type:alloc by:0x80119f1c]
[    2.670951]  $26 : 804133e8 0x804133e8
[    2.674723]  $27 : 83c2f99c [stack(swapper): 83c2c000+0x399c]
[    2.680532]  $28 : 83c2c000 [threadinfo(swapper): 83c2c000+0x0]
[    2.686516]  $29 : 83c2f998 [stack(swapper): 83c2c000+0x3998]
[    2.692329]  $31 : 80196ed8 0x80196ed8
[    2.696089] Modules linked in:
[    2.699174] Process swapper (pid: 1, threadinfo=83c2c000, task=83c28000, tls=00000000)
[    2.707189] Stack : 00000007 000000d7 00000000 00d60000 00000007 80530000 80540000 800ad10c
[    2.707189]       00000001 0000000a 00000040 00000021 00000031 80540000 00000000 00000000
[    2.707189]       00000001 00000001 00000000 00000031 80536278 804a0000 00000021 00000021
[    2.707189]       83f036a8 83f036a8 000000d6 8019bfd8 00000000 00000000 00000000 800ad5c4
[    2.707189]       00000000 00000001 ffffffe1 ff2a0000 83f053d0 00010000 00000000 00000000
[    2.707189]       ...
[    2.743111] Classified pointer on stack:
[    2.747053] 80530000 0x80530000
[    2.750223] 800ad10c 0x800ad10c
[    2.753445] 804a0000 0x804a0000
[    2.756585] 83f036a8 [slab: type:kmalloc-2048 size:2048 start:0x83f03000+0x6a8]
[    2.763963] 83f036a8 [slab: type:kmalloc-2048 size:2048 start:0x83f03000+0x6a8]
[    2.771353] 8019bfd8 0x8019bfd8
[    2.774531] 800ad5c4 0x800ad5c4
[    2.777707] 83f053d0 [slab: type:kmalloc-32 size:32 start:0x83f053c0+0x10]
[    2.784654] 80536682 0x80536682
[    2.787835] Call Trace:
[    2.790270] 39b8: [<800ad10c>] 0x800ad10c
[    2.794317] 3a08: [<8019bfd8>] 0x8019bfd8
[    2.798362] 3a18: [<800ad5c4>] 0x800ad5c4
[    2.802415] 3ab0: [<8019ad00>] 0x8019ad00
[    2.806459] 3ae8: [<80198868>] 0x80198868
[    2.810508] 3b28: [<8018f1d0>] 0x8018f1d0
[    2.814555] 3b48: [<80190310>] 0x80190310
[    2.818604] 3b80: [<80195a94>] 0x80195a94
[    2.822650] 3b84: [<80119ca4>] 0x80119ca4
[    2.826699] 3bc0: [<8018eb44>] 0x8018eb44
[    2.830750] 3c50: [<801d0d98>] 0x801d0d98
[    2.834793] 3c58: [<80122fdc>] 0x80122fdc
[    2.838843] 3c7c: [<8018ed50>] 0x8018ed50
[    2.842890] 3c88: [<8018ed68>] 0x8018ed68
[    2.846938] 3ca0: [<80123308>] 0x80123308
[    2.850987] 3cd8: [<8011a794>] 0x8011a794
[    2.855035] 3d08: [<8018b030>] 0x8018b030
[    2.859084] 3d1c: [<8018ed50>] 0x8018ed50
[    2.863130] 3d20: [<8013c0d8>] 0x8013c0d8
[    2.867178] 3d28: [<801240bc>] 0x801240bc
[    2.871227] 3d50: [<8013c18c>] 0x8013c18c
[    2.875274] 3d78: [<8013ecd4>] 0x8013ecd4
[    2.879322] 3d80: [<8011a794>] 0x8011a794
[    2.883370] 3d88: [<800ebce4>] 0x800ebce4
[    2.887418] 3da0: [<800fbbac>] 0x800fbbac
[    2.891467] 3dc0: [<800fbc6c>] 0x800fbc6c
[    2.895515] 3de4: [<80500000>] 0x80500000
[    2.899562] 3df0: [<8013f090>] 0x8013f090
[    2.903609] 3df8: [<804f275c>] 0x804f275c
[    2.907659] 3e28: [<804e3050>] 0x804e3050
[    2.911705] 3e30: [<8012f1e0>] 0x8012f1e0
[    2.915755] 3e68: [<804e2230>] 0x804e2230
[    2.919802] 3e74: [<80500000>] 0x80500000
[    2.923850] 3e88: [<804e2230>] 0x804e2230
[    2.927898] 3e98: [<804e347c>] 0x804e347c
[    2.931946] 3eb0: [<804e2230>] 0x804e2230
[    2.935994] 3ec0: [<804e2d1c>] 0x804e2d1c
[    2.940043] 3ee0: [<804e2230>] 0x804e2230
[    2.944092] 3f10: [<800649c0>] 0x800649c0
[    2.948138] 3f24: [<800649ac>] 0x800649ac
[    2.952185] 3f28: [<80060470>] 0x80060470
[    2.956234]
[    2.957712]
[    2.957712] Code: 3c048041  0c02ae2c  248433e8 <000c000d> 1000ffff  00000000  00a42823  8e23012c  02202025
[    2.967749] ---[ end trace 781ceda5ea0c73c4 ]---
-----
crashreport: read crash-variable '[0]3fa0613a,61162a91,1[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0'
crashreport: old parsed checksum[0].cs = 3fa0613a new_sum=3fa0613a (new_len=16305)
crashreport: crash-variable set to '[0]3fa0613a,61162a91,3[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0'
(first) sent on: Fri Aug 13 08:17:21 2021 UTC by crash report
----------
END SECTION '/proc/avm/log_sd/panic'

Seems to be this is the cause?

Code:

[    2.410050] squashfs: SQUASHFS error: unable to read id index table
[    2.416621] yaffs: dev is 32505856 name is "mtdblock0" ro
[    2.422055] yaffs: passed flags ""
[    2.425460] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    2.425470] yaffs: MTD device does not support have the right page sizes
[    2.425557] yaffs: dev is 32505856 name is "mtdblock0" ro
[    2.430977] yaffs: passed flags ""
[    2.434392] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    2.434401] yaffs: auto selecting inband tags
[    2.469371] yaffs: 214 blocks to be sorted...
[    2.469570] yaffs: **>> yaffs: get_block_info block 215 is not valid

baribal · 13 Aug 2021

@PeterPawn

Looks like this was the log from some other kernel panic.

Now I run the 7.01 recovery firmware which flashed all mtd partitions. Then I flashed the alien.image I've built using your instructions earlier. It is again spent ~8sec with the Power led lighting, then the leds switched off and then restart where I flashed again but this time just the kernel.image 7.01. Please find the support data file attached.

Code:

BEGIN SECTION '/proc/avm/log_sd/panic'
----------
UPTIME: 13
(0 d 0 h 0 min 13 s - panic on Thu Jan 01 00:00:13 1970 UTC )
Irregular Reboots: SUM(1) - KCRASH(1) (since last regular reboot/power-cut)
HW: 205.2
FW: 07.27
Bootloader: 1.2349
PANIC LOG VERSION 2.1
[    0.000000] Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.000000] bootconsole [early0] enabled
[    0.000000] DT @ 804c8040: d0 0d fe ed 00 00 1c 8e
[    0.000000] MIPS: machine is AVM FritzRepeater DVB-C
[    0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[    0.000000] Set Port base
[    0.000000] detect_sys_type
[    0.000000] SoC: Qualcomm Atheros QCA9556 ver 1 rev 0
[    0.000000] [plat_mem_setup] memsize 0x4000000, memstart 0x00000000
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] On node 0 totalpages: 16384
[    0.000000] free_area_init_node: node 0, pgdat 804993b0, node_mem_map 81005a80
[    0.000000]   Normal zone: 128 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 16384 pages, LIFO batch:3
[    0.000000] [fw-info] Version 07.27
[    0.000000] [module-mem] Use 0x01086000-0x0141dfff (mapped at 81086000-8141dfff) for 24 modules
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line:  gocommand console=ttyS0,115200n8r nor_size=0 sflash_size=16MB nand_size=0MB ethaddr=5C:49:79:4F:A8:8E
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] [mips_nmi_setup] setup NMI vector to base 0x80000380
[    0.000000] Memory: 55156K/65536K available (3602K kernel code, 337K rwdata, 636K rodata, 312K init, 732K bss, 10380K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:91
[    0.000000] Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, Ref:40.000MHz
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 5309056796 ns
[    0.000008] sched_clock: 32 bits at 360MHz, resolution 2ns, wraps every 5965232126ns
[    0.008314] console [ttyS0] enabled
[    0.015728] bootconsole [early0] disabled
[    0.024244] Calibrating delay loop... 359.42 BogoMIPS (lpj=718848)
[    0.054856] pid_max: default: 32768 minimum: 301
[    0.059617] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.066252] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.074295] Performance counters: mips/74K PMU enabled, 4 32-bit counters available to each CPU, irq 21
[    0.084853] devtmpfs: initialized
[    0.089143] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.098973] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.105756] NET: Registered protocol family 16
[    0.110560] console [avm0] enabled
[    0.114115] cpuidle: using governor ladder
[    0.118218] cpuidle: using governor menu
[    0.122141] Creating Config Table
[    0.125683] Enabling UART-Input for Pin 9
[    0.131944] MIPS: machine is AVM FritzRepeater DVB-C
[    0.148967] Can't analyze schedule() prologue at 80066bc8
[    0.154401] avm_check_cpu_features: mips-options: 0x40006d638b icache.flags 0x00000000 dcache.flags 0x00000004 isa_level 0x00000031 ases 00000051
[    0.167714] avm_alloc_page_extension node_extension_table[0] entries=16384 (size=65536)  alloced
[    0.176571] Reboot Status is: Power-On
[    0.180491] no support for hwid 205
[    0.183949] [avmnet] [avmnet_cfg_init] initializing
[    0.189086] [find_nmi_vector] no nmi vector found
[    0.456204] registering PCI controller with io_map_base unset
[    0.462066] PCI host bridge to bus 0000:00
[    0.466168] pci_bus 0000:00: root bus resource [mem 0x10000000-0x11ffffff]
[    0.473101] pci_bus 0000:00: root bus resource [io  0x0000]
[    0.478734] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[    0.485597] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    0.493637] pci 0000:00:00.0: [168c:003c] type 00 class 0x028000
[    0.493697] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[    0.493751] pci 0000:00:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[    0.493826] pci 0000:00:00.0: supports D1
[    0.493840] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[    0.494061] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[    0.494092] pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x101fffff 64bit]
[    0.501474] pci 0000:00:00.0: BAR 6: assigned [mem 0x10200000-0x1020ffff pref]
[    0.508741] pci 0000:00:00.0: using irq 80 for pin 1
[    0.514227] AVM PA for Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.514227]  (early init)
[    0.529867] clocksource: Switched to clocksource MIPS
[    0.536526] NET: Registered protocol family 2
[    0.541687] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    0.548730] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.555118] TCP: Hash tables configured (established 1024 bind 1024)
[    0.561609] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.567496] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.574055] avm_pa: try to activate hw accelaration for pid 3 (ipv4) called from 0x802f2bfc
[    0.582493] NET: Registered protocol family 1
[    0.586908] PCI: CLS 0 bytes, default 32
[    0.588130] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.594017] yaffs: yaffs Installing.
[    0.594357] io scheduler noop registered
[    0.598290] io scheduler deadline registered (default)
[    0.607177] ttyS0 at MMIO 0x18020000 (irq = 19, base_baud = 2500000) is a PORT_16550A
[    0.615679] [loadcontrol] set auto - scale=1
[    0.619970] [avm] configured: watchdog event debug
[    0.624851] AVM_WATCHDOG: Watchdog Driver for AR7 Hardware (Version 1.0)
[    0.631977] Register push button event to receive the set_factory_kernel event
[    0.639791] AVM Simple Profiling enabled Version 3.0
[    0.644789] [simple-profiling]:4 performance counters implemented, OLD_34K
[    0.652108] avm_net_trace: Up and running.
[    0.663051] loop: module loaded
[    0.666542] Registering ATH-flash-driver...
[    0.670796] [ath_flash] Use 3 byte addressing
[    0.698314] 6 avm_squashfs partitions found on MTD device ath-nor
[    0.704425] [TFFS3_Register_Panic_CB] registering panic callback for mtd ath-nor
[    0.711905] Creating 6 MTD partitions on "ath-nor":
[    0.716841] 0x00000019e600-0x000000f00000 : "rootfs"
[    0.722861] [rootfs] use mtd0 (rootfs) as root
[    0.727362] mtdsplit: no squashfs found in "rootfs"
[    0.732249] 0x000000020000-0x00000019e600 : "kernel"
[    0.738332] 0x000000000000-0x000000020000 : "urlader"
[    0.744405] 0x000000f00000-0x000000f80000 : "tffs (1)"
[    0.750635] 0x000000f80000-0x000001000000 : "tffs (2)"
[    0.756788] 0x000000000000-0x000001000000 : "reserved-kernel"
[    0.763600] Atheros on-chip NAND FLash Controller Driver, Version 1.0 (c) 2014 AVM GmbH, 2010 Atheros Communications, Ltd.
[    0.774866] tun: Universal TUN/TAP device driver, 1.6
[    0.779923] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[    0.786361] i2c /dev entries driver
[    0.790052] AVM PA for Linux Linux version 4.4.60 ([email protected]) (gcc version 5.5.0 (Buildroot 2018.11.4-gd289799ba7) ) #1 2021-04-08
[    0.790052]  (late init)
[    0.806375] gre: GRE over IPv4 demultiplexor driver
[    0.811345] NET: Registered protocol family 10
[    0.816715] avm_pa: try to activate hw accelaration for pid 4 (ipv6) called from 0x802f2bfc
[    0.825246] NET: Registered protocol family 17
[    0.829728] Bridge broadcast ratelimiter registered
[    0.834611] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[    0.847392] Bridge firewalling registered
[    0.851472] l2tp_core: L2TP core driver, V2.0
[    0.855814] l2tp_ip: L2TP IP encapsulation support (L2TPv3)
[    0.861464] l2tp_netlink: L2TP netlink interface
[    0.866147] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
[    0.872096] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
[    0.878631] 8021q: 802.1Q VLAN Support v1.8
[    0.883799] [TFFS3_Init] Called.
[    0.887036] [TFFS3_Init] No storage module registered, trying legacy fallback
[    0.894229] [TFFS3_CACHE_Configure] Setting up caching for backend legacy
[    0.901080] [TFFS3-CACHE] Caching module for TFFS 3.x
[    0.906187] [TFFS3_LGCY_Setup] using mtd3(tffs (1)), mtd4(tffs (2))
[    0.912526] [TFFS3_LGCY_Setup] mtd "tffs (1)": segment value 1
[    0.918420] [TFFS3_LGCY_Setup] mtd "tffs (2)": segment value 1
[    0.924310] [TFFS3_LGCY_Setup] Using segment 1 (avail: 1 + 1)
[    0.930117] [TFFS3_LGCY_Setup] mtd4 size=0x80000
[    0.935524] TFFS: tiny flash file system driver. GPL (c) AVM Berlin (Version 3.0)
[    0.943089] Adam2 environment variables API installed.
[    0.949343] {avmnet_cfg_netinit}
[    0.952586] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    0.962583] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    1.387068] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    2.594595] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    3.802088] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    5.009592] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    6.217066] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    7.424530] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    8.632018] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    9.110068] [0]system-load  54% loadavg 0.8 0.2 0.1 - pgstat: sum=13338 free=12998 slab=340 alloc=79/s (sleep 0)
[    9.850028] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   11.057544] avm_power: [avm_power_temperature] No cpu sensor registered
[   11.064212] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   12.271743] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   13.479254] [avmnet] [setup_phy] Giving up on hanging PHY ar8033 ID 0xffff
[   13.486205] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e
[   13.494719] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 8029cbfc
[   13.505450] PCI: int=00000000 aer=00000000 uer=00000000 cer=00000000 debug=00004111 mac_phy=00208850 phy_mac=038022c6 err_cnt=00000000
[   13.517669] set_reboot_status: Soft-Reboot(KCRASH)  - KCRASH(1)SUM(1)UP(13)UTC(13)FW(07.27)HW(205)HWS(2)BV(1.2349)
[   13.528137] Oops[#1]:
[   13.530404] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.60 #1
[   13.536207] task: 83c28000 ti: 83c2c000 task.ti: 83c2c000
[   13.541659] $ 0   : 00000000 00000000 00000000 00000000
[   13.546927] $ 4   : 83f05000 83c2fdac 00000000 00000004
[   13.552206] $ 8   : 805d0000 000000ff 805cced4 00000000
[   13.557486] $12   : 00000000 00000000 00000000 00000000
[   13.562766] $16   : 00000000 805d0000 805cced4 805cced4
[   13.568046] $20   : 804b5180 00000001 00000002 00000003
[   13.573326] $24   : 00000000 00000000              
[   13.578607] $28   : 83c2c000 83c2fd90 80521798 8029cbfc
[   13.583887] Hi    : 00000032
[   13.586802] Lo    : 0000053b
[   13.589695] Status: 1100dc03    KERNEL EXL IE
[   13.593933] Cause : 00800008 exc_code:2 TLBL
[   13.598241] BadVA : 00000000
[   13.601138] epc   : 00000000   (null)
[   13.604851] ra    : 8029cbfc 0x8029cbfc
[   13.608716]     Not tainted
[   13.611531] PrId  : 00019750 (MIPS 74Kc)
[   13.615533] Classified pointer on registers:
[   13.619805]  $ 4 : 83f05000 [slab: type:kmalloc-2048 size:2048 start:0x83f05000+0x0]
[   13.627641]  $ 5 : 83c2fdac [stack(swapper): 83c2c000+0x3dac]
[   13.633460]  $ 8 : 805d0000 0x805d0000
[   13.637238]  $10 : 805cced4 0x805cced4
[   13.641051]  $17 : 805d0000 0x805d0000
[   13.644798]  $18 : 805cced4 0x805cced4
[   13.648581]  $19 : 805cced4 0x805cced4
[   13.652366]  $20 : 804b5180 0x804b5180
[   13.656182]  $26 : 804b5180 0x804b5180
[   13.659947]  $27 : 83e46600 [slab: type:kmalloc-256 size:256 start:0x83e46600+0x0]
[   13.667595]  $28 : 83c2c000 [threadinfo(swapper): 83c2c000+0x0]
[   13.673578]  $29 : 83c2fd90 [stack(swapper): 83c2c000+0x3d90]
[   13.679383]  $30 : 80521798 0x80521798
[   13.683166]  $31 : 8029cbfc 0x8029cbfc
[   13.686946] Modules linked in:
[   13.690031] Process swapper (pid: 1, threadinfo=83c2c000, task=83c28000, tls=00000000)
[   13.698034] Stack : 805d0000 83e3da00 80521798 801d0d98 804b5180 83e3d9c0 804b5180 83e3d9c0
[   13.698034]       00000000 00000000 8028fda0 80291d30 83c7e2a0 000000cd 804b5040 83f05000
[   13.698034]       00000001 00000001 00000000 804b5040 805d0000 80450000 000000cd 00000000
[   13.698034]       804b4700 00000008 80530000 80292164 00000000 000000cd 00000002 00000000
[   13.698034]       00000000 80449608 368a0c06 80530000 80291da8 80490000 805054a8 00000000
[   13.698034]       ...
[   13.733940] Classified pointer on stack:
[   13.737899] 805d0000 0x805d0000
[   13.741073] 83e3da00 [slab: type:kmalloc-64 size:64 start:0x83e3da00+0x0]
[   13.747935] 80521798 0x80521798
[   13.751101] 801d0d98 0x801d0d98
[   13.754269] 804b5180 0x804b5180
[   13.757437] 83e3d9c0 [slab: type:kmalloc-64 size:64 start:0x83e3d9c0+0x0]
[   13.764317] 8028fda0 0x8028fda0
[   13.767470] 80291d30 0x80291d30
[   13.770648] 83c7e2a0 [slab: type:kmalloc-96 size:96 start:0x83c7e2a0+0x0]
[   13.777510] 804b5040 0x804b5040
[   13.780681] 83f05000 [slab: type:kmalloc-2048 size:2048 start:0x83f05000+0x0]
[   13.787894] 804b5040 0x804b5040
[   13.791053] 80450000 0x80450000
[   13.794236] 804b4700 0x804b4700
[   13.797386] 80292164 0x80292164
[   13.800585] 80449608 0x80449608
[   13.803735] 80291da8 0x80291da8
[   13.806894] 80490000 0x80490000
[   13.810061] 805054a8 0x805054a8
[   13.813226] 804e2230 0x804e2230
[   13.816399] 800697dc 0x800697dc
[   13.819565] 80490000 0x80490000
[   13.822732] 8016d97c 0x8016d97c
[   13.825909] 804a4688 0x804a4688
[   13.829058] 80500000 0x80500000
[   13.832238] 8016d674 0x8016d674
[   13.835402] Call Trace:
[   13.837873] 3da0: [<801d0d98>] 0x801d0d98
[   13.841921] 3dbc: [<8028fda0>] 0x8028fda0
[   13.845968] 3dc0: [<80291d30>] 0x80291d30
[   13.850018] 3e00: [<80292164>] 0x80292164
[   13.854066] 3e24: [<80291da8>] 0x80291da8
[   13.858113] 3e34: [<804e2230>] 0x804e2230
[   13.862160] 3e38: [<800697dc>] 0x800697dc
[   13.866209] 3e40: [<8016d97c>] 0x8016d97c
[   13.870257] 3e4c: [<80500000>] 0x80500000
[   13.874305] 3e50: [<8016d674>] 0x8016d674
[   13.878354] 3e70: [<8009be70>] 0x8009be70
[   13.882403] 3ebc: [<804e2230>] 0x804e2230
[   13.886449] 3ec0: [<804e2c90>] 0x804e2c90
[   13.890497] 3ee0: [<804e2230>] 0x804e2230
[   13.894546] 3f10: [<800649c0>] 0x800649c0
[   13.898593] 3f24: [<800649ac>] 0x800649ac
[   13.902640] 3f28: [<80060470>] 0x80060470
[   13.906689]
[   13.908165]
[   13.908165] Code:
[   13.910118]  (Bad address in epc)
[   13.913622]
[   13.915135] ---[ end trace e9f1382e446540ee ]---
-----
crashreport: read crash-variable '[0]3fa0613a,61162a91,3[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0'
crashreport: old parsed checksum[0].cs = 3fa0613a new_sum=3ee04352 (new_len=16113)
crashreport: crash-variable set to '[0]3ee04352,48,6[1]0,0,0[2]58259de,6114fd97,3[3]0,0,0'
(first) sent on: Thu Jan 01 00:01:12 1970 UTC by support data
----------
END SECTION '/proc/avm/log_sd/panic'

I guess this is smth to deal with "filesystem/etc/default.Fritz_Box_HW206/" inside the filesystem?

Code:

    0.949343] {avmnet_cfg_netinit}
[    0.952586] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    0.962583] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    1.387068] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    2.594595] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    3.802088] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    5.009592] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    6.217066] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    7.424530] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    8.632018] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    9.110068] [0]system-load  54% loadavg 0.8 0.2 0.1 - pgstat: sum=13338 free=12998 slab=340 alloc=79/s (sleep 0)
[    9.850028] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   11.057544] avm_power: [avm_power_temperature] No cpu sensor registered
[   11.064212] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   12.271743] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   13.479254] [avmnet] [setup_phy] Giving up on hanging PHY ar8033 ID 0xffff
[   13.486205] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e
[   13.494719] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 8029cbfc
[   13.505450] PCI: int=00000000 aer=00000000 uer=00000000 cer=00000000 debug=00004111 mac_phy=00208850 phy_mac=038022c6 err_cnt=00000000
[   13.517669] set_reboot_status: Soft-Reboot(KCRASH)  - KCRASH(1)SUM(1)UP(13)UTC(13)FW(07.27)HW(205)HWS(2)BV(1.2349)

PeterPawn · 13 Aug 2021

baribal schrieb:
Looks like this was the log from some other kernel panic.

OK, I've to start over with my research - I was already a bit irritated by this line from the other post:

baribal schrieb:
[ 0.000000] DT @ 804cbeb0: d0 0d fe ed 00 00 1f 38

The used (flattened) device tree lies perfectly within the configuration area (which starts at memory address 0x804c8000 and ends 96 KB further), but it has the wrong start address and the wrong size, too.

It will take some times and I can't immediately continue yet - what's the slogan from radio or TV broadcasts (something from the past)? Stay tuned.

EDIT:
There's obviously a first achievement:

Rich (BBCode):

[ 0.000000] DT @ 804c8040: d0 0d fe ed 00 00 1c 8e
[ 0.000000] MIPS: machine is AVM FritzRepeater DVB-C

baribal · 13 Aug 2021

@PeterPawn

I tried to copy:

filesystem/etc/default.Fritz_Box_HW206/
to
filesystem/etc/default.Fritz_Box_HW205/

Rebuilt the filesystem image with the tools/mksquashfs4-avm-be - the same kernel panic.

Code:

[    0.949416] {avmnet_cfg_netinit}
[    0.952657] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    0.962653] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    1.387133] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    2.594665] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    3.802162] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    5.009665] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    6.217154] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    7.424629] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    8.632126] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    9.110111] [0]system-load  54% loadavg 0.8 0.2 0.1 - pgstat: sum=13338 free=12998 slab=340 alloc=79/s (sleep 0)
[    9.850149] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   11.057670] avm_power: [avm_power_temperature] No cpu sensor registered
[   11.064344] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   12.271874] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   13.479393] [avmnet] [setup_phy] Giving up on hanging PHY ar8033 ID 0xffff
[   13.486346] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e
[   13.494859] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 8029cbfc
[   13.505590] PCI: int=00000000 aer=00000000 uer=00000000 cer=00000000 debug=00004111 mac_phy=002078e6 phy_mac=0380690d err_cnt=00000000
[   13.517810] set_reboot_status: Soft-Reboot(KCRASH)  - KCRASH(1)SUM(1)UP(13)UTC(13)FW(07.27)HW(205)HWS(2)BV(1.2349)

PeterPawn · 13 Aug 2021

baribal schrieb:
I guess this is smth to deal with "filesystem/etc/default.Fritz_Box_HW206/" inside the filesystem?

There's no SquashFS image found:

Rich (BBCode):

[    0.711905] Creating 6 MTD partitions on "ath-nor":
[    0.716841] 0x00000019e600-0x000000f00000 : "rootfs"
[    0.722861] [rootfs] use mtd0 (rootfs) as root
[    0.727362] mtdsplit: no squashfs found in "rootfs"
[    0.732249] 0x000000020000-0x00000019e600 : "kernel"
[    0.738332] 0x000000000000-0x000000020000 : "urlader"
[    0.744405] 0x000000f00000-0x000000f80000 : "tffs (1)"
[    0.750635] 0x000000f80000-0x000001000000 : "tffs (2)"
[    0.756788] 0x000000000000-0x000001000000 : "reserved-kernel"

The flash layout (from Linux's point of view) is as follows:

Rich (BBCode):

0x00000000 - 0x00020000 -> urlader (bootloader EVA)
0x00020000 - 0x00f00000 -> one "partition" containing the firmware image
0x00f00000 - 0x00f80000 -> first TFFS image
0x00f80000 - 0x01000000 -> second TFFS image

At startup, the filesystem scanner from kernel looks for the SquashFS magic in the second partition and splits it at this spot into the pure "kernel" and the "rootfs" partition. Obviously the correct position was found (the packed kernel size (in EVA format) was 0x17e600 and it starts at flash offset 0x020000 after the bootloader) and the splitted partitions were created - the riddle is now, what's the reason for the red line, when the partitions where created and their dimensions look good.

There's no "Mounted root [...] on [...]" message as from other devices (here from a 7580, but with a kernel version 4, too - if AVM changed some code from 3.10.x to 4.y.x):

Rich (BBCode):

[    0.000000] Linux version 4.9.198 ([email protected]) (gcc version 8.3.0 (Buildroot 2018.11.4-gc73018b701) ) #1 SMP 2021-04-13
[    0.000000] avm_check_isa_features: isa_level 0x00000031
[    0.000000] avm_check_cpu_features: mips-options (cache flags preliminary!): 0x000088c40e69638b ases 0x00000030
[    0.000000] avm_check_cpu_features: (preliminary flags: MIPS_CPU_CACHE_CDEX_P MIPS_CPU_PREFETCH MIPS_CPU_INCLUSIVE_CACHES MIPS_CPU_CACHE_CDEX_S)
[    0.000000] SoC: GRX500 rev 1.2
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0001a120 (MIPS interAptiv (multi))
[    0.000000] Enhanced Virtual Addressing (EVA Legacy 512MB) activated
[    0.000000] MIPS: machine is AVM7580 vrx318 (GRX550, HW225-1) Main model
[...]
[    6.102723] [announce_root] filesystem (/dev/mtdblock5) will be used as root device
[    6.123085] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.

Possibly this mtdsplit failure is from an additional search for further signatures and the mount wasn't logged, because the system died too early - but this theory can't make me believe immediately.

The later problem:

Rich (BBCode):

[    0.949343] {avmnet_cfg_netinit}
[    0.952586] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    0.962583] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    1.387068] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    2.594595] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    3.802088] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    5.009592] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    6.217066] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    7.424530] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    8.632018] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[    9.110068] [0]system-load  54% loadavg 0.8 0.2 0.1 - pgstat: sum=13338 free=12998 slab=340 alloc=79/s (sleep 0)
[    9.850028] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   11.057544] avm_power: [avm_power_temperature] No cpu sensor registered
[   11.064212] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   12.271743] [avmnet] [setup_phy] PHY ar8033 hanging, trying to reset it.
[   13.479254] [avmnet] [setup_phy] Giving up on hanging PHY ar8033 ID 0xffff
[   13.486205] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e

has to be solved, but this may get researched later, too - most likely the hardware description doesn't match here (those "alien games" aren't something with fast successes), maybe it's from a different location outside the configuration area (there wasn't a visible entry with a tag avm_kernel_config_tags_avmnet in 1750E's config area, afaik).

To grasp the problem with the kernel scanner better, a second log would be helpful (or what else? Right, a serial console output.

) for a comparison, how the messages are looking, if the rootfs gets mounted successfully. As far as I understood, the (unmodified) 1750E firmware works with the DVB-C model, too, and there's only a problem with the WLAN hardware. Instead of rushing through the kernel sources for 1750E, such a comparison may show the expected results much easier.

And by the way ... the final reason for the kernel crash seems to be a paging request for address 0x0:

Code:

[   13.494859] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 00000000, ra == 8029cbfc

- something that shouldn't occur ever (neither for a data nor for a code address). Whether the shown PC value (the address of the current instruction) is valid, may be doubted - but the return address could provide a hint, which code tried to use this address. Usually a value of 0x0 is a sign of any unresolved reference - but because the kernel is linked statically, it's either a "weak reference" or an attempt to load an address from a completely wrong location - both surely due to a wrong turn somewhere in the previously executed code. Maybe this wrong branch is the result of the wrong hardware description - so it must be the next building site, when the filesystem problem was solved (or it was discovered, that the messages are to be expected).

In neither case it's something with the filesystem image yet ... it's not mounted and therefore it's CONTENT can't be the reason of a problem. But this leads us to the filesystem itself ... to get the boot log (using dmesg) from the unmodified 1750E firmware, you'll need shell access. I don't know, whether you've read already, how to get it -but I'll describe it here again for later readers, too.

- unpack the filesystem image
- create a symlink in the unpacked structure as /usr/sbin/telnetd, which points to ../../bin/busybox
- add a service to start the daemon, using a file like this as /lib/systemd/system/telnetd.service:

Rich (BBCode):

[Unit]
ExecStart=/usr/sbin/telnetd -l /sbin/ar7login
Type=oneshot
After=net.service
[Install]
WantedBy=multi-user.target

- pack the filesystem again and use the image everywhere an original one would be used else
EDIT: A former version did show /usr/bin/telnetd as command to run - that's obviously wrong according to the symlink created a few lines above. I've changed it meanwhile.

This (re-)adds an (unconditionally started) telnet daemon - nothing else ... and I wouldn't make any further changes (like a SSH daemon or others) to a firmware, which is mainly intended to research some basics, because each additional difference may lead to a different behavior. This telnet daemon starts a bit too late ... but the other option with earlier access would be again the serial console. The buffered boot log gets overwritten later, when more messages have been generated - to get the log from the very beginning, the dmesg command should be used as soon as possible after the device has been started and the telnet session was established.

And if you've managed it with the 1750E 07.27 version, it would be "the cherry on top", if you do the same with the in-house firmware for your DVB-C repeater, too. There are no source files for this in-house version (afaik) and a boot log is the only option to see (or at least the simplest, beside searching in the unpacked kernel image), how a "normal" startup should look like and whether the 07.08 version uses the same kernel version as 07.27. Maybe it's documented elsewhere already (even for an in-house version) ... but I tend to make sure myself and to exclude any (possible) mistakes made by others earlier.

And now for something (not completely) different ... did you ever try to set HWRevision (persistently) to the 1750E's value (206)? I'd wrote something about this in an earlier post - if it's changeable persistently, the research for the reason and outcomes of:

Rich (BBCode):

[    0.180491] no support for hwid 205
[    0.183949] [avmnet] [avmnet_cfg_init] initializing

could be skipped (but it's immediately in front of the very first initialization of the avmnet module) ... at least it may be postponed and we could see, whether there's a difference and what the results are. I would tend to a second location somewhere in the kernel code, where an independent reference (beside the avm_kernel_config structures) is used.

And another (yet untelled) fact ... what are the original values from your DVB-C device for HWRevision und HWSubrevision? It's necessary to know them to be able to interpret some messages.

Based on the meanwhile detected differences I'd like to bet, that there wasn't a (functioning) "replace kernel" option ever for those devices with the Scorpion chipset (at least not with this kernel version). So we can't trust any assumptions, it had worked ever - it should leave us in doubt even, whether the source files are complete and for the right version/chipset. That's one more reason to challenge any earlier result from other devices - we have to check each conclusion, whether it's valid for these (unicorn?) devices from AVM's portfolio, too.

As far as I know, there were only three models using this chipset as "bare metal" processor - 450E, DVB-C and 1750E. Another use case of this chipset was WLAN hardware of some VR9-based models - but they're using a different kernel setup strategy, because they get most info from the "bare metal" operating system and various models by AVM with this WiSoC shared the same firmware image (for it) either.

baribal · 13 Aug 2021

PeterPawn schrieb:
Possibly this mtdsplit failure is from an additional search for further signatures and the mount wasn't logged, because the system died too early - but this theory can't make me believe immediately.

There are logs from the normal run I assume in the support data file (#73, attached file, line 7411). And there I see also:

Code:

[    0.925287]
[    0.925278] [TFFS3_Register_Panic_CB] registering panic callback for mtd ath-nor
[    0.932758] Creating 6 MTD partitions on "ath-nor":
[    0.937694] 0x000000198200-0x000000f00000 : "rootfs"
[    0.943757] mtd: device 0 (rootfs) set to be root filesystem
[    0.949481] mtdsplit: no squashfs found in "rootfs"
[    0.954369] 0x000000020000-0x000000198200 : "kernel"
[    0.960358] 0x000000000000-0x000000020000 : "urlader"
[    0.966404] 0x000000f00000-0x000000f80000 : "tffs (1)"
[    0.972532] 0x000000f80000-0x000001000000 : "tffs (2)"
[    0.978637] 0x000000000000-0x000001000000 : "reserved-kernel"

PeterPawn schrieb:
Rich (BBCode):

Code:

[COLOR=rgb(184, 49, 47)][B][ 0.180491] no support for hwid 205[/B][/COLOR] [ 0.183949] [avmnet] [avmnet_cfg_init] initializing

I see above in the normal run also (#73, attached file, line 7360):

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

PeterPawn schrieb:
And another (yet untelled) fact ... what are the original values from your DVB-C device for HWRevision und HWSubrevision? It's necessary to know them to be able to interpret some messages.

I assume 205 and 2

Code:

##### TITLE Version 133.07.01
##### TITLE SubVersion
##### TITLE Produkt Fritz_Box_HW205
##### TITLE Datum Thu Jan  1 01:00:51 CET 1970
##### BEGIN SECTION Support_Data Supportdata Linux fritz.repeater 4.4.60 #1 Wed Oct 31 11:52:23 CET 2018 mips Version 133.07.01
Support Data
------------
Thu Jan  1 01:00:52 CET 1970
4.4.60
HWRevision    205
HWSubRevision    2
ProductID    Fritz_Box_HW205

baribal · 13 Aug 2021

@PeterPawn

I couldn't connect via telnet unfortunately despite I did all steps you wrote and built the new FS image. However the support data file has the debug log since the very beginning (line 5634) and then also dmesg log inside. Please see attached.

Is it enough data?

baribal · 13 Aug 2021

@PeterPawn

And I've also just tried with the FTD from 7.01 firmware - the same issue.

PeterPawn · 13 Aug 2021

OK, got some info from this file (from #73):

- HWRevision 205
- HWSubrevision 2
- FRITZ!OS version (for this support data file) 07.01
- /dev/debug output starts too late

Code:

##### BEGIN SECTION debug Kernel output

/dev/debug
----------
[    0.084800] devtmpfs: initialized
[    0.089088] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.098920] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.105712] NET: Registered protocol family 16

, even if it shows the same message regarding mtdsplit:

Code:

[    0.932758] Creating 6 MTD partitions on "ath-nor":
[    0.937694] 0x000000198200-0x000000f00000 : "rootfs"
[    0.943757] mtd: device 0 (rootfs) set to be root filesystem
[    0.949481] mtdsplit: no squashfs found in "rootfs"
[    0.954369] 0x000000020000-0x000000198200 : "kernel"
[    0.960358] 0x000000000000-0x000000020000 : "urlader"
[    0.966404] 0x000000f00000-0x000000f80000 : "tffs (1)"
[    0.972532] 0x000000f80000-0x000001000000 : "tffs (2)"
[    0.978637] 0x000000000000-0x000001000000 : "reserved-kernel"
[    0.985416] Atheros on-chip NAND FLash Controller Driver, Version 1.0 (c) 2014 AVM GmbH, 2010 Atheros Communications, Ltd.

- dmesg output of the very first lines was overwritten already:

Code:

##### BEGIN SECTION dmesg
[   29.259455] ol_vdev_start_resp_ev for vap 0 (83d06000)
[   29.259471] ol_if_dfs_configure: called
[   29.259473] ol_if_dfs_configure: ETSI domain
[   29.259477] ol_if_dfs_disable: called
[   29.259767] ol_if_dfs_enable: called
[   29.259781] [SM] vap-0(ath1):ieee80211_state_event: VAP state event 1, cur_state=10, vap_deleted_is_set=0

- suddenly it turns out, that the DVB-C model uses a NMI vector gap, we didn't notice yet and (therefore) we didn't take into account yet:

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=0x00bf0000

- looking at the 1750E image for 07.27, it exists for this model, too:

Rich (BBCode):

vidar:/tmp/YourFritz $ unsquashfs4-avm -s -k kernel_1750E_07.27.image
Found a valid superblock at offset 0x0017E500 while scanning kernel_1750E_07.27.image.
NMI vector found at 0x00BE0000, size=4096
#
# It took the --scan option (-k for short) to reveal this vector ... this is from an older patch of mine for the squashfs-tools package.
#
Found TI checksum (0xD015B9E2) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on kernel_1750E_07.27.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12666.28 Kbytes (12.37 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 157
Number of inodes 3611
Number of ids 1

- as a result, we have to copy this area, too, and we have to take its size into account, while creating a new image - that's possibly the origin of problems, when kernel size changes and the NMI vector gap gets moved

Please don't get me wrong - even if those info may be extracted from the attached support data, I would like to insist on something - I want to get a "complete" boot log (starting with the very first line) and this in one continuous file (without other garbage). It makes it simpler to find the right places while switching between different logs ... if you have to gather it up from different places, it gets annoying rapidly.

Addendum: Meanwhile (it takes some time to present any commands run, esp. with some color as eye-catcher) your file for 1750E firmware version 07.27 (with a HWRevision mismatch) arrived - this reduces the open requests to a DVB-C 07.08 boot log (it could be nearer to the 07.27 firmware, even if it looks like all versions use the same Linux kernel 4.4.60) and a 07.27 log with a HWRevision value set to 205.

It doesn't mean, that other info from support data is useless ... but it's easier to read or to handle, when it gets dismantled first. Because that's true for other/further readers, too, it's better to do this for the attachments to a post already. Keep the complete file elsehow - but please add (at least one) more (only) with the requested info.

I would wait now for the answer (or some tries) regarding the persistently changed HWRevision value ... and its consequences.

Meanwhile the avmnet initialization seems really to be the next problem ... the mount process runs in parallel or immediately after this initialization:

Rich (BBCode):

[    1.171548] {avmnet_cfg_netinit}
[    1.174745] [avmnet] No config found for HWRev 205, HWSubRev 2, Profile-ID 0, trying base config for HWSubRev
[    1.184793] [avmnet] No config found for HWRev 205, HWSubRev 2, trying base config for HWRev
[    2.619859] [avmnet] [avmnet_ar8033_powerdown] Called for module ar8033
[    2.626545] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 5c:49:79:4f:a8:8e
[    2.639164] VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
[    2.651016] devtmpfs: mounted
[    2.655371] Freeing unused kernel memory: 268K (804cd000 - 80510000)
[    3.318467] [TFFS_Cache] Allocate segement buffer cache (size=32784)
[    3.325502] TFFS Name Table M

But it looks like, whether the two green lines are "normal" even with the proper firmware for the DVB-C repeater - it seems to be a fallback mechanism, which's intervening here, and the next question would be, why/whether it may find the hardware with the 1750E configuration, but not with the patched FDT for the DVB-C repeater. Maybe we've to look further into the FDT data ... but firstly we should solve the problem with any changes to the filesystem image. It has to be possible, to get shell access via telnet protocol - this should be one of the importants tasks at the moment.

This leads us back to the other problem ... some MIPS devices by AVM (the affected models are part of it) are using a 1:1 flash mapping during boot - either from a hardware mapping of addresses to a used NOR flash memory or for a SPI chip (your repeater uses 16 MB of this flash memory), which got its content copied to RAM before it gets called.

To handle NMI (non-maskable interrupt) exceptions from the very early initialization of a MIPS processor (which was done by EVA already, but is repeated by kernel again), a special address (0xBFC0000) is used to get "vectors" (they're simply addresses of code to branch to, depending on the condition, that has thrown the exception) for exception handling. This area gets relocated later (by loading a special register with the right address) and I'm not really sure, whether it's necessary for these models either - it's moreover a special case for those devices, where the kernel and filesystem image are stored as a continuous data stream in flash memory (means: models with a combined firmware image).

Both models have only a RAM size of 16 MB (0x01000000) and the vectors are looked up at 0x3FC00000 (after the "access type" flags from the upper two bits have been masked out) - that's far behind the available memory and it would only matter, if AVM wouldn't use/connect of some (upper) address lines ... and an access attempt on 0x3FC00000 therefore gets mapped to ~~0x00C00000~~ 0x03C00000 (edited: the device has 64 MB of RAM).

But let's assume, it does matter really (even if Freetz images are built without it either, as far as I know/remember) ... the repeater models are unique here, too, because their NMI vector gap is (usually) located behind the whole SquashFS image - simply due to their limited flash memory size. If we take the firmware partition offset from flash (0x20000, after the urlader part) into account, a NMI vector gap will be found at offset 0x00C00000 - 0x00020000 = 0x00BE0000 of a (complete) firmware image and the NMI vector table (it has a size of 4K for these models) may be located in-between the SquashFS image data (and has to be skipped while accessing data from filesystem) or after the firmware image, if the sum of (packed) kernel size and the size of our filesystem image is below this value (it's 12.451.840 in decimal). Here it's obviously in the middle of filesystem data and we don't need to append it after padding to 0xBE0000 size.

Let's have a look at the original file from AVM's firmware version 07.27 for 1750E:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> hexdump -C -s $(( 0xBE0000 - 64 )) -n $(( 4096 + 128 )) kernel_1750E_07.27.image
00bdffc0  2b 0d 9a f4 ea 2e 8c db  4a d2 aa 8d 71 46 ac ef  |+.......J...qF..|
00bdffd0  25 40 33 48 91 f5 19 26  14 f4 c4 85 db a9 40 62  |%@3H...&......@b|
00bdffe0  fb 02 5d e3 7a 61 7f b5  ab cf 92 7d 2b bc 1c db  |..].za.....}+...|
00bdfff0  6c c0 0f f6 57 1d dd 05  ac 12 7c 15 45 a8 6d 8f  |l...W.....|.E.m.|
00be0000  40 9a e8 05 40 9b e0 04  3c 1a 80 00 37 5a 03 80  |@...@...<...7Z..|
00be0010  8f 5b 00 0c 3b 7b de ad  14 1b 00 19 00 00 00 00  |.[..;{..........|
00be0020  40 1b e0 04 03 40 00 08  00 00 00 00 00 00 00 00  |@....@..........|
00be0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00be0040  00 dd d5 00 00 00 10 00  4e 4d 49 20 42 6f 6f 74  |........NMI Boot|
00be0050  20 56 65 63 74 6f 72 00  00 00 00 00 00 00 00 00  | Vector.........|
00be0060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be0080  3c 1a b8 06 8f 5b 00 08  33 7b 00 03 24 1a 00 02  |<....[..3{..$...|
00be0090  13 7a 00 03 00 00 00 00  10 00 00 0c 00 00 00 00  |.z..............|
00be00a0  3c 1b 10 00 3c 1a b8 06  af 5b 00 0c 00 00 00 0f  |<...<....[......|
00be00b0  8f 5b 00 0c 13 60 ff fa  24 1b 00 03 af 5b 00 08  |.[...`..$....[..|
00be00c0  00 00 00 0f 10 00 00 f2  00 00 00 00 3c 1a 80 00  |............<...|
00be00d0  37 5a 03 80 8f 5b 00 0c  3b 7b de ad 14 1b 00 02  |7Z...[..;{......|
00be00e0  00 00 00 00 27 5a 00 10  40 1b e0 04 03 40 00 08  |....'Z..@....@..|
00be00f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be0200  40 9a e8 05 40 9b e0 04  10 00 ff 9d 00 00 00 00  |@...@...........|
00be0210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be0380  40 9a e8 05 40 9b e0 04  10 00 ff 3d 00 00 00 00  |@...@......=....|
00be0390  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be0400  40 9a e8 05 40 9b e0 04  10 00 ff 1d 00 00 00 00  |@...@...........|
00be0410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be0480  40 9a e8 05 40 9b e0 04  10 00 fe fd 00 00 00 00  |@...@...........|
00be0490  3c 1a bd 00 37 5a 05 00  27 5a 00 0c af 41 00 00  |<...7Z..'Z...A..|
00be04a0  af 42 00 04 af 43 00 08  af 44 00 0c af 45 00 10  |.B...C...D...E..|
00be04b0  af 46 00 14 af 47 00 18  af 48 00 1c af 49 00 20  |.F...G...H...I. |
00be04c0  af 4a 00 24 af 4b 00 28  af 4c 00 2c af 4d 00 30  |.J.$.K.(.L.,.M.0|
00be04d0  af 4e 00 34 af 4f 00 38  af 50 00 3c af 51 00 40  |.N.4.O.8.P.<.Q.@|
00be04e0  af 52 00 44 af 53 00 48  af 54 00 4c af 55 00 50  |.R.D.S.H.T.L.U.P|
00be04f0  af 56 00 54 af 57 00 58  af 58 00 5c af 59 00 60  |.V.T.W.X.X.\.Y.`|
00be0500  40 1b e8 05 af 5b 00 64  40 1b e0 04 af 5b 00 68  |@....[.d@....[.h|
00be0510  af 5c 00 6c af 5d 00 70  af 5e 00 74 af 5f 00 78  |.\.l.].p.^.t._.x|
00be0520  40 1b 60 00 af 5b 00 7c  40 1b 68 00 af 5b 00 80  |@.`..[.|@.h..[..|
00be0530  40 1b 70 00 af 5b 00 84  40 1b f0 00 af 5b 00 88  |@.p..[..@....[..|
00be0540  40 1b 40 00 af 5b 00 8c  33 bb 00 03 17 60 00 5b  |@.@..[..3....`.[|
00be0550  00 00 d8 25 3c 1b 80 01  03 7d d8 2b 13 60 00 57  |...%<....}.+.`.W|
00be0560  00 00 d8 25 3c 1b 84 00  03 7d d8 2b 17 60 00 53  |...%<....}.+.`.S|
00be0570  00 00 d8 25 27 5a 00 90  8f bb 00 00 af 5b 00 00  |...%'Z.......[..|
00be0580  8f bb 00 04 af 5b 00 04  8f bb 00 08 af 5b 00 08  |.....[.......[..|
00be0590  8f bb 00 0c af 5b 00 0c  8f bb 00 10 af 5b 00 10  |.....[.......[..|
00be05a0  8f bb 00 14 af 5b 00 14  8f bb 00 18 af 5b 00 18  |.....[.......[..|
00be05b0  8f bb 00 1c af 5b 00 1c  8f bb 00 20 af 5b 00 20  |.....[..... .[. |
00be05c0  8f bb 00 24 af 5b 00 24  8f bb 00 28 af 5b 00 28  |...$.[.$...(.[.(|
00be05d0  8f bb 00 2c af 5b 00 2c  8f bb 00 30 af 5b 00 30  |...,.[.,...0.[.0|
00be05e0  8f bb 00 34 af 5b 00 34  8f bb 00 38 af 5b 00 38  |...4.[.4...8.[.8|
00be05f0  8f bb 00 3c af 5b 00 3c  8f bb 00 40 af 5b 00 40  |...<.[.<...@.[.@|
00be0600  8f bb 00 44 af 5b 00 44  8f bb 00 48 af 5b 00 48  |...D.[.D...H.[.H|
00be0610  8f bb 00 4c af 5b 00 4c  8f bb 00 50 af 5b 00 50  |...L.[.L...P.[.P|
00be0620  8f bb 00 54 af 5b 00 54  8f bb 00 58 af 5b 00 58  |...T.[.T...X.[.X|
00be0630  8f bb 00 5c af 5b 00 5c  8f bb 00 60 af 5b 00 60  |...\.[.\...`.[.`|
00be0640  8f bb 00 64 af 5b 00 64  8f bb 00 68 af 5b 00 68  |...d.[.d...h.[.h|
00be0650  8f bb 00 6c af 5b 00 6c  8f bb 00 70 af 5b 00 70  |...l.[.l...p.[.p|
00be0660  8f bb 00 74 af 5b 00 74  8f bb 00 78 af 5b 00 78  |...t.[.t...x.[.x|
00be0670  8f bb 00 7c af 5b 00 7c  8f bb 00 80 af 5b 00 80  |...|.[.|.....[..|
00be0680  8f bb 00 84 af 5b 00 84  8f bb 00 88 af 5b 00 88  |.....[.......[..|
00be0690  8f bb 00 8c af 5b 00 8c  8f bb 00 90 af 5b 00 90  |.....[.......[..|
00be06a0  8f bb 00 94 af 5b 00 94  8f bb 00 98 af 5b 00 98  |.....[.......[..|
00be06b0  8f bb 00 9c af 5b 00 9c  3c 1b 00 a0 3c 1a bd 00  |.....[..<...<...|
00be06c0  37 5a 05 00 37 7b 00 90  af 5b 00 08 3c 1b 53 54  |7Z..7{...[..<.ST|
00be06d0  37 7b 41 31 af 5b 00 00  3c 1b 44 55 37 7b 4d 50  |7{A1.[..<.DU7{MP|
00be06e0  af 5b 00 04 10 00 fe 79  00 00 00 00 00 00 00 00  |.[.....y........|
00be06f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be1000  a4 3e f0 8a b7 9b 42 d4  41 e8 8a 85 e3 a6 45 04  |.>....B.A.....E.|
00be1010  3a 5d 59 4d 22 9a 2d 7d  64 2b 6f b4 75 40 4d 57  |:]YM".-}d+o.u@MW|
00be1020  d1 5a c4 c5 f3 6e 4e 40  8d fd e9 11 10 a0 32 25  |[email protected]%|
00be1030  94 27 33 6a 29 a4 57 3b  04 99 38 d1 79 f5 6b 7b  |.'3j).W;..8.y.k{|
00be1040
peh@vidar:/tmp/YourFritz>

The whole data between 0x00be0000 and 0xbe1000 have to be copied from the original image to the "alien image" ... but at the same offset and the remaining data of the alien image (starting at 0x00be0000 before any further action) have to be appended after this copy.

But let's verify first, whether the older findings are still valid for newer versions ... there has to be some code (anywhere) to ensure, that this gap is skipped properly - or AVM has made it's own version of SquashFS utilities (it's an ever-lasting riddle to me, why AVM doesn't publish the source code for the changed squashfs-tools project, too ... my only guess is it, that these changes are so creepy, wild and weird, that noone in the public should get a look at), where this area is taken into account for each pointer, which belongs to an address behind it. Earlier versions by AVM (for other models) had some code in their flash driver to assure, that this area was skipped while reading.

The easiest approach to verify, whether this area was taken into account by the used mksquashfs tool (or however it's called by AVM), is to unpack the (already splitted) filesystem - once containing the NMI boot vector table and once without it:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> dd if=kernel_1750E_07.27.image of=filesystem.image bs=256 skip=$(( 1565952 / 256 ))
50688+1 records in
50688+1 records out
12976136 bytes (13 MB, 12 MiB) copied, 0.366917 s, 35.4 MB/s
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -s -k filesystem.image
Found a valid superblock at offset 0x00000000 while scanning filesystem.image.
NMI vector found at 0x00A61B00, size=4096
Found TI checksum (0xD015B9E2) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on filesystem.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12666.28 Kbytes (12.37 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 157
Number of inodes 3611
Number of ids 1
#
# OK, -stat looks fine (the NMI gap was moved as expected due to the now missing kernel image at the beginning),
# but what's while really unpacking this image?
#
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -k filesystem.image
Found a valid superblock at offset 0x00000000 while scanning filesystem.image.
NMI vector found at 0x00A61B00, size=4096
Found TI checksum (0xD015B9E2) at the end of the image.
Filesystem on filesystem.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
3344 inodes (3819 blocks) to write

[=========[...]=========|] 3819/3819 100%

created 2965 files
created 267 directories
created 379 symlinks
created 0 devices
created 0 fifos
#
# seems to be fine, too
# now let's remove the NMI vector before we try to unpack again
#
peh@vidar:/tmp/YourFritz> ( dd if=filesystem.image bs=256 count=$(( 0xA61B )); dd if=filesystem.image bs=256 skip=$(( 0xA61B + ( 4096 / 256 ) )) ) > filesystem_without_nmi_vector.image
42523+0 records in
42523+0 records out
10885888 bytes (11 MB, 10 MiB) copied, 0.298477 s, 36.5 MB/s
8149+1 records in
8149+1 records out
2086152 bytes (2.1 MB, 2.0 MiB) copied, 0.0563451 s, 37.0 MB/s
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -s -k filesystem_without_nmi_vector.image
Found a valid superblock at offset 0x00000000 while scanning filesystem_without_nmi_vector.image.
Found TI checksum (0xD015B9E2) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on filesystem_without_nmi_vector.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12666.28 Kbytes (12.37 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 157
Number of inodes 3611
Number of ids 1
peh@vidar:/tmp/YourFritz> sudo rm -r squashfs-root/
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -k filesystem.image
Found a valid superblock at offset 0x00000000 while scanning filesystem_without_nmi_vector.image.
Found TI checksum (0xD015B9E2) at the end of the image.
Filesystem on filesystem_without_nmi_vector.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
3344 inodes (3819 blocks) to write

[=========[...]=========|] 3819/3819 100%

created 2965 files
created 267 directories
created 379 symlinks
created 0 devices
created 0 fifos
#
# unpacking is possible, no more NMI vector found
#
peh@vidar:/tmp/YourFritz>

Looks like there's really some code elsewhere - I'd bet, it's still anywhere in the flash (chip) driver (this gap is known to ath_flash, according to some boot log lines). But that means at the same time, that we can use the NMI vector table from AVM's firmware image and insert it (at the right place naturally) - but it should be the one for the same kernel, because it's highly presumable, it contains any absolute addresses and will be valid for a special kernel only. (This could be another problem while using an own kernel - if the entry points get moved, an absolute address (if any) has to be recomputed. Luckily this vector table is only needed, if any NMI exception occurs while the table wasn't relocated already.)

Let's try this again using dd:

Rich (BBCode):

peh@vidar:/tmp/YourFritz> dd if=kernel_1750E_07.27.image of=nmi_vector bs=4096 skip=$(( 0xBE0000 / 4096 )) count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0164954 s, 248 kB/s
#
# verify contents
#
peh@vidar:/tmp/YourFritz> hexdump -C nmi_vector
00000000  40 9a e8 05 40 9b e0 04  3c 1a 80 00 37 5a 03 80  |@...@...<...7Z..|
00000010  8f 5b 00 0c 3b 7b de ad  14 1b 00 19 00 00 00 00  |.[..;{..........|
00000020  40 1b e0 04 03 40 00 08  00 00 00 00 00 00 00 00  |@....@..........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 dd d5 00 00 00 10 00  4e 4d 49 20 42 6f 6f 74  |........NMI Boot|
00000050  20 56 65 63 74 6f 72 00  00 00 00 00 00 00 00 00  | Vector.........|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  3c 1a b8 06 8f 5b 00 08  33 7b 00 03 24 1a 00 02  |<....[..3{..$...|
00000090  13 7a 00 03 00 00 00 00  10 00 00 0c 00 00 00 00  |.z..............|
000000a0  3c 1b 10 00 3c 1a b8 06  af 5b 00 0c 00 00 00 0f  |<...<....[......|
000000b0  8f 5b 00 0c 13 60 ff fa  24 1b 00 03 af 5b 00 08  |.[...`..$....[..|
000000c0  00 00 00 0f 10 00 00 f2  00 00 00 00 3c 1a 80 00  |............<...|
000000d0  37 5a 03 80 8f 5b 00 0c  3b 7b de ad 14 1b 00 02  |7Z...[..;{......|
000000e0  00 00 00 00 27 5a 00 10  40 1b e0 04 03 40 00 08  |....'Z..@....@..|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  40 9a e8 05 40 9b e0 04  10 00 ff 9d 00 00 00 00  |@...@...........|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000380  40 9a e8 05 40 9b e0 04  10 00 ff 3d 00 00 00 00  |@...@......=....|
00000390  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  40 9a e8 05 40 9b e0 04  10 00 ff 1d 00 00 00 00  |@...@...........|
00000410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000480  40 9a e8 05 40 9b e0 04  10 00 fe fd 00 00 00 00  |@...@...........|
00000490  3c 1a bd 00 37 5a 05 00  27 5a 00 0c af 41 00 00  |<...7Z..'Z...A..|
000004a0  af 42 00 04 af 43 00 08  af 44 00 0c af 45 00 10  |.B...C...D...E..|
000004b0  af 46 00 14 af 47 00 18  af 48 00 1c af 49 00 20  |.F...G...H...I. |
000004c0  af 4a 00 24 af 4b 00 28  af 4c 00 2c af 4d 00 30  |.J.$.K.(.L.,.M.0|
000004d0  af 4e 00 34 af 4f 00 38  af 50 00 3c af 51 00 40  |.N.4.O.8.P.<.Q.@|
000004e0  af 52 00 44 af 53 00 48  af 54 00 4c af 55 00 50  |.R.D.S.H.T.L.U.P|
000004f0  af 56 00 54 af 57 00 58  af 58 00 5c af 59 00 60  |.V.T.W.X.X.\.Y.`|
00000500  40 1b e8 05 af 5b 00 64  40 1b e0 04 af 5b 00 68  |@....[.d@....[.h|
00000510  af 5c 00 6c af 5d 00 70  af 5e 00 74 af 5f 00 78  |.\.l.].p.^.t._.x|
00000520  40 1b 60 00 af 5b 00 7c  40 1b 68 00 af 5b 00 80  |@.`..[.|@.h..[..|
00000530  40 1b 70 00 af 5b 00 84  40 1b f0 00 af 5b 00 88  |@.p..[..@....[..|
00000540  40 1b 40 00 af 5b 00 8c  33 bb 00 03 17 60 00 5b  |@.@..[..3....`.[|
00000550  00 00 d8 25 3c 1b 80 01  03 7d d8 2b 13 60 00 57  |...%<....}.+.`.W|
00000560  00 00 d8 25 3c 1b 84 00  03 7d d8 2b 17 60 00 53  |...%<....}.+.`.S|
00000570  00 00 d8 25 27 5a 00 90  8f bb 00 00 af 5b 00 00  |...%'Z.......[..|
00000580  8f bb 00 04 af 5b 00 04  8f bb 00 08 af 5b 00 08  |.....[.......[..|
00000590  8f bb 00 0c af 5b 00 0c  8f bb 00 10 af 5b 00 10  |.....[.......[..|
000005a0  8f bb 00 14 af 5b 00 14  8f bb 00 18 af 5b 00 18  |.....[.......[..|
000005b0  8f bb 00 1c af 5b 00 1c  8f bb 00 20 af 5b 00 20  |.....[..... .[. |
000005c0  8f bb 00 24 af 5b 00 24  8f bb 00 28 af 5b 00 28  |...$.[.$...(.[.(|
000005d0  8f bb 00 2c af 5b 00 2c  8f bb 00 30 af 5b 00 30  |...,.[.,...0.[.0|
000005e0  8f bb 00 34 af 5b 00 34  8f bb 00 38 af 5b 00 38  |...4.[.4...8.[.8|
000005f0  8f bb 00 3c af 5b 00 3c  8f bb 00 40 af 5b 00 40  |...<.[.<...@.[.@|
00000600  8f bb 00 44 af 5b 00 44  8f bb 00 48 af 5b 00 48  |...D.[.D...H.[.H|
00000610  8f bb 00 4c af 5b 00 4c  8f bb 00 50 af 5b 00 50  |...L.[.L...P.[.P|
00000620  8f bb 00 54 af 5b 00 54  8f bb 00 58 af 5b 00 58  |...T.[.T...X.[.X|
00000630  8f bb 00 5c af 5b 00 5c  8f bb 00 60 af 5b 00 60  |...\.[.\...`.[.`|
00000640  8f bb 00 64 af 5b 00 64  8f bb 00 68 af 5b 00 68  |...d.[.d...h.[.h|
00000650  8f bb 00 6c af 5b 00 6c  8f bb 00 70 af 5b 00 70  |...l.[.l...p.[.p|
00000660  8f bb 00 74 af 5b 00 74  8f bb 00 78 af 5b 00 78  |...t.[.t...x.[.x|
00000670  8f bb 00 7c af 5b 00 7c  8f bb 00 80 af 5b 00 80  |...|.[.|.....[..|
00000680  8f bb 00 84 af 5b 00 84  8f bb 00 88 af 5b 00 88  |.....[.......[..|
00000690  8f bb 00 8c af 5b 00 8c  8f bb 00 90 af 5b 00 90  |.....[.......[..|
000006a0  8f bb 00 94 af 5b 00 94  8f bb 00 98 af 5b 00 98  |.....[.......[..|
000006b0  8f bb 00 9c af 5b 00 9c  3c 1b 00 a0 3c 1a bd 00  |.....[..<...<...|
000006c0  37 5a 05 00 37 7b 00 90  af 5b 00 08 3c 1b 53 54  |7Z..7{...[..<.ST|
000006d0  37 7b 41 31 af 5b 00 00  3c 1b 44 55 37 7b 4d 50  |7{A1.[..<.DU7{MP|
000006e0  af 5b 00 04 10 00 fe 79  00 00 00 00 00 00 00 00  |.[.....y........|
000006f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
peh@vidar:/tmp/YourFritz> printf "%08X\n" "$(stat -c %s kernel.padded)"
0017E600
peh@vidar:/tmp/YourFritz> printf "%08X\n" "$(stat -c %s filesystem_without_nmi_vector.image)"
00C5F008
peh@vidar:/tmp/YourFritz> printf "%08X\n" $(( "$(stat -c %s filesystem_without_nmi_vector.image)" + "$(stat -c %s kernel.padded)" ))
00DDD608
peh@vidar:/tmp/YourFritz> printf "%u\n" $(( "$(stat -c %s filesystem_without_nmi_vector.image)" + "$(stat -c %s kernel.padded)" ))
14538248
peh@vidar:/tmp/YourFritz> printf "%u\n" $(( "$(stat -c %s filesystem_without_nmi_vector.image)" + "$(stat -c %s kernel.padded)" + "$(stat -c %s nmi_vector)" ))
14542344
#
# It's the expected file size of the final image, for a first quick check.
#
peh@vidar:/tmp/YourFritz> cat kernel.padded filesystem_without_nmi_vector.image > alien_without_nmi_vector.image
peh@vidar:/tmp/YourFritz> ls -l alien_without_nmi_vector.image
-rw-r--r-- 1 peh users 14538248 Aug 13 17:51 alien_without_nmi_vector.image
#
# expected size after 1st step
#
peh@vidar:/tmp/YourFritz> hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 alien_without_nmi_vector.image
00bdffc0  57 f3 b0 e1 e7 e8 d7 cd  32 5b 77 bf 40 b1 1e 83  |W.......2[w.@...|
00bdffd0  77 74 9d ea 08 f4 4a c4  4c 39 d7 01 e0 be 8d 65  |wt....J.L9.....e|
00bdffe0  8f c8 cf 0a 7c 6b 7e 2a  cd 27 5b 73 58 e0 e5 39  |....|k~*.'[sX..9|
00bdfff0  49 9a 41 f4 16 d4 84 7a  bb 9a 89 ff 02 7f 1a 23  |I.A....z.......#|
00be0000  47 1c a6 31 94 3a c0 cb  c6 a3 16 05 07 39 0c 6f  |G..1.:.......9.o|
00be0010  ad df 70 7b d3 7d 0a 59  87 3f 90 2f 28 94 46 e3  |..p{.}.Y.?./(.F.|
00be0020  af 4c 35 48 b6 01 5c d7  b1 55 9c 28 1b d1 f6 b3  |.L5H..\..U.(....|
00be0030  6c a7 e6 d7 94 cb 35 4c  f2 b1 5f cb ba 8c 0e 2e  |l.....5L.._.....|
00be0040
#
# The expected data before and after the inserted NMI vector table.
#
peh@vidar:/tmp/YourFritz> ( dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) count=$(( 0xBE )); \
> cat nmi_vector; dd if=alien_without_nmi_vector.image bs=$(( 0x10000 )) skip=$(( 0xBE )) ) > alien_with_nmi_vector.image
190+0 records in
190+0 records out
12451840 bytes (12 MB, 12 MiB) copied, 0.0154672 s, 805 MB/s
31+1 records in
31+1 records out
2086408 bytes (2.1 MB, 2.0 MiB) copied, 0.00233252 s, 894 MB/s
peh@vidar:/tmp/YourFritz> ls -l alien*.image
-rw-r--r-- 1 peh users 14542344 Aug 13 18:01 alien_with_nmi_vector.image
-rw-r--r-- 1 peh users 14538248 Aug 13 17:51 alien_without_nmi_vector.image
#
# Size looks fine, too.
#
peh@vidar:/tmp/YourFritz> hexdump -C -s $(( 0xBE0000 - 64 )) -n 128 alien_with_nmi_vector.image
00bdffc0  57 f3 b0 e1 e7 e8 d7 cd  32 5b 77 bf 40 b1 1e 83  |W.......2[w.@...|
00bdffd0  77 74 9d ea 08 f4 4a c4  4c 39 d7 01 e0 be 8d 65  |wt....J.L9.....e|
00bdffe0  8f c8 cf 0a 7c 6b 7e 2a  cd 27 5b 73 58 e0 e5 39  |....|k~*.'[sX..9|
00bdfff0  49 9a 41 f4 16 d4 84 7a  bb 9a 89 ff 02 7f 1a 23  |I.A....z.......#|
00be0000  40 9a e8 05 40 9b e0 04  3c 1a 80 00 37 5a 03 80  |@...@...<...7Z..|
00be0010  8f 5b 00 0c 3b 7b de ad  14 1b 00 19 00 00 00 00  |.[..;{..........|
00be0020  40 1b e0 04 03 40 00 08  00 00 00 00 00 00 00 00  |@....@..........|
00be0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00be0040
peh@vidar:/tmp/YourFritz> hexdump -C -s $(( 0xBE1000 - 64 )) -n 128 alien_with_nmi_vector.image
00be0fc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00be1000  47 1c a6 31 94 3a c0 cb  c6 a3 16 05 07 39 0c 6f  |G..1.:.......9.o|
00be1010  ad df 70 7b d3 7d 0a 59  87 3f 90 2f 28 94 46 e3  |..p{.}.Y.?./(.F.|
00be1020  af 4c 35 48 b6 01 5c d7  b1 55 9c 28 1b d1 f6 b3  |.L5H..\..U.(....|
00be1030  6c a7 e6 d7 94 cb 35 4c  f2 b1 5f cb ba 8c 0e 2e  |l.....5L.._.....|
00be1040
#
# Everything seems to be fine up to this step - now let's try to unpack it again.
#
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -s -k alien_with_nmi_vector.image
Found a valid superblock at offset 0x0017E600 while scanning alien_with_nmi_vector.image.
NMI vector found at 0x00BE0000, size=4096
Found TI checksum (0xD015B9E2) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on alien_with_nmi_vector.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12666.28 Kbytes (12.37 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 157
Number of inodes 3611
Number of ids 1
peh@vidar:/tmp/YourFritz> sudo rm -r squashfs-root/
peh@vidar:/tmp/YourFritz> unsquashfs4-avm -k alien_with_nmi_vector.image
Found a valid superblock at offset 0x0017E600 while scanning alien_with_nmi_vector.image.
NMI vector found at 0x00BE0000, size=4096
Found TI checksum (0xD015B9E2) at the end of the image.
Filesystem on alien_with_nmi_vector.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
3344 inodes (3819 blocks) to write

[=========[...]=========|] 3819/3819 100%

created 2965 files
created 267 directories
created 379 symlinks
created 0 devices
created 0 fifos
peh@vidar:/tmp/YourFritz>

Everything looks perfect - while "replaying" the commands, it's naturally not necessary to verify each step as excessive, as I did it above.

But that was one problem only ... let's try now to find, why you do not get a telnet daemon running - it's absolutely necessary later, too, while doing further research.

Please restart your modifications of the filesystem image once more (best from a freshly extracted one) ... but this time provide the whole log, starting with unsquashfs (or even grep and dd) and ending with mksquashfs (and best an immediate attempt to unpack the image just once again). Some times anyone may be blind for own failures ... this could be the same for my examples, but while reading this from someone else, a problem can be found better (at least this is true for myself).

Freetz für AVM DVB-C Repeater verfügbar?

IPPF-Urgestein

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Anhänge

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

Anhänge

Neuer User

Anhänge

IPPF-Urgestein

Statistik des Forums