[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.   *
******************************************************************