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 at dlasys.net> wrote:
>
>
>    Are we all using the same meaning of firmware ?
>
>    While firmware == BIOS is the norm for PC's
>     atleast in the embedded FPGA space firmware could mean the FPGA
> programing that creates the hardware.
>    For an FPGA based system a dtb generated by the same software that
> created the "firmware" for the FPGA,
>    had better match the "hardware" exactly.  Literally welding the
> "firmware" to the dtb makes alot of sense.
>
>    FPGA "firmware" is typically created with hardware programming
> languages like Verilog, and VHDL.
>    It is still "programmed" and like all programming quality varies.
>
> David Gibson wrote:
>> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>>
>>> On Mon, May 11, 2009 at 7:12 PM, David Gibson
>>> <david at 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 at dlasys.net           http://www.dlasys.net
> fax: 1.253.369.9244                                Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too numerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
> Albert Einstein
>
>



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