Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Sughosh Ganu 
On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
 On Wed, 11 Jul 2012 00:09:06 +0530
 Sughosh Ganu urwithsugh...@gmail.com wrote:
   diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
   b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
   --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
   +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
  
  snip
  
void board_init_r(gd_t *id, ulong dummy)
{
   -#ifdef CONFIG_SPL_NAND_LOAD
   - nand_init();
   - puts(Nand boot...\n);
   - nand_boot();
   -#endif
   -#ifdef CONFIG_SPL_SPI_LOAD
   - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
   - CONFIG_SYS_MALLOC_LEN);
   + u32 boot_device;
   + void (*uboot)(void) __noreturn;
   +
   + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
   + CONFIG_SYS_SPL_MALLOC_SIZE);
  
  We do not need any heap for the spl on the hawkboard, so can you
  please explain why do we need the heap allocation for all spl
  images. Can't this be made configurable.
 
 this is needed at least for:
   * MMC support
   * SPI support
   * gunzip support (see next patch)
 
 it can be configurable, but is it reasonable?

I would think so -- i guess it should be fine to include this only for
boards/configurations that actually need the heap.

 

 gd = gdata;
 gd-bd = bdata;
 gd-flags |= GD_FLG_RELOC;
   +#ifdef CONFIG_SPL_SERIAL_SUPPORT
 gd-baudrate = CONFIG_BAUDRATE;
   - serial_init();  /* serial communications setup */
   + serial_init();
 gd-have_console = 1;
   +#endif
  
  This call to serial_init is not needed on the hawkboard -- we
  initialise the console needed for spl through NS16550_init for all
  da8xx based spl's in arch_cpu_init, which suffices for spl's debug
  message requirement. I know this is being used for spi based spl
  images, but now that this is being made common, just wanted to
  know why we need this. Also, do these changes have any impact on the
  size of the spl images.
 
 hm, i'll look on it more carefully. I've just look on spi support in spl.
 
 What about ymodem support? If I am not mistake it require a normal console.

If it's needed for ymodem support, include it for that use case -- i
see that your patch already has a separate cases for ymodem
support, spi flash support and so on. Can't it be called for cases
where it is really needed.

Btw, forgot to mention in my earlier mail that you need to add the
license header for all the new files, like spl_mmc.c etc.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Tom Rini 
On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
 On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
 On Wed, 11 Jul 2012 00:09:06 +0530
 Sughosh Ganu urwithsugh...@gmail.com wrote:
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
 b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c

 snip

  void board_init_r(gd_t *id, ulong dummy)
  {
 -#ifdef CONFIG_SPL_NAND_LOAD
 -  nand_init();
 -  puts(Nand boot...\n);
 -  nand_boot();
 -#endif
 -#ifdef CONFIG_SPL_SPI_LOAD
 -  mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
 -  CONFIG_SYS_MALLOC_LEN);
 +  u32 boot_device;
 +  void (*uboot)(void) __noreturn;
 +
 +  mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
 +  CONFIG_SYS_SPL_MALLOC_SIZE);

 We do not need any heap for the spl on the hawkboard, so can you
 please explain why do we need the heap allocation for all spl
 images. Can't this be made configurable.

 this is needed at least for:
   * MMC support
   * SPI support
   * gunzip support (see next patch)

 it can be configurable, but is it reasonable?
 
 I would think so -- i guess it should be fine to include this only for
 boards/configurations that actually need the heap.

Shouldn't load u-boot.img from vfat SD card be a common case at least
for developers?

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Sughosh Ganu 
On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
 On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
  On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
  On Wed, 11 Jul 2012 00:09:06 +0530
  Sughosh Ganu urwithsugh...@gmail.com wrote:
  diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
  b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
  --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
  +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 
  snip
 
   void board_init_r(gd_t *id, ulong dummy)
   {
  -#ifdef CONFIG_SPL_NAND_LOAD
  -nand_init();
  -puts(Nand boot...\n);
  -nand_boot();
  -#endif
  -#ifdef CONFIG_SPL_SPI_LOAD
  -mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
  -CONFIG_SYS_MALLOC_LEN);
  +u32 boot_device;
  +void (*uboot)(void) __noreturn;
  +
  +mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
  +CONFIG_SYS_SPL_MALLOC_SIZE);
 
  We do not need any heap for the spl on the hawkboard, so can you
  please explain why do we need the heap allocation for all spl
  images. Can't this be made configurable.
 
  this is needed at least for:
* MMC support
* SPI support
* gunzip support (see next patch)
 
  it can be configurable, but is it reasonable?
  
  I would think so -- i guess it should be fine to include this only for
  boards/configurations that actually need the heap.
 
 Shouldn't load u-boot.img from vfat SD card be a common case at least
 for developers?

Yes, it should be, but what i meant was that things that are not
needed for certain boards or configurations need not be made
common. Like in this case, why does setting up a heap, which is not
needed at least on my board need to be common for all spl images. If a
particular board/configuration needs it, then use it.

Loading an image from a media is a common case, but for that
particular media only. Other media might have different requirements.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Tom Rini 
On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
 On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
 On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
 On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
 On Wed, 11 Jul 2012 00:09:06 +0530
 Sughosh Ganu urwithsugh...@gmail.com wrote:
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
 b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c

 snip

  void board_init_r(gd_t *id, ulong dummy)
  {
 -#ifdef CONFIG_SPL_NAND_LOAD
 -nand_init();
 -puts(Nand boot...\n);
 -nand_boot();
 -#endif
 -#ifdef CONFIG_SPL_SPI_LOAD
 -mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
 -CONFIG_SYS_MALLOC_LEN);
 +u32 boot_device;
 +void (*uboot)(void) __noreturn;
 +
 +mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
 +CONFIG_SYS_SPL_MALLOC_SIZE);

 We do not need any heap for the spl on the hawkboard, so can you
 please explain why do we need the heap allocation for all spl
 images. Can't this be made configurable.

 this is needed at least for:
   * MMC support
   * SPI support
   * gunzip support (see next patch)

 it can be configurable, but is it reasonable?

 I would think so -- i guess it should be fine to include this only for
 boards/configurations that actually need the heap.

 Shouldn't load u-boot.img from vfat SD card be a common case at least
 for developers?
 
 Yes, it should be, but what i meant was that things that are not
 needed for certain boards or configurations need not be made
 common. Like in this case, why does setting up a heap, which is not
 needed at least on my board need to be common for all spl images. If a
 particular board/configuration needs it, then use it.

Wouldn't load from SD be a common case on hawkboard, esp once the ones
that can load from SD, from the ROM become more available?  I'm fine
saying that we should wrap the call around an #if, but I would expect it
to be set in the common case and only not set in custom production boards.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Sughosh Ganu 
On Wed Jul 11, 2012 at 03:46:46AM -0700, Tom Rini wrote:
 On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
  On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
  On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
  On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
  On Wed, 11 Jul 2012 00:09:06 +0530
  Sughosh Ganu urwithsugh...@gmail.com wrote:
  diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
  b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
  --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
  +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 
  snip
 
   void board_init_r(gd_t *id, ulong dummy)
   {
  -#ifdef CONFIG_SPL_NAND_LOAD
  -  nand_init();
  -  puts(Nand boot...\n);
  -  nand_boot();
  -#endif
  -#ifdef CONFIG_SPL_SPI_LOAD
  -  mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
  -  CONFIG_SYS_MALLOC_LEN);
  +  u32 boot_device;
  +  void (*uboot)(void) __noreturn;
  +
  +  mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
  +  CONFIG_SYS_SPL_MALLOC_SIZE);
 
  We do not need any heap for the spl on the hawkboard, so can you
  please explain why do we need the heap allocation for all spl
  images. Can't this be made configurable.
 
  this is needed at least for:
* MMC support
* SPI support
* gunzip support (see next patch)
 
  it can be configurable, but is it reasonable?
 
  I would think so -- i guess it should be fine to include this only for
  boards/configurations that actually need the heap.
 
  Shouldn't load u-boot.img from vfat SD card be a common case at least
  for developers?
  
  Yes, it should be, but what i meant was that things that are not
  needed for certain boards or configurations need not be made
  common. Like in this case, why does setting up a heap, which is not
  needed at least on my board need to be common for all spl images. If a
  particular board/configuration needs it, then use it.
 
 Wouldn't load from SD be a common case on hawkboard, esp once the ones
 that can load from SD, from the ROM become more available?

Yes, loading from SD could be supported on any board in the future,
but in that case, should it not be just a matter of adding something
like CONFIG_SPL_MMC_LOAD to the board's config file.


 I'm fine saying that we should wrap the call around an #if, but I
 would expect it to be set in the common case and only not set in
 custom production boards.

Correct, so all that is needed for SD/MMC loading can still be kept
separate from, say nand load in the spl.c file, isn't it. So if sd/mmc
spl load needs heap to be set up, can't it be done only for that
case.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Tom Rini 
On 07/11/2012 04:05 AM, Sughosh Ganu wrote:
 On Wed Jul 11, 2012 at 03:46:46AM -0700, Tom Rini wrote:
 On 07/11/2012 03:40 AM, Sughosh Ganu wrote:
 On Wed Jul 11, 2012 at 01:19:40AM -0700, Tom Rini wrote:
 On 07/10/2012 11:38 PM, Sughosh Ganu wrote:
 On Tue Jul 10, 2012 at 11:20:53PM +0400, Mikhail Kshevetskiy wrote:
 On Wed, 11 Jul 2012 00:09:06 +0530
 Sughosh Ganu urwithsugh...@gmail.com wrote:
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
 b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c

 snip

  void board_init_r(gd_t *id, ulong dummy)
  {
 -#ifdef CONFIG_SPL_NAND_LOAD
 -  nand_init();
 -  puts(Nand boot...\n);
 -  nand_boot();
 -#endif
 -#ifdef CONFIG_SPL_SPI_LOAD
 -  mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
 -  CONFIG_SYS_MALLOC_LEN);
 +  u32 boot_device;
 +  void (*uboot)(void) __noreturn;
 +
 +  mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
 +  CONFIG_SYS_SPL_MALLOC_SIZE);

 We do not need any heap for the spl on the hawkboard, so can you
 please explain why do we need the heap allocation for all spl
 images. Can't this be made configurable.

 this is needed at least for:
   * MMC support
   * SPI support
   * gunzip support (see next patch)

 it can be configurable, but is it reasonable?

 I would think so -- i guess it should be fine to include this only for
 boards/configurations that actually need the heap.

 Shouldn't load u-boot.img from vfat SD card be a common case at least
 for developers?

 Yes, it should be, but what i meant was that things that are not
 needed for certain boards or configurations need not be made
 common. Like in this case, why does setting up a heap, which is not
 needed at least on my board need to be common for all spl images. If a
 particular board/configuration needs it, then use it.

 Wouldn't load from SD be a common case on hawkboard, esp once the ones
 that can load from SD, from the ROM become more available?
 
 Yes, loading from SD could be supported on any board in the future,
 but in that case, should it not be just a matter of adding something
 like CONFIG_SPL_MMC_LOAD to the board's config file.

Yes, along with adding the defines for the heap.  And unless you end up
being severely space constrained for the SPL file, it's usually the case
you build in support for a few modes, when it's possible to detect at
run time where you came from.

 I'm fine saying that we should wrap the call around an #if, but I
 would expect it to be set in the common case and only not set in
 custom production boards.
 
 Correct, so all that is needed for SD/MMC loading can still be kept
 separate from, say nand load in the spl.c file, isn't it. So if sd/mmc
 spl load needs heap to be set up, can't it be done only for that
 case.

Yes, but we don't want to have N locations that set up the heap.  We
want one location that will, if the board has defined a heap area, we
set it up.  Or to put it another way, calling mem_malloc_init isn't part
of the mmc boot-flow, it's part of the general boot flow.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Sughosh Ganu 
On Wed Jul 11, 2012 at 04:43:19AM -0700, Tom Rini wrote:
 On 07/11/2012 04:05 AM, Sughosh Ganu wrote:

