Merging the pogo_e02 and sheevaplug code

U-Boot Karl O. Pinc 2 participants 5 messages Aug 1, 2012 – Aug 3, 2012

Share & tools

Karl O. Pinc

author

2012-08-01 15:42 UTC #0 lore 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 <[email protected]>
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.

Prafulla Wadaskar

2012-08-02 17:10 UTC #1 lore raw

Quoted 13 lines

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

Quoted 15 lines

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

Karl O. Pinc

author

2012-08-02 17:37 UTC #2 lore raw

Quoted 31 lines · Prafulla Wadaskar

Quoted 6 lines
-----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
Quoted 8 lines
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
Quoted 6 lines
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
Quoted 8 lines
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;

Quoted 4 lines

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 <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

Prafulla Wadaskar

2012-08-03 06:48 UTC #3 lore raw

Quoted 66 lines

-----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
Quoted 31 lines · Prafulla Wadaskar
Quoted 6 lines
-----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
Quoted 8 lines
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
Quoted 6 lines
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
Quoted 8 lines
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;
Quoted 4 lines
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.

Quoted 4 lines

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

Quoted 6 lines

Thanks for the help.
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

Karl O. Pinc

author

2012-08-03 15:40 UTC #4 lore raw

Quoted 73 lines · Prafulla Wadaskar

Quoted 22 lines
-----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
Quoted 12 lines · Prafulla Wadaskar
Quoted 6 lines
-----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
Quoted 5 lines
Subject: Merging the pogo_e02 and sheevaplug code
Hi,
I'm looking at possibly merging the pogo_e02 and sheevaplug
code
Quoted 19 lines
Quoted 19 lines
Quoted 3 lines
and have some general questions before doing anything.
The pogoplug POGO-E02 (pogo_e02 target) and the sheevaplug
(sheevaplug
Quoted 14 lines
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;
Quoted 1 line
Quoted 1 line
There are several other custom boards which are clone of
sheevaplug
Quoted 24 lines
Quoted 3 lines
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.
Quoted 4 lines
The main point of the "example patch"
was to use a different kwbimage.cfg file
while retaining the rest of the sheevaplug
code.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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.)

Quoted 4 lines

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 <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein