This is definitely a weird situation. Mainly because from your kernel boot message *and* your checking of the mtd devices, that darn partition is clearly there.
Creating 7 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x00080000 : "uboot"
0x00080000-0x00260000 : "kernel"
0x002e0000-0x003a0000 : "picture"
0x003a0000-0x003c0000 : "parameters"
0x003c0000-0x0a3c0000 : "rootfs"
0x0a3c0000-0x0a4c0000 : "app"
0x0a4c0000-0x40000000 : "other"
Again, you *could* sacrifice an SD card to make that your "onboard" partition but maybe that's not the point of noodling with this.
FWIW, here's my mtd devices:
Code:
[\u@\h \W]\$ ls -l | grep mtd
brw-r--r-- 1 root root 90, 0 Feb 3 2010 mtd0
brw-r--r-- 1 root root 90, 1 Feb 3 2010 mtd0ro
brw-r--r-- 1 root root 90, 2 Feb 3 2010 mtd1
brw-r--r-- 1 root root 90, 3 Feb 3 2010 mtd1ro
brw-r--r-- 1 root root 90, 4 Feb 3 2010 mtd2
brw-r--r-- 1 root root 90, 5 Feb 3 2010 mtd2ro
brw-r--r-- 1 root root 90, 6 Feb 3 2010 mtd3
brw-r--r-- 1 root root 90, 7 Feb 3 2010 mtd3ro
crw-r--r-- 1 root root 90, 8 Jan 1 1970 mtd4
brw-r--r-- 1 root root 90, 9 Feb 3 2010 mtd4ro
brw-r--r-- 1 root root 90, 10 Feb 3 2010 mtd5
brw-r--r-- 1 root root 90, 11 Feb 3 2010 mtd5ro
brw-r--r-- 1 root root 90, 12 Feb 3 2010 mtd6
brw-r--r-- 1 root root 90, 13 Feb 3 2010 mtd6ro
brw-r--r-- 1 root root 31, 0 Oct 19 2009 mtdblock0
brw-r--r-- 1 root root 31, 1 Oct 19 2009 mtdblock1
brw-r--r-- 1 root root 31, 2 Oct 19 2009 mtdblock2
brw-r--r-- 1 root root 31, 3 Oct 24 2009 mtdblock3
brw-r--r-- 1 root root 31, 4 Oct 25 2009 mtdblock4
brw-r--r-- 1 root root 31, 5 Feb 3 2010 mtdblock5
brw-r--r-- 1 root root 240, 0 Feb 3 2010 mtdblock6
I think that large "mtdb4" may just be a stray file for you.
Would you be able to try and *read* from mtdblock6? I'm expecting it'll fail, and I'm trying to decide if trying to use `dd` magic on the whole flash chip is a good idea or not. In theory, you could either skip ahead to where the "onboard" partition starts or overwrite the whole thing from start to end. If it's an issue with the data structure of the flash then a full overwrite is the better course of action.
You're only going to be out $10 if we brick this thing right?
A little update, I see similar issues when I try and read the other mtdblock paritions on the flash:
Code:
$ dd if=/dev/mtd1 of=/dev/null bs=1024k
dd: can't open '/dev/mtd1': No such device or address
$ dd if=/dev/mtdblock6 of=/dev/null bs=1024k
$ dd if=/dev/mtdblock0 of=/dev/null bs=1024k
dd: /dev/mtdblock0: Input/output error
$ dd if=/dev/mtdblock1 of=/dev/null bs=1024k
1+1 records in
1+1 records out
$ dd if=/dev/mtdblock2 of=/dev/null bs=1024k
0+1 records in
0+1 records out
$ dd if=/dev/mtdblock3 of=/dev/null bs=1024k
0+1 records in
0+1 records out
$ dd if=/dev/mtdblock4 of=/dev/null bs=1024k
dd: /dev/mtdblock4: Input/output error
$ dd if=/dev/mtdblock5 of=/dev/null bs=1024k
1+0 records in
1+0 records out
$ dd if=/dev/mtdblock6 of=/dev/null bs=1024k
### I ejected my SD card at this point, killing my serial session over Bluetooth XD ###
Update #2: It turns out that "mtd" devices are defined at the kernel source level, so whether it's readable/writable is actually compiled into your kernel which is good. I'm no closer to finding the device you could access once the system is booted. You might very well need to do this from U-boot after all.
https://bootlin.com/blog/managing-fl...ge-with-linux/