[U-Boot] libfdt: make fdt_increase_size() available to everyone

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BFC1075.5010508 at freescale.com> you wrote:
> 
> > But as this seems obvious I feel you might have something else in
> > mind, yet I cannot figure out what it might be.
> 
> How would you prefer the user to be able to specify the address of the
> firmware FIT image, when he wants to boot Linux?  I think I remember Kumar
> saying something about an environment variable, but I can't find that email
> any more.

That was on IRC; here the relevant snippet:

(17:09:35) wdenk_: If the feature is enabled for a board, and if
        there is an entry "insert blob type xxx here", then common
        code should do that.
(17:10:10) wdenk_: in plain old style it could be a 4th argument, or
	with FIT images it could be part of the image description.
(17:11:46) wdenk_: or it could be an env variable, or ...
(17:12:05) wdenk_: this is a design question then, and probably easy
	to solve.
(17:12:45) galak: are we ok w/the use of an env variable to point to
	the blob?
(17:13:16) galak: manly I'm trying to avoid moving to FIT images as
	that's a big churn on the user community
(17:13:24) galak: s/manly/mainly/
(17:14:09) TimurTabi: it would be nice if we didn't have to wrap
        everything in a FIT image in order for U-boot to be able to
        use it.
(17:14:52) TimurTabi: the QE firmware, for instance, already has a
	documented header that includes its size
(17:15:06) galak: I'd say there is a point at which FIT images make
	sense
(17:15:22) TimurTabi: as a hard requirement for this feature?
(17:15:39) galak: not for this feature, but in general
(17:16:08) galak: we need to be doing some tooling to make FIT usage
	as seamless as "old style/mkimage" is today
(17:16:43) galak: I'd like to try and separate the two issues, and
        thus asking if an env var pointing to the address of the qe
        firmware in this case would be acceptable to wdenk1
(17:16:52) TimurTabi: how do we make the "add a blob" feature generic
	without using FIT images?
(17:18:26) wdenk_: galak: please omit the "qe" part :-) It would be
        the address of a IH_TYPE_FIRMWARE image then, right?
(17:20:11) galak: wdenk1: I'd say the address can point to that, but
        I think its still a getenv ("qe_fw_addr")
(17:20:49) wdenk_: NAK. I want a _generic_ implementation, and "qe"
	is highly special.
(17:21:32) wdenk_: I don't want to use "qe_something" for an Altera
	FPGA bitstream.
(17:21:38) galak: wdenk1: agreed
(17:22:02) wdenk_: fdt_fw_addr or so might be better.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(17:22:21) galak: I'd be ok with that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(17:22:23) TimurTabi: wdenk1: so you want all such firmware to be
        wrapped in an IH_TYPE_FIRMWARE image so that we can know
        generically how large that image is, even thought we need
        board-specific code to embed that image into the fdt?
(17:22:52) wdenk_: TimurTabi: we do not need any board-specific code
	for that.
(17:23:12) TimurTabi: wdenk1: yes we do. There is a specific device
        tree binding for embedding QE firmware.
(17:23:22) galak: its not board specific
(17:23:35) wdenk_: if a board enables the feature in it's
        configuration, and if the variable is found in the env, then
        generic code will do what needs to be done.
(17:26:03) galak: its firmware type specific, do we have anyway in
        the image hdr to determine QE firmware from Altera FPGA
        firmware?
(17:26:56) wdenk_: TimurTabi: That was a silly thing to add to the DT
        spec. Now nobody else can use it. If I have a MPC823E and I
        need to load it with CPM microcode I cannot use this, because
        CPM microcode is not QEFW. If I have a FPGA bitstream I
        cannot use it because it is not QEFW. If I have a firmware
        blob for FOO I cannot use it because it's not QEFW.
(17:28:00) TimurTabi: wdenk1: I don't think it's silly at all. The
        compatible property tells the linux driver whether the
        embedded firmware is for it or for something else
(17:28:07) galak: there needs to be some bit of information to convey
        the intended purpose of the FW
(17:28:28) wdenk_: galak: guess we don't have yet, but adding one
        specific type of firmware image and making it so special that
        nobody else who needs the same feature is just stupid.
(17:29:15) TimurTabi: wdenk1: generic firmware really doesn't make
	much sense, to me.
(17:29:58) galak: I agree, however there are few items that are
        specific. I think the vast majority of the code can be used
        by any firmware but we do need something to convey the
        intended user of the firmware (FPGA, QE, usb dev, etc.)
(17:35:32) TimurTabi: wdenk1: so qe firmware needs to be embedded in
	the device tree differently than other firmware
(17:37:05) wdenk_:  add a type identifier, then
(17:37:27) TimurTabi: wdenk1: I have. It's called the "compatible"
	property
(17:38:25) TimurTabi: U-boot also needs to locate all the QE nodes in
        the device tree, and put pointers from those nodes to the
        firmware node
(17:38:35) TimurTabi: so this can't be done generically
(17:38:58) galak: thus my question of type or use of name in the env
	var to imply type
(17:39:06) TimurTabi: this is the reason I posted the patch "libfdt:
        introduce function fdt_get_max_phandle"
(17:39:32) wdenk_: you and your "can't be done".
(17:39:43) TimurTabi: ok, "can't be done in a reasonable manner"
(17:40:15) wdenk_: use the name field in the image, for example
(17:40:45) TimurTabi: wdenk1: how do I know which nodes in the device
        tree should be updated?
(17:40:56) TimurTabi: also, the binding says that the qe firmware
        node should be located inside the first qe node
(17:41:17) TimurTabi: and that the other qe nodes should have
        phandles pointing to the firmware node in the first qe node
(17:41:53) wdenk_: TimurTabi: I do not care about QE...
(17:42:22) TimurTabi: wdenk1: I'm giving you an example of why we
	can't treat embedded firmware blobs in the device tree in a
	completely generic manner
(17:42:49) TimurTabi: the process of putting the firmware in the
	device tree is specific to the type of firmware itself
(17:43:20) wdenk_: sorry, gotta run now
(17:43:30) TimurTabi: ok

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"No one talks peace unless he's ready to back it up with war."
"He talks of peace if it is the only way to live."
	-- Colonel Green and Surak of Vulcan, "The Savage Curtain",
	   stardate 5906.5.