[HowTo] Wie erstell ich aus einem .image ein .inmemory

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
373
Punkte für Reaktionen
52
Punkte
28
Dies funktioniert mit allen Images, also von AVM, Freetz, modfs, Freetz-NG, ...

aus push-firmware
Code:
tar xf DAS.image
for f in ./var/tmp/kernel.image ./var/tmp/filesystem.image; do
FREETZVERZEICHNIS/tools/tichksum -r $f >/dev/null
dd if=$f bs=256 conv=sync 2>/dev/null
done > NEUES.inmemory

Scipt in freetz-ng
Code:
FREETZVERZEICHNIS/tools/image2inmemory DAS.image NEUES.inmemory

PeterPawn in #7 freetz
Code:
FREETZVERZEICHNIS/tools/yf/eva_tools/image2ram < DAS.image > NEUES.inmemory

PeterPawn in #7 yourfritz
Code:
wget -q https://raw.githubusercontent.com/PeterPawn/YourFritz/master/eva_tools/image2ram
cat DAS.image | sh ./image2ram > NEUES.inmemory


Noch einfacher geht es mit "tools/push_firmware" aus Freetz-NG
Dieses flasht .image-Dateien direkt, egal ob alte Fritzboxen, neue "nand" Fritzboxen, alte "Docsis" oder die neuen "uimg"-Docsis
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1 und gismotro
Werde es mal testen und berichten.
 
geht es mit der push_firmware für die F!B 7590 in Win, ewtl. mit Powershell?
 
Probier das mal besser mit dem neuen Terminal (aus dem Microsoft-Store) und der Ubuntu 18.04 Erweiterung dafür (ist ja alles kostenlos).
Das sollte klappen.
 
Dies funktioniert mit allen Images, also von AVM, Freetz, modfs, Freetz-NG, ...
Hast Du das wenigstens einmal selbst mit einem AVM-Image in dieser Form probiert? Was meinst Du, warum mein "image2ram" da nicht nur aus 2x Extrahieren und 1x Zusammenkopieren besteht?

