[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[Timur Tabi]

The Freescale QE and FMAN devices support uploading of firmware, and U-Boot
can locate that firmware on different types of storage media.  However,
the current macros used for this code are inconsistent and poorly documented.

Note that some of the code managed by these macros have not yet been posted
externally.  Such code will be posted, but properly documenting the macros
is the first step.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 README |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 0886987..f47cea1 100644
--- a/README
+++ b/README
@@ -3124,6 +3124,44 @@ Low Level (hardware related) configuration options:
 		be used if available. These functions may be faster under some
 		conditions but may increase the binary size.
 
+Freescale QE/FMAN Firmware Support:
+-----------------------------------
+
+The Freescale QUICCEngine (QE) and Frame Manager (FMAN) both support the
+loading of "firmware", which is encoded in the QE firmware binary format.
+This firmware often needs to be loaded during U-Boot booting, so macros
+are used to identify the storage device (NOR flash, SPI, etc) and the address
+within that device.
+
+- CONFIG_SYS_FMAN_FW_ADDR
+	The address in the storage device where the firmware is located.  The
+	meaning of this address depends on which CONFIG_SYS_QE_FW_IN_xxx macro
+	is also specified.
+
+- CONFIG_SYS_FMAN_FW_LENGTH
+	The maximum possible size of the firmware.  The firmware binary format
+	has a field that specifies the actual size of the firmware, but it
+	might not be possible to read any part of the firmware unless some
+	local storage is allocated to hold the entire firmware first.
+
+- CONFIG_SYS_QE_FW_IN_NOR
+	Specifies that QE/FMAN firmware is located in NOR flash, mapped as
+	normal addressable memory via the LBC.  CONFIG_SYS_FMAN_FW_ADDR is the
+	virtual address in NOR flash.
+
+- CONFIG_SYS_QE_FW_IN_NAND
+	Specifies that QE/FMAN firmware is located in NAND flash.
+	CONFIG_SYS_FMAN_FW_ADDR is the offset within NAND flash.
+
+- CONFIG_SYS_QE_FW_IN_MMC
+	Specifies that QE/FMAN firmware is located on the primary SD/MMC
+	device.  CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+
+- CONFIG_SYS_QE_FW_IN_SPIFLASH
+	Specifies that QE/FMAN firmware is located on the primary SPI
+	device.  CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+
+
 Building the Software:
 ======================
 
-- 
1.7.3.4

[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[Tabi Timur-B04825]

On Mon, Aug 22, 2011 at 4:45 PM, Timur Tabi <timur@freescale.com> wrote:
> The Freescale QE and FMAN devices support uploading of firmware, and U-Boot
> can locate that firmware on different types of storage media. ?However,
> the current macros used for this code are inconsistent and poorly documented.
>
> Note that some of the code managed by these macros have not yet been posted
> externally. ?Such code will be posted, but properly documenting the macros
> is the first step.

Wolfgang, if you're okay with the text in this patch, I will go ahead
and make the corresponding changes to the code.  I just want to make
sure that there are no objections to these definitions before I work
on the code itself.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[Wolfgang Denk]

Dear Tabi Timur-B04825,

In message <CAOZdJXUUp6tA_J=_cvVDcd3bfqJMyYTg2s1DTX5mO2fWATNogA@mail.gmail.com> you wrote:
>
> > Note that some of the code managed by these macros have not yet been posted

s/have/has/ ?

> > externally. ?Such code will be posted, but properly documenting the macros
> > is the first step.
>
> Wolfgang, if you're okay with the text in this patch, I will go ahead
> and make the corresponding changes to the code.  I just want to make
> sure that there are no objections to these definitions before I work
> on the code itself.

Sorry, but I don't even understand this.  What does "post externally"
mean?

And why don't you add the documentation with the code?



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
The alternative to genuflecting before the  god  of  code-bumming  is
finding  a  better  algorithm.  It should be clear that none such was
available. If your code is too slow, you must make it faster.  If  no
better algorithm is available, you must trim cycles.
                                 - td at alice.UUCP (Tom Duff) 29 Aug 88

[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[Timur Tabi]

Wolfgang Denk wrote:
> Dear Tabi Timur-B04825,
> 
> In message <CAOZdJXUUp6tA_J=_cvVDcd3bfqJMyYTg2s1DTX5mO2fWATNogA@mail.gmail.com> you wrote:
>>
>>> Note that some of the code managed by these macros have not yet been posted
> 
> s/have/has/ ?

Thanks.

>>> externally.  Such code will be posted, but properly documenting the macros
>>> is the first step.
>>
>> Wolfgang, if you're okay with the text in this patch, I will go ahead
>> and make the corresponding changes to the code.  I just want to make
>> sure that there are no objections to these definitions before I work
>> on the code itself.
> 
> Sorry, but I don't even understand this.  What does "post externally"
> mean?

Sorry, that's a term we use in Freescale.  We have in-house code that has not
yet been posted on this mailing list for the "official" U-Boot.  That's what I
mean by posting externally.  I guess I need a better term for that.  We also
call that "upstream".

> And why don't you add the documentation with the code?

I haven't written the code yet.  I want to make sure the idea is acceptable
before I start implementing it.  Plus, since our internal code is different than
our "external" code, I need to manage both code bases independently.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros

[Wolfgang Denk]

Dear Timur Tabi,

In message <4E558423.8020803@freescale.com> you wrote:
>
> > And why don't you add the documentation with the code?
> 
> I haven't written the code yet.  I want to make sure the idea is acceptable
> before I start implementing it.  Plus, since our internal code is different than
> our "external" code, I need to manage both code bases independently.

I cannot comment on code or features I haven't seen yet. I suggest you
submit the documentation when you submit the code.

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
"I dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."    - Eric S. Raymond