All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Balister <philip@balister.org>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [ARM] TI DaVinci (TMS320DM644x) support [1/5]
Date: Mon, 06 Aug 2007 11:36:25 -0400	[thread overview]
Message-ID: <46B73FF9.5080104@balister.org> (raw)
In-Reply-To: <200708060922.21300.sr@denx.de>

Stefan Roese wrote:
> I noticed that you have one board directory "board/davinci". And from my 
> understanding (I'm no DaVinci expert at all) a lot of CPU (SoC) code is 
> included in this board directory. Stuff like nand-driver or lowlevel_init 
> seem quite cpu-specific. Please correct me if I'm wrong here. But if my 
> finding is correct, I would like to seem some of this cpu-specific stuff 
> moved into the cpu directory and perhaps rename the board directory into 
> something not that generic as "board/davinci". We usually name the board 
> directory according to the name of the board itself. You are supporting 3 
> different boards in this board directory right now. This makes it difficult 
> to pick a name for such a board directory. But when more and more DaVince 
> port will emerge, it will not be possible anymore to support them all in one 
> board directory. It should be one board directory per board. Only *very* 
> similar board should share a board directory.
> 
> So I suggest to create 3 separate board directories and try to move the 
> generic, cpu-specific stuff in the cpu directory.
> 
> What do you think? Does this make sense?

I agree with Stefan. Although different boards using a davinci 
processor, in the case a dm6446 ..., are similar, trying to capture 
board differences in one common uboot board directory makes the addition 
of new boards very difficult. The config/davinci.h in Sergey's latest 
patch requires you set a #define for your board and then makes all 
selections of config options based on this #define. I have tried adding 
a new board hos patches and gave up when I kept losing track of where I 
was in sets of nested #ifdef's.

I think Dirk did a good job trying to break up Sergey's work into 
patches for review. The key thing to move forward is get a set of 
patches accepted into uboot git so davinci users can start testing and 
adding support for their own boards. Once we get the first patches in, I 
think the process will go much smoother.

Philip

PS: I am not a uboot guru, but the people I work with think I am.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070806/15b62a97/attachment.bin 

  reply	other threads:[~2007-08-06 15:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06  0:27 [U-Boot-Users] [ARM] TI DaVinci (TMS320DM644x) support [1/5] ksi at koi8.net
2007-08-06  7:22 ` Stefan Roese
2007-08-06 15:36   ` Philip Balister [this message]
2007-08-06 16:58     ` ksi at koi8.net
2007-08-06 16:47   ` Dirk Behme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46B73FF9.5080104@balister.org \
    --to=philip@balister.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.