Kobo Original N416 SD Card Image

[RandomInsano]

Hey all,

I made a bit of a mistake trying to mount various parts of the mtdblock device on Linux and it wrote over the Linux RAM disk magic values here. I'm living in boot land with this:

From 0x00080000 to 0x00280000
Target read size = 0x00200000
Booting image at 31000000
Bad Magic Number


Is someone able to PM me the SD card image for this guy?

If not, I'm downloading an ancient version of the Kobo Desktop application to see if it'll allow me to use the `loadu` command to perform the upgrade. That may work, so here's the link (I lost the original post from this forum):
http://download.kobobooks.com/desktop/58/KoboSetup.dmg

Thanks!

[davidfor]

Sorry, I haven't seen an image for the original Kobo. I have no idea if one exists.

[BloodRagg]

I think i can help you

Create an image from the sdcard compress it and send me a PM with
1. the link (use filesend or something similar)
2. what you think you did wrong (including any commands you remember)
3. what you had hoped to achieve

I will:
1. try to fix it
2. send you a link with the fixed image.

Sounds good?

[RandomInsano]

Good news all! I spent a few hours yesterday hacking around and managed to unbrick things:

Using the link from the following thread, I was able to grab the kernel image:
https://www.mobileread.com/forums/sh...d.php?t=314655
http://download.kobobooks.com/firmwa...pgrade-1.8.zip

From there, because U-Boot doesn't have a good way to load data from an SD card (that I could find) I wrote a quick Python script that would convert the binary data from the "uImage-eb600em" into lines of text that U-Boot's `mm` command would understand.

I then connected with a USB-FTDI device to the system using `cu` from my Mac like so:

$ cu -l /dev/usb.tty-00000000 -s 115200

From here, I entered the right magic for `mm`:

U-Boot# mm 31000000

