[PATCH] powerpc/fsl: add device tree binding for QE firmware

Grant Likely grant.likely at secretlab.ca
Thu Mar 25 05:10:32 EST 2010


On Wed, Mar 24, 2010 at 11:31 AM, Timur Tabi <timur at freescale.com> wrote:
> Grant Likely wrote:
>> On Wed, Mar 24, 2010 at 11:00 AM, Segher Boessenkool
>> <segher at kernel.crashing.org> wrote:
>>>>> Why the phandle redirection?  Why not just put the firmware blob into
>>>>> a property in the QE node, or as a subnode?
>>>>
>>>> Because there might be multiple QE devices on a single chip, and each
>>>> will need to upload the same firmware.  So instead of embedding the
>>>> firmware multiple times, just embed it once, and have a pointer.
>>>
>>> You're messing up the binding because of a (perceived) deficiency in
>>> the DTB format?
>
> Huh?  Who says anything about messing up?  I don't see anything "messed up" about including a blob of data with proper compatible properties, etc.
>
>>> Or maybe just the DTS format.  Or maybe you shouldn't
>>> even care about size here.  Or really, the device tree is the wrong
>>> place to store firmware blobs at all.
>>
>> That is a good question.  Why is it necessary to pass the blob via the
>> tree?
>
> Because sometimes the firmware is needed before networking or serial I/O can function.  Today, we do one of two things on systems with QE (or QE-like microcontrollers):
>
> 1) U-Boot uploads the firmware, and may create a DTB node that provides some information about the firmware.
>
> 2) U-Boot uploads the firmware, but then gives Linux the physical address (in flash) of the firmware so that it can upload it again.
>
>> So far we've avoided using firmware blobs in the flat trees.
>> Or to ask in other words; what is the use case that requires passing
>> via the device tree?
>
> The Fman devices on the Freescale P4080 needs to have the firmware uploaded by the kernel before they will function.  I can't depend on having the firmware on the root file system, and we can't embed it in the kernel itself (because it's proprietary), so where else should I put it?  Today, we just leave it in flash and give the physical address to the Fman Linux driver via a command-line parameter.  But that doesn't work because then it means we have to have flash mapped to every partition that runs Linux.

Thanks.  This is important information when talking about his.

You can also put it into an initrd and use the Linux firmware loader.
That would also neatly solve your GPL distribution issues.

>> Also, depending on firmware to correctly squirt the firmware blob into
>> the dtb at boot is risky.  Even when firmware is buggy, there is
>> resistance to upgrading firmware on working boards because it could
>> result in a bricked board.
>
> I'm not sure what you're getting at.  This has nothing to do with upgrading firmware.  The firmware is already in flash, I just need a better way of giving it to the kernel.  If you upgrade the firmware in flash, then U-Boot will automatically provide the new version to the kernel via the DTB.  I just don't see how upgrading is a factor.

Heh, can't you understand my completely ambiguous statements?  Sorry
about that, I should have been clearer.  Let me rephrase...

Also, depending on U-Boot (or any other boot firmware) to correctly
squirt the QE blob into
the dtb at boot is risky.  Even when U-Boot is buggy, there is
resistance to upgrading U-Boot
on working boards because it could result in a bricked board.

>>  In fact, every time we depend on firmware

to revise my statement: s/firmware/U-Boot/

>> to modify the dtb at boot is risky, so it should only be done when
>> strictly necessary (I would even say that to date we've probably been
>> rather too liberal about getting u-boot to modify the device tree).
>
> Embedding the firmware blob in the DTS is uglier than having U-Boot do it, IMHO.

Not with the right syntax, see below...

>> I would say that either the firmware should be loaded via the existing
>> (non-dt) firmware loading mechanism,
>
> That, unfortunately, is not an option.
>
>> or it should be built into the
>> static dtb blob.  Don't try to add it at runtime.
>
> Then how do I distribute the firmware blob?  It's not GPL, so it can't go into arch/powerpc/boot/dts/.  Are you suggesting I do this in the DTS:
>
> / {
>        model = "MPC8323EMDS";
>        compatible = "MPC8323EMDS", "MPC832xMDS", "MPC83xxMDS";
>        #address-cells = <1>;
>        #size-cells = <1>;
>
> ...
>
>        qe_firmware:qe-firmware {
>                compatible = "fsl,qe-firmware";
>                fsl,firmware = <0x70 0xcd 0x00 0x00 0x01 0x46 0x45 0x63 ...>
>        }

You're right, that wouldn't be very nice.  Try this syntax instead:

fsl,firmware = /incbin/("firmware-file-name.bin");

> }
>
> Most firmware is 8-12KB, so this will make for one ugly DTS.  Plus, there's the issue of distributing non-GPL firmware data inside a DTS, which is GPL.

You've got the distribution problem that needs to be solved regardless
because it cannot be part of U-Boot either.  How do you plan to handle
QE firmware distribution and loading?

g.

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


More information about the Linuxppc-dev mailing list