Gen3 Bootloader reload options

readerdm · 07-20-2010, 02:45 PM

Well, I went ahead and hooked up the serial port to my Gen3, and it works; the baud rate is 115kB. I see a boot up message that matches the one on OpenInkpot etc. but it gets hallfway along and then....

....
DZ Test vivi code
Press Return to start the LINUX now, any other key for vivi
Copy linux kernel from 0x00030000 to 0x30008000, size = 0x00100000 ... done
zImage magic = 0x016f2818
Setup linux parameters at 0x30000100
linux command line is: "noinitrd root=/dev/mtdblock/2 init=/linuxrc console=ttyS0"
MACH_TYPE = 193
NOW, Booting Linux......
Uncompressing Linux............................................
crc error
-- System halted

So, it looks like the compressed Linux image may be currupted. I can get to the "vivi" command line:

DZ Test vivi code
Press Return to start the LINUX now, any other key for vivi
type "help" for help.
vivi> help
Usage:
cpu [{cmds}] -- Manage cpu clocks
reset -- Reset the system
param [set|show|save|reset] -- set/get parameter
part [add|del|show|reset] -- Manage MTD partitions
mem [{cmds}] -- Manage Memory
load {...} -- Load a file to RAM/Flash
go <addr> <a0> <a1> <a2> <a3> -- jump to <addr>
dump <addr> <length> -- Display (hex dump) a range of memory.
call <addr> <a0> <a1> <a2> <a3> -- jump_with_return to <addr>
boot [{cmds}] -- Booting linux kernel
help [{cmds}] -- Help about help?
vivi>

So, lots of possible options. Does anybody know how I could reload the thing at this point? I have the update kernal files etc from Bookeen, but I'm not sure how to proceed at this point. Perhaps I should switch this over to the Gen3 Developers Forum too

Godzil · 07-20-2010, 04:05 PM

You can't do anything, you need some special tool, and the necessary software to take back your Gen3 to live

readerdm · 07-21-2010, 04:35 PM

I understand your concerns. However, since I haven't gotten a response from Bookeen regarding repair, I don't see any other options. I am simply trying to repair a unit I purchased new, using the legitimately obtained firmware update. I have bought lots of mobi books with DRM, so changing to a new reader with ePub will be a pain, if even possible.

Using the vivi commands, I can see that several things appear to be correct.

vivi> part show
mtdpart info. (6 partitions)
name offset size flag
------------------------------------------------
vivi : 0x00000000 0x00020000 0 128k
param : 0x00020000 0x00010000 0 64k
kernel : 0x00030000 0x00100000 0 1M
root : 0x00130000 0x00170000 4 1M+448k
ebr : 0x002a0000 0x00540000 4 5M+256k
BMP : 0x007e0000 0x00020000 0 128k

For example, a dump of the kernel at memory 0x03000 appears to match the kernel.bin portion of the update code exactly.

Also, a dump of BMP at 0x007e000 matches the bootim.bin portion of the update code. Could this be a bitmap (BMP) of the boot-up image (bootim) that shows on start-up?

They key bits appear to be the root and ebr partitions. These start out matching the boordr.bin (boo reader?) code, but then diverge, perhaps because they are compressed?

At any rate, I will keep playing with it, because otherwise it is indeed useless, and it is a fun excercise in troubleshooting. Anybody else interested?

readerdm · 07-22-2010, 09:19 PM

I'm getting closer... I can get the linux to uncompress from RAM, but I can't get it reloaded into flash. The problem appears to be that my unit crashed with firmware 1.5, and I only have the extracted firmware from Update_Kernel for 1.2.789fmt. I can almost load it, but the partition table appears to be different, and I can't quite tell what it should be. Does anybody have the extracted firmware for the 1.5 update? I found a firmware extract utility (python script), but it doesn't output anything for 1.5 like it did for 1.2.789.

readerdm · 07-28-2010, 02:46 PM

Well, I did it!
I have a Gen3 that crashed during a firmware update and then locked-up at the first screen, LED on forever...

So, I connected the serial port and started hacking. I found the Samusung ARM vivi bootloater utility which has some diagnostic functions. I extracted the firmware from the update_kernel files supplied by Bookeen. Between the two of these I was able to determine that my linux kernel section was corrupted; I could even find the affected memory locations.

So, how to get it reloaded? First, I installed an SD card with the 1.2.789fmt update_kernel ready to go, should something good happen. Then I logged some of the vivi serial port traffic until I figured out what was going on. I managed to load the kernal into RAM, then boot from RAM and it came up! I quickly pushed the enter button and it started the firmware update process and... it worked.

