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. <dh...@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 >>> <da...@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 dh...@dlasys.net http://www.dlasys.net > fax: 1.253.369.9244 Cell: 1.717.587.7774 > Over 25 years' experience in platforms, languages, and technologies too > numerous to list. > > "Any intelligent fool can make things bigger and more complex... It takes a > touch of genius - and a lot of courage to move in the opposite direction." > Albert Einstein > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
