[U-Boot] [PATCH v2 02/14] arm/km: add kmcoge5un board support

Holger Brunck
2012-07-03T09:37:34Z

On 07/03/2012 10:04 AM, Prafulla Wadaskar wrote:
> Dear Holger
>
>> -----Original Message-----
>> From: Holger Brunck [mailto:holger.brunck at keymile.com]
>> Sent: 13 June 2012 19:03
>> To: u-boot at lists.denx.de
>> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Thomas
>> Herzmann
>> Subject: [PATCH v2 02/14] arm/km: add kmcoge5un board support
>>
>> For u-boot this board is similar to mgcoge3un. But some differences
>> are present. We have a different SDRAM on it and therefore a new
>> SDRAM config file. Additionaly this board has a direct MAC/MAC
>> connection from the kirkwood to a marvell simple switch without a
>> phy inbetween, this needs a new configuration for the mvgbe driver.
>> The testpin was inverted compared to other km_kirkwood boards, this
>> is the reason we need the change in post_hotkeys_pressed.
>>
>> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>> cc: Prafulla Wadaskar <prafulla@marvell.com>
>>
>> Signed-off-by: Thomas Herzmann <thomas.herzmann@keymile.com>
>> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>> ---
>> changes for v2:
>> - rename KMCOGE5UN to KM_COGE5UN
>> - rename 256M8-1.cfg -> kwbimage_256M8_1.cfg
>> - squash 17/20 arm/km: fix testpin detection for kmcoge5un into this
>> commit because it should come with the board support patch
>>
>> MAINTAINERS | 1 +
>> board/keymile/km_arm/km_arm.c | 4 +
>> board/keymile/km_arm/kwbimage_256M8_1.cfg | 296
>> +++++++++++++++++++++++++++++
>
> There is anther file coming in patch 01/14 i.e.
> board/keymile/km_arm/kwbimage_128M16_1.cfg | 296 ++++++++++++++++++++++++++++
>
> I think the change is only RAM size supported, this must be effectively managed using post-configuration in the function
> board_early_init_f()
>

no the SDRAM size isn't the only difference. If you had a look at these files
there are also differences for other SDRAM controller register e.g. for DDR
timing. So I see no chance for an improvement here.

Regards
Holger