Two examples of abandoned hardware
Posted Apr 12, 2007 15:02 UTC (Thu) by dufkaf
In reply to: Two examples of abandoned hardware
Parent article: Two examples of abandoned hardware
"/sys/devices/platform/omapfb/panel/backlight_level and blanking is in omapfb"
Yes it is, and so what? Try to change it - dsme immediatelly restores its own value. Try to stop/not start dsme so it does not interfere - wow some basic functionality is missing (i.e it all falls apart). You even cannot read root device name (settable via flasher) early in boot sequence without dsme already running (and meddling with your brightness).
"All in functional drivers, not just "read/write to registers" as you claim."
I said "mainly" not "just". Yes I know most things are in kernel and I already said that. Still the battery thing (and what else? how can I know when stuff is closed?) is done by banging undocumented HW registers from userspace.
The result - you possibly cannot have fully open system replacing current image due to battery charging. I guess it can be reverse engineered, it depends on how much the charging is done is software or hardware. If all charging logic is in sofware it is pretty dangerous stuff to mess with. Or do you suggest to reboot to nokia firmware each time you want to charge battery?
Or you mean I should ignore bme binary and have it running (in otherwise free system) for the charging to work? Will it run with heavily modified/upgraded linux kernel two years from now? Will it work with another kernel than linux? Do you also suggest I should leave whole uclibc based initfs partition (mostly with closed stuff) also in place just because of bme in it (probably linked to that uclibc and other proprietary stuff)?
Well, everything is solvable but telling me this is a myth and there is no problem because everything is in kernel is simply not true.
to post comments)