[U-Boot-Users] uboot custodian question

[U-Boot-Users] uboot custodian question

[Peter Pearse]

I bottom post 

> -----Original Message-----
> From: Nishanth Menon [mailto:menon.nishanth at gmail.com] 
> Sent: 01 August 2007 03:53
> To: Peter Pearse
> Subject: uboot custodian question
> 
> Hi Peter,
> am wondering if OMAP patches are expected to be pushed to u or not..
> thought i'd do a bit of devel as i get time..
> Regards,
> Nishanth Menon
> 

Until such time as we get a volunteer for arm/OMAP custodian I will be 
checking them.

But patches should be pushed to the list, not direct to me......

Peter

[U-Boot-Users] uboot custodian question

[ksi at koi8.net]

On Wed, 1 Aug 2007, Peter Pearse wrote:

Hey, any chances that TI DaVinci will come into the main tree until it's too
late for this release? Patches won't be accepted after August 19th or so
according to the new release schedule...

> I bottom post
>
>> -----Original Message-----
>> From: Nishanth Menon [mailto:menon.nishanth at gmail.com]
>> Sent: 01 August 2007 03:53
>> To: Peter Pearse
>> Subject: uboot custodian question
>>
>> Hi Peter,
>> am wondering if OMAP patches are expected to be pushed to u or not..
>> thought i'd do a bit of devel as i get time..
>> Regards,
>> Nishanth Menon
>>
>
> Until such time as we get a volunteer for arm/OMAP custodian I will be
> checking them.
>
> But patches should be pushed to the list, not direct to me......
>
> Peter
>
>
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] uboot custodian question

[Wolfgang Denk]

In message <Pine.LNX.4.64ksi.0708010957430.5139@home-gw.koi8.net> you wrote:
> 
> Hey, any chances that TI DaVinci will come into the main tree until it's too
> late for this release? Patches won't be accepted after August 19th or so
> according to the new release schedule...

August 17...

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
In the future, you're going to get computers as prizes  in  breakfast
cereals.  You'll  throw  them out because your house will be littered
with them.                                             - Robert Lucky

[U-Boot-Users] uboot custodian question

[Dirk Behme]

ksi at koi8.net wrote:
> On Wed, 1 Aug 2007, Peter Pearse wrote:
> 
> Hey, any chances that TI DaVinci will come into the main tree until it's too
> late for this release?

Which TI DaVinci patches do you refer to? Any pointers?

Many thanks

Dirk

[U-Boot-Users] uboot custodian question

[Nishanth Menon]

ksi at koi8.net stated on 8/1/2007 12:00 PM:
> Hey, any chances that TI DaVinci will come into the main tree until it's
> too
> late for this release? Patches won't be accepted after August 19th or so
> according to the new release schedule...
>
I think there'd be some amount of work to do before we can get davinci
and other OMAP platforms (2430,3430) in the system.. I am CCying davinci
list for their opinions and contributions if any..

Regards,
Nishanth Menon

[U-Boot-Users] uboot custodian question

[ksi at koi8.net]

On Wed, 1 Aug 2007, Nishanth Menon wrote:

> ksi at koi8.net stated on 8/1/2007 12:00 PM:
>> Hey, any chances that TI DaVinci will come into the main tree until
> it's
>> too
>> late for this release? Patches won't be accepted after August 19th or
> so
>> according to the new release schedule...
>>
> I think there'd be some amount of work to do before we can get davinci
> and other OMAP platforms (2430,3430) in the system.. I am CCying davinci
> list for their opinions and contributions if any..

What work? It's been 3 months since I've submitted patches for fully working
U-Boot on TMS320DM6446  platform. I do already have some patches to those
patches. We do run it for something like 6 months on various boards. What
work are you talking about, man?

I'm really really angry, nobody seems to care... What else should I do to
get the _PERFECTLY WORKING_ port into the main tree? What's the problem?