snip

  I'm fine saying that we should wrap the call around an #if, but I
  would expect it to be set in the common case and only not set in
  custom production boards.
  
  Correct, so all that is needed for SD/MMC loading can still be kept
  separate from, say nand load in the spl.c file, isn't it. So if sd/mmc
  spl load needs heap to be set up, can't it be done only for that
  case.
 
 Yes, but we don't want to have N locations that set up the heap.  We
 want one location that will, if the board has defined a heap area, we
 set it up.  Or to put it another way, calling mem_malloc_init isn't part
 of the mmc boot-flow, it's part of the general boot flow.

Fair enough. My only concern was just that if some feature is not
needed for a board, it should be possible to exclude it out.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-11 Thread Tom Rini 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/2012 05:08 AM, Sughosh Ganu wrote:
 On Wed Jul 11, 2012 at 04:43:19AM -0700, Tom Rini wrote:
 On 07/11/2012 04:05 AM, Sughosh Ganu wrote:
 
 snip
 
 I'm fine saying that we should wrap the call around an #if,
 but I would expect it to be set in the common case and only
 not set in custom production boards.
 
 Correct, so all that is needed for SD/MMC loading can still be
 kept separate from, say nand load in the spl.c file, isn't it.
 So if sd/mmc spl load needs heap to be set up, can't it be done
 only for that case.
 
 Yes, but we don't want to have N locations that set up the heap.
 We want one location that will, if the board has defined a heap
 area, we set it up.  Or to put it another way, calling
 mem_malloc_init isn't part of the mmc boot-flow, it's part of the
 general boot flow.
 
 Fair enough. My only concern was just that if some feature is not 
 needed for a board, it should be possible to exclude it out.

To be clear, absolutely agreed.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP/W50AAoJENk4IS6UOR1W6VEQAJ2C+IlU/irdxIBQJkWKdGoe
Rwr1bdQpnUIA4ILEBuD7jwiDj/Q6znfzUQf0XXZuRg+ShYu10y/2HBazn/alfrMj
FyLqm7YnjxDoWpfbSzR5EajdUOD7UgdDbZURwyte/NQos2WeS89IZTrlIT5sxfYV
L7DT0fDdK4pfh7+gArr99Ge/eE3ddm9kVdoxFbvYsr0BQs8xLnjh7t1DZ2rk0P7Y
AabwKIiM1o7xNn5GPIb7lraO4A1/m7U1/if2ad+I/qtEsAnsTC+Ds7VPvnxSdK/w
ga/r/OcYzpQLHna0dBQ4qXqnl5hKDARw3ZX2EYiqxRECRDLMDo2OWJio2F7yEqID
nYhhVKFNcSIC6mcIz1DyPGd/q3QFziCRFfFq0xrfF6K2rNByfXK4xHdld33EFvM1
V7Kfu8XSXeswGU41T+I6hHZyaCFWeNzDBTF/JtfXoZ0IoGgb045JLc6i14KAmwpO
AVCLhQy64h4O7BfvrzYK5u93RmI0PtjdXwkrBMpqAcICwsiPJ0mAU2azYQNbhYVk
NJM5xecgobni0HQek1f/UgzwllwDusjrjo5Hv+Di/D5wYBYTOWxPKZGEHOWfcuf6
O/io1QVQc3FMdrU3cCf5kB/tDAXDOpENhStCkkCgbFVf6u2hVz4vdSxV7oZ5Gmkp
bpFoazwtHzXpzE5B6eIe
=kJeB
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-10 Thread Sughosh Ganu 
hi Mikhail,
On Mon Jul 09, 2012 at 10:53:39PM +0400, Mikhail Kshevetskiy wrote:
 This patch allow us to have a universal spl that detects a boot
 device and select a corresponding boot algorithm for main u-boot part
 (SOC_DA8XX only)

I have not tested this patch, will do so sometime this week. I had a
couple of questions though.