Rich (BBCode):
peh@vidar:/tmp/7490> wget -qO- https://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.21.image | tar -xO ./var/tmp/filesystem.image >filesystem.image
peh@vidar:/tmp/7490> wget -qO- https://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.21.image | tar -xO ./var/tmp/kernel.image >kernel.image
peh@vidar:/tmp/7490> cat kernel.image filesystem.image >113.07.21.image
peh@vidar:/tmp/7490> ls -l
total 66108
-rw-r--r-- 1 peh users 33842192 Sep 21 10:57 113.07.21.image
-rw-r--r-- 1 peh users 31154184 Sep 21 10:56 filesystem.image
-rw-r--r-- 1 peh users  2688008 Sep 21 10:56 kernel.image
peh@vidar:/tmp/7490> git clone https://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
remote: Enumerating objects: 93, done.
remote: Counting objects: 100% (93/93), done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 3458 (delta 54), reused 73 (delta 38), pack-reused 3365
Receiving objects: 100% (3458/3458), 4.02 MiB | 5.36 MiB/s, done.
Resolving deltas: 100% (2208/2208), done.
peh@vidar:/tmp/7490> cd YourFritz/eva_tools/
peh@vidar:/tmp/7490/YourFritz/eva_tools> eval $(./eva_discover INTERFACE=vlan7 FROM=192.168.130.2 TO=192.168.130.1 BLIP=1);[ "$EVA_FOUND" = "1" ] && ./eva_to_memory ../../113.07.21.image $EVA_IP
Found AVM bootloader: AVM EVA Version 1.1964 0x0 0x740D
Found hardware revision: 185
Memory size is 0x10000000 (256 MB)
Memory size limited to 128 MB
Image size is 0x2046410 (32 MB)
Setting temporary memory size to: 0x05fb9bf0
Setting temporary kernel args to: mtdram1=0x85fb9bf0,0x88000000
Image uploaded to device.
peh@vidar:/tmp/7490/YourFritz/eva_tools>
Meanwhile in another universe (it's a serial-attached console for the used device) ...
Rich (BBCode):
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000
[\]

(AVM) EVA Revision: 1.1964 Version: 2964
(C) Copyright 2005 AVM Date: Nov 27 2013 Time: 14:33:10 (1) 3 0x0-0x740D

[FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 16 sectors a 64kB)
[NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
[SYSTEM:] VR9 on 500MHz/250MHz/250MHz

.Atheros 8030/35 detected

Eva_AVM >

.............................................................
Lantiq xDSL CPE VR9
phym = 05fb9bf0, mem = 05fb9bf0, max_pfn = 00005fb9
Reserving memory for CP1 @0xa5fb9bf0, size 0x00000000
plat_device_tree_setup: AVM hardware subrevision 3
plat_device_tree_setup: using Fallback device-tree of AVM hardware subrevision 0
DT: d0 0d fe ed 00 00 14 36
[    0.000000] Linux version 3.10.107 (jenkins@edxbuildxjplxpsq19p1xvr9xavmdect) (collect2: error: ld returned 1 exit status) #1 SMP Mon Aug 17 17:21:20 CEST 2020
[    0.000000] [env_init] 0x81018160[0]
[    0.000000] [env_init] 0x810181a0[1]
[    0.000000] [env_init] 0x810182a0[2]
[    0.000000] [env_init] switch to ram location
[    0.000000] [init_avm_kernel_config] AVM Kernel Config (ptr 80892000)
[    0.000000] [init_avm_kernel_config] AVM Kernel Config: module memory entry
[    0.000000] [init_avm_kernel_config] AVM Kernel Config: version info entry
[    0.000000] [init_avm_kernel_config] AVM Kernel Config: device-tree for subrev 0 found
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00019556 (MIPS 34Kc)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 05fb9bf0 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] [module-alloc] use 0x79f000 bytes at 0x810c4000
[    0.000000] Detected 1 available secondary CPU(s)
[    0.000000] PERCPU: Embedded 7 pages/cpu @81867000 s7392 r8192 d13088 u32768
[    0.000000] Kernel command line: mtdram1=0x85fb9bf0,0x88000000 console=ttyS0,115200n8r nor_size=0MB sflash_size=1024KB nand_size=512MB ethaddr=08:96:D7:6E:9A:31  audit=1
[    0.000000] [mtdram_setup] mtdram1 0x05fb9bf0-0x07ffffff
[    0.000000] [NAND] nand_size = 0x20000000
[    0.000000] audit: enabled (after initialization)
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Writing ErrCtl register=00008080
[    0.000000] Readback ErrCtl register=00008080
[    0.000000] Memory: 79020k/98020k available (6296k kernel code, 19000k reserved, 2535k data, 312k init, 0k highmem)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:181
[    0.000000] SRSConf0 0x3feffbfe: SRS1: 0xffffffff, SRS2 0xffffffff, SRS3 0xffffffff
[    0.000000] Lantiq ICU driver, version 3.0.1, (c) 2001-2011 Lantiq Deutschland GmbH
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [ttyS0] enabled, bootconsole disabled
[    0.000000] console [ttyS0] enabled, bootconsole disabled
[    0.020000] Calibrating delay loop... 331.77 BogoMIPS (lpj=1658880)
[    0.080000] pid_max: default: 32768 minimum: 301
[    0.080000] Security Framework initialized
[    0.080000] AppArmor: AppArmor initialized
[    0.090000] Mount-cache hash table entries: 512
[    0.090000] Performance counters: mips/34K PMU enabled, 2 32-bit counters available to each CPU, irq 6
[    0.100000] CPU1 revision is: 00019556 (MIPS 34Kc)
[    0.180000] Brought up 2 CPUs
[    0.180000] [yield_context_init] cpu=1 tc=2 mask=2301
[    0.190000] [yield_context_init] cpu=0 tc=3 mask=410
[    0.190000] devtmpfs: initialized
[    0.210000] pinctrl core: initialized pinctrl subsystem
[    0.210000] Creating Config Table
[    0.210000] [avm_generate_hw_config_table_from_device_tree] gpio_cnt: 46
[    0.220000] NET: Registered protocol family 16
[    0.230000] Version 07.21
[    0.230000] avm_check_cpu_features: mips-options: 0x006d638b icache.flags 0x00000000 dcache.flags 0x00000004 isa_level 0x00000063 ases 00000031
[    0.240000] avm_alloc_page_extension node_extension_table[0] entries=24505 (size=98020)  alloced
[    0.240000] Reboot Status is: Soft-Reboot
[    0.250000] [avmnet] [avmnet_cfg_init] Driver version: 6.317-vr9_mc_vlan_jz72603Mon Aug 17 17:20:39 CEST 2020
[    1.060000] Lantiq PCIe Root Complex driver, version 2.0.0, (c) 2001-2011 Lantiq Deutschland GmbH
[    1.110000] bio: create slab <bio-0> at 0
[    1.120000] PCI host bridge to bus 0000:00
[    1.120000] pci_bus 0000:00: root bus resource [mem 0x1c000000-0x1cffffff]
[    1.130000] pci_bus 0000:00: root bus resource [io  0x1d800000-0x1d8fffff]
[    1.130000] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[    1.140000] ifx_pcie_rc_class_early_fixup port 0: fixed pcie host bridge to pci-pci bridge
[    1.150000] pci 0000:00:00.0: BAR 8: assigned [mem 0x1c000000-0x1c0fffff]
[    1.160000] pci 0000:01:00.0: BAR 0: assigned [mem 0x1c000000-0x1c001fff 64bit]
[    1.160000] pci 0000:00:00.0: PCI bridge to [bus 01]
[    1.170000] pci 0000:00:00.0:   bridge window [mem 0x1c000000-0x1c0fffff]
[    1.180000] AVM PA for Linux version 3.10.107 (jenkins@edxbuildxjplxpsq19p1xvr9xavmdect) (collect2: error: ld returned 1 exit status) #1 SMP Mon Aug 17 17:21:20 CEST 2020
[    1.180000]  (early init)
[    1.190000] NET: Registered protocol family 8
[    1.200000] NET: Registered protocol family 20
[    1.200000] Switching to clocksource MIPS
[    1.210000] AppArmor: AppArmor Filesystem Enabled
[    1.260000] NET: Registered protocol family 2
[    1.270000] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[    1.270000] TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
[    1.280000] TCP: Hash tables configured (established 1024 bind 1024)
[    1.280000] TCP: reno registered
[    1.290000] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    1.290000] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    1.300000] avm_pa: try to activate hw accelaration for pid 1 (ipv4) called from avm_pa_dev_pidhandle_register_with_ingress
[    1.310000] NET: Registered protocol family 1
[    1.320000] pci 0000:01:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x801
[    1.330000] Lantiq CGU driver, version 1.1.32, (c) 2001-2011 Lantiq Deutschland GmbH
[    1.340000] IFX DMA driver, version ifxmips_dma_core.c:v1.0.17, (c) 2009 Infineon Technologies AG
[    1.340000]  skb_shared_size:184
[    1.350000] audit: initializing netlink socket (enabled)
[    1.350000] type=2000 audit(1.350:1): initialized
[    1.360000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.370000] ANTFS Module: Version 2.46
[    1.370000] fuse init (API version 7.22)
[    1.370000] msgmni has been set to 154
[    1.380000] io scheduler noop registered (default)
[    1.710000] ttyS0 at MMIO 0x1e100c00 (irq = 107) is a PORT_IFX_ASC
[    1.720000] ifx_usif_uart_init: uart_register_driver failed
[    1.720000] avm_net_trace: Up and running.
[    1.730000] [loadcontrol] set auto - scale=1
[    1.730000] AVM_WATCHDOG: Watchdog Driver for AR7 Hardware (Version 1.0)
[    1.740000] Register push button event to receive the set_factory_kernel event
[...]
[    1.870000] Lantiq Thermal Sensor driver, version 1.0.3, (c) 2001-2011 Lantiq Deutschland GmbH
[    1.880000] ifx_pmu_init: Major 244
[    1.880000] Lantiq PMU driver, version 1.2.6, (c) 2001-2011 Lantiq Deutschland GmbH
[    1.890000] Lantiq GPIO driver, version 1.3.2, (c) 2001-2011 Lantiq Deutschland GmbH
[    1.900000] Infineon Technologies RCU driver version 1.0.7
[    1.920000] loop: module loaded
[    1.920000] nbd: registered device at major 43
[    1.950000] [ifx_jffs2_parser_function] exit on mtd ram-filesystem
[    1.950000] [ifx_ext2fs_parser_function:251] Use offset of 0x10 to search ext2 magic.
[    2.070000] 2 find_squashfs partitions found on MTD device ram-filesystem
[    2.070000] Creating 2 MTD partitions on "ram-filesystem":
[    2.080000] 0x000000000000-0x000002046410 : "rootfs_ram"
[    2.090000] 0x000000000000-0x000002046410 : "kernel_ram"
[    2.090000] mtd-ram mtd-ram: registered mtd device
[    2.100000] [HSNAND] Hardware-ECC activated
[    2.110000] ONFI param page 0 valid
[    2.110000] ONFI flash detected
[    2.110000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABADAWP), 512MiB, page size: 2048, OOB size: 64
[    2.120000] Scanning device for bad blocks
[    2.530000] Creating 6 MTD partitions on "ifx_hsnand":
[    2.530000] 0x000000000000-0x000000400000 : "kernel"
[    2.540000] 0x000000400000-0x000003400000 : "filesystem"
[    2.540000] 0x000003400000-0x000003800000 : "reserved-kernel"
[    2.550000] 0x000003800000-0x000006800000 : "reserved-filesystem"
[    2.560000] 0x000006800000-0x000006a00000 : "config"
[    2.570000] 0x000006a00000-0x000020000000 : "nand-filesystem"
[    2.570000] [TFFS3_Register_Panic_CB] registering panic callback for mtd ifx_hsnand
[    2.580000] [TFFS3_Register_Panic_CB] registering panic callback for mtd ifx_sflash
[    2.590000] Creating 3 MTD partitions on "ifx_sflash":
[    2.590000] 0x000000000000-0x000000040000 : "urlader"
[    2.600000] 0x000000040000-0x0000000a0000 : "tffs (1)"
[    2.610000] 0x0000000a0000-0x000000100000 : "tffs (2)"
[    2.610000] Lantiq SPI flash driver, version 2.0.2, (c) 2001-2011 Lantiq Deutschland GmbH
[    2.630000] tun: Universal TUN/TAP device driver, 1.6
[    2.630000] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[...]
[    2.770000] [TFFS3_Init] Called.
[    2.770000] [TFFS3_Init] No storage module registered, trying legacy fallback
[    2.780000] [TFFS3_LGCY_Setup] using mtd10(tffs (1)), mtd11(tffs (2))
[    2.780000] [TFFS3_LGCY_Setup] mtd "tffs (1)": segment value 1074
[    2.790000] [TFFS3_LGCY_Setup] mtd "tffs (2)": segment value 1073
[    2.790000] [TFFS3_LGCY_Setup] Using segment 1074 (avail: 1074 + 1073)
[    2.800000] [TFFS3_LGCY_Setup] mtd10 size=0x60000
[    2.810000] TFFS: tiny flash file system driver. GPL (c) AVM Berlin (Version 3.0)
[    2.810000] Adam2 environment variables API installed.
[...]
[    6.920000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock0
[    6.930000] yaffs: dev is 32505856 name is "mtdblock0" ro
[    6.930000] yaffs: passed flags ""
[    6.930000] yaffs: dev is 32505856 name is "mtdblock0" ro
[    6.940000] yaffs: passed flags ""
[    6.940000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)
[    6.940000] set_reboot_status: Soft-Reboot(PANIC)  - PANIC(1)SUM(1)UP(6)UTC(6)FW(07.21)HW(185)HWS(3)BV(1.1964)
[    6.940000] [panic_reinit] Called for mtd ifx_hsnand
[    6.940000] [panic_reinit] Called for mtd ifx_sflash
[    6.940000]
[    6.940000]
[    6.940000] ------------------- Last part of Panic-log Content: -------------------
[    6.940000]
[...]
[    6.940000] [    6.920000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock0
[    6.940000] [    6.930000] yaffs: dev is 32505856 name is "mtdblock0" ro
[    6.940000] [    6.930000] yaffs: passed flags ""
[    6.940000] [    6.930000] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    6.940000] [    6.930000] yaffs: yaffs: MTD device is not NAND it's type 1
[    6.940000] [    6.930000] yaffs: dev is 32505856 name is "mtdblock0" ro
[    6.940000] [    6.940000] yaffs: passed flags ""
[    6.940000] [    6.940000] yaffs: yaffs: Attempting MTD mount of 31.0,"mtdblock0"
[    6.940000] [    6.940000] yaffs: yaffs: MTD device is not NAND it's type 1
[    6.940000] [    6.940000] List of all partitions:
[    6.940000] [    6.940000] 1f00           33049 mtdblock0  (driver?)
[    6.940000] [    6.940000] 1f01           33049 mtdblock1  (driver?)
[    6.940000] [    6.940000] 1f02           33049 mtdblock2  (driver?)
[    6.940000] [    6.940000] 1f03            4096 mtdblock3  (driver?)
[    6.940000] [    6.940000] 1f04           49152 mtdblock4  (driver?)
[    6.940000] [    6.940000] 1f05            4096 mtdblock5  (driver?)
[    6.940000] [    6.940000] 1f06           49152 mtdblock6  (driver?)
[    6.940000] [    6.940000] 1f07            2048 mtdblock7  (driver?)
[    6.940000] [    6.940000] 1f08          415744 mtdblock8  (driver?)
[    6.940000] [    6.940000] 1f09             256 mtdblock9  (driver?)
[    6.940000] [    6.940000] 1f0a             384 mtdblock10  (driver?)
[    6.940000] [    6.940000] 1f0b             384 mtdblock11  (driver?)
[    6.940000] [    6.940000] No filesystem could mount root, tried:  ext3 ext2 ext4 squashfs antfs fuseblk yaffs yaffs2
[    6.940000] [    6.940000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)
[    6.940000] [    6.940000] set_reboot_status: Soft-Reboot(PANIC)  - PANIC(1)SUM(1)UP(6)UTC(6)FW(07.21)HW(185)HWS(3)BV(1.1964)
[    6.940000] Rebooting in 5 seconds..
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000
[\]

(AVM) EVA Revision: 1.1964 Version: 2964
(C) Copyright 2005 AVM Date: Nov 27 2013 Time: 14:33:10 (1) 3 0x0-0x740D

[FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 16 sectors a 64kB)
[NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
[SYSTEM:] VR9 on 500MHz/250MHz/250MHz

.Atheros 8030/35 detected

Eva_AVM >
Ich habe mir erlaubt, viele (unwichtige) Teile aus dem o.a. Log zu entfernen.

Benutzt man aber "image2ram" (oder auch die PowerShell-Alternative mit dem "getBootableImage" aus "FirmwareImage.ps1"):
Rich (BBCode):
peh@vidar:/tmp/7490/YourFritz/eva_tools> wget -qO- https://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.21.image | ./image2ram > ../../113.07.21.image2ram.image
peh@vidar:/tmp/7490/YourFritz/eva_tools> ls -l ../..
total 99160
-rw-r--r-- 1 peh users 33842192 Sep 21 10:57 113.07.21.image
-rw-r--r-- 1 peh users 33842176 Sep 21 11:33 113.07.21.image2ram.image
-rw-r--r-- 1 peh users 31154184 Sep 21 10:56 filesystem.image
-rw-r--r-- 1 peh users  2688008 Sep 21 10:56 kernel.image
drwxr-xr-x 1 peh users      738 Sep 21 11:06 YourFritz
peh@vidar:/tmp/7490/YourFritz/eva_tools> eval $(./eva_discover INTERFACE=vlan7 FROM=192.168.130.2 TO=192.168.130.1 BLIP=1);[ "$EVA_FOUND" = "1" ] && ./eva_to_memory ../../113.07.21.image2ram.image $EVA_IP
Found AVM bootloader: AVM EVA Version 1.1964 0x0 0x740D
Found hardware revision: 185
Memory size is 0x10000000 (256 MB)
Memory size limited to 128 MB
Image size is 0x2046400 (32 MB)
Setting temporary memory size to: 0x05fb9c00
Setting temporary kernel args to: mtdram1=0x85fb9c00,0x88000000
Image uploaded to device.
peh@vidar:/tmp/7490/YourFritz/eva_tools>
, sieht das gleich viel besser aus (man beachte die Unterschiede in der Dateigröße, die durch das Abschneiden der Prüfsumme an beiden Dateien - VOR dem Zusammenkopieren - entstehen) und die Serielle gibt u.a. folgende Nachrichten aus (hier nur auszugsweise, weil ohnehin schon die max. Beitragslänge naht):
Rich (BBCode):
[...]
[    1.940000] [ifx_jffs2_parser_function] exit on mtd ram-filesystem
[    2.010000] 2 find_squashfs partitions found on MTD device ram-filesystem
[    2.010000] Creating 2 MTD partitions on "ram-filesystem":
[    2.020000] 0x000000290400-0x000002046400 : "rootfs_ram"
[    2.030000] 0x000000000000-0x000000290400 : "kernel_ram"
[    2.030000] mtd-ram mtd-ram: registered mtd device
[...]
[    6.900000] VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
[    6.910000] devtmpfs: mounted
[    6.910000] Freeing unused kernel memory: 312K (808a2000 - 808f0000)
[    8.440000] led_module: module license '
[    8.440000] (C) Copyright 2012 by AVM
[    8.440000] ' taints kernel.
[    8.450000] Disabling lock debugging due to kernel taint
[    8.460000] [module-alloc-by-name] give 0x39000 bytes at 0x810c4000 to module 'led_module' (0x766000 total bytes left)
[    8.490000] [LED] use GPIO 45 for 'gpio_avm_led_power'
[    8.490000] [LED] use GPIO 47 for 'gpio_avm_led_internet'
[    8.500000] [LED] use GPIO 36 for 'gpio_avm_led_festnetz'
[    8.500000] [LED] use GPIO 35 for 'gpio_avm_led_wlan'
[    8.510000] [LED] use GPIO 33 for 'gpio_avm_led_info'
[    8.510000] [LED] use GPIO 46 for 'gpio_avm_led_info_red'
[    8.520000] [BUTTON] use GPIO 29 for 'gpio_avm_button_wlan'
[    8.530000] [BUTTON] use GPIO 1 for 'gpio_avm_button_dect'
[    8.530000] [avm_connect][state_machine_init] starting event worker thread
[    8.540000] led_module: Waiting for event system to be ready...
[    9.210000] [0]system-load  60% loadavg 0.32 0.7 0.2 - pgstat: sum=20109 free=14854 slab=1498 alloc=1137/s fault=671/s (sleep 2)
[    9.600000] [1]system-load  36% loadavg 0.32 0.7 0.2 - task runtime:6% max:update_kernel 6%  pgstat: sum=20111 free=14881 slab=1498 alloc=1142/s fault=683/s (sleep 1)
[    9.830000] yaffs: dev is 32505860 name is "mtdblock4" rw
[    9.830000] yaffs: passed flags ""
[   19.210000] [0]system-load  71% loadavg 0.35 0.8 0.3 - task runtime:34% max:cp 30%  pgstat: sum=20116 free=405 slab=1711 alloc=2396/s fault=81/s (sleep 2)
[   21.950000] TFFS Name Table N
[   22.120000] set_reboot_status: Soft-Reboot
[   22.130000] Res
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000
[\]

(AVM) EVA Revision: 1.1964 Version: 2964
(C) Copyright 2005 AVM Date: Nov 27 2013 Time: 14:33:10 (1) 3 0x0-0x740D

[FLASH:] MACRONIX Uniform-Flash 1MB 256 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 16 sectors a 64kB)
[NAND:] 512MB MICRON 2048 Pagesize 128k Blocksize 4096 Blocks 8Bit 1 CS HW
[SYSTEM:] VR9 on 500MHz/250MHz/250MHz

.Atheros 8030/35 detected

Eva_AVM >
Man beachte die jetzt gültigen Größenangaben für die beiden RAM-Partitionen für Kernel und Dateisystem - das zeugt davon, daß der Scanner in diesem Speicherblock tatsächlich eine Dateisystem-Signatur gefunden hat und deshalb den Kernel auf die tatsächliche Größe verkleinern und den Beginn der Dateisystem-Partition nach hinten verschieben konnte - das ist ihm im ersten Versuch nicht gelungen, weshalb beide Partitionen auf der "gesamten Größe" verharren und dann natürlich ein Mounten des Root-FS in die Hose geht, weil der Beginn der Partition falsch eingetragen ist und immer noch auf den Kernel - am Beginn der übertragenen Daten - zeigt.

In beiden Fällen startet natürlich die Box dann automatisch noch einmal ... nur wurde im zweiten tatsächlich auch das neue System in den Flash-Speicher geschrieben, während im ersten die Box erneut mit dem alten System startet.

Ich möchte jetzt nicht raten müssen, wem "die Nutzer" in diesem Falle wohl "die Schuld" geben würden - besonders witzig finde ich es aber, daß in "push_firmware" ja sogar wieder richtige (wenn auch andere) "Vorkehrungen" getroffen werden: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/push_firmware#L288

Ich bin mir nicht sicher, ob Du den Sinn Deines eigenen "dd" und der dort verwendeten Optionen jetzt verstanden hast und die Kommandos deshalb in "push_firmware" stehen (das "verlängert" den letzten Block der Eingabedatei, der nur aus den 8 Byte Prüfsumme besteht, dann wieder auf 256 Byte und damit stimmen auch die integralen Grenzen wieder - eine andere Herangehensweise, aber sie funktioniert i.d.R. auch) und Du das nur oben in #1 "vergessen" hast ... aber so, wie das in #1 steht, klappt das nicht mal mit einem Freetz- oder Freetz-NG-Image, solange da die Prüfsummen an den Dateien kleben und man weder die "/var/install" noch den Dateisystem-Scanner im Kernel nicht auch noch ändert. EDIT: Ich habe gerade erst gesehen (ich verwende ja selbst kein "fwmod"), daß das 1:1 die Zeilen aus der "fwmod" von Freetz sind, die da in "push_firmware" stehen.

EDIT/BTW: Wenn das so tatsächlich funktionieren würde, wie es in #1 für Linux steht, könnte man das sogar wieder als "Einzeiler" und ohne "Dateileichen" machen:
Code:
tar -f DAS.image -x -O ./var/tmp/kernel.image ./var/tmp/filesystem.image > neues.inmemory
- da muß man hinterher nicht mal "aufräumen" und das beim Entpacken erstellte Unterverzeichnis "var" entsorgen. Außerdem ist es immer beim Arbeiten mit "tar" auch eine Vorsichtsmaßnahme, daß man nicht einfach blind alles entpackt, was sich in so einer Archiv-Datei befindet. Sonst ruft man das doch mal an der falschen Stelle für die falsche Datei auf und dann ist dieses Kommando ziemlich unbarmherzig ... es überschreibt alles an der angegebenen Stelle im Dateisystem, was im Archiv steht. Daher sollte man bei "tar"-Files mit unbekanntem Inhalt immer erst mal noch einen Blick in die Datei werfen oder dafür sorgen, daß man selbst den Namen der Zieldatei bestimmt und der nicht aus den Verwaltungsinformationen der Archivdatei gebildet wird.

Aber wie geschrieben ... so einfach ist es ja gar nicht.

Und nochmal EDIT/BTW:
Wer sich den Code im Kernel für die Suche nach dem Dateisystem ansieht, der wird sogar feststellen, daß AVM versucht, das Dateisystem auch dann zu finden, wenn der (gesamte) Speicherbereich mit den beiden RAM-Partitionen nicht an einer 256-Byte-Grenze beginnt (in arch/mips/lantiq/common/ifxmips_mtd.c):
C:
380         // Starten mit einer 256-Byte aligned Adresse.
381         // Begruendung:
382         // Das Squashfs wird 256-Byte aligned. Der Kernel steht davor. Die Startadresse der MTD-RAM-Partition ist also nicht aligned.
383         // Der Suchalgorythmus kann also nicht im schlimmsten Fall das Squashfs-Magic nicht finden.
384         // pos wird als auf die ersten 256 Byte NACH dem Kernel-Start positioniert.
385         if(maptype == MAP_RAM) {
386             if((ifx_ram_resource[0].start & ((1 << 8) - 1))) {
387                 pos = ((ifx_ram_resource[0].start & ~((1 << 8) - 1)) + 256) - ifx_ram_resource[0].start;
388
389                 /*--- printk(KERN_ERR "[%s:%d] Use offset of 0x%x to search squashfs magic.\n", __func__, __LINE__, (unsigned int)pos); ---*/
390             }
391         }
Hier werden also die letzten acht Bit der Startadresse als Offset ermittelt (das landet in "pos" und wird praktisch von der integralen Grenze abgezogen) und die Suche nach dem "magic" eines Dateisystems startet dann auch mit einem entsprechenden Offset in die Kernel-Partition (das in 256-Byte-Schritten erhöht wird).

Nur ergibt das eben (man sieht es auch weiter oben im Console-Log des ersten Versuchs, weil es beim "ext2"-Parser protokolliert wird mit der Zeile, die beim SquashFS-Parser oben auskommentiert ist) in diesem Falle ein Offset von 16 (oder 0x10, wie es im Log angezeigt wird), weil 2x die acht Byte der Prüfsumme diese Grenzen beim "einfachen Kopieren" verschieben. Der Beginn des Dateisystem-Images ist aber nur um acht Byte ("nach unten") verschoben (nämlich um die Prüfsumme hinter dem Dateisystem-Image).

Wie man's auch dreht und wendet ... das Sicherste ist es hier, wenn beide Images eine integrale Größe besitzen (und die Verschiebung damit 0 ist) und ob man das jetzt dadurch erreicht, daß man die (nicht benötigte) Prüfsumme abschneidet (AVM-Recovery-Programme schreiben auch ohne die Prüfsummen) oder den letzten Block einer Eingabedatei, der ansonsten nur aus den acht Byte der Prüfsumme besteht, auf 256 Byte aufbläst, spielt erst dann wieder eine (entscheidende) Rolle, wenn eines der Images tatsächlich "am Anschlag" ist (das kann ja auch schon vorher auf die Größe der Partition aufgefüllt worden sein, bevor da die Prüfsumme hinten drangeklatscht wurde) und der eine zusätzliche Block jetzt dazu führt, daß der Platz in der Flash-Partition nicht mehr ausreicht.

Ich habe mich daher für den - in meinen Augen sichereren - Weg entschieden, die überflüssigen Prüfsummen zu entfernen und würde das eigentlich auch jedem für ein Freetz-(NG-)Image empfehlen.

Denn auch die Größenprüfung in Freetz(-NG) erfolgt ja, bevor da eine Prüfsumme angehangen wird, womit es - wenn danach noch weitere 248 Byte aufgefüllt werden, wie das bei "push_firmware" definitiv für beide Image-Files der Fall wäre - wieder einen "corner case" (oder meinetwegen einen "Grenzfall") gibt, bei dem zwar die Berechnung und Überprüfung der Größe in Freetz (und in Freetz-NG) noch "paßt schon" ergeben kann, während danach beim Versuch des Flashens die Dateien zu groß sind und das Schreiben dann (auch von der "/var/install" von AVM - deshalb hatte ich die oben schon mal (fälschlicherweise) erwähnt) abgebrochen würde.

Letztlich ist Freetz von dem Problem mit dem potentiellen "Grenzfall" aber auch nicht betroffen - denn da erfolgt das Erstellen der "zusammenkopierten Datei" schon, bevor die Prüfsumme an die beiden Eingabedateien geschrieben wird: https://github.com/Freetz/freetz/blob/master/fwmod#L1710 - und eine Größe, die ein Vielfaches von 256 Byte ist, sollten diese beiden Dateien VOR dem Anbringen der Prüfsumme ohnehin auch automatisch haben, so daß hier das "dd" nur eine Vorsichtsmaßnahme ist.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1
Hab den OP angepasst. Die Zeilen sind nicht mehr in fwmod da dies nicht zur .image-Erstellung, sondern zum Flashen gehört (Genau so wie das Auspacken von uimg, Spliten für hansenet-edition...). Ob aus fwmod oder fwdu weiss ich nicht mehr, aktuell zb hat nur fwdu grundlegende "fit" Unterstützung.
 
Damit fehlt jetzt die Windows-Variante?

Und vielleicht solltest Du doch noch einmal ganz deutlich in #1 schreiben, daß das nur dann funktioniert, wenn auch das "tools"-Verzeichnis aus der Freetz-Toolchain (was auch mind. ein "make tools" absolviert haben muß) vorhanden ist - das dürfte bei den meisten z.B. unter der WSL (ob 1 oder 2) eher selten der Fall sein. Gibt es kein "FREETZVERZEICHNIS" auf dem System (und all die anderen Voraussetzungen, damit das "make tools" da zuvor erfolgreich ausgeführt werden konnte), ist das alles nur Makulatur in #1.

Ich mache hier mal einen "alternativen" Vorschlag - alles, was man dazu braucht, sind im Linux ohnehin bereits vorhandene Kommandos: cat, mkdir, rm, wc, dd, tar (egal welches), base64 - für die Ausführung von image2ram und noch etwas für den HTTP-Download (wget, curl, etc.) und natürlich eine Internetverbindung, zumindest für den Zeitpunkt des Downloads. Dann kommt noch ein Ort dazu, wo man temporäre Dateien speichern kann - üblicherweise ist das ein Verzeichnis "/tmp" oder es gibt eine passende Environment-Variable, wenn das abweicht.

Dabei nehme ich eine "leichte Uneleganz" bewußt in Kauf, weil der Download und das direkte Ausführen von (Shell-)Code, den man aus dem Netz geladen hat, nicht wirklich zu empfehlen ist, solange man die Vertrauenswürdigkeit der Quelle nicht einschätzen kann. Daher braucht's bei dieser Variante auch noch ein "sha256sum" für die Integritätsprüfung der geladenen Daten - stimmt die unten grün angezeigte Zeichenkette mit der auf dem eigenen System angezeigten überein, ist es derselbe Inhalt - Stand heute im GitHub. Ändert sich das Skript, ändert sich auch die Prüfsumme - dann muß man ggf. den "Text" der Datei prüfen, weil ich für die einzelne Datei jetzt keine ständige Aktualisierung von Prüfsummen einrichten werde.

Rich (BBCode):
peh@vidar:/tmp/7490> wget -q https://raw.githubusercontent.com/PeterPawn/YourFritz/master/eva_tools/image2ram
peh@vidar:/tmp/7490> sha256sum image2ram
1bbcf6d44fccd1975882739fb980fb0979790f67e1eff60b1c5c0f58f0997251  image2ram
peh@vidar:/tmp/7490> wget -qO- https://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.21.image | sh ./image2ram > 113.07.21.image2ram.image
peh@vidar:/tmp/7490> ls -l
total 33056
-rw-r--r-- 1 peh users 33842176 Sep 22 13:14 113.07.21.image2ram.image
-rw-r--r-- 1 peh users     1888 Sep 22 13:07 image2ram
peh@vidar:/tmp/7490>
Es braucht also gerade mal drei Eingaben (wobei das "sha256sum" ja auch noch Kür ist und das "ls -l" zur "Anzeige" des Ergebnisses habe ich natürlich dabei auch nicht gezählt), um aus einer Image-Datei (im TAR-Format von AVM - egal, wo und wer dieses Image dann erstellt hat und mein Download von AVM im o.g. Beispiel könnte natürlich auch ein "cat ..." für ein schon vorhandenes File in eine Pipe sein oder das "Eingabe-Image" wird über eine (STDIN-)Redirection für das Skript bereitgestellt, usw. usf.) auf einem Linux-System ein passendes, startfähiges Image zu erstellen. Und zwar praktisch auf jedem beliebigen System (auch ohne Freetz-Installation), weil die benutzten Kommandos nun wirklich überall installiert sein dürften, da sie zur "Grundausstattung" eines Systems gehören und sogar auf einer FRITZ!Box mit AVM-Firmware wären die erwähnten Kommandos als Applet in der BusyBox enthalten.

Das dürfte deutlich weniger Vorbereitungen brauchen und auch deutlich weniger Abhängigkeiten aufweisen, als irgendetwas, wo man erst noch Freetz(-NG) installieren und die Tools erzeugen muß. Und wenn Freetz(-NG) einfach auf eine neuere Version von YourFritz zugreifen würde und nicht auf eine von "Anno Knack", stünde das POSIX-kompatible Skript (zuvor war es auf die "bash" ausgelegt) auch dort im "tools"-Verzeichnis zur Verfügung, was das dann bei vorhandener Freetz-(NG-)Installation auf einen einzelnen Aufruf beschränkt, weil das Skript ja in der YourFritz-Kopie (die in beiden Freetz-Versionen auch für andere Dinge verwendet wird) bereits vorhanden wäre.

EDIT: Hier habe ich mich geirrt mit der Zeit und habe mich von der (für dieses Skript unnötigen) Anpassung von "/bin/sh" auf "/bin/bash" durch einen Freetz-Patch irritieren lassen - die in Freetz verwendete YourFritz-Version ist zwar tatsächlich alt (> 1 Jahr), aber da war die Änderung auf POSIX-Kompatibilität schon (weitgehend) erledigt.

Das heißt dann aber auch wieder, daß man selbst unter Freetz-NG (unter Freetz ist es ja nicht wirklich erforderlich, wenn man die Option für dieses Format nutzen kann) das wieder auf einen einzigen Aufruf beschränken kann, der dann in etwa so aussieht:
Rich (BBCode):
FREETZVERZEICHNIS/tools/yf/eva_tools/image2ram < DAS.image > NEUES.inmemory
, wobei die beiden "spitzen Klammern" hier tatsächlich die Umleitung von Dateien beim Aufruf (also "redirections") bedeuten sollen und nicht die (auch gebräuchliche) Darstellung von "<DAS.image>" als variable Angabe in einem Beispiel: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html (Kapitel 12.1 Utility Argument Syntax, Aufzählung Punkt 4)
ENDE EDIT

Ich hätte natürlich auch noch irgendein "spezialisiertes Programm" wie das "tichksum" einbauen können ... nur was sollte das bringen? Die Verwendung von Shell-Kommandos ist - anders als die Verwendung von binären Dateien - plattformunabhängig und wenn man anstelle der Verwendung einer solchen Binärdatei auch einfach die ersten vier der letzten acht Byte der Datei auf anderem Weg prüfen kann und dann - wenn man festgestellt hat, daß es sich dabei tatsächlich um die Prüfsumme handelt - einfach auf das Kopieren dieser Daten verzichtet, dann ist das eben deutlich weniger plattformabhängig und warum man dafür (das gilt sogar für das Berechnen und Überprüfen dieser Prüfsummen, wenn man das braucht) jetzt ein "Programm" braucht, erschließt sich mir nicht.

Zieht man dann noch die Tatsache in Betracht, daß man das alles selbst unter "Freetz-Bedingungen" nur dann machen muß, wenn man Freetz-NG verwendet, fehlt nach meiner Ansicht sogar noch ein passender Hinweis auf diesen Umstand im Titel des Threads - denn ein "HowTo" in dieser Form ist bei Freetz ja gar nicht erforderlich, da muß man nur die passende Option in der Konfiguration aktivieren.

-------------------------------------------------------------------------------------------------------------------------

Ich ziehe auch die Idee hinter "push_firmware" in der derzeitigen Form generell in Zweifel - es erinnert von der Philosophie ein wenig an Freetz gesamt.

Denn es ist unter Linux (und auch schon unter früheren Unix-Versionen) eigentlich ziemlich unüblich, daß man so viele verschiedene Aufgaben in ein und dieselbe Datei quetscht und auf diesem Weg versucht, eine "eierlegende Wollmilchsau" zu erschaffen (obwohl es auch dafür gute Gründe gibt oder zumindest geben kann - das ist also kein Dogma). Nein ... unter diesen Systemen ist es eher üblich, daß man kleine, einzelne Programme erstellt, die einem einzigen, bestimmten Zweck dienen und dann baut man sich aus diesen kleinen Programmen ein "großes" zusammen.

Hier würde das beim "push_firmware" eben heißen, daß man die Teile "FTP-Kommunikation", "Modellermittlung" und "Dateiextraktion" gerade nicht in einem einzelnen "Moloch" zusammenfaßt (das "fwmod" aus Freetz ist ähnlich - mein "modfs" auch, aber das hat "historische Ursachen, die ich dem "fwmod" auch attestieren würde, während das "push_firmware" ja erst in jüngerer Vergangenheit (seit dem Fork) so "aufgeblasen" wurde), sondern daß man diese Aufgaben auf einzelne Programme/Shell-Skripte verteilt und dann mit deren Ergebnissen und dem eigenen Skript als "Klammer" um diese, weiterarbeitet.

Insofern kann ich das hier:
Die Zeilen sind nicht mehr in fwmod da dies nicht zur .image-Erstellung, sondern zum Flashen gehört (Genau so wie das Auspacken von uimg, Spliten für hansenet-edition...).
auch nicht wirklich nachvollziehen bzw. unterschreiben ... das Erstellen eines (abweichenden) Image-Formats gehört für mich durchaus (bis absolut) ins "fwmod" (man könnte sogar auf alle anderen Formate und die weiteren Schritte im "fwmod" verzichten, wenn man das ohnehin über den Bootloader installieren will) und das Auspacken irgendwelcher anderen Formate (wie uimg oder für alte Modelle) hat mit der FTP-Kommunikation absolut nichts zu tun und gehört damit entweder nicht nach "push_firmware" (wenn das - wie bisher in Freetz - das Skript zur FTP-Kommunikation sein soll) oder das FTP-Zeugs gehört ausgelagert, wenn man "push_firmware" als die erwähnte "Klammer" um andere Tools/Skripte und als "Versteher" der Firmware-Formate ansehen will.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1
OP um ein Paar Varianten erweitert.
Wie diejenigen die ein inmemory brauchen daran kommen ist mir ja egal, nur die ewigen Nachfragen danach sind nervig. Zu 99% handelt es sich dabei um Leute die ihr Freetz irgendwo "gefunden" haben, keine Linux haben und deshalb mit Windows flashen wollen. Da ist die Verwunderung gross dass es kein inimage für Docsis-Geräte gibt ^^
Siehe auch die 2 letzten Zeilen im OP, das alles braucht man für freetz-ng nicht...
Wenn dir das YourFritz in den Freetzen zu alt ist kannst du es gern ändern!
 
Na ja ... ich kann mir schon noch ein paar mehr Konstellationen vorstellen, wo man dann unter Windows flashen will oder gar muß - sonst hätte ich mir auch nicht die Arbeit gemacht, das für dieses System zu implementieren.

Schon die Tatsache, daß viele ein "Freetz-Linux" nur in einer VM laufen lassen werden und das Flashen von dort üblicherweise nur dann funktionieren wird, wenn die Netzwerkanbindung dieses Systems in der VM als "Bridge" daherkommt, begründet einen solchen "special case" ... und mir fallen da auch noch viele weitere ein (einer z.B., wo in einer VM in der Cloud kompiliert wird).

Für das Flashen (über EVA) braucht es aber immer die direkte Verbindung zwischen FRITZ!Box und dem verwendeten PC (Gerät) - schon wenn da der PC in der Wohnung/im Haus nur über ein Mesh (bei funktionierender FRITZ!Box) mit dem Internet verbunden und die FRITZ!Box im Keller ist, stellt sich das Problem, das zu flashende Image irgendwie auf einem Gerät zur FRITZ!Box "zu transportieren" und ich wage jetzt mal die Behauptung, daß die allermeisten Geräte, die in einem Haushalt üblicherweise als "mobile Computer" (Notebook/Laptop/ggf. Tablet, wenn Ethernet vorhanden) existieren, nicht mit Linux arbeiten werden, selbst wenn sich jemand sein Freetz auf dem eigenen PC selbst gebacken hat.

Auch die zwischendrin mal von AVM ins Leben gerufene Inhouse-Reihe 07.08 war ein Beispiel für einen solchen "use case" (da habe ich dann auch das Extrahieren des startfähigen Images per PowerShell implementiert) - da gab es auch keine Notwendigket (und bei manchem auch keine Möglichkeit), das nun unter Linux zu machen (und erst recht nicht mit einer Freetz-Installation).

Da gibt es also - neben dem Download irgendwelcher fertigen Images, gegen den auch nichts einzuwenden ist, solange die Lizenzbedingungen passen (s. mein "first_aid") - noch jede Menge, auch durchaus plausibler Gründe, warum man nun gerade nicht mit Deinem "push_firmware" aus der eigenen Freetz-NG-Installation flashen kann .. einer davon wäre es z.B. auch, daß Dein Skript zwar alle möglichen Formate für die Eingabedatei akzeptieren will, aber eben gerade das "natürliche Format", was man für den Start aus dem RAM braucht, weder erkennen, noch verstehen kann. Letztlich muß man - um das "push_firmware" benutzen zu können, das Ganze erst einmal einpacken, schön mit Schleifchen drum, damit es dann vom "push_firmware" gleich wieder aufgerissen werden kann.

Es mag zwar Sinn machen, wenn man (dem "großen" Programm zum Flashen) auch ein TAR-Image anbieten/nutzen kann - aber das kann man natürlich auch so lösen, daß man in einem Schritt dann das notwendige File zum Flashen aus der Eingabedatei erstellt und danach dann das eigentliche Flashen in einem anderen Schritt ausführt - die kann man ja auch nacheinander automatisch ausführen lassen.

Bei diesem Aufbau hat man aber auch gleich noch die Möglichkeit, den ersten Teil zu übergehen (weil man das "in-memory"-Image eben schon hat) und nur das Flashen auszuführen - DAS kann aber Dein "push_firmware" schon prinzipiell nicht, was seinen "Nutzen" dann eben doch deutlich einschränkt ... selbst wenn das für Freetz-NG-Benutzer genau das Richtige sein mag, weil die ja ohnehin nichts anderes machen sollen.

Was ich aber besonders irritierend finde ... da bist Du nun schon bestrebt, eine eierlegende Wollmilchsau zu erstellen, die das alles auf einmal enthält und dann sucht dieses Skript mit einem "ping" nach der FRITZ!Box und verläßt sich damit auf irgendwelches "timing"? Ehrlich ... das konnte schon "recover_eva" in Freetz besser, auch wenn das Perl war.

Mal abgesehen davon, daß nicht jedes "sleep" automatisch auch Perioden < 1 Sekunde versteht - eigentlich ist das die POSIX-Spezifikation: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sleep.html und die spricht deutlich von "A non-negative decimal integer specifying the number of seconds for which to suspend execution." für die Wartezeit.

Theoretisch müßte man also sogar noch testen, ob das vorhandene "sleep"-Kommando überhaupt Float-Zahlen akzeptiert - ansonsten wird es schnell "implementation dependent", wie so ein "sleep 0.2" dann arbeitet. Im besten Falle wird daraus ohne Fehlermeldung ein "sleep 0" (weil das Parsen der Zeitangabe beim ersten "non-integer"-Zeichen beendet wird) - dann funktioniert das sogar weiterhin, wenn auch wohl mit einem kürzeren Intervall als 200 ms zwischen den "pings".

Außerdem kommt eben noch hinzu, daß Du mit den "ping"-Kommandos gar nicht entdecken/entscheiden kannst, ob die Box nun im Bootloader ist oder ob es sich um die Erreichbarkeit unter ihrer "normalen" IP-Adresse, die sie im Betrieb verwendet, handelt. Im schlechtesten Falle hat der Aufrufer Dir die IP-Adresse aus dem Normalbetrieb angegeben (nehmen wir mal die 192.168.128.1), die findest Du jetzt beim "ping" in "push_fw" und die verschwindet auch aus Deinem "Gesichtsfeld", wenn er die Box stromlos macht. Irgendwann (i.d.R. so nach 30-60 Sekunden) taucht die auch wieder auf beim "ping", weil die Box dann wieder weit genug gestartet ist.

Die Zeit dazwischen, wo die Box im Bootloader erreichbar gewesen wäre (und zwar unter der "Standardadresse" 192.168.178.1, die wir mal als unverändert annehmen), hat Dein Skript gar nicht mitbekommen und trotzdem stürzt es sich (wenn ich es nicht übersehen habe, ohne weitere Prüfungen) auf den FTP-Server und da gehen die potentiellen Probleme dann weiter.

Damit da überhaupt etwas läuft, muß schon mal der FTP-Server (im FRITZ!OS bzw. in Freetz(-NG)) aktiviert sein, sonst gibt's gar keine FTP-Verbindung ... und auch bei dem folgenden Versuch des Flashens sorgt wohl nur die - hoffentlich fehlschlagende - Authentifizierung mit "adam2/adam2" (wenn der Benutzer das nicht im FRITZ!OS konfiguriert hat als Account :) ) am Ende dafür, daß da nicht noch mehr Unsinn veranstaltet wird.

Das ist also - bei allen Bemühungen Deinerseits - noch weit von "perfekt" entfernt und es gibt - auch aus dem "täglichen Leben" - noch genug Fallstricke, über die ein Benutzer bei diesem Skript stolpern kann. Ich erhebe meinerseits gar nicht erst den Anspruch, das mit meinen "Angeboten" alles automatisch machen zu wollen ... aber wenn bei mir aus dem "eva_discover" nicht die Info zurückkommt, daß da eine FRITZ!Box im Bootloader gefunden wurde (auch wenn das nicht 100% treffsicher ist, weil dieser Mechanismus noch von TI stammt und nicht nur von AVM genutzt wird), dann wird da auch nichts geschrieben (siehe #5 - und so sollte man das nach meinen Erklärungen praktisch immer anwenden).

Wenn man "die Komplexität" vor dem Benutzer verstecken will, dann muß/sollte man eben auch die Fehlerfälle alle sauber abfangen oder behandeln - sonst scheitert man (zumindest nach meinen Begriffen) am eigenen Anspruch.
 
Ich baue meine Images u.a. auch "auf Halde". Die Boxen werden also nicht zwangsweise mit dem Buildsystem geflasht sondern u.U. auch erst am Einsatzort. Daher lasse ich (bei den betreffenden Modellen versteht sich) neben dem normalen Image auch gleich ein in-memory Image mit erstellen, sodass ich je nach Zweck (Initial-Flash oder Update per WebGUI) das passende gleich griffbereit habe.

Von daher ist es mir nach wie vor nicht verständlich, weshalb die Option (erstellen eines in-memory Images) in Freetz-NG entfernt wurde!
 
NDilPP, sei doch froh dass es die Funktion nicht mehr gibt. Alle damit bisher erstellen inmemory sind fehlerhaft da sie die überflüssige Checksumme enthalten. Also am besten mit einem Befehl aus dem OP neuerstellen...

Bei den AVM Geräten wird die Firmware als .Image verteilt. Grundsätzlich ist Freetz eine Firmwaremodifikation.
Es wird ein .Image genommen und ein modifiziert .Image kommt wieder heraus.
Dieses .Image flasht man
- übers avm Webif, falls der pubkey des Image auf der Box ist (zb durch freetz)
- übers Freetz Webif, dem ist die Signatur egal
- mit tools/push_firmware über den Bootloader, die Signatur auch egal

Wenn man über den Bootloader nun manuell nach irgend einer Anleitung oder unter Windows mit einem Script flasht muss man das .Image halt vorbereiten, so wie es dieses Script will
- für uimg auspacken und nochmal das uimg selbst auspacken
- für nand auspacken und zusammenfügen
- für alice auspacken und splitten
- für die älteren Fritzboxen nur auspacken
- ...
Das hat dann mit freetz aber nichts zu tun. Man kann auch nicht für jede Möglichkeit eigene Ausgabeformate erfinden.
Wenn das Flashscript ein ungewöhnliches Format benötigt, muss man das .Image entweder selbst umwandeln oder ein besseres Script verwenden das dies automatisch macht.
 
sei doch froh dass es die Funktion nicht mehr gibt. Alle damit bisher erstellen inmemory sind fehlerhaft da sie die überflüssige Checksumme enthalten.
Das trifft für die Lösung in Freetz ja explizit nicht zu ... denn dort werden die beiden Dateien zur "in-memory"-Datei zusammengefügt (ab Zeile 1711), BEVOR die Prüfsummen für die beiden Dateien erzeugt werden (ab Zeile 1721): https://github.com/Freetz/freetz/blob/master/fwmod#L1711

Aber man braucht - wenn man Freetz-NG nutzen will oder muß - ja tatsächlich nur den einen zusätzlichen Aufruf, wenn man lieber das "ungewöhnliche Format" haben will, daß da vom Bootloader (m.W. bei allen Boxen, was das "ungewöhnlich" irgendwie gewöhnlich und häufig anzutreffen erscheinen läßt) auch verstanden wird.

Letztlich ist sogar die "kombinierte Datei" bei den Modellen, wo die "filesystem.image" eine Größe von 0 Byte hat, dasselbe ... bei den früheren Modellen störte (iirc) auch die Prüfsumme an der "kernel.image" noch und mußte abgeschnitten werden, wenn man diese "aus dem RAM" starten wollte.

Es gab also den weiter oben gezeigten Code, der bei VR9-Boxen mit einem Offset nach dem Dateisystem sucht, noch nicht - bei Start aus dem Flash-Speicher startet bei NOR-Flash der Kernel eben auch automatisch an einer 256-Byte-Grenze, weil er ja an den Beginn der entsprechenden Partition (die i.d.R. an einer solchen Grenze ausgerichtet ist) geschrieben wird.

Das Prinzip des Startens aus dem RAM beherrschen die AVM-Boxen iirc seit der Umstellung von ADAM(2) auf EVA - bei TI sieht/sah das noch etwas anders aus, obwohl auch da schon "spezielle Images" gestartet werden konnten, für die es sogar ein paar nachgebildete Funktionen aus dem "YAMON interface" gab zum Zugriff auf die Konsole und für die Benutzung von ISR/ESR (Interrupt Service Routine/Exception Service Routine) - leider ist das ganze Zeug dazu "Copyright (c) 2004 MIPS Technologies, Inc. All rights reserved." und nicht OpenSource, daher kann/darf man es nicht weitergeben.

Aus dieser Zeit stammt jedenfalls das Prinzip mit dem "Header" vor dem (ggf. gepackten) Kernel und AVM hat dann (immer nur m.W. bzw. nach meinen Recherchen) den Teil dazugebaut, wo das eben nicht automatisch Flash-Speicher sein mußte, aus dem das System (bei "gleichbleibendem Prinzip") gestartet werden konnte (hier legte der Wert von "mtd1" dann die "Startadresse" fest), sondern wo das auch aus dem RAM möglich war, nachdem man Kernel und Dateisystem dorthin geladen hatte.

Die Angaben in den "kernel_args" zur Adresse und Größe des "mtdram"-Devices dienen erst dem gestarteten Kernel zur Orientierung ... für den Startversuch aus dem RAM an sich ist das spezielle Format des "STOR"-Kommandos im FTP-Dialog verantwortlich (deshalb gibt es die Fehlermeldung mit dem 553 auch in Reaktion auf dieses Kommando).

Man kann sich natürlich auch auf den Standpunkt stellen, das dabei von AVM verwendete Format wäre "ungewöhnlich" - nur ist das eben schon sehr, sehr lange auch in dieser Form "stabil" und wird auch von JEDEM AVM-Recovery-Programm genutzt, wenn das FRITZ!Box-Modell diese Form der Installation durch den Start aus dem RAM verwendet. In einem Recovery-Programm finden sich dann eben auch von Beginn an keine (TI-)Prüfsummen hinter den Teilen "Kernel" und "Dateisystem" - und obendrein stehen die auch in einem Recovery-Programm üblicherweise nicht hintereinander (zumindest nicht so, daß sie als ein gemeinsamer Stream übertragen werden könnten).

Dieses "ungewöhnliche" Format ist letztlich auch mit dem Flash-Inhalt bei NOR-Modellen identisch, nur werden die Daten beim Start aus dem RAM eben ans obere Ende des verfügbaren Speichers geladen und genau diese Änderung des "Ankers" (mal "von vorne", mal "von hinten") ist der Grund dafür, daß die Prüfsumme (wenn vorhanden) zu einem "mis-alignment" beim Start aus dem RAM führt (was den Kernel gar nicht juckt, denn erst beim Suchen des Dateisystems geht das dann - mal mehr, mal weniger - schief) - beim Start aus dem (NOR-)Flash hängt die Prüfsumme einfach nur hinten dran und interessiert niemanden.

Das macht die Frage, ob das Vorhandensein einer solchen Prüfsumme nun als "Normalfall" oder nur als (alte) Absicherung bei BESTIMMTEN Vorgehensweisen anzusehen ist, doch gleich noch mal so interessant, denn bei genauerer Betrachtung ist die Feststellung:
Bei den AVM Geräten wird die Firmware als .Image verteilt.
ja auch falsch, solange da kein "unter anderem" oder auch ein "überwiegend" enthalten ist. Denn die Firmware wird natürlich auch in Form des Recovery-Programms verteilt und Freetz ist sogar in der Lage, aus einem solchen die beiden benötigten Images zu extrahieren und diese dann anstelle einer AVM-Image-Datei zu verwenden.

Diese ganzen Prüfsummem werden eben nur dann benötigt, wenn das originale Installations-Skript von AVM (/var/install in einer Image-Datei) verwendet wird, weil das (wohl eher aus historischen Gründen, denn aus tatsächlicher Notwendigkeit) diese Prüfsummen "sehen" und überprüfen will, obwohl die denkbaren Ursachen für Abweichungen an dieser Stelle nun wirklich sehr exotische Probleme darstellen würden.

Sogar ein Problem mit zu wenig freiem Speicher beim Entpacken (das ist einer der wenigen "glaubwürdigen" Fälle) würde auf diesem Weg (bei praktisch allen AVM-Images, die ich in letzter Zeit gesehen habe) nicht wirklich erkannt, weil das in der "/var/install" (die ganz vorne im TAR-File steht bei AVM) aufgerufene "chksum" erst nach der "filesystem.image" im TAR-File kommt und dann wohl auch nicht mehr erfolgreich entpackt werden könnte ... damit schlägt das dann nicht deshalb fehl, weil die Prüfsumme an der Datei nicht stimmt, sondern weil der Aufruf des Programms komplett in die Hose geht, da seine Existenz auch nicht überprüft wird, bevor man es bei AVM ausführen will.

Selbst das "CHECK"-Kommando im FTP-Server berechnet auch nur einen neuen CRC32-Wert (afaik über die gesamte Partition, auch wenn die nicht vollständig gefüllt ist) und vergleicht den nicht mit irgendwelchen Werten am Ende der (gültigen) Daten. Würde Freetz also - anstatt selbst eine Prüfsumme zu berechnen und anzuhängen - einfach nur deren Prüfung aus der "/var/install" entfernen, gäbe es das ganze Theater mit der Frage, ob da nun eine Prüfsumme dranklebt oder nicht, schon längst nicht mehr.

Ich habe ja auch kein Problem damit, wenn jemand eine bestimmte Vorstellung hat, wie etwas gemacht wurde/werden sollte und daran dann auch festhält, zumindest für sich selbst - nur muß man deshalb die anderen Wege ja nicht "entwerten" oder die Nachfrage nach diesen dann als "ungewöhnlich" ansehen oder den eigenen Weg als "besser" anstatt "anders" - zumindest nicht ohne nachvollziehbare Begründungen, wobei die eben nicht nur einen selbst, sondern die anderen überzeugen sollten.

Und wenn man - durch das "Abschaffen" der notwendigen Einstellungen - versucht, die Benutzer auf die eigene Lösung "hinzuleiten", dann sollte/muß diese eben auch funktionieren. Angesichts von einigen erheblichen Schnitzern in der Vergangenheit in "push_firmware", die auch über längere Zeit nicht auffielen, haben die Neuerungen in "push_firmware" diese Hürde in der Akzeptanz wohl bei "der breiten Masse" von Freetz-NG-Benutzern doch noch nicht gefunden (oder vielleicht hat sich das auch gebessert, nachdem die Schnitzer beseitigt waren - wobei ja immer noch einiges offen wäre, s.o.) - woran das nun am Ende liegen mag und wie da die Verteilung aussieht, weiß ich natürlich auch nicht.

Das wäre m.E. doch eigentlich alles gar nicht notwendig und ja nun auch sehr leicht zu korrigieren (selbst wenn die Positionen in den Dateien in Freetz-NG inzwischen etwas andere sind) ... etwas (Funktionierendes) aus dem "Eltern-Projekt" auszubauen, braucht schon eine sehr gute Begründung in meinen Augen und angesichts der Tatsache, daß da auch nichts groß "zu pflegen" wäre bei dieser Option oder das - außer dem Platzbedarf für die zusätzliche Datei und der ist wohl auch nur selten ein Thema - irgendwelche anderen Nachteile (für die Freetz-Benutzer) hätte, bleibt halt die Frage, warum das notwendig war und ob man das nicht noch einmal überdenken kann oder gar sollte.

Ein "braucht ohnehin keiner" kann es ja am Ende auch nicht gewesen sein, wenn der Bedarf besteht (und das sogar so häufig nachgefragt wird, daß Du (@fda89) davon schon genervt bist und es zu diesem Thread überhaupt kam) und auch ein "geht ja auch anders" ist - beim "Ausbauen" einer Funktion, die keiner ständigen Pflege bedarf, wie irgendwelche Pakete o.ä. - sicherlich für die Freetz-Benutzer nur schwer nachzuvollziehen (und am Ende sollen die ja sicherlich "die Zielgruppe" sein).

Die acht Zeilen aus dem "fwmod" in Freetz (und die zusätzliche Option in der Vorlagedatei für "Kconfig") machen den Kohl nun auch nicht mehr fett (da war das Entfernen sogar zusätzlicher Aufwand) und das ist auch keine "uralte Funktion", die nun wirklich niemand (außer einer Handvoll von Leuten) mehr braucht (wie die Unterstützung von "Alice-Boxen" u.a.) oder die sich mit irgendeiner anderen Funktion oder Einstellung (weder in Freetz, noch in Freetz-NG) beißt oder einer anderen "weichen" mußte, weil sie mit ihrer puren Existenz das Implementieren neuer Funktionen erschwerte und damit zum Hemmschuh wurde.

Das ist praktisch ein "in sich geschlossener Block" ohne irgendwelche anderen Abhängigkeiten - außer einem passenden Modell, weil Freetz das für die NOR-Boxen (obwohl es dort ebenso funktioniert, nur daß die Installation in den Flash-Speicher dabei nicht automatisch erfolgt) ohnehin nicht vorsah.

Letztlich stellt sich (für mich, der ich üblicherweise über den Bootloader installiere und nur sehr selten über selbst-signierte Images, wobei bei mir die Variante über das Freetz-GUI nicht in Frage kommt, weil ich ja keinen "Freetz-Mod" verwende) sogar die Frage, ob man nicht tatsächlich die Option zur Erzeugung des "in-memory"-Images noch dahingehend erweitern kann, daß eine zweite Option (die nur dann auswählbar ist) das Erstellen des kompletten Images (was nach dem Zusammenkopieren ja noch einige Zeit braucht) verhindern kann - wer ohnehin über den Bootloader installieren will, braucht dann auch kein anderes Format mehr ... egal wie gewöhnlich oder ungewöhnlich man das finden mag.

Das gesamte Signieren von Images (für das ich ja auch eine (mittlerweile in 100% und nicht nur in 95% (19 von 20) der möglichen Fälle für die "Restgröße" einer Imagedatei im letzten (10 KB-)Block) funktionierende Lösung anbiete) habe ich auch nicht primär für diese Fälle analysiert und nachgebaut - die Verwendung zum Signieren "kompletter Firmware-Images" ist eigentlich nur ein (nettes) Abfallprodukt. Wirklich interessant wird dieses Signieren dort, wo es um das "Nachladen" von solchen Image-Files im laufenden System geht, wie das z.B. beim Update von DECT-Firmware der Fall ist.
 
Durch die inmemory Funktion gabe es sogar Mehraufwand, da dann wegen der Konditionierung versucht wurde mit PF ein inmemory zu flashen... Daher hätt ich gern diese ganzen inmemory-Kram los
Dass die Checksumme bei den alten "singleboot" zum flashen entfernt werden muss ist mir neu. Es ging jedenfalls immer auch ohne Entfernen. Ich hab aber davon keine Gerät mehr. Vermutlich wird ignoriert was hinter dem Dateisystemende liegt.
Ich hab auch keine Docsis Gerät und muss mich da auf die Aussagen anderer verlassen. Leider ist mir niemand bekannt der so ein Gerät hat, das vernünftig testen könnte und dann eine klare Aussage treffen kann obs nun geht oder nicht. Da dauert es halt schonmal Monate bis ein Fehler gefunden wird
 
da dann wegen der Konditionierung versucht wurde mit PF ein inmemory zu flashen
Tja ... die Lösung dafür, habe ich Dir oben ja schon "durch die Blume" versucht zu vermitteln.

Wenn "push_firmware" das Format selbst verstehen würde, käme es gar nicht erst auf die Idee, da irgendetwas entpacken zu wollen. Diesen "Mangel" von "push_firmware" jetzt dadurch zu beseitigen, daß das (nicht verstandene) Format erst gar nicht erzeugt wird, hat was von der Joo-Janta Gefahr-O-Sensitiv (https://de.wikipedia.org/wiki/Hintergründe_zu_Per_Anhalter_durch_die_Galaxis#Joo-Janta_Gefahr-O-Sensitiv).

Wie ich oben schon schrieb ... wenn "push_firmware" etwas smarter wäre (und offenbar willst/wolltest Du das ja in diese Richtung "weiterentwickeln"), würde es den Schritt mit der Erzeugung der benötigten Datei (die bei Dir dann als "ramboot.flash" auch denselben Inhalt (nur halt mit 2x 256 Byte mehr als nötig) hat) einfach übergehen, wenn es bereits die passende Datei vorgesetzt bekommt.

Dann braucht man auch die Schuld an den "falschen Daten" nicht mehr dem Nutzer zuzuweisen - am Ende hat man ihm dann das Leben tatsächlich leichter gemacht und Dir auch, wenn Du es tatsächlich so oft erlebst oder erlebt hast, daß die Leute "push_firmware" mit einem "in-memory"-File "füttern" wollten ... da ist die Reaktion, dann auf das Erzeugen des "in-memory"-Files zu verzichten, anstatt das "Verständnis" dafür in das (ohnehin schon überladene, jedenfalls nach meiner Ansicht) "push_firmware" zu integrieren, ja auch eher "Vogel Strauß"-Behavior.

Wenn man irgendwelche unsinnigen Formate nicht verstehen WILL (meinetwegen ein ISO-File einer CD, auf die eine Firmware-Datei gebrannt wurde), kann ich das verstehen - aber das, womit Dein Skript als Eingabe nichts anfangen kann, erzeugt es im Verlauf der Verarbeitung letztlich sogar selbst.

Das alles gilt natürlich immer nur unter der Prämisse, daß das eigene Programm auch den Anspruch erheben will, "smart" oder gar "besser" zu sein - denn ich weiß natürlich auch, daß mein "eva_to_memory" weder Alice-Firmware installiert, noch (selbst) mit einem TAR-File etwas anfangen kann (dafür gibt's ja dann gerade das "image2ram") und das ist natürlich auch bei mir "Absicht", wie ich oben schon versucht habe zu erklären - der Linux-Gedanke mit dem "one tool for one job", wenn's nicht gewichtige Gründe dagegen gibt.

Ich setze auch nicht immer gleich alles um, was ein Nutzer an mich heranträgt ... aber ich baue eben auch keine Funktion aus, ohne dafür einen wirklich guten Grund zu haben (und den teile ich dann i.d.R. auch mit, weil man mir eher nicht den Vorwurf macht, daß ich zu "schweigsam" wäre, was Überlegungen und Entscheidungen angeht).

Solltest Du Dich entscheiden, das Format der Eingabe-Datei nicht länger an den übergebenen Optionen festzumachen (wobei man da natürlich auch noch eine für "RAM, aber kein TAR-File als Eingabe" hinzufügen könnte) oder Deine Erkennung (ab hier: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/push_firmware#L463) dahingehend zu erweitern, daß auch dieses Format automatisch erkannt wird (macht natürlich nur bei den Boxen Sinn, wo der Bootloader damit auch etwas anfangen kann, was die Cable-Boxen schon mal ausschließt), dann können wir ja noch mal überlegen, wie man so eine Datei (außer am Magic des "Record 1" (die ersten 12 Byte) am Beginn des Kernels, wobei das fast schon reichen sollte) erkennen könnte. Da dort ja auch die Länge des Kernel-Images steht, findet man - so man will - auch den (ungefähren) Beginn des Dateisystems in so einer Datei und kann da dann wenigstens noch nach der Signatur suchen, wenn man ganz, ganz sicher sein will.

Es ist also gar nicht wirklich kompliziert, die Kenntnisse über dieses Dateiformat "nachzurüsten" ... und dann fällt ja offensichtlich auch der Grund mit der "Konditionierung" weg, weil es dann vollkommen egal ist, welche Datei der Nutzer Dir "anbietet".

-----------------------------------------------------------------------------------------------------------------

Es ging jedenfalls immer auch ohne Entfernen.
Ich schrieb da schon vom "Start aus dem RAM" - ich weiß nicht, wie oft Du das bei einer NOR-Box (mit einem AVM-Image) gemacht hast, weil sich dabei die Firmware eben nicht selbst installiert und es nur eine Möglichkeit war, (auf Kosten des verfügbaren RAM) auch mal Sachen auszuprobieren, ohne sie gleich ins Flash schreiben zu müssen.

EDIT: Ich habe gerade noch mal nachgesehen ... zumindest bei der 7390 (also in den Fusiv-Quellen) erfolgt tatsächlich kein Alignment für die Adresse beim Scannen nach dem Dateisystem (die auch dort aber in 256-Byte-Schritten erfolgt) - damit stört das dort dann tatsächlich nicht, wobei es ja auch bei späteren Modellen nicht zum Problem wird, wenn nur an EINER der beiden Image-Dateien eine Prüfsumme hängt, auch wenn ich die - vorsichtshalber - beide entferne, weil auch das AVM-Recovery-Programm eben ohne diese arbeitet.
 
Zuletzt bearbeitet:
> Solltest Du Dich entscheiden, das Format der Eingabe-Datei nicht länger an den übergebenen Optionen festzumachen
Unsinn, das Format wird ohne Parameter automatisch erkannt. Du hast oben doch selbst den Unterschied von <> und [] erläutert. Man könnte die Parameter eigentlich löschen, aber dann kommt wieder jemand an und jammert dass sie weg sind...

Die Erkennung von inmemory könnte man noch nachrüsten, kenne aber keinen Befehl zur Erkennun. Du?
 
Habe ich doch oben schon geschrieben ... der einfachste Fall ist es, wenn die ersten vier Byte der Datei 0xfeed1281 (MIPS/ARM, außer GRX5), 0xfeed9112 (GRX5 - wg. des zusätzlichen "bootcore"-Kernels im Image) oder 0xfeed8112 (Puma, also uninteressant, weil ein einzelnes System/Image hier ohnehin nicht reicht) sind - alles in "little endian"-Speicherreihenfolge.

Andere Magics habe ich auf die Schnelle in einer kleinen Auswahl von Kernel-Images, die ich immer zum Testen solcher Sachen herumliegen habe (von diversen Boxen) nicht gesehen, das sollte alles abdecken, was man heutzutage braucht bzw. wo es Sinn macht, wenn man ein "fertiges Image" kriegt (das kann ja auch eines für ein NOR-Gerät sein, die soll "push_firmware" ja offensichtlich nach Deinem Willen ebenso unterstützen):
Rich (BBCode):
vidar:/tmp/check_images $ for f in kernel.image.*; do echo $f; hexdump -x -n 4 $f | head -n 1; head -c 4 $f | base64; echo; done
kernel.image.4020
0000000    1281    feed
gRLt/g==

kernel.image.4040
0000000    1281    feed
gRLt/g==

kernel.image.5490
0000000    1281    feed
gRLt/g==

kernel.image.6360
0000000    1281    feed
gRLt/g==

kernel.image.6820
0000000    1281    feed
gRLt/g==

kernel.image.6890
0000000    9112    feed
EpHt/g==

kernel.image.7270v3
0000000    1281    feed
gRLt/g==

kernel.image.7369
0000000    1281    feed
gRLt/g==

kernel.image.7390
0000000    1281    feed
gRLt/g==

kernel.image.7490-1
0000000    1281    feed
gRLt/g==

kernel.image.7490-2
0000000    1281    feed
gRLt/g==

kernel.image.7520
0000000    1281    feed
gRLt/g==

kernel.image.7530
0000000    1281    feed
gRLt/g==

kernel.image.7581
0000000    1281    feed
gRLt/g==

kernel.image.7590
0000000    9112    feed
EpHt/g==

kernel.image.arm.6490-1
0000000    1281    feed
gRLt/g==

kernel.image.arm.6490-2
0000000    1281    feed
gRLt/g==

kernel.image.atom.6490-1
0000000    8112    feed
EoHt/g==

kernel.image.atom.6490-2
0000000    8112    feed
EoHt/g==

vidar:/tmp/check_images $
Auslesen kann man das problemlos mit "dd" (oder hier sogar mit "head", weil's ja am Beginn startet und die Länge bekannt ist), dann verfüttert man es an "base64" und vergleicht das Ergebnis mit einem (oder mehreren) bekannten Wert(en). Genau so ermittelt auch "image2ram", ob da eine TI-Prüfsumme an der Datei hängt - da kannst Du Dich also inspirieren lassen, wenn Du willst, wobei da noch hinzu kam, daß man eben vier Byte lesen mußte, die ab Offset -8 (also acht Byte vor dem Ende der Datei) zu finden sind.

Ob man sich mit der Existenz des "magic" dann schon zufrieden gibt oder noch nach dem Dateisystem sucht, muß jeder selbst wissen ... ein Dateisystem ist (bei passendem Kernel mit eingebauter "initrd") auch nicht wirklich "Pflicht".

Wie schon geschrieben, startet EVA das Entpacken anhand der Signatur und der Adressen/Länge in den ersten 12 Byte und wenn das klappt (und die Werte im zweiten TI-Record nach den gepackten Daten auch noch stimmen), wird an der dort angegebenen Adresse der entpackte Kernel gestartet.

BTW:
Unsinn, das Format wird ohne Parameter automatisch erkannt.
Hättest Du oben einfach richtig gelesen, hättest Du (hoffentlich) auch bemerkt, daß mir das durchaus geläufig war ... immerhin habe ich in demselben Satz, dessen Anfang Du zitiert hast, sogar noch einen Link auf die entsprechende Zeile in Deinem "push_firmware" angebracht.

Was genau willst Du mir also mit dem Zitat und der - jetzt von mir wieder zitierten - Feststellung sagen? Ich gehe mal davon aus, daß andere Leser das schon bei mir richtig gelesen haben sollten und wenn Du die jetzt nicht alle für zu dumm zum Lesen hältst, hätte es diese "Klarstellung" (die ja eigentlich eine Bekräftigung und kein Widerspruch ist, was die Einleitung mit "Unsinn" noch unverständlicher macht) wohl auch nicht gebraucht.
 
Zuletzt bearbeitet:
Danke. Hab in PF schon eine ähnliche Prüfung mittels "hexdump -n4" gefunden
> offensichtlich nach Deinem Willen ebenso unterstützen
Ich weiss nicht ob dir das so ganz klar ist, PF ist nicht ursprünglich von mir, sondern ich hab es nur erweitert. In den letzten Jahren hat es niemand mehr wegen mangelndem "nand" Support genutzt
 
  • Like
Reaktionen: gismotro
Ich weiss nicht ob dir das so ganz klar ist, PF ist nicht ursprünglich von mir, sondern ich hab es nur erweitert.
Ich weiß eigentlich nicht, wo Deine Zweifel in diesem Satz ihren Ursprung haben ... wenn ich meinerseits schon geschrieben habe:
während das "push_firmware" ja erst in jüngerer Vergangenheit (seit dem Fork) so "aufgeblasen" wurde
und vielleicht hätte ich es ja noch deutlicher schreiben sollen (was aber zum Balance-Akt auf der Rasierklinge wird, damit das nicht wieder jemand in den falschen Hals kriegt), daß Du diese (für NOR-Boxen bereits enthaltene) Erkennung für Deine Änderungen vergessen oder ganz bewußt darauf verzichtet hast.

Schaut man auf das Datum der Änderung in Freetz-NG (https://github.com/Freetz-NG/freetz-ng/commit/8c7f339278d9e82ff9e7355240b721424b8cb565), muß es ja (in den ersten vier Wochen Freetz-NG - der erste "fda77"-Commit ist dieser: eaf06dbb153d8ee2eabeedb827f1c8d80e409744) schon sehr, sehr viele "Falschmacher" beim Image-Format gegeben haben in den zwei Tagen, die zwischen dem Einbauen der Unterstützung für NAND-Boxen in "push_firmware" (https://github.com/Freetz-NG/freetz-ng/commit/567e5f170c248440157d7904d95fd99fb4cc66e3) und dem Ausbau des "in-memory"-Formats aus "fwmod" gelegen haben, wenn das solchen Mehraufwand verursachte:
Durch die inmemory Funktion gabe es sogar Mehraufwand, da dann wegen der Konditionierung versucht wurde mit PF ein inmemory zu flashen

=========================================================================================

Ob man nun "hexdump" nimmt (was angesichts verschiedener Ausgabeformate eher unzuverlässig ist - siehe schon der Unterschied zwischen der GNU- und der BSD-Version im "alten" "push_firmware") oder den Test gegen die Ausgabe von "base64" macht (was auf allen Systemen dieselbe Ausgabe liefert - auch wenn es nicht zum POSIX-Standard gehört, aber das spielt in "push_firmware" ohnehin keine Rolle, weil das per se nur mit der "bash" funktioniert aufgrund verwendeter Sprachkonstrukte), ist am Ende auch nur Geschmackssache und ein "base64" gehört deutlich öfter zur "Grundausstattung", als ein "hexdump" (siehe die Bemerkung im Kopf von "push_firmware" dazu).

Wenn man das nur unter "Freetz-Bedingungen" anwenden will/soll, wäre sogar wieder "sfk" die bessere Wahl, weil das bereits verwendet wird in der Toolchain an anderer Stelle und die Nutzung von "hexdump" in "push_firmware" (schon vor Deinen Änderungen, damit Du nicht wieder denkst, ich würde das jetzt Dir zuschreiben wollen) das einzige Vorkommen in Freetz (auf dem Build-Host) ist.

So richtig klar ist mir "die Stoßrichtung" bzw. die "Zielgruppe" für "push_firmware" aber auch immer noch nicht, denn wenn es nur unter "Freetz-Bedingungen" zu verwenden wäre bzw. sein soll, dann bräuchte es ja die Abfragen für "Darwin" nicht - oder hat jemand tatsächlich die gesamte Freetz-Toolchain auf dem Mac am Laufen? Und auch unter "cygwin" ist Freetz (auch -NG) m.W. etwas "zickig".

Letzten Endes hängt die Wahl der verwendeten Kommandos dann halt immer auch davon ab, auf welchen Plattformen das nun lauffähig sein soll - nach meiner Einschätzung ist das mit "base64" deutlich eher "portable", als mit einem "hexdump".

Wobei man natürlich auch mit dem "kleinsten gemeinsamen Nenner" (und das wäre die ausschließliche Verwendung von Shell-Code-Konstrukten und (externen) Kommandos, die der POSIX-Spezifikation entsprechen) einen solchen Vergleich hinbekommt: https://github.com/PeterPawn/YourFritz/blob/master/scriptlib/functions/yf_bin2hex.function - dann braucht man gar kein Kommando mehr, was nicht zur POSIX-Spezifikation gehört und die hier benötigten "cat", "printf" und "cmp" sollten, genau so wie "/dev/zero", tatsächlich überall vorhanden sein und auch exakt dieselben Ergebnisse liefern - wobei "printf" sogar häufig als Builtin anzutreffen ist und nicht als "external" gebraucht wird.
 
Ich hatte gesten hexdump genommen, weil es eh schon in dem Script verwendet wird. War gar nicht soviel Aufwand. Wenn man das eine hexdump optimiert kann man das andere mitmachen. Für sfk müsste es gebaut sein, finde das tool auch etwas komisch. Mit base64 bin ich mir nicht sicher, ob es da nicht verschieden Versionen von hexdump gibt die mal tabs oder spaces nutzen, da ist grep sicherer. Das Darwin, Cyygwin etc nutze ich nicht, aber du weisst ja wie das ist wenn man was löscht :D
Was mit PF nicht gemacht werden soll? Aktuell nichts, solang keine Fehler gefunden werden. Irgendwann mal FIT support
 
Nun gehen bei Dir zwar auch Puma-ATOM-Kernel als "in-memory"-Image durch (bei diesem Test), aber die wird hoffentlich niemand als Eingabedatei verwenden.

Mit base64 bin ich mir nicht sicher, ob es da nicht verschieden Versionen von hexdump gibt die mal tabs oder spaces nutzen, da ist grep sicherer.
Den Satz verstehe ich ohnehin nicht ... das "base64" soll(te) man ja auch auf die binären Daten anwenden und nicht auf die Ausgabe von "hexdump" - und dann sind - mir zumindest - keine "base64"-Programme bekannt, die da irgendetwas anderes als den - nunmehr Base64-kodierten - Inhalt der Eingabedatei ausgeben, was dann bei 4 Byte binärer Eingabe immer 8 Byte als Zeichen ergibt (mit den Gleichheitszeichen als "filler" für die nicht benötigten Bits).

So habe ich das oben ja auch "vorgemacht" - die Zeilen mit der "hexdump"-Anzeige nach dem Namen der Eingabedatei waren ja nur "zum Verdeutlichen" bzw. zum Vergleichen und die Base64-Darstellung in der nächsten Zeile wäre genau das gewesen, was man hier zum Vergleich heranziehen könnte. Das mag zwar - in dem Kommando - nicht so ausgesehen haben ... aber die Eingabe für das "base64" waren die vier Byte Binärdaten und nicht die Ausgabe des vorhergehenden "hexdump".

Genau die Tatsache, daß ein "hexdump -n X" eben kein "wohldefiniertes" Ausgabeformat verwenden muß, was dann zu unterschiedlichen Ausgaben führen kann, wie sie auch in "push_firmware" in Zeile 340 (https://github.com/Freetz-NG/freetz-ng/blob/master/tools/push_firmware#L340) berücksichtigt wurden, macht ja die (für mich unnötige) Verwendung von "hexdump" so unerklärlich.

Zumal es eben mit "od" auch eine POSIX-konforme Alternative gibt (iirc sogar in der BusyBox von AVM), die dank genauer Spezifikation (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html) auch wieder portabel ist, selbst wenn irgendwelche Versionen ggf. noch zusätzliche Optionen enthalten könnten.

Aber so ein "od" sollte auch wieder überall verfügbar sein, wo "POSIX" draufsteht und von der Anwendung her ist das praktisch dasselbe:
Rich (BBCode):
peh@vidar:~> cd /tmp/check_images/
peh@vidar:/tmp/check_images> od -An -x -N 4 kernel.image.5490
1281 feed
peh@vidar:/tmp/check_images>
- der Verzicht auf das "hexdump" (was in der POSIX-kompatiblen Form eben "od" heißt und daher wird es ein zweites, praktisch identisches POSIX-Tool wohl auch in der Zukunft nicht geben) ist/wäre also ganz einfach, selbst wenn man kein "base64" verwenden will - wobei mir der Vergleich der kompletten vier Byte (zwei der drei möglichen Werte sind ja nur sinnvoll - der für GRX5 mit "bootcore" und der für die anderen Modelle, solange es nicht die Puma6-ATOM-Signatur ist) immer noch logischer erscheint, als wenn man da nur die verbleibenden 16 Bit prüft, wie Du das jetzt machst.

Was hier auch gerne übersehen wird ... so, wie Du das jetzt implementiert hast, ist das - sowohl mit "hexdump" als auch mit "od" - immer noch plattformabhängig. Denn die Ausgabe benutzt hier ja "Worte" (also 16-Bit-Integer) als Grundlage und deren "Wert" ist eben davon abhängig, ob das System die Daten im "little endian"- oder im "big endian"-Format speichert. Bei einem "Byte-Strom" ist das egal, weil jedes Byte für sich betrachtet wird ... aber sowie die "Dateneinheiten" größer werden, spielt das sehr wohl eine Rolle. So ist eben der hexadezimale (Integer-)Wert 0x3031 (was den ASCII-Zeichen "01" entspricht, aber wir reden hier ja von Zahlen) bei der Speicherung auf einer LE-Maschine als "31 30" im Speicher zu finden (und natürlich auch in Dateien), während es auf einer BE-Maschine "30 31" wäre.

Das kann jeder mit einem x86-PC (mit Linux) und einer (MIPS-)FRITZ!Box (mit Shell-Zugang) ganz leicht selbst ausprobieren ... erzeugt man die Byte-Folge "81 12 ed fe" (so steht das ja in den Dateien) per "printf" (auf dem x86-PC) oder liest auf einer FRITZ!Box direkt die ersten vier Byte einer Kernel-Partition und gibt das dann an verschiedene Aufrufe von "hexdump" und "base64" weiter, so erzeugt eben die "hexdump"-Variante mit dem "-x"-Format (was Standard ist, wenn man nichts anderes angibt und deshalb bei "-n 4" zum Zuge kommt) unterschiedliche Ausgaben, je nachdem, auf welcher Architektur man sich befindet:
Rich (BBCode):
~ # grep Prod /proc/sys/urlader/environment
ProductID       Fritz_Box_HW185
~ # grep '"kernel"' /proc/mtd
mtd2: 00400000 00020000 "kernel"
~ # busybox head -c 4 /dev/mtd2 | busybox hexdump -C
00000000  81 12 ed fe                                       |....|
00000004
~ # busybox head -c 4 /dev/mtd2 | busybox hexdump -n 4
0000000 8112 edfe
0000004
~ # busybox head -c 4 /dev/mtd2 | busybox base64
gRLt/g==
~ #
Rich (BBCode):
peh@vidar:~> head -c 4 /tmp/check_images/kernel.image.7490-1 | hexdump -C
00000000  81 12 ed fe                                       |....|
00000004
peh@vidar:~> head -c 4 /tmp/check_images/kernel.image.7490-1 | hexdump -n 4
0000000 1281 feed
0000004
peh@vidar:~> head -c 4 /tmp/check_images/kernel.image.7490-1 | base64
gRLt/g==
peh@vidar:~> printf "\x81\x12\xed\xfe" | hexdump -C
00000000  81 12 ed fe                                       |....|
00000004
peh@vidar:~> printf "\x81\x12\xed\xfe" | hexdump -n 4
0000000 1281 feed
0000004
peh@vidar:~> printf "\x81\x12\xed\xfe" | base64
gRLt/g==
peh@vidar:~>

oder mal mit was ganz anderem, wenn man weder "hexdump", noch "od" und auch kein "base64" hat/haben will:

peh@vidar:~> printf "\x81\x12\xed\xfe" | cmp -b -n 4 -- /tmp/check_images/kernel.image.7490-1
peh@vidar:~> printf "\x12\x81\xed\xfe" | cmp -b -n 4 -- /tmp/check_images/kernel.image.7490-1 (Gegenprobe)
/tmp/check_images/kernel.image.7490-1 - differ: byte 1, line 1 is 201 M-^A  22 ^R
peh@vidar:~>
Wie Du siehst, ist die von Dir (und von denjenigen, die das vor Dir bearbeitet haben) gewählte Variante nun gerade eine, die auf unterschiedlichen Plattformen für dieselben Daten unterschiedliche Ausgaben liefert.

Wenn einem "base64" trotz seiner Schlichtheit und seiner Verbreitung nicht zusagt, kann man das - bei diesen wenigen Daten - immer noch zu Fuß und mit "cmp" machen (man gibt per "printf" die erwartete Bytefolge aus - siehe oben am Ende in den Beispielen - und läßt die vergleichen mit den ersten vier Byte der Datei), wobei man da auch einfach den Return-Code auswerten kann und die Option "-b" nicht braucht.

Es gibt also (wie immer unter der Shell) viele verschiedene Wege ... und man ist - wenn man einen wirklich portablen dabei wählt - auch nicht davon abhängig, auf welcher Plattform das Skript nun läuft.

Es ist sicherlich nicht sehr häufig, daß eine BE-Maschine als Build-Host für Freetz zum Einsatz kommt ... aber die alten Motorola-Macs oder die mit den PowerPC-Prozessoren (wobei die umschaltbar waren) kämen mit passendem Linux dafür ja durchaus auch in Betracht - und selbst wenn man nicht weiß, ob der Rest der Freetz-Toolchain da mitspielen würde oder ob da noch weitere Fallstricke enthalten sind, wenn das mal nicht auf einer Maschine mit "Intel-Format" bei der Datenspeicherung arbeitet, muß man ja nicht in die eigenen Programme und Skripte entsprechende Beschränkungen einbauen, wenn es auch anders (in meinen Augen auch "smarter") geht.

BTW/EDIT:
Wenn man tatsächlich die Vergleichswerte mit "printf" erzeugt, sollte man - anders als ich es wegen der größeren Anschaulichkeit oben getan habe - auch gleich oktale Werte anstelle von hexadezimalen verwenden, weil diese Notation auch nicht POSIX-konform ist (also z.B. "\033" anstelle von "\x1B").
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.