Kobo Original N416 SD Card Image

[tonyyng]

Much to catch up on with lots of good suggestions. I'm going to try dnw first and then look at the other options.

@RandomInsano

Originally Posted by RandomInsano

This is looking great! I'm especially excited about being able to boot from USB as I can just re-configure U-boot to default to `loadum & boot`making testing various kernel builds possible (if I choose to go down that route)!

My biggest concerns at the moment are this error:

end_request: I/O error, dev mmcblk0, sector 2765263

And this guy from U-Boot:

init=uxrc

The I/O error and missing text make me think the internal Flash memory is failing, and that getting this thing booting via SD card is *probably* the best way to go.

When I compared your terminal output with mine, I was concerned about the differences that I saw. (post #8) However, looking closer, I think the serial connection has just dropped some characters. It was your log that I saw the "init=uxrc". My log was correct. "init=/linuxrc". It just didn't exist because the rootfs was corrupt.

As you pointed out (I think), I don't think the error message with mmcblk0 is relevant, since that is the SD card. If the kobo worked correctly, I wouldn't need the SD card.

@BloodRagg
The kobo-upgrade-1.8.zip only has
fs.img
u-boot.bin-eb600em
uImage-eb600em
I have previously updated my kobo's flash with these items.

[tonyyng]

Success on using the dnw linux port, using the Makefile changes recommended by NickE

On Kobo (bootu)

eBR-1A # loadum 31000000
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_VBUS
IspHandle......................PHPDC_MODE_SOFTCT
IspHandle......................PHPDC_IE_RESM
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
[isp_WaitForConfigure] download into 0x31000000
+phgPdc_Remove
-phPdc_Remove
[isp_WaitForConfigure]---

On Ubuntu:

tony@tony-Vostro-2520:~/dnw-linux-master/src/dnw$ ./dnw -a 0x31000000 Makefile
load address: 0x31000000
Can not open /dev/secbulk0: No such file or directory
tony@tony-Vostro-2520:~/dnw-linux-master/src/dnw$ ./dnw --help
./dnw: invalid option -- '-'
Usage: dwn [-a load_addr] <filename>
Default load address: 0x57e00000

Hmm - missing /dev/secbulk0?

tony@tony-Vostro-2520:/dev$ ls -l | grep secbulk
crw-rw-rw-  1 root disk    180,   1 Mar 10 10:19 secbulk1
tony@tony-Vostro-2520:/dev$ sudo ln -s secbulk1 secbulk0

tony@tony-Vostro-2520:~/dnw-linux-master/src/dnw$ ./dnw -a 0x31000000 Makefile
load address: 0x31000000
Writing data...
100%    0x00000061 bytes (0 K)
speed: infM/S
tony@tony-Vostro-2520:~/dnw-linux-master/src/dnw$

Back on Kobo:

eBR-1A # md 31000000
31000000: 776e640a 64203a20 632e776e 6367090a    .dnw : dnw.c..gc
31000010: 672d2063 206f2d20 24204024 0a090a5e    c -g -o $@ $^...
31000020: 61656c63 0a3a206e 206d7209 2066722d    clean :..rm -rf
31000030: 20776e64 0a6f2e2a 736e690a 6c6c6174    dnw *.o..install
31000040: 64203a20 090a776e 24207063 752f205e     : dnw..cp $^ /u
31000050: 622f7273 790a6e69 e1a00018 e1a00000    sr/bin.y........
31000060: ea000002 016f2818 00000000 0017a340    .....(o.....@...
31000070: e1a07001 e1a08002 e10f2000 e3120003    .p....... ......

I'm not sure why I needed to create the symlink for /dev/secbulk0, but dnw works after I created the link.

At this point, I'm uncertain as to what to do next. RandomInsano's approach for fixing the kernel was to modify the memory at 0x31000000 and then use nandw to update flash at 0x80000. However, the kernel was only ~1MB in size.

I think I'm trying to repair mtdblock6 which lives in flash at:
0x0a4c0000-0x40000000 : "other"

I have NickE's image file of mtblock6 which is 836MB in size. I don't want to mess things up, now that I've gotten this far.

Should I be using loadu or loadum? What memory address/flash address should I be using?

Thanks

[tonyyng]

Originally Posted by RandomInsano

Update2: Just thinking about the I/O error, that should be the SD card. The segfault of `nickel` could be for any number of reasons but it's likely missing or corrupted libraries. From my poking around that all lives inside of "/usr/local/" with "Kobo" holding `nickel` and `Trolltech` holding the Qt libraries.

Here's the file listing on mine:

/usr/local/
/usr/local/Trolltech
<snip>

I had to sort both lists to do a compare, but my file listing of the /usr/local directory was identical. Some of my actual files could be corrupted though. Perhaps come back to this point after seeing if mtblock6 works after using the dnw tool.

[tonyyng]

I can't figure out how loadu works. I tried an experiment with it.

I know the kernel image is stored on the nand at 0x80000 and is copied to memory at 0x31000000. Using uboot commands, I confirmed this:

eBR-1A # nandv 80000
000h: 27 05 19 56 f4 91 0f 3f 4c 11 3c 57 00 17 a3 40
010h: 30 00 80 00 30 00 80 00 f4 67 23 80 05 02 02 00
eBR-1A # md 31000000
31000000: 56190527 3f0f91f4 573c114c 40a31700    '..V...?L.<W...@
31000010: 00800030 00800030 802367f4 00020205    0...0....g#.....

Then I used mw to change a few bytes and nandw to write them

eBR-1A # mw.b 31000000 0 8
eBR-1A # md 31000000
31000000: 00000000 00000000 573c114c 40a31700    ........L.<W...@
31000010: 00800030 00800030 802367f4 00020205    0...0....g#.....
<snip>
eBR-1A # nandw 80000 8 31000000
eBR-1A # nandv 80000
000h: 00 00 00 00 00 00 00 00 4c 11 3c 57 00 17 a3 40
010h: 30 00 80 00 30 00 80 00 f4 67 23 80 05 02 02 00

Then guessing at the loadu steps:

eBR-1A # loadu 80000
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_VBUS
IspHandle......................PHPDC_MODE_SOFTCT
IspHandle......................PHPDC_IE_RESM
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
[isp_WaitForConfigure] download into 0x00080000

In Linux:
tony@tony-Vostro-2520:~/dnw-linux-master/src/dnw$ ./dnw -a 0x80000 ~/kobo-update-1.8/uImage-eb600em
load address: 0x00080000
Writing data...
100%    0x0017A38A bytes (1512 K)
speed: 0.244567M/S

+phgPdc_Remove
-phPdc_Remove
[isp_WaitForConfigure]---
Download O.K.
NFAddress=0x00000000
<Uboot> BaseBlock=0x00000000, BaseAddr=0x00000000
<Uboot> BlockSize=  00000004, ByteLength=0x00080000
From 0x00000000 to 0x00020000
Target write size = 0x00020000
Erase Block] from [0x00000000] to [0x00000000] total [0x00000001]
Erase addr ] from [0x00000000] to [0x0001ffff]
Erase finished
From 0x00020000 to 0xfffffff6
Target write size = 0xfffdfff6
Erase Block] from [0x00000001] to [0x00007fff] total [0x00007fff]
Erase addr ] from [0x00020000] to [0xffffffff]
Erase finished
Program finished
eBR-1A # nandv 80000
000h: 00 00 00 00 00 00 00 00 4c 11 3c 57 00 17 a3 40
010h: 30 00 80 00 30 00 80 00 f4 67 23 80 05 02 02 00

eBR-1A # md 80000
00080000: 00000000 00000000 00000000 00000000    ................
00080010: 00000000 00000000 00000000 00000000    ................
00080020: 00000000 00000000 00000000 00000000    ................
00080030: 00000000 00000000 00000000 00000000    ................

I don't get it. It doesn't appear to update the nand or memory at 0x80000.

Here's the output from using loadum and nandw for the kernel image:

eBR-1A # loadum 31000000
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_VBUS
IspHandle......................PHPDC_MODE_SOFTCT
IspHandle......................PHPDC_IE_RESM
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
IspHandle......................PHPDC_IE_SUSP
IspHandle......................PHPDC_IE_RESM
IspHandle........................PHPDC_IE_RST
[isp_WaitForConfigure] download into 0x31000000
+phgPdc_Remove
-phPdc_Remove
[isp_WaitForConfigure]---
Download O.K.
NFAddress=0x31000000
Program finished
eBR-1A # nandw 80000 200000 31000000
From 0x00080000 to 0x00280000
Target write size = 0x00200000
Erase Block] from [0x00000004] to [0x00000013] total [0x00000010]
Erase addr ] from [0x00080000] to [0x0027ffff]
Erase finished
eBR-1A # nandv 80000
000h: 27 05 19 56 f4 91 0f 3f 4c 11 3c 57 00 17 a3 40
010h: 30 00 80 00 30 00 80 00 f4 67 23 80 05 02 02 00