snip

 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
 b/arch/arm/cpu/arm926ejs/davinci/spl.c
 index 74632e5..50b4bbc 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c

snip

  void board_init_r(gd_t *id, ulong dummy)
  {
 -#ifdef CONFIG_SPL_NAND_LOAD
 - nand_init();
 - puts(Nand boot...\n);
 - nand_boot();
 -#endif
 -#ifdef CONFIG_SPL_SPI_LOAD
 - mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
 - CONFIG_SYS_MALLOC_LEN);
 + u32 boot_device;
 + void (*uboot)(void) __noreturn;
 +
 + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
 + CONFIG_SYS_SPL_MALLOC_SIZE);

We do not need any heap for the spl on the hawkboard, so can you
please explain why do we need the heap allocation for all spl
images. Can't this be made configurable.


  
   gd = gdata;
   gd-bd = bdata;
   gd-flags |= GD_FLG_RELOC;
 +#ifdef CONFIG_SPL_SERIAL_SUPPORT
   gd-baudrate = CONFIG_BAUDRATE;
 - serial_init();  /* serial communications setup */
 + serial_init();
   gd-have_console = 1;
 +#endif

This call to serial_init is not needed on the hawkboard -- we
initialise the console needed for spl through NS16550_init for all
da8xx based spl's in arch_cpu_init, which suffices for spl's debug
message requirement. I know this is being used for spi based spl
images, but now that this is being made common, just wanted to
know why we need this. Also, do these changes have any impact on the
size of the spl images.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-10 Thread Mikhail Kshevetskiy 
On Wed, 11 Jul 2012 00:09:06 +0530
Sughosh Ganu urwithsugh...@gmail.com wrote:

 hi Mikhail,
 On Mon Jul 09, 2012 at 10:53:39PM +0400, Mikhail Kshevetskiy wrote:
  This patch allow us to have a universal spl that detects a boot
  device and select a corresponding boot algorithm for main u-boot part
  (SOC_DA8XX only)
 
 I have not tested this patch, will do so sometime this week. I had a
 couple of questions though.
 
 snip
 
  diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
  b/arch/arm/cpu/arm926ejs/davinci/spl.c index 74632e5..50b4bbc 100644
  --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
  +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 
 snip
 
   void board_init_r(gd_t *id, ulong dummy)
   {
  -#ifdef CONFIG_SPL_NAND_LOAD
  -   nand_init();
  -   puts(Nand boot...\n);
  -   nand_boot();
  -#endif
  -#ifdef CONFIG_SPL_SPI_LOAD
  -   mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
  -   CONFIG_SYS_MALLOC_LEN);
  +   u32 boot_device;
  +   void (*uboot)(void) __noreturn;
  +
  +   mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
  +   CONFIG_SYS_SPL_MALLOC_SIZE);
 
 We do not need any heap for the spl on the hawkboard, so can you
 please explain why do we need the heap allocation for all spl
 images. Can't this be made configurable.

this is needed at least for:
  * MMC support
  * SPI support
  * gunzip support (see next patch)

it can be configurable, but is it reasonable?

   
  gd = gdata;
  gd-bd = bdata;
  gd-flags |= GD_FLG_RELOC;
  +#ifdef CONFIG_SPL_SERIAL_SUPPORT
  gd-baudrate = CONFIG_BAUDRATE;
  -   serial_init();  /* serial communications setup */
  +   serial_init();
  gd-have_console = 1;
  +#endif
 
 This call to serial_init is not needed on the hawkboard -- we
 initialise the console needed for spl through NS16550_init for all
 da8xx based spl's in arch_cpu_init, which suffices for spl's debug
 message requirement. I know this is being used for spi based spl
 images, but now that this is being made common, just wanted to
 know why we need this. Also, do these changes have any impact on the
 size of the spl images.

hm, i'll look on it more carefully. I've just look on spi support in spl.

What about ymodem support? If I am not mistake it require a normal console.

 -sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-09 Thread Mikhail Kshevetskiy 
This patch allow us to have a universal spl that detects a boot
device and select a corresponding boot algorithm for main u-boot part
(SOC_DA8XX only)

This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and
drivers/mtd/spi/spi_spl_load.c for the following reasons:
 * avoid jump to main u-boot code just after its loading (required
   for the next patch: spl - add compressed u-boot image support)
 * makes a structure similar to omap3 sources

Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
---
Change for v3:
 * split MMC+SPL+no partition table support bugfix to separate patch
   series (series 3/3)
Change for v2:
 * fix checkpatch warnings
 * defines for constants
 * use readl() to read a BOOTCFG_REG
 * improve patch description
---
 arch/arm/cpu/arm926ejs/davinci/Makefile  |5 ++
 arch/arm/cpu/arm926ejs/davinci/spl.c |   91 +++---
 arch/arm/cpu/arm926ejs/davinci/spl_mmc.c |   39 ++
 arch/arm/cpu/arm926ejs/davinci/spl_nand.c|   11 +++
 arch/arm/cpu/arm926ejs/davinci/spl_spi_flash.c   |   25 ++
 arch/arm/cpu/arm926ejs/davinci/spl_ymodem.c  |   42 ++
 arch/arm/include/asm/arch-davinci/davinci_boot.h |   50 
 include/configs/cam_enc_4xx.h|   12 +--
 include/configs/da850evm.h   |   19 +++--
 include/configs/hawkboard.h  |   11 +--
 10 files changed, 275 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_mmc.c
 create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_nand.c
 create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_spi_flash.c
 create mode 100644 arch/arm/cpu/arm926ejs/davinci/spl_ymodem.c
 create mode 100644 arch/arm/include/asm/arch-davinci/davinci_boot.h

diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile 
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index da7efac..12bd37a 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -40,6 +40,11 @@ ifdef CONFIG_SPL_BUILD
 COBJS-y+= spl.o
 COBJS-$(CONFIG_SOC_DM365)  += dm365_lowlevel.o
 COBJS-$(CONFIG_SOC_DA8XX)  += da850_lowlevel.o
+
+COBJS-$(CONFIG_SPL_NAND_SUPPORT)   += spl_nand.o
+COBJS-$(CONFIG_SPL_SPI_FLASH_SUPPORT)  += spl_spi_flash.o
+COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
+COBJS-$(CONFIG_SPL_MMC_SUPPORT)+= spl_mmc.o
 endif
 
 SOBJS  = reset.o
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 74632e5..50b4bbc 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -25,9 +25,11 @@
 #include asm/utils.h
 #include nand.h
 #include asm/arch/dm365_lowlevel.h
+#include asm/arch/davinci_boot.h
 #include ns16550.h
 #include malloc.h
 #include spi_flash.h
+#include linux/compiler.h
 
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 
@@ -72,25 +74,92 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, NULL, CONFIG_SPL_TEXT_BASE);
 }
 
+u32 davinci_boot_device(void){
+#ifdef CONFIG_SOC_DA8XX
+   u32 bootmode = readl(BOOTCFG_REG)  BOOTCFG_REG_DEVICE_MASK;
+   switch (bootmode) {
+   case BOOTCFG_DEVICE_NAND8:
+   case BOOTCFG_DEVICE_NAND16:
+   return BOOT_DEVICE_TYPE_NAND;
+   case BOOTCFG_DEVICE_SPI0_FLASH:
+   case BOOTCFG_DEVICE_SPI1_FLASH:
+   return BOOT_DEVICE_TYPE_SPI_FLASH;
+   case BOOTCFG_DEVICE_UART0:
+   case BOOTCFG_DEVICE_UART1:
+   case BOOTCFG_DEVICE_UART2:
+   return BOOT_DEVICE_TYPE_UART;
+   case BOOTCFG_DEVICE_MMC_OR_SD0:
+   return BOOT_DEVICE_TYPE_MMC;
+   default:
+   return BOOT_DEVICE_TYPE_NONE;
+   }
+#else
+#ifdef
+#endif CONFIG_SPL_NAND_SUPPORT
+   return BOOT_DEVICE_TYPE_NAND;
+#endif
+#ifdef BOOT_DEVICE_SPI_FLASH
+   return BOOT_DEVICE_TYPE_SPI_FLASH;
+#endif
+#ifdef CONFIG_SPL_YMODEM_SUPPORT
+   return BOOT_DEVICE_TYPE_UART;
+#endif
+#ifdef CONFIG_SPL_MMC_SUPPORT
+   return BOOT_DEVICE_TYPE_MMC;
+#endif
+}
+
 void board_init_r(gd_t *id, ulong dummy)
 {
-#ifdef CONFIG_SPL_NAND_LOAD
-   nand_init();
-   puts(Nand boot...\n);
-   nand_boot();
-#endif
-#ifdef CONFIG_SPL_SPI_LOAD
-   mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
-   CONFIG_SYS_MALLOC_LEN);
+   u32 boot_device;
+   void (*uboot)(void) __noreturn;
+
+   mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
+   CONFIG_SYS_SPL_MALLOC_SIZE);
 
