Re: device trees.
David Gibson wrote: >> >> It is not THE dtb, it is A dtb. Our systems support and typically use >> multiple FPGA bit streams. >> > > Ah, ok. And those multiple bitstreams all inhabit the same NOR flash? > From what I read below I'm guessing not.. > In my work they virtually always do, but in clusters our cards typically do not contain CPU's or Flash. > > > Ok. But they must be using some tool to push the bitstream into the > board yes? Could that same tool be made to take a bitstream+dtb > bundle and push each piece into the right section of flash? > The entire flash is treated as a FileSystem. Bitstreams are written to it as files. When a pico card is hosted it looks like a disk to the host. Whne it is standalone, monitor does file reads/writes/directories, exeutes elf's and loads new bitstreams >> Worse still the wrong dtb will probably mostly work. If it just failed >> they would be more likely to grasp what they got wrong. >> >> I need/want the device tree welded to the bitstream. That means creating >> it dynamically or welding it to the bitstream. >> Anything else wil be a support nightmare. >> > > Right. I guess it's all a question of what constitutes "welded" given > the tool setup that's typically used by your clients. I'm trying to > understand enough about your system to make practical suggestions of > how to achieve weldedness. > It is not just about a system, it is a family of systems, that are similar but not identical. And are used for an extremely wide variety of purposes. My personal focus is Pico cards as embedded systems. That is about 1/3 of our market. 1/3 is clusters, and 1/3 is custom systems that are designed similar to our cards but are produced in volume for the specific needs of the client. These typically do not have an OS and this is one of the places the spartans show up. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Wed, May 13, 2009 at 02:11:22PM -0400, David H. Lynch Jr. wrote: > David Gibson wrote: > > > > > > Ok. If you have NOR flash, why couldn't you just put the dtb in a > > separate partition of the NOR? > > > > > It is not THE dtb, it is A dtb. Our systems support and typically use > multiple FPGA bit streams. Ah, ok. And those multiple bitstreams all inhabit the same NOR flash? >From what I read below I'm guessing not.. > Clients are > That means each bitstream must have its own dtb, clients are > allowed/expected to create their own firmware, > but the norm is to leave the "PrimaryBoot.bit" startup bit file intact. > Clients may swap between several bit files for development purposes in > the course of a day. > It is even possible that a clients application may require swapping bit > files as part of normal operations. > I want one linux binary - because I know damn well that given two my > clients will use the wrong one alteast 30% of the time. > Somewhere arround 4 binaries that becomes almost 100% of the time. > Using dtb's to make the linux binary does NOT solve the problem it just > changes the file they have to get right. Ok. But they must be using some tool to push the bitstream into the board yes? Could that same tool be made to take a bitstream+dtb bundle and push each piece into the right section of flash? > Worse still the wrong dtb will probably mostly work. If it just failed > they would be more likely to grasp what they got wrong. > > I need/want the device tree welded to the bitstream. That means creating > it dynamically or welding it to the bitstream. > Anything else wil be a support nightmare. Right. I guess it's all a question of what constitutes "welded" given the tool setup that's typically used by your clients. I'm trying to understand enough about your system to make practical suggestions of how to achieve weldedness. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
David Gibson wrote: > > > Ok. If you have NOR flash, why couldn't you just put the dtb in a > separate partition of the NOR? > > It is not THE dtb, it is A dtb. Our systems support and typically use multiple FPGA bit streams. Clients are That means each bitstream must have its own dtb, clients are allowed/expected to create their own firmware, but the norm is to leave the "PrimaryBoot.bit" startup bit file intact. Clients may swap between several bit files for development purposes in the course of a day. It is even possible that a clients application may require swapping bit files as part of normal operations. I want one linux binary - because I know damn well that given two my clients will use the wrong one alteast 30% of the time. Somewhere arround 4 binaries that becomes almost 100% of the time. Using dtb's to make the linux binary does NOT solve the problem it just changes the file they have to get right. Worse still the wrong dtb will probably mostly work. If it just failed they would be more likely to grasp what they got wrong. I need/want the device tree welded to the bitstream. That means creating it dynamically or welding it to the bitstream. Anything else wil be a support nightmare. Though this does not impact Linux, we have clusters of FPGA's that are used for High Performance computing, One typical application is decryption where they work much like turing's Bomb's at bletchley park only much faster. Anyway in that application we load bitstreams into FPGA's exactly the way someone would load programs into a processor. The FPGA programming can be changed on a whim. In a cluster some FPGA's/Processors might be executing one set of code while others might be running different programming. As the tools get better this is going to become even more common. Right now this is not a linux application (linux manages the cluster), but there is no reason you can not think of the cluster as a massive SMP machine, with massively parallel soft CPU's, and who knows the whole mess could be running Linux itself. The point I am trying to make is whatever I am doing now, things may be totally different soon enough. Every significant performance gain that occurs with Xilinx tools results in a significant increase in our markets. Hard and fast constraints guarantee problems down the line. Wasteful choices that are easy now come back to haunt us down the line. Standalone embedded systems are my bread and butter, but they are only about 1/3 of our market. Even within them 95% of our clients do not need Linux. Most do not really need an OS at all. Some of the time they do not even need a CPU. We provide Linux because it makes them happy, because they are not up to developing their own standalone programs to perform the tasks. Still that means that Linux needs to make the task easier - not harder. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
>> Um.. one thing I'm missing in this discussion of attaching the dtb to >> the bitstream: I don't see how the bitstream becomes accessible to >> the kernel at runtime. Unless you were exposing the dtb as part of >> the fpga programming, but I thought you explicitly weren't doing that >> because of limited bram space. >While I am not sure I grasp all of the nuances why, this is NOT the >scheme Stephen recomends. >But it looks to be the most promising for me at Pico. There is not a general way to pass additional information which does not program configuration bits of the FPGA through the configuration interface. There is a mechanism to do this in Virtex 4 and Virtex 5, but there is no such mechanism for Spartan 3. The best option that works for all Xilinx FPGAs is to use the initial state of a BRAM memory block to contain the .dtb, which can then be scavenged and reused in the system, if necessary, although this can impact overall system design. David specifically asked for a mechanism which: 1) works on Spartan 3, in addition to V4 and V5. 2) does not require reserving an initialized BRAM, since BRAM information is very expensive in his system. The solution is highly specific to the configuration mechanism that David's company uses in their systems, and is not generally applicable to all board designs. The main point of all of this is to avoid separating the bitstream from the corresponding .dtb, in order to avoid consistency issues. Essentially, the bitstream describes itself using a .dtb. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote: > David Gibson wrote: > > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote: > > > >> Another possibility is to pad the DTB with a DESYNC command and the > >> correct pad frame, just in case it cannot be prevented. > >> > > > > Um.. one thing I'm missing in this discussion of attaching the dtb to > > the bitstream: I don't see how the bitstream becomes accessible to > > the kernel at runtime. Unless you were exposing the dtb as part of > > the fpga programming, but I thought you explicitly weren't doing that > > because of limited bram space. > > > > I imagine this is simply due to my ignorance about FPGA techniques, > > but if someone could enlighten me...? > > > While I am not sure I grasp all of the nuances why, this is NOT the > scheme Stephen recomends. > But it looks to be the most promising for me at Pico. > > In my instance, the FPGA code is typically in NOR Flash - actually > several different FPGA bitstreams might be in Flash. > The mechanism that we use to load the FPGA ensures that I can know > the Flash File that was used to program the FPGA. > That means that my monitor an read that file and extract the device > tree. > The remainder is a discussion of how to concatenate the dtb and the > bit stream together, the pros/cons of prepending vs. appending, > and work arrounds for issues. > The critical factor is that the nature of the FPGA load process > makes it possible to put data at the front or rear and assure that it > gets ignored. Ok. If you have NOR flash, why couldn't you just put the dtb in a separate partition of the NOR? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
David Gibson wrote: > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote: > >> Another possibility is to pad the DTB with a DESYNC command and the >> correct pad frame, just in case it cannot be prevented. >> > > Um.. one thing I'm missing in this discussion of attaching the dtb to > the bitstream: I don't see how the bitstream becomes accessible to > the kernel at runtime. Unless you were exposing the dtb as part of > the fpga programming, but I thought you explicitly weren't doing that > because of limited bram space. > > I imagine this is simply due to my ignorance about FPGA techniques, > but if someone could enlighten me...? > While I am not sure I grasp all of the nuances why, this is NOT the scheme Stephen recomends. But it looks to be the most promising for me at Pico. In my instance, the FPGA code is typically in NOR Flash - actually several different FPGA bitstreams might be in Flash. The mechanism that we use to load the FPGA ensures that I can know the Flash File that was used to program the FPGA. That means that my monitor an read that file and extract the device tree. The remainder is a discussion of how to concatenate the dtb and the bit stream together, the pros/cons of prepending vs. appending, and work arrounds for issues. The critical factor is that the nature of the FPGA load process makes it possible to put data at the front or rear and assure that it gets ignored. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, May 12, 2009 at 8:36 PM, David Gibson wrote: > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote: >> >> Another possibility is to pad the DTB with a DESYNC command and the >> correct pad frame, just in case it cannot be prevented. > > Um.. one thing I'm missing in this discussion of attaching the dtb to > the bitstream: I don't see how the bitstream becomes accessible to > the kernel at runtime. Unless you were exposing the dtb as part of > the fpga programming, but I thought you explicitly weren't doing that > because of limited bram space. > > I imagine this is simply due to my ignorance about FPGA techniques, > but if someone could enlighten me...? In this case the processor has access to the flash where the FPGA bitstreams are stored and a set of registers in a CPLD which tells it which bitstream was used to configure the FPGA. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote: > > Another possibility is to pad the DTB with a DESYNC command and the > correct pad frame, just in case it cannot be prevented. Um.. one thing I'm missing in this discussion of attaching the dtb to the bitstream: I don't see how the bitstream becomes accessible to the kernel at runtime. Unless you were exposing the dtb as part of the fpga programming, but I thought you explicitly weren't doing that because of limited bram space. I imagine this is simply due to my ignorance about FPGA techniques, but if someone could enlighten me...? > > -Original Message- > > From: Grant Likely [mailto:grant.lik...@secretlab.ca] > > Sent: Monday, May 11, 2009 10:30 PM > > To: Stephen Neuendorffer > > Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org > > Subject: Re: device trees. > > > > On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer > > wrote: > > >> > OK, so the key question seems to be *when* the bitstream is > > > associated > > >> > with the > > >> > device tree. If at bitstream generation time, you can prepend the > > > .dtb > > >> > to the bitstream. As long as the dtb doesn't contain the magic > > >> > bitstream start code, you can go back and access it later. > > >> > > > >> You really mean prepend ? I was presuming that things would work > > > better > > >> if it was appended ? > > > > > > Yes, actually prepend is simpler because you don't have to know the size > > > of the bitstream. > > > Everything before the SYNC code in the bitstream is ignored. > > > > ...In this case, might need to preprocess the .dtb the escape out the > > possibility of a sync code appearing. > > > > g. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, May 12, 2009 at 08:13:19PM -0400, David H. Lynch Jr. wrote: > > > Are we all using the same meaning of firmware ? > > While firmware == BIOS is the norm for PC's Well, BIOS, or bootloader is what I'm meaning here. > atleast in the embedded FPGA space firmware could mean the FPGA > programing that creates the hardware. > For an FPGA based system a dtb generated by the same software that > created the "firmware" for the FPGA, > had better match the "hardware" exactly. Literally welding the > "firmware" to the dtb makes alot of sense. Well, yes, but FPGA based systems are not *that* common. And even in this case the devtree will only match the "hardware" exactly if the generator isn't buggy. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Whenever I say firmware I mean executable code that executes when the processor comes out of reset. When I mean the FPGA bitstream, I say bitstream. :-) g. On Tue, May 12, 2009 at 6:13 PM, David H. Lynch Jr. wrote: > > > Are we all using the same meaning of firmware ? > > While firmware == BIOS is the norm for PC's > atleast in the embedded FPGA space firmware could mean the FPGA > programing that creates the hardware. > For an FPGA based system a dtb generated by the same software that > created the "firmware" for the FPGA, > had better match the "hardware" exactly. Literally welding the > "firmware" to the dtb makes alot of sense. > > FPGA "firmware" is typically created with hardware programming > languages like Verilog, and VHDL. > It is still "programmed" and like all programming quality varies. > > David Gibson wrote: >> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote: >> >>> On Mon, May 11, 2009 at 7:12 PM, David Gibson >>> wrote: >>> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: > In other words; having your bootloader support FDT is preferred, but > not required. > I wouldn't even go so far as to say it's preferred. IMO, people have gone a bit prematurely keen on moving devtree handling into the firmware. Putting it in the firmware has a number of advantages, but it also has a number of non-trivial disadvantages. >>> I disagree. The more I work with it, the more I appreciate the >>> advantage of decoupling the kernel image file from the hardware >>> description. It is valuable being able to build a single image file >>> that boots on a wide range of boards because the device tree passed in >>> by firmware. >>> >> >> Heh, where all my work in the embedded space has led me to more and >> more appreciate the fact that firmware is almost invariably crap, and >> that it's therefore best not to trust anything it tells you. >> >> >>> I'm not downplaying the disadvantages and problems, but I still hold >>> the view that the striving for generic multiplatform kernel images is >>> worth the effort. >>> >>> ... but I do agree that hard linking the .dtb into firmware, or making >>> the .dtb hard to upgrade is the way of madness. >>> >> >> Ah, we're talking at cross purposes a bit then. Yeah, I'm talking >> about the situation where the dtb is part of the firmware, or at least >> as difficult / inconvenient to update as the firmware. If the dtb is >> separate from the kernel, but as easy to update / switch as the >> kernel, that is indeed a very nice setup. >> >> > > > -- > Dave Lynch DLA Systems > Software Development: Embedded Linux > 717.627.3770 dh...@dlasys.net http://www.dlasys.net > fax: 1.253.369.9244 Cell: 1.717.587.7774 > Over 25 years' experience in platforms, languages, and technologies too > numerous to list. > > "Any intelligent fool can make things bigger and more complex... It takes a > touch of genius - and a lot of courage to move in the opposite direction." > Albert Einstein > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Are we all using the same meaning of firmware ? While firmware == BIOS is the norm for PC's atleast in the embedded FPGA space firmware could mean the FPGA programing that creates the hardware. For an FPGA based system a dtb generated by the same software that created the "firmware" for the FPGA, had better match the "hardware" exactly. Literally welding the "firmware" to the dtb makes alot of sense. FPGA "firmware" is typically created with hardware programming languages like Verilog, and VHDL. It is still "programmed" and like all programming quality varies. David Gibson wrote: > On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote: > >> On Mon, May 11, 2009 at 7:12 PM, David Gibson >> wrote: >> >>> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: >>> In other words; having your bootloader support FDT is preferred, but not required. >>> I wouldn't even go so far as to say it's preferred. IMO, people have >>> gone a bit prematurely keen on moving devtree handling into the >>> firmware. Putting it in the firmware has a number of advantages, but >>> it also has a number of non-trivial disadvantages. >>> >> I disagree. The more I work with it, the more I appreciate the >> advantage of decoupling the kernel image file from the hardware >> description. It is valuable being able to build a single image file >> that boots on a wide range of boards because the device tree passed in >> by firmware. >> > > Heh, where all my work in the embedded space has led me to more and > more appreciate the fact that firmware is almost invariably crap, and > that it's therefore best not to trust anything it tells you. > > >> I'm not downplaying the disadvantages and problems, but I still hold >> the view that the striving for generic multiplatform kernel images is >> worth the effort. >> >> ... but I do agree that hard linking the .dtb into firmware, or making >> the .dtb hard to upgrade is the way of madness. >> > > Ah, we're talking at cross purposes a bit then. Yeah, I'm talking > about the situation where the dtb is part of the firmware, or at least > as difficult / inconvenient to update as the firmware. If the dtb is > separate from the kernel, but as easy to update / switch as the > kernel, that is indeed a very nice setup. > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
Another possibility is to pad the DTB with a DESYNC command and the correct pad frame, just in case it cannot be prevented. Steve > -Original Message- > From: Grant Likely [mailto:grant.lik...@secretlab.ca] > Sent: Monday, May 11, 2009 10:30 PM > To: Stephen Neuendorffer > Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org > Subject: Re: device trees. > > On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer > wrote: > >> > OK, so the key question seems to be *when* the bitstream is > > associated > >> > with the > >> > device tree. If at bitstream generation time, you can prepend the > > .dtb > >> > to the bitstream. As long as the dtb doesn't contain the magic > >> > bitstream start code, you can go back and access it later. > >> > > >> You really mean prepend ? I was presuming that things would work > > better > >> if it was appended ? > > > > Yes, actually prepend is simpler because you don't have to know the size > > of the bitstream. > > Everything before the SYNC code in the bitstream is ignored. > > ...In this case, might need to preprocess the .dtb the escape out the > possibility of a sync code appearing. > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, May 12, 2009 at 5:24 PM, David Gibson wrote: > On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote: >> ... but I do agree that hard linking the .dtb into firmware, or making >> the .dtb hard to upgrade is the way of madness. > > Ah, we're talking at cross purposes a bit then. Yeah, I'm talking > about the situation where the dtb is part of the firmware, or at least > as difficult / inconvenient to update as the firmware. If the dtb is > separate from the kernel, but as easy to update / switch as the > kernel, that is indeed a very nice setup. :-D g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote: > On Mon, May 11, 2009 at 7:12 PM, David Gibson > wrote: > > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: > >> In other words; having your bootloader support FDT is preferred, but > >> not required. > > > > I wouldn't even go so far as to say it's preferred. IMO, people have > > gone a bit prematurely keen on moving devtree handling into the > > firmware. Putting it in the firmware has a number of advantages, but > > it also has a number of non-trivial disadvantages. > > I disagree. The more I work with it, the more I appreciate the > advantage of decoupling the kernel image file from the hardware > description. It is valuable being able to build a single image file > that boots on a wide range of boards because the device tree passed in > by firmware. Heh, where all my work in the embedded space has led me to more and more appreciate the fact that firmware is almost invariably crap, and that it's therefore best not to trust anything it tells you. > I'm not downplaying the disadvantages and problems, but I still hold > the view that the striving for generic multiplatform kernel images is > worth the effort. > > ... but I do agree that hard linking the .dtb into firmware, or making > the .dtb hard to upgrade is the way of madness. Ah, we're talking at cross purposes a bit then. Yeah, I'm talking about the situation where the dtb is part of the firmware, or at least as difficult / inconvenient to update as the firmware. If the dtb is separate from the kernel, but as easy to update / switch as the kernel, that is indeed a very nice setup. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 06:04:16PM -0600, Grant Likely wrote: > > David: If you would like to have a discussion regarding particular > > design tradeoffs, I'd be happy to, but since I doubt there is anyone on > > this list who is interested in the vagaries of FPGA configuration > > methods, I suggest we have the discussion privately. > > I disagree. There are lots of lurkers on this list who care about > virtex stuff, not to mention non-lurkers like me. :-) I would at > least like to be a fly on the wall of any such discussion. +1 :) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer wrote: >> > OK, so the key question seems to be *when* the bitstream is > associated >> > with the >> > device tree. If at bitstream generation time, you can prepend the > .dtb >> > to the bitstream. As long as the dtb doesn't contain the magic >> > bitstream start code, you can go back and access it later. >> > >> You really mean prepend ? I was presuming that things would work > better >> if it was appended ? > > Yes, actually prepend is simpler because you don't have to know the size > of the bitstream. > Everything before the SYNC code in the bitstream is ignored. ...In this case, might need to preprocess the .dtb the escape out the possibility of a sync code appearing. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 7:12 PM, David Gibson wrote: > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: >> In other words; having your bootloader support FDT is preferred, but >> not required. > > I wouldn't even go so far as to say it's preferred. IMO, people have > gone a bit prematurely keen on moving devtree handling into the > firmware. Putting it in the firmware has a number of advantages, but > it also has a number of non-trivial disadvantages. I disagree. The more I work with it, the more I appreciate the advantage of decoupling the kernel image file from the hardware description. It is valuable being able to build a single image file that boots on a wide range of boards because the device tree passed in by firmware. I'm not downplaying the disadvantages and problems, but I still hold the view that the striving for generic multiplatform kernel images is worth the effort. ... but I do agree that hard linking the .dtb into firmware, or making the .dtb hard to upgrade is the way of madness. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
> -Original Message- > From: David H. Lynch Jr. [mailto:dh...@dlasys.net] > Sent: Monday, May 11, 2009 7:35 PM > To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org > Subject: Re: device trees. > > Stephen Neuendorffer wrote: > > > >> Many of our systems are LX systems but currently we are not running > >> Linux on them. > >> > > > > Master SelectMap, I presume? What FPGA family? > > Does the FPGA have access to the CPLD after boot, other than through the > > configuration pins? > > > > > One of the skills I have not had time to develop - because Pico has > plenty of qualified firmware/hardware people and not enough OS people, > is fluency with Xilinx tools. > > FPGA Families - currently Spartan, virtex 4 and virtex 5. > LX & FX, in all kinds of sizes. So that as an example our E14 (1st > generation cardbus) comes in FX40's and FX60's and LX## ... > > I am presuming that is what you mean. > > Access to the hardware on the cards can be weird. As our cards are often > hosted, that means the firmware is often setup to allow host and target > access to hardware. In others only the host or only the target does. > > What I know is that if I send a few magic values to the CPLD and then > start reading the bit file out of flash, I will trigger the CPLD to > reload the FPGA from the bitfile I selected. > > > > > > > OK, so that means the boot monitor can open sector 2 of the flash and > > read info, right? (Or wherever else the bitstream is coming from. > On powerup the CPLD boots from sector 2. IF it is rebooted by the host > or target it can reboot from any flash sector. > In the "normal" setup the target has indirect access to the entire NOR > flash. > > > Can > > the CPLD store one 32 bit int that the new bitstream can come back and > > read later? > > > Off the top of my head I do nto know, but if you are saying I need to > find someway of preserving a 32bit value through rebooting the FPGA I > can find a way to do it. > > > > > > > OK, so the key question seems to be *when* the bitstream is associated > > with the > > device tree. If at bitstream generation time, you can prepend the .dtb > > to the bitstream. As long as the dtb doesn't contain the magic > > bitstream start code, you can go back and access it later. > > > You really mean prepend ? I was presuming that things would work better > if it was appended ? Yes, actually prepend is simpler because you don't have to know the size of the bitstream. Everything before the SYNC code in the bitstream is ignored. For instance, this is the start of a spartan 3ADSP bitstream: 00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 0b |.a..| 0010 73 79 73 74 65 6d 2e 6e 63 64 00 62 00 0e 33 73 |system.ncd.b..3s| 0020 64 33 34 30 30 61 66 67 36 37 36 00 63 00 0b 32 |d3400afg676.c..2| 0030 30 30 39 2f 20 35 2f 20 31 00 64 00 09 31 34 3a |009/ 5/ 1.d..14:| 0040 34 38 3a 32 31 00 65 00 16 59 d4 ff ff ff ff ff |48:21.e..Y..| 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || 0060 ff ff ff ff ff ff ff ff ff ff ff aa 99 30 a1 00 |.0..| 'FF FF AA 99' is the Spartan 3 DUMMY code/SYNC code combination, everything before that is discarded by the FPGA. > Regardless, I have the means to know exactly what bit file is currently > loaded, and I can then look it up in the NOR Flash. Yes, so as long as when the bitstream is loaded, it can figure out where in the flash it was loaded *from* and then go back there and get the dtb, then that should work. This would make it difficult to do certain things (like loading a useful bitstream from anywhere OTHER than flash), but if you can make that restriction, then it should work. I can think of several ways of doing this, the simple of which is to have your bootloader go to the CPLD after it has loaded to figure out where the bitstream came from. > I can glue the dtb and the bit file together in anyway that will make > xilinx happy. Fortunately, you don't have to keep Xilinx happy, only the FPGA.. :) > If it is prepended the only case I care about is the power up sequence, > because that must start loading the bit file at sector 2. > We do cope with the scenario where the sector 2 bit file is completely > screwed up. The CPLD STARTS trying to load at sector 2, but it will > continue to the end of flash until something actually loads. The dead > card scenario is sector 2 is the start of a valid but non-functional bit > file. > At that point you must load a bit image using JTAG and then write a good > bit file to flash. > > Alright lets say I prepend.
Re: device trees.
Stephen Neuendorffer wrote: > >> Many of our systems are LX systems but currently we are not running >> Linux on them. >> > > Master SelectMap, I presume? What FPGA family? > Does the FPGA have access to the CPLD after boot, other than through the > configuration pins? > > One of the skills I have not had time to develop - because Pico has plenty of qualified firmware/hardware people and not enough OS people, is fluency with Xilinx tools. FPGA Families - currently Spartan, virtex 4 and virtex 5. LX & FX, in all kinds of sizes. So that as an example our E14 (1st generation cardbus) comes in FX40's and FX60's and LX## ... I am presuming that is what you mean. Access to the hardware on the cards can be weird. As our cards are often hosted, that means the firmware is often setup to allow host and target access to hardware. In others only the host or only the target does. What I know is that if I send a few magic values to the CPLD and then start reading the bit file out of flash, I will trigger the CPLD to reload the FPGA from the bitfile I selected. > OK, so that means the boot monitor can open sector 2 of the flash and > read info, right? (Or wherever else the bitstream is coming from. On powerup the CPLD boots from sector 2. IF it is rebooted by the host or target it can reboot from any flash sector. In the "normal" setup the target has indirect access to the entire NOR flash. > Can > the CPLD store one 32 bit int that the new bitstream can come back and > read later? > Off the top of my head I do nto know, but if you are saying I need to find someway of preserving a 32bit value through rebooting the FPGA I can find a way to do it. > > > OK, so the key question seems to be *when* the bitstream is associated > with the > device tree. If at bitstream generation time, you can prepend the .dtb > to the bitstream. As long as the dtb doesn't contain the magic > bitstream start code, you can go back and access it later. > You really mean prepend ? I was presuming that things would work better if it was appended ? Regardless, I have the means to know exactly what bit file is currently loaded, and I can then look it up in the NOR Flash. I can glue the dtb and the bit file together in anyway that will make xilinx happy. If it is prepended the only case I care about is the power up sequence, because that must start loading the bit file at sector 2. We do cope with the scenario where the sector 2 bit file is completely screwed up. The CPLD STARTS trying to load at sector 2, but it will continue to the end of flash until something actually loads. The dead card scenario is sector 2 is the start of a valid but non-functional bit file. At that point you must load a bit image using JTAG and then write a good bit file to flash. Alright lets say I prepend. I am loosely familar with the magic start code. Does that need to be aligned in anyway ? And just for the sake of argument lets say I append the dtb. Do I need some padding between the bitfile and the dtb to keep the FPGA from loading the dtb as firmware ? Is there a magic stop sequence ? Is the load terminated by the length of the bits. > Is this sounding reasonable? > > I am sure there is something I can work with here. Thanks. > Steve > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Tue, 2009-05-12 at 08:56 +1000, David Gibson wrote: > On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote: > > Grant Likely wrote: > > >>Anyway, all I was looking for was a leg up on figuring out how to do > > >> what I want with them. Rather than starting from scratch. > > >>I am not looking to be convinced that I am approaching this all wrong. > > >>If you are happy with what you have - great. I am not. > > >>While I was not looking to restart a great debate over device trees > > >> - I do not actually think they are a bad idea. > > >> > > > > > > I still don't understand what you're worried about starting an arguing > > > about. Pretty much any of the PowerPC maintainers can point at warts > > > and problems in the current handling of device trees. I'm not > > > particularly happy with simpleImage (and I wrote it), but it takes > > > time and effort to write something more capable. > > > > > I was not trying to start an argument, my initial question was > > > >"Is there an example somewhere that shows building a device tree on the > > fly ?" > > > >The responses have questioned why I want to do that rather than how can > > I do that. > >I was not actually seeking a debate over the merit of device trees, or > > u-boot, or libdft, or > > Probably the closest things to suitable examples here are > arch/powerpc/kernel/prom_init.c, which builds the dtb from the "live" > OF device tree. At the moment that's a bit of a special case, but > there's no inherent reason that logic couldn't be moved to the > bootwrapper. > > The other, not in the main tree, is Paul's restodt, which builds a > device tree from old-style PReP residual information. I recall it was > sent to the list as a userspace program (we were gathering information > on the sorts of PReP out there). I think Paul made at least a first > cut at fusing it into the bootwrapper, but I don't know if that ever > got sent out to the list. There's also the iseries code, which is not pretty, but shows a very minimal example of constructing a device tree on the fly, some of it based on static config and some that's not. The routines for constructing DT nodes and properties is about 110 lines, and most of that is brackets. arch/powerpc/platforms/iseries/dt.c cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote: > On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. wrote: > > Grant Likely wrote: > >> > >> What do you mean by "one size fits all solution?" > >> > >> The kernel doesn't care where the device tree comes from. All it > >> cares about is that by the time the kernel is started the device tree > >> must be fully formed and populated. It can be completely pre-canned > >> (like simpleImage), it can be modified by firmware (like u-boot), or > >> it can be generated from scratch (like with real OpenFirmware). There > >> is lots of flexibility on how to handle it. > >> > >> > > First device trees are now the ONLY means of passing information to the > > kernel. > > By definition that means it is a one size fits all solution. > > While there is nothing inherently wrong with that, solutions intended to > > meet all circumstances need to be > > simple, powerful, and flexible. They need to work well 100% of the time > > not 98%. > > > > Not only is the device tree expected to pass static hardware > > configuration information, but it is the sole means of passing anything. > > As an example Command lines are to be in the device tree. > > Everything is supposed to be in the device tree, whether that > > information is static or dynamic, whether it is hardware information, > > or user choices. > > It is the sole means of passing anything *to the kernel*. You can > pass whatever you like to the bootwrapper. :-) > > > That means that whether you are in a Sun or Apple Desktop or a > > system with the no flash and barely enough resources to run Linux, > > you still may have to manipulate the device tree. > > ...or if you really are constrained, then define a format for the data > you want to pass, pass it to the bootwrapper along with the device > tree, and use the bootwrapper (which already has libfdt) to update the > device tree. cuImage targets do this to support older u-boots which > don't understand device trees. You are not forced to put device tree > support in your firmware. > > In other words; having your bootloader support FDT is preferred, but > not required. I wouldn't even go so far as to say it's preferred. IMO, people have gone a bit prematurely keen on moving devtree handling into the firmware. Putting it in the firmware has a number of advantages, but it also has a number of non-trivial disadvantages. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 12:54:58PM -0400, David H. Lynch Jr. wrote: > Timur Tabi wrote: > > On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. > > wrote: > > > > So all you need to do is have your boot loader create a device tree > > from scratch. If you're using U-Boot, then you can already do this by > > making the appropriate libfdt calls. Otherwise, you should probably > > add libfdt to your boot loader. > > > As I mentioned before, we do nto use u-boot. I am not looking to > start a debate on it either, but it does not meet a number of our needs, > and would require significant architectural changes to do so. The > difference between it and devicetrees is that u-boot is avaiable to us > if we want, I did port u-boot to our hardware at one point and it did > everything it promised, but u-boot is optional, device trees are not. > I do not have to re-architect u-boot to fit into 16k of bram, or > load bit files or . > If I want to move past 2.6.26 I have to not only use device trees > but actually make them work in a way that will function as we need with > our systems. > It is likely I will use libdft as a starting point, but I can not > see it as more than a short term solution. libdft is orders of magnitude > large than our entire monitor, and it is a toolkit rather than the whole > solution. I'm very willing to make changes to libfdt, if it helps make it more useful to you without breaking it for other people. I'm a little horrified at the size of libfdt, and a bit baffled as to why it's ending up that large. From some initial poking around, it looks like -fPIC inflates the code size a *lot* (~3x on x86, which I know is not what we're dealing with here, but was the easiest for a quick test). So if you don't need that in your context, that could save a heap. The separation into separate .o files is also deliberate, so that portions you don't use can be omitted. I have considered breaking it up into many more .c files, so that you can omit individual not-needed functions. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote: > Grant Likely wrote: > > > > What do you mean by "one size fits all solution?" > > > > The kernel doesn't care where the device tree comes from. All it > > cares about is that by the time the kernel is started the device tree > > must be fully formed and populated. It can be completely pre-canned > > (like simpleImage), it can be modified by firmware (like u-boot), or > > it can be generated from scratch (like with real OpenFirmware). There > > is lots of flexibility on how to handle it. > First device trees are now the ONLY means of passing information to > the kernel. That's not really true in practice. Yes, the device tree is the only way to pass information to the kernel proper, but having a bootwrapper, built along with the kernel, which translates information in some other form into a device tree is a perfectly reasonable solution for the right circumstances. > By definition that means it is a one size fits all > solution. While there is nothing inherently wrong with that, > solutions intended to meet all circumstances need to be simple, > powerful, and flexible. They need to work well 100% of the time not > 98%. > > Not only is the device tree expected to pass static hardware > configuration information, but it is the sole means of passing anything. > As an example Command lines are to be in the device tree. > Everything is supposed to be in the device tree, whether that > information is static or dynamic, whether it is hardware information, > or user choices. > > That means that whether you are in a Sun or Apple Desktop or a > system with the no flash and barely enough resources to run Linux, > you still may have to manipulate the device tree. Compared to running Linux, manipulating the device tree is a complete triviality, so I don't see what the problem is here. [snip] > Welding the bit file to the dtb might solve 75% of my issues, > And it probably would get me to the point where I could move > forward and live with > the remaining issues untile I was inspired to solve them. > but it does not solve everything. It is increasingly clear to me > that I am going to have to > manipulate device trees. That's probably true. But you don't necessarily have to do it within your BRAM firmware - you can do it inside the Linux bootwrapper. > >>Anyway, all I was looking for was a leg up on figuring out how to do > >> what I want with them. Rather than starting from scratch. > >>I am not looking to be convinced that I am approaching this all wrong. > >>If you are happy with what you have - great. I am not. > >>While I was not looking to restart a great debate over device trees > >> - I do not actually think they are a bad idea. > >> > > > > I still don't understand what you're worried about starting an arguing > > about. Pretty much any of the PowerPC maintainers can point at warts > > and problems in the current handling of device trees. I'm not > > particularly happy with simpleImage (and I wrote it), but it takes > > time and effort to write something more capable. > > > I was not trying to start an argument, my initial question was > >"Is there an example somewhere that shows building a device tree on the > fly ?" > >The responses have questioned why I want to do that rather than how can I > do that. >I was not actually seeking a debate over the merit of device trees, or > u-boot, or libdft, or Probably the closest things to suitable examples here are arch/powerpc/kernel/prom_init.c, which builds the dtb from the "live" OF device tree. At the moment that's a bit of a special case, but there's no inherent reason that logic couldn't be moved to the bootwrapper. The other, not in the main tree, is Paul's restodt, which builds a device tree from old-style PReP residual information. I recall it was sent to the list as a userspace program (we were gathering information on the sorts of PReP out there). I think Paul made at least a first cut at fusing it into the bootwrapper, but I don't know if that ever got sent out to the list. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 5:19 PM, Stephen Neuendorffer wrote: > >> >> The best alternative to creating the device tree dynamically > would >> >> be to >> >> append the devicetree to the bitimage in a way the boot loader > could >> >> always find it. >> >> >> > >> > That sounds like a good solution to me. >> > >> I am glad you like it. If Xilinx would like to offer any advice as >> to how to prepend a device tree to the end of a bit file without >> foreclosing any of their future plans or I would be happy to >> look at implementing it. > > There are options here... > > For the benefit of the mailing list: they are tied into how the FPGA > configuration is loaded, and the > particular FPGA family. By far the most portable/generic option is to > simply use an initialized BRAM for this. > > David: If you would like to have a discussion regarding particular > design tradeoffs, I'd be happy to, but since I doubt there is anyone on > this list who is interested in the vagaries of FPGA configuration > methods, I suggest we have the discussion privately. I disagree. There are lots of lurkers on this list who care about virtex stuff, not to mention non-lurkers like me. :-) I would at least like to be a fly on the wall of any such discussion. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
> >>The best alternative to creating the device tree dynamically would > >> be to > >>append the devicetree to the bitimage in a way the boot loader could > >> always find it. > >> > > > > That sounds like a good solution to me. > > > I am glad you like it. If Xilinx would like to offer any advice as > to how to prepend a device tree to the end of a bit file without > foreclosing any of their future plans or I would be happy to > look at implementing it. There are options here... For the benefit of the mailing list: they are tied into how the FPGA configuration is loaded, and the particular FPGA family. By far the most portable/generic option is to simply use an initialized BRAM for this. David: If you would like to have a discussion regarding particular design tradeoffs, I'd be happy to, but since I doubt there is anyone on this list who is interested in the vagaries of FPGA configuration methods, I suggest we have the discussion privately. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. wrote: > Grant Likely wrote: >> >> What do you mean by "one size fits all solution?" >> >> The kernel doesn't care where the device tree comes from. All it >> cares about is that by the time the kernel is started the device tree >> must be fully formed and populated. It can be completely pre-canned >> (like simpleImage), it can be modified by firmware (like u-boot), or >> it can be generated from scratch (like with real OpenFirmware). There >> is lots of flexibility on how to handle it. >> >> > First device trees are now the ONLY means of passing information to the > kernel. > By definition that means it is a one size fits all solution. > While there is nothing inherently wrong with that, solutions intended to > meet all circumstances need to be > simple, powerful, and flexible. They need to work well 100% of the time > not 98%. > > Not only is the device tree expected to pass static hardware > configuration information, but it is the sole means of passing anything. > As an example Command lines are to be in the device tree. > Everything is supposed to be in the device tree, whether that > information is static or dynamic, whether it is hardware information, > or user choices. It is the sole means of passing anything *to the kernel*. You can pass whatever you like to the bootwrapper. :-) > That means that whether you are in a Sun or Apple Desktop or a > system with the no flash and barely enough resources to run Linux, > you still may have to manipulate the device tree. ...or if you really are constrained, then define a format for the data you want to pass, pass it to the bootwrapper along with the device tree, and use the bootwrapper (which already has libfdt) to update the device tree. cuImage targets do this to support older u-boots which don't understand device trees. You are not forced to put device tree support in your firmware. In other words; having your bootloader support FDT is preferred, but not required. Word of warning; if you do define your own format, be very very very careful. Otherwise you end up with something subtly broken and not future proof. This is one of the reasons adding FDT support to your firmware is preferred; these issues have already been thought about. > Though I still have an issue. One of the problem with 98% solutions, > is that they result in a chain of work arrounds for > the other 2%. Instead of one case or two cases, you end up with a > dozen cases each handling increasingly tiny slivers. > And it becomes increasingly easy to claim that the problem is with > the slivers not the broad solution. No, it's not. Everything you need to do can be done within the bootwrapper if you so desire, passing data in whatever format you like. > I am not sure what you are saying here ? > By firmware do you mean bootloader ? Or do you mean bitfiles ? Yes, I'm using the terms "firmware" and "bootloader" interchangeably. >> I still don't understand what you're worried about starting an arguing >> about. Pretty much any of the PowerPC maintainers can point at warts >> and problems in the current handling of device trees. I'm not >> particularly happy with simpleImage (and I wrote it), but it takes >> time and effort to write something more capable. >> > I was not trying to start an argument, my initial question was > > "Is there an example somewhere that shows building a device tree on the fly > ?" > > The responses have questioned why I want to do that rather than how can I > do that. > I was not actually seeking a debate over the merit of device trees, or > u-boot, or libdft, or ... but the questions were necessary to understand your problem set. I cannot give good advice without understanding. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, 2009-05-11 at 17:38 -0400, David H. Lynch Jr. wrote: > Not only is the device tree expected to pass static hardware > configuration information, but it is the sole means of passing > anything. > As an example Command lines are to be in the device tree. > Everything is supposed to be in the device tree, whether that > information is static or dynamic, whether it is hardware information, > or user choices. > > That means that whether you are in a Sun or Apple Desktop or a > system with the no flash and barely enough resources to run Linux, > you still may have to manipulate the device tree. To some extend, but the user choice information is well isolated, it's all in /chosen, so it's really only that node that needs to be modified or created from scratch by the bootloader. Thus, your bootloader can pick the right static dtb for a given bitfile, and then just use libfdt to generate the right /chosen node with other informations. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
> > Not pretty, but it does more or less what you're talking about. Would > > need some work to get it going on !pseries obviously. > > Heh, I didn't even know this existed. :-) > > Thinking about this more, it seems to me that the tricky bit would be > figuring out how to drop all references to a node before it is pruned > from the tree. of_platform_devices would probably be the easiest > because the bus could walked before pruning the node, but there are > also references on the i2c, spi and mdio busses that must be dealt > with appropriately. Also, the way userspace manipulates the tree via /proc/ppc64 is quite gross... Some time ago we discussed about moving that to the kernel since the firmware call that gives us the new bits of tree could be done there in a relatively generic way but that's only one option. Maybe it's time to have a proper devicetreefs so one can use standard fs APIs to create nodes & properties though we would need a trick to turn them from "temporary" to "online" and similar for offlining. Maybe with mv from/to a "staging" directory that isn't "live" vs. the kernel. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Grant Likely wrote: > > What do you mean by "one size fits all solution?" > > The kernel doesn't care where the device tree comes from. All it > cares about is that by the time the kernel is started the device tree > must be fully formed and populated. It can be completely pre-canned > (like simpleImage), it can be modified by firmware (like u-boot), or > it can be generated from scratch (like with real OpenFirmware). There > is lots of flexibility on how to handle it. > > First device trees are now the ONLY means of passing information to the kernel. By definition that means it is a one size fits all solution. While there is nothing inherently wrong with that, solutions intended to meet all circumstances need to be simple, powerful, and flexible. They need to work well 100% of the time not 98%. Not only is the device tree expected to pass static hardware configuration information, but it is the sole means of passing anything. As an example Command lines are to be in the device tree. Everything is supposed to be in the device tree, whether that information is static or dynamic, whether it is hardware information, or user choices. That means that whether you are in a Sun or Apple Desktop or a system with the no flash and barely enough resources to run Linux, you still may have to manipulate the device tree. >>The best alternative to creating the device tree dynamically would >> be to >>append the devicetree to the bitimage in a way the boot loader could >> always find it. >> > > That sounds like a good solution to me. > I am glad you like it. If Xilinx would like to offer any advice as to how to prepend a device tree to the end of a bit file without foreclosing any of their future plans or I would be happy to look at implementing it. > As for using up BRAM, a gzipped dtb image is smaller than 2k and it > can be reclaimed for other uses after the kernel has booted. That may > not help your situation, but for my use cases the tradeoff works. > If I recall the minimum increment for BRAM is 16K. I am not trying to claim it is not an answer for anyone, or even most people. Though I still have an issue. One of the problem with 98% solutions, is that they result in a chain of work arrounds for the other 2%. Instead of one case or two cases, you end up with a dozen cases each handling increasingly tiny slivers. And it becomes increasingly easy to claim that the problem is with the slivers not the broad solution. >>Regardless it still makes my point. The problem with devicetrees as >> they are is that they handle probably 98% of all cases well. >>The remaining 2% are a mess. >> > > No it isn't. It is expected that firmware will fixup the device tree > data with board specific values. This is intentional. The device > tree is simply the bearer. It makes no determination about where the > data comes from. > I am not sure what you are saying here ? By firmware do you mean bootloader ? Or do you mean bitfiles ? In large systems like Sun or Apple desktop the OF Device tree need not be static. There is software that may well be larger than the linux kernel. Our "firmware" bootloader is actually stored in the bitfile - 16K of BRAM basically becomes the boot ROM - except that it is bitfile initialized RAM. I guess this is much like you dtb in BRAM. We are not increasing the size of the BRAM, while most of our systems have NOR flash, or ... or , the all don't. Even the amount of DRAM varies, and our code is written not to use DRAM until we have verified that it works. > >>lots of .dtb files lying arround is only a better solution than >> simpleimage. >>I will guarantee that unless they are welded together the wrong >> device tree will get used with the wrong bit file. >> > > I agree. > > >>Inevitably I will make that mistake myself occasionally and waste >> hours or possibly days trying to debug it. >>And if I will do it rarely clients will do it frequently. >> >>In my expereince if you create a situation where confusion can exist >> it will. >> >>It is also my expereince that time spend coding a solution to a >> common client problem is well spent. >>If it takes me a week to work out dynamically creating a device >> tree, that ill likely save many weeks of >>support headaches. >> > > Again, it doesn't sound like you want dynamic *creation* of device > trees. It sounds like you want a reliable way to make sure the > bitstream is welded together with the correct dtb, preferably within > the Xilinx toolchain. > Welding the bit file to the dtb might solve 75% of my issues, And it probably would get me to the point where I could move forward and live with the remaining issues untile I was inspired to solve them. but it does not solve everything. It is increasingly clear to me that I am going to have to manipul
Re: device trees.
On Mon, May 11, 2009 at 10:45 AM, David H. Lynch Jr. wrote: > Grant Likely wrote: >> >>> We are very actively headed in the opposite direction. It is my/our >>> intention to have a single linux executable that works accross >>> everyone of our cards and everyone of our bitfiles. >>> >> >> That is the direction we are already going in. U-Boot supports this. >> In fact, I can build a single kernel image which will boot on all of >> my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot >> running on a Virtex board, I can build a single image which will boot >> all of them if the correct .dtb is passed to it. >> > I was not aware that u-boot was currently doing that, but I was > aware that was possible. > It is the most useful alternative to simple image. > I was not specifically trying to criticize simple image. > My problem is not with specific means of handling device trees. > It is that it is a one size fits all solution, and it is not > sufficiently flexible for that. What do you mean by "one size fits all solution?" The kernel doesn't care where the device tree comes from. All it cares about is that by the time the kernel is started the device tree must be fully formed and populated. It can be completely pre-canned (like simpleImage), it can be modified by firmware (like u-boot), or it can be generated from scratch (like with real OpenFirmware). There is lots of flexibility on how to handle it. >> You *could* generate the device tree dynamically, but I think that is >> a path of diminishing returns considering that generating a .dts at >> the same time as bitstream creation time is cheap and it is small. At >> one time Steven Neuendorffer was playing with a scheme to preload a >> section of BRAM with a gzipped .dtb so that the correct device tree is >> always present. I really liked the idea, and I'd like to try to >> pursue it. >> > I would prefer not to waste bram by filling it with a device tree. > The best alternative to creating the device tree dynamically would > be to > append the devicetree to the bitimage in a way the boot loader could > always find it. That sounds like a good solution to me. As for using up BRAM, a gzipped dtb image is smaller than 2k and it can be reclaimed for other uses after the kernel has booted. That may not help your situation, but for my use cases the tradeoff works. > Regardless it still makes my point. The problem with devicetrees as > they are is that they handle probably 98% of all cases well. > The remaining 2% are a mess. No it isn't. It is expected that firmware will fixup the device tree data with board specific values. This is intentional. The device tree is simply the bearer. It makes no determination about where the data comes from. > lots of .dtb files lying arround is only a better solution than > simpleimage. > I will guarantee that unless they are welded together the wrong > device tree will get used with the wrong bit file. I agree. > Inevitably I will make that mistake myself occasionally and waste > hours or possibly days trying to debug it. > And if I will do it rarely clients will do it frequently. > > In my expereince if you create a situation where confusion can exist > it will. > > It is also my expereince that time spend coding a solution to a > common client problem is well spent. > If it takes me a week to work out dynamically creating a device > tree, that ill likely save many weeks of > support headaches. Again, it doesn't sound like you want dynamic *creation* of device trees. It sounds like you want a reliable way to make sure the bitstream is welded together with the correct dtb, preferably within the Xilinx toolchain. > Even if I do not end up creating the device tree dynamically, I am > likely to end up at a minimum doing some validation on it. > i.e. once the bitfile is loaded scanning the device tree and probing > to ascertain that the hardware that I am supposed to expect > it really present. If you like. > ultimately devicetrees are supposed to be a database not a black box. I don't understand what you mean by this statement. > Anyway, all I was looking for was a leg up on figuring out how to do > what I want with them. Rather than starting from scratch. > I am not looking to be convinced that I am approaching this all wrong. > If you are happy with what you have - great. I am not. > While I was not looking to restart a great debate over device trees > - I do not actually think they are a bad idea. I still don't understand what you're worried about starting an arguing about. Pretty much any of the PowerPC maintainers can point at warts and problems in the current handling of device trees. I'm not particularly happy with simpleImage (and I wrote it), but it takes time and effort to write something more capable. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___
Re: device trees.
Timur Tabi wrote: > On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote: > > So all you need to do is have your boot loader create a device tree > from scratch. If you're using U-Boot, then you can already do this by > making the appropriate libfdt calls. Otherwise, you should probably > add libfdt to your boot loader. > As I mentioned before, we do nto use u-boot. I am not looking to start a debate on it either, but it does not meet a number of our needs, and would require significant architectural changes to do so. The difference between it and devicetrees is that u-boot is avaiable to us if we want, I did port u-boot to our hardware at one point and it did everything it promised, but u-boot is optional, device trees are not. I do not have to re-architect u-boot to fit into 16k of bram, or load bit files or . If I want to move past 2.6.26 I have to not only use device trees but actually make them work in a way that will function as we need with our systems. It is likely I will use libdft as a starting point, but I can not see it as more than a short term solution. libdft is orders of magnitude large than our entire monitor, and it is a toolkit rather than the whole solution. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Grant Likely wrote: > >>We are very actively headed in the opposite direction. It is my/our >> intention to have a single linux executable that works accross >>everyone of our cards and everyone of our bitfiles. >> > > That is the direction we are already going in. U-Boot supports this. > In fact, I can build a single kernel image which will boot on all of > my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot > running on a Virtex board, I can build a single image which will boot > all of them if the correct .dtb is passed to it. > I was not aware that u-boot was currently doing that, but I was aware that was possible. It is the most useful alternative to simple image. I was not specifically trying to criticize simple image. My problem is not with specific means of handling device trees. It is that it is a one size fits all solution, and it is not sufficiently flexible for that. > You *could* generate the device tree dynamically, but I think that is > a path of diminishing returns considering that generating a .dts at > the same time as bitstream creation time is cheap and it is small. At > one time Steven Neuendorffer was playing with a scheme to preload a > section of BRAM with a gzipped .dtb so that the correct device tree is > always present. I really liked the idea, and I'd like to try to > pursue it. > I would prefer not to waste bram by filling it with a device tree. The best alternative to creating the device tree dynamically would be to append the devicetree to the bitimage in a way the boot loader could always find it. But ultimately the problem still exists. Device trees are the ONLY legitimate way to pass information post 2.6.26. That means that if there is a single peice of dynamic information that needs to be passed to linux, at a minimum the device tree must be edited. It is my understanding that u-boot already does some of this to manage command lines, and maybe a few other items. Regardless it still makes my point. The problem with devicetrees as they are is that they handle probably 98% of all cases well. The remaining 2% are a mess. lots of .dtb files lying arround is only a better solution than simpleimage. I will guarantee that unless they are welded together the wrong device tree will get used with the wrong bit file. Inevitably I will make that mistake myself occasionally and waste hours or possibly days trying to debug it. And if I will do it rarely clients will do it frequently. In my expereince if you create a situation where confusion can exist it will. It is also my expereince that time spend coding a solution to a common client problem is well spent. If it takes me a week to work out dynamically creating a device tree, that ill likely save many weeks of support headaches. Even if I do not end up creating the device tree dynamically, I am likely to end up at a minimum doing some validation on it. i.e. once the bitfile is loaded scanning the device tree and probing to ascertain that the hardware that I am supposed to expect it really present. ultimately devicetrees are supposed to be a database not a black box. Anyway, all I was looking for was a leg up on figuring out how to do what I want with them. Rather than starting from scratch. I am not looking to be convinced that I am approaching this all wrong. If you are happy with what you have - great. I am not. While I was not looking to restart a great debate over device trees - I do not actually think they are a bad idea. > g. > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
Stephen Neuendorffer wrote: >> You *could* generate the device tree dynamically, but I think that is >> a path of diminishing returns considering that generating a .dts at >> the same time as bitstream creation time is cheap and it is small. At >> one time Steven Neuendorffer was playing with a scheme to preload a >> section of BRAM with a gzipped .dtb so that the correct device tree is >> always present. I really liked the idea, and I'd like to try to >> pursue it. >> Thanks and I will look at it. But if you want my .02, append the .dtb to the bit file in some fashion that it can easily be located. We already use all the bram we are willing to steal from clients (16k) for our monitor/boot loader. > > In fact, the code to do this should still be floating around > git.xilinx.com, although someone would likely have to bring it up to the > current kernel versions. > My intention was to treat it as two independent configuration options: > > 1) .dtb location is in BRAM > 2) .dtb is passed compressed (regardless of location) > > Steve > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: device trees.
> You *could* generate the device tree dynamically, but I think that is > a path of diminishing returns considering that generating a .dts at > the same time as bitstream creation time is cheap and it is small. At > one time Steven Neuendorffer was playing with a scheme to preload a > section of BRAM with a gzipped .dtb so that the correct device tree is > always present. I really liked the idea, and I'd like to try to > pursue it. In fact, the code to do this should still be floating around git.xilinx.com, although someone would likely have to bring it up to the current kernel versions. My intention was to treat it as two independent configuration options: 1) .dtb location is in BRAM 2) .dtb is passed compressed (regardless of location) Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote: > We are very actively headed in the opposite direction. It is my/our > intention to have a single linux executable that works accross > everyone of our cards and everyone of our bitfiles. This is the same direction that "we" are headed in as well. For a given core, it is more or less possible to generate one kernel that works on any number of SOCs and boards that use that core. The only difference is which device tree it is given. So all you need to do is have your boot loader create a device tree from scratch. If you're using U-Boot, then you can already do this by making the appropriate libfdt calls. Otherwise, you should probably add libfdt to your boot loader. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. wrote: > But partial reconfiguration is not the only way to encounter a > dynamic environment. > A typical pico system has multiple bit files and multiple > executables stored in its flash file system. > Power up and soft resets might each run through a different sequence > of bit files and executables. > > My issue is that post 2.6.26 unless I can dynamically create the > device tree inside our monitor/bootloader > we must at minimum have a different device tree for each bitfile, This is true > or worse if we wrap the device tree into the executable, >a different linux executable for each bit file. As you say, this is undesirable. simpleImage does this, but it it intended for the least common denominator case where there is no firmware support at all available and the kernel needs to be completely contained. simpleImage is not intended to be the ideal. > We are very actively headed in the opposite direction. It is my/our > intention to have a single linux executable that works accross > everyone of our cards and everyone of our bitfiles. That is the direction we are already going in. U-Boot supports this. In fact, I can build a single kernel image which will boot on all of my MPC5200 boards, and my MPC83xx boards. Similarly, if I have u-boot running on a Virtex board, I can build a single image which will boot all of them if the correct .dtb is passed to it. You *could* generate the device tree dynamically, but I think that is a path of diminishing returns considering that generating a .dts at the same time as bitstream creation time is cheap and it is small. At one time Steven Neuendorffer was playing with a scheme to preload a section of BRAM with a gzipped .dtb so that the correct device tree is always present. I really liked the idea, and I'd like to try to pursue it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
I will have to look at the code referenced below, But my objective is not to address partial reconfiguration at this time. At Pico we have come to the conclusion that as it is currently done partial reconfiguration has extremely limited use. We are actively looking at other techniques as well as different FPGA technology to impliment usable equivalents. But partial reconfiguration is not the only way to encounter a dynamic environment. A typical pico system has multiple bit files and multiple executables stored in its flash file system. Power up and soft resets might each run through a different sequence of bit files and executables. My issue is that post 2.6.26 unless I can dynamically create the device tree inside our monitor/bootloader we must at minimum have a different device tree for each bitfile, or worse if we wrap the device tree into the executable, a different linux executable for each bit file. We are very actively headed in the opposite direction. It is my/our intention to have a single linux executable that works accross everyone of our cards and everyone of our bitfiles. Grant Likely wrote: > On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman > wrote: > >> On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote: >> >>> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. >>> wrote: >>> Is there an example somewhere that shows building a device tree on the fly ? As our products move forward it becomes increasingly clear that static configurations are not going to work. >>> To use device tree with partial reconfiguration would require rework >>> to the device tree infrastructure to prune and graft portions of the >>> device tree. I think it is possible, but it is non-trivial to get >>> working. >>> >> arch/powerpc/platforms/pseries/reconfig.c >> >> Not pretty, but it does more or less what you're talking about. Would >> need some work to get it going on !pseries obviously. >> > > Heh, I didn't even know this existed. :-) > > Thinking about this more, it seems to me that the tricky bit would be > figuring out how to drop all references to a node before it is pruned > from the tree. of_platform_devices would probably be the easiest > because the bus could walked before pruning the node, but there are > also references on the i2c, spi and mdio busses that must be dealt > with appropriately. > > g. > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman wrote: > On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote: >> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. wrote: >> > Is there an example somewhere that shows building a device tree on >> > the fly ? >> > >> > As our products move forward it becomes increasingly clear that >> > static configurations are not going to work. > >> To use device tree with partial reconfiguration would require rework >> to the device tree infrastructure to prune and graft portions of the >> device tree. I think it is possible, but it is non-trivial to get >> working. > > arch/powerpc/platforms/pseries/reconfig.c > > Not pretty, but it does more or less what you're talking about. Would > need some work to get it going on !pseries obviously. Heh, I didn't even know this existed. :-) Thinking about this more, it seems to me that the tricky bit would be figuring out how to drop all references to a node before it is pruned from the tree. of_platform_devices would probably be the easiest because the bus could walked before pruning the node, but there are also references on the i2c, spi and mdio busses that must be dealt with appropriately. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote: > On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. wrote: > >Is there an example somewhere that shows building a device tree on > > the fly ? > > > >As our products move forward it becomes increasingly clear that > > static configurations are not going to work. > To use device tree with partial reconfiguration would require rework > to the device tree infrastructure to prune and graft portions of the > device tree. I think it is possible, but it is non-trivial to get > working. arch/powerpc/platforms/pseries/reconfig.c Not pretty, but it does more or less what you're talking about. Would need some work to get it going on !pseries obviously. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. wrote: > Is there an example somewhere that shows building a device tree on > the fly ? > > As our products move forward it becomes increasingly clear that > static configurations are not going to work. Knowing your history, I assume you're talking about FPGA device trees here. Are you doing partial reconfiguration at runtime? Or are you talking about generating a device tree to match the FPGA design? For the later, there is a tool which works with EDK to generate a device tree based on an EDK design. You can find it on the xilinx git server: http://git.xilinx.com/cgi-bin/gitweb.cgi?p=device-tree.git;a=summary To use device tree with partial reconfiguration would require rework to the device tree infrastructure to prune and graft portions of the device tree. I think it is possible, but it is non-trivial to get working. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
you can look at the source to SLOF or u-boot to see cases of building nodes on the fly. - k On May 8, 2009, at 11:03 AM, David H. Lynch Jr. wrote: Is there an example somewhere that shows building a device tree on the fly ? As our products move forward it becomes increasingly clear that static configurations are not going to work. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device trees.
On Fri, May 8, 2009 at 11:03 AM, David H. Lynch Jr. wrote: > Is there an example somewhere that shows building a device tree on > the fly ? A whole device tree? I don't think so. U-Boot does manipulate quite a few properties, but it assume that the DTS lists all the devices. Remember, one of the primary purposes of the DTS is to list devices that cannot be probed. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On Mon, Oct 22, 2007 at 08:07:14AM -0500, Timur Tabi wrote: > Either you do it at driver __init time, or via a probe. The probe > actually occurs at __init time, anyway, so they're kinda the same thing. > The only thing the probe gets you is that you're called multiple times > for each instance of a node in the tree. It also means that you're *not* called if there's no node in the tree at all -- which I believe was Jon's point about being platform specific. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Jon Smirl <[EMAIL PROTECTED]> wrote: > I have received conflicting opinions as to whether a codec hooked to > an ac97 bus should get a chip specific codec entry in the device tree. > Without the codec specific entry only generic ac97 features can be > used. The Efika has a STA9766. Looking at the data sheet for the chip > I see that it implements some proprietary functions in addition to the > standard ones. You definitely want the codec node on the control bus. This is analogous to how Ethernet PHYs are handled. The PHY nodes are children of an MDIO node (because that's the control path). The ethernet MAC node contains a phandle to the PHY. In I2S/I2C terms, the CODEC ~= MAC, I2C ~= MDIO and I2S ~= MAC. In AC97 terms this analogy doesn't work because AC97 doesn't separate the control and data interfaces. An AC97 codec is simply a child of an AC97 controller. For the MPC5200; the device tree should reflect the required mode. If the PSC needs to be in AC97 mode, then the device tree should say compatible = "fsl,mpc5200b-psc-ac97". If the PSC needs to be in I2C mode, then it should be compatible = "fsl,mpc5200b-psc-i2s". For the 5200 PSCs, the device node not only reflects the hardware (a PSC core), but also reflects the schematic design (it is wired either as an I2S bus or an AC97 bus). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
It seems to me there are four issues here: 1) How to describe the audio transport controller; 2) How to describe the codecs; 3) How the various parts are connected together in the device tree; 4) How to describe the "layout". >>> How do we want to be consistent with the Efika which uses an AC97 >>> codec that only connects to i2s? >> >> Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S >> device if you do all the interleaving and whatever stuff by hand -- >> but >> then you probably shouldn't call the I2S "host" an I2S anymore, but >> name >> it "ac97" in the device tree, or >> "this-or-that-i2s-controller-hooked-up- >> in-this-particular-crazy-way". You will want to know which driver to >> use for the device, and if it's hooked up in "strange and unforeseen" >> ways you want to know about it. > > I meant an ac97 bus. ac97 is conceptually the same as i2s with the > control signals also routed over it. ac97 and i2s are handled in the > same PSC on the 5200. Okay. On any specific board, there can _only_ be ac97 or _only_ i2s codecs hooked onto the bus; the device node for the PSC should say which it is, either by having different "compatible" entries for the different modes, or by having some device-specific property in there saying which it is. Ideally, the name of the node would be "i2s" resp. "ac97" as well. This handles 1). > I have received conflicting opinions as to whether a codec hooked to > an ac97 bus should get a chip specific codec entry in the device tree. Every codec gets its own device node, and its "compatible" entry describes it uniquely. This is a very basic property of device trees. This handles 2). > Without the codec specific entry only generic ac97 features can be > used. The Efika has a STA9766. Looking at the data sheet for the chip > I see that it implements some proprietary functions in addition to the > standard ones. > > asoc has a generic ac97 driver. Should the ac97 bus be required to > have a entry for the generic ac97 device? It would make loading the > driver much easier. If the kernel driver does _not_ recognise the codec in the device tree, it could use a "generic" ac97 codec driver, if such a thing indeed exists. If on the other hand it knows about the specific codec, it can use a chip- specific driver. AC'97 codecs are addressed over the AC'97 bus, so the codecs should be children of the ac97 bus in the device tree, and have fully qualified names like "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]" etc. I2S codecs that are addressed (== its configuration registers written) over I2C should be children of their I2C bus in the device tree, with fully qualified names like "[EMAIL PROTECTED]"; they should show which I2S bus they sit on, for example by having an "i2s-bus" property (containing the phandle of the i2s bus) in the codec node. This is 3). Now for 4), the layout thing; you could try to describe the layout in the device tree, but that would probably fail; there just is too much variance. If I understand you correctly, you have a platform-specific layout driver; now you need to find a nice way to probe this from the device tree. Maybe you should just look at the properties in the root node of the device tree for this. >> _Please_ don't name busses that are not plain I2S "i2s" in the device >> tree. At best this means you'll need a quirk in the kernel code to >> deal >> with this later. > > the i2s and ac97 drivers for the mpc5200 already exist. I'm using > these preexisting drivers. Sure, but that doesn't mean you cannot fix the way things are probed in those drivers. Bugs are there to fix ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: > I meant an ac97 bus. ac97 is conceptually the same as i2s with the > control signals also routed over it. ac97 and i2s are handled in the > same PSC on the 5200. > > I have received conflicting opinions as to whether a codec hooked to > an ac97 bus should get a chip specific codec entry in the device tree. I think it should. For one thing, ASoC requires a pointer to a structure in the codec device driver so that it knows which functions to call to change volume. What if you have multiple i2s/ac97 devices and multiple codecs? You'll need to know which i2s device is connected to which codec. The only way to distinguish that is by having a node for the codec under the i2s node. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: > Doing it that way will make the kernel specific to the target device. > Currently I can load the same mpc5200 kernel on several different > target devices since the platform specific code is triggered in the > probe machine phase. Maybe I need to take a look at your code, but the fabric driver is, in effect, a platform-specific driver. Its job is to figure out what hardware is on the board, how it's connected, and then initialize and connect the other drivers as appropriate. > I tried making the fabric driver into a platform driver instead of an > openfirmware driver, but the mpc5200 code is not initializing platform > drivers correctly. Yeah, that wouldn't work. Platform drivers are initialized way too early. > I could insert calls into arch/powerpc/platforms/52xx/whatever to load > the specific asoc fabric, but doing that is a mess. There must be a > way to trigger loading of machine specific drivers Either you do it at driver __init time, or via a probe. The probe actually occurs at __init time, anyway, so they're kinda the same thing. The only thing the probe gets you is that you're called multiple times for each instance of a node in the tree. >> Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay >> attention to what they do. > > Those Apple drivers are very similar to asoc drivers. They could > easily be folded into the asoc code. Perhaps, but that's a job for another day (and another developer). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > How do we want to be consistent with the Efika which uses an AC97 > > codec that only connects to i2s? > > Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S > device if you do all the interleaving and whatever stuff by hand -- but > then you probably shouldn't call the I2S "host" an I2S anymore, but name > it "ac97" in the device tree, or "this-or-that-i2s-controller-hooked-up- > in-this-particular-crazy-way". You will want to know which driver to > use for the device, and if it's hooked up in "strange and unforeseen" > ways you want to know about it. I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. asoc has a generic ac97 driver. Should the ac97 bus be required to have a entry for the generic ac97 device? It would make loading the driver much easier. > _Please_ don't name busses that are not plain I2S "i2s" in the device > tree. At best this means you'll need a quirk in the kernel code to deal > with this later. the i2s and ac97 drivers for the mpc5200 already exist. I'm using these preexisting drivers. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
> Fabric driver tells how the generic codec is hooked up on the specific > board. Some of the codecs are extremely flexible and can be hooked up > hundreds of different ways. It is like GPIO pins, they are wired in > however is convenient for the design. Gotcha. *Very* much like GPIOs, indeed. >>> The fabric driver corresponds to the 'layout-id' in the Apple model. >>> It tells how to configure the generic codec driver for the specific >>> configuration needed by the actual platform hardware. >> >> The apple layout-id selects one of several tables with *lots* of info. >> I think you want a subset of that only. > > The fabric/layout-id stuff is platform specific. I mean that Apple's layout-id abstraction is "bigger" than your fabric abstraction seems to be. Not too important a point, anyway. >>> My target hardware has a codec that is linked to both i2s and i2c. >>> How >>> should it be represented? >> >> Since the codec is addressable on i2c, and not on i2s, it should be >> a child node of the i2c bus it sits on; and then you put a property >> in the codec node pointing to the i2s bus node it is connected to. >> Multiple of those (or multiple entries) if it is connected to more >> than one i2s bus. "i2s-parent" might be a good name for such a prop. > > How do we want to be consistent with the Efika which uses an AC97 > codec that only connects to i2s? Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S device if you do all the interleaving and whatever stuff by hand -- but then you probably shouldn't call the I2S "host" an I2S anymore, but name it "ac97" in the device tree, or "this-or-that-i2s-controller-hooked-up- in-this-particular-crazy-way". You will want to know which driver to use for the device, and if it's hooked up in "strange and unforeseen" ways you want to know about it. Maybe the platform code should do this, dunno. _Please_ don't name busses that are not plain I2S "i2s" in the device tree. At best this means you'll need a quirk in the kernel code to deal with this later. So anyway, why is it inconsistent to have an audio codec that is configured over i2c sit on that i2c bus in the device tree as well, and refer to the i2s bus it pumps audio data over; vs. having an ac97 codec that sits on an ac97 bus sit on that ac97 bus in the device tree as well? In both cases, the device is a child of the bus via which it is addressed. The one exceptional case would be a dumb codec that isn't addressable at all; it would be a device tree child of the dumb transport bus (where else could it be put)? > Actually those platform-XXX entries may be the solution I am looking > for. Like Ben already said, no you _do not_ want the platform-do stuff. Trust him on this. Or if you're feeling brave, look at the existing kernel code that handles some of it ;-P Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On Sun, 2007-10-21 at 18:12 -0400, Jon Smirl wrote: > On 10/21/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote: > > > > This is one of the i2s channels on the macio. Dunno why they put > > > > all those platform-XXX entries in here, (most of) these don't > > > > logically belong here. > > > > > > Actually those platform-XXX entries may be the solution I am looking > > > for. I can use the generic i2s driver to load a fabric driver as an > > > ALSA module. > > > > Yuck. > > And your alternative is? > > I can use the DTC to load the I2S and codec drivers. > > How do I get the platform specific fabric driver loaded? There is no > way to load a driver matching on the platform name. platform-do-XXX is unrelated to that. It's a kind of script in a blob that is used to toggle various bits, it's plain ugly, totally powermac specific (the code to handle it is in platform/powermac and I won't make it generic) and so you don't want it... ever. For your problem, an option is to do like apple, and have a "sound" pseudo device which represents the "sound subsystem" of the machine which cn ahave a compatible property and other bits that you can use to match your fabric against, and loads the other bits & pieces. Except that I would put it at the root of the tree. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote: > > > This is one of the i2s channels on the macio. Dunno why they put > > > all those platform-XXX entries in here, (most of) these don't > > > logically belong here. > > > > Actually those platform-XXX entries may be the solution I am looking > > for. I can use the generic i2s driver to load a fabric driver as an > > ALSA module. > > Yuck. And your alternative is? I can use the DTC to load the I2S and codec drivers. How do I get the platform specific fabric driver loaded? There is no way to load a driver matching on the platform name. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote: > > This is one of the i2s channels on the macio. Dunno why they put > > all those platform-XXX entries in here, (most of) these don't > > logically belong here. > > Actually those platform-XXX entries may be the solution I am looking > for. I can use the generic i2s driver to load a fabric driver as an > ALSA module. Yuck. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > I'm working on ALSA ASoC support for a codec chip on my mpc5200 based > > target hardware. > > What is ASoC? asoc = ALSA System on a Chip. It is in sound/soc > > Under ASoC the device drivers for the codec chips are platform > > independent. In the current ASoC model there are three device > > drivers: i2s (or spi, etc), the generic codec, and a platform specific > > 'fabric' driver. Some codecs are linked to both i2c and i2s. > > The i2s driver is simply for data transport, the codec driver does, > well, what codecs do; and what is the fabric driver for? Just to > know which output ports are which, etc.? Fabric driver tells how the generic codec is hooked up on the specific board. Some of the codecs are extremely flexible and can be hooked up hundreds of different ways. It is like GPIO pins, they are wired in however is convenient for the design. > > The fabric driver corresponds to the 'layout-id' in the Apple model. > > It tells how to configure the generic codec driver for the specific > > configuration needed by the actual platform hardware. > > The apple layout-id selects one of several tables with *lots* of info. > I think you want a subset of that only. The fabric/layout-id stuff is platform specific. > > My target hardware has a codec that is linked to both i2s and i2c. How > > should it be represented? > > Since the codec is addressable on i2c, and not on i2s, it should be > a child node of the i2c bus it sits on; and then you put a property > in the codec node pointing to the i2s bus node it is connected to. > Multiple of those (or multiple entries) if it is connected to more > than one i2s bus. "i2s-parent" might be a good name for such a prop. How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? > > Apple has three entries. One for i2s, one for the codec, and one for > > soundchip. What is the soundchip entry, does it correspond to real > > hardware? > > > > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > > PROTECTED]/[EMAIL PROTECTED]: > > This is one of the i2s channels on the macio. Dunno why they put > all those platform-XXX entries in here, (most of) these don't > logically belong here. Actually those platform-XXX entries may be the solution I am looking for. I can use the generic i2s driver to load a fabric driver as an ALSA module. > > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > > PROTECTED]/[EMAIL PROTECTED]/sound: > > The codec. I guess Apple puts this here for their weirdo platform-do > stuff; don't imitate this :-) > > > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > > PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: > > The codec. _Do_ put it here in your tree :-) -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
> I'm working on ALSA ASoC support for a codec chip on my mpc5200 based > target hardware. What is ASoC? > Under ASoC the device drivers for the codec chips are platform > independent. In the current ASoC model there are three device > drivers: i2s (or spi, etc), the generic codec, and a platform specific > 'fabric' driver. Some codecs are linked to both i2c and i2s. The i2s driver is simply for data transport, the codec driver does, well, what codecs do; and what is the fabric driver for? Just to know which output ports are which, etc.? > The fabric driver corresponds to the 'layout-id' in the Apple model. > It tells how to configure the generic codec driver for the specific > configuration needed by the actual platform hardware. The apple layout-id selects one of several tables with *lots* of info. I think you want a subset of that only. > My target hardware has a codec that is linked to both i2s and i2c. How > should it be represented? Since the codec is addressable on i2c, and not on i2s, it should be a child node of the i2c bus it sits on; and then you put a property in the codec node pointing to the i2s bus node it is connected to. Multiple of those (or multiple entries) if it is connected to more than one i2s bus. "i2s-parent" might be a good name for such a prop. > Apple has three entries. One for i2s, one for the codec, and one for > soundchip. What is the soundchip entry, does it correspond to real > hardware? > > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > PROTECTED]/[EMAIL PROTECTED]: This is one of the i2s channels on the macio. Dunno why they put all those platform-XXX entries in here, (most of) these don't logically belong here. > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > PROTECTED]/[EMAIL PROTECTED]/sound: The codec. I guess Apple puts this here for their weirdo platform-do stuff; don't imitate this :-) > /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: The codec. _Do_ put it here in your tree :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Timur Tabi <[EMAIL PROTECTED]> wrote: > > For development purposes I'm using an Efika as a target platform. It > > is easy enough to load the i2s driver using the device tree. I can add > > entries to the i2s node to trigger loading of the generic sta9766 > > codec driver. How do I trigger loading the Efika specific fabric > > driver? > > You don't need a device tree entry to trigger loading a driver. You can just > load the driver and initialize it in its __init function. > > However, in this case, you might want to do what I'm doing -- putting a probe > function in the fabric driver for the i2s device (which gets its own node > under the SOC node), and then in that probe function search for all the other > nodes that you need. Doing it that way will make the kernel specific to the target device. Currently I can load the same mpc5200 kernel on several different target devices since the platform specific code is triggered in the probe machine phase. I tried making the fabric driver into a platform driver instead of an openfirmware driver, but the mpc5200 code is not initializing platform drivers correctly. I could insert calls into arch/powerpc/platforms/52xx/whatever to load the specific asoc fabric, but doing that is a mess. There must be a way to trigger loading of machine specific drivers > Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay > attention to what they do. Those Apple drivers are very similar to asoc drivers. They could easily be folded into the asoc code. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: > I'm working on ALSA ASoC support for a codec chip on my mpc5200 based > target hardware. How should the codec be represented in the device > tree? I'm also working on an ASoC driver, but for the 8610. I have a similar problem. > Under ASoC the device drivers for the codec chips are platform > independent. In the current ASoC model there are three device > drivers: i2s (or spi, etc), the generic codec, and a platform specific > 'fabric' driver. Some codecs are linked to both i2c and i2s. Annoying, isn't it? :-) You can use phandles to cross-reference nodes. I suggest putting the codec node under the i2s node (and containing I2S-specific information), and then putting another codec node under the i2c node (this is a new layout proposed by Scott Wood), and use a phandle to let the i2s-codec node point to the i2c-codec node. > The fabric driver corresponds to the 'layout-id' in the Apple model. > It tells how to configure the generic codec driver for the specific > configuration needed by the actual platform hardware. > > For development purposes I'm using an Efika as a target platform. It > is easy enough to load the i2s driver using the device tree. I can add > entries to the i2s node to trigger loading of the generic sta9766 > codec driver. How do I trigger loading the Efika specific fabric > driver? You don't need a device tree entry to trigger loading a driver. You can just load the driver and initialize it in its __init function. However, in this case, you might want to do what I'm doing -- putting a probe function in the fabric driver for the i2s device (which gets its own node under the SOC node), and then in that probe function search for all the other nodes that you need. > My target hardware has a codec that is linked to both i2s and i2c. How > should it be represented? > > Apple has three entries. One for i2s, one for the codec, and one for > soundchip. What is the soundchip entry, does it correspond to real > hardware? Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay attention to what they do. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
