Hi @PolynomialDivision
it would be interesting if the bootloader is booting this device via device-tree or legacy boot. device-tree can contain runtime configurations like cmdline but also other information e.g. which serial can be used.
Further it is possible for bootloaders to change the partition table depending which partition to boot.
OEM Bootlog
[ 0.000000] Kernel command line: gocommand console=ttyS0,115200n8r nor_size=0 sflash_size=64MB nand_size=0MB ethaddr=3C:A6:2F:1F:CF:95 slub_debug=-
Suspicious. What for is
nor_size=0 sflash_size=64MB nand_size=0MB
Who parse and use it? The kernel or userspoace?
Let's check the partition table
OEM Bootlog
[ 1.065446] Creating 6 MTD partitions on “ath-nor”:
[ 1.070473] 0x0000022d2e00-0x000004000000 : “rootfs”
[ 1.076717] [rootfs] use mtd0 (rootfs) as root
[ 1.081298] mtdsplit: no squashfs found in “rootfs”
[ 1.086267] 0x000002090000-0x0000022d2e00 : “kernel”
[ 1.092402] 0x000000000000-0x000000020000 : “urlader”
[ 1.098615] 0x000000020000-0x000000090000 : “tffs (1)”
[ 1.104976] 0x000002020000-0x000002090000 : “tffs (2)”
[ 1.111381] 0x000000090000-0x000002000000 : “reserved-kernel”
What in tffs (1) or tffs (2)?
Do you have a full dump of the flash (e.g. by booting an OpenWrt via tftp)?
mtdsplit is splitting up mtd partitions. This allows us to skip updating the kernel partition everytime it increase. Also it saves some flash memory.
This is also the reason why the kernel doesn't end up on an erase block (usually 64kbyte, depending on your flash).
Let's sort the partition table:
0x000000000000-0x000000020000 : “urlader”
0x000000020000-0x000000090000 : “tffs (1)”
0x000000090000-0x000002000000 : “reserved-kernel”
0x000002020000-0x000002090000 : “tffs (2)”
0x000002090000-0x0000022d2e00 : “kernel”
0x0000022d2e00-0x000004000000 : “rootfs”
This flash is huge. 64Mbyte. But is it really SPI-NOR? I would guess it's SPI-NAND. Can you check it?
Also I would guess AVM implement either A/B firmware scheme or a recovery/production scheme to make it harder to brick it.
So merging now the kernel + rootfs part
0x000002090000 - 0x000004000000.
This looks like the reserved-kernel partition with an offset.
So as start I would call this merged partition "firmware". OpenWrt treats mtd parts with name "firmware" special and is doing everything what it needs to be done.
If this is a SPI-NAND we have to use UBI and also have to check if the old bootloader even supports UBI. Or if it's possible to add a second stage u-boot.
Also we need to know how the A/B or recovery/production image works. How is the booted system reports it's running correct?
I'm also wondering where the calibration data are? From where does it take the mac address?