Firmware upgrade scripts

[uboot]

@Lucas: JFYK - Embedded Linux is different from Desktop Linux by the fact that the kernel and initial ramdisk does not reside within a file system (aka boot partition), but within a raw partition, that is a portion of un-partitioned space which cannot be mounted as usual, but only dumped with dd. Additionally, there is a boot loader - uboot - which knows at which raw offset the kernel can be found.

Many Android devices work like this as well, e.g. the Sony PRS T1 reader.

[Lucas Malor]

@uboot: Interesting. Anyway, can't you use a boot partition at all? I know nothing about it and I'm reading an online tutorial. This tutorial creates kernel partitions.
I suppose the unpartitioned space is used when you want to mildly hide it. This make sense if you want more security, or you want to secret the kernel binaries from competitors. What do you think about?

I've found an uImage extract script, I'll try to use it on Kobo uImage.

@davidfor: I confirm that the "recovery" upgrade-wifi.sh does install the uImage kernel:

PHP Code:

KERNEL=/mnt/onboard/.kobo/upgrade/$PLATFORM/uImage 


Furthermore it doesn't distinguish between Aura HD and the other devices. Maybe on the Auras there are different scripts? I'm too much confused.

I think that renaming uImage and sideloading the firmware should be the suggested way to update the device, instead of using Kobo Desktop. My tutorial about installing Virtualbox for using Kobo Desktop on Linux will be completely useless

[davidfor]

Originally Posted by Lucas Malor

@davidfor: I confirm that the "recovery" upgrade-wifi.sh does install the uImage kernel:

PHP Code:

KERNEL=/mnt/onboard/.kobo/upgrade/$PLATFORM/uImage 


Yes, that's what I am seeing.

Furthermore it doesn't distinguish between Aura HD and the other devices. Maybe on the Auras there are different scripts? I'm too much confused.

No, it is probably a version issue. The Glo factory resets to 2.1.5. The Aura HD is 2.4, I think. The script in the 2.4.0 package looks like it handles this correctly.

I think that renaming uImage and sideloading the firmware should be the suggested way to update the device, instead of using Kobo Desktop. My tutorial about installing Virtualbox for using Kobo Desktop on Linux will be completely useless

It doesn't matter what method you use, so long as you copy the uImage to the appropriate name for the Glo, Touch and Mini. You can do that after the desktop app downloads the firmware and before you eject.

[uboot]

@Lucas: I think not putting kernel into a regular partition has several benefits:

1.) the boot loader is easier to configure - it just needs to know a fixed offset / flash memory address
2.) the kernel cannot be easily corrupted as would be the case with file system
3.) embedded devices cannot boot easily from - say - a USB stick or Linux Live CD. There must be an easy way to install kernel, filesystem etc. Often - as with Android - uboot bootloader provides a way to put the device into some boot loader mode such that the kernel can be flashed via USB.

More info at http://www.denx.de/wiki/U-Boot


Anyways - if you want to boot the kernel from a boot partition, you may need a different boot loader. You may have a look at the Kobo Debian Linux image - maybe it does have something like Grub or Syslinux: https://www.mobileread.com/forums/sho...d.php?t=222123

[Lucas Malor]

This is very interesting, thank you

Out of curiosity: it is probably useless, since embedded devices are not intended to be easily configured by end users, but does it exists a bootloader that do both? I mean, allow you to access the bootloader and kernel by OS using partition abstraction, but they are managed at boot directly?

[uboot]

I don't get your question, I'm afraid Could you please clarify? Are you looking for something like Grub or Syslinux?

[Lucas Malor]

Yes, but only for file management from OS. Let me explain.

As you said, it's better to directly access the kernel file for many reasons (and I suppose the most important is that if partition table gets corrupted you can continue to use it). On the other hand, bootloaders like GRUB are more easy to manage, since you can access files using an ext4 partition, when the OS is loaded.
The question is: do you know if it exists a bootloader that allow you to manage the bootloader itself and the kernel image from the OS using partition abstraction, BUT it loads the kernel image directly from the device, provided offset, block size and block number?

[Lucas Malor]

@davidfor: I know you have a Touch. If you can telnet it and it's the new Touch, can read what
ntx_hwconfig -s -p /dev/mmcblk0 CPU
gives you?

[davidfor]

Sorry, my Touch is the N905 version. But, the command gives:

NtxHwCfg_GetCfgFldStrVal:[WARNING]Config header error !!
NtxHwCfg_GetCfgFldStrVal : error (-2)

[pazos]

Originally Posted by Lucas Malor

Yes, but only for file management from OS. Let me explain.

As you said, it's better to directly access the kernel file for many reasons (and I suppose the most important is that if partition table gets corrupted you can continue to use it). On the other hand, bootloaders like GRUB are more easy to manage, since you can access files using an ext4 partition, when the OS is loaded.
The question is: do you know if it exists a bootloader that allow you to manage the bootloader itself and the kernel image from the OS using partition abstraction, BUT it loads the kernel image directly from the device, provided offset, block size and block number?

Uboot does implement loading binaries in memory from fat and ext2 partitions (as well as read and write the environment from linux userspace) but I don't know if those options are enabled on kobos firmware. If you attach a serial cable you can try it yourself (at uboot prompt try ext2load or fsload) I think kobo wrote the kernel into a dedicated raw partition to allow recovery mode to boot off even with a broken root partition ( /dev/mmcblk0p1)

all recent imx soc implement a way to bootstrap the kernel into memory without uboot or any other bootloader, it is implemented by bootlets ( just two programs that start dram and power up the device, then just load the kernel into memory and jump there) This way is good for very simple systems, but command line parameters needs to be stored in the kernel itseft, not passed trhough the bootloader, which make the system less flexible (you need to recompile your kernel to change the parameters) and it is incompatible with kobo's way of restore.

[Lucas Malor]

Thank you, that's a bunch of informations

Originally Posted by pazos

I think kobo wrote the kernel into a dedicated raw partition to allow recovery mode to boot off even with a broken root partition ( /dev/mmcblk0p1)

There's a recovery partition and factory reset can be executed at boot pressing the light button, so I suppose it don't need it for that reason.

Originally Posted by pazos

If you attach a serial cable you can try it yourself (at uboot prompt try ext2load or fsload)

Since I have no idea of what are you talking about, "serial cable" apart, I have to kindly thank you and refuse the offer

[PeterT]

The serial cable would refer to a JTAG cable that can be attached to many embedded devices to allow for debugging.

[Aydan]

Originally Posted by PeterT

The serial cable would refer to a JTAG cable that can be attached to many embedded devices to allow for debugging.

No, there's a serial connection exposed on the PCB, which outputs the U-Boot shell and kernel boot messages.
I made a little hack (3-pin female header soldered to the board and hole in hte back cover) so I don't have to open the kobo to connect to the serial port.
The thing is that Kobo's uboot has a boot delay of zero so you can't get into the shell.
I hope the boot delay is configured in uboot's attributes and I can modify it with a hex editor.

Regards
Aydan

[Lucas Malor]

Can't you overwrite uboot completely?

[Aydan]

Originally Posted by Lucas Malor

Can't you overwrite uboot completely?

Yes, with another uboot or some such, that can load the kernel into memory and start it. uboot also does the basic hardware initialization like setting up clocks for the CPU and RAM. Just copying the kernel doesn't cut it.
Basically uboot is like the BIOS for the PC.

Regards
Aydan