Dear Timur Tabi,
In message <4bfc1075.5010...@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: w...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
