Two examples of abandoned hardware
Back in January, Ari Jaaksi, Nokia's head of open source software operations, wrote about the fate of the 770:
Few people would disagree with the goal of offering better hardware over
time - we have all come to expect that, actually. But that does not mean
we want our old hardware to turn into paperweights, so the "supports it
fully" statement was taken as a good sign by Nokia 770 owners. Many of
those owners are expressing their
disappointment, however, now that Nokia has started closing bugs with a
message saying "WONTFIX. No fixes to N770 anymore.
" It seems
they had thought that "supports it fully" meant that the product was, well,
supported fully.
Nokia's Quim Gil has clarified what Nokia means by "full support":
In other words, 770 users can expect the device to not turn into a brick overnight, but not a whole lot more. Mr. Gil does go on to say that severe security problems would be fixed, but that seems to be about the extent of it. There are no plans for another system software release for the 770. There is an OS 2007 on 770 project which is working at porting a version of OS 2007 (the version running on the N800) to the 770 as a "hacker edition," but some parts of it work better than others, and it's not likely to be what many 770 owners had in mind. The hacker edition will not be a supported product.
It's tempting to say that, since the 770 is a Linux-based device, the community should be able to support it into the future. As long as people care about the platform, it should continue to work. The problem is that the 770 contains a fair amount of non-free software at all levels. It seems that Nokia's agreement with Opera prohibits them from providing a new version of the browser for the 770. Some of the power management code is proprietary, 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; it's a slow death sentence for the 770 tablet.
There have been calls for the opening of the tablet software. The same message from Mr. Gil talks about why that was not done in the first place:
An obvious counterargument would be the One Laptop Per Child project which is successfully developing high-quality hardware and software under tight deadlines in an entirely open manner. That notwithstanding, the 770 project is long finished, so Nokia should be able to release the relevant source now. Unfortunately, such a release appears not to be in the cards:
Note that the "slow" argument applies only to the hardware-specific components. A release of higher-level software is even less likely:
Mr. Gil's postings include a number of statements to the effect that things will be better in the future. He says:
There are hints that more components will be opened in the future as well, but no promises. The end result is that the 770 will, for many users, hit the end of its useful life much sooner than it should have, and that the N800, while hopefully lasting longer, may well encounter similar issues. This state of affairs is unfortunate, it makes a nice piece of hardware less valuable than it really should be.
On a different front, users of the proprietary NVIDIA drivers should be aware, by now, that the company has decided to drop support for a number of its products from the latest driver release. Here's a list of supported (and dropped) adapters for the curious. The older hardware can still be run using the "legacy" driver, but not all features are supported.
This loss of support can be a problem for users; it is also a problem for
the few distributors which make these drivers available. Ubuntu, in
particular, has
been contending with this issue. Including the "legacy" driver adds a
support requirement over time. It also adds some interesting twists to the
"feisty" upgrade: some systems will have to "upgrade" to the
"legacy" driver, while others can go to the current module. One assumes
they will work everything out, but it is a hassle that nobody needed. And
it could have been avoided by simply making the driver be free software.
Posted Apr 12, 2007 3:25 UTC (Thu)
by joey (guest, #328)
[Link] (3 responses)
BTW, you missed the example of the OpenMoku project which is being very careful to develop their embedded system using fully free software.
(Disclaimer: I work for a company that develops embedded systems running Debian.)
Posted Apr 12, 2007 4:54 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
Yesterday Thomas Kunze announced on oz-devel that he'd managed to write a SD driver for it. Amazing! If it works, this piece of hardware that I bought in 2002 will continue to be a viable device.
Proprietary bits might not seem very bad now but, as N770 owners are discovering, they'll bite you eventually. I pity anyone who spent $400 on an N770. I can't imagine being told only 1.5 years later that the device is end-of-lifed. Personally, I'd be furious!
Posted Apr 13, 2007 16:31 UTC (Fri)
by ken_i_m (guest, #4938)
[Link]
I am very tired of getting burned by hardware vendors. High on the list is Linksys who changes chipsets from one supported by open source driver to one not without changing the model name or packaging in any way that would indicate that it is a different piece of hardware on the inside.
HP printers are another pain. HP makes a lot of noise about supporting CUPS. Yet a few months ago I bought a new printer only to find that it does not work very well (I have to power cycle the printer after every print job). Needless to say, if I connect it to my dual-boot system it works great under Windows. :-(
I have an ATI 9200 video card in my desktop system and will be moving it to my new desktop box that I am building. I refuse to buy another card without open source support.
Posted Apr 14, 2007 18:55 UTC (Sat)
by eli (guest, #11265)
[Link]
Posted Apr 12, 2007 8:19 UTC (Thu)
by nhippi (subscriber, #34640)
[Link] (10 responses)
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.
Posted Apr 12, 2007 8:55 UTC (Thu)
by dufkaf (guest, #10358)
[Link] (9 responses)
Posted Apr 12, 2007 13:57 UTC (Thu)
by nhippi (subscriber, #34640)
[Link] (8 responses)
/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.
Posted Apr 12, 2007 15:02 UTC (Thu)
by dufkaf (guest, #10358)
[Link] (4 responses)
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.
Posted Apr 12, 2007 16:04 UTC (Thu)
by nhippi (subscriber, #34640)
[Link] (2 responses)
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.
Posted Apr 12, 2007 16:58 UTC (Thu)
by dufkaf (guest, #10358)
[Link]
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.
Posted Apr 12, 2007 17:12 UTC (Thu)
by mrfredsmoothie (guest, #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.
Posted Apr 12, 2007 19:25 UTC (Thu)
by daniels (subscriber, #16193)
[Link]
Posted Apr 12, 2007 15:17 UTC (Thu)
by dufkaf (guest, #10358)
[Link] (2 responses)
Posted Apr 12, 2007 19:18 UTC (Thu)
by oak (guest, #2786)
[Link] (1 responses)
Posted Apr 12, 2007 20:17 UTC (Thu)
by dufkaf (guest, #10358)
[Link]
Posted Apr 12, 2007 8:53 UTC (Thu)
by pointwood (guest, #2814)
[Link] (1 responses)
Posted Apr 12, 2007 10:40 UTC (Thu)
by drag (guest, #31333)
[Link]
It's unfortunate.
The video drivers seem to affect Nokia N800 stuff also. They got burned by it.
I haven't seen it mentioned here, and I do not own the device nor do I understand a whole lot about it so I may be completely off base but I've heard....
The Nokia N800 is using the Ti OMAP2420 cpu/chipset stuff for it's proccessing stuff.
OMAP2420 supports not only 2D acceleration via Kdrive interface, but has OpenGL ES drivers aviable for Linux for it's 'PowerVR MBX'!
But apparently those drivers are only aviable under very restrictive terms.
I am not blaming Nokia for this in anyway, so don't misunderstand me.
It's seems to me that it's very unfortunate that a handheld device like the Nokia N800 is being distributed with very powerful video hardware support that would make it perfect for media playback (and even potentially as a handheld game platform), but nobody can use it because the software to supports it is closed!
Posted Apr 12, 2007 12:28 UTC (Thu)
by a9db0 (subscriber, #2181)
[Link] (4 responses)
Nokia's user base isn't in nearly as good a position. The installed user base is far smaller so there is less impetus to develop open alternatives. And the missing pieces are much more critical - not like swapping out a video card. I do feel sorry for the N770 owners.
That's the risk we take running proprietary stuff.
Posted Apr 12, 2007 18:00 UTC (Thu)
by phiggins (subscriber, #5605)
[Link] (2 responses)
I then decided I would buy a Matrox card because they always had such excellent Linux driver support, but I see that the only reasonably priced cards available are the G450 and G550 series, which are ages old, and people are now complaining about lockups with them on recent kernels.
Going through the cards for sale at Newegg, it appears that ATI and nVidia are the ONLY players left in town, and they're exactly the manufacturers I don't want to buy a card from. How do I show my displeasure if I can't even vote with my dollars? Where is the alternative?
Posted Apr 13, 2007 1:46 UTC (Fri)
by drag (guest, #31333)
[Link]
Buy a Intel system with 945g chipset for the GMA 950 and it's effortless 2d AND 3d acceleration. Open source drivers developed internally by Intel hired X.org hackers.
Other then that, that's it.
And as far a AMD/ATI goes it's just going to get worse. They are locking their cards down to the point were now you can't even access the framebuffer anymore. All for the sake of DRM.
It's not like Intel is any better in terms of morality. They just know how to support Linux properly.
Posted Apr 19, 2007 15:37 UTC (Thu)
by Duncan (guest, #6647)
[Link]
There's now beta status reverse engineered 3D/OpenGL support for the ATI
Here's an xorg r300/r400 portal link.
Of particular interest there is the external link (also below), a status
However, for new mobo/CPU/GPU units, it's definitely Intel at this point,
As for ATI and the future, now that AMD owns them, we'll see. Given AMD's
So I doubt Intel will remain the only viable new-hardware platform choice
Duncan
Posted Apr 12, 2007 18:23 UTC (Thu)
by oak (guest, #2786)
[Link]
As far as I know the N770/N800 video drivers (in kernel and X server)
This is why I want to run fully free software distributions (ideally Debian) on embedded hardware. The N800 also has several proprietary bits, see <http://kitenet.net/~joey/blog/entry/openmoko_and_n800/dis...>Two examples of abandoned hardware
In related, rather surprising news, the Zaurus 5500 might be viable again. The problem was its proprietary SD/MMC card reader. Sharp's closed source driver doomed the 5500 to only run Linux kernel 2.4. Since all other Zaurus devices had moved to 2.6 and 2.4 support was being dropped, it looked like the end of the line for the venerable 5500.Two examples of abandoned hardware
Well, I am mad as I got an N770 as an xmas gift less than four months ago. I was unaware that the N800 was forth coming and that Nokia would abandon the N770 so soon.Two examples of abandoned hardware
Two examples of abandoned hardware
In related, rather surprising news, the Zaurus 5500 might be
viable again.
Yesterday Thomas Kunze announced on oz-devel that he'd
managed to write a SD driver for it.
As a 5500 owner, this is a big deal to me. I had to do a bit of hunting
to find the messages referenced, so for others,
the openzaurus-devel thread.
>Some of the power management code is proprietaryTwo examples of abandoned hardware
That's better than your laptop, where power management is proprietary ACPI bytecode.
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
> backlight control and blanking (dsme daemon) Two examples of abandoned hardware
"/sys/devices/platform/omapfb/panel/backlight_level and blanking is in omapfb"
Two examples of abandoned hardware
> You even cannot read root device name (settable via flasher) early in boot sequence without dsme already runningpower management
"That's just a line in a shell script that asks from dsme for the "root" device."power management
power management
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.
Two examples of abandoned hardware
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.)
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
There was a good article on misconception about "somewhere" beingTwo examples of abandoned hardware
some 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.
:-)
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 ...Two examples of abandoned hardware
Thanks for the info about NVIDIA drivers, I have an older desktop with a card that is affected by this.Two examples of abandoned hardware
It's funny. I have the same issue. I am only able to run very obsolete Nvidia drivers for my roomate's PC.Two examples of abandoned hardware
Users of nVidia's proprietary driver for their hardware (such as myself) aren't in quite the same fix as the Nokia users. Then nv driver exists and works fine for 2D stuff, and we have hopes for the Nouveau project. That said, I do run the proprietary drivers on my FX-5200 based machine - it's the only way to get MythTV to give me decent video - and I'm watching it slide slowly to the bottom of the supported cards list. It may not make the cut next go-round.On a different front...
I'm really kicking myself for buying an nVidia card now. I just upgraded from Fedora 5 to Fedora 6 over the weekend and had to switch to the "legacy" driver. Now I see lockups that I've never seen before, all GLX apps crash the X server, and these problems all go away if I use the nv driver. But then Xorg takes huge amounts of CPU time and my desktop is sluggish.On a different front...
Sell your AMD proccessor, sell your ram, sell your motherboard. On a different front...
or
Go for the Intel G965 based motherboards and put up with some teething problems in terms of Linux driver support and get better 3D performance.
If you are looking at the old Matrox stuff, I'm assuming you are AGP, in On a different front...
which case you can get old ATI Radeon 9200-ish stuff, the last chip they
opened the specs for (the Radeon 2, thru the r200, rv280/m9+). I'm
running the 9200 (rv280) in dual monitor mode with the native xorg radeon
driver and the related kernel dri stuff and am relatively happy with it.
The biggest problem is that I'm running dual 1600x1200 monitors stacked
for 1600x2400 resolution, and the driver only supports 3D/OpenGL accel up
to 2048x2048, so a stripe 352 px high at the bottom of my bottom monitor
is OpenGL unaccelerated. That cuts out some of the fancy newer 3D
accelerated window manager stuff,, and because the bottom monitor is
my "working" monitor as well, cuts out full-screen OpenGL on what would be
the natural monitor to run it on.
Radeon 3, r300 series chips, Radeon 9500 (r300) thru 9800xt (r360) and
Radeon 4, r400 series chips, thru the Radeon x850. The x300-x850 are
available in PCI-E, so there's /some/ choice beyond Intel on semi-modern
hardware. However, in addition to being beta status, these were reverse
engineered without the cooperation of ATI (unlike Intel, which is funding
xorg developers AND open drivers), so while they may work and will work
better as their status matures, buying them IS funding hardware
uncooperativeness. Still, it's the only real choice for open drivers with
a separate PCI-E card, and on AMD, at the moment. For those who already
have their mobo/CPU and are just looking at graphics upgrades, it's about
the only option beyond the Radeon 9200 series, which WAS open-speced by
ATI.
http://dri.freedesktop.org/wiki/R300_20Portal
page listing among other things, workable resolutions playing various
games on an x800xt. and the status of various feature demos/programs.
http://megahurts.dk/rune/r300_status.html
particularly since they are not only releasing specs, not only sponsoring
hardware drivers, but ALSO sponsoring general xorg development, including
Keith Packard.
announced plans for combined multi-core chips with both CPU and GPU cores,
and the developing interested (AMD/ATI and elsewhere) in harnessing
what /has/ been the GPU as a non-graphical if still somewhat specialized
parallel instruction accelerator, it would seem difficult to continue down
the proprietary route to the degree that both ATI and NVidia had been
going. Certainly, opening up to some extent will be needed to efficiently
implement compilers to those sets of instructions. As a CPU company, AMD
is used to publicly specing out their hardware to a rather large extent,
and beyond that, it can't have missed them that a lot of the early support
for AMD64 was from open source, Linux and otherwise, well before MS had
anything at all public to share. Given that the force of that market was
enough to catapult AMD into a market leading position that even Intel had
to acknowledge, with their em64t, AMD should appreciate the potential loss
of that market to Intel better than anyone, and I can't believe they'll
sit idly by and let it happen.
forever, but they certainly seem to be so at this point. Luckily for me,
I'm not likely to be in the hardware platform market again for another
three years or so (I've a dual Opteron 242 with 8 gigs memory that I
intend to upgrade to 290s this year, then use for ~3 years before further
core upgrades), as I like a bit more choice than that. Hopefully, I'll
have it by then.
> Users of nVidia's proprietary driver for their hardware (such as myself)On a different front...
> aren't in quite the same fix as the Nokia users. Then nv driver exists
> and works fine for 2D stuff
are also Open Source.