[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Imre.Deak at nokia.com]

Hi,

I included a patch that adds support for CS boot mode recognition on
OMAP1610 Innovator and H2 boards.
Currently you have to build U-Boot either for CS0 or CS3 boot mode.
The patch adds new make targets for binaries that will check the boot
mode and set flash address accordingly. Also some board specific init
steps are skipped when booting from RAM.
The new targets are:
omap1610h2_cs_autoboot_config
omap1610inn_cs_autoboot_config

Imre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-u-boot-1.1.1-omap
Type: application/octet-stream
Size: 9842 bytes
Desc: patch-u-boot-1.1.1-omap
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040526/b81d5deb/attachment.obj 

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Wolfgang Denk]

In message <0F6832DAA2EE0B4D9281EDC36F09A8FC0FC3E6@esebe025.ntc.nokia.com> you wrote:
> 
> The new targets are:
> omap1610h2_cs_autoboot_config
> omap1610inn_cs_autoboot_config

Please explain where the name "autoboot" comes from.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Certainly there are things in life that money  can't  buy,  but  it's
very funny - Did you ever try buying them without money? - Ogden Nash

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Dave Peverley]

Wolfgang Denk wrote:
> Please explain where the name "autoboot" comes from.

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Wolfgang Denk]

In message <0F6832DAA2EE0B4D9281EDC36F09A8FC0FC3E6@esebe025.ntc.nokia.com> you wrote:
>
> I included a patch that adds support for CS boot mode recognition on
> OMAP1610 Innovator and H2 boards.
> Currently you have to build U-Boot either for CS0 or CS3 boot mode.
> The patch adds new make targets for binaries that will check the boot
> mode and set flash address accordingly. Also some board specific init
> steps are skipped when booting from RAM.
> The new targets are:
> omap1610h2_cs_autoboot_config
> omap1610inn_cs_autoboot_config

Thanks, added - except for the part which modifies common/env_flash.c

Here, instead  of  simply  initializing  the  relevant  variables  at
compile  time,  you  added code to do this at run time. I don't think
this is a good idea. Please explain why you are doing this, and which
problem you attempt to fix.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
THIS IS A 100% MATTER  PRODUCT:  In  the  Unlikely  Event  That  This
Merchandise  Should  Contact  Antimatter  in Any Form, a Catastrophic
Explosion Will Result.

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Imre.Deak at nokia.com]

Hi Wolfgang,

Sorry if the name is misleading, or not exact, I tried
to denote with it the following:
In order to set the correct base address for the flash
memory, U-Boot has to know somehow the boot mode of the
board. There are two of it. In the first ROM is mapped
to address 0 and the flash is to address 0x0C00000. In
the second mode the two are swapped, ROM is at
0x0C000000 and flash is at 0. Boot happens always from
address 0. In this way we can effectivly select (with
a dip switch) where we'd like to boot from.
At the moment U-Boot has to be configured to either of
the two modes. There are 3 make targets for this, first
and third being equivalent:

omap1610h2_config ( ==omap1610h2_cs3_boot_config )
omap1610h2_cs0_boot_config
omap1610h2_cs3_boot_config

It is possible however to determine the boot mode
automatically, from an OMAP status register and thus set
the flash base address correctly. For this I added a
new target omap1610h2_cs_autoboot_config.
Maybe it should be a CONFIG variable instead of 4
targets for each board (H2, Innovator), like
CONFIG_OMAP_BOOTMODE_CS0
CONFIG_OMAP_BOOTMODE_CS3
CONFIG_OMAP_BOOTMODE_DETECT
?

Regards,
Imre

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: 26 May, 2004 20:25
> To: Deak Imre (Nokia-M/Helsinki)
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] OMAP1610 cs boot mode 
> 
> 
> In message 
> <0F6832DAA2EE0B4D9281EDC36F09A8FC0FC3E6@esebe025.ntc.nokia.com
> > you wrote:
> > 
> > The new targets are:
> > omap1610h2_cs_autoboot_config
> > omap1610inn_cs_autoboot_config
> 
> Please explain where the name "autoboot" comes from.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> Certainly there are things in life that money  can't  buy,  but  it's
> very funny - Did you ever try buying them without money? - Ogden Nash
> 

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Wolfgang Denk]

In message <0F6832DAA2EE0B4D9281EDC36F09A8FC0FC3EC@esebe025.ntc.nokia.com> you wrote:
> 
> Sorry if the name is misleading, or not exact, I tried

Well, I  think  it  needs  some  explanation  -  at  least  I  didn't
understand it.

> It is possible however to determine the boot mode
> automatically, from an OMAP status register and thus set
> the flash base address correctly. For this I added a
> new target omap1610h2_cs_autoboot_config.
> Maybe it should be a CONFIG variable instead of 4
> targets for each board (H2, Innovator), like
> CONFIG_OMAP_BOOTMODE_CS0
> CONFIG_OMAP_BOOTMODE_CS3
> CONFIG_OMAP_BOOTMODE_DETECT
> ?

Te question is: how many people are likely to change this?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Get back to your stations!"
"We're beaming down to the planet, sir."
	-- Kirk and Mr. Leslie, "This Side of Paradise",
	   stardate 3417.3

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Imre.Deak at nokia.com]

Hi Wolfgang,

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: 09 June, 2004 18:39
> To: Deak Imre (Nokia-M/Helsinki)
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] OMAP1610 cs boot mode 
>
> > Maybe it should be a CONFIG variable instead of 4
> > targets for each board (H2, Innovator), like
> > CONFIG_OMAP_BOOTMODE_CS0
> > CONFIG_OMAP_BOOTMODE_CS3
> > CONFIG_OMAP_BOOTMODE_DETECT
> > ?
> 
> Te question is: how many people are likely to change this?
> 

Here it's quite a useful option, since you need only one
binary instead of two, to boot in either of the two modes.
I suggest that we keep the Makefile targets as they are:
omap1610h2_cs_autoboot_config
omap1610inn_cs_autoboot_config

> 
> Thanks, added - except for the part which modifies common/env_flash.c
> 
> Here, instead  of  simply  initializing  the  relevant  variables  at
> compile  time,  you  added code to do this at run time. I don't think
> this is a good idea. Please explain why you are doing this, and which
> problem you attempt to fix.
> 

It needs to be done in runtime since CFG_FLASH_BASE is defined as a
variable when one of the new targets is selected:

include/configs/omap1610inn.h:

[...]

#ifdef CONFIG_CS_AUTOBOOT                       /* Determine CS assignment in runtime */

#ifndef __ASSEMBLY__
extern unsigned long omap_flash_base;           /* set in flash__init */
#endif
#define CFG_FLASH_BASE          omap_flash_base

[...]

#endif

Regards,
Imre

[U-Boot-Users] [PATCH] OMAP1610 cs boot mode

[Wolfgang Denk]

In message <0F6832DAA2EE0B4D9281EDC36F09A8FC0FB1D9@esebe025.ntc.nokia.com> you wrote:
> 
> > Thanks, added - except for the part which modifies common/env_flash.c
> >
> > Here, instead  of  simply  initializing  the  relevant  variables  at
> > compile  time,  you  added code to do this at run time. I don't think
> > this is a good idea. Please explain why you are doing this, and which
> > problem you attempt to fix.
> 
> It needs to be done in runtime since CFG_FLASH_BASE is defined as a
> variable when one of the new targets is selected:

Did you actually test this on other hardware?

My concern is: the first  access  to  trhe  environment  happen  long
before  relocation  to  RAM,  and  during  this phase we don't have a
writable data segment.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A failure will not appear until a unit has passed final inspection.