[U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).

[Wolfgang Denk]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Please don't top-post/full-quote! This is *really* annoying.

In message <EA12F909C0431D458B9D18A176BEE4A502469206 at dlee02.ent.ti.com> you wrote:
> 
> Yes indeed I duplicated cfi_flash.c.  The changes in my previous patch
> to CFI were rejected.  You indicated see the previous list mail on the
> subject.  Your assertion at that time was to put things into the board
> specific files was one way to go.

Yes, but not by duplicating thousands of lines of code!

> The patch I had at that time was ifdef'ed just for my board in CFI and
> for the flash part I'm using would seem to show errors.  I think those
> OMAP specific ifdef's may fix errors, but I being its such a highly
> coupled driver it is very difficult to add in changes with out breaking
> a lot of boards.  How do you suggest real integration into that driver?
> The 1% changes are minor and isolated now and that's not acceptable what
> is?

The problem with the previous discussion was that there was no agree-
ment wether the board should come up with  the  flash  generally  un-
locked  (which is probably what most users expect and what is assumed
in the existing documentation), or if it  should  be  left  untouched
(which  is  what some board maintainers want). Detlev ZUndel tried to
start a poll of opinions, which - to  the  best  of  my  knowledge  -
resulted in no replies at all.

I can see only one way to keep everybody satisfied: 

The unlocking feature gets implemented (as part  of  the  common  CFI
flash  driver),  with  the  default that flash automatically gets un-
locked when the board comes up (this gives most  users  the  expected
standard behaviour).

A new environment variable "flash_unlock" can be defined which,  when
set to a value that starts with a 'n' (like "setenv flash_unlock no")
will turn off the automatic unlock (so board maintainers or users who
need  to  optimize  boot  times  can  turn  this off, eventually as a
default by pre-setting this variable in thier board config file).

It shall be a requirement (1) that the existing commands  "lock"  and
"unlock" work as expected and (2) that the "flinfo" command shows the
current  lock  state correctly, i. e. if the flash comes up locked it
*must* be displayed as read-only.

Comments welcome.

[I will accept a clean patch that implements such a solution.]

> I certainly can break the patch into parts, but they are all coupled.
> The chip and board are very new have went though flux and this results
> in large patches at this time.  This is not a PPC821 which shouldn't
> have a lot of change.

Please separate at least the cfi_flash part.

> > -----Original Message-----
> > From: wd at denx.de [mailto:wd at denx.de]
> > Sent: Wednesday, September 28, 2005 6:46 PM
> > To: Woodruff, Richard
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] [PATCH] Update OMAP242x for git head (plus
> > sign).

[Full quote deleted].


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I wish Captain Vimes were here. He wouldn't have  known  what  to  do
either, but he's got a much better vocabulary to be baffled in.
                                 - Terry Pratchett, _Guards! Guards!_