Once that was set up, I called on `cu`s `~>` send file functionality to essentially type out all 1.5MB of Kernel as though I were typing it by hand. This took probably around 3 hours to complete.
(ref: https://www.computerhope.com/unix/ucu.htm)

Once done, I typed "." and the enter key to exit `mm` and stored the RAM that was just transferred over using the following command:

U-Boot# nandw 80000 200000 31000000

After rebooting, I have my Kobo back!

I have some details over here:
https://gist.github.com/RandomInsano...621f4699d3595e

And here's the Python script in case that link ever gets lost to the sands of time:

#!/usr/bin/env python3

import sys

# There's some acrobatics here as our binary file
# is stored in a different endiannes than what U-Boot's
# `mm` command is expecting

with open(sys.argv[1], "rb") as f:
	bytes = f.read(4)
	while bytes != b'':
		buffer = list('00000000')
		i = 3
		for byte in bytes:
			value = list('{:02x}'.format(byte))
			buffer[i * 2] = value[0]
			buffer[i * 2 + 1] = value[1]

			i -= 1
		print(''.join(buffer))
		bytes = f.read(4)

[tonyyng]

I also have a Kobo Original N416 that I can't get to boot beyond three squares. I've tried the various reset techniques without success.

I've got the device opened up. Can you provide details of the steps required to connect it to an FTDI adapter?

Thanks

[nicke]

Below is an image of my N416. I have labeled TX/RX as the opposite of what my FTDI USB to Serial is labeled. (I have found that various adapters label these opposite, so you might have to swap them).

On Windows, look in Device Manager->Ports to determine the COM port. Use a terminal program like Putty, Teraterm, or Hyperterminal. Set the COM port to 115200,N,1,8.

On Linux, the link https://stackoverflow.com/questions/...u-10-10-maveri provides adequate instructions.

I usually connect to the serial port first, then try to either turn the N416 on (if it is off) or click the reset button (if it is on). If your bootloader is intact, you will see initialization messages. You must hit a key during the initialization to prevent u-boot from trying to load the kernel. From here, you have several options to rebuild the flash.

[tonyyng]

Thanks for the picture. It confirmed what I thought was the serial port.

I made some progress, but now I'm stuck. I'm using cu with MacOS and an FTDI adapter. As you suggested, I connected the serial first and then pressed the reset button. A bunch of messages were displayed in Terminal.

I hit a few keys during the output, but at the end, it hangs with these messsages:

yaffs: auto selecting yaffs2
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.

The complete log is attached.

I tried resetting a few more times with the same results.

Any suggestions on what to try next?

[tonyyng]

I compared my cu output with that from randominsano (ri).

These were the differences I thought might be relevant:

me: U-Boot 1.1.4 (Mar  9 2010 - 16:28:25)
ri: U-Boot 1.1.4 (Jun 22 2010 - 14:55:31)

I'm pretty sure my device is the original firmware as shipped.

me:
Kernel command line: noinitrd root=/dev/mtdblock4 rw rootfstype=yaffs init=/linuxrc console=ttySAC0 controller=2 PA_BB=29 PA_BT=1 FS_BB=30 FS_BT=1280 AP_BB=1310 AP_BT=8 US_BB=1318 US_BT=6874 UVer=ntx-600em-v2.6

ri:
Kernel command line: noinitrd root=/dev/mtdblock4 rw rootfstype=yaffs init=uxrc console=ttySAC0 controller=2 PA_BB=29 PA_BT=1 FS_BB=30 FS_BT=1280 AP_BB=1310 AP_BT=8 US_BB=1318 US_BT=6874 UVer=ntx-600em-v2.6

init=/linuxrc vs
init=uxrc

me:
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x00000023 umcon 0x00000000

ri:
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x0023 umcon 0x00000000

ubrdiv 0x00000023 vs 0x0023

me:
Warning: unable to open an initial console.
Failed to execute /linuxrc.  Attempting defaults...

ri:
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x00000023 umcon 0x00000000
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x00000023 umcon 0x00000000
PORT: 4034920448 baud 115200 uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051 ubrdiv 0x00000023 umcon 0x00000000

I'm not sure what to make of these differences. Hoping someone with more experience with these devices has some suggestions.

[tonyyng]

One other thing I tried was to put the device into firmware update mode. This is what Kobo Desktop prompts you to do before it attempts to write an update to the device through the usb port.

To do this, you power on holding Power/Menu/DPAD and the device boots with the LED red.

Here is the serial output:

U-Boot 1.1.4 (Mar  9 2010 - 16:28:25)
U-Boot code: 33F80000 -> 00000000  BSS: -> 33FAB5F4
SDRAM: 64 MB
io_check_em:  -1
***************init GPIO : set GPD13 to high
NAND device ID: [0xd3ec] [Samsun K9K8G08]
NAND Total Blocks=8192 <5>
nand_read_ecc: Attempt read beyond end of device 30000 10000 0
*** Warning - bad CRC or NAND, using default environment
io_check_em:  -1
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
TransferByDMA len=240000
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
TransferByDMA len=240000
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
TransferByDMA len=240000
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
io_check_em:  -1
PowerCheck:eb600em cost down
Battry only!!!
Battery voltage more than 3.3V!!!
USB device init ....chip_id:[0x00158230]..done.
USB information[ISP's USBD]: EP0: control, EP1: in, EP3: out
should perform loadu
IspHandle......................PHPDC_IE_SUSP

What the Desktop software does with the device in this state is described in this post:

Originally Posted by mTamblyn

It’s doing three things: First it copies the boot firmware, then the kernel. They get updated in the first 30 seconds. Then the application gets transferred over.

This isn't enough information for me to know what to do next, but maybe gives one of you experts some ideas of what else I could try.

Thanks

[nicke]

If you hit a key fast enough during boot, it should drop you into the u-boot prompt instead of booting the kernel.

Contained in the update file: kobo-upgrade-1.8.zip (or the older kobo-upgrade-1.4.zip):

fs.img
u-boot.bin-eb600em
uImage-eb600em

So, you should be able to use RandomInsano's technique to load the files into memory and then write to flash. Your kernel is booting already, so I would do the fs.img first and see if the kobo will boot all the way. Keep in mind that the fs.img itself contains another upgrade file that gets loaded by /etc/init.d/rcS.

The structure of the internal flash shown during boot as:

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"

If you want to test whether your existing kernel will work with the fs.img in the kobo-upgrade-1.x.zip without committing to writing it to internal flash, you can boot the rootfs from an SD card (I did this with a 1GB SD card I have lying around).
1) On a Linux (and presumably a Mac - but I don't know Mac) PC, create an ext3 partition on the SD card.

a) For the PC, get yaffshiv (a python script to extract the yaffs filesystem from fs.img). https://github.com/devttys0/yaffshiv
I used:

yaffshiv -a -f fs.img -d ./rootfs

b) Mount the SD card with the ext3 partition and copy the contents of the extracted yaffs filesystem to the root of the SD card:

cd rootfs
cp -P -r * /path/to/mounted/sdcard

2) With the kobo off and FTDI attached, put the SD card into the kobo

3) Here you have two choices:

a) Hold down the center D-pad button while powering on and watch the boot messages. Chances are it will boot all the way.
b) Hit a key during u-boot. Then, type bootsd. Watch the boot messages. Chances are it will boot all the way.

4) At this point, check to see if the /mnt/onboard structure exists:
# cd /mnt/onboard
# ls -la
drwxr-xr-x 5 root root 4096 Jan 1 1970 .
drwxr-xr-x 1 root root 2048 Jan 1 1970 ..
drwxr-xr-x 2 root root 4096 Apr 8 2009 .adobe-digital-editions
drwxr-xr-x 9 root root 8192 Mar 20 2017 .kobo
drwxr-xr-x 4 root root 4096 Apr 8 2009 Desktop Installers
-rwxr-xr-x 1 root root 298 Feb 19 07:46 bookmarks
-rwxr-xr-x 1 root root 3761 Feb 19 07:46 books

This gets mounted by /etc/init.d/rcS from mtdblock6.

If booted from SD card:
# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,data=ordered)
none on /proc type proc (rw)
none on /tmp type tmpfs (rw)
none on /var/log type tmpfs (rw)
none on /var/run type tmpfs (rw)
none on /sys type sysfs (rw)
/dev/mtdblock6 on /mnt/onboard type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset =utf8)

Compare to booted from flash:
# mount
rootfs on / type rootfs (rw)
/dev/root on / type yaffs (rw) <= the only difference!
none on /proc type proc (rw)
none on /tmp type tmpfs (rw)
none on /var/log type tmpfs (rw)
none on /var/run type tmpfs (rw)
none on /sys type sysfs (rw)
/dev/mtdblock6 on /mnt/onboard type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset =utf8)

Hopefully, the previous bad upgrade did not delete or corrupt mtdblock6 (it should not have touched these parts of the flash). If this is missing, you will need the mtdblock6 image. Otherwise, you should have a fully functional Kobo if the upgrade rootfs is compatible with the older kernel and u-boot.

[tonyyng]

Thanks for the detailed post. Most of it is over my head, but I was able to follow the instructions.

Some of my earlier problems were caused because I didn't have the FTDI adapter configured properly on my Mac. It wasn't letting me transmit data, so my keystrokes weren't being detected. As a result, it was booting the kernel and not dropping to u-boot. After struggling with it, I ended up switching to Teraterm on Windows connected to the device.

I used randominsano's technique to write the uImage-eb600em file from the 1.8 update to flash. My kobo's kernel is now 1.8, but I get the same errors when it tries to boot.

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.

Teraterm didn't have the same ability as cu for sending keystrokes from a file. I used copy/paste to send the encoded bytes, but I also had to use Teraterm's transmit delay, because the paste seemed to skip some characters at full speed. Pasting the uImage-eb600em 1.5 million bytes took over 12 hours. I'll need to find another option to deal with 57 million bytes in fs.img. Putty also had an issue with pasting a large amount of data, and it didn't have a transmit delay option.

Next I followed your instructions for creating a bootable SD card with fs.img from the 1.8 update and rebooted using the bootsd command. Unfortunately, it ends up with the same error:

EDIT. I did something wrong creating the bootable SD...repeating this step

[nicke]

tonyyng,

I ran through the exact procedure I posted above and it worked for me. Odd...

I sent you a PM with a link to a tar.gz of the rootfs of my N416. You should delete all the files on your SD card but leave the partition intact. Then expand the tar.gz onto the SD card and try again to bootsd from u-boot.

Just to test the procedure, I took a fresh SD card and created an ext3 partition on it, then expanded the N416rootfs.tar.gz onto it. Then, I put it into the Kobo, turned it on, stopped the boot in u-boot, and used bootsd. It booted to the "Please press Enter to activate this console". I hit Enter, and got the command prompt. You can do a "pkill nickel" to stop nickel from doing its stuff.

From here, do step 4 above to verify /mnt/onboard.

Additionally, see if you can mount the rootfs mtdblock4 with:
#mount /dev/mtdblock /mnt/sd

If the mount succeeds (it should autodetect yaffs2 filesystem). You can just copy over the rootfs from the SD card:
#cd /
#cp -P -r bin /mnt/sd
#cp -P -r boot /mnt/sd
#cp -P -r dev /mnt/sd
#cp -P -r etc /mnt/sd
#cp -P -r lib /mnt/sd
#cp -P -r lost+found /mnt/sd
#cp -P -r root /mnt/sd
#cp -P -r sbin /mnt/sd
#cp -P -r usr /mnt/sd
#cp -P -r linuxrc /mnt/sd
#cp -P -r gmon.out /mnt/sd
#mkdir /mnt/sd/mnt
#mkdir /mnt/sd/mnt/onboard
#mkdir /mnt/sd/mnt/sd
#mkdir /mnt/sd/proc
#mkdir /mnt/sd/sys
#mkdir /mnt/sd/tmp
#mkdir /mnt/sd/var

Then, you can try to boot normally.

If you cannot mount /dev/mtdblock4 or if mount does not detect it as yaffs, then you will probably have to flash fs.img to mtdblock4.

Good luck!
NickE

[tonyyng]

I didn't create the SD card correctly, so the first time I ran it, the results weren't meaningful.

After I rebuilt the sd card, I still had issues. I booted from the card twice and the output the first run had many more error messages. It was likely due to running the upgrade process, as you pointed out.

I've attached the output from both runs.

I'll download your rootfs files and give them a try next.

[tonyyng]

Good news and bad news.

I was able to boot from your rootfs...once. After booting, I glanced at the device's screen, and it was at one of the configuration screens (date time?). I have not been past the original boot screen in some time.

I was able to run some of the commands you suggested. See the attached log.

However, when I rebooted, it wouldn't start again. I get these messages when I try to bootsd. I tried rebuilding the SD card from rootfs.tar.gz, with no luck.

Hit any key to stop autoboot:  0
eBR-1A #
eBR-1A # bootsd
Boot from SD
From 0x00080000 to 0x00280000
Target read size = 0x00200000
Booting image at 31000000
Bad Magic Number
eBR-1A # bootsd
Boot from SD
From 0x00080000 to 0x00280000
Target read size = 0x00200000
Booting image at 31000000
Bad Magic Number

I guess I'll need to use RandomInsano technique for rebuilding the kernel? Starting it now...

[tonyyng]

While waiting for the restore of the kernel through mm, I'm looking at the last successful bootsd using your rootfs image:

From the image's /etc/init.d/rc5, I see this:

# expose gadget storage
insmod /lib/modules/module.ko pre_format=0
/bin/mount -t vfat -o iocharset=utf8 /dev/mtdblock6 /mnt/onboard

In the output I see this:

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

This seems relevant to your points about /dev/mtdblock. Can you elaborate and suggest options for correcting this?

Thanks