Glo bug in upgrade-wifi.sh?

[lomo74]

Hello all,
I'm very new to the forum and to Kobo hacking.
While looking at /etc/init.d/upgrade-wifi.sh from 3.17.3 release, I discovered a possible bug. Look around lines 23~33:

if [ $CPU ]; then
PCB=`ntx_hwconfig -s -p /dev/mmcblk0 PCB`
RAM=`ntx_hwconfig -s -p /dev/mmcblk0 RAMType`
RAM_SIZE=`ntx_hwconfig -s -p /dev/mmcblk0 RamSize`
RAM_SIZE=`echo $RAM_SIZE | awk '{print $RAM_SIZE-MB}'`
NEW_UBOOT=/mnt/onboard/.kobo/upgrade/$PLATFORM/u-boot_mddr_$RAM_SIZE-$PCB-$RAM.bin
NEW_KERNEL=/mnt/onboard/.kobo/upgrade/$PLATFORM/uImage-$PCB
[ ! -e NEW_UBOOT ] && NEW_UBOOT=/mnt/onboard/.kobo/upgrade/$PLATFORM/u-boot_lpddr2_$RAM_SIZE-$PCB-$RAM.bin
UBOOT=$NEW_UBOOT
KERNEL=$NEW_KERNEL
fi

See the bolded line, shouldn't it read:

[ ! -e $NEW_UBOOT ] && NEW_UBOOT=/mnt/onboard/.kobo/upgrade/$PLATFORM/u-boot_lpddr2_$RAM_SIZE-$PCB-$RAM.bin

Am I wrong? Without the dollar, NEW_UBOOT variable is not expanded, the test fails and the variable NEW_UBOOT is always assigned the value /mnt/onboard/.kobo/upgrade/$PLATFORM/u-boot_lpddr2_$RAM_SIZE-$PCB-$RAM.bin.
As no u-boot_lpddr2* file exists in the package, the bootloader is never updated.
Any thoughts?
Cheers
- Lorenzo -

[frostschutz]

It makes sense. Although in case of my H2O it does not make any difference.

In my package there are two files:

u-boot_lpddr2_512-E606G0-LPDDR2.bin
u-boot_mddr_256-E606F0B-K4X2G323PC.bin

But it would look for u-boot_mddr_512-E606G0-LPDDR2.bin (which does not exist) so with and without the change it would end up using u-boot_lpddr2_512-E606G0-LPDDR2.bin instead.

Have you checked whether it actually affects your reader?

It should be reported to Kobo in any case, it looks unintentional. Although I guess if they actually installed the wrong bootloader for a device they would notice? (Presumably it would cause booting problems or similar?)

[PeterT]

I'm sure I remember davidfor pointing out some issues with the upgrade scripts in the past and nothing ever changing with them.

[davidfor]

The problem I pointed out was with the kernel. The upgrade script generates a file name the includes the PCB. But, the mark4 firmware package doesn't include a kernel that matches the name generated for either the Glo or the N905C Touch. There is a version for the other devices in their packages.

I think I agree with the analysis here, but my shell scripting in rubbish and I need to actually test it before agreeing completely.

As to how much it matters, it really depends on how often the image and uboot are changed. From comparing the upgrades, it doesn't happen that often. But it does happen. And not upgrading these might explain some different behaviour that people see. And, from memory, the version of this in the recovery firmware for the Glo gets the names right. Which means the uboot and kernel are installed for next first update. And that probably explains why a factory reset fixes some of the unusual problems.

[Lucas Malor]

Report the bug here:
https://github.com/kobolabs/Kobo-Rea...pen+is%3Aissue