| |||||||||||||
ELCE: The state of embedded LinuxELCE: The state of embedded LinuxPosted Nov 4, 2010 21:26 UTC (Thu) by giraffedata (subscriber, #1954)Parent article: ELCE: The state of embedded Linux
The first is the problem with "IP blocks", which are particular components that are licensed for use in system-on-chip (SoC) devices. A typical SoC "consists of a number of licensed IP blocks", and it is very hard for the kernel to determine which blocks are supported by a particular SoC. I wish people wouldn't use "supported" this way. It's ambiguous -- there is always a more explicit, plain way to say what you mean. And its almost always inconsistent with the regular English definition of the word (to hold up; more abstractly, to assist). This article does it nine times. So someone help me out: first, what is an IP block (what sort of component are we talking about)? And what does it mean for one to be supported by a particular system-on-a-chip (particular model of SoC, of course).
(Log in to post comments)
ELCE: The state of embedded Linux Posted Nov 4, 2010 22:01 UTC (Thu) by tbird20d (subscriber, #1901) [Link]
An example of an IP block on an SOC would be an ethernet PHY - the silicon gates needed to provide ethernet functionality directly from the SOC chip, and not from an external chip. In this context, "included" may have been a better word than "supported". That is, an SOC will often include several collections of (mostly predefined) silicon gates to provide specific hardware functions from the SOC.
SOC manufacturers often license or purchase IP blocks to add to their chips from external parties. Often, a spec. sheet for an SOC will say that a chip has a particular functionality, but not describe the hardware in enough detail to easily write a driver or adapt an existing one. Because many of these IP blocks come from the same vendors, it can save a lot of work if a driver author knows the source of the IP block on the SOC, as the developer can then reuse an existing driver, if there is one, more easily.
ELCE: The state of embedded Linux Posted Nov 4, 2010 22:22 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the issue is that in most cases the only variation between the same block being used on different chips is the exact details of how they are wired (and therefor how they are addressed)
another way to think about this for people is to think about serial ports on PCs. there were some standard places where the first couple of ports were configured to be used, but you could install additional serial ports in your system on non-standard ports, but you would have to configure the OS to know where the ports were. At one point this involved editing the linux source code.
this is the state that these SoC setups are in today. they have a different subarchitecture definition for each chip, mostly differing only by this sort of details.
the devicetree plan pulls these addressing issues out of the kernel into a separate file that's passed to the kernel at boot time. This way you can know that a kernel that is tested with the devices at one address will work with the devices configured at a different address rather than having to test every permutation, just in case there is some difference between the different subarchitecture definitions. The problem with the subarchitecture definitions is that they don't only contain this sort of problem, they contain a lot of other config options, and that's what Linus blew up over a few months ago, he saw how there was no consistancy about the config options that had nothing to do with the hardware in the different subarchitecture defintions, and the differences were not justifiable with any need, they were just what the person who created that subarchitecture thought were reasonable defaults.
ELCE: The state of embedded Linux Posted Nov 14, 2010 1:17 UTC (Sun) by Kamilion (subscriber, #42576) [Link]
In this case, an Intellectual Property Block, or the Verilog/VHDL gate description of a specific subsystem:
OpenRISC 1000
Most of them have a common 'bus-type' inside the chip; a lot of these open ones are Wishbone based.
See http://opencores.org/ for a list of many more IP Cores. There are thousands more proprietary cores one can license from a company, for example, ARM. Some charge more than others. Some won't allow you to synthesize designs; some will license it separately.
Most of them can be added to the bitstream of a FPGA, a Field Programmable Gate Array (Basically a big block of logic gates that can be programmed to 'be anything') and later, burned into silicon as an ASIC design, after the synthesized FPGA design proves itself in field testing.
|
|||||||||||||