Grant Likely wrote:
> Thanks. This is important information when talking about his.
>
> You can also put it into an initrd and use the Linux firmware loader.
We may also need to support non-Linux operating systems that don't use an
initrd. For now, an initrd might work. I don't know how I'll convince our BSP
team to start using one, though.
> That would also neatly solve your GPL distribution issues.
True.
> 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.
Ok, that makes more sense, but we're not talking about upgrading U-Boot. Once
U-Boot has the capability to inject the QE blob into the DTB, then upgrading
the QE blob won't require an upgrade to U-Boot. The QE blob is still a QE blob.
> You're right, that wouldn't be very nice. Try this syntax instead:
>
> fsl,firmware = /incbin/("firmware-file-name.bin");
It's not a bad idea, but it would require firmware-file-name.bin to be
distributed with the kernel itself, otherwise building the DTB will be
complicated. The path to firmware-file-name.bin would need to be hard-coded in
the DTS.
> 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?
Today, we just put the QE blob somewhere in flash, and then U-Boot is told
about like this:
#define CONFIG_SYS_QE_FW_ADDR 0xfff00000
Then we have GPL code in U-Boot that uploads it.
But you do have a point -- once we embed the QE blob in the DTB, whether it's a
DTB created by DTC or updated by U-Boot, we might already have a GPL issue.
I'll have to get back to you on that one.
--
Timur Tabi
Linux kernel developer at Freescale
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