gd = gdata;
gd-bd = bdata;
gd-flags |= GD_FLG_RELOC;
+#ifdef CONFIG_SPL_SERIAL_SUPPORT
gd-baudrate = CONFIG_BAUDRATE;
-   serial_init();  /* serial communications setup */
+   serial_init();
gd-have_console = 1;
+#endif
 
-   puts(SPI boot...\n);
-   spi_boot();
+   boot_device = davinci_boot_device();
+   debug(boot device - %d\n, boot_device);
+   switch

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-09 Thread Tom Rini 
On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote:
 This patch allow us to have a universal spl that detects a boot
 device and select a corresponding boot algorithm for main u-boot part
 (SOC_DA8XX only)
 
 This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and
 drivers/mtd/spi/spi_spl_load.c for the following reasons:
  * avoid jump to main u-boot code just after its loading (required
for the next patch: spl - add compressed u-boot image support)
  * makes a structure similar to omap3 sources
 
 Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com

I guess I wasn't clear enough when I asked the series to be split.  I
want to see this portion turned into:
a) Move omap-common spl bits to arch/arm/lib/
b) davinci converted (and as needed, omap3/4/am33xx converted) to be
able to use the same code.

We shouldn't introduce a new spl_mmc.c for example, we should modify the
davinci structure to be able to re-use the same spl_mmc.c code to
load/verify and let the next step, as needed happen.  I want to see
omap be able to re-use SPI (since am33xx can do it too, and I've
kludged the davinci stuff before) and potentially be able to re-use for
example the gunzip support.  This I think is the easy set of steps to
being able to reuse this fairly common SPL logic outside of not just TI
parts but anyone else that wants it.

-- 
Tom


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-09 Thread Tom Rini 
On 07/09/2012 12:57 PM, Mikhail Kshevetskiy wrote:
 On Mon, 9 Jul 2012 12:41:06 -0700
 Tom Rini tr...@ti.com wrote:
 
 On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote:
 This patch allow us to have a universal spl that detects a boot
 device and select a corresponding boot algorithm for main u-boot part
 (SOC_DA8XX only)

 This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and
 drivers/mtd/spi/spi_spl_load.c for the following reasons:
  * avoid jump to main u-boot code just after its loading (required
for the next patch: spl - add compressed u-boot image support)
  * makes a structure similar to omap3 sources

 Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com

 I guess I wasn't clear enough when I asked the series to be split.  I
 want to see this portion turned into:
 a) Move omap-common spl bits to arch/arm/lib/
 b) davinci converted (and as needed, omap3/4/am33xx converted) to be
 able to use the same code.

 We shouldn't introduce a new spl_mmc.c for example, we should modify the
 davinci structure to be able to re-use the same spl_mmc.c code to
 load/verify and let the next step, as needed happen.  I want to see
 omap be able to re-use SPI (since am33xx can do it too, and I've
 kludged the davinci stuff before) and potentially be able to re-use for
 example the gunzip support.  This I think is the easy set of steps to
 being able to reuse this fairly common SPL logic outside of not just TI
 parts but anyone else that wants it.
 
 Ok, I'll take this task. Unfortunately I have no too much free time for this
 job (summer, parents visit, new job and so on), so it may take a month or so.

OK, thanks.

 What about other patches?

The ddr/uart ones should make their way in soon and I've assigned the
SPI ones to the custodian in patchwork.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-09 Thread Mikhail Kshevetskiy 
On Mon, 9 Jul 2012 12:41:06 -0700
Tom Rini tr...@ti.com wrote:

 On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote:
  This patch allow us to have a universal spl that detects a boot
  device and select a corresponding boot algorithm for main u-boot part
  (SOC_DA8XX only)
  
  This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and
  drivers/mtd/spi/spi_spl_load.c for the following reasons:
   * avoid jump to main u-boot code just after its loading (required
 for the next patch: spl - add compressed u-boot image support)
   * makes a structure similar to omap3 sources
  
  Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
 
 I guess I wasn't clear enough when I asked the series to be split.  I
 want to see this portion turned into:
 a) Move omap-common spl bits to arch/arm/lib/
 b) davinci converted (and as needed, omap3/4/am33xx converted) to be
 able to use the same code.
 
 We shouldn't introduce a new spl_mmc.c for example, we should modify the
 davinci structure to be able to re-use the same spl_mmc.c code to
 load/verify and let the next step, as needed happen.  I want to see
 omap be able to re-use SPI (since am33xx can do it too, and I've
 kludged the davinci stuff before) and potentially be able to re-use for
 example the gunzip support.  This I think is the easy set of steps to
 being able to reuse this fairly common SPL logic outside of not just TI
 parts but anyone else that wants it.

Ok, I'll take this task. Unfortunately I have no too much free time for this
job (summer, parents visit, new job and so on), so it may take a month or so.

What about other patches?

Mikhail

 
 -- 
 Tom
 
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/3] arm/davinci: spl - boot device selection

2012-07-09 Thread Mikhail Kshevetskiy 
On Mon, 9 Jul 2012 13:08:07 -0700
Tom Rini tr...@ti.com wrote:

 On 07/09/2012 12:57 PM, Mikhail Kshevetskiy wrote:
  On Mon, 9 Jul 2012 12:41:06 -0700
  Tom Rini tr...@ti.com wrote:
  
  On 07/09/2012 11:53 AM, Mikhail Kshevetskiy wrote:
  This patch allow us to have a universal spl that detects a boot
  device and select a corresponding boot algorithm for main u-boot part
  (SOC_DA8XX only)
 
  This patch create copy copy of drivers/mtd/nand/nand_spl_load.c and
  drivers/mtd/spi/spi_spl_load.c for the following reasons:
   * avoid jump to main u-boot code just after its loading (required
 for the next patch: spl - add compressed u-boot image support)
   * makes a structure similar to omap3 sources
 
  Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
 
  I guess I wasn't clear enough when I asked the series to be split.  I
  want to see this portion turned into:
  a) Move omap-common spl bits to arch/arm/lib/
  b) davinci converted (and as needed, omap3/4/am33xx converted) to be
  able to use the same code.
 
  We shouldn't introduce a new spl_mmc.c for example, we should modify the
  davinci structure to be able to re-use the same spl_mmc.c code to
  load/verify and let the next step, as needed happen.  I want to see
  omap be able to re-use SPI (since am33xx can do it too, and I've
  kludged the davinci stuff before) and potentially be able to re-use for
  example the gunzip support.  This I think is the easy set of steps to
  being able to reuse this fairly common SPL logic outside of not just TI
  parts but anyone else that wants it.
  
  Ok, I'll take this task. Unfortunately I have no too much free time for this
  job (summer, parents visit, new job and so on), so it may take a month or
  so.
 
 OK, thanks.
 
  What about other patches?
 
 The ddr/uart ones should make their way in soon and I've assigned the
 SPI ones to the custodian in patchwork.
 
 -- 
 Tom

Thanks!

Mikhail
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot