-----Original Message----- From: Holger Brunck [mailto:holger.brunck@keymile.com] Sent: 04 June 2012 21:50 To: Prafulla Wadaskar Cc: Valentin Longchamp; Marek Vasut; u-boot@lists.denx.de Subject: Re: [PATCH] Kirkwood: Add support for Ka-Ro TK71
On 06/04/2012 05:46 PM, Prafulla Wadaskar wrote:
-----Original Message----- From: Valentin Longchamp [mailto:valentin.longchamp@keymile.com] Sent: 04 June 2012 21:07 To: Marek Vasut Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Holger Brunck Subject: Re: [PATCH] Kirkwood: Add support for Ka-Ro TK71
Hi Marek and Prafulla,
On 06/01/2012 03:03 PM, Marek Vasut wrote:
Dear Prafulla Wadaskar,
-----Original Message----- From: Marek Vasut [mailto:marex@denx.de] Sent: 31 May 2012 16:37 To: u-boot@lists.denx.de Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk Subject: [PATCH] Kirkwood: Add support for Ka-Ro TK71
Signed-off-by: Marek Vasut marex@denx.de Cc: Prafulla Wadaskar prafulla@marvell.com Cc: Wolfgang Denk wd@denx.de
board/karo/tk71/Makefile | 45 ++++++++++ board/karo/tk71/kwbimage-256.cfg | 174
++++++++++++++++++++++++++++++++++++++
board/karo/tk71/kwbimage-512.cfg | 174
++++++++++++++++++++++++++++++++++++++
Dear Marek Just for DRAM size change do not add one more cfg file, configure
by
default 256MB of RAM in default kwbimg.cfg file and in function board_early_init_f() tune it to 512 for your other board version.
There's only one single bit flipped between those two kwb configs.
Do you think
it'd work if we just configured the system for 512MB RAM and ran
get_ram_size()
to see if it has only 256MB? That'd eliminate two board entries
for
this tk71.
I would like to have your advice on this as well Prafulla.
We have tested this on km_arm (we will have the same boards with
1/2
the RAM size) and with the above get_ram_size() it works as expected.
We still should, however, at some point (board_early_init_f() is a good candidate) then reduce the corresponding RAM CS size (reg @1504 for CS0 so that the window is the same size as what was detected by get_ram_size). What do you guys think ?
Dear Valentin Yes, we should use this method. That's why I always ask if one can
reuse any existing kwbimage.cfg.
It makes no sense to add one more file of 250 lines just for one or
two difference/s that can be handled through board_early_init_f().
but how should this work for kwbimabe.cfg files for images which will be downloaded via serial terminal and the runs directly from RAM. This patch is related to this topic: http://lists.denx.de/pipermail/u-boot/2012-May/124802.html
In this case we change already the *.kwb in that way that we can download it directly into RAM and execute it directly from there. Isn't it mandatory for this usecase to have the exact RAM size specified in u-boot.kwb ? If so the above approach would not work, or we enhance the kwboot tool proposed in the patch with an additional commandline argument for the ramsize.
In theory one common kwbimage.cfg should be used by both methods (boot from UART and boot from media)
Currently kwbimage.cfg embeds boot option, it can be abstracted and u-boot.kwb can be prepared for boot from UART or boot from media (flash). This can be addressed through u-boot.kwb target generation ( mkimage tool is not mandatory).
Whereas u-boot.kwb prepared for UART can be fetched by said tool into RAM by Kirkwood and will be executed in the same way (as it fetches and executes from flash)
Regards.. Prafulla . . .