[U-Boot] Merging the pogo_e02 and sheevaplug code

[U-Boot] Merging the pogo_e02 and sheevaplug code

[Karl O. Pinc]

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.

[U-Boot] Merging the pogo_e02 and sheevaplug code

[Prafulla Wadaskar]

> -----Original Message-----
> From: Karl O. Pinc [mailto:kop at meme.com]
> Sent: 01 August 2012 21:13
> To: u-boot at lists.denx.de; david.c.purdy at gmail.com; Prafulla Wadaskar
> Subject: Merging the pogo_e02 and sheevaplug code
> 
> 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;

There are several other custom boards which are clone of sheevaplug and u-boot image works as it is for them.

Does sheevaplug u-boot image boots as it is on pogo-plug_e02?

Regards...
Prafulla . . .

[U-Boot] Merging the pogo_e02 and sheevaplug code

[Karl O. Pinc]

On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote:
> 
> 
> > -----Original Message-----
> > From: Karl O. Pinc [mailto:kop at meme.com]
> > Sent: 01 August 2012 21:13
> > To: u-boot at lists.denx.de; david.c.purdy at gmail.com; Prafulla 
> Wadaskar
> > Subject: Merging the pogo_e02 and sheevaplug code
> > 
> > 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;
> 
> There are several other custom boards which are clone of sheevaplug
> and u-boot image works as it is for them.
> 
> Does sheevaplug u-boot image boots as it is on pogo-plug_e02?

