| |||||||||||||
|
| |||||||||||||
Two examples of abandoned hardwareTwo examples of abandoned hardwarePosted Apr 12, 2007 8:19 UTC (Thu) by nhippi (subscriber, #34640)Parent article: Two examples of abandoned hardware
>Some of the power management code is proprietary
This is a myth! The power management code is in the kernel, and it's GPL.
The power management myth was even busted in a reply to the comment you based this article on:
http://lwn.net/Articles/227591/
>as are various other pieces of the system. So, even if the "hacker edition" can be made to work, it will be a system with a number of binary blobs in important places. That will severely limit the degree to which the community can support the platform;
The only hard-to-replace blob is battery charging code. Then again, your laptop has proprietary battery charging code in the bios flash as well..
I'd say it's more accurate to say that perception that there is many important irreplaceable blobs is limiting people from creating a community created distribution.
(Log in to post comments)
Two examples of abandoned hardware Posted Apr 12, 2007 8:55 UTC (Thu) by dufkaf (subscriber, #10358) [Link] Well for me the battery charging (bme daemon) and backlight control and blanking (dsme daemon) is part of power management. So this is not myth at all. Yes most things are in kernel but not all off them. Specifically management of Nokia proprietary chips (Retu, Tahvo) are done in userspace (bme,dsme,?) with kernel driver that mainly allows you to write specific hardware registers from userspace (without documenting those registers of course).
Two examples of abandoned hardware Posted Apr 12, 2007 13:57 UTC (Thu) by nhippi (subscriber, #34640) [Link] > backlight control and blanking (dsme daemon)
/sys/devices/platform/omapfb/panel/backlight_level and blanking is in omapfb.
> Specifically management of Nokia proprietary chips (Retu, Tahvo) are done in userspace (bme,dsme,?) with kernel driver that mainly allows you to write specific hardware registers from userspace (without documenting those registers of course).
retu-rtc (rtc), tahvo-usb (usb on 770), retu-wdt (watchdog), retu-pwrbutton (guess). All in functional drivers, not just "read/write to registers" as you claim.
bme (battery charging) is unfortunately implemented in software. In the easiest case, you can just ignore it as you would ignore a laptops hardware based charging code.
Two examples of abandoned hardware Posted Apr 12, 2007 15:02 UTC (Thu) by dufkaf (subscriber, #10358) [Link] "/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.
power management Posted Apr 12, 2007 16:04 UTC (Thu) by nhippi (subscriber, #34640) [Link] > You even cannot read root device name (settable via flasher) early in boot sequence without dsme already running
That's just a line in a shell script that asks from dsme for the "root" device.
> Or you mean I should ignore bme binary and have it running (in otherwise free system) for the charging to work?
That's my impression. Notice that I don't have anything to do with bme.
> 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)?
Once you have a otherwise free system, you could ask for a static bme binary. That would be a request much harder to to argue as not reasonable, than the "plz provide commercial quality images for old hardware forever" request.
> 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.
I guess we disagree in terminology. I consider power management to be the code that enables powering down unneeded devices, dyntick, managing the power states the core etc. Wikipedia kinda agrees. I guess your idea of power management includes battery charging logic. Which is fair enough, related to electric power.
But I already told in my first post that bme is the hard bit.
power management Posted Apr 12, 2007 16:58 UTC (Thu) by dufkaf (subscriber, #10358) [Link] "That's just a line in a shell script that asks from dsme for the "root" device."
Not sure what you mean, there is cal-tool command in initfs which can read root device name stored in config partition (cal-tool -r), this does not work without dsme running because cal-tool does it via closed libraries (libcal,libdsme) in /usr/lib (in initfs) which need dsme to be running. It looks like dsme proxies all access to config partition and libcal or libdsme communicates with dsme over socket in /tmp to do the dirty work. So you cannot read stuff from config partition without having dsme running. I guess there is lot of interesting stuff stored in config parition (like WLAN MAC address?) so you probably need dsme (and whole initfs partition with other binaries) also for wlan initialization at least. I'm not sure if you can kill it then without trigering watchdog, maybe yes, maybe no. Also the config partition might be needed for bootloader too so you probably need to leave it as is too.
Even without power management stuff (no matter what is the definition) it is not easy at all to roll your own free solution for n770 and do not lose basic device functionality. Free kernel is not enough. And wasting a lot of time figuring out how the closed stuff works with real possibility that sometime in future you hit some stone wall and all your effort is wasted is not funny.
"Once you have a otherwise free system, you could ask for a static bme binary."
You must be joking. Yes, I can ask, will I get it? Will it work and solve all problems? Maybe. Maybe not.
Anyway, this should better go to maemo-developers, not here.
power management Posted Apr 12, 2007 17:12 UTC (Thu) by mrfredsmoothie (subscriber, #3100) [Link]
Yeah, especially considering the device wasn't "commercial quality" for at least months after it was released. Please. This "commercial quality" thing is a total canard. There are quite a number of flagship FOSS projects producing software of a quality no commercial product can match, and you well know it, or you wouldn't even be reading this site. The fact is, given enough information -- or lacking that, time and people who live in jurisdictions where EULA restrictions against reverse engineering aren't enforceable -- the community can, and probably will produce images for the N770 of a higher quality than that which shipped on the device when it first became available. Nokia could certainly help with that, but it seems their policy is to be officially unhelpful and maybe turning a blind eye to occasional, sufficiently cryptic attempts by some of their employees to offer bits of help.
Two examples of abandoned hardware Posted Apr 12, 2007 19:25 UTC (Thu) by daniels (subscriber, #16193) [Link] 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.Currently, the main things you cannot get working with open source components are the wireless LAN and battery charging. There are very few binary blobs at a low level (i.e. not the UI): nolo, dsme, bme, and umac (essentially WLAN firmware). Replacing DSME is not a one-liner. But it is easy, verging on trivial: there are very few parts which aren't already known (e.g. blanking the screen with omapfb; a lot of these parts will almost certainly move into open source components such as the X server in the future anyway), so you could run a fully-functional tablet without DSME. But no-one has attempted before. The flasher has been reverse engineered, but no-one from the community has ever even tried to replace DSME, so declaring that it's impossible strikes me as kind of dumb. In my experience, general demands ('hey, the wireless should be open source', 'tell us what DSME does') don't get much currency. But specific technical questions (looking particularly at the details of the N800's display architecture on maemo-developers: look for the threads with myself and Siarhei) are more likely to get detailed answers than you'd think. So, if there's truly a huge developer demand for a fully open-source system: why has no-one ever attempted to replace DSME with an open component? Maybe the answer lies in perceived developer demand not being quite as strong as some assert ... (Disclaimer: I'm paid by Nokia to work on the internet tablets. I looked at DSME's source just today to verify what I've just said. However, this is not Nokia's official position, et al.)
Two examples of abandoned hardware Posted Apr 12, 2007 15:17 UTC (Thu) by dufkaf (subscriber, #10358) [Link] Also those drivers you did not mention in your list are called retu-user and tahvo-user (both in drivers/cbus/ in kernel source) and the whole point of having them in kernel is allowing banging HW registers from userspace. They only offer IOCTL for that, nothing else.
Two examples of abandoned hardware Posted Apr 12, 2007 19:18 UTC (Thu) by oak (guest, #2786) [Link] There was a good article on misconception about "somewhere" beingsome perfect documentation for the hardware that the "evil" people had "plotted" to keep away from the open source developers, but unfortunately I couldn't find that article now. Basically it said that many of the device drivers just "bang some HW registers" and only documentation available (anywhere) is the code banging those HW registers. And the "magic" values in the code are something that have been found to work by experimentation. :-)
Two examples of abandoned hardware Posted Apr 12, 2007 20:17 UTC (Thu) by dufkaf (subscriber, #10358) [Link] well one could log all reads and writes that go through those *-user drivers together with pid of calling process so we could guess what those closed userspace parts do ...
|
|
||||||||||||