Slashdot Mirror
Free/Open Source Software Hardware Requirements?
Bender asks: "Most on Slashdot seem to be concerned with getting Free/Open Source software to be compatible with hardware (firmware, register sets, etc). My question is from the other side of the table: I'm in the hardware business and I'm wondering if there are any central guidelines to better guarantee compatibility with Linux/*BSD. As an example, to guarantee that our hardware runs Microsoft Windows, we have to conform to the Windows Logo Program Requirements. These requirements dictate (among other things) firmware interfaces, debug ports, and DRM. Some of these requirements, if not implemented carefully, could trigger incompatibilities with non-Microsoft operating systems. Is there a Linux/*BSD equivalent to the Microsoft requirements to allow hardware designers to build OS agnostic systems?"
If you release complete documentation of said hardware ...
Linux is not *BSD, and *BSD is not linux, maybe you don't want to look for compatibility between them.
ajf
Conform to freely available published standards. If you have good reason to produce proprietary hardware, publish the programming interface in sufficient detail for people to make a clean-room implementation of drivers. And don't worry -- free drivers will follow.
You can use linuxhardware.org to search compatible linux hardware.
h wcompat.ht ml
But maybe you can find this article a little more helpfull
http://www.control-escape.com/linux/lx-
The obvious solution is the Open Hardware Certification at http://www.open-hardware.org/
You said:
From the "MS Logo" link:
So is it really a question of ensuring that your hardware "works", or is it a marketing issue in which you need to show the colourful Windows flag on your product's packagaing?
I'll admit that I didn't devle too deep into that MS document, though, so it may encompass far more than the logo, despite what the title suggests.
Make all registers readable! Write-only registers are a pain in the #$@#$%^!
Like the beaver, it's just Dam one thing after another
First of all, provide documentation and an engineering contact to answer questions about the documentation. Keep in mind that you will get asked questions from sources other than those related to the core Linux development team - the *BSD teams may have questions for you, some hobbiest may ask questions - answer them all. Incorporate the answers to their questions into your documentation, etc.
If you are doing anything that is truly groundbreaking, for your company, but has been done in other places, at other times, the experienced OS developers in the free software community can sometimes provide invaluable feedback on what is wrong with your design.
For example, as I understand it, the AMD64 architecture did not have an IOMMU until rather late. The Linux developers working with AMD on providing support for this architecture pointed out that it was useful and a huge performance win to have one, so AMD reworked that into the architecture. That kind of feedback is invaluable, and something a company like MicroSoft simply can't give, because they lack the necessary cross-platform experience to care. I believe the major Linux distributors are open to consulting arrangements of this type - approach them and ask them for assistance!
If the hardware you have needs firmware to be loaded into it, consider what license the firmware is distributed under, and how that interacts with the licenses of the free software you are trying to work with. At the very least, make sure other people can redistribute the firmware, unmodified, so the users are not dependent on a download from your site.
So, document the hardware interfaces. Answer questions on the hardware, and involve those more knowledgeable than your company early and often to give a better design.
Intel is trying to release Linux drivers at the same they release hardware. They are also trying to create a hardware copatability matrix. If you are a system builder or VAR this would be very helpfull. Some background:n ux/2100-7344_3-5465225.html?tag=nefd.top/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://techrepublic.com.com/5100-22_11-5465929.htm l?part=rss&tag=feed&subj=tr/
http/news.com.com/Intel+more+active+in+desktop+Li
The original poster is quite serious. It *is* a pain in the butt to have write-only registers. This is very common.
What this means is that you write some control values to the registers, which causes the hardware to do something.
If you later wish to use those values, you can't just read them back from the registers. You have to have "shadow" registers which cache the last value written to the real hardware registers.
-- Andyvan
First of all, I must commend you and your company for caring about these things - it's definitely nice to see that there are companies who actually care about their customers. ^_~ That being said, here are a few things to get you started:
Hope this helps!
quidquid latine dictum sit altum videtur.
As Linus said himself (almost TWO years ago), there is no fundamental incompatibility between DRM and Linux.
quidquid latine dictum sit altum videtur.
In Windoze land, Microsoft publishes a list of requirements, and offers testing services to ensure compliance. You code to these requirements and get the thing tested and validated. Once done, Microsoft awards you the right to put "Windows-certified" on your box, and you can consider your product "done" (modulo bug fixes/patches).
In F/OSS circles, no such certification program exists. There is no list of requirements; there is no explicit testing service. Instead, what there is is the complete kernel source code (so that you can determine precise requirements yourself), hundreds of existing drivers (to get you started writing your own), and hundreds of thousands of users who will beat up on your hardware/driver and liberally shower you with bug reports (of highly variable quality).
This may seem like a recipe for complete disaster but, depending on what you want to do, it's really not. Linux's device driver model is almost pathetically simple compared to the byzantine mess that Windows uses. So getting a driver with basic functionality is a fairly simple affair. Depending on your device, you'll probably be able to leverage off of existing infrastructure to handle bookkeeping details (for example, I2C bus devices already have an API layer that handles reference counts and locking; coding to it is dead-simple).
Conversely, there are some areas of Linux driver land that are still evolving. One of the big areas is power management. There are three major competing power management mechanisms for Linux (APM, ACPI, and the lesser-known DPM). None of them really address all power management needs and, while some sleep/suspend modes sorta kinda work, Linux's solution is far from complete. You'll be working with a moving target.
As other posters have already mentioned, publicly-available, complete hardware documentation (register maps, theory of operation, strapping options, clock diagrams, etc.) is absolutely essential . In case you get bored with your product or, heaven forfend, your company dies, the F/OSS community will be able to take up the slack. They'll also be able to add features or enhance kernel compatibility when and where it's needed. (Some lawyers or senior execs will try to veto a documentation release, citing imaginary fears such as "loss" of proprietary information and trade secrets. You are encouraged to nut-punch these knuckleheads until their opinion is changed.)
F/OSS is not as strictly regimented as the Windows camp, so strictly regimented project planning isn't as easy. There's a lot of chaos out there. This is, on balance, widely regarded as a good thing. You may be surprised at how well your engineers cope in such an environment. (Conversely, it will also help you identify more quickly exactly which features your users actually value.)
Schwab
P.S: If you have the ability, tell Microsoft to take their copy protection ("DRM") requirements and cram them.
Editor, A1-AAA AmeriCaptions
Absolutely.
a bout halfway down)
t the bottom)
And if you're looking for something to feed your marketing department, check out the applications for certification on major distro vendor's sites.
Mandrake: http://www.linux-mandrake.com/en/hardware.php3
(
RedHat:
http://bugzilla.redhat.com/hwcert/
(a
Those processes will probably get you a shiny logo for your product's box.
We don't need you to write drivers for us. It would be nice, and we will thank you profusely if you do. But we're not requiring it. All we care about is access to the complete hardware specifications. It's that simple.
Even if you have "proprietary" behavior you need to hide behind some proprietary software, just provide us an object file for that *tiny* portion of code, and we can manage the rest. We might grumble a little bit, but we'll still accept it.
What we don't want is for you to act as if you own the hardware. Don't lock us in to your driver. That's just rude.
Don't blame me, I didn't vote for either of them!
This guy is "in the hardware business".
Meaning, he buys hardware from a distributor, and with a $4 screwdriver, assembles said hardware and pitches it a customer.
I've been there, and done that. Trying to make one that's WINDOWS compatable is a royal pain in the arse, let alone OSS.
When I ran a store, we had a few lines of hardware that seemed to be more or less compatable with each other. We had to continually buy hardware of all kinds and test them to see how they did together.
It was always shocking to me how much of the hardware just didn't pass our testing. Our testing was pretty extensive, and consequently, the hardware lines we stocked were fairly limited.
Also, it was commonplace to have hardware revisions that would change without any notice whatsoever, ruining compatability.
At the time (ending Spring of 2000) one of the *WORST* offenders was Asus. On the other hand, a few relatively unknown brands (DFI and A-trend) scored rather well in our testing, and were cheaper to boot!
My best advice would be to simply test some hardware before you sell it, and see how compatable it is with your favorite distro.
Good luck.
I have no problem with your religion until you decide it's reason to deprive others of the truth.