device trees.

device trees.

[David H. Lynch Jr.]

    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 	       dhlii@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

Re: device trees.

[Timur Tabi]

On Fri, May 8, 2009 at 11:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
> =A0 =A0Is 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.

--=20
Timur Tabi
Linux kernel developer at Freescale

Re: device trees.

[Kumar Gala]

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 	       dhlii@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
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: device trees.

[Grant Likely]

On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
> =A0 =A0Is there an example somewhere that shows building a device tree on
> the fly ?
>
> =A0 =A0As 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=3Ddevice-tree.git;a=3Dsummary

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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

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. <dhlii@dlasys.net> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: device trees.

[Grant Likely]

On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman
<michael@ellerman.id.au> 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. <dhlii@dlasys.net> w=
rote:
>> > =A0 =A0Is there an example somewhere that shows building a device tree=
 on
>> > the fly ?
>> >
>> > =A0 =A0As 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. =A0I 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[David H. Lynch Jr.]

    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
> <michael@ellerman.id.au> 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. <dhlii@dlasys.net> 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 	       dhlii@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

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. <dhlii@dlasys.net> wro=
te:
> =A0 =A0But partial reconfiguration is not the only way to encounter a
> dynamic environment.
> =A0 =A0A typical pico system has multiple bit files and multiple
> executables stored in its flash file system.
> =A0 =A0Power up and soft resets might each run through a different sequen=
ce
> of bit files and executables.
>
> =A0 =A0My issue is that post 2.6.26 unless I can dynamically create the
> device tree inside our monitor/bootloader
> =A0 =A0we 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.

> =A0 =A0We are very actively headed in the opposite direction. It is my/ou=
r
> intention to have a single linux executable that works accross
> =A0 =A0everyone 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[Timur Tabi]

On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
> =A0 =A0We are very actively headed in the opposite direction. It is my/ou=
r
> intention to have a single linux executable that works accross
> =A0 =A0everyone 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.

--=20
Timur Tabi
Linux kernel developer at Freescale

RE: device trees.

[Stephen Neuendorffer]

> 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 r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: device trees.

[David H. Lynch Jr.]

Timur Tabi wrote:
> On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. <dhlii@dlasys.net> 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 	       dhlii@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

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 10:45 AM, David H. Lynch Jr. <dhlii@dlasys.net> wro=
te:
> Grant Likely wrote:
>>
>>> =A0 =A0We are very actively headed in the opposite direction. It is my/=
our
>>> intention to have a single linux executable that works accross
>>> =A0 =A0everyone of our cards and everyone of our bitfiles.
>>>
>>
>> That is the direction we are already going in. =A0U-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. =A0Similarly, 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.
>>
> =A0 =A0I was not aware that u-boot was currently doing that, but I was
> aware that was possible.
> =A0 =A0It is the most useful alternative to simple image.
> =A0 =A0I was not specifically trying to criticize simple image.
> =A0 =A0My problem is not with specific means of handling device trees.
> =A0 =A0It 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. =A0At
>> 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. =A0I really liked the idea, and I'd like to try to
>> pursue it.
>>
> =A0 =A0I would prefer not to waste bram by filling it with a device tree.
> =A0 =A0The best alternative to creating the device tree dynamically would
> be to
> =A0 =A0append the devicetree to the bitimage in a way the boot loader cou=
ld
> 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.

> =A0 =A0Regardless it still makes my point. =A0The problem with devicetree=
s as
> they are is that they handle probably 98% of all cases well.
> =A0 =A0The 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.

> =A0 =A0lots of .dtb files lying arround is only a better solution than
> simpleimage.
> =A0 =A0I will guarantee that unless they are welded together the wrong
> device tree will get used with the wrong bit file.

I agree.

> =A0 =A0Inevitably I will make that mistake myself occasionally and waste
> hours or possibly days trying to debug it.
> =A0 =A0And if I will do it rarely clients will do it frequently.
>
> =A0 =A0In my expereince if you create a situation where confusion can exi=
st
> it will.
>
> =A0 =A0It is also my expereince that time spend coding a solution to a
> common client problem is well spent.
> =A0 =A0If it takes me a week to work out dynamically creating a device
> tree, that ill likely save many weeks of
> =A0 =A0support 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.

> =A0 =A0Even 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.
> =A0 =A0i.e. once the bitfile is loaded scanning the device tree and probi=
ng
> to ascertain that the hardware that I am supposed to expect
> =A0 =A0it really present.

If you like.

> =A0 =A0ultimately devicetrees are supposed to be a database not a black b=
ox.

I don't understand what you mean by this statement.

> =A0 =A0Anyway, 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.
> =A0 =A0I am not looking to be convinced that I am approaching this all wr=
ong.
> =A0 =A0If you are happy with what you have - great. I am not.
> =A0 =A0While I was not looking to restart a great debate over device tree=
s
> - 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[David H. Lynch Jr.]

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
    manipulate device trees.



>   
>>    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.
>   
    Right now for embedded systems device trees are a black box not a
database.
    You get them from EDK and pass them on to linux.
    Only Linux and the EDK understand and manipulate them.
    I gather u-boot is  twiddling at the fringes.

>   
>>    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 .... 

   







-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@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

Re: device trees.

[Benjamin Herrenschmidt]

> > 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.
 

Re: device trees.

[Benjamin Herrenschmidt]

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.

Re: device trees.

[David Gibson]

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

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
> Grant Likely wrote:
>>
>> What do you mean by "one size fits all solution?"
>>
>> The kernel doesn't care where the device tree comes from. =A0All it
>> cares about is that by the time the kernel is started the device tree
>> must be fully formed and populated. =A0It 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). =A0There
>> is lots of flexibility on how to handle it.
>>
>>
> First device trees are now the ONLY means of =A0passing information to th=
e
> 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.  :-)

> =A0 =A0That 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.

> =A0 =A0Though I still have an issue. One of the problem with 98% solution=
s,
> is that they result in a chain of work arrounds for
> =A0 =A0the other 2%. Instead of one case or two cases, you end up with a
> dozen cases each handling increasingly tiny slivers.
> =A0 =A0And 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.

> =A0 =A0I am not sure what you are saying here ?
> =A0 =A0By 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. =A0Pretty much any of the PowerPC maintainers can point at warts
>> and problems in the current handling of device trees. =A0I'm not
>> particularly happy with simpleImage (and I wrote it), but it takes
>> time and effort to write something more capable.
>>
> =A0 =A0I was not trying to start an argument, my initial question was
>
> =A0 "Is there an example somewhere that shows building a device tree on t=
he fly ?"
>
> =A0 The responses have questioned why I want to do that rather than how c=
an I do that.
> =A0 I was not actually seeking a debate over the merit of device trees, o=
r u-boot, or libdft, or ....

... but the questions were necessary to understand your problem set.
I cannot give good advice without understanding.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: device trees.

[Stephen Neuendorffer]

> >>    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 r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: device trees.

[David Gibson]

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. <dhlii@dlasys.net> 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

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 5:19 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>> >> =A0 =A0The best alternative to creating the device tree dynamically
> would
>> >> be to
>> >> =A0 =A0append the devicetree to the bitimage in a way the boot loader
> could
>> >> always find it.
>> >>
>> >
>> > That sounds like a good solution to me.
>> >
>> =A0 =A0 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
>> =A0 =A0 foreclosing any of their future plans or .... I would be happy t=
o
>> 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. =A0By 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[David Gibson]

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. <dhlii@dlasys.net> 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

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: device trees.

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: device trees.

[Stephen Neuendorffer]

> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@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:

00000000  00 09 0f f0 0f f0 0f f0  0f f0 00 00 01 61 00 0b
|.............a..|
00000010  73 79 73 74 65 6d 2e 6e  63 64 00 62 00 0e 33 73
|system.ncd.b..3s|
00000020  64 33 34 30 30 61 66 67  36 37 36 00 63 00 0b 32
|d3400afg676.c..2|
00000030  30 30 39 2f 20 35 2f 20  31 00 64 00 09 31 34 3a  |009/ 5/
1.d..14:|
00000040  34 38 3a 32 31 00 65 00  16 59 d4 ff ff ff ff ff
|48:21.e..Y......|
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
|................|
00000060  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. I am loosely familar with the magic start
> code. Does that need to be aligned in anyway ?

My understanding is that alignment does matter somewhat if you are using
SelectMap32, so if this is what you are doing, it's probably best to
preserve the existing alignment, padding the dtb to a number of words
divisible by 4.  If you're using serial configuration modes, or
selectmap8, then it doesn't matter.

> 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.

The bitstream ends with a DESYNC code, followed by a pad of frame data.
After that, everything is ignored until the next SYNC code.  BTW, all of
this is documented in the various configuration user guides.

I'll add that if you are doing V4 and V5 only and don't care about S3,
then there is another mechanism which avoids 'knowing where you loaded
the bitstream from'.  This relies on the USR_ACCESS_VIRTEX4 and
USER_ACCESS_VIRTEX5 primitives to pass further configuration information
to the FPGA design from the configuration source.  You could use this to
append the dtb to the bitstream and to copy it into external memory
using a little bit of FPGA logic, and presumably, the processor.
However, this mechanism is not available on S3.

Steve

This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 7:12 PM, David Gibson
<david@gibson.dropbear.id.au> 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. =A0IMO, people have
> gone a bit prematurely keen on moving devtree handling into the
> firmware. =A0Putting 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[Grant Likely]

On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>> > OK, so the key question seems to be *when* the bitstream is
> associated
>> > with the
>> > device tree. =A0If at bitstream generation time, you can prepend the
> .dtb
>> > to the bitstream. =A0As 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

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/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: device trees.

[David Gibson]

On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 7:12 PM, David Gibson
> <david@gibson.dropbear.id.au> 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

Re: device trees.

[Grant Likely]

On Tue, May 12, 2009 at 5:24 PM, David Gibson
<david@gibson.dropbear.id.au> 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. =A0Yeah, 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. =A0If 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: device trees.

[Stephen Neuendorffer]

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.likely@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
> <stephen.neuendorffer@xilinx.com> wrote:
> >> > OK, so the key question seems to be *when* the bitstream is
> > associated
> >> > with the
> >> > device tree. =A0If at bitstream generation time, you can prepend the=

> > .dtb
> >> > to the bitstream. =A0As 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 siz=
e
> > 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 r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: device trees.

[David H. Lynch Jr.]

    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
>> <david@gibson.dropbear.id.au> 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 	       dhlii@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

Re: device trees.

[Grant Likely]

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. <dhlii@dlasys.net> wrot=
e:
>
>
> =A0 =A0Are we all using the same meaning of firmware ?
>
> =A0 =A0While firmware =3D=3D BIOS is the norm for PC's
> =A0 =A0 atleast in the embedded FPGA space firmware could mean the FPGA
> programing that creates the hardware.
> =A0 =A0For an FPGA based system a dtb generated by the same software that
> created the "firmware" for the FPGA,
> =A0 =A0had better match the "hardware" exactly. =A0Literally welding the
> "firmware" to the dtb makes alot of sense.
>
> =A0 =A0FPGA "firmware" is typically created with hardware programming
> languages like Verilog, and VHDL.
> =A0 =A0It 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
>>> <david@gibson.dropbear.id.au> 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. =A0IMO, people hav=
e
>>>> gone a bit prematurely keen on moving devtree handling into the
>>>> firmware. =A0Putting it in the firmware has a number of advantages, bu=
t
>>>> it also has a number of non-trivial disadvantages.
>>>>
>>> I disagree. =A0The more I work with it, the more I appreciate the
>>> advantage of decoupling the kernel image file from the hardware
>>> description. =A0It 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. =A0Yeah, 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. =A0If 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DLA Systems
> Software Development: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0Embedded Linux
> 717.627.3770 =A0 =A0 =A0 =A0 =A0 dhlii@dlasys.net =A0 =A0 =A0 =A0 =A0 htt=
p://www.dlasys.net
> fax: 1.253.369.9244 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too n=
umerous 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
>
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[David Gibson]

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

Re: device trees.

[David Gibson]

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.likely@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
> > <stephen.neuendorffer@xilinx.com> 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

Re: device trees.

[Grant Likely]

On Tue, May 12, 2009 at 8:36 PM, David Gibson
<david@gibson.dropbear.id.au> 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: =A0I don't see how the bitstream becomes accessible to
> the kernel at runtime. =A0Unless 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: device trees.

[David Gibson]

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

RE: device trees.

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]


>> 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.


[-- Attachment #2: Type: text/html, Size: 2530 bytes --]

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: device trees.

[David Gibson]

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

Re: device trees.

[David H. Lynch Jr.]

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 	       dhlii@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

Re: Device Trees

[Grant Likely]

[cc'ing device tree discuss mailing list]

On Sun, Jul 3, 2011 at 1:20 PM, Omair Eshkenazi
<stimpson-GM2B4lVtXfaYZoqfULhbRA@public.gmane.org> wrote:
> G'day,
>
> The recent Device Trees article on LWN contained the following paragraph:
> "Drivers expecting platform data should check the dev.platform_data pointer
> in the usual way. If there is a non-null value there, the driver has been
> instantiated in the traditional way and device tree does not enter into the
> picture; the platform data should be used in the usual way. If, however, the
> driver has been instantiated from the device tree code, the platform_data
> pointer will be null, indicating that the information must be acquired from
> the device tree directly."
>
> I read that as saying that the in-kernel platform_data takes precedent over
> the device-tree.
>
> Is that correct? Shouldn't it be the other way 'round? After all, the point
> of device trees is to avoid the hard-coded kernel board config.

No, it probably shouldn't be the other way around.  If the kernel has
gone to the trouble of setting the platform_data pointer when it
happens to have a device_node reference, then it probably has a
*really good* reason for doing so and the platform_data pointer
shouldn't be ignored.  It's not desirable, but sometimes it is
unavoidable.

In actual fact, there is more subtlety here than the LWN article
suggests.  It is entirely possible for a device to have both a
platform_data pointer and a device_node reference, and the driver may
very well have to take into account both.  The most common situation
where this will happen is if a driver requires a board specific
callback pointer which cannot be encoded into a device tree.  In which
case, the driver can get most of its configuration from the device
node, but refer to the platform_data to obtain the callback pointers
it requires.  *most of the time* this is not an issue and a driver
only needs to worry about platform_data OR device_node, not both.
However, it is important to be aware of the possibility that a driver
might indeed use both.

g.