pcmhacking.net

Looking at the file system could I assume the section in front of the mdt8 partition(serialnum) isn't used by anything else? I didn't see any reference to it in the config files..

I have been successful in simply reconfiguring the setbootargsprimary using askenv and saving it, then changing the serialnum config file and also setting it up in test mode.. Then once you boot it tells you there is no serial number but lets you set one and it's successful in writing it, then change the test mode and init file back and you're good to go...

Seems to work fine for diagnostics, haven't had a change to try a reflash yet, my only concern is something else is accessing that flash in between mtd7 and mtd8.. As long as nothing touches it this seems to work just fine..

Course I'm pretty sure this will revert back to the old serial and partition table during a restore.. just having fun with this, lol...

What do you mean between mtd7 and mtd8? Arnt they back to back? What setbootargsprimary are you using?

the clone's set boot primary specifies where mtd8(serialnum) starts.. at least that's what I think it's doing.. serialnum is specified to start at 16320 and is only 32k long.. macaddress starts right after.. There is room to make serial num 128k long and keep macaddress in the same location.. below is the clone's setbootargsprimary.. I don't have the genuine MDI's because I can't get into U-boot yet.. Next time I have a few minutes to tinker I think I might try hex editing the flash to allow access..

setbootargsprimary=run normalargs addinit addconsole addeth addprimary;setenv bootargs ${bootargs} mtdparts=flash0:256k(boot),128k(bootvars),1536k(linux1),6144k(initrd1),1536k(linux2),6144k(initrd2),128k(linuxvars1),128k(linuxvars2),32k@16320k(serialnum),32k(macaddress);

looking at the partitions you'll see that there is a gap between mtd7(linuxvars) end and mtd8(serialnum) start..
Jan 1 00:00:05 1220-19721972 kernel: 0x00000000-0x00040000 : "boot"
Jan 1 00:00:05 1220-19721972 kernel: 0x00040000-0x00060000 : "bootvars"
Jan 1 00:00:05 1220-19721972 kernel: 0x00060000-0x001e0000 : "linux1"
Jan 1 00:00:05 1220-19721972 kernel: 0x001e0000-0x007e0000 : "initrd1"
Jan 1 00:00:05 1220-19721972 kernel: 0x007e0000-0x00960000 : "linux2"
Jan 1 00:00:05 1220-19721972 kernel: 0x00960000-0x00f60000 : "initrd2"
Jan 1 00:00:05 1220-19721972 kernel: 0x00f60000-0x00f80000 : "linuxvars1"
Jan 1 00:00:05 1220-19721972 kernel: 0x00f80000-0x00fa0000 : "linuxvars2"
Jan 1 00:00:05 1220-19721972 kernel: 0x00ff0000-0x00ff8000 : "serialnum"
Jan 1 00:00:05 1220-19721972 kernel: mtd: partition "serialnum" doesn't start on an erase block boundary -- force read-only
Jan 1 00:00:05 1220-19721972 kernel: 0x00ff8000-0x01000000 : "macaddress"
Jan 1 00:00:05 1220-19721972 kernel: mtd: partition "macaddress" doesn't start on an erase block boundary --force read-only

You could copy mtd1 from a genuine to the clone and that way if there is any checksum on 'bootvars' it'll be correct. You'll also get the same config as the genuine, but you'll loose u-boot on the clone.

So yeah I see what you mean, your moving the start of serial num back to FA0000 and extending its size, so its back to back with linuxvars2 and ends before macadderss. That would safe, that area is unmapped and its a safe bet nothing is there.

Hi and sorry for bumping this old thread.

I've got a genuine ETAS GM MDI with missing complete serial number(4+8 digits), so I need to be able to run 'serialnum'.
I read in this thread that the clones' uboot has bootdelay=3 but the genuine seems to have bootdelay=0 because the counter never increase and nothing happens when I hit a key.
Anyone know if there is any other way to stop it from continuing the booting? Or if there are any other way to get hold of the complete serial number.