I do also have an initial bootloader that allows to program a virgin system
and makes it boot off of NAND and NOR Flash. Without Windo$e and without
that stupid dotnet or whatever. What else should I do? Fall to my knees and
beg? Bribe someone?

It looks like some kind of omerta here... I do _NOT_ need any opinions or
contributions from any list, I submitted a fully working port :(

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] uboot custodian question

[Nishanth Menon]

Ksi,

ksi at koi8.net stated on 8/1/2007 11:39 PM:
> What work? It's been 3 months since I've submitted patches for fully
> working
> U-Boot on TMS320DM6446  platform. I do already have some patches to those
> patches. We do run it for something like 6 months on various boards. What
> work are you talking about, man?
> 
> I'm really really angry, nobody seems to care... What else should I do to
> get the _PERFECTLY WORKING_ port into the main tree? What's the problem?
My apologies on not following up mails in the uboot list.. I was not
aware of your work.. but I do know that OMAP24xx and OMAP34xx patches
need a lot of rework.. I could be wrong to imagine that these could
share some files with Davinci and viceversa... I can see the patch here
in the ARM  queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted on
2007-05-08) maybe Peter can comment on his plans of merger..
Regards,
Nishanth Menon

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Dirk Behme]

Nishanth Menon wrote:
> Ksi,
> 
> ksi at koi8.net stated on 8/1/2007 11:39 PM:
> 
>>What work? It's been 3 months since I've submitted patches for fully
>>working
>>U-Boot on TMS320DM6446  platform. I do already have some patches to those
>>patches. We do run it for something like 6 months on various boards. What
>>work are you talking about, man?
>>
>>I'm really really angry, nobody seems to care... What else should I do to
>>get the _PERFECTLY WORKING_ port into the main tree? What's the problem?
> 
> My apologies on not following up mails in the uboot list.. I was not
> aware of your work.. but I do know that OMAP24xx and OMAP34xx patches
> need a lot of rework.. I could be wrong to imagine that these could
> share some files with Davinci and viceversa... I can see the patch here
> in the ARM  queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted on
> 2007-05-08) maybe Peter can comment on his plans of merger..

Let us start to get an overview regarding TI DaVinci patches floating 
around. Sorry if anything is wrong or missing, please correct then.

First, I think we should split the discussion for OMAP24xx and 
OMAP34xx from DaVinci.

So, looking at DaVinci, I can at least identify three patchsets 
floating around, not sure if and what the relationship is between them.

1. (Original?) patch from Ksi:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314

I think these are the patches mentioned in

http://www.denx.de/wiki/UBoot/PatchStatus

2.Patch from Philip Balister:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/29399

http://www.balister.org/~balister/u-boot-sffsdr.patch

3. Patch from Ivan Tonchev:

http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/003645.html
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/003652.html

I haven't looked at all of these.

A short discussion with Philip Balister showed some basic requirements 
for a merge candidate: At least support for TMS320DM6446 based DV-EVM 
with default/basic NOR and EMIF configuration. Further, it would be 
nice if the initial work is easily extendable to machines beyond the 
EVM. May be we need to split the processor stuff off from the board 
stuff so that it is easy to add additional boards later.

Opinions?

Best regards

Dirk

P.S.: DaVinci list in CC for information.

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[ksi at koi8.net]

On Thu, 2 Aug 2007, Dirk Behme wrote:

> Nishanth Menon wrote:
>> Ksi,
>> 
>> ksi at koi8.net stated on 8/1/2007 11:39 PM:
>> 
>>> What work? It's been 3 months since I've submitted patches for fully
>>> working
>>> U-Boot on TMS320DM6446  platform. I do already have some patches to
> those
>>> patches. We do run it for something like 6 months on various boards.
> What
>>> work are you talking about, man?
>>> 
>>> I'm really really angry, nobody seems to care... What else should I
> do to
>>> get the _PERFECTLY WORKING_ port into the main tree? What's the
> problem?
>> 
>> My apologies on not following up mails in the uboot list.. I was not
>> aware of your work.. but I do know that OMAP24xx and OMAP34xx patches
>> need a lot of rework.. I could be wrong to imagine that these could
>> share some files with Davinci and viceversa... I can see the patch
> here
>> in the ARM  queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted
> on
>> 2007-05-08) maybe Peter can comment on his plans of merger..
>
> Let us start to get an overview regarding TI DaVinci patches floating
> around. 
> Sorry if anything is wrong or missing, please correct then.
>
> First, I think we should split the discussion for OMAP24xx and OMAP34xx
> from 
> DaVinci.
>
> So, looking at DaVinci, I can at least identify three patchsets floating
> around, not sure if and what the relationship is between them.
>
> 1. (Original?) patch from Ksi:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
>
> I think these are the patches mentioned in
>
> http://www.denx.de/wiki/UBoot/PatchStatus
>
> 2.Patch from Philip Balister:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/29399
>
> http://www.balister.org/~balister/u-boot-sffsdr.patch
>
> 3. Patch from Ivan Tonchev:
>
> http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/0036
> 45.html
> http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/0036
> 52.html
>
> I haven't looked at all of these.
>
> A short discussion with Philip Balister showed some basic requirements
> for a 
> merge candidate: At least support for TMS320DM6446 based DV-EVM with 
> default/basic NOR and EMIF configuration. Further, it would be nice if
> the 
> initial work is easily extendable to machines beyond the EVM. May be we
> need 
> to split the processor stuff off from the board stuff so that it is easy
> to 
> add additional boards later.

If you take a look at my patch you can find that it works at least on 3
different boards. It has a separate CPU directory and it is very easy to
extend for a new board (as a matter of fact it should work on any board with
minor changes if any.) We do run it on 2 additional boards since it's been
posted.

Also it is _FULLY_ working port, with all the peripherals properly supported
and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND flash
supported. For NAND both small and large page devices supported with full
hardware-assisted ECC fully compatible with Linux MTD implementation.

There is a bug in large page NAND ECC code though that makes U-Boot hang
after showing detected NAND Flash info. That came from TI kernel code and it
is fixed long ago but I can not send a patch for it because there is nothing
I can make that patch against. That's why I keep pushing for inclusion it
into the main tree so I would be able to send a fix.

I do also have an initial bootloader (UBL in TI's terms) that allows for
programming a virgin system and works as NAND UBL booting _ANY_ user app
(including U-Boot) from NAND, both small and large page. It's nothing like
that TI's weirdo with dotnet or whatever and Windo$e. And it makes automated
programming of freshly manufactured boards very easy.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Dirk Behme]

ksi at koi8.net wrote:
> On Thu, 2 Aug 2007, Dirk Behme wrote:
...
>> So, looking at DaVinci, I can at least identify three patchsets floating
>> around, not sure if and what the relationship is between them.
>>
>> 1. (Original?) patch from Ksi:
>>
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
>>
>> I think these are the patches mentioned in
>>
>> http://www.denx.de/wiki/UBoot/PatchStatus
...
>> A short discussion with Philip Balister showed some basic requirements
>> for a merge candidate: At least support for TMS320DM6446 based DV-EVM 
>> with default/basic NOR and EMIF configuration. Further, it would be 
>> nice if
>> the initial work is easily extendable to machines beyond the EVM. May 
>> be we
>> need to split the processor stuff off from the board stuff so that it 
>> is easy
>> to add additional boards later.
> 
> If you take a look at my patch you can find that it works at least on 3
> different boards. It has a separate CPU directory and it is very easy to
> extend for a new board (as a matter of fact it should work on any board 
> with
> minor changes if any.) We do run it on 2 additional boards since it's been
> posted.
> 
> Also it is _FULLY_ working port, with all the peripherals properly 
> supported
> and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND flash
> supported. For NAND both small and large page devices supported with full
> hardware-assisted ECC fully compatible with Linux MTD implementation.

Sounds good! Many thanks for summarizing this again for everybody who 
missed your older infos!

Looking at your patches, some quick thoughts. Most of them are really 
minor ones:

- While they still apply against recent git, would be good to update 
them to cleanly apply. There is a newer mach-types.h as well.

- There are some #if 0 and #if 1 throughout the code. I think Peter 
would like to see this fixed.

- Do we really need an additional types.h 
include/asm-arm/arch-tms320dm6446/types.h?

- Why not calling the directories

cpu/arm926ejs/tms320dm6446/
include/asm-arm/arch-tms320dm6446/

"davinci" instead? davinci sounds more generic.

- Not sure about this, but instead of introducing additional

nand.c nand_defs.h

is there a chance to use more from the existing NAND code?

- Any chance to reuse anything from drivers/ns8382x.c for DP83848?

Do you like to split the patches in smaller chunks (main stuff, 
drivers) and then sending them unzipped (except mach-types.h) as plain 
text to the list? Maybe this could help people to directly comment.

Best regards

Dirk

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Wolfgang Denk]

In message <46B2C9DA.4070608@googlemail.com> you wrote:
>
> Do you like to split the patches in smaller chunks (main stuff, 
> drivers) and then sending them unzipped (except mach-types.h) as plain 
> text to the list? Maybe this could help people to directly comment.

This is definitely a good idea; compressed patched tend to get ignored
as they violate the requirements for a proper patch - see
http://www.denx.de/wiki/UBoot/Patches


Dirk - thanks a lot for all the other very helpful comments.
I appreciate that we get this thing rolling finally!

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
Certainly there are things in life that money  can't  buy,  but  it's
very funny - Did you ever try buying them without money? - Ogden Nash

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[ksi at koi8.net]

On Fri, 3 Aug 2007, Wolfgang Denk wrote:

> In message <46B2C9DA.4070608@googlemail.com> you wrote:
>>
>> Do you like to split the patches in smaller chunks (main stuff,
>> drivers) and then sending them unzipped (except mach-types.h) as plain
>> text to the list? Maybe this could help people to directly comment.
>
> This is definitely a good idea; compressed patched tend to get ignored
> as they violate the requirements for a proper patch - see
> http://www.denx.de/wiki/UBoot/Patches

These requirements are broken. It is a good idea for patches that fix
something but it is absolutely bad for adding new port. Initial set of
patches for it is big and it is much better to use a compressed patch (or
even set of such) than posting 30 or 50 small patches in separate emails.

When it is already in the tree, yes, it is possible to use small patches and
it is good to do so.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Wolfgang Denk]

In message <Pine.LNX.4.64ksi.0708031047300.23796@home-gw.koi8.net> you wrote:
> 
> These requirements are broken. It is a good idea for patches that fix
> something but it is absolutely bad for adding new port. Initial set of
> patches for it is big and it is much better to use a compressed patch (or
> even set of such) than posting 30 or 50 small patches in separate emails.

This is your opinion; others voted differently.

Note that nobody asked for lots of tiny patches. Please  re-read  the
text,  especially the part "[if] ... you are absolutely sure that you
should not split it" ...

> When it is already in the tree, yes, it is possible to use small patches and
> it is good to do so.

compressed -> unreadable -> ignored.

Please do not complain then.

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
"It's hard to believe that something which is neither seen  nor  felt
can do so much harm."
"That's true. But an idea can't be seen or felt. And that's what kept
the Troglytes in the mines all these centuries. A mistaken idea."
	-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[ksi at koi8.net]

On Fri, 3 Aug 2007, Dirk Behme wrote:

