[davidfor]

Originally Posted by fastrobot

Because I have edited some files on the working image; and then an update happens... and some of my files were replaced, some were not: Simple Conclusion, not all files in the working image are being replaced by updated ones, hence the update is a partial system update.

But, did you edit executable or configuration files? The latter might be generated at run time by something so we don't want them replaced. If there are executables that are not replaced by an upgrade, that to me is a concern. Or it means they are no longer being used.

And that includes the kernel and kernel drivers, such as are used for the ir touch?

That I don't know. Not all are needed as booting from the recovery partition simply runs a script to reinstall the factory firmware in the root partition. The script is very similar to the one that installs the upgrade, but it formats the root and user partitions first.

Which gives one more possible reason why the KoboGlo's e-paper driver reports correct orientation, but the Kobo AuraHD reports a flipped orientation (180 degrees out from reality). For if the CPU is the same, the build in e-paper hardware must be the same -- and only the kernel driver could be causing the problem. But if the hardware is different they could have the same driver, and still have different operation.

When I get my new Glo, I'll have to check the exact CPU in /proc/cpuinfo -- and download the /proc/config.gz from both the Glo and the AuraHD, so I can run diff on them and see what is reported as different...

The Glo and Aura HD are different hardware. They share some things, such as the CPU, but other elements are different enough that the upgrade package includes a separate kernel image for the Aura HD, but the Glo, N905C Touch and the Mini share one.
[QUOTE]
Wait. Do you mean that there is an upgrade package on the backup/resert partition, which installs those files rather than copying the backup partition in its entirety?
I would have expected it to just clone the backup partition using dd.
For if it merely installs a package, then it might not be replacing the kernel on the working root image -- and if the working root kernel got corrupted, even a restore might not fix the reader.
/QUOTE]
Well, that's why I said "installs it's copy of the firmware files in exactly the same way that the upgrade does". You can't do a dd of the recovery partition to the root partition as there is code to execute the reinstall. You would need to remove that afterwards. In any case, the factory reset does install a copy of the uBoot and kernel. And everything else.

I was planning on doing the same thing, except installing a hacked version of the upgrade so that a factory reset brings it back to a working version with my extensions already built in; and probably some modifications so that when a new upgrade is detected, that it checks them to see if they can be patched to include my modifications to /etc/init.d/rcS

Yes, that should work. Others are fiddling with the rcS and others have replaced the firmware package on the recovery partition with later versions. Getting it right is the important thing. But taking a copy of the SD card will save you if you make a mistake.

I see. The repository for hardware -- is as a whole -- biased-labeled glohd kernels.
Even though it has the kernels for all the readers up until now, and not just glohd.

Who knows, next year they might add a kindle kernel to the repository and rename the whole directory "kindle kernels." ! (Wouldn't that be helpful?!) Or maybe someone will write a python script to change the directory names once a week to alternate possibilities....

I didn't have a clue what you meant by this but I went a directory up and realised. What you are talking about is the comment from the last commit in that area. The columns in the list are the name item in the repository, the comment included in the last commit for that item, or item within a directory, and how long ago that commit was made. Hence, "glohd kernel and bootloader" because that was the last thing changed. And before you say anything, the quality of the commit comment is on par with just about any place I've worked.

But seriously:
Inside, under imx507 and not labeled GLO as a directory -- which is why I didn't notice it before; is a directory containing a second kernel marked kobo-glo. It's just not labeled as such on the directory which contains it.

A bit of labeling inconsistency which makes doing GPL recompilation work harder.
If it has the Glo and Touch kernel, the directory ought to be lableled imx507-glo+touch+foobaz (whatever other devices use this kernel).

So -- I linked my pseudo zforce-ir-touch driver against the AuraHD kernel, and it works perfectly in the AuraHD -- but occasionally locks up in the Glo. Go figure... and the kernel didn't even complain that it was a mismatched module...

Yes, it would have been very good if their crystal ball had told them that they would need multiple versions of this and exactly what they would need to call them.