So, without further documentation etc. I'm not certain if this is a universal fix, but if you have a thoroughly bricked Gen3 Cybook then it's worth a try. It does take some skills (I am an electronics engineer) and tools (3.3 Volt to RS-232 converter.

It appears from the forums that this is the first time this has been done, so there may be some hope after all. LEt me know if you want more details.

Domas · 08-12-2010, 06:28 AM

Quote:

Originally Posted by readerdm

I extracted the firmware from the update_kernel files supplied by Bookeen

How did you extract firmware from update_kernel file?

readerdm · 08-13-2010, 07:03 PM

I found a python script in this forum under the "reverse engineering the gen3..." thread. It only worked on the 1.2.789fmt version of the update_kernel, but it did generate three files as noted in this thread above. I was able to compare these files against the later update_kernel and I found that the boot image and kernal are identical, at least up to 1.5 (mobi) verison. I also hacked the python script to extract the later update_kernal files, but I got incomplete results...

My problem was a corrupted compressed linux kernel that prevented full boting of the unit. I was able to actually download the internal flash memory and compare it to the kernal files and fine the corrupted memory locations. Gettiing it reloaded was a bit more of a pain.

The Samsung ARM Vivi bootloader tool is not very easy. Some hints: THe <x,y,z> choice in the file download menu is for xmodem, ymodem or zmodem, and only xmodem works...

The load memory command has a table for where to load to that looks something like:
1 = Flash
2 = NAND
3 = RAM
so you would assume that the argument would be 1, 2, or 3, but it is actually the word FLASH, RAM etc. This is the same for the BOOT command.

So, I reloaded the kernal to RAM, then booted from RAM. I'm not really sure what else there is...

ijovy · 03-14-2011, 08:20 AM

Quote:

Originally Posted by readerdm

My problem was a corrupted compressed linux kernel that prevented full boting of the unit. I was able to actually download the internal flash memory and compare it to the kernal files and fine the corrupted memory locations. Gettiing it reloaded was a bit more of a pain.

.

Hello,

I' ve got a similar problem. So i have compiled the linux kernel from source GPL bookeen 1.0
To do this , il use the cross compiler 2.95.3 which is in the Code source GPL 2.0. I load zImage in ram and boot ram. The unit boot without problem.

07-20-2010, 02:45 PM	#1
readerdm Member Posts: 13 Karma: 10 Join Date: Jul 2010 Device: Cybook Gen3	Gen3 Bootloader reload options Well, I went ahead and hooked up the serial port to my Gen3, and it works; the baud rate is 115kB. I see a boot up message that matches the one on OpenInkpot etc. but it gets hallfway along and then.... .... DZ Test vivi code Press Return to start the LINUX now, any other key for vivi Copy linux kernel from 0x00030000 to 0x30008000, size = 0x00100000 ... done zImage magic = 0x016f2818 Setup linux parameters at 0x30000100 linux command line is: "noinitrd root=/dev/mtdblock/2 init=/linuxrc console=ttyS0" MACH_TYPE = 193 NOW, Booting Linux...... Uncompressing Linux............................................ crc error -- System halted So, it looks like the compressed Linux image may be currupted. I can get to the "vivi" command line: DZ Test vivi code Press Return to start the LINUX now, any other key for vivi type "help" for help. vivi> help Usage: cpu [{cmds}] -- Manage cpu clocks reset -- Reset the system param [set\|show\|save\|reset] -- set/get parameter part [add\|del\|show\|reset] -- Manage MTD partitions mem [{cmds}] -- Manage Memory load {...} -- Load a file to RAM/Flash go <addr> <a0> <a1> <a2> <a3> -- jump to <addr> dump <addr> <length> -- Display (hex dump) a range of memory. call <addr> <a0> <a1> <a2> <a3> -- jump_with_return to <addr> boot [{cmds}] -- Booting linux kernel help [{cmds}] -- Help about help? vivi> So, lots of possible options. Does anybody know how I could reload the thing at this point? I have the update kernal files etc from Bookeen, but I'm not sure how to proceed at this point. Perhaps I should switch this over to the Gen3 Developers Forum too

07-28-2010, 02:46 PM	#5
readerdm Member Posts: 13 Karma: 10 Join Date: Jul 2010 Device: Cybook Gen3	Bricked Gen3 reloaded from scratch(?) Well, I did it! I have a Gen3 that crashed during a firmware update and then locked-up at the first screen, LED on forever... So, I connected the serial port and started hacking. I found the Samusung ARM vivi bootloater utility which has some diagnostic functions. I extracted the firmware from the update_kernel files supplied by Bookeen. Between the two of these I was able to determine that my linux kernel section was corrupted; I could even find the affected memory locations. So, how to get it reloaded? First, I installed an SD card with the 1.2.789fmt update_kernel ready to go, should something good happen. Then I logged some of the vivi serial port traffic until I figured out what was going on. I managed to load the kernal into RAM, then boot from RAM and it came up! I quickly pushed the enter button and it started the firmware update process and... it worked. So, without further documentation etc. I'm not certain if this is a universal fix, but if you have a thoroughly bricked Gen3 Cybook then it's worth a try. It does take some skills (I am an electronics engineer) and tools (3.3 Volt to RS-232 converter. It appears from the forums that this is the first time this has been done, so there may be some hope after all. LEt me know if you want more details.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Gen3 Can't Get to Bootloader	readerdm	Bookeen	7	07-28-2010 02:48 PM
iLiad Iliad bootloader: how to break automatic boot process?	alegeott	iRex Developer's Corner	2	12-03-2009 01:16 PM
reset options	oncdoc	Calibre	2	09-05-2009 08:14 AM
SD Memory options?	Abisha	Sony Reader	14	10-01-2008 09:54 AM
Reload The Matrix	Saud	Lounge	6	06-02-2003 05:01 PM

07-20-2010, 04:05 PM	#2
Godzil a pthread?? where? where? Posts: 1,763 Karma: 30462 Join Date: Mar 2009 Location: Somewhere in EU Device: Newton MessagePad 2100, and only this	You can't do anything, you need some special tool, and the necessary software to take back your Gen3 to live

07-21-2010, 04:35 PM	#3
readerdm Member Posts: 13 Karma: 10 Join Date: Jul 2010 Device: Cybook Gen3	I understand your concerns. However, since I haven't gotten a response from Bookeen regarding repair, I don't see any other options. I am simply trying to repair a unit I purchased new, using the legitimately obtained firmware update. I have bought lots of mobi books with DRM, so changing to a new reader with ePub will be a pain, if even possible. Using the vivi commands, I can see that several things appear to be correct. vivi> part show mtdpart info. (6 partitions) name offset size flag ------------------------------------------------ vivi : 0x00000000 0x00020000 0 128k param : 0x00020000 0x00010000 0 64k kernel : 0x00030000 0x00100000 0 1M root : 0x00130000 0x00170000 4 1M+448k ebr : 0x002a0000 0x00540000 4 5M+256k BMP : 0x007e0000 0x00020000 0 128k For example, a dump of the kernel at memory 0x03000 appears to match the kernel.bin portion of the update code exactly. Also, a dump of BMP at 0x007e000 matches the bootim.bin portion of the update code. Could this be a bitmap (BMP) of the boot-up image (bootim) that shows on start-up? They key bits appear to be the root and ebr partitions. These start out matching the boordr.bin (boo reader?) code, but then diverge, perhaps because they are compressed? At any rate, I will keep playing with it, because otherwise it is indeed useless, and it is a fun excercise in troubleshooting. Anybody else interested?

07-22-2010, 09:19 PM	#4
readerdm Member Posts: 13 Karma: 10 Join Date: Jul 2010 Device: Cybook Gen3	I'm getting closer... I can get the linux to uncompress from RAM, but I can't get it reloaded into flash. The problem appears to be that my unit crashed with firmware 1.5, and I only have the extracted firmware from Update_Kernel for 1.2.789fmt. I can almost load it, but the partition table appears to be different, and I can't quite tell what it should be. Does anybody have the extracted firmware for the 1.5 update? I found a firmware extract utility (python script), but it doesn't output anything for 1.5 like it did for 1.2.789.

08-13-2010, 07:03 PM	#7
readerdm Member Posts: 13 Karma: 10 Join Date: Jul 2010 Device: Cybook Gen3	I found a python script in this forum under the "reverse engineering the gen3..." thread. It only worked on the 1.2.789fmt version of the update_kernel, but it did generate three files as noted in this thread above. I was able to compare these files against the later update_kernel and I found that the boot image and kernal are identical, at least up to 1.5 (mobi) verison. I also hacked the python script to extract the later update_kernal files, but I got incomplete results... My problem was a corrupted compressed linux kernel that prevented full boting of the unit. I was able to actually download the internal flash memory and compare it to the kernal files and fine the corrupted memory locations. Gettiing it reloaded was a bit more of a pain. The Samsung ARM Vivi bootloader tool is not very easy. Some hints: THe <x,y,z> choice in the file download menu is for xmodem, ymodem or zmodem, and only xmodem works... The load memory command has a table for where to load to that looks something like: 1 = Flash 2 = NAND 3 = RAM so you would assume that the argument would be 1, 2, or 3, but it is actually the word FLASH, RAM etc. This is the same for the BOOT command. So, I reloaded the kernal to RAM, then booted from RAM. I'm not really sure what else there is...

Advert

Advert