> ksi at koi8.net wrote:
>> On Thu, 2 Aug 2007, Dirk Behme wrote:
> ...
>>> So, looking at DaVinci, I can at least identify three patchsets
> floating
>>> around, not sure if and what the relationship is between them.
>>> 
>>> 1. (Original?) patch from Ksi:
>>> 
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
>>> 
>>> I think these are the patches mentioned in
>>> 
>>> http://www.denx.de/wiki/UBoot/PatchStatus
> ...
>>> A short discussion with Philip Balister showed some basic
> requirements
>>> for a merge candidate: At least support for TMS320DM6446 based DV-EVM
> with 
>>> default/basic NOR and EMIF configuration. Further, it would be nice
> if
>>> the initial work is easily extendable to machines beyond the EVM. May
> be 
>>> we
>>> need to split the processor stuff off from the board stuff so that it
> is 
>>> easy
>>> to add additional boards later.
>> 
>> If you take a look at my patch you can find that it works at least on
> 3
>> different boards. It has a separate CPU directory and it is very easy
> to
>> extend for a new board (as a matter of fact it should work on any
> board 
>> with
>> minor changes if any.) We do run it on 2 additional boards since it's
> been
>> posted.
>> 
>> Also it is _FULLY_ working port, with all the peripherals properly 
>> supported
>> and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND
> flash
>> supported. For NAND both small and large page devices supported with
> full
>> hardware-assisted ECC fully compatible with Linux MTD implementation.
>
> Sounds good! Many thanks for summarizing this again for everybody who
> missed 
> your older infos!
>
> Looking at your patches, some quick thoughts. Most of them are really
> minor 
> ones:
>
> - While they still apply against recent git, would be good to update
> them to 
> cleanly apply. There is a newer mach-types.h as well.

Sure. But it is not possible because if I had a new patchset posted it will
get outdated again because I doubt it would be processed in less than 6
months or so. So let's get _something_ in first than I'll be able to clean
it up.

> - There are some #if 0 and #if 1 throughout the code. I think Peter
> would 
> like to see this fixed.

I will. But let's get something in first. Otherwise it won't get in ever.

> - Do we really need an additional types.h 
> include/asm-arm/arch-tms320dm6446/types.h?

That only has 2 typedefs for register and pointer to register. Yes, I can
get rid of those but that would be just cosmetic. Again, let's get something
in then I'll fix cosmetics.

> - Why not calling the directories
>
> cpu/arm926ejs/tms320dm6446/
> include/asm-arm/arch-tms320dm6446/
>
> "davinci" instead? davinci sounds more generic.

It it TOO generic. DaVinci family also includes ARM-less DSP chips. The more
generic name would be tms320dm644x but that can be changed later.

> - Not sure about this, but instead of introducing additional
>
> nand.c nand_defs.h
>
> is there a chance to use more from the existing NAND code?

No. This is board (or, in this case, CPU) specific code. This is _NOT_ NAND
code, this is CPU/board NAND hardware interface code. I did use the new NAND
code for NAND, absolutely generic. The same is true for NOR code -- there is
no custom code, generic CFI Flash driver is used.

> - Any chance to reuse anything from drivers/ns8382x.c for DP83848?

Nope. That drivers/ns8382x.c is _MAC_ driver, not PHY. And that has nothing
in common with DaVinci EMAC.

DP83848 is added PHY driver. All other boards I'm aware of including DV-EVM
use Intel LXT971/972 PHY. We use DP83848 here because it is better than
LXT971 and much cheaper. And it is readily available.

> Do you like to split the patches in smaller chunks (main stuff, drivers)
> and 
> then sending them unzipped (except mach-types.h) as plain text to the
> list? 
> Maybe this could help people to directly comment.

Do you want me to send 30 or so emails for a new port? That would do
absolutely no sense and something will get lost in the process. Been there
done that. Let's get a base in first then it will make sense to do small
isolated patches.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Wolfgang Denk]

