[fastrobot]

Originally Posted by davidfor

Why do you think they are partial replacements?

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.

They don't include what is on the recovery partition. That has much the same files excluding nickel and related files.

And that includes the kernel and kernel drivers, such as are used for the ir touch?
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...

It also has a set of the files in the upgrade package as at device release. The factory reset simply reboots, formats the root and user partition and installs it's copy of the firmware files in exactly the same way that the upgrade does.

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.

And there has been at least one person who replaces the firmware files on the recovery partition with those from an upgrade package and the factory reset worked perfectly to give them that version.

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

I'm pretty sure the Glo and Aura HD use different kernels. They share the same update package, but there are two uImage files in the package. One has an PCB identifier for the Aura HD as part of the name. They are different sizes, so I assume there is a difference in the code.

The bugs I'm seeing ought not happen if the hardware for both machines is an imx507, AND the kernel is identical. So -- there definitely is something wrong somewhere. I'd say the odds are excellent that you are correct, ... eg: different kernel code somewhere.

Huh? The Glo code has been there for ages.

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....

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...

The new one is for the Glo HD. The problem is that the labelling has changed.

Yup. And quite inconsistently... for the whole hw repository is now labeled with 'hd'...

That suggests to me that this is the code used for those three devices.

Assuming the labeling isn't wrong (and I will hope it isn't). But yes.... it does suggest that.
A diff will prove the point, later...

They were released at the same time and probably share more hardware than the other devices. The newer devices have their own package. I think the "imx508" is for the first two versions of the Touch, and the others are for the three versions of the WiFi and the original Kobo.

Looking at these, it does make me question my statement about shared code trees. Hopefully they are snapshots taken for each of the devices from the shared code. Someone would have to compare the contents to see.

I will... but only after I get another Glo to work with in a few days...
Thanks for the pointers.