All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl O. Pinc <kop@meme.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Merging the pogo_e02 and sheevaplug code
Date: Wed, 01 Aug 2012 10:42:56 -0500	[thread overview]
Message-ID: <1343835776.13373.0@mofo> (raw)

Hi,

I'm looking at possibly merging the pogo_e02 and sheevaplug code
and have some general questions before doing anything.

The pogoplug POGO-E02 (pogo_e02 target) and the sheevaplug (sheevaplug
development kit) (sheevaplug target) board are very similar.  
They are arm (Marvell) kirkwood boards.
The sheevaplug has 1G of ram the pogo_e02 has 256M.
Code-wise, the two boards have slightly different
kwbimage.cfg files.  There is something going on in the
kwmpp_config[] array, the current pogo_e02 code omits a lot
of elements of this array that are present in the sheevaplug
but are otherwise identical.  I can look into this myself
unless someone wants to hand me a clue.  Finally, there's
the board initialization: board_init(void).  The
sheevaplug has
  gd->bd->bi_arch_number = MACH_TYPE_SHEEVAPLUG;
wheras the pogo_e02 does something different
  gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100;


Here are my questions:

(FYI I haven't pulled from the git repo in about 2 weeks
as I've looked about and made notes.)

Should I even try to merge this code?  Is the code reduction
worth the #ifdefs?  Is this going to confound the
official maintainers of these boards?

The sheevaplug is a Marvell board boards/Marvell/
whereas the pogo_e02 is made by cloudengines,
boards/cloudengines/.  This seems to present a
policy problem.  Should I leave a 
boards/cloudengines/README.pogo_e02 behind
after the merge or what?

I'll look at the kwmpp_config[] array content.

What is MACH_TYPE_*?  arch/arm/include/asm/mach-types.h 
says it's automatically generated from
arch/arm/tools/mach-types and to see
arch/arm/kernel/arch.c but neither of these
files exist.  Does the pogo_e02 need
a MACH_TYPE_POGO_E02?  I grepped around and the
whole point of MACH_TYPE_SHEEVAPLUG seems
to be to #define machine_is_sheevaplug()
but this does not seem to be used anywhere.

I'll look up gd->bd->bi_boot_params
but if anybody has a clue I'd be happy to
get one.

If I do this what's the best series of patches
to send?  Should I try to make the code 
as similar as possible by synchronizing the
comments and such before doing the merge
or should I just send one patch that merges
the code?

FWIW I plan a CONFIG_IDENT_STRING to
distinguish the sheevaplug from the pogo_e02 image.

Anything else I should know?

Thanks for the help.

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

P.S.  I have reason to believe that the 
boards/cloudengines/pogo_e02/kwbimage.cfg file
should be changed.  At least it does not conform
to what's in the factory-supplied file.
Before I send a patch I want to use the
new values in an image that I use to boot
an actual device.  I'm putting this off
until I have the final code I want to run.
Hence this message.

             reply	other threads:[~2012-08-01 15:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01 15:42 Karl O. Pinc [this message]
2012-08-02 17:10 ` [U-Boot] Merging the pogo_e02 and sheevaplug code Prafulla Wadaskar
2012-08-02 17:37   ` Karl O. Pinc
2012-08-03  6:48     ` Prafulla Wadaskar
2012-08-03 15:40       ` Karl O. Pinc

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=1343835776.13373.0@mofo \
    --to=kop@meme.com \
    --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.