I'm afraid to try it.  I don't have any jtag hardware.
(If you know of any that will work on Linux for a 10-pin
jtag (probably for OpenOCD -- something on Debian would
be helpful, that will support the cpu).

One reason I'm afraid is that the kwbimage.cfg file from
the factory is different from the stock sheevaplug
kwbimage.cfg.  (It also seems to be different from the
kwbimage.cfg in the current pogo_e02 target.)

FYI, the "example" patch I sent here:
http://lists.denx.de/pipermail/u-boot/2012-July/129182.html
includes the kwbimage.cfg file I've verified against
the factory pogo_e02 values -- except that my file
includes
  DATA 0xFFD01500 0x00000000	# CS[0]n Base address to 0x0
which was not in the original but is in the
sheevaplug's kwbimage.cfg file.  It seemed
a good idea to add this.

The main point of the "example patch"
was to use a different kwbimage.cfg file
while retaining the rest of the sheevaplug
code.

Thanks for the help.

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

[U-Boot] Merging the pogo_e02 and sheevaplug code

[Prafulla Wadaskar]

> -----Original Message-----
> From: Karl O. Pinc [mailto:kop at meme.com]
> Sent: 02 August 2012 23:07
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; david.c.purdy at gmail.com
> Subject: Re: Merging the pogo_e02 and sheevaplug code
> 
> On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote:
> >
> >
> > > -----Original Message-----
> > > From: Karl O. Pinc [mailto:kop at meme.com]
> > > Sent: 01 August 2012 21:13
> > > To: u-boot at lists.denx.de; david.c.purdy at gmail.com; Prafulla
> > Wadaskar
> > > Subject: Merging the pogo_e02 and sheevaplug code
> > >
> > > 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;
> >
> > There are several other custom boards which are clone of sheevaplug
> > and u-boot image works as it is for them.
> >
> > Does sheevaplug u-boot image boots as it is on pogo-plug_e02?
> 
> I'm afraid to try it.  I don't have any jtag hardware.
> (If you know of any that will work on Linux for a 10-pin
> jtag (probably for OpenOCD -- something on Debian would
> be helpful, that will support the cpu).
> 
> One reason I'm afraid is that the kwbimage.cfg file from
> the factory is different from the stock sheevaplug
> kwbimage.cfg.  (It also seems to be different from the
> kwbimage.cfg in the current pogo_e02 target.)
> 
> FYI, the "example" patch I sent here:
> http://lists.denx.de/pipermail/u-boot/2012-July/129182.html
> includes the kwbimage.cfg file I've verified against
> the factory pogo_e02 values -- except that my file
> includes
>   DATA 0xFFD01500 0x00000000	# CS[0]n Base address to 0x0
> which was not in the original but is in the
> sheevaplug's kwbimage.cfg file.  It seemed
> a good idea to add this.
> 
> The main point of the "example patch"
> was to use a different kwbimage.cfg file
> while retaining the rest of the sheevaplug
> code.

Hi Karl
I think it is exactly opposite, you can reuse the sheevaplug kwbimage and if have your own code, or you can you sheevaplug source files as it is. This is the reason we introduced macro CONFIG_SYS_KWD_CONFIG

Secondly your board is custom board and not sheevaplug, so modifying sheevaplug code for the same does not sound good. Still if it is one or two lines #ifdef change we can manage that instead of adding complete new board specific folder.

To me it looks that you can u-boot with sheevaplug u-boot image, where as it may report wrong DRAM size, that can be fixed.

Regards...
Prafulla . . .

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

[U-Boot] Merging the pogo_e02 and sheevaplug code

[Karl O. Pinc]

On 08/03/2012 01:48:02 AM, Prafulla Wadaskar wrote:
> 
> 
> > -----Original Message-----
> > From: Karl O. Pinc [mailto:kop at meme.com]
> > Sent: 02 August 2012 23:07
> > To: Prafulla Wadaskar
> > Cc: u-boot at lists.denx.de; david.c.purdy at gmail.com
> > Subject: Re: Merging the pogo_e02 and sheevaplug code
> > 
> > On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Karl O. Pinc [mailto:kop at meme.com]
> > > > Sent: 01 August 2012 21:13
> > > > To: u-boot at lists.denx.de; david.c.purdy at gmail.com; Prafulla
> > > Wadaskar
> > > > Subject: Merging the pogo_e02 and sheevaplug code
> > > >
> > > > 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;
> > >
> > > There are several other custom boards which are clone of
> sheevaplug
> > > and u-boot image works as it is for them.
> > >
> > > Does sheevaplug u-boot image boots as it is on pogo-plug_e02?
> > 
> > I'm afraid to try it.  I don't have any jtag hardware.
> > (If you know of any that will work on Linux for a 10-pin
> > jtag (probably for OpenOCD -- something on Debian would
> > be helpful, that will support the cpu).
> > 
> > One reason I'm afraid is that the kwbimage.cfg file from
> > the factory is different from the stock sheevaplug
> > kwbimage.cfg.  (It also seems to be different from the
> > kwbimage.cfg in the current pogo_e02 target.)
> > 
> > FYI, the "example" patch I sent here:
> > http://lists.denx.de/pipermail/u-boot/2012-July/129182.html
> > includes the kwbimage.cfg file I've verified against
> > the factory pogo_e02 values -- except that my file
> > includes
> >   DATA 0xFFD01500 0x00000000	# CS[0]n Base address to 0x0
> > which was not in the original but is in the
> > sheevaplug's kwbimage.cfg file.  It seemed
> > a good idea to add this.
> > 
> > The main point of the "example patch"
> > was to use a different kwbimage.cfg file
> > while retaining the rest of the sheevaplug
> > code.
> 
> Hi Karl
> I think it is exactly opposite, you can reuse the sheevaplug kwbimage
> and if have your own code, or you can you sheevaplug source files as
> it is. This is the reason we introduced macro CONFIG_SYS_KWD_CONFIG

I think there's benefit in using CONFIG_SYS_KWD_CONFIG
to have different configs for the "almost same" board.
See below.

> Secondly your board is custom board and not sheevaplug, so modifying
> sheevaplug code for the same does not sound good.

Yes. This is why I asked.  It's _almost_ a sheevaplug, but isn't.

> Still if it is one
> or two lines #ifdef change we can manage that instead of adding
> complete new board specific folder.

(There is already a board specific folder, board/cloudengines/
pogo_e02/.
The patch would remove it.)

There's 2 #ifdefs, each controlling 1 line.
One sets the kwbimage.cfg file, the other frobs
CONFIG_IDENT_STRING.

(Although there could be a third #ifdef-- the
current pogo_e02 code omits some kwmpp_config[] elements.
I need to look at this.)

> 
> To me it looks that you can u-boot with sheevaplug u-boot image, 
> where
> as it may report wrong DRAM size, that can be fixed.

The only way I know to fix it is to use mem= on the
kernel command line.  The problem with this is that
the pogo_e02 is a consumer device.  It's not a matter
of the command line being set once at time of manufacture.
Anyone who's going to be installing u-boot on the
pogo_e02 is going to be doing it one device at a time,
probably one per person.  Rather than have all these
people have to go through the extra step of setting
up a kernel parameter it makes sense to me to do it
once when the u-boot image is built.  This is
why I want a separate kwbimage.cfg file for the
pogo_e02.

Aside from kwmpp_config[] issues, the only difference
between the pogo_e02 and the sheevaplug is the
kwbimage.cfg file.  If you don't think that it's
worth having a separate kwbimage.cfg file for the
pogo_e02 then it's probably not worth having
a separate pogo_e02 board in u-boot at all.

(If you happen to know, offhand, what docs
I should be looking at to investigate the kwmpp_config[]
array please let me know.)

Regards,



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