On 08/03/2012 01:48:02 AM, Prafulla Wadaskar wrote:
>
>
> > -----Original Message-----
> > From: Karl O. Pinc [mailto:k...@meme.com]
> > Sent: 02 August 2012 23:07
> > To: Prafulla Wadaskar
> > Cc: u-boot@lists.denx.de; david.c.pu...@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:k...@meme.com]
> > > > Sent: 01 August 2012 21:13
> > > > To: u-boot@lists.denx.de; david.c.pu...@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 <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