In message <Pine.LNX.4.64ksi.0708031052420.23796@home-gw.koi8.net> you wrote:
> 
> Sure. But it is not possible because if I had a new patchset posted it will
> get outdated again because I doubt it would be processed in less than 6
> months or so. So let's get _something_ in first than I'll be able to clean
> it up.

U-Boot development process has changed significantly in hte last  few
months.  But to work quick and easy it requires that you adapt to the
methods and tools used in this process.

> > - There are some #if 0 and #if 1 throughout the code. I think Peter
> > would 
> > like to see this fixed.
> 
> I will. But let's get something in first. Otherwise it won't get in ever.
...
> That only has 2 typedefs for register and pointer to register. Yes, I can
> get rid of those but that would be just cosmetic. Again, let's get something
> in then I'll fix cosmetics.

It seems you misunderstand how this patch review process  works.  You
are  supposed  to  fix  your  patches  according  to the feedback you
receive, and then resubmit the cleaned up patches, until they can  be
merged  cleanly.  We  don't  want  to  add code that is known to need
fixing, even if somebody promises to clean up later.

Please clean up now and resubmit.

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 game of life is a game of boomerangs.  Our  thoughts,  deeds  and
words return to us sooner or later with astounding accuracy.

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[ksi at koi8.net]

On Fri, 3 Aug 2007, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64ksi.0708031052420.23796@home-gw.koi8.net> you
> wrote:
>>
>> Sure. But it is not possible because if I had a new patchset posted it
> will
>> get outdated again because I doubt it would be processed in less than
> 6
>> months or so. So let's get _something_ in first than I'll be able to
> clean
>> it up.
>
> U-Boot development process has changed significantly in hte last  few
> months.  But to work quick and easy it requires that you adapt to the
> methods and tools used in this process.
>
>>> - There are some #if 0 and #if 1 throughout the code. I think Peter
>>> would
>>> like to see this fixed.
>>
>> I will. But let's get something in first. Otherwise it won't get in
> ever.
> ...
>> That only has 2 typedefs for register and pointer to register. Yes, I
> can
>> get rid of those but that would be just cosmetic. Again, let's get
> something
>> in then I'll fix cosmetics.
>
> It seems you misunderstand how this patch review process  works.  You
> are  supposed  to  fix  your  patches  according  to the feedback you
> receive, and then resubmit the cleaned up patches, until they can  be
> merged  cleanly.  We  don't  want  to  add code that is known to need
> fixing, even if somebody promises to clean up later.
>
> Please clean up now and resubmit.

Clean up WHAT? Man, I'm on the verge now...

The problem is there were _ABSOLUTELY NO_ feedback, just silence. I _WOULD_
clean up or fix anything but there was _ABSOLUTELY NO_ , repeat _ABSOLUTELY
NO_ feedback on that submission !!! I've just got "your patches are added to
the queue" from Peter and that's all.

What feedback?! Who is reviewing those patches? It looks like you guys are
desperately trying to find an excuse to NOT accept anything no matter how
laughable that excuse is, pardon my French.

Have I refused to clean up or fix the code? Should one develop a sixth sense
and anticipate what would you think 6 months from now? How can one submit
patches against _CURRENT_ version reflecting ever changing party line if
those patches are sitting dormant for 3+ months? They _WERE_ current as of
the time of posting. What sense does it make to redo them from today's
version if they would sit in the queue for another half year and then again
declared not current enough?

I'm fed up with that nonsense. And I have much better use for my time, my
prototype boards just came in so I have to grab my soldering iron and scope
and make them work. I have neither time nor will to fight with windmills any
more. You won, I accept my defeat.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Woodruff, Richard]

> Clean up WHAT? Man, I'm on the verge now...
> 
> The problem is there were _ABSOLUTELY NO_ feedback, just silence. I
> _WOULD_
> clean up or fix anything but there was _ABSOLUTELY NO_ , repeat
> _ABSOLUTELY
> NO_ feedback on that submission !!! I've just got "your patches are added
> to
> the queue" from Peter and that's all.
> 
> What feedback?! Who is reviewing those patches? It looks like you guys are
> desperately trying to find an excuse to NOT accept anything no matter how
> laughable that excuse is, pardon my French.