Notice the difference in the Erase addr messages:
loadu: Erase addr ] from [0x00000000] to [0x0001ffff]
loadu: Erase addr ] from [0x00020000] to [0xffffffff]

nandw: Erase addr ] from [0x00080000] to [0x0027ffff]


This output from the loadu approach doesn't look right. The base address and the ByteLength are incorrect.

NFAddress=0x00000000
<Uboot> BaseBlock=0x00000000, BaseAddr=0x00000000
<Uboot> BlockSize= 00000004, ByteLength=0x00080000

Perhaps the dnw communication with loadu isn't correct?

[RandomInsano]

I’m not sure about how `loadu` works, but it’s only reasonable to use to pass information that would fit inside the measily amount of RAM the N416 has. Good for kernels to boot from USB, bad for larger storage.

I think if you’re at a point where the kernel is happy, the next step is to use `dd` to copy an image from an SD card into mtdblock0p6.

I got myself a Kobo Mini for dev work now, but before I sit down to play with it I’ll try and see what you’d need to do with the data on the recorveey SD card to wipe the “onboard” parition.

[tonyyng]

Originally Posted by RandomInsano

I’m not sure about how `loadu` works, but it’s only reasonable to use to pass information that would fit inside the measily amount of RAM the N416 has. Good for kernels to boot from USB, bad for larger storage.

I think if you’re at a point where the kernel is happy, the next step is to use `dd` to copy an image from an SD card into mtdblock0p6.

I got myself a Kobo Mini for dev work now, but before I sit down to play with it I’ll try and see what you’d need to do with the data on the recorveey SD card to wipe the “onboard” parition.

See posts 18 and 20. I can't get /dev/mtdblock6 to mount properly. It doesn't appear to be available when I boot from nand or sd. Any suggestions?

Also, do you know how much ram is available and what address it is referenced at? Can I write 836mb (the size of the mtdblock6 image I got from NickE) to 0x31000000?

I could try breaking up the file into chunks and using loadum and nandw to write the chunks to the nand.

[RandomInsano]

It's itty itty bitty. About 64MB, and some of that U-boot'll be using.

If you have a shell, you should be able to do something like the following:

dd if=fs.img of=/dev/mtdblock6 bs=1024k

Then wait awhile. Assuming "fs.img" is a byte-for-byte disk image that should be all that's required there. Though I'm not 100% sure that's the "/mnt/onboard" partition, it'll be pretty much the same as what you're trying to do with `loadu` + `nandw` just with less fiddling with tools.

[tonyyng]

I tried dd two ways. First from booting from NAND, mounting the SD and reading the disk image from /mnt/sd/fs. Second attempt was booting from sd and reading the disk image from /fs. Both fail with the same reason:

Init Flash Error !!!
fd_init Done !!!
insmod: can't insert '/lib/modules/module.ko': Operation not permitted
mount: mounting /dev/mtdblock6 on /mnt/onboard failed: No such device or address
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x00000023 umcon 0x00000000

Please press Enter to activate this console. hwclock: settimeofday() failed: Invalid argument

# cd /fs
# ls -ltr
-rw-r--r--    1 1000     1000    876609536 Feb 27  2019 N416mtdblock6.img
# dd if=N416mtdblock6.img of=/dev/mtdblock6 bs=1024k
dd: can't open '/dev/mtdblock6': No such device or address

Logs for both attempts attached.

[RandomInsano]

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:

[\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:

$ 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/

[tonyyng]

In response to your questions:

Again, you *could* sacrifice an SD card to make that your "onboard" partition but maybe that's not the point of noodling with this.

Right. This has become an intellectual exercise only. If I don't get it working soon, it's going to the scrap bin.

You're only going to be out $10 if we brick this thing right?

Right and I'm hoping we brick it sooner than later so I stop having an excuse to play with this thing.

I think that large "mtdb4" may just be a stray file for you.

I deleted it and it didn't have an impact.

Here's my mtd devices and attempts to read from them:

# cd /dev
# ls -l | grep mtd
ls: ./mtdb6: Input/output error
brw-r--r--    1 root     root      90,   0 Feb 26  2019 mtd0
brw-r--r--    1 root     root      90,   1 Feb 26  2019 mtd0ro
brw-r--r--    1 root     root      90,   2 Feb 26  2019 mtd1
brw-r--r--    1 root     root      90,   3 Feb 26  2019 mtd1ro
brw-r--r--    1 root     root      90,   4 Feb 26  2019 mtd2
brw-r--r--    1 root     root      90,   5 Feb 26  2019 mtd2ro
brw-r--r--    1 root     root      90,   6 Feb 26  2019 mtd3
brw-r--r--    1 root     root      90,   7 Feb 26  2019 mtd3ro
crw-r--r--    1 root     root      90,   8 Feb 26  2019 mtd4
brw-r--r--    1 root     root      90,   9 Feb 26  2019 mtd4ro
brw-r--r--    1 root     root      90,  10 Feb 26  2019 mtd5
brw-r--r--    1 root     root      90,  11 Feb 26  2019 mtd5ro
brw-r--r--    1 root     root      90,  12 Feb 26  2019 mtd6
brw-r--r--    1 root     root      90,  13 Feb 26  2019 mtd6ro
brw-r--r--    1 root     root      31,   0 Feb 26  2019 mtdblock0
brw-r--r--    1 root     root      31,   1 Feb 26  2019 mtdblock1
brw-r--r--    1 root     root      31,   2 Feb 26  2019 mtdblock2
brw-r--r--    1 root     root      31,   3 Feb 26  2019 mtdblock3
brw-r--r--    1 root     root      31,   4 Aug 29 13:10 mtdblock4
brw-r--r--    1 root     root      31,   5 Feb 26  2019 mtdblock5
brw-r--r--    1 root     root     240,   0 Feb 26  2019 mtdblock6
# dd if=/dev/mtdblock0 of=/dev/null bs=1024k
0+1 records in
0+1 records out
# 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
end_request: I/O error, dev mtdblock4, sector 298752
Buffer I/O error on device mtdblock4, logical block 37344
end_request: I/O error, dev mtdblock4, sector 298760
Buffer I/O error on device mtdblock4, logical block 37345
end_request: I/O error, dev mtdblock4, sector 298768
Buffer I/O error on device mtdblock4, logical block 37346
end_request: I/O error, dev mtdblock4, sector 298776
Buffer I/O error on device mtdblock4, logical block 37347
end_request: I/O error, dev mtdblock4, sector 298784
Buffer I/O error on device mtdblock4, logical block 37348
end_request: I/O error, dev mtdblock4, sector 298792
Buffer I/O error on device mtdblock4, logical block 37349
end_request: I/O error, dev mtdblock4, sector 298800
Buffer I/O error on device mtdblock4, logical block 37350
end_request: I/O error, dev mtdblock4, sector 298808
Buffer I/O error on device mtdblock4, logical block 37351
end_request: I/O error, dev mtdblock4, sector 298816
Buffer I/O error on device mtdblock4, logical block 37352
end_request: I/O error, dev mtdblock4, sector 298824
Buffer I/O error on device mtdblock4, logical block 37353
end_request: I/O error, dev mtdblock4, sector 298832
end_request: I/O error, dev mtdblock4, sector 298840
end_request: I/O error, dev mtdblock4, sector 298848
end_request: I/O error, dev mtdblock4, sector 298856
end_request: I/O error, dev mtdblock4, sector 298864
end_request: I/O error, dev mtdblock4, sector 298872
end_request: I/O error, dev mtdblock4, sector 298880
end_request: I/O error, dev mtdblock4, sector 298896
end_request: I/O error, dev mtdblock4, sector 298904
end_request: I/O error, dev mtdblock4, sector 298912
end_request: I/O error, dev mtdblock4, sector 298920
end_request: I/O error, dev mtdblock4, sector 298928
end_request: I/O error, dev mtdblock4, sector 298936
end_request: I/O error, dev mtdblock4, sector 298944
end_request: I/O error, dev mtdblock4, sector 298952
end_request: I/O error, dev mtdblock4, sector 298960
end_request: I/O error, dev mtdblock4, sector 298968
end_request: I/O error, dev mtdblock4, sector 298976
end_request: I/O error, dev mtdblock4, sector 298984
end_request: I/O error, dev mtdblock4, sector 298992
end_request: I/O error, dev mtdblock4, sector 299000
end_request: I/O error, dev mtdblock4, sector 298752
end_request: I/O error, dev mtdblock4, sector 298752
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
dd: can't open '/dev/mtdblock6': No such device or address

More on the mtdblock4 errors in the next post.

[tonyyng]

Since post 17 (Feb 26), my mtdblock4 device has seemed to be working. Given the other problems though, I thought it would be worthwhile trying to rebuild it, as NickE suggested at the end of post 12.

My approach was to bootsd and then use dd to write fs.img (from kobo-update-1.8.zip)

# cd /fs
# ls -ltr
-rw-r--r--    1 1000     1000    876609536 Feb 27  2019 N416mtdblock6.img
-rw-rw-r--    1 1000     1000     57735744 Mar 17  2019 fs.img
# dd if=fs.img of=/dev/mtdblock4 bs=1024k
55+1 records in
55+1 records out
# reboot

However, after I did that, my situation regressed to where I was at the beginning of this mess.

Here's the end of the boot log, with complaints that the /linuxrc failing to execute:

yaffs: dev is 32505860 name is "mtdblock4"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.4, "mtdblock4"
yaffs: auto selecting yaffs2
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
***kay***  :gpio_getpin ret 0 gpio_wprotect 32
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
s3c2410-sdi s3c2410-sdi: CMDSTAT: error CMDTIMEOUT
mmc0: error requesting CID: -110
mmcblk0: mmc0:1234 SD02G 1992704KiB
 mmcblk0: p1
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
VFS: Mounted root (yaffs filesystem).
Freeing init memory: 96K
Warning: unable to open an initial console.
Failed to execute /linuxrc.  Attempting defaults...
SBZ: try run /sbin/init
SBZ: try run /etc/init
SBZ: try run /bin/init
SBZ: try run /bin/sh
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

When I bootsd again and mount /dev/mtdblock4, it looks like garbage in the filesystem, with duplicate files (linuxrc) and some junk (D files):

bootsd

# mount /dev/mtdblock4 /mnt/mtd4/
yaffs: dev is 32505860 name is "mtdblock4"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.4, "mtdblock4"
yaffs: auto selecting yaffs2
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
# ls -l mtd4/
-rw-r--r--    1 root     root            0 Aug 29 05:23 D
-rw-r--r--    1 root     root            0 Aug 29 05:23 D
drwxr-xr-x    1 root     root         2048 Aug 28 08:53 bin
drwxr-xr-x    1 root     root         2048 Aug 28 08:53 boot
drwxr-xr-x    1 root     root         2048 Aug 28 08:54 etc
lrwxrwxrwx    1 root     root           11 Aug 28 08:57 linuxrc -> bin/busybox
lrwxrwxrwx    1 root     root           11 Aug 28 08:57 linuxrc -> bin/busybox
drw-rw-rw-    1 root     root         2048 Aug 29 12:39 lost+found
drwxr-xr-x    1 root     root         2048 Aug 28 08:57 mnt
drwxr-xr-x    1 root     root         2048 Jan  1  1970 proc
drwxr-xr-x    1 root     root         2048 Aug 28 08:55 sbin
drwxr-xr-x    1 root     root         2048 Jan  1  1970 tmp
drwxr-xr-x    1 root     root         2048 Aug 28 08:55 usr

I tried to delete the files in /mnt/mtd4 so I could copy them again from the sdcard's root folder, but deleting certain files from /mnt/mtd4 causes a reboot:

# rm -rf mtd4/
Unable to handle kernel NULL pointer dereference at virtual address 00000008
arch_reset: attempting watchdog reset

@@@@@ REBOOT @@@@@ <- this is text I added

U-Boot 1.1.4 (Jun 22 2010 - 14:55:31)
U-Boot code: 33F80000 -> 00000000  BSS: -> 33FAB614

After trying to delete various files/directories, I'm left with the following in mtdblock4:

# mount /dev/mtdblock4 /mnt/mtd4
yaffs: dev is 32505860 name is "mtdblock4"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.4, "mtdblock4"
yaffs: auto selecting yaffs2
**>> Block 1166 retired
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
yaffs tragedy: attempting to use non-directory as a directory in scan. Put in lost+found.
**>> Block 979 retired
**>> Block 1279 retired
# ls -l /mnt/mtd4/
drwxr-xr-x    1 root     root         2048 Aug 28 08:54 etc
drw-rw-rw-    1 root     root         2048 Aug 29 14:03 lost+found
drwxr-xr-x    1 root     root         2048 Aug 28 08:55 sbin

Just "cd"ing to one of these directories results in a reboot. Any ideas on how to reset a yaffs filesystem?

[tonyyng]

Before trashing mtdblock4 (previous post), I tried restoring mtdblock6 using loadum, dnw and nandw. It didn't solve anything, but I thought I'd mention it.

First I determined how much memory I had to work with:

eBR-1A # mw.b 31000000 0 4000000 # reboots
eBR-1A # mw.b 31000000 0 3000000 # reboots
eBR-1A # mw.b 31000000 0 2000000 # ok 32M

Then, on Linux, I broke up the file image I got from Nick into 32M chunks:

tony@tony-Vostro-2520:~/mtdblock6$ split -b 32M -d N416mtdblock6.img b6img-split
tony@tony-Vostro-2520:~/mtdblock6$ ls -ltr
total 1712132
-rw-r--r-- 1 tony tony 876609536 Mar 17 12:09 N416mtdblock6.img
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split00
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split01
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split02
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split03
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split04
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split05
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split06
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split07
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split08
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split09
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split10
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split11
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split12
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split13
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split14
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split15
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split16
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split17
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split18
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split19
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split20
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split21
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split22
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split23
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:09 b6img-split24
-rw-rw-r-- 1 tony tony  33554432 Mar 17 12:10 b6img-split25
-rw-rw-r-- 1 tony tony   4194304 Mar 17 12:10 b6img-split26

Then for each chunk, I did the following steps:

eBR-1A # loadum 31000000
tony@vostro-2520:~/dnw-linux-master/src/dnw$ ./dnw -a 0x31000000 ~/mtdblock6/b6img-split00
eBR-1A # nandw a4c0000 2000000 31000000

loadum 31000000
dnw -a 0x31000000 ~/mtdblock6/b6img-split01
nandw C4C0000 2000000 31000000

<snip>
loadum 31000000
dnw -a 0x31000000 ~/mtdblock6/b6img-split25
nandw 3C4C0000 2000000 31000000

mw.b 31000000 ff 2000000
loadum 31000000
dnw -a 0x31000000 ~/mtdblock6/b6img-split26
nandw 3E4C0000 500000 31000000  # last one slightly different

I was hopeful, but this didn't have any impact on the errors trying to access /dev/mtdblock6.

[tonyyng]

Originally Posted by RandomInsano

https://bootlin.com/blog/managing-fl...ge-with-linux/

I scanned through this article, understanding a bit of it. It mentions flash_eraseall, which is part of MTD utilities. Anyone know where I can find binaries that will run in this environment?

Edit: Found some at the bottom of this page: https://wiki.beyondlogic.org/index.p..._Utils_for_ARM

I'll download them and give them a try, but I'm a noobie with regards to Linux versions/architecture/CPU.

[tonyyng]

I couldn't get the binaries to work:

# ls -l | grep flash
-rwxr-xr-x    1 root     root        84380 Feb  4  2012 flash_erase
-rwxr-xr-x    1 root     root          150 Feb  4  2012 flash_eraseall
-rwxr-xr-x    1 root     root        11808 Feb  4  2012 flash_lock
-rwxr-xr-x    1 root     root        10416 Feb  4  2012 flash_otp_dump
-rwxr-xr-x    1 root     root        10753 Feb  4  2012 flash_otp_info
-rwxr-xr-x    1 root     root        11818 Feb  4  2012 flash_unlock
-rwxr-xr-x    1 root     root        25226 Feb  4  2012 flashcp
# ./flash_erase
/bin/sh: ./flash_erase: not found

But maybe they need to be "installed" along with their dependencies?

Back on ubuntu, I used file/ldd to look at the binaries on the sd card I've been booting from:

root@tony-Vostro-2520:/mnt/sd/mtdutils-1.4.9/sbin# file flash_erase
flash_erase: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
root@tony-Vostro-2520:/mnt/sd/mtdutils-1.4.9/sbin# ldd flash_erase
        not a dynamic executable

flash_erase: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x897310145779d26409542e12fc151822d3ef395d, not stripped
root@tony-Vostro-2520:/mnt/sd/mtdutils-1.5.0/sbin# ldd flash_erase
        not a dynamic executable

The "file" information looks similar to the busybox binary for the kobo

root@tony-Vostro-2520:/mnt/sd# file bin/busybox
bin/busybox: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.4.3, stripped

Here's some more information about the kobo environment

Linux-version 2.6.18.2-ntx600-v0.82
Uboot-version CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
# uname -a
Linux (none) 2.6.18.2-ntx600-v0.82 #6 Thu Jun 10 15:26:02 EDT 2010 armv4tl GNU/Linux

Am I barking up the wrong tree?

[BloodRagg]

Originally Posted by tonyyng

@BloodRagg
The kobo-upgrade-1.8.zip only has
fs.img
u-boot.bin-eb600em
uImage-eb600em
I have previously updated my kobo's flash with these items.

Its a yaffs filesystem, you can unpack it with unyaffs. Then run the sha256sum like i mentioned in the previous post. I unpacked it for you into a tarball. PM sent.

EDIT1: Hope I wasnt too late, reading last weeks follow ups now.

EDIT2: After catching up you can clear out mtdblock6 like this:

# Note the partition label of mtdblock6
blkid

# Unmount mtd device
umount /dev/mtdblock6

# Zero the device
dd if=/dev/zero of=/dev/mtdblock6 bs=1M conv=fsync

# Then format it with:
# options:
# -c
#    Check the device for bad blocks before creating the file system. 
#
# -n volume-name
#    Sets the volume name (label) of the file system. The volume name can be up to 11 characters long. The default is no label. 
#
# -v
#    Verbose execution.
msdosfs -c -n LABEL-FROM-BLKID -v /dev/mtdblock6

# Mount it again
mount -t vfat -o iocharset=utf8 /dev/mtdblock6 /mnt/onboard