[U-Boot] 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;
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.

-----Original Message----- From: Karl O. Pinc [mailto:kop@meme.com] Sent: 01 August 2012 21:13 To: u-boot@lists.denx.de; david.c.purdy@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 . . .

On 08/02/2012 12:10:28 PM, Prafulla Wadaskar wrote:
-----Original Message----- From: Karl O. Pinc [mailto:kop@meme.com] Sent: 01 August 2012 21:13 To: u-boot@lists.denx.de; david.c.purdy@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

-----Original Message----- From: Karl O. Pinc [mailto:kop@meme.com] Sent: 02 August 2012 23:07 To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; david.c.purdy@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@meme.com] Sent: 01 August 2012 21:13 To: u-boot@lists.denx.de; david.c.purdy@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

On 08/03/2012 01:48:02 AM, Prafulla Wadaskar wrote:
-----Original Message----- From: Karl O. Pinc [mailto:kop@meme.com] Sent: 02 August 2012 23:07 To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; david.c.purdy@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@meme.com] Sent: 01 August 2012 21:13 To: u-boot@lists.denx.de; david.c.purdy@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
participants (2)
-
Karl O. Pinc
-
Prafulla Wadaskar