Well, watching and occasionally pushing fixes over the last several years, I've not observed the kind of thing you are venting about.

Generally, patch handling of large patches has been slow.  Fixes and incremental changes have happened at a reasonable rate.  Rate varies from project to project depending on demand. In an attempt to speed this up as Wolfgang doesn't scale the model changed recently.  The project has been quite beneficial for users so it's generally worth the effort.

I have many OMAP fixes and a few more boards which would be good to get in the tree. Part of why they are there was the delays and parts are our own fault. I try to see this pragmatically not bitterly.

Regards,
Richard W.

[U-Boot-Users] TI DaVinci merge, was: uboot custodian question

[Wolfgang Denk]

In message <Pine.LNX.4.64ksi.0708031344040.24286@home-gw.koi8.net> you wrote:
> 
> Clean up WHAT? Man, I'm on the verge now...

Please calm down and let's discuss this on a technical level.

> The problem is there were _ABSOLUTELY NO_ feedback, just silence. I _WOULD_
> clean up or fix anything but there was _ABSOLUTELY NO_ , repeat _ABSOLUTELY
> NO_ feedback on that submission !!! I've just got "your patches are added to
> the queue" from Peter and that's all.

You are right, ther ehas not been any feedback for a long, long time,
and nothing happened since your submission. That is regrettable,  but
that was in the past. Now is now.

> What feedback?! Who is reviewing those patches? It looks like you guys are

You received a few very useful comments from Dirk Behme on Fri, 03 Aug
2007. He wrote:

| - While they still apply against recent git, would be good to update 
| them to cleanly apply. There is a newer mach-types.h as well.
| 
| - There are some #if 0 and #if 1 throughout the code. I think Peter 
| would like to see this fixed.
| 
| - Do we really need an additional types.h 
| include/asm-arm/arch-tms320dm6446/types.h?
...

[I'll omit the remaining suggestions here because you already replied
why you would not want to follow his suggestions.  Even  though  this
might still be debated, it is not significant here.]

But the three suggestions above *are* feedback to your  patches.  Let
me summarize and repeat:

* Please clean up #if 0 and #if 1 in your patch.
* While doing this, please rebase it against the current  version  of
  U-Boot so your patch applies cleanly.
* Please avoid the new types.h file if it is not really necessary.

> Have I refused to clean up or fix the code? Should one develop a sixth sense
> and anticipate what would you think 6 months from now? How can one submit
> patches against _CURRENT_ version reflecting ever changing party line if
> those patches are sitting dormant for 3+ months? They _WERE_ current as of
> the time of posting. What sense does it make to redo them from today's
> version if they would sit in the queue for another half year and then again
> declared not current enough?

It would make little sense if there was reason to believe they  would
indeed stew in the pot for so long.

I can understand that you ar4e frustrated, but  please  help  us  and
give  us  a  chance  that  the new development process is actually an
improvement. If it is possible to use a simple "git  am"  command  to
add  your  patches  to  the current tree chances are *very* good that
they will get added.  On the other side, if they are  known  to  need
cleanup  and  cause a lot of conflicts with current code your chances
are really small.

> I'm fed up with that nonsense. And I have much better use for my time, my
> prototype boards just came in so I have to grab my soldering iron and scope
> and make them work. I have neither time nor will to fight with windmills any
> more. You won, I accept my defeat.

It seems an awful waste of resources to me  to  throw  in  the  towel
after  you  made  95%  of the way. I suggest you leave this issue for
now, and re-read the last few  messages  of  this  thread  after  the
weekend. Then, please reconsider.


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
"One thing they don't tell you about doing  experimental  physics  is
that sometimes you must work under adverse conditions... like a state
of sheer terror."                                    - W. K. Hartmann