Firmware upgrade scripts

davidfor · 04-18-2014, 12:32 AM

Could someone with more shell script knowledge than me have a look at the firmware install code? What I am interested in us exactly what files are installed from the upgrade directory for each of the devices.

The code to look at is in etc/init.d. And the scripts involved are rc5, upgrade-wifi.sh and upgrade-generic.sh.

I think I know what happens, but would prefer that someone else checks before I say anything more.

Lucas Malor · 04-19-2014, 07:57 AM

As far as I've understood:

if there's a Kobo.tgz in the /mnt/onboard/.kobo/ directory, all the new files are copied to /usr/local/Kobo/
If there's a KoboRoot.tgz, all the new files are copied to the root
If there's an upgrade directory, the entire internal SD partitions will be overwritten by new partition images

davidfor · 04-20-2014, 07:57 AM

Quote:

Originally Posted by Lucas Malor

As far as I've understood:

if there's a Kobo.tgz in the /mnt/onboard/.kobo/ directory, all the new files are copied to /usr/local/Kobo/
If there's a KoboRoot.tgz, all the new files are copied to the root

Yes, but it might be better to say "unpacked to ..." as both of these are compressed files.

Quote:

If there's an upgrade directory, the entire internal SD partitions will be overwritten by new partition images

It is more complicated than that. The scripts query the hardware to decide which of the uBoot and uImage files to use. Then they install these files.

The problem I see is that the file names are built up using the amount of RAM, the PCB identifier and the RAM type. Looking at the 3.2.0 Mark4 firmware package, there is a uBoot file for the four different devices. But, there are only two uImage files. One is for the Aura HD. The other is just called "uImage" and Kobo have said it is for the three other devices. The uImage is the kernel.

The scripts build the file names, checks if they exist and if they do, they are installed. But, there is no failback to the non-device specific version. So, with the current code, the kernel is not being installed on the Glo, Mini and N905C Touch.

The reason I noticed this was the multi-touch kernel. I installed that and it worked OK. But, I wanted to remove it and retest the supplied kernel. All I did was to put the 3.2.0 firmware package back on. I was surprised when the multi-touch still worked. So, I looked at what was happening. That was when I read the install code and became suspicious. I put the firmware package back on, copied "uImage" to "uImage-E606B0" and the install happened. I also used telnet to connect and run the scripts manually with extra echo statements to see what happened. This also suggested I was right.

That was the part I was hoping someone would confirm or disprove.

The other part of this is that I had a look at the install scripts that are put onto the device when you do a factory reset. Firstly, the factory reset installs the kernel that is in the recovery partition. Then, the first firmware upgrade uses the install scripts that the factory reset installs. These do basically the same thing, but will use the uImage file if a more specific version isn't found.

What all this means is that after a factory reset and upgrade, the device will always have the kernel that came with that firmware installed. But, a later firmware upgrade will not install the latest kernel for the Glo, Mini and N905C Touch. This probably isn't that important as looking through the last few firmware versions, the uImage file has stayed the same size. There is a pretty good chance that means it hasn't changed. So, if you have done a factory reset recently, you will be OK. But, if you haven't ever done one, you might have the wrong kernel. This would also explain why some people have had trouble with some firmware but after a factory reset and upgrade, it was all OK.

That's what I think is happening. My tests seem to confirm it. But, I'm not confident with shell scripts, so I might have missed something. So, I was hoping someone would confirm or disprove it.

Lucas Malor · 04-20-2014, 05:47 PM

Yes, it's as you think. uImage is used only if PLATFORM=freescale.

Quote:

Originally Posted by davidfor

Firstly, the factory reset installs the kernel that is in the recovery partition. Then, the first firmware upgrade uses the install scripts that the factory reset installs. These do basically the same thing, but will use the uImage file if a more specific version isn't found.

It seems that the factory reset simply overwrite the u-boot. This way you'll see only the "connect to PC to start" message. The firmware will be downloaded by the Desktop app: it's not reinstalled by the factory reset. So in theory it still will not update the kernel.

But the question is: PLATFORM="freescale" at this point? It will be freescale if

PHP Code:


			
dd if=/dev/mmcblk0 bs=512 skip=1024 count=1 | grep -c "HW CONFIG"

returns 0, whatever it means. You should try to reinstall the multitouch and see if a factory reset remove it.

Other questions are: what means that cpu is "freescale"? For what I know all Kobo eink product use a freescale cpu. What's the difference between the two kernel images? It seems that the "freescale" image is a generic image. What is the purpose of the specific image, and why the firmware package doesn't include all the specific kernels? Previous firmware packages have also kernel images for other hw, like uImage-E606B0?

PS: I wouldn't seem arrogant, but IMHO Kobo devs should follow more the DRY principle.

davidfor · 04-20-2014, 11:31 PM

Quote:

Originally Posted by Lucas Malor

Yes, it's as you think. uImage is used only if PLATFORM=freescale.

It seems that the factory reset simply overwrite the u-boot. This way you'll see only the "connect to PC to start" message. The firmware will be downloaded by the Desktop app: it's not reinstalled by the factory reset. So in theory it still will not update the kernel.

No, that's not right. The factory reset boots from the recoveryfs partition. It contains a compressed copy of the initial firmware, uBoot and uImage files. During the boot, it runs its versions of the upgrade script. This reformats the other two partitions, installs the uBoot and uImage files, unpacks the firmware to the rootfs partition and creates the database on the user partition. Then it does a restart.

After the restart, the firmware knows it has to be setup, so it the prompts you to do it. Exactly what happens depends on the device and the factory reset firmware. My Glo resets to 2.1.5 and can do the setup without a computer. My Touch goes back to 1.9.11 and needs the computer. Both can be connected to the computer and the database changed so they don't need to do the setup.

Quote:

But the question is: PLATFORM="freescale" at this point? It will be freescale if

PHP Code:


			
dd if=/dev/mmcblk0 bs=512 skip=1024 count=1 | grep -c "HW CONFIG"

returns 0, whatever it means. You should try to reinstall the multitouch and see if a factory reset remove it.

At them moment, I don't want to do that. But, I have used telnet to run the statement and it returned 1. Hence, $PLATFORM is "mx50-ntx" and $CPU is "mx50".

Quote:

Other questions are: what means that cpu is "freescale"? For what I know all Kobo eink product use a freescale cpu. What's the difference between the two kernel images? It seems that the "freescale" image is a generic image. What is the purpose of the specific image, and why the firmware package doesn't include all the specific kernels? Previous firmware packages have also kernel images for other hw, like uImage-E606B0?

The kernel images depend on the hardware. I have a statement from Kobo that the Glo, Mini and N905C Touch have different PCB revisions but share the same kernel. The Aura HD has a different kernel which is "uImage-E606C0". The firmware package for the Aura has another kernel image. I haven't seen anything other than these and the common uImage in any firmware package.

The problem is that for the Glo, the $PLATFORM will not be "freescale". After executing:

Code:

PLATFORM=freescale
if [ `dd if=/dev/mmcblk0 bs=512 skip=1024 count=1 | grep -c "HW CONFIG"` == 1 ]; then
	CPU=`ntx_hwconfig -s -p /dev/mmcblk0 CPU`
	PLATFORM=$CPU-ntx
fi

$PLATFORM is "mx50-ntx" and $CPU is "mx50". That means the next IF statement is true and the block executed. At the end of that $UBOOT will be "/mnt/onboard/.kobo/upgrade/mx50-ntx/u-boot_mddr_512-E606C0-K4X2G323PC.bin". And $KERNEL will not be set.

The latter is because:

Code:

NEW_KERNEL=/mnt/onboard/.kobo/upgrade/$PLATFORM/uImage-$PCB

evaluates to set $NEW_KERNEL to "/mnt/onboard/.kobo/upgrade/mx50-ntx/uImage-E606C0". That file doesn't exist so:

Code:

[ -e $NEW_KERNEL ] && KERNEL=$NEW_KERNEL

means that $KERNEL isn't set.

So when "upgrade-generic.sh" is called, no name for the kernel image is passed and hence it isn't installed.

Quote:

PS: I wouldn't seem arrogant, but IMHO Kobo devs should follow more the DRY principle.

Personally, I just want them to fix the code so it does what it should.

Lucas Malor · 04-21-2014, 07:51 AM

Quote:

Originally Posted by davidfor

No, that's not right. The factory reset boots from the recoveryfs partition.

I suppose we're saying the same thing: u-boot is replaced with a "recovery" u-boot. the recovery u-boot boots the system from a recovery partition. This is what I can see in rcS. Or are you talking about the code executed by the contemporary press of light and power buttons? If so, where is it?

Quote:

Originally Posted by davidfor

During the boot, it runs its versions of the upgrade script.

Where's the code?

Quote:

Originally Posted by davidfor

The problem is that for the Glo, the $PLATFORM will not be "freescale". [...] $PLATFORM is "mx50-ntx" and $CPU is "mx50".

My guess is PLATFORM=freescale when the system boots from the recovery partition.

Quote:

Originally Posted by davidfor

Personally, I just want them to fix the code so it does what it should.

The optimal will be Kobo will fix it, since we don't know exactly what's the purpose of the "generic" and "specific" kernels.

PS: happy Easter!

davidfor · 04-21-2014, 08:26 AM

Quote:

Originally Posted by Lucas Malor

I suppose we're saying the same thing: u-boot is replaced with a "recovery" u-boot. the recovery u-boot boots the system from a recovery partition. This is what I can see in rcS. Or are you talking about the code executed by the contemporary press of light and power buttons? If so, where is it?

Maybe it does, but I think it just forces the next boot to be from the recoveryfs. The code is on the recoveryfs partition. Same names. The recovery firmware and images is in "/recoveryfs/upgrade" If you telnet in, you can access it. Or take the SD card out an mount it in a PC.

Quote:

Where's the code?

Again, on the recoveryfs partition.

Quote:

My guess is PLATFORM=freescale when the system boots from the recovery partition.

As far as I can tell it is for backward compatibility with the older hardware.

Quote:

The optimal will be Kobo will fix it, since we don't know exactly what's the purpose of the "generic" and "specific" kernels.

Different hardware need different kernels. The N905C Touch, Glo and Mini are close enough they use the same kernel. The other devices have there own. As I said, that came directly from Kobo.

Quote:

PS: happy Easter!

And to you.

Lucas Malor · 04-21-2014, 06:45 PM

Ok, I mounted the recovery partition. For what I see, among other things, "recovery" rcS overwrites the "normal" partition, using an image stored on the recovery partition.

About firmware upgrading: overwriting the "normal" partition with an image file, or extracting KoboRoot.tgz to the root is exactly the same thing in theory. So why firmware packages contains KoboRoot.tgz AND image files?

I suspect image files is the upgrade method of Mini, Touch and Aura HD. On the contrary, file coping is the Glo and Aura method. What a mess. EDIT: just wrong

Can you link me the multi-touch kernel installer?

davidfor · 04-21-2014, 09:08 PM

Quote:

Originally Posted by Lucas Malor

Ok, I mounted the recovery partition. For what I see, among other things, "recovery" rcS overwrites the "normal" partition, using an image stored on the recovery partition.

Correct.

Quote:

About firmware upgrading: overwriting the "normal" partition with an image file, or extracting KoboRoot.tgz to the root is exactly the same thing in theory. So why firmware packages contains KoboRoot.tgz AND image files?

The uImage is 1.8MB and the KoboRoot.tgz is over 87MB. Hopefully there is something useful in that 87MB. Unless they have a really, REALLY good compression algorithm.

The uImage file is just the kernel. Everything else, including all the code for the Kobo applications are in the rootfs.

Quote:

I suspect image files is the upgrade method of Mini, Touch and Aura HD. On the contrary, file coping is the Glo and Aura method. What a mess.

NO. They all use EXACTLY the same code to do this. The contents of KoboRoot.tgz is identical across all the devices except for the fonts and pictures. The uImage and uBoot files are different for the different devices.

Quote:

Can you link me the multi-touch kernel installer?

I can't point to an "installer" as it uses the same method for installation as the firmware packages. But https://www.mobileread.com/forums/sho...d.php?t=232431 is where the kernel is available. When you open that file or the uninstall file, you will see an extra uImage which has the PCB for the Glo.

Lucas Malor · 04-22-2014, 09:31 AM

Yes, that is the kernel. I got really confused, because actually there's not a partition for the linux kernel. AFAIK linux kernel should go to a separate partition, and the image needs not to be extracted. But I don't know very much about u-boot and all this stuff.

About multitouch, have you run the multitouch uninstaller before reinstall 3.2.0 firmware?

davidfor · 04-22-2014, 09:51 AM

Quote:

Originally Posted by Lucas Malor

About multitouch, have you run the multitouch uninstaller before reinstall 3.2.0 firmware?

No I didn't. By the time I noticed it, I had done most of the investigation and got the 3.2.0 kernel reinstalled by copying uImage to an appropriately named file for the Glo. But, it just supplies the uBoot and uImage files in the appropriate directories so they get installed using the firmware upgrade code on the devices. And if you look at the multi-touch uninstall package, it agrees with what I have been saying about the needed files and proves my point that the firmware upgrade won't install the kernel supplied in the package for the Glo. If it did, the "uImage-E606B0" wouldn't be needed.

Lucas Malor · 04-22-2014, 11:48 AM

Yes, the kernel image is not updated by 3.2.0 firmware package, this is certain.

If you're right, so

1. kernel is the same for Mini, Glo and "low cost" Touch
2. their kernel is the uImage file

if so, there's a bug in the update script.

But we can't be 100% sure. uImage could be the kernel for Mini and Touch. Glo kernel could be remained unchanged, so it didn't need an upgrade. That's why I asked you if in previous firmware packages there was an uImage-E606B0 image file.

I can't see what recovery uImage contains:

PHP Code:


			
# mkdir /mnt/recovery-fs
# mkdir /mnt/recovery-kernel/
# mount /dev/mmcblk0p2 /mnt/recovery-fs
# mount -t ext4 -o loop /mnt/recovery-fs/upgrade/ntx508/uImage /mnt/kernel-recovery/
mount: mounting /dev/loop0 on /mnt/kernel-recovery/ failed: Invalid argument

Lucas Malor · 04-22-2014, 12:50 PM

By the way, this is why there's not a boot partition:

http://unix.stackexchange.com/questi...and-do-exactly

I could extract the uImage on a formatted USB. I think that its content could be very interesting...

EDIT: no it isn't, see below

Lucas Malor · 04-22-2014, 06:30 PM

old post:

Spoiler:

EDIT: gross mistake: it can't work if there's no partition table on the uImage... and uImage contains only the kernel, so the most interesting thing is the source code on the Kobo Git

davidfor · 04-22-2014, 09:46 PM

Quote:

Originally Posted by Lucas Malor

Yes, the kernel image is not updated by 3.2.0 firmware package, this is certain.

If you're right, so

1. kernel is the same for Mini, Glo and "low cost" Touch
2. their kernel is the uImage file

if so, there's a bug in the update script.

Yes.

Quote:

But we can't be 100% sure. uImage could be the kernel for Mini and Touch. Glo kernel could be remained unchanged, so it didn't need an upgrade. That's why I asked you if in previous firmware packages there was an uImage-E606B0 image file.

I have never seen a Glo specific kernel file. And I have a statement from Kobo that the Mini, Touch N905c and Glo share the same kernel.

Quote:

I can't see what recovery uImage contains:

PHP Code:


			
# mkdir /mnt/recovery-fs

# mkdir /mnt/recovery-kernel/

# mount /dev/mmcblk0p2 /mnt/recovery-fs

# mount -t ext4 -o loop /mnt/recovery-fs/upgrade/ntx508/uImage /mnt/kernel-recovery/

mount: mounting /dev/loop0 on /mnt/kernel-recovery/ failed: Invalid argument

It should be an older version of the kernel that matches the rest of the firmware package used for the factory reset.

04-18-2014, 12:32 AM	#1
davidfor Grand Sorcerer Posts: 24,907 Karma: 47303748 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	Firmware upgrade scripts Could someone with more shell script knowledge than me have a look at the firmware install code? What I am interested in us exactly what files are installed from the upgrade directory for each of the devices. The code to look at is in etc/init.d. And the scripts involved are rc5, upgrade-wifi.sh and upgrade-generic.sh. I think I know what happens, but would prefer that someone else checks before I say anything more.

04-19-2014, 07:57 AM	#2
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	As far as I've understood: if there's a Kobo.tgz in the /mnt/onboard/.kobo/ directory, all the new files are copied to /usr/local/Kobo/ If there's a KoboRoot.tgz, all the new files are copied to the root If there's an upgrade directory, the entire internal SD partitions will be overwritten by new partition images

04-21-2014, 06:45 PM	#8
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	Ok, I mounted the recovery partition. For what I see, among other things, "recovery" rcS overwrites the "normal" partition, using an image stored on the recovery partition. About firmware upgrading: overwriting the "normal" partition with an image file, or extracting KoboRoot.tgz to the root is exactly the same thing in theory. So why firmware packages contains KoboRoot.tgz AND image files? I suspect image files is the upgrade method of Mini, Touch and Aura HD. On the contrary, file coping is the Glo and Aura method. What a mess. EDIT: just wrong Can you link me the multi-touch kernel installer? Last edited by Lucas Malor; 04-22-2014 at 10:15 AM.

04-22-2014, 09:31 AM	#10
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	Yes, that is the kernel. I got really confused, because actually there's not a partition for the linux kernel. AFAIK linux kernel should go to a separate partition, and the image needs not to be extracted. But I don't know very much about u-boot and all this stuff. About multitouch, have you run the multitouch uninstaller before reinstall 3.2.0 firmware? Last edited by Lucas Malor; 04-22-2014 at 09:33 AM.

04-22-2014, 11:48 AM	#12
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	Yes, the kernel image is not updated by 3.2.0 firmware package, this is certain. If you're right, so 1. kernel is the same for Mini, Glo and "low cost" Touch 2. their kernel is the uImage file if so, there's a bug in the update script. But we can't be 100% sure. uImage could be the kernel for Mini and Touch. Glo kernel could be remained unchanged, so it didn't need an upgrade. That's why I asked you if in previous firmware packages there was an uImage-E606B0 image file. I can't see what recovery uImage contains: PHP Code: `# mkdir /mnt/recovery-fs # mkdir /mnt/recovery-kernel/ # mount /dev/mmcblk0p2 /mnt/recovery-fs # mount -t ext4 -o loop /mnt/recovery-fs/upgrade/ntx508/uImage /mnt/kernel-recovery/ mount: mounting /dev/loop0 on /mnt/kernel-recovery/ failed: Invalid argument` Last edited by Lucas Malor; 04-22-2014 at 12:53 PM.

04-22-2014, 12:50 PM	#13
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	By the way, this is why there's not a boot partition: http://unix.stackexchange.com/questi...and-do-exactly I could extract the uImage on a formatted USB. I think that its content could be very interesting... EDIT: no it isn't, see below Last edited by Lucas Malor; 04-25-2014 at 06:27 AM.

04-22-2014, 06:30 PM	#14
Lucas Malor Pain in the arse Posts: 758 Karma: 77856 Join Date: Apr 2013 Device: Kobo Aura One, Kindle 4	old post: Spoiler: sigh nothing. I created a 11 Mb ext4 partition on a USB stick and I tried to do PHP Code: `dd if=uImage of=/dev/sdb bs=512 seek=14335` Probably seek=1 is enough. Anyway, nothing. No files is present on the partition. Further investigations may be required. EDIT: gross mistake: it can't work if there's no partition table on the uImage... and uImage contains only the kernel, so the most interesting thing is the source code on the Kobo Git Last edited by Lucas Malor; 04-25-2014 at 06:27 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Why can’t I complete the Kobo Touch firmware upgrade or Desktop upgrade?	DarrellAtKobo	Kobo Reader	31	08-31-2012 10:45 PM
Opus I can't upgrade firmware	charex	Bookeen	17	09-21-2011 09:14 AM
PRS-500 Can I still firmware upgrade this?	Rangoon	Sony Reader	9	08-11-2011 03:11 PM
iLiad How can I upgrade my firmware to 2.12?	npceodp	iRex	1	08-30-2010 04:03 PM
Firmware Upgrade Available!	scottcstoness	Sony Reader	65	08-06-2007 11:13 PM

Advert

Advert