Re: [U-Boot] [PATCH] [UBI] UBI command support

[Wolfgang Denk]

Dear Kyungmin Park,

In message <[EMAIL PROTECTED]> you wrote:
...
> >> + printf("Unknown UBI command or invalid number of arguments\n");
> >
> > Print usage message instead.
> 
> How to display usage?

printf ("Usage:\n%s\n", cmdtp->usage);

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Misquotation is, in fact, the pride and privilege of the  learned.  A
widely-read  man  never  quotes  accurately,  for  the rather obvious
reason that he has read too widely.
- Hesketh Pearson _Common Misquotations_ introduction
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] AT91SAM9260 and Micrel KSZ8041

[Ing.G.Morandi (Portatile)]

>  I wanted to check to see if anyone
> is working with the Micrel KSZ8041, and whether the lights should be
> working, and if they had gotten it working under Linux.

Yes, we're currently and succesfully using KSZ8041 together with 
AT91SAM9260. We have tested it with both u-boot and linux (we're using 
2.6.21 kernel) and without big patches.

I suggest you to double check your hardware platform (since the KSZ8041 
comes in QFN package with termal pad on bottom side). You probably have some 
unsoldered pin.

Regards

Gianfranco

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

[U-Boot] AT91SAM9260 and Micrel KSZ8041

[Kevin Greer]

Hello,

I am working with a custom board based on the AT91SAM9260 with a Micrel
KSZ8041 physical layer.  The ethernet appears to work fine in u-boot, but
neither of the lights on the jack are working, however I can tftp files
through the ethernet port.  My bigger problem is that in Linux I cannot
connect to my network, all of the RX packets show are listed as errors.  I
am trying to rule-out a hardware issue so I wanted to check to see if anyone
is working with the Micrel KSZ8041, and whether the lights should be
working, and if they had gotten it working under Linux.  Also, if anyone
knows of a difference between the u-boot ethernet and linux kernel ethernet
that may be causing the problem I would appreciate any insight.  I have
tried the 2.6.24, 2.6.25, and 2.6.27 kernels.

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

[U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx

[Kyungmin Park]

Move machine specific code to smdk6400.
Some board use OneNAND instead of NAND.

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/board/samsung/smdk6400/lowlevel_init.S 
b/board/samsung/smdk6400/lowlevel_init.S
index e0119a7..53d9125 100644
--- a/board/samsung/smdk6400/lowlevel_init.S
+++ b/board/samsung/smdk6400/lowlevel_init.S
@@ -104,6 +104,13 @@ lowlevel_init:
bl nand_asm_init
 #endif
 
+   /* Memory subsystem address 0x7e00f120 */
+   ldr r0, =ELFIN_MEM_SYS_CFG
+
+   /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */
+   mov r1, #0xd
+   str r1, [r0]
+
bl  mem_ctrl_asm_init
 
 /* Wakeup support. Don't know if it's going to be used, untested. */
diff --git a/cpu/arm1176/s3c64xx/cpu_init.S b/cpu/arm1176/s3c64xx/cpu_init.S
index 08bda99..32bb467 100644
--- a/cpu/arm1176/s3c64xx/cpu_init.S
+++ b/cpu/arm1176/s3c64xx/cpu_init.S
@@ -28,13 +28,6 @@
 
.globl mem_ctrl_asm_init
 mem_ctrl_asm_init:
-   /* Memory subsystem address 0x7e00f120 */
-   ldr r0, =ELFIN_MEM_SYS_CFG
-
-   /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */
-   mov r1, #0xd
-   str r1, [r0]
-
/* DMC1 base address 0x7e001000 */
ldr r0, =ELFIN_DMC1_BASE
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Hangs at relocation on 460EX Target

[Stefan Roese]

On Tuesday 21 October 2008, Ayman M. El-Khashab wrote:
> > How about reading the code?
>
> (Looking at canyonlands.h)
>
> Ok, I took a look at this and the autocalibration is not obvious.  It looks
> like there is a currently a hardcoded RQDC value of 8038.  If this is
> undefined then the code will go into the autocalibration mode.  So
> I've undefined it and sure enough it goes into autocalibration.  The part
> that is odd is that the autocal does not work on the Canyonlands board.  If
> it is enabled, then the Canyonlands fails in the same way as our hardware.
> I.e. right at the time of relocation, it just hangs.  When set back to the
> hardcoded value, the canyonlands works fine.
>
> Perusing the code, the only sort of exception that I noticed was one for
> the Katmai.  During operation I don't see the code fail to find the window,
> so it appears that it finds a suitable value.  When examined with the
> abatron it looks like a value is set into the mfio_rqdc register.
>
> So I am somewhat puzzled.  It is not obvious to me why the autocal is
> failing to work on the canyonlands.

Yes, there have been issues with the "old" autocalibration code on some boards. 
That's one 
reason that AMCC provided a new version just a few weeks ago:

075d0b81e896e8735ae26372cd384f87cbd24e41

ppc4xx: IBM Memory Controller DDR autocalibration routines

Alternate SDRAM DDR autocalibration routine that can be generically used
for any PPC4xx chips that have the IBM SDRAM Controller core allowing for
support of more DIMM/memory chip vendors and gets the DDR autocalibration
values which give the best read latency performance (SDRAM0_RDCC.[RDSS]).

Two alternate SDRAM DDR autocalibration algoritm are provided in this patch,
"Method_A" and "Method_B".  DDR autocalibration Method_A scans the full 
range
of possible PPC4xx  SDRAM Controller DDR autocalibration values and takes a
lot longer to run than Method_B.  Method_B executes in the same amount of 
time
as the currently existing DDR autocalibration routine, i.e. 1 second or so.
Normally Method_B is used and it is set as the default method.

The current U-Boot PPC4xx DDR autocalibration code calibrates the IBM SDRAM
Controller registers.[bit-field]:
1)  SDRAM0_RQDC.[RQFD]
2)  SDRAM0_RFDC.[RFFD]

This alternate PPC4xx DDR autocalibration code calibrates the following
IBM SDRAM Controller registers.[bit-field]:

1)  SDRAM0_WRDTR.[WDTR]
2)  SDRAM0_CLKTR.[CKTR]
3)  SDRAM0_RQDC.[RQFD]
4)  SDRAM0_RFDC.[RFFD]

and will also use the calibrated settings of the above four registers that
produce the best "Read Sample Cycle Select" value in the SDRAM0_RDCC.[RDSS]
register.[bit-field].

Signed-off-by: Adam Graham <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>


It's currently only used on Kilauea (405EX) but I think it should work
on Canyonlands as well. So I suggest you give this version a try. IIRC,
it also has some advanced debugging mechanisms that you could use to track
down the problems.

Here an extract from kilauea.h:

/*
 * CONFIG_PPC4xx_DDR_AUTOCALIBRATION
 *
 * Note: DDR Autocalibration Method_A scans the full range of possible PPC4xx
 *   SDRAM Controller DDR autocalibration values and takes a lot longer
 *   to run than Method_B.
 * (See the Method_A and Method_B algorithm discription in the file:
 *  cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c)
 * Define CONFIG_PPC4xx_DDR_METHOD_A to use DDR autocalibration Method_A
 *
 * DDR Autocalibration Method_B is the default.
 */
#define CONFIG_PPC4xx_DDR_AUTOCALIBRATION   /* IBM DDR autocalibration */
#define DEBUG_PPC4xx_DDR_AUTOCALIBRATION/* dynamic DDR autocal debug */
#undef  CONFIG_PPC4xx_DDR_METHOD_A


Give it a try in your board (and Canyonlands as well) and let me know if
this helps or not.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [UBI] Basic Unsorted Block Image (UBI) support (part 1)

[Kyungmin Park]

Dear Wolfgang and Stefan,

On Tue, Oct 21, 2008 at 10:16 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Stefan Roese,
>
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> That's directly imported from the Linux source. Most of your comments below
>> also deal with this Linux code copying. I personally think it is a good idea
>> to clone the code from Linux instead of writing a U-Boot specific UBI driver.
>> We have done this before on other occasions and it makes perfect sense here
>> too from my point of view. It makes porting easier and faster and less error
>> prone and even more important, it makes porting of new versions, fixes etc
>> easier.
>
> We agree on that. So maybe we should send coding style cleanup patches
> for the Linux kenrel?
>
>
>> > > + * Core registration and callback routines for MTD
>> > > + * drivers and users.
>> > > + */
>> >
>> > GPL header missing - here and in many other files.

I added the GPL.

>
> This *is* a serious issue. And I don;t care  wether  the  code  comes
> from  Linux or not, but I will not accept any code without absolutley
> clear licensing conditions.
>
>> > Need "{...}" for multi-line statements.
>>
>> Again from the Linux original source. When we start changing this code 
>> because
>> of coding-style issue, it will get very hard to compare those versions and
>> add fixes in the future. So I vote for keeping the code as is. It's not that
>> ugly, at least from my understanding.
>
> It is a clear violation of Linux Coding Style requirements.
>
> If we don;t want to fix it here, I suggest to fixit at the origin,
> i.e. in Linux.
>
>> > > +++ b/drivers/mtd/mtdpart.c
>> > > @@ -0,0 +1,531 @@
>> > > +/*
>> > > + * Simple MTD partitioning layer
>> >
>> > Hm... We were talking about UBI support.
>> >
>> > Do we really have to pull in the whole MTD layer from Linux for this?
> ...
>
>> > Please do not add dead code.

It's needed. almost flash related code except the NOR, are based on
MTD and uses.
Event though it's only compiled UBI command, it will be changed.
Now partition codes use own implementation at u-boot, I think it's
better MTD partition code.

>>
>> Here I'm not sure which version I prefer. The one Kyungmin used, disabling > 
>> the
>> not needed code via #if 0 (or something else, like #if UBI_LINUX), or
>> completely removing it. Both has some advantages. But again for comparison>
>> with the original Linux source it's perhaps better to just disable the code> 
>> .
>> An "#if UBI_LINIX" is probably better than on "#if 0" though.

I change to use UBI_LINUX instead of if 0.

>
> There is two things I am concerned about:
>
> 1) Do we really need all these files?
> 2) Do we really need all of this code?
>
> Lots of the code that was left in was obviously dealing with features
> we don;t have in U-Boot, and will not have: concepts like  user  IDs,
> file permissions, major and minor numbers, etc.
>
>> Of course we haven't. But it's hard to draw the line *if* you decide to
>> include the Linux source. Most OS functions (like spin_lock()...) are defin> 
>> ed
>> to no-ops in ubi_uboot.h. So it doesn't really increase the code size for
>> U-Boot. It just keeps the source in-line with the Linux version.
>
> On the other hand it makes it semi-impossible to review the  code  in
> U-Boot  context,  or  even to get an understanding of flow of control
> etc.
>

Basically I think if we use the imported code. we don't modify code
itself. Instead we give some adaptation layer or wrapper. In this case
I use the latter. ubi_uboot.h wrapped the UBI kernel code and can run
it on u-boot. Of course it disables the some linux specific kernel if
can't wrap.

Meanwhile who is the main users of this modules? It's linux kernel. It
means users can familiar with kernel UBI code and they can use it more
easily. They don't need to understand the UBI code at u-boot.

Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] booting the kernel

[Roman Mashak]

Hello Mathieu

2008/10/21 Mathieu Dube <[EMAIL PROTECTED]>:
> the kernel I use is for freescale imx31_litekit. I've booted it using the
> logicpd loader so I know it works.
>
> I use the arch/arm/boot/Image with mkimage like this:
>
> mkimage -A arm -O linux -T kernel -C none -a 8600 -e 8600 -d Image

   
Double check these addresses. The convention is to load the Linux
kernel at the base of physical RAM plus an offset of 0x8000 (32K),
which allows enough room for the parameters area (typically placed at
offset 0x100), page exception vectors and page tables.

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

Re: [U-Boot] [PATCH v2] pci: Allow for PCI addresses to be 64-bit

[Becky Bruce]

On Oct 21, 2008, at 4:48 PM, Kumar Gala wrote:

> PCI bus is inherently 64-bit.  While not all system require access to
> the full 64-bit PCI address range some do.  This allows those systems
> to enable the full PCI address width via CONFIG_SYS_PCI_64BIT.

I suspect this isn't complete, but I have no proof :)  As an example,  
what are the mem and io args to pci_hose_config_device?  Is unsigned  
long still OK there?  (it may well be - I haven't looked at how  
they're used).

A few comments below.

>
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
>
> moved to CONFIG_SYS_PCI_64BIT instead of CONFIG_PCI_64BIT
>
> - k
>
> drivers/pci/pci.c  |4 ++--
> drivers/pci/pci_auto.c |   22 +++---
> include/pci.h  |   24 
> 3 files changed, 29 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 41780db..127d50f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -223,7 +223,7 @@ unsigned long pci_hose_phys_to_bus (struct  
> pci_controller *hose,
>   unsigned long flags)
> {
>   struct pci_region *res;
> - unsigned long bus_addr;
> + pci_addr_t bus_addr;
>   int i;
>
>   if (!hose) {

Is there a reason pci_hose_phys_to_bus() isn't now returning a  
pci_addr_t?

>
> @@ -252,7 +252,7 @@ Done:
> }
>
> phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
> -  unsigned long bus_addr,
> +  pci_addr_t bus_addr,
>unsigned long flags)
> {
>   struct pci_region *res;
> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> index 3844359..547ce5b 100644
> --- a/drivers/pci/pci_auto.c
> +++ b/drivers/pci/pci_auto.c
> @@ -52,7 +52,7 @@ void pciauto_region_align(struct pci_region *res,  
> unsigned long size)
>
> int pciauto_region_allocate(struct pci_region* res, unsigned int  
> size, unsigned int *bar)

Is this size really OK as an unsigned int?  There are a lot of  
"unsigned int size" declarations in this file; I haven't looked at  
them all.

- snip --

> diff --git a/include/pci.h b/include/pci.h
> index 1c8e216..d79f26a 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -312,13 +312,21 @@
>
> #include 
>
> +#ifdef CONFIG_SYS_PCI_64BIT
> +typedef u64 pci_addr_t;
> +typedef u64 pci_size_t;
> +#else
> +typedef u32 pci_addr_t;
> +typedef u32 pci_size_t;
> +#endif
> +
> struct pci_region {
> - unsigned long bus_start;/* Start on the bus */
> - phys_addr_t phys_start; /* Start in physical address 
> space */
> - unsigned long size; /* Size */
> - unsigned long flags;/* Resource flags */
> + pci_addr_t bus_start;   /* Start on the bus */
> + phys_addr_t phys_start; /* Start in physical address space */
> + pci_size_t size;/* Size */
> + unsigned long flags;/* Resource flags */
>
> - unsigned long bus_lower;
> + pci_addr_t bus_lower;
> };
>
> #define PCI_REGION_MEM0x  /* PCI memory space */
> @@ -330,9 +338,9 @@ struct pci_region {
> #define PCI_REGION_RO 0x0200  /* Read-only memory */
>
> extern __inline__ void pci_set_region(struct pci_region *reg,
> -   unsigned long bus_start,
> +   pci_addr_t bus_start,
> phys_addr_t phys_start,
> -   unsigned long size,
> +   pci_size_t size,
> unsigned long flags) {
>   reg->bus_start  = bus_start;
>   reg->phys_start = phys_start;
> @@ -433,7 +441,7 @@ extern __inline__ void pci_set_ops(struct  
> pci_controller *hose,
> extern void pci_setup_indirect(struct pci_controller* hose, u32  
> cfg_addr, u32 cfg_data);
>
> extern phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
> - unsigned long addr, unsigned long 
> flags);
> + pci_addr_t addr, unsigned long flags);
> extern unsigned long pci_hose_phys_to_bus(struct pci_controller* hose,
> phys_addr_t addr, unsigned long 
> flags);
>

Should this return pci_addr_t?

Cheers,
Becky

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

Re: [U-Boot] [PATCH] [UBI] UBI command support

[Kyungmin Park]

Dear Wolfgang,

On Tue, Oct 21, 2008 at 7:24 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Kyungmin Park,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> UBI command support
>>
>> Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
> ...
>> +++ b/common/cmd_ubi.c
>> @@ -0,0 +1,535 @@
>> +/*
>> + * Unsorted Block Image commands
>> + */
>> +
>> +#include 
>> +#include 
>
> GPL header missing.

Okay I added.

>
>> +/* board/\*\/ubi.c */
>
> What's the '\'s there?
>
>> +extern int ubi_board_scan(void);
>
> Please move the prototypes to some header file.
>
>> +/* drivers/mtd/ubi/build.c */
>> +extern struct ubi_device *ubi_devices[];

Moved to proper header files.

>> +
>> +/* Private own data */
>> +static struct ubi_device *ubi;
>> +static int ubi_initialized;
>> +
>> +static void ubi_dump_vol_info(const struct ubi_volume *vol)
>> +{
>> + dbg_msg("volume information dump:");
>> + dbg_msg("vol_id  %d", vol->vol_id);
>> + dbg_msg("reserved_pebs   %d", vol->reserved_pebs);
>> + dbg_msg("alignment   %d", vol->alignment);
>> + dbg_msg("data_pad%d", vol->data_pad);
>> + dbg_msg("vol_type%d", vol->vol_type);
>> + dbg_msg("name_len%d", vol->name_len);
>> + dbg_msg("usable_leb_size %d", vol->usable_leb_size);
>> + dbg_msg("used_ebs%d", vol->used_ebs);
>> + dbg_msg("used_bytes  %lld", vol->used_bytes);
>> + dbg_msg("last_eb_bytes   %d", vol->last_eb_bytes);
>> + dbg_msg("corrupted   %d", vol->corrupted);
>> + dbg_msg("upd_marker  %d", vol->upd_marker);
>
> Please use the standard  debug()  macro.

It's not debug message, it's ubi msg. I fixed.

>
>> +static int ustrtoul(const char *cp, char **endp, unsigned int base)
>
> Maybe we should add this to some global place, like lib_generic ?

Move to lib_generic/vsprintf.c

>
>> +unsigned long result = simple_strtoul(cp, endp, base);
>> +switch (**endp) {
>> +case 'G' :
>> +result *= 1024;
>
> Please add a
>/* fall through */
> comment to make clkear that it is intentional not to have a "break;"
> here.
>
>> +case 'M':
>> +result *= 1024;
>
> Ditto.

Did

>
>> +static int verify_mkvol_req(const struct ubi_device *ubi,
>> + const struct ubi_mkvol_req *req)
>> +{
> ...
>> +bad:
>> + printf("bad volume creation request");
>> +//  ubi_dbg_dump_mkvol_req(req);
>> + return err;
>
> No C++ comments, please. And please don;t add dead code either.

Yes I remove it

>
>> + tbuf = vmalloc(tbuf_size);
>
> Why do we need new alloc() stuff?
>
>> +
>> + vfree(tbuf);
>
> Ditto?

Use malloc & free.

>
>> +static int do_ubi(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
>> +{
>> + size_t size = 0;
>> + ulong addr = 0;
>> + int err = 0;
>> +
>> + if (!ubi_initialized) {
>> + err = ubi_board_scan();
>> + if (err) {
>> + printf("ubi initialize error %d\n", err);
>
> "UBI init error" -- maybe we can decode the error number into some
> string?
>
>> + /* E.g., create volume size type */
>> + if (argc == 5) {
>> + if (strncmp(argv[4], "s", 1) == 0)
>> + dynamic = 0;
>> + else if (strncmp(argv[4], "d", 1) != 0) {
>> + printf("You give wrong type\n");
>
> "Incorrect type". It would also be helpful if the incorrect parameter
> gets printed, so the user sees what he passed.
>
>> + return 1;
>> + }
>> + argc--;
>> + }
>> + /* E.g., create volume size */
>> + if (argc == 4) {
>> + err = parse_num(&size, argv[3]);
>> + if (err) {
>> + printf("You give correct size\n");
>
> "Incorrect size". Please also print incorrect argument value.
>
>> + if (strncmp(argv[1], "write", 5) == 0) {
>> + if (argc < 5) {
>> + printf("You give wrong parameters\n");
>
> Print usage message instead.
>
>> + }
>> +
>> + addr = simple_strtoul(argv[2], NULL, 16);
>> + err = parse_num(&size, argv[4]);
>> + if (err) {
>> + printf("You give wrong size\n");
>
> See above.
>
>> + if (err) {
>> + printf("You give wrong size\n");
>
> Ditto.
>
>> + printf("Unknown UBI command or invalid number of arguments\n");
>
> Print usage message instead.
>

How to display usage?

Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/6] i.MX31: Add basic support for Freescale's i.MX31 PDK board.

[Fabio Estevam]

Hi Jean-Christophe,

--- On Thu, 10/16/08, Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> 
wrote:

> From: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
> Subject: Re: [U-Boot] [PATCH v3 3/6] i.MX31: Add basic support for 
> Freescale's i.MX31 PDK board.
> To: "Alan Carvalho de Assis" <[EMAIL PROTECTED]>
> Cc: u-boot@lists.denx.de, "Magnus Lilja" <[EMAIL PROTECTED]>
> Date: Thursday, October 16, 2008, 5:17 AM
> On 14:44 Wed 15 Oct , Alan Carvalho de Assis wrote:
> > Hi Jean-Christophe,
> > 
> > On Wed, Oct 15, 2008 at 2:04 PM, Jean-Christophe
> PLAGNIOL-VILLARD
> > <[EMAIL PROTECTED]> wrote:
> > > On 08:51 Wed 15 Oct , Alan Carvalho de Assis
> wrote:
> > >> Hi Jean-Christophe,
> > >>
> > >> On Mon, Oct 13, 2008 at 5:49 AM,
> Jean-Christophe PLAGNIOL-VILLARD
> > >> <[EMAIL PROTECTED]> wrote:
> > >> >> Is there any special reason it was
> not added to the master branch
> > >> >> yet?
> > >> >
> > >> >>
> > >> > As we discuss on IRC this board will be
> merge when it can boot from a storage
> > >> >
> > >>
> > >> Using some patches I sent we can boot it from
> storage, even without
> > >> the MTD NAND driver.
> > > Could you specify which one? pease
> > >
> > 
> > Please check the following thread:
> >
> http://lists.denx.de/pipermail/u-boot/2008-October/041355.html
> > 
> > I can boot from NAND Flash on iMX31PDK board after
> applying this
> > series of patches.
> 
> Thanks,
> I've seen this patch I put some comment on it asap

Have you had a chance to review Alan's patch for booting MX31PDK from NAND 
Flash? 

Thanks,

Fabio Estevam




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

Re: [U-Boot] [PATCH] [ARM] Apollon UBI support

[Ben Warren]

Hi Kyungmin,

Kyungmin Park wrote:
> Dear Wolfgang,
>
>   
>>> -# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=64M 
>>> console=ttyS0,115200n8 
>>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off
>>>  nfsroot=/tftpboot/nfsroot profile=2"
>>> +# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=64M 
>>> console=ttyS0,115200n8 
>>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off
>>>  nfsroot=/tftpboot/nfsroot profile=2 lpj=1646592 ubi.mtd=4"
>>>  #else
>>> -# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=128M 
>>> console=ttyS0,115200n8 
>>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off
>>>  nfsroot=/tftpboot/nfsroot profile=2"
>>> +# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=128M 
>>> console=ttyS0,115200n8 
>>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off
>>>  nfsroot=/tftpboot/nfsroot profile=2 lpj=1646592 ubi.mtd=4"
>>>   
>> Maximum line length exceeded.
>>
>> 
>
> Fixed all commented except one.
> I run the checkpatch.pl and passed.
>
>   
>> And please do not hard-code network parameters into U-Boot.
>>
>> 
>
> Then how to define the network IP at bootargs? please give some example?
>   
You set environment variables (ie. setenv bootcmd ...)

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

Re: [U-Boot] [PATCH] [ARM] Apollon UBI support

[Kyungmin Park]

Dear Wolfgang,

>> -# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=64M 
>> console=ttyS0,115200n8 
>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off 
>> nfsroot=/tftpboot/nfsroot profile=2"
>> +# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=64M 
>> console=ttyS0,115200n8 
>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off 
>> nfsroot=/tftpboot/nfsroot profile=2 lpj=1646592 ubi.mtd=4"
>>  #else
>> -# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=128M 
>> console=ttyS0,115200n8 
>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off 
>> nfsroot=/tftpboot/nfsroot profile=2"
>> +# define CONFIG_BOOTARGS "root=/dev/nfs rw mem=128M 
>> console=ttyS0,115200n8 
>> ip=192.168.116.25:192.168.116.1:192.168.116.1:255.255.255.0:apollon:eth0:off 
>> nfsroot=/tftpboot/nfsroot profile=2 lpj=1646592 ubi.mtd=4"
>
> Maximum line length exceeded.
>

Fixed all commented except one.
I run the checkpatch.pl and passed.

> And please do not hard-code network parameters into U-Boot.
>

Then how to define the network IP at bootargs? please give some example?

Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-mpc83xx.git

[Kim Phillips]

Dear Wolfgang Denk,

Please pull:

The following changes since commit def0819e920b05b34b56d8b42e1e43d9b89a52d6:
  Wolfgang Denk (1):
FDT: don't use private kernel header files

are available in the git repository at:

  git://git.denx.de/u-boot-mpc83xx.git master

Anton Vorontsov (8):
  mpc83xx: mpc8360emds: rework LBC SDRAM setup
  mpc83xx: fix serdes setup for the MPC8378E boards
  mpc83xx: serdes: add forgotten shifts for rfcks
  mpc83xx: add TSECs' HRCWH masks for MPC837x processors
  mpc83xx: add SGMII riser module support for the MPC8378E-MDS boards
  mpc83xx: fix PCI scan hang on the standalone MPC837xE-MDS boards
  mpc83xx: add ELBC NAND support for the MPC837XEMDS boards
  mpc83xx: add support for switching between USB Host/Function for 
MPC837XEMDS

Richard Retanubun (1):
  mpc83xx: Removed #ifdef CONFIG_MPC834X dependency on upmconfig function

 board/freescale/mpc8360emds/mpc8360emds.c |   39 +--
 board/freescale/mpc837xemds/mpc837xemds.c |  172 -
 board/freescale/mpc837xemds/pci.c |3 +
 board/freescale/mpc837xerdb/mpc837xerdb.c |2 +-
 cpu/mpc83xx/cpu.c |5 -
 cpu/mpc83xx/serdes.c  |2 +-
 include/asm-ppc/fsl_serdes.h  |   10 +-
 include/configs/MPC8360EMDS.h |   25 ++---
 include/configs/MPC837XEMDS.h |   20 +++-
 include/mpc83xx.h |2 +
 10 files changed, 234 insertions(+), 46 deletions(-)

Thanks,

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

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Kumar Gala]

On Oct 21, 2008, at 2:44 PM, Jerry Van Baren wrote:

>
> I've been hacking at cmd_bootm.c and image.c.  The direction I'm  
> hacking in is:
> * Move boot_* stuff from image.c into cmd_bootm.c
>  - Calling out to another file to a function unused in that file?  
> Ugly.
> * Move the FIT stuff out of image.c into a new file fit_image.c
>  - The resulting files are more cohesive and less BIG.
> * Move the im* commands out of cmd_bootm.c into a new file cmd_image.c
>  - At one time, I was of the opinion that "bootm (loados|ramdisk|fdt)"
>  should be "ldimage (os|ramdisk|fdt)".  I'm less sure of myself,
>  but have not totally discarded the opinion.
>  - Looking in cmd_bootm.c for im* commands is rather unintuitive.

these all sound like good things.  I've posted a "clean" patchset for  
Wolfgang to apply to 'master' or 'testing'

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

[U-Boot] [PATCH 4/4] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Kumar Gala]

Added the ability to config out bootm support for Linux, NetBSD, RTEMS

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 common/cmd_bootm.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 1b2dfc4..47f9b45 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -103,13 +103,23 @@ extern int do_reset (cmd_tbl_t *cmdtp, int flag, int 
argc, char *argv[]);
 typedef int boot_os_fn (int flag, int argc, char *argv[],
bootm_headers_t *images); /* pointers to os/initrd/fdt 
*/
 
+#define CONFIG_BOOTM_LINUX 1
+#define CONFIG_BOOTM_NETBSD 1
+#define CONFIG_BOOTM_RTEMS 1
+
+#ifdef CONFIG_BOOTM_LINUX
 extern boot_os_fn do_bootm_linux;
+#endif
+#ifdef CONFIG_BOOTM_NETBSD
 static boot_os_fn do_bootm_netbsd;
+#endif
 #if defined(CONFIG_LYNXKDI)
 static boot_os_fn do_bootm_lynxkdi;
 extern void lynxkdi_boot (image_header_t *);
 #endif
+#ifdef CONFIG_BOOTM_RTEMS
 static boot_os_fn do_bootm_rtems;
+#endif
 #if defined(CONFIG_CMD_ELF)
 static boot_os_fn do_bootm_vxworks;
 static boot_os_fn do_bootm_qnxelf;
@@ -121,12 +131,18 @@ static boot_os_fn do_bootm_integrity;
 #endif
 
 boot_os_fn * boot_os[] = {
+#ifdef CONFIG_BOOTM_LINUX
[IH_OS_LINUX] = do_bootm_linux,
+#endif
+#ifdef CONFIG_BOOTM_NETBSD
[IH_OS_NETBSD] = do_bootm_netbsd,
+#endif
 #ifdef CONFIG_LYNXKDI
[IH_OS_LYNXOS] = do_bootm_lynxkdi,
 #endif
+#ifdef CONFIG_BOOTM_RTEMS
[IH_OS_RTEMS] = do_bootm_rtems,
+#endif
 #if defined(CONFIG_CMD_ELF)
[IH_OS_VXWORKS] = do_bootm_vxworks,
[IH_OS_QNX] = do_bootm_qnxelf,
@@ -1161,6 +1177,7 @@ static void fixup_silent_linux ()
 /* OS booting routines */
 /***/
 
+#ifdef CONFIG_BOOTM_NETBSD
 static int do_bootm_netbsd (int flag, int argc, char *argv[],
bootm_headers_t *images)
 {
@@ -1246,6 +1263,7 @@ static int do_bootm_netbsd (int flag, int argc, char 
*argv[],
 
return 1;
 }
+#endif /* CONFIG_BOOTM_NETBSD*/
 
 #ifdef CONFIG_LYNXKDI
 static int do_bootm_lynxkdi (int flag, int argc, char *argv[],
@@ -1269,6 +1287,7 @@ static int do_bootm_lynxkdi (int flag, int argc, char 
*argv[],
 }
 #endif /* CONFIG_LYNXKDI */
 
+#ifdef CONFIG_BOOTM_RTEMS
 static int do_bootm_rtems (int flag, int argc, char *argv[],
   bootm_headers_t *images)
 {
@@ -1299,6 +1318,7 @@ static int do_bootm_rtems (int flag, int argc, char 
*argv[],
 
return 1;
 }
+#endif /* CONFIG_BOOTM_RTEMS */
 
 #if defined(CONFIG_CMD_ELF)
 static int do_bootm_vxworks (int flag, int argc, char *argv[],
-- 
1.5.5.1

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

[U-Boot] [PATCH 3/4] bootm: support subcommands in linux ppc bootm

[Kumar Gala]

Add support for 'bdt', 'cmdline', 'prep' to the linux PPC bootm.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 lib_ppc/bootm.c |  271 +++
 1 files changed, 175 insertions(+), 96 deletions(-)

diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 6c9cf9e..fce4eff 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -47,6 +47,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
 extern ulong get_effective_memsize(void);
 static ulong get_sp (void);
 static void set_clocks_in_mhz (bd_t *kbd);
@@ -55,6 +56,74 @@ static void set_clocks_in_mhz (bd_t *kbd);
 #define CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE   (768*1024*1024)
 #endif
 
+static void boot_jump_linux(bootm_headers_t *images)
+{
+   void(*kernel)(bd_t *, ulong r4, ulong r5, ulong r6,
+ ulong r7, ulong r8, ulong r9);
+#ifdef CONFIG_OF_LIBFDT
+   char *of_flat_tree = images->ft_addr;
+#endif
+
+   kernel = (void (*)(bd_t *, ulong, ulong, ulong,
+  ulong, ulong, ulong))images->ep;
+   debug ("## Transferring control to Linux (at address %08lx) ...\n",
+   (ulong)kernel);
+
+   show_boot_progress (15);
+
+#if defined(CONFIG_SYS_INIT_RAM_LOCK) && !defined(CONFIG_E500)
+   unlock_ram_in_cache();
+#endif
+
+#if defined(CONFIG_OF_LIBFDT)
+   if (of_flat_tree) { /* device tree; boot new style */
+   /*
+* Linux Kernel Parameters (passing device tree):
+*   r3: pointer to the fdt
+*   r4: 0
+*   r5: 0
+*   r6: epapr magic
+*   r7: size of IMA in bytes
+*   r8: 0
+*   r9: 0
+*/
+#if defined(CONFIG_85xx) || defined(CONFIG_440)
+ #define EPAPR_MAGIC   (0x45504150)
+#else
+ #define EPAPR_MAGIC   (0x65504150)
+#endif
+
+   debug ("   Booting using OF flat tree...\n");
+   (*kernel) ((bd_t *)of_flat_tree, 0, 0, EPAPR_MAGIC,
+  CONFIG_SYS_BOOTMAPSZ, 0, 0);
+   /* does not return */
+   } else
+#endif
+   {
+   /*
+* Linux Kernel Parameters (passing board info data):
+*   r3: ptr to board info data
+*   r4: initrd_start or 0 if no initrd
+*   r5: initrd_end - unused if r4 is 0
+*   r6: Start of command line string
+*   r7: End   of command line string
+*   r8: 0
+*   r9: 0
+*/
+   ulong cmd_start = images->cmdline_start;
+   ulong cmd_end = images->cmdline_end;
+   ulong initrd_start = images->initrd_start;
+   ulong initrd_end = images->initrd_end;
+   bd_t *kbd = images->kbd;
+
+   debug ("   Booting using board info...\n");
+   (*kernel) (kbd, initrd_start, initrd_end,
+  cmd_start, cmd_end, 0, 0);
+   /* does not return */
+   }
+   return ;
+}
+
 void arch_lmb_reserve(struct lmb *lmb)
 {
phys_size_t bootm_size;
@@ -99,153 +168,163 @@ void arch_lmb_reserve(struct lmb *lmb)
return ;
 }
 
-__attribute__((noinline))
-int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
+static void boot_prep_linux(void)
 {
-   ulong   initrd_start, initrd_end;
-   ulong   rd_len;
-
-   ulong   cmd_start, cmd_end, bootmap_base;
-   bd_t*kbd;
-   void(*kernel)(bd_t *, ulong r4, ulong r5, ulong r6,
- ulong r7, ulong r8, ulong r9);
-   int ret;
-   ulong   of_size = images->ft_len;
-   struct lmb *lmb = &images->lmb;
-
-#if defined(CONFIG_OF_LIBFDT)
-   char*of_flat_tree = images->ft_addr;
+#if (CONFIG_NUM_CPUS > 1)
+   /* if we are MP make sure to flush the dcache() to any changes are made
+* visibile to all other cores */
+flush_dcache();
 #endif
+   return ;
+}
 
-   if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
-   return 1;
-
-   kernel = (void (*)(bd_t *, ulong, ulong, ulong,
-  ulong, ulong, ulong))images->ep;
+static int boot_cmdline_linux(bootm_headers_t *images)
+{
+   ulong bootmap_base = getenv_bootm_low();
+   ulong of_size = images->ft_len;
+   struct lmb *lmb = &images->lmb;
+   ulong *cmd_start = &images->cmdline_start;
+   ulong *cmd_end = &images->cmdline_end;
 
-   bootmap_base = getenv_bootm_low();
+   int ret = 0;
 
if (!of_size) {
/* allocate space and init command line */
-   ret = boot_get_cmdline (lmb, &cmd_start, &cmd_end, 
bootmap_base);
+   ret = boot_get_cmdline (lmb, cmd_start, cmd_end, bootmap_base);
if (ret) {
puts("ERROR with allocation of cmdline\n");
- 

[U-Boot] [PATCH 2/4] bootm: Add subcommands

[Kumar Gala]

Add the ability to break the steps of the bootm command into several
subcommands: start, loados, ramdisk, fdt, bdt, cmdline, prep, go.

This allows us to do things like manipulate device trees before
they are passed to a booting kernel or setup memory for a secondary
core in multicore situations.

Not all OS types support all subcommands (currently only start, loados,
ramdisk, fdt, and go are supported).

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 common/cmd_bootm.c |  168 +++-
 include/image.h|   20 ++-
 lib_arm/bootm.c|3 +
 lib_avr32/bootm.c  |3 +
 lib_blackfin/bootm.c   |3 +
 lib_i386/bootm.c   |3 +
 lib_m68k/bootm.c   |3 +
 lib_microblaze/bootm.c |3 +
 lib_mips/bootm.c   |3 +
 lib_nios2/bootm.c  |3 +
 lib_ppc/bootm.c|3 +
 lib_sh/bootm.c |3 +
 lib_sparc/bootm.c  |3 +
 13 files changed, 219 insertions(+), 2 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 956e1a0..1b2dfc4 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #if defined(CONFIG_CMD_USB)
@@ -296,7 +297,7 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int 
argc, char *argv[])
}
 
images.os.start = (ulong)os_hdr;
-   images.valid = 1;
+   images.state = BOOTM_STATE_START;
 
return 0;
 }
@@ -399,6 +400,121 @@ static int bootm_load_os(image_info_t os, ulong 
*load_end, int boot_progress)
return 0;
 }
 
+/* we overload the cmd field with our state machine info instead of a
+ * function pointer */
+cmd_tbl_t cmd_bootm_sub[] = {
+   U_BOOT_CMD_MKENT(start, 0, 1, (void *)BOOTM_STATE_START, "", ""),
+   U_BOOT_CMD_MKENT(loados, 0, 1, (void *)BOOTM_STATE_LOADOS, "", ""),
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+   U_BOOT_CMD_MKENT(ramdisk, 0, 1, (void *)BOOTM_STATE_RAMDISK, "", ""),
+#endif
+#ifdef CONFIG_OF_LIBFDT
+   U_BOOT_CMD_MKENT(fdt, 0, 1, (void *)BOOTM_STATE_FDT, "", ""),
+#endif
+   U_BOOT_CMD_MKENT(bdt, 0, 1, (void *)BOOTM_STATE_OS_BD_T, "", ""),
+   U_BOOT_CMD_MKENT(cmdline, 0, 1, (void *)BOOTM_STATE_OS_CMDLINE, "", ""),
+   U_BOOT_CMD_MKENT(prep, 0, 1, (void *)BOOTM_STATE_OS_PREP, "", ""),
+   U_BOOT_CMD_MKENT(go, 0, 1, (void *)BOOTM_STATE_OS_GO, "", ""),
+};
+
+int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+   int ret = 0;
+   int state;
+   cmd_tbl_t *c;
+   boot_os_fn *boot_fn;
+
+   c = find_cmd_tbl(argv[1], &cmd_bootm_sub[0], ARRAY_SIZE(cmd_bootm_sub));
+
+   if (c) {
+   state = (int)c->cmd;
+
+   /* treat start special since it resets the state machine */
+   if (state == BOOTM_STATE_START) {
+   argc--;
+   argv++;
+   return bootm_start(cmdtp, flag, argc, argv);
+   }
+   }
+   /* Unrecognized command */
+   else {
+   printf ("Usage:\n%s\n", cmdtp->usage);
+   return 1;
+   }
+
+   if (images.state >= state) {
+   printf ("Trying to execute a command out of order\n");
+   printf ("Usage:\n%s\n", cmdtp->usage);
+   return 1;
+   }
+
+   images.state |= state;
+   boot_fn = boot_os[images.os.os];
+
+   switch (state) {
+   ulong load_end;
+   case BOOTM_STATE_START:
+   /* should never occur */
+   break;
+   case BOOTM_STATE_LOADOS:
+   ret = bootm_load_os(images.os, &load_end, 0);
+   if (ret)
+   return ret;
+
+   lmb_reserve(&images.lmb, images.os.load,
+   (load_end - images.os.load));
+   break;
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+   case BOOTM_STATE_RAMDISK:
+   {
+   ulong rd_len = images.rd_end - images.rd_start;
+   char str[17];
+
+   ret = boot_ramdisk_high(&images.lmb, images.rd_start,
+   rd_len, &images.initrd_start, 
&images.initrd_end);
+   if (ret)
+   return ret;
+
+   sprintf(str, "%lx", images.initrd_start);
+   setenv("initrd_start", str);
+   sprintf(str, "%lx", images.initrd_end);
+   setenv("initrd_end", str);
+   }
+   break;
+#endif
+#ifdef CONFIG_OF_LIBFDT
+   case BOOTM_STATE_FDT:
+   {
+   ulong bootmap_base = getenv_bootm_low();
+   ret = boot_relocate_fdt(&images.lmb, bootmap_base,
+  

[U-Boot] [PATCH 1/4] bootm: Move to using a function pointer table for the boot os function

[Kumar Gala]

This removes a bit of code and makes it easier for the upcoming sub bootm
command support to call into the proper OS specific handler.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 common/cmd_bootm.c |   68 +++
 1 files changed, 31 insertions(+), 37 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index b02da3e..956e1a0 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -119,6 +119,22 @@ int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[]);
 static boot_os_fn do_bootm_integrity;
 #endif
 
+boot_os_fn * boot_os[] = {
+   [IH_OS_LINUX] = do_bootm_linux,
+   [IH_OS_NETBSD] = do_bootm_netbsd,
+#ifdef CONFIG_LYNXKDI
+   [IH_OS_LYNXOS] = do_bootm_lynxkdi,
+#endif
+   [IH_OS_RTEMS] = do_bootm_rtems,
+#if defined(CONFIG_CMD_ELF)
+   [IH_OS_VXWORKS] = do_bootm_vxworks,
+   [IH_OS_QNX] = do_bootm_qnxelf,
+#endif
+#ifdef CONFIG_INTEGRITY
+   [IH_OS_INTEGRITY] = do_bootm_integrity,
+#endif
+};
+
 ulong load_addr = CONFIG_SYS_LOAD_ADDR;/* Default Load Address */
 static bootm_headers_t images; /* pointers to os/initrd/fdt images */
 
@@ -386,12 +402,22 @@ static int bootm_load_os(image_info_t os, ulong 
*load_end, int boot_progress)
 /***/
 /* bootm - boot application image from image in memory */
 /***/
+static int relocated = 0;
+
 int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
-
ulong   iflag;
ulong   load_end = 0;
int ret;
+   boot_os_fn  *boot_fn;
+
+   /* relocate boot function table */
+   if (0 == relocated) {
+   int i;
+   for (i = 0; i < ARRAY_SIZE(boot_os); i++)
+   boot_os[i] += gd->reloc_off;
+   relocated = 1;
+   }
 
if (bootm_start(cmdtp, flag, argc, argv))
return 1;
@@ -454,45 +480,13 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
 
show_boot_progress (8);
 
-   switch (images.os.os) {
-   default:/* handled by (original) Linux case */
-   case IH_OS_LINUX:
 #ifdef CONFIG_SILENT_CONSOLE
-   fixup_silent_linux();
-#endif
-   do_bootm_linux (0, argc, argv, &images);
-   break;
-
-   case IH_OS_NETBSD:
-   do_bootm_netbsd (0, argc, argv, &images);
-   break;
-
-#ifdef CONFIG_LYNXKDI
-   case IH_OS_LYNXOS:
-   do_bootm_lynxkdi (0, argc, argv, &images);
-   break;
+   if (images.os.os == IH_OS_LINUX)
+   fixup_silent_linux();
 #endif
 
-   case IH_OS_RTEMS:
-   do_bootm_rtems (0, argc, argv, &images);
-   break;
-
-#if defined(CONFIG_CMD_ELF)
-   case IH_OS_VXWORKS:
-   do_bootm_vxworks (0, argc, argv, &images);
-   break;
-
-   case IH_OS_QNX:
-   do_bootm_qnxelf (0, argc, argv, &images);
-   break;
-#endif
-
-#ifdef CONFIG_INTEGRITY
-   case IH_OS_INTEGRITY:
-   do_bootm_integrity (0, argc, argv, &images);
-   break;
-#endif
-   }
+   boot_fn = boot_os[images.os.os];
+   boot_fn(0, argc, argv, &images);
 
show_boot_progress (-9);
 #ifdef DEBUG
-- 
1.5.5.1

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

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Kumar Gala]

On Oct 21, 2008, at 2:30 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED] 
> > you wrote:
>> Add the ability to break the steps of the bootm command into several
>> subcommands: start, loados, ramdisk, fdt, bdt, cmdline, prep, go.
>>
>> This allows us to do things like manipulate device trees before
>> they are passed to a booting kernel or setup memory for a secondary
>> core in multicore situations.
>>
>> Not all OS types support all subcommands (currently only start,  
>> loados,
>> ramdisk, fdt, and go are supported).
>>
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>
> This looks mostly OK to me, but I haven't actually tested any of this
> code yet - can you please comment to what extend you tested it?

I've tested this on FSL 85xx HW.  I'm able to boot using a sequence of  
bootm subcommands + a few other commands as well as plain old bootm.

>> --- a/common/cmd_bootm.c
>> +++ b/common/cmd_bootm.c
> ...
>> @@ -1022,6 +1170,9 @@ static int do_bootm_netbsd (int flag, int  
>> argc, char *argv[],
>>  char *consdev;
>>  char *cmdline;
>>
>> +if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
>> +return 1;
>> +
>
> This is a test that repeats quite often... Maybe e can optimize this
> as
>
>   if ((flag ^ BOOTM_STATE_OS_GO) != 0)
>   return 1;

Hmm, this isn't equivalent:

0 ^ BOOTM_STATE_OS_GO => BOOTM_STATE_OS_GO
BOOTM_STATE_OS_GO != 0
return 1.

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

Re: [U-Boot] Hangs at relocation on 460EX Target

[Ayman M. El-Khashab]

On Tue, Oct 21, 2008 at 09:10:03PM +0200, Wolfgang Denk wrote:

> > 
> > I should have mentioned that we have DEBUG enabled and we've also 
> > run the RAM test that is included in u-boot.  The ram test does pass.
> 
> Please see the FAQ, entry # 1. Passing the RAM test does not mean
> anything when it comes to accessing the RAM in burst mode.

Ok, makes sense I understand that the ram test is not sufficient to fully
exercise the bus. In particular, it appears that it does not have lots of
entropy, so shorted address/data may not be detected and the timing tolerance
is much wider than would be found in normal operating conditions.

> 
> > I am not familiar with those, I thought that once the SDRAM is operating
> > you cannot alter those calibration and timing/delay registers.  Is this 
> > calibration something that is enabled in u-boot or just via the register
> > accesses to the memory controller?
> 
> How about reading the code?

(Looking at canyonlands.h)

Ok, I took a look at this and the autocalibration is not obvious.  It looks
like there is a currently a hardcoded RQDC value of 8038.  If this is 
undefined then the code will go into the autocalibration mode.  So
I've undefined it and sure enough it goes into autocalibration.  The part
that is odd is that the autocal does not work on the Canyonlands board.  If
it is enabled, then the Canyonlands fails in the same way as our hardware. 
I.e. right at the time of relocation, it just hangs.  When set back to the
hardcoded value, the canyonlands works fine.  

Perusing the code, the only sort of exception that I noticed was one for 
the Katmai.  During operation I don't see the code fail to find the window,
so it appears that it finds a suitable value.  When examined with the abatron
it looks like a value is set into the mfio_rqdc register.

So I am somewhat puzzled.  It is not obvious to me why the autocal is failing
to work on the canyonlands.

On another project we found that the window constrained slightly when operating
in burst mode (via DMA) vs regular ram line reads/writes.  I don't know if
that could be the same issue where since the failure is just at the time
the burst mode is enabled.   

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

[U-Boot] [PATCH v2] pci: Allow for PCI addresses to be 64-bit

[Kumar Gala]

PCI bus is inherently 64-bit.  While not all system require access to
the full 64-bit PCI address range some do.  This allows those systems
to enable the full PCI address width via CONFIG_SYS_PCI_64BIT.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---

moved to CONFIG_SYS_PCI_64BIT instead of CONFIG_PCI_64BIT

- k

 drivers/pci/pci.c  |4 ++--
 drivers/pci/pci_auto.c |   22 +++---
 include/pci.h  |   24 
 3 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 41780db..127d50f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -223,7 +223,7 @@ unsigned long pci_hose_phys_to_bus (struct pci_controller 
*hose,
unsigned long flags)
 {
struct pci_region *res;
-   unsigned long bus_addr;
+   pci_addr_t bus_addr;
int i;
 
if (!hose) {
@@ -252,7 +252,7 @@ Done:
 }
 
 phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-unsigned long bus_addr,
+pci_addr_t bus_addr,
 unsigned long flags)
 {
struct pci_region *res;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 3844359..547ce5b 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -52,7 +52,7 @@ void pciauto_region_align(struct pci_region *res, unsigned 
long size)
 
 int pciauto_region_allocate(struct pci_region* res, unsigned int size, 
unsigned int *bar)
 {
-   unsigned long addr;
+   pci_addr_t addr;
 
if (!res) {
DEBUGF("No resource");
@@ -68,7 +68,7 @@ int pciauto_region_allocate(struct pci_region* res, unsigned 
int size, unsigned
 
res->bus_lower = addr + size;
 
-   DEBUGF("address=0x%lx bus_lower=%x", addr, res->bus_lower);
+   DEBUGF("address=0x%llx bus_lower=%llx", (u64)addr, (u64)res->bus_lower);
 
*bar = addr;
return 0;
@@ -289,10 +289,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_mem) {
pciauto_region_init(hose->pci_mem);
 
-   DEBUGF("PCI Autoconfig: Bus Memory region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Memory region: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
-   hose->pci_mem->bus_start,
-   hose->pci_mem->bus_start + hose->pci_mem->size - 1,
+   (u64)hose->pci_mem->bus_start,
+   (u64)(hose->pci_mem->bus_start + hose->pci_mem->size - 1),
hose->pci_mem->phys_start,
hose->pci_mem->phys_start + hose->pci_mem->size - 1);
}
@@ -300,10 +300,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_prefetch) {
pciauto_region_init(hose->pci_prefetch);
 
-   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
-   hose->pci_prefetch->bus_start,
-   hose->pci_prefetch->bus_start + hose->pci_prefetch->size - 
1,
+   (u64)hose->pci_prefetch->bus_start,
+   (u64)(hose->pci_prefetch->bus_start + 
hose->pci_prefetch->size - 1),
hose->pci_prefetch->phys_start,
hose->pci_prefetch->phys_start +
hose->pci_prefetch->size - 1);
@@ -312,10 +312,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_io) {
pciauto_region_init(hose->pci_io);
 
-   DEBUGF("PCI Autoconfig: Bus I/O region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus I/O region: [%llx-%llx],\n"
   "\t\tPhysical Memory: [%x-%x]\n",
-   hose->pci_io->bus_start,
-   hose->pci_io->bus_start + hose->pci_io->size - 1,
+   (u64)hose->pci_io->bus_start,
+   (u64)(hose->pci_io->bus_start + hose->pci_io->size - 1),
hose->pci_io->phys_start,
hose->pci_io->phys_start + hose->pci_io->size - 1);
 
diff --git a/include/pci.h b/include/pci.h
index 1c8e216..d79f26a 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -312,13 +312,21 @@
 
 #include 
 
+#ifdef CONFIG_SYS_PCI_64BIT
+typedef u64 pci_addr_t;
+typedef u64 pci_size_t;
+#else
+typedef u32 pci_addr_t;
+typedef u32 pci_size_t;
+#endif
+
 struct pci_region {
-   unsigned long bus_start;/* Start on the bus */
-   phys_addr_t phys_start; /* Start in physical address 
space */
-   unsigned long size; /* Size */
-   unsigned long flags;/* Resource flags */
+   pci_addr_t bus_start;   /* Start on the bus */
+   phys_addr_t phys_start; /* Start in physical add

[U-Boot] [PATCH v3] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Use the GNU 'date' command to auto-generate a new U-Boot
timestamp on every compile.

Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
---
NOTE: As far as the changes to the Makefile, I wasn't sure
why the NAND_SPL and ONENAND_IPL didn't have the "depend"
dependency and why they needed the $(VERSION_FILE)
dependency.  I added the $(TIMESTAMP) dependency to be
consistent, but if its not correct, let me know.
 
Changes since v1:
* Split up U_BOOT_DATE define (date and time) into
  U_BOOT_DATE (day, month, year) and U_BOOT_TIME (time of day)
  defines
* Updated all architetures/boards

Changes since v2:
* Placed U_BOOT_DATE and U_BOOT_TIME defines in
  timestamp_autogenerated.h.
* Added include/timestamp.h

 Makefile|   19 +--
 board/bmw/bmw.c |4 ++--
 board/eXalion/eXalion.c |3 ++-
 board/mousse/mousse.c   |3 ++-
 board/netstar/eeprom.c  |3 ++-
 board/sandburst/karef/karef.c   |6 --
 board/sandburst/metrobox/metrobox.c |6 --
 board/trab/trab_fkt.c   |3 ++-
 board/voiceblue/eeprom.c|3 ++-
 common/lcd.c|4 +++-
 cpu/74xx_7xx/start.S|3 ++-
 cpu/leon2/start.S   |3 ++-
 cpu/leon3/start.S   |3 ++-
 cpu/mcf5227x/start.S|3 ++-
 cpu/mcf523x/start.S |3 ++-
 cpu/mcf52x2/start.S |3 ++-
 cpu/mcf532x/start.S |3 ++-
 cpu/mcf5445x/start.S|3 ++-
 cpu/mcf547x_8x/start.S  |3 ++-
 cpu/mpc512x/start.S |3 ++-
 cpu/mpc5xx/start.S  |3 ++-
 cpu/mpc5xxx/start.S |3 ++-
 cpu/mpc8220/start.S |3 ++-
 cpu/mpc824x/start.S |3 ++-
 cpu/mpc8260/start.S |3 ++-
 cpu/mpc83xx/start.S |3 ++-
 cpu/mpc85xx/start.S |3 ++-
 cpu/mpc86xx/start.S |3 ++-
 cpu/mpc8xx/start.S  |3 ++-
 cpu/mpc8xx/video.c  |4 +++-
 cpu/nios/start.S|3 ++-
 cpu/nios2/start.S   |3 ++-
 cpu/ppc4xx/start.S  |3 ++-
 include/.gitignore  |1 +
 include/configs/NETPHONE.h  |2 +-
 include/configs/NETTA.h |2 +-
 include/configs/NETTA2.h|2 +-
 include/timestamp.h |   30 ++
 lib_arm/board.c |3 ++-
 lib_avr32/board.c   |3 ++-
 lib_blackfin/board.c|3 ++-
 lib_i386/board.c|3 ++-
 lib_microblaze/board.c  |3 ++-
 lib_mips/board.c|3 ++-
 lib_sh/board.c  |3 ++-
 net/net.c   |3 +++
 46 files changed, 134 insertions(+), 51 deletions(-)
 create mode 100644 include/timestamp.h

diff --git a/Makefile b/Makefile
index 9a132f7..f680479 100644
--- a/Makefile
+++ b/Makefile
@@ -30,6 +30,7 @@ U_BOOT_VERSION = 
$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 else
 U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL)$(EXTRAVERSION)
 endif
+TIMESTAMP_FILE = $(obj)include/timestamp_autogenerated.h
 VERSION_FILE = $(obj)include/version_autogenerated.h
 
 HOSTARCH := $(shell uname -m | \
@@ -259,7 +260,7 @@ LIBS += api/libapi.a
 LIBS += post/libpost.a
 
 LIBS := $(addprefix $(obj),$(LIBS))
-.PHONY : $(LIBS) $(VERSION_FILE)
+.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE) 
 
 LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
@@ -351,13 +352,13 @@ $(SUBDIRS):   depend $(obj)include/autoconf.mk
 $(LDSCRIPT):   depend $(obj)include/autoconf.mk
$(MAKE) -C $(dir $@) $(notdir $@)
 
-$(NAND_SPL):   $(VERSION_FILE) $(obj)include/autoconf.mk
+$(NAND_SPL):   $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
 
 $(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin $(obj)include/autoconf.mk
cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > 
$(obj)u-boot-nand.bin
 
-$(ONENAND_IPL):$(VERSION_FILE) $(obj)include/autoconf.mk
+$(ONENAND_IPL):$(TIMESTAMP_FILE) $(VERSION_FILE) 
$(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
 
 $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin 
$(obj)include/autoconf.mk
@@ -370,6 +371,12 @@ $(VERSION_FILE):
 ) > [EMAIL PROTECTED]
@cmp -s $@ [EMAIL PROTECTED] && rm -f [EMAIL PROTECTED] || mv 
-f [EMAIL PROTECTED] $@
 
+$(TIMESTAMP_FILE):
+   @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d 
%C%y")' \
+) > $@
+   @( printf '#define U_BOOT_TIME "%s"\n' '$(shell date +"%T")' \
+) >

Re: [U-Boot] [PATCH] AT91: Enable PLLB for USB

[Stelian Pop]

Le mardi 21 octobre 2008 à 19:54 +0200, Remy Bohmer a écrit :
> Hello Stelian,

Hi Remy,

> Are all your USB stick problems solved by now? Including that stick
> that did not work?

Nope. I still have one (kinda old) stick which does not work, on any
AT91 board. But I suspect the issues are no longer in the board/cpu
code, but in the core USB layer.

> I will try your patches tomorrow, but I have one question:
> > #define AT91_MAIN_CLOCK18432000/* 18.432 MHz 
> > crystal */
> >  #define AT91_MASTER_CLOCK  1   /* peripheral */
> >  #define AT91_CPU_CLOCK 2   /* cpu */
> 
> Are such nice rounded values possible with that unrounded crystal?
> 
> Looking at sam9261 I see:
> #define AT91_MAIN_CLOCK 198656000   /* from 18.432 MHz crystal */

This one is clearly wrong. 18.432 MHz is 18432000 Hz.

> #define AT91_MASTER_CLOCK   99328000/* peripheral = main / 2

And the master clock is not main / 2, but PLLA / 2, where PLLA is
initialized by the bootstrap to (main * 0x60) / 9.

This gives:
PLLA = 18432000 * 0x60 / 9 = 196608000 Hz
MASTER = 196608000 / 2 = 98304000 Hz.

The defines in the header files contain rounded values, I don't think
it's too important to be precise here.

Stelian.
-- 
Stelian Pop <[EMAIL PROTECTED]>

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

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:42 Tue 21 Oct , Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <[EMAIL PROTECTED]> you wrote:
> > 
> > >> +#define CONFIG_BOOTM_LINUX 1
> > >> +#define CONFIG_BOOTM_NETBSD 1
> > >> +#define CONFIG_BOOTM_RTEMS 1
> > >
> > > The only somewhat reasonable thing I can come up with  is  to  add  a
> > > "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
> > > support Linux by default, and leave it up to the board maintainers to
> > > add additioonal OS support if needed.
> > >
> > > Comment?
> > 
> > Hmm, can we hold off on this until we have Kconfig than?  It would be  
> > much easier at that point rather me having to touch ~450 config.h's.
> 
> OK from my POV. Should we check in your patch as is, then?

Maybe simple add the CONFIG_BOOTM to include/config_cmd_default.h and 
include/config_cmd_all.h until we have Kconfig? So if a board do not need
an OS support it will just add an #undef to its config.

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

Re: [U-Boot] [PATCH] lcd: print custom strings after the logo

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:40 Tue 21 Oct , Wolfgang Denk wrote:
> Dear Stelian Pop,
> 
> In message <[EMAIL PROTECTED]> you wrote:
> > > +#ifndef CONFIG_LCD_LOGO_TEXT1
> > > +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> > > +#endif
> > 
> > Wouldn't it be better if we move this text into
> > include/configs/at91xxx.h for all the boards ?
> 
> Yes, please.
> 
> 
> Anatolij, Jean-Christophe - who of you will be taking care of this?
I'm reveiwing at91 now so if Anatolij see no problem I'll take care of this

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

Re: [U-Boot] [PATCH v2] Update U-Boot's build timestamp on every compile

[Wolfgang Denk]

Dear Peter Tyser,

In message <[EMAIL PROTECTED]> you wrote:
>
> How does a $(TIMESTAMP_FILE) target of
> $(obj)include/timestamp_autogenerated.h sound?  An include/timestamp.h
> file would also be added which includes
> included/timestamp_autogenerated.h.

That's OK with me. Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Where would we be without rhetorical questions?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Hi Wolfgang,

> > --- a/Makefile
> > +++ b/Makefile
> > @@ -368,6 +368,10 @@ $(VERSION_FILE):
> > @( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' 
> > "$(U_BOOT_VERSION)" \
> >  '$(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion 
> > $(TOPDIR))' \
> >  ) > [EMAIL PROTECTED]
> > +   @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d 
> > %C%y")' \
> > +) >> [EMAIL PROTECTED]
> > +   @( printf '#define U_BOOT_TIME "%s"\n' '$(shell date +"%T")' \
> > +) >> [EMAIL PROTECTED]
> > @cmp -s $@ [EMAIL PROTECTED] && rm -f [EMAIL PROTECTED] || mv 
> > -f [EMAIL PROTECTED] $@
> 
> Please do not do this here. Use a separate target instead.
> 
> As you can see, we take care NOT to create  a  new  VERSION_FILE  for
> each  build, but only when it eally changed. Your change forces it to
> change with each build, which we tried to avoid.

How does a $(TIMESTAMP_FILE) target of
$(obj)include/timestamp_autogenerated.h sound?  An include/timestamp.h
file would also be added which includes
included/timestamp_autogenerated.h.

Best,
Peter

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

Re: [U-Boot] [PATCH v2] Update U-Boot's build timestamp on every compile

[Wolfgang Denk]

Dear Peter Tyser,

In message <[EMAIL PROTECTED]> you wrote:
> Use the GNU 'date' command to auto-generate a new U-Boot
> timestamp on every compile.
...
> --- a/Makefile
> +++ b/Makefile
> @@ -368,6 +368,10 @@ $(VERSION_FILE):
>   @( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' 
> "$(U_BOOT_VERSION)" \
>'$(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion 
> $(TOPDIR))' \
>) > [EMAIL PROTECTED]
> + @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d 
> %C%y")' \
> +  ) >> [EMAIL PROTECTED]
> + @( printf '#define U_BOOT_TIME "%s"\n' '$(shell date +"%T")' \
> +  ) >> [EMAIL PROTECTED]
>   @cmp -s $@ [EMAIL PROTECTED] && rm -f [EMAIL PROTECTED] || mv 
> -f [EMAIL PROTECTED] $@

Please do not do this here. Use a separate target instead.

As you can see, we take care NOT to create  a  new  VERSION_FILE  for
each  build, but only when it eally changed. Your change forces it to
change with each build, which we tried to avoid.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
  - Doug Gwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jerry Van Baren,
> 
> In message <[EMAIL PROTECTED]> you wrote:
>>> If it helps, we can use a branch in u-boot-testing for this.
> ...
>> Sounds good to me.
> 
> Please just drop me a note which patches (in which versions) should go
> in. I kind of lost track...
> 
> Best regards,
> 
> Wolfgang Denk

Dear Kumar Gala,

I kind of lost track too.  :-/

gvb

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

[U-Boot] [PATCH v2] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Use the GNU 'date' command to auto-generate a new U-Boot
timestamp on every compile.

Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
---
Changes since inital PATCH/RFC:
* Split up U_BOOT_DATE define (date and time) into
  U_BOOT_DATE (day, month, year) and U_BOOT_TIME (time of day)
  defines
* Updated all architetures/boards

 Makefile|4 
 board/bmw/bmw.c |2 +-
 board/eXalion/eXalion.c |3 ++-
 board/mousse/mousse.c   |3 ++-
 board/netstar/eeprom.c  |3 ++-
 board/sandburst/karef/karef.c   |6 --
 board/sandburst/metrobox/metrobox.c |6 --
 board/trab/trab_fkt.c   |3 ++-
 board/voiceblue/eeprom.c|3 ++-
 common/lcd.c|3 ++-
 cpu/74xx_7xx/start.S|2 +-
 cpu/leon2/start.S   |2 +-
 cpu/leon3/start.S   |2 +-
 cpu/mcf5227x/start.S|2 +-
 cpu/mcf523x/start.S |2 +-
 cpu/mcf52x2/start.S |2 +-
 cpu/mcf532x/start.S |2 +-
 cpu/mcf5445x/start.S|2 +-
 cpu/mcf547x_8x/start.S  |2 +-
 cpu/mpc512x/start.S |2 +-
 cpu/mpc5xx/start.S  |2 +-
 cpu/mpc5xxx/start.S |2 +-
 cpu/mpc8220/start.S |2 +-
 cpu/mpc824x/start.S |2 +-
 cpu/mpc8260/start.S |2 +-
 cpu/mpc83xx/start.S |2 +-
 cpu/mpc85xx/start.S |2 +-
 cpu/mpc86xx/start.S |2 +-
 cpu/mpc8xx/start.S  |2 +-
 cpu/mpc8xx/video.c  |3 ++-
 cpu/nios/start.S|2 +-
 cpu/nios2/start.S   |2 +-
 cpu/ppc4xx/start.S  |2 +-
 include/configs/NETPHONE.h  |2 +-
 include/configs/NETTA.h |2 +-
 include/configs/NETTA2.h|2 +-
 lib_arm/board.c |2 +-
 lib_avr32/board.c   |2 +-
 lib_blackfin/board.c|2 +-
 lib_i386/board.c|2 +-
 lib_microblaze/board.c  |2 +-
 lib_mips/board.c|2 +-
 lib_sh/board.c  |2 +-
 net/net.c   |3 +++
 44 files changed, 62 insertions(+), 44 deletions(-)

diff --git a/Makefile b/Makefile
index 9a132f7..fedb9d0 100644
--- a/Makefile
+++ b/Makefile
@@ -368,6 +368,10 @@ $(VERSION_FILE):
@( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' 
"$(U_BOOT_VERSION)" \
 '$(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion 
$(TOPDIR))' \
 ) > [EMAIL PROTECTED]
+   @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d 
%C%y")' \
+) >> [EMAIL PROTECTED]
+   @( printf '#define U_BOOT_TIME "%s"\n' '$(shell date +"%T")' \
+) >> [EMAIL PROTECTED]
@cmp -s $@ [EMAIL PROTECTED] && rm -f [EMAIL PROTECTED] || mv 
-f [EMAIL PROTECTED] $@
 
 gdbtools:
diff --git a/board/bmw/bmw.c b/board/bmw/bmw.c
index b629c38..1c72993 100644
--- a/board/bmw/bmw.c
+++ b/board/bmw/bmw.c
@@ -45,7 +45,7 @@ int checkboard(void)
 char  buf[32];
 
 puts ("Board: BMW MPC8245/KAHLUA2 - CHRP (MAP B)\n");
-printf("Built: %s at %s\n", __DATE__ , __TIME__ );
+printf("Built: %s at %s\n", U_BOOT_DATE, U_BOOT_TIME);
 /* printf("MPLD:  Revision %d\n", SYS_REVID_GET()); */
 printf("Local Bus at %s MHz\n", strmhz(buf, busfreq));
 return 0;
diff --git a/board/eXalion/eXalion.c b/board/eXalion/eXalion.c
index 34538c4..26d2e85 100644
--- a/board/eXalion/eXalion.c
+++ b/board/eXalion/eXalion.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "piix_pci.h"
 #include "eXalion.h"
 
@@ -40,7 +41,7 @@ int checkboard (void)
char buf[32];
 
printf ("Board: eXalion MPC824x - CHRP (MAP B)\n");
-   printf ("Built: %s at %s\n", __DATE__, __TIME__);
+   printf ("Built: %s at %s\n", U_BOOT_DATE, U_BOOT_TIME);
printf ("Local Bus:  %s MHz\n", strmhz (buf, busfreq));
 
return 0;
diff --git a/board/mousse/mousse.c b/board/mousse/mousse.c
index 6a12b57..0625767 100644
--- a/board/mousse/mousse.c
+++ b/board/mousse/mousse.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mousse.h"
 #include "m48t59y.h"
@@ -42,7 +43,7 @@ int checkboard (void)
char buf[32];
 
puts ("Board: MOUSSE MPC8240/KAHLUA - CHRP (MAP B)\n");
-   printf ("Built: %s at %s\n", __DATE__, __TIME__);
+   printf ("Built: %s at %s\n", U_BOOT_DATE, U_BOOT_TIME);
printf ("MPLD:  Revision %d\n", SYS_REVID_GET ());
printf ("Local Bus:  %s MHz\n", strmhz (buf, busfreq));
 
diff --git a/board/netstar/eeprom.c b/board/netstar/eeprom.c
index 0de594b..7817da8 100644
--- a/board/netst

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <[EMAIL PROTECTED]> you wrote:
>
> > If it helps, we can use a branch in u-boot-testing for this.
...
> Sounds good to me.

Please just drop me a note which patches (in which versions) should go
in. I kind of lost track...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
"That unit is a woman."
"A mass of conflicting impulses."
-- Spock and Nomad, "The Changeling", stardate 3541.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jerry Van Baren,
> 
> In message <[EMAIL PROTECTED]> you wrote:
>> Do you have a git repo I can clone rather than trying to keep up with 
>> the master repo + your patches?  My tracking of your work is falling 
>> apart.  I see you have an out-of-date repo on git.kernel.org, can you 
>> update that perhaps?
> 
> If it helps, we can use a branch in u-boot-testing for this.
> 
> Best regards,
> 
> Wolfgang Denk

Sounds good to me.

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

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <[EMAIL PROTECTED]> you wrote:
>
> Do you have a git repo I can clone rather than trying to keep up with 
> the master repo + your patches?  My tracking of your work is falling 
> apart.  I see you have an out-of-date repo on git.kernel.org, can you 
> update that perhaps?

If it helps, we can use a branch in u-boot-testing for this.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Objects in mirror are closer than they appear.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Jerry Van Baren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> Dear Kumar Gala,
>>
>> In message <[EMAIL PROTECTED]> you wrote:
> +#define CONFIG_BOOTM_LINUX 1
> +#define CONFIG_BOOTM_NETBSD 1
> +#define CONFIG_BOOTM_RTEMS 1
 The only somewhat reasonable thing I can come up with  is  to  add  a
 "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
 support Linux by default, and leave it up to the board maintainers to
 add additioonal OS support if needed.

 Comment?
>>> Hmm, can we hold off on this until we have Kconfig than?  It would be  
>>> much easier at that point rather me having to touch ~450 config.h's.
>> OK from my POV. Should we check in your patch as is, then?
>>
>> Best regards,
>>
>> Wolfgang Denk
> 
> Ugly but effective work-around would be to put in an appropriate location:
> /*
>   * Todo: REMOVE when Kconfig becomes real!
>   */
> #ifndef CONFIG_BOOTM_LINUX
> #define CONFIG_BOOTM_LINUX 1
> #endif

...or not.  I'm OK with it as is.  My #define hack is mostly useless.

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

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Mike Frysinger]

On Tuesday 21 October 2008, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED]> you 
wrote:
> > Added the ability to config out bootm support for Linux, NetBSD, RTEMS
> >
> > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> > ---
> >
> > Looking for suggestions on how to deal with enabling LINUX, NETBSD, and
> > RTEMS.
>
> ...
>
> > --- a/common/cmd_bootm.c
> > +++ b/common/cmd_bootm.c
> > @@ -103,13 +103,23 @@ extern int do_reset (cmd_tbl_t *cmdtp, int flag,
> > int argc, char *argv[]); typedef int boot_os_fn (int flag, int argc, char
> > *argv[],
> > bootm_headers_t *images); /* pointers to os/initrd/fdt 
> > */
> >
> > +#define CONFIG_BOOTM_LINUX 1
> > +#define CONFIG_BOOTM_NETBSD 1
> > +#define CONFIG_BOOTM_RTEMS 1
>
> The only somewhat reasonable thing I can come up with  is  to  add  a
> "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
> support Linux by default, and leave it up to the board maintainers to
> add additioonal OS support if needed.

sounds great to me
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Kumar Gala]

On Oct 21, 2008, at 2:42 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <4DE53147-6FF6-4145- 
> [EMAIL PROTECTED]> you wrote:
>>
 +#define CONFIG_BOOTM_LINUX 1
 +#define CONFIG_BOOTM_NETBSD 1
 +#define CONFIG_BOOTM_RTEMS 1
>>>
>>> The only somewhat reasonable thing I can come up with  is  to   
>>> add  a
>>> "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so  
>>> all
>>> support Linux by default, and leave it up to the board maintainers  
>>> to
>>> add additioonal OS support if needed.
>>>
>>> Comment?
>>
>> Hmm, can we hold off on this until we have Kconfig than?  It would be
>> much easier at that point rather me having to touch ~450 config.h's.
>
> OK from my POV. Should we check in your patch as is, then?

I say commit as is than.

- k

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

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <[EMAIL PROTECTED]> you wrote:
 +#define CONFIG_BOOTM_LINUX 1
 +#define CONFIG_BOOTM_NETBSD 1
 +#define CONFIG_BOOTM_RTEMS 1
>>> The only somewhat reasonable thing I can come up with  is  to  add  a
>>> "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
>>> support Linux by default, and leave it up to the board maintainers to
>>> add additioonal OS support if needed.
>>>
>>> Comment?
>> Hmm, can we hold off on this until we have Kconfig than?  It would be  
>> much easier at that point rather me having to touch ~450 config.h's.
> 
> OK from my POV. Should we check in your patch as is, then?
> 
> Best regards,
> 
> Wolfgang Denk

Ugly but effective work-around would be to put in an appropriate location:
/*
  * Todo: REMOVE when Kconfig becomes real!
  */
#ifndef CONFIG_BOOTM_LINUX
#define CONFIG_BOOTM_LINUX 1
#endif

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

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Jerry Van Baren]

Kumar Gala wrote:
> Add the ability to break the steps of the bootm command into several
> subcommands: start, loados, ramdisk, fdt, bdt, cmdline, prep, go.
> 
> This allows us to do things like manipulate device trees before
> they are passed to a booting kernel or setup memory for a secondary
> core in multicore situations.
> 
> Not all OS types support all subcommands (currently only start, loados,
> ramdisk, fdt, and go are supported).
> 
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

Hi Kumar,

I've been hacking at cmd_bootm.c and image.c.  The direction I'm hacking 
in is:
* Move boot_* stuff from image.c into cmd_bootm.c
   - Calling out to another file to a function unused in that file? Ugly.
* Move the FIT stuff out of image.c into a new file fit_image.c
   - The resulting files are more cohesive and less BIG.
* Move the im* commands out of cmd_bootm.c into a new file cmd_image.c
   - At one time, I was of the opinion that "bootm (loados|ramdisk|fdt)"
   should be "ldimage (os|ramdisk|fdt)".  I'm less sure of myself,
   but have not totally discarded the opinion.
   - Looking in cmd_bootm.c for im* commands is rather unintuitive.

My intent is to do this hacking based on your bootm subcommand changes, 
so we can do a two-step cleanup.

Do you have a git repo I can clone rather than trying to keep up with 
the master repo + your patches?  My tracking of your work is falling 
apart.  I see you have an out-of-date repo on git.kernel.org, can you 
update that perhaps?

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

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> 
> >> +#define CONFIG_BOOTM_LINUX 1
> >> +#define CONFIG_BOOTM_NETBSD 1
> >> +#define CONFIG_BOOTM_RTEMS 1
> >
> > The only somewhat reasonable thing I can come up with  is  to  add  a
> > "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
> > support Linux by default, and leave it up to the board maintainers to
> > add additioonal OS support if needed.
> >
> > Comment?
> 
> Hmm, can we hold off on this until we have Kconfig than?  It would be  
> much easier at that point rather me having to touch ~450 config.h's.

OK from my POV. Should we check in your patch as is, then?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] lcd: print custom strings after the logo

[Wolfgang Denk]

Dear Stelian Pop,

In message <[EMAIL PROTECTED]> you wrote:
> > +#ifndef CONFIG_LCD_LOGO_TEXT1
> > +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> > +#endif
> 
> Wouldn't it be better if we move this text into
> include/configs/at91xxx.h for all the boards ?

Yes, please.


Anatolij, Jean-Christophe - who of you will be taking care of this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Der Horizont vieler Menschen ist ein Kreis mit Radius Null --
und das nennen sie ihren Standpunkt.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Kumar Gala]

On Oct 21, 2008, at 2:35 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED] 
> > you wrote:
>> Added the ability to config out bootm support for Linux, NetBSD,  
>> RTEMS
>>
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>> ---
>>
>> Looking for suggestions on how to deal with enabling LINUX, NETBSD,  
>> and RTEMS.
> ...
>> --- a/common/cmd_bootm.c
>> +++ b/common/cmd_bootm.c
>> @@ -103,13 +103,23 @@ extern int do_reset (cmd_tbl_t *cmdtp, int  
>> flag, int argc, char *argv[]);
>> typedef int boot_os_fn (int flag, int argc, char *argv[],
>>  bootm_headers_t *images); /* pointers to os/initrd/fdt 
>> */
>>
>> +#define CONFIG_BOOTM_LINUX 1
>> +#define CONFIG_BOOTM_NETBSD 1
>> +#define CONFIG_BOOTM_RTEMS 1
>
> The only somewhat reasonable thing I can come up with  is  to  add  a
> "#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
> support Linux by default, and leave it up to the board maintainers to
> add additioonal OS support if needed.
>
> Comment?

Hmm, can we hold off on this until we have Kconfig than?  It would be  
much easier at that point rather me having to touch ~450 config.h's.

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

Re: [U-Boot] [PATCH] FDT: don't use private kernel header files

[Wolfgang Denk]

Dear Wolfgang Denk,

In message <[EMAIL PROTECTED]> you wrote:
> From: Wolfgang Denk <[EMAIL PROTECTED]>
> 
> On some systems (for example Fedora Core 4) U-Boot builds with the
> following wanrings only:
> 
> ...
> In file included from /home/wd/git/u-boot/include/libfdt_env.h:33,
>  from fdt.c:51:
>/usr/include/asm/byteorder.h:6:2: warning: #warning using 
> private kernel header; include  instead!
> 
> This patch fixes this problem.
> 
> Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
> ---
>  include/image.h  |   20 +++-
>  include/libfdt_env.h |   19 ++-
>  2 files changed, 25 insertions(+), 14 deletions(-)

Applied.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
All repairs tend to destroy the structure, to  increase  the  entropy
and  disorder  of the system. Less and less effort is spent on fixing
original design flaws; more and more is spent on fixing flaws  intro-
duced by earlier fixes.   - Fred Brooks, "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> Added the ability to config out bootm support for Linux, NetBSD, RTEMS
> 
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> 
> Looking for suggestions on how to deal with enabling LINUX, NETBSD, and RTEMS.
...
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -103,13 +103,23 @@ extern int do_reset (cmd_tbl_t *cmdtp, int flag, int 
> argc, char *argv[]);
>  typedef int boot_os_fn (int flag, int argc, char *argv[],
>   bootm_headers_t *images); /* pointers to os/initrd/fdt 
> */
>  
> +#define CONFIG_BOOTM_LINUX 1
> +#define CONFIG_BOOTM_NETBSD 1
> +#define CONFIG_BOOTM_RTEMS 1

The only somewhat reasonable thing I can come up with  is  to  add  a
"#define  CONFIG_BOOTM_LINUX"  to  all  board  config  files,  so all
support Linux by default, and leave it up to the board maintainers to
add additioonal OS support if needed.

Comment?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
"It was the Law of the Sea, they said. Civilization ends at  the  wa-
terline.  Beyond  that,  we  all enter the food chain, and not always
right at the top."   - Hunter S. Thompson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Allow for PCI addresses to be 64-bit

[Kumar Gala]

On Oct 21, 2008, at 2:12 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED] 
> > you wrote:
>> PCI bus is inherently 64-bit.  While not all system require access to
>> the full 64-bit PCI address range some do.  This allows those systems
>> to enable the full PCI address width via CONFIG_PCI_64BIT.
>>
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>
> Mostly an ACK, except one tiny detail...
>
>> --- a/include/pci.h
>> +++ b/include/pci.h
>> @@ -312,13 +312,21 @@
>>
>> #include 
>>
>> +#ifdef CONFIG_PCI_64BIT
>
> I think we should make this "CONFIG_SYS_PCI_64BIT" instead.
>
> This is really a low-level config option where the end user is not
> supposed to mess with.

ok.  will make the change and repost.

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

Re: [U-Boot] [PATCH 1/2] bootm: Add subcommands

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> Add the ability to break the steps of the bootm command into several
> subcommands: start, loados, ramdisk, fdt, bdt, cmdline, prep, go.
> 
> This allows us to do things like manipulate device trees before
> they are passed to a booting kernel or setup memory for a secondary
> core in multicore situations.
> 
> Not all OS types support all subcommands (currently only start, loados,
> ramdisk, fdt, and go are supported).
> 
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

This looks mostly OK to me, but I haven't actually tested any of this
code yet - can you please comment to what extend you tested it?

> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
...
> @@ -1022,6 +1170,9 @@ static int do_bootm_netbsd (int flag, int argc, char 
> *argv[],
>   char *consdev;
>   char *cmdline;
>  
> + if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
> + return 1;
> +

This is a test that repeats quite often... Maybe e can optimize this
as

if ((flag ^ BOOTM_STATE_OS_GO) != 0)
return 1;

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
 - Fred Brooks, Jr., _The Mythical Man Month_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] bootm: Move to using a function pointer table for the boot os function

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> 
> > One that we should implement, I think.
> 
> So this means introducing CONFIG_BOOT_RTEMS, CONFIG_BOOT_NETBSD, and  
> CONFIG_BOOT_LINUX.

ACK.

> Should these be enabled in all board configs by default?

I recommend to enable only CONFIG_BOOT_LINUX by default.


Board maintainers, please register now if you have different needs :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
If a man had a child who'd gone  anti-social,  killed  perhaps,  he'd
still tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git

[Wolfgang Denk]

Dear Stefan Roese,

In message <[EMAIL PROTECTED]> you wrote:
> The following changes since commit f61f1e150c84f5b9347fca79a4bc5f2286c545d2:
>   Stefan Roese (1):
> Merge branch 'master' of /home/stefan/git/u-boot/u-boot
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Adam Graham (3):
>   ppc4xx: Add AMCC Arches board support (dual 460GT)
>   ppc4xx: Add static support for 44x IBM SDRAM Controller
>   ppc4xx: Add routine to retrieve CPU number
> 
> Dirk Eibach (1):
>   ppc4xx: Add GDSys neo 405EP board support
> 
> Niklaus Giger (1):
>   ppc4xx: Update configs for Netstal boards
> 
> Stefan Roese (2):
>   ppc4xx: Correctly setup ranges property in ebc node
>   ppc4xx: Add 1.0 & 1.066 GHz to canyonlands bootstrap command for PLL 
> setup
> 
>  MAINTAINERS  |4 +
>  MAKEALL  |2 +
>  Makefile |6 +-
>  board/amcc/canyonlands/bootstrap.c   |   12 ++
>  board/amcc/canyonlands/canyonlands.c |  140 +++
>  board/amcc/canyonlands/init.S|   17 +++
>  board/gdsys/neo/Makefile |   51 +++
>  board/gdsys/neo/config.mk|   24 +++
>  board/gdsys/neo/neo.c|  101 +
>  board/gdsys/neo/u-boot.lds   |  132 ++
>  cpu/ppc4xx/44x_spd_ddr2.c|   71 +++---
>  cpu/ppc4xx/cpu.c |   19 +++-
>  cpu/ppc4xx/fdt.c |   45 ---
>  include/asm-ppc/ppc4xx-ebc.h |   31 
>  include/configs/amcc-common.h|   17 ++-
>  include/configs/canyonlands.h|  222 +++---
>  include/configs/hcu4.h   |  100 ++
>  include/configs/hcu5.h   |  118 ++--
>  include/configs/mcu25.h  |   94 ++---
>  include/configs/neo.h|  231 ++
>  include/configs/netstal-common.h |  255 
> ++
>  include/ppc440.h |3 +
>  include/ppc4xx.h |3 +
>  23 files changed, 1368 insertions(+), 330 deletions(-)
>  create mode 100644 board/gdsys/neo/Makefile
>  create mode 100644 board/gdsys/neo/config.mk
>  create mode 100644 board/gdsys/neo/neo.c
>  create mode 100644 board/gdsys/neo/u-boot.lds
>  create mode 100644 include/configs/neo.h
>  create mode 100644 include/configs/netstal-common.h

Done, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
This is now.  Later is later.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] improved strmhz()

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
>
> > --- a/lib_generic/strmhz.c
> > +++ b/lib_generic/strmhz.c
> > @@ -27,7 +27,7 @@ char *strmhz (char *buf, long hz)
> > long l, n;
> > long m;
> >
> > -   n = DIV_ROUND(hz, 100L);
> > +   n = DIV_ROUND(hz, 1000) / 1000L;
> > l = sprintf (buf, "%ld", n);
> >
> > hz -= n * 100L;
> > -- 
> > 1.5.5.1
> 
> I haven't been following this thread, but can we control the number of  
> significant digits.  I'm starting to see output like:
> 
> Clock Configuration:
> CPU:1500.4294967282 MHz, CCB:600.4294967291 MHz,
> DDR:400.4294967293 MHz (800.4294967289 MT/s data rate)  
> (Asynchronous), LBC:37.500 MHz
> 
> (it use to look like)
> 
> Clock Configuration:
> CPU:1500 MHz, CCB: 600 MHz,
> DDR: 401 MHz (801 MT/s data rate) (Asynchronous), LBC:  37 MHz

Can you please provide the input to the strmhz() function  (the  "hz"
parameter) that is causing such output?

I am aware that we will have a problem when "hz" exceeds the 2.147 GHz
limit (as that's the limit for a "long" data type), but that's another
problem, and requires many changes.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
We are all agreed that your  theory  is  crazy.  The  question  which
divides  us  is  whether it is crazy enough to have a chance of being
correct. My own feeling is that it is not crazy enough.  - Niels Bohr
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Allow for PCI addresses to be 64-bit

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> PCI bus is inherently 64-bit.  While not all system require access to
> the full 64-bit PCI address range some do.  This allows those systems
> to enable the full PCI address width via CONFIG_PCI_64BIT.
> 
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

Mostly an ACK, except one tiny detail...

> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -312,13 +312,21 @@
>  
>  #include 
>  
> +#ifdef CONFIG_PCI_64BIT

I think we should make this "CONFIG_SYS_PCI_64BIT" instead.

This is really a low-level config option where the end user is not
supposed to mess with.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Hangs at relocation on 460EX Target

[Wolfgang Denk]

Dear "Ayman M. El-Khashab",

In message <[EMAIL PROTECTED]> you wrote:
> 
> I should have mentioned that we have DEBUG enabled and we've also 
> run the RAM test that is included in u-boot.  The ram test does pass.

Please see the FAQ, entry # 1. Passing the RAM test does not mean
anything when it comes to accessing the RAM in burst mode.

> I am not familiar with those, I thought that once the SDRAM is operating
> you cannot alter those calibration and timing/delay registers.  Is this 
> calibration something that is enabled in u-boot or just via the register
> accesses to the memory controller?

How about reading the code?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Contrary to popular belief, thinking does not cause brain damage.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

[Wolfgang Denk]

Dear Ilko Iliev,

In message <[EMAIL PROTECTED]> you wrote:
>
> > Maybe instead of adding mor #ifdef'ery here, we can turn
> > lowlevel_init() into a "weak" function that can be redefined by board
> > specific code?
> The lowlevel_init() is an assembler function called from another 
> assembler function and the attribute .weak doesn't work.

What do you mean by "attribute .weak doesn't work" ?

> There are no assembler file in the U-BOOT tree which use weak functions.
> Do you know how can I make an assembler function weak?

Well, if you don't know, then don't ask me, ask your compiler - he
knows how to do this.

For example, common/cmd_boot.c has this code snippet right at the
beginning:

 30
 31 /* Allow ports to override the default behavior */
 32 __attribute__((weak))
 33 unsigned long do_go_exec (ulong (*entry)(int, char *[]), int argc, char 
*argv[])
 34 {
 35 return entry (argc, argv);
 36 }

Compile this with -S option, and you get this:

 12 .Ltext0:
 13 .align 2
 14 .weak   do_go_exec
 15 .type   do_go_exec, @function
 16 do_go_exec:
 17 .LFB87:
 18 .file 1 "cmd_boot.c"
 19 .loc 1 34 0
 20 .LVL0:
 21 mflr 0
 22 .LCFI0:
 23 stwu 1,-16(1)
...


So to me it seems as if the attribute .weak is supposed to work just fine.

What exactly is not working for you?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
"You shouldn't make my toaster angry." - Household security explained
in "Johnny Quest"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Hi Andy,

> I don't think he's wanting this as much for releases (which would be
> fine with the git id as you mentioned), but during the development
> process.  It is very useful during development to have a timestamp
> which confirms that what you are running now is what you expect.
> There are various ways I have used this:
> 
> * Catch that I failed to copy the new image to my tftp directory
> * Confirm that I'm booting from the flash bank I just programmed
> * Helpful for figuring out which of the files in my tftp directory
> corresponds to what's running

100% agree - all our releases are generated from fully-committed git
trees with tags.  This patch only intends to improve development.

> Also, while I can see good arguments for not having a time stamp,
> having one that is not up-to-date seems totally useless.  The stamp
> might not be updated for months, and thus provides only an indicator
> as to when the date was last updated.
> 
> Upshot: I endorse this patch's concept, and urge Peter to put in his
> (apparently underpaid) time to complete it.  :)

I'll submit a patch shortly.  I'll also mention the underpaid comment to
management and see what comes of that;)

Peter

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

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Andy Fleming]

On Tue, Oct 21, 2008 at 9:59 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Peter Tyser,
>

>> > Timestamps are not suitable to provide this type of  information.  If
>> > you care about which code you are running, than make sure to use git.
>>
>> I do, but the minor annoyance of having the exact same version
>> string/time stamp for different code still exists for uncommited
>> changes.
>
> You must be doing something awfully wrong when  you  have  uncommited
> changes in any form of software you're releasing.


I don't think he's wanting this as much for releases (which would be
fine with the git id as you mentioned), but during the development
process.  It is very useful during development to have a timestamp
which confirms that what you are running now is what you expect.
There are various ways I have used this:

* Catch that I failed to copy the new image to my tftp directory
* Confirm that I'm booting from the flash bank I just programmed
* Helpful for figuring out which of the files in my tftp directory
corresponds to what's running

Also, while I can see good arguments for not having a time stamp,
having one that is not up-to-date seems totally useless.  The stamp
might not be updated for months, and thus provides only an indicator
as to when the date was last updated.

Upshot: I endorse this patch's concept, and urge Peter to put in his
(apparently underpaid) time to complete it.  :)

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

Re: [U-Boot] [PATCH] AT91: Enable PLLB for USB

[Remy Bohmer]

Hello Stelian,

2008/10/21 Stelian Pop <[EMAIL PROTECTED]>:
> At least some (old ?) versions of the AT91Bootstrap do not set up the
> PLLB correctly to 48 MHz in order to make USB host function correctly.
>
> This patch sets up the PLLB to the same values Linux uses, and makes USB
> work ok on the following CPUs:
>- AT91CAP9
>- AT91SAM9260
>- AT91SAM9263

Are all your USB stick problems solved by now? Including that stick
that did not work?

I noticed that (with my latest patchset) sometimes a cold boot result
in a non-working USB stick on my boards, but a hard reset always
worked...

I will try your patches tomorrow, but I have one question:
> #define AT91_MAIN_CLOCK18432000/* 18.432 MHz crystal 
> */
>  #define AT91_MASTER_CLOCK  1   /* peripheral */
>  #define AT91_CPU_CLOCK 2   /* cpu */

Are such nice rounded values possible with that unrounded crystal?

Looking at sam9261 I see:
#define AT91_MAIN_CLOCK 198656000   /* from 18.432 MHz crystal */
#define AT91_MASTER_CLOCK   99328000/* peripheral = main / 2

This seems more logical to me, but I may be wrong...


Kind Regards,

Remy


>
> This patch also defines CONFIG_USB_STORAGE and CONFIG_CMD_FAT for all
> the relevant AT91CAP9/AT91SAM9 boards.
>
> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
> ---
>  cpu/arm926ejs/at91/usb.c|   18 ++
>  include/configs/at91cap9adk.h   |3 +++
>  include/configs/at91sam9260ek.h |2 ++
>  include/configs/at91sam9261ek.h |1 +
>  include/configs/at91sam9263ek.h |2 ++
>  5 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/arm926ejs/at91/usb.c b/cpu/arm926ejs/at91/usb.c
> index 2a92f73..c02334f 100644
> --- a/cpu/arm926ejs/at91/usb.c
> +++ b/cpu/arm926ejs/at91/usb.c
> @@ -31,6 +31,15 @@
>
>  int usb_cpu_init(void)
>  {
> +
> +#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
> +defined(CONFIG_AT91SAM9263)
> +   /* Enable PLLB */
> +   at91_sys_write(AT91_CKGR_PLLBR, CFG_AT91_PLLB);
> +   while ((at91_sys_read(AT91_PMC_SR) & AT91_PMC_LOCKB) != 
> AT91_PMC_LOCKB)
> +   ;
> +#endif
> +
>/* Enable USB host clock. */
>at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_UHP);
>  #ifdef CONFIG_AT91SAM9261
> @@ -51,6 +60,15 @@ int usb_cpu_stop(void)
>  #else
>at91_sys_write(AT91_PMC_SCDR, AT91_PMC_UHP);
>  #endif
> +
> +#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
> +defined(CONFIG_AT91SAM9263)
> +   /* Disable PLLB */
> +   at91_sys_write(AT91_CKGR_PLLBR, 0);
> +   while ((at91_sys_read(AT91_PMC_SR) & AT91_PMC_LOCKB) != 0)
> +   ;
> +#endif
> +
>return 0;
>  }
>
> diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
> index 1dbd3a4..47145d8 100644
> --- a/include/configs/at91cap9adk.h
> +++ b/include/configs/at91cap9adk.h
> @@ -32,6 +32,7 @@
>  #define AT91_MAIN_CLOCK1200/* 12 MHz crystal */
>  #define AT91_MASTER_CLOCK  1   /* peripheral */
>  #define AT91_CPU_CLOCK 2   /* cpu */
> +#define CFG_AT91_PLLB  0x10073e01  /* PLLB settings for USB */
>  #define CFG_HZ 100 /* 1us resolution */
>
>  #define AT91_SLOW_CLOCK32768   /* slow clock */
> @@ -137,6 +138,8 @@
>  #define CFG_USB_OHCI_REGS_BASE 0x0070  /* AT91_BASE_UHP */
>  #define CFG_USB_OHCI_SLOT_NAME "at91cap9"
>  #define CFG_USB_OHCI_MAX_ROOT_PORTS2
> +#define CONFIG_USB_STORAGE 1
> +#define CONFIG_CMD_FAT 1
>
>  #define CFG_LOAD_ADDR  0x7200  /* load address */
>
> diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
> index cb8857a..cd09288 100644
> --- a/include/configs/at91sam9260ek.h
> +++ b/include/configs/at91sam9260ek.h
> @@ -32,6 +32,7 @@
>  #define AT91_MAIN_CLOCK18432000/* 18.432 MHz crystal 
> */
>  #define AT91_MASTER_CLOCK  1   /* peripheral */
>  #define AT91_CPU_CLOCK 2   /* cpu */
> +#define CFG_AT91_PLLB  0x107c3e18  /* PLLB settings for USB */
>  #define CFG_HZ 100 /* 1us resolution */
>
>  #define AT91_SLOW_CLOCK32768   /* slow clock */
> @@ -123,6 +124,7 @@
>  #define CFG_USB_OHCI_SLOT_NAME "at91sam9260"
>  #define CFG_USB_OHCI_MAX_ROOT_PORTS2
>  #define CONFIG_USB_STORAGE 1
> +#define CONFIG_CMD_FAT 1
>
>  #define CFG_LOAD_ADDR  0x2200  /* load address */
>
> diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
> index 92e134d..aa6c6ab 100644
> --- a/include/configs/at91sam9261ek.h
> +++ b/include/configs/at91sam9261ek.h
> @@ -137,6 +137,7 @@
>  #define CFG_USB_OHCI_SLOT_NAME "at91sam9261"
>  #define CFG_USB_OHCI_MAX_ROOT_PO

Re: [U-Boot] booting the kernel

[Jerry Van Baren]

Mathieu Dube wrote:
> Hi,
> Im trying to boot the linux kernel with uboot and it just hangs so I
> tried the instructions in the Linux PostMortem FAQ entry.
> 
> I'd like to know if I could be doing something obviously wrong here:
> 
> the kernel I use is for freescale imx31_litekit. I've booted it using the
> logicpd loader so I know it works.
> 
> I use the arch/arm/boot/Image with mkimage like this:
> 
> mkimage -A arm -O linux -T kernel -C none -a 8600 -e 8600 -d Image
> image.bin
> 
> are the load address and entry point ok? if not how can I determine which
> value they should have?

Sorry, I don't know.

> Starting kernel ...
> 
> and hangs there, if I use my jtag I can see that the core is running ie: it
> doesnt crash. Btw I've also tried with the jtag attached so thats not the
> problem.

Do you have a console configured and enabled?

> __log_buf in my System.map is at c035c168
> and CONFIG_KERNEL_START is c000
> 
> so am I right to do
> 
> md 8635c168 ?
> 
> there doesnt seem to be anything interesting around this address...

Try 0035c168 - I'm not a arm-man, but the linux kernel traditionally 
relocates itself at location  and remaps itself to the virtual 
address c000.  When you are looking with the debugger, you need to 
drop the "c" to get the physical address.

> what else could I try to figure out why the kernel isnt booting?
> 
> thanks a lot.
> -M

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

[U-Boot] booting the kernel

[Mathieu Dube]

Hi,
Im trying to boot the linux kernel with uboot and it just hangs so I
tried the instructions in the Linux PostMortem FAQ entry.

I'd like to know if I could be doing something obviously wrong here:

the kernel I use is for freescale imx31_litekit. I've booted it using the
logicpd loader so I know it works.

I use the arch/arm/boot/Image with mkimage like this:

mkimage -A arm -O linux -T kernel -C none -a 8600 -e 8600 -d Image
image.bin

are the load address and entry point ok? if not how can I determine which
value they should have?

I tftp it to 0x8100 like this:

tftp 0x8100 /tftpboot/image.bin

that works fine

then I bootm

it loads the kernel and ends up printing:

Starting kernel ...

and hangs there, if I use my jtag I can see that the core is running ie: it
doesnt crash. Btw I've also tried with the jtag attached so thats not the
problem.

__log_buf in my System.map is at c035c168
and CONFIG_KERNEL_START is c000

so am I right to do

md 8635c168 ?

there doesnt seem to be anything interesting around this address...

what else could I try to figure out why the kernel isnt booting?

thanks a lot.
-M

-- 
Mathieu Dube
Software Engineer
MobileFusion, Inc
2715 Sarah St
Pittsburgh PA, 15203
Main: 412.481. Ext:140
Fax: 412.481.0220
Email: [EMAIL PROTECTED]
URL: www.mobilefusioninc.com

This communication (including any attachments) is for the use of the
intended recipient(s) only and may contain information that is confidential,
privileged or otherwise legally protected. Any unauthorized use or
dissemination of this communication is prohibited. If you have received this
communication in error, please immediately notify the sender by return
e-mail message and delete all copies of the original communication. Thank
you for your cooperation.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] improved strmhz()

[Mike Frysinger]

On Tuesday 21 October 2008, Kumar Gala wrote:
> I haven't been following this thread, but can we control the number of
> significant digits.

customizable # of digits is always going to differ according to taste.  just 
lock everyone to like .3 and be done.  no point in wasting overhead on this.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] improved strmhz()

[Jerry Van Baren]

Kumar Gala wrote:
>> That looks overly complex to me. Can you please check if this patch
>> fixes the problem for your test cases, too:
>>
>>> From 963e7db81379225b78bfac0d7457300c86d6b4d6 Mon Sep 17 00:00:00  
>>> 2001
>> From: Wolfgang Denk <[EMAIL PROTECTED]>
>> Date: Tue, 21 Oct 2008 15:53:51 +0200
>> Subject: [PATCH] Fix strmhz(): avoid printing negative fractions
>>
>> Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
>> ---
>> lib_generic/strmhz.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/lib_generic/strmhz.c b/lib_generic/strmhz.c
>> index 342cf2b..d6da1d1 100644
>> --- a/lib_generic/strmhz.c
>> +++ b/lib_generic/strmhz.c
>> @@ -27,7 +27,7 @@ char *strmhz (char *buf, long hz)
>>  long l, n;
>>  long m;
>>
>> -n = DIV_ROUND(hz, 100L);
>> +n = DIV_ROUND(hz, 1000) / 1000L;
>>  l = sprintf (buf, "%ld", n);
>>
>>  hz -= n * 100L;
>> -- 
>> 1.5.5.1
> 
> I haven't been following this thread, but can we control the number of  
> significant digits.  I'm starting to see output like:
> 
> Clock Configuration:
> CPU:1500.4294967282 MHz, CCB:600.4294967291 MHz,
> DDR:400.4294967293 MHz (800.4294967289 MT/s data rate)  

(unsigned) 4294967289 = (signed) -7 (if I did my math right).  This is 
indicating Wolfgang's patch still does negative remainders, but masks 
that by printing them as unsigned numbers.

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

Re: [U-Boot] [PATCH] improved strmhz()

[Kumar Gala]

>>
> That looks overly complex to me. Can you please check if this patch
> fixes the problem for your test cases, too:
>
>> From 963e7db81379225b78bfac0d7457300c86d6b4d6 Mon Sep 17 00:00:00  
>> 2001
> From: Wolfgang Denk <[EMAIL PROTECTED]>
> Date: Tue, 21 Oct 2008 15:53:51 +0200
> Subject: [PATCH] Fix strmhz(): avoid printing negative fractions
>
> Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
> ---
> lib_generic/strmhz.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib_generic/strmhz.c b/lib_generic/strmhz.c
> index 342cf2b..d6da1d1 100644
> --- a/lib_generic/strmhz.c
> +++ b/lib_generic/strmhz.c
> @@ -27,7 +27,7 @@ char *strmhz (char *buf, long hz)
>   long l, n;
>   long m;
>
> - n = DIV_ROUND(hz, 100L);
> + n = DIV_ROUND(hz, 1000) / 1000L;
>   l = sprintf (buf, "%ld", n);
>
>   hz -= n * 100L;
> -- 
> 1.5.5.1

I haven't been following this thread, but can we control the number of  
significant digits.  I'm starting to see output like:

Clock Configuration:
CPU:1500.4294967282 MHz, CCB:600.4294967291 MHz,
DDR:400.4294967293 MHz (800.4294967289 MT/s data rate)  
(Asynchronous), LBC:37.500 MHz

(it use to look like)

Clock Configuration:
CPU:1500 MHz, CCB: 600 MHz,
DDR: 401 MHz (801 MT/s data rate) (Asynchronous), LBC:  37 MHz

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

Re: [U-Boot] [PATCH] lcd: print custom strings after the logo

[Stelian Pop]

Le mardi 21 octobre 2008 à 18:43 +0200, Ilko Iliev a écrit :

> >> +#ifndef CONFIG_LCD_LOGO_TEXT1
> >> +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> >> +#endif
> >> 
> >
> > Wouldn't it be better if we move this text into
> > include/configs/at91xxx.h for all the boards ?
> >   
> Yes, it will be better.
> Because I'm a newbie in the U-BOOT development I didn't want to make 
> changes in all boards.


> I have also other suggestions: see my email for the lowlevel_init.S

Yes, I saw them. Wolfgang proposed to use a weak function, which is
probably way better 

> Do you know why the CPU registers are defined in this way:
> #define AT91_PMC(0xfc00 - AT91_BASE_SYS)

This is because the header files ware copied (with some editing) from
Linux, and this is how Linux does define those register offsets.

> This is OK for a C-code, but for an assembler it is a problem because 
> the following code gives an "Error: bad immediate value for offset":
> ldr r1, =AT91_BASE_SYS

You shouldn't do this. Look at at91_sys_read()/at91_sys_write()
implementation. So the code should be:
ldr r1, =(AT91_BASE_SYS + AT91_PMC)

which will be optimised by cpp to:
ldr r1, =0xfc00

Stelian.
-- 
Stelian Pop <[EMAIL PROTECTED]>

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

[U-Boot] [PATCH] pci: Allow for PCI addresses to be 64-bit

[Kumar Gala]

PCI bus is inherently 64-bit.  While not all system require access to
the full 64-bit PCI address range some do.  This allows those systems
to enable the full PCI address width via CONFIG_PCI_64BIT.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 drivers/pci/pci.c  |4 ++--
 drivers/pci/pci_auto.c |   22 +++---
 include/pci.h  |   24 
 3 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 41780db..127d50f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -223,7 +223,7 @@ unsigned long pci_hose_phys_to_bus (struct pci_controller 
*hose,
unsigned long flags)
 {
struct pci_region *res;
-   unsigned long bus_addr;
+   pci_addr_t bus_addr;
int i;
 
if (!hose) {
@@ -252,7 +252,7 @@ Done:
 }
 
 phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-unsigned long bus_addr,
+pci_addr_t bus_addr,
 unsigned long flags)
 {
struct pci_region *res;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 3844359..547ce5b 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -52,7 +52,7 @@ void pciauto_region_align(struct pci_region *res, unsigned 
long size)
 
 int pciauto_region_allocate(struct pci_region* res, unsigned int size, 
unsigned int *bar)
 {
-   unsigned long addr;
+   pci_addr_t addr;
 
if (!res) {
DEBUGF("No resource");
@@ -68,7 +68,7 @@ int pciauto_region_allocate(struct pci_region* res, unsigned 
int size, unsigned
 
res->bus_lower = addr + size;
 
-   DEBUGF("address=0x%lx bus_lower=%x", addr, res->bus_lower);
+   DEBUGF("address=0x%llx bus_lower=%llx", (u64)addr, (u64)res->bus_lower);
 
*bar = addr;
return 0;
@@ -289,10 +289,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_mem) {
pciauto_region_init(hose->pci_mem);
 
-   DEBUGF("PCI Autoconfig: Bus Memory region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Memory region: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
-   hose->pci_mem->bus_start,
-   hose->pci_mem->bus_start + hose->pci_mem->size - 1,
+   (u64)hose->pci_mem->bus_start,
+   (u64)(hose->pci_mem->bus_start + hose->pci_mem->size - 1),
hose->pci_mem->phys_start,
hose->pci_mem->phys_start + hose->pci_mem->size - 1);
}
@@ -300,10 +300,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_prefetch) {
pciauto_region_init(hose->pci_prefetch);
 
-   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
-   hose->pci_prefetch->bus_start,
-   hose->pci_prefetch->bus_start + hose->pci_prefetch->size - 
1,
+   (u64)hose->pci_prefetch->bus_start,
+   (u64)(hose->pci_prefetch->bus_start + 
hose->pci_prefetch->size - 1),
hose->pci_prefetch->phys_start,
hose->pci_prefetch->phys_start +
hose->pci_prefetch->size - 1);
@@ -312,10 +312,10 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_io) {
pciauto_region_init(hose->pci_io);
 
-   DEBUGF("PCI Autoconfig: Bus I/O region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus I/O region: [%llx-%llx],\n"
   "\t\tPhysical Memory: [%x-%x]\n",
-   hose->pci_io->bus_start,
-   hose->pci_io->bus_start + hose->pci_io->size - 1,
+   (u64)hose->pci_io->bus_start,
+   (u64)(hose->pci_io->bus_start + hose->pci_io->size - 1),
hose->pci_io->phys_start,
hose->pci_io->phys_start + hose->pci_io->size - 1);
 
diff --git a/include/pci.h b/include/pci.h
index 1c8e216..5249e88 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -312,13 +312,21 @@
 
 #include 
 
+#ifdef CONFIG_PCI_64BIT
+typedef u64 pci_addr_t;
+typedef u64 pci_size_t;
+#else
+typedef u32 pci_addr_t;
+typedef u32 pci_size_t;
+#endif
+
 struct pci_region {
-   unsigned long bus_start;/* Start on the bus */
-   phys_addr_t phys_start; /* Start in physical address 
space */
-   unsigned long size; /* Size */
-   unsigned long flags;/* Resource flags */
+   pci_addr_t bus_start;   /* Start on the bus */
+   phys_addr_t phys_start; /* Start in physical address space */
+   pci_size_t size;/* Size */
+   unsigned

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:00 Tue 21 Oct , Ilko Iliev wrote:
> Wolfgang Denk wrote:
> > Dear Ilko Iliev,
> >
> > In message <[EMAIL PROTECTED]> you wrote:
> >   
> >> This patch allows to have an at91 board specific lowlevel_init.S
> >>
> >> Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
> >>
> >> index ec6ad5d..7882e89 100644
> >> --- a/cpu/arm926ejs/at91/lowlevel_init.S
> >> +++ b/cpu/arm926ejs/at91/lowlevel_init.S
> >> @@ -27,7 +27,7 @@
> >>  #include 
> >>  #include 
> >>
> >> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> >> +#if !defined(CONFIG_SKIP_LOWLEVEL_INIT) && 
> >> !defined(CONFIG_USER_LOWLEVEL_INIT)
> >>
> >>  .globl lowlevel_init
> >>  lowlevel_init:
> >> @@ -39,5 +39,5 @@ lowlevel_init:
> >> mov pc, lr
> >>
> >> .ltorg
> >> -
> >> -#endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> >> +
> >> +#endif /* !CONFIG_SKIP_LOWLEVEL_INIT && !CONFIG_USER_LOWLEVEL_INIT */
> >> 
> >
> > Maybe instead of adding mor #ifdef'ery here, we can turn
> > lowlevel_init() into a "weak" function that can be redefined by board
> > specific code?
> The lowlevel_init() is an assembler function called from another 
> assembler function and the attribute .weak doesn't work.
> There are no assembler file in the U-BOOT tree which use weak functions.
> Do you know how can I make an assembler function weak?
IIRC .weak fct1 = fct2 should work

.weakref not

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

Re: [U-Boot] [PATCH] lcd: print custom strings after the logo

[Ilko Iliev]

Hello Stelian,

Stelian Pop wrote:
> Le mardi 21 octobre 2008 à 15:10 +0200, Ilko Iliev a écrit :
>   
>> This patch allows to print custom strings on the LCD after the logo.
>> 
>
> Hi Ilko,
>
>   
>> Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
>>
>> index d104b26..a94a4da 100644
>> --- a/common/lcd.c
>> +++ b/common/lcd.c
>> @@ -827,11 +827,19 @@ static void *lcd_logo (void)
>> sprintf (info, "%s", U_BOOT_VERSION);
>> lcd_drawchars (LCD_INFO_X, LCD_INFO_Y, (uchar *)info, strlen(info));
>>
>> -   sprintf (info, "(C) 2008 ATMEL Corp");
>> +#ifndef CONFIG_LCD_LOGO_TEXT1
>> +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
>> +#endif
>> 
>
> Wouldn't it be better if we move this text into
> include/configs/at91xxx.h for all the boards ?
>   
Yes, it will be better.
Because I'm a newbie in the U-BOOT development I didn't want to make 
changes in all boards.

I have also other suggestions: see my email for the lowlevel_init.S

Do you know why the CPU registers are defined in this way:
#define AT91_PMC(0xfc00 - AT91_BASE_SYS)

This is OK for a C-code, but for an assembler it is a problem because 
the following code gives an "Error: bad immediate value for offset":
ldr r1, =AT91_BASE_SYS
ldrr0, [r1, #AT91_PMC_MCKR]


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

[U-Boot] [PATCH] ppc4xx: Generic architecture for xilinx ppc405(v3)

[Ricardo Ribalda Delgado]

As "ppc44x: Unification of virtex5 pp440 boards" did for the xilinx
ppc440 boards, this patch presents a common architecture for all the
xilinx ppc405 boards.

Any custom xilinx ppc405 board can be added very easily with no code
duplicity.

This patch also adds a simple generic board, that can be used on almost
any design with xilinx ppc405 replacing the file ppc405-generic/xparameters.h

This patch is prepared to work with the latest version of EDK (10.1)

Signed-off-by: Ricardo Ribalda Delgado <[EMAIL PROTECTED]>
---
v2
Includes changes propossed by Stefan Roese

-Remove unneeded init.S
-PPC404 ->PPC405
v3
rebased to ppc4xx/master

 CREDITS|1 +
 MAINTAINERS|1 +
 Makefile   |   16 ++
 board/xilinx/ppc405-generic/.gitignore |1 +
 board/xilinx/ppc405-generic/Makefile   |   60 
 board/xilinx/ppc405-generic/config.mk  |   25 
 board/xilinx/ppc405-generic/u-boot-ram.lds |  134 ++
 board/xilinx/ppc405-generic/u-boot-rom.lds |  144 
 .../xilinx/ppc405-generic/xilinx_ppc405_generic.c  |   59 
 board/xilinx/ppc405-generic/xparameters.h  |   36 +
 cpu/ppc4xx/start.S |3 +-
 include/configs/xilinx-ppc405-generic.h|   58 
 include/configs/xilinx-ppc405.h|  126 +
 13 files changed, 663 insertions(+), 1 deletions(-)
 create mode 100644 board/xilinx/ppc405-generic/.gitignore
 create mode 100644 board/xilinx/ppc405-generic/Makefile
 create mode 100644 board/xilinx/ppc405-generic/config.mk
 create mode 100644 board/xilinx/ppc405-generic/u-boot-ram.lds
 create mode 100644 board/xilinx/ppc405-generic/u-boot-rom.lds
 create mode 100644 board/xilinx/ppc405-generic/xilinx_ppc405_generic.c
 create mode 100644 board/xilinx/ppc405-generic/xparameters.h
 create mode 100644 include/configs/xilinx-ppc405-generic.h
 create mode 100644 include/configs/xilinx-ppc405.h

diff --git a/CREDITS b/CREDITS
index 3767322..9ddf0d2 100644
--- a/CREDITS
+++ b/CREDITS
@@ -407,6 +407,7 @@ N: Ricardo Ribalda Delgado
 E: [EMAIL PROTECTED]
 D: PPC440x5 (Virtex5), ML507 Board, eeprom_simul, adt7460, v5fx30teval
 D: Virtex ppc440 generic architecture
+D: Virtex ppc405 generic architecture
 W: http://www.ii.uam.es/~rribalda
 
 N: Stefan Roese
diff --git a/MAINTAINERS b/MAINTAINERS
index 60cb6a6..a5d1038 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -320,6 +320,7 @@ Ricardo Ribalda <[EMAIL PROTECTED]>
ml507   PPC440x5
v5fx30teval PPC440x5
xilinx-pp440-genericPPC440x5
+   xilinx-pp405-genericPPC405
 
 Stefan Roese <[EMAIL PROTECTED]>
 
diff --git a/Makefile b/Makefile
index fceb8a2..66922eb 100644
--- a/Makefile
+++ b/Makefile
@@ -1518,6 +1518,22 @@ sycamore_config: unconfig
 WUH405_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc ppc4xx wuh405 esd
 
+xilinx-ppc405-generic_flash_config: unconfig
+   @mkdir -p $(obj)include $(obj)board/xilinx/ppc405-generic
+   @echo "LDSCRIPT:=$(SRCTREE)/board/xilinx/ppc405-generic/u-boot-rom.lds"\
+   > $(obj)board/xilinx/ppc405-generic/config.tmp
+   @echo "TEXT_BASE := 0xFE36" \
+   >> $(obj)board/xilinx/ppc405-generic/config.tmp
+   @$(MKCONFIG) xilinx-ppc405-generic ppc ppc4xx ppc405-generic xilinx
+
+xilinx-ppc405-generic_config: unconfig
+   @mkdir -p $(obj)include $(obj)board/xilinx/ppc405-generic
+   @echo "LDSCRIPT:=$(SRCTREE)/board/xilinx/ppc405-generic/u-boot-ram.lds"\
+   > $(obj)board/xilinx/ppc405-generic/config.tmp
+   @echo "TEXT_BASE := 0x0400" \
+   >> $(obj)board/xilinx/ppc405-generic/config.tmp
+   @$(MKCONFIG) xilinx-ppc405-generic ppc ppc4xx ppc405-generic xilinx
+
 xilinx-ppc440-generic_flash_config: unconfig
@mkdir -p $(obj)include $(obj)board/xilinx/ppc440-generic
@echo "LDSCRIPT:=$(SRCTREE)/board/xilinx/ppc440-generic/u-boot-rom.lds"\
diff --git a/board/xilinx/ppc405-generic/.gitignore 
b/board/xilinx/ppc405-generic/.gitignore
new file mode 100644
index 000..b644f59
--- /dev/null
+++ b/board/xilinx/ppc405-generic/.gitignore
@@ -0,0 +1 @@
+config.tmp
diff --git a/board/xilinx/ppc405-generic/Makefile 
b/board/xilinx/ppc405-generic/Makefile
new file mode 100644
index 000..b56bb49
--- /dev/null
+++ b/board/xilinx/ppc405-generic/Makefile
@@ -0,0 +1,60 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+#
+# (C) Copyright 2008
+# Ricardo Ribalda-Universidad Autonoma de [EMAIL PROTECTED]
+# Work supported by Qtechnology http://www.qtec.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# publ

Re: [U-Boot] [PATCH] lcd: print custom strings after the logo

[Stelian Pop]

Le mardi 21 octobre 2008 à 15:10 +0200, Ilko Iliev a écrit :
> This patch allows to print custom strings on the LCD after the logo.

Hi Ilko,

> Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
> 
> index d104b26..a94a4da 100644
> --- a/common/lcd.c
> +++ b/common/lcd.c
> @@ -827,11 +827,19 @@ static void *lcd_logo (void)
> sprintf (info, "%s", U_BOOT_VERSION);
> lcd_drawchars (LCD_INFO_X, LCD_INFO_Y, (uchar *)info, strlen(info));
> 
> -   sprintf (info, "(C) 2008 ATMEL Corp");
> +#ifndef CONFIG_LCD_LOGO_TEXT1
> +# define CONFIG_LCD_LOGO_TEXT1 "(C) 2008 ATMEL Corp"
> +#endif

Wouldn't it be better if we move this text into
include/configs/at91xxx.h for all the boards ?


-- 
Stelian Pop <[EMAIL PROTECTED]>

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

Re: [U-Boot] Hangs at relocation on 460EX Target

[Ayman M. El-Khashab]

Thank you Stefan,

On Tue, Oct 21, 2008 at 05:54:21PM +0200, Stefan Roese wrote:
> On Tuesday 21 October 2008, Ayman M. El-Khashab wrote:
> > it is stuck inside the relocation or immediately after it branches
> > to the code in RAM.
> 
> I suggest that you enable DEBUG in lib_ppc/board.c (define DEBUG before the 
> #includes). This will show you a little more.

I should have mentioned that we have DEBUG enabled and we've also 
run the RAM test that is included in u-boot.  The ram test does pass.

> 
> But you may be correct that U-Boot hangs/crashes upon relocation. This is 
> most 
> likely a problem with the DDR2 configuration. You might have noticed the 
> latest autocalibration changes for the 4xx DDR2 controller. It's worth to 
> give these new methods a try.

I am not familiar with those, I thought that once the SDRAM is operating
you cannot alter those calibration and timing/delay registers.  Is this 
calibration something that is enabled in u-boot or just via the register
accesses to the memory controller?

Thanks
Ayman

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

[U-Boot] [PATCH] AT91: Use AT91_CPU_CLOCK in displays

[Stelian Pop]

Introduce AT91_CPU_CLOCK and use it for displaying the CPU
speed in the LCD driver.

Also make AT91_MAIN_CLOCK and AT91_MASTER_CLOCK reflect the
corresponding board clocks.

Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
---
 common/lcd.c|2 +-
 include/configs/at91cap9adk.h   |5 +++--
 include/configs/at91sam9260ek.h |6 --
 include/configs/at91sam9261ek.h |5 +++--
 include/configs/at91sam9263ek.h |5 +++--
 include/configs/at91sam9rlek.h  |5 +++--
 6 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index 25f8664..c6ced91 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -837,7 +837,7 @@ static void *lcd_logo (void)
 
sprintf (info, "%s CPU at %s MHz",
AT91_CPU_NAME,
-   strmhz(temp, AT91_MAIN_CLOCK));
+   strmhz(temp, AT91_CPU_CLOCK));
lcd_drawchars (LCD_INFO_X, LCD_INFO_Y + VIDEO_FONT_HEIGHT * 3,
(uchar *)info, strlen(info));
 
diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index fd06245..1dbd3a4 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -29,8 +29,9 @@
 
 /* ARM asynchronous clock */
 #define AT91_CPU_NAME  "AT91CAP9"
-#define AT91_MAIN_CLOCK2   /* from 12 MHz crystal 
*/
-#define AT91_MASTER_CLOCK  1   /* peripheral = main / 2 */
+#define AT91_MAIN_CLOCK1200/* 12 MHz crystal */
+#define AT91_MASTER_CLOCK  1   /* peripheral */
+#define AT91_CPU_CLOCK 2   /* cpu */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 41d1da3..cb8857a 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -28,8 +28,10 @@
 #define __CONFIG_H
 
 /* ARM asynchronous clock */
-#define AT91_MAIN_CLOCK198656000   /* from 18.432 MHz 
crystal */
-#define AT91_MASTER_CLOCK  99328000/* peripheral = main / 2 */
+#define AT91_CPU_NAME  "AT91SAM9260"
+#define AT91_MAIN_CLOCK18432000/* 18.432 MHz crystal */
+#define AT91_MASTER_CLOCK  1   /* peripheral */
+#define AT91_CPU_CLOCK 2   /* cpu */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
index 80c3b03..92e134d 100644
--- a/include/configs/at91sam9261ek.h
+++ b/include/configs/at91sam9261ek.h
@@ -29,8 +29,9 @@
 
 /* ARM asynchronous clock */
 #define AT91_CPU_NAME  "AT91SAM9261"
-#define AT91_MAIN_CLOCK198656000   /* from 18.432 MHz 
crystal */
-#define AT91_MASTER_CLOCK  99328000/* peripheral = main / 2 */
+#define AT91_MAIN_CLOCK18432000/* 18.432 MHz crystal */
+#define AT91_MASTER_CLOCK  1   /* peripheral */
+#define AT91_CPU_CLOCK 2   /* cpu */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index b4368ef..c914571 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -29,8 +29,9 @@
 
 /* ARM asynchronous clock */
 #define AT91_CPU_NAME  "AT91SAM9263"
-#define AT91_MAIN_CLOCK199919000   /* from 16.367 MHz 
crystal */
-#define AT91_MASTER_CLOCK  99959500/* peripheral = main / 2 */
+#define AT91_MAIN_CLOCK16367660/* 16.367 MHz crystal */
+#define AT91_MASTER_CLOCK  1   /* peripheral */
+#define AT91_CPU_CLOCK 2   /* cpu */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h
index 32168dc..9bcd2db 100644
--- a/include/configs/at91sam9rlek.h
+++ b/include/configs/at91sam9rlek.h
@@ -29,8 +29,9 @@
 
 /* ARM asynchronous clock */
 #define AT91_CPU_NAME  "AT91SAM9RL"
-#define AT91_MAIN_CLOCK2   /* from 12.000 MHz 
crystal */
-#define AT91_MASTER_CLOCK  1   /* peripheral = main / 2 */
+#define AT91_MAIN_CLOCK1200/* 12 MHz crystal */
+#define AT91_MASTER_CLOCK  1   /* peripheral */
+#define AT91_CPU_CLOCK 2   /* cpu */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
-- 
1.5.4.3

___
U

[U-Boot] [PATCH] AT91: Replace AT91_BASE_EMAC by the board specific values.

[Stelian Pop]

AT91_BASE_EMAC is never used outside the board specific files,
so replace its usage by the board specific AT91xxx_BASE_EMAC.

Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
---
 board/atmel/at91cap9adk/at91cap9adk.c |2 +-
 board/atmel/at91sam9260ek/at91sam9260ek.c |2 +-
 board/atmel/at91sam9263ek/at91sam9263ek.c |2 +-
 include/asm-arm/arch-at91/hardware.h  |3 ---
 4 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/board/atmel/at91cap9adk/at91cap9adk.c 
b/board/atmel/at91cap9adk/at91cap9adk.c
index 787d64d..0f39de6 100644
--- a/board/atmel/at91cap9adk/at91cap9adk.c
+++ b/board/atmel/at91cap9adk/at91cap9adk.c
@@ -383,7 +383,7 @@ int board_eth_init(bd_t *bis)
 {
int rc = 0;
 #ifdef CONFIG_MACB
-   rc = macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
+   rc = macb_eth_initialize(0, (void *)AT91CAP9_BASE_EMAC, 0x00);
 #endif
return rc;
 }
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c 
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 913e3fb..25a33b2 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -255,7 +255,7 @@ int board_eth_init(bd_t *bis)
 {
int rc = 0;
 #ifdef CONFIG_MACB
-   rc = macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
+   rc = macb_eth_initialize(0, (void *)AT91SAM9260_BASE_EMAC, 0x00);
 #endif
return rc;
 }
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c 
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index c705074..f5718df 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -315,7 +315,7 @@ int board_eth_init(bd_t *bis)
 {
int rc = 0;
 #ifdef CONFIG_MACB
-   rc = macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
+   rc = macb_eth_initialize(0, (void *)AT91SAM9263_BASE_EMAC, 0x00);
 #endif
return rc;
 }
diff --git a/include/asm-arm/arch-at91/hardware.h 
b/include/asm-arm/arch-at91/hardware.h
index f312419..b881e4e 100644
--- a/include/asm-arm/arch-at91/hardware.h
+++ b/include/asm-arm/arch-at91/hardware.h
@@ -20,7 +20,6 @@
 #include 
 #elif defined(CONFIG_AT91SAM9260)
 #include 
-#define AT91_BASE_EMAC AT91SAM9260_BASE_EMAC
 #define AT91_BASE_SPI  AT91SAM9260_BASE_SPI0
 #define AT91_ID_UHPAT91SAM9260_ID_UHP
 #define AT91_PMC_UHP   AT91SAM926x_PMC_UHP
@@ -31,7 +30,6 @@
 #define AT91_PMC_UHP   AT91SAM926x_PMC_UHP
 #elif defined(CONFIG_AT91SAM9263)
 #include 
-#define AT91_BASE_EMAC AT91SAM9263_BASE_EMAC
 #define AT91_BASE_SPI  AT91SAM9263_BASE_SPI0
 #define AT91_ID_UHPAT91SAM9263_ID_UHP
 #define AT91_PMC_UHP   AT91SAM926x_PMC_UHP
@@ -41,7 +39,6 @@
 #define AT91_ID_UHPAT91SAM9RL_ID_UHP
 #elif defined(CONFIG_AT91CAP9)
 #include 
-#define AT91_BASE_EMAC AT91CAP9_BASE_EMAC
 #define AT91_BASE_SPI  AT91CAP9_BASE_SPI0
 #define AT91_ID_UHPAT91CAP9_ID_UHP
 #define AT91_PMC_UHP   AT91CAP9_PMC_UHP
-- 
1.5.4.3

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

[U-Boot] [PATCH] AT91: Replace (undefined) AT91_ID_US* by the board specific values.

[Stelian Pop]

AT91_ID_US0 / AT91_ID_US1 / AT91_ID_US2 were used but never defined.
Since they are never used outside the board specific files, they can
be replaced by the board specific AT91xxx_ID_US0 / AT91xxx_ID_US1 /
AT91xxx_ID_US2.

Bug spotted by Jesus Alvarez <[EMAIL PROTECTED]>.

Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
---
 board/atmel/at91cap9adk/at91cap9adk.c |6 +++---
 board/atmel/at91sam9260ek/at91sam9260ek.c |6 +++---
 board/atmel/at91sam9261ek/at91sam9261ek.c |6 +++---
 board/atmel/at91sam9263ek/at91sam9263ek.c |6 +++---
 board/atmel/at91sam9rlek/at91sam9rlek.c   |6 +++---
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/board/atmel/at91cap9adk/at91cap9adk.c 
b/board/atmel/at91cap9adk/at91cap9adk.c
index 0f39de6..57fe617 100644
--- a/board/atmel/at91cap9adk/at91cap9adk.c
+++ b/board/atmel/at91cap9adk/at91cap9adk.c
@@ -52,19 +52,19 @@ static void at91cap9_serial_hw_init(void)
 #ifdef CONFIG_USART0
at91_set_A_periph(AT91_PIN_PA22, 1);/* TXD0 */
at91_set_A_periph(AT91_PIN_PA23, 0);/* RXD0 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91CAP9_ID_US0);
 #endif
 
 #ifdef CONFIG_USART1
at91_set_A_periph(AT91_PIN_PD0, 1); /* TXD1 */
at91_set_A_periph(AT91_PIN_PD1, 0); /* RXD1 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91CAP9_ID_US1);
 #endif
 
 #ifdef CONFIG_USART2
at91_set_A_periph(AT91_PIN_PD2, 1); /* TXD2 */
at91_set_A_periph(AT91_PIN_PD3, 0); /* RXD2 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US2);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91CAP9_ID_US2);
 #endif
 
 #ifdef CONFIG_USART3   /* DBGU */
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c 
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 25a33b2..ca1f11a 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -48,19 +48,19 @@ static void at91sam9260ek_serial_hw_init(void)
 #ifdef CONFIG_USART0
at91_set_A_periph(AT91_PIN_PB4, 1); /* TXD0 */
at91_set_A_periph(AT91_PIN_PB5, 0); /* RXD0 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_US0);
 #endif
 
 #ifdef CONFIG_USART1
at91_set_A_periph(AT91_PIN_PB6, 1); /* TXD1 */
at91_set_A_periph(AT91_PIN_PB7, 0); /* RXD1 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_US1);
 #endif
 
 #ifdef CONFIG_USART2
at91_set_A_periph(AT91_PIN_PB8, 1); /* TXD2 */
at91_set_A_periph(AT91_PIN_PB9, 0); /* RXD2 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US2);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_US2);
 #endif
 
 #ifdef CONFIG_USART3   /* DBGU */
diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c 
b/board/atmel/at91sam9261ek/at91sam9261ek.c
index 647aab5..436f041 100644
--- a/board/atmel/at91sam9261ek/at91sam9261ek.c
+++ b/board/atmel/at91sam9261ek/at91sam9261ek.c
@@ -48,19 +48,19 @@ static void at91sam9261ek_serial_hw_init(void)
 #ifdef CONFIG_USART0
at91_set_A_periph(AT91_PIN_PC8, 1); /* TXD0 */
at91_set_A_periph(AT91_PIN_PC9, 0); /* RXD0 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9261_ID_US0);
 #endif
 
 #ifdef CONFIG_USART1
at91_set_A_periph(AT91_PIN_PC12, 1);/* TXD1 */
at91_set_A_periph(AT91_PIN_PC13, 0);/* RXD1 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9261_ID_US1);
 #endif
 
 #ifdef CONFIG_USART2
at91_set_A_periph(AT91_PIN_PC14, 1);/* TXD2 */
at91_set_A_periph(AT91_PIN_PC15, 0);/* RXD2 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US2);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9261_ID_US2);
 #endif
 
 #ifdef CONFIG_USART3   /* DBGU */
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c 
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index f5718df..3de6b81 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -51,19 +51,19 @@ static void at91sam9263ek_serial_hw_init(void)
 #ifdef CONFIG_USART0
at91_set_A_periph(AT91_PIN_PA26, 1);/* TXD0 */
at91_set_A_periph(AT91_PIN_PA27, 0);/* RXD0 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_US0);
 #endif
 
 #ifdef CONFIG_USART1
at91_set_A_periph(AT91_PIN_PD0, 1); /* TXD1 */
at91_set_A_periph(AT91_PIN_PD1, 0); /* RXD1 */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+ 

[U-Boot] [PATCH] AT91: Enable PLLB for USB

[Stelian Pop]

At least some (old ?) versions of the AT91Bootstrap do not set up the
PLLB correctly to 48 MHz in order to make USB host function correctly.

This patch sets up the PLLB to the same values Linux uses, and makes USB
work ok on the following CPUs:
- AT91CAP9
- AT91SAM9260
- AT91SAM9263

This patch also defines CONFIG_USB_STORAGE and CONFIG_CMD_FAT for all
the relevant AT91CAP9/AT91SAM9 boards.

Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
---
 cpu/arm926ejs/at91/usb.c|   18 ++
 include/configs/at91cap9adk.h   |3 +++
 include/configs/at91sam9260ek.h |2 ++
 include/configs/at91sam9261ek.h |1 +
 include/configs/at91sam9263ek.h |2 ++
 5 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/at91/usb.c b/cpu/arm926ejs/at91/usb.c
index 2a92f73..c02334f 100644
--- a/cpu/arm926ejs/at91/usb.c
+++ b/cpu/arm926ejs/at91/usb.c
@@ -31,6 +31,15 @@
 
 int usb_cpu_init(void)
 {
+
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
+defined(CONFIG_AT91SAM9263)
+   /* Enable PLLB */
+   at91_sys_write(AT91_CKGR_PLLBR, CFG_AT91_PLLB);
+   while ((at91_sys_read(AT91_PMC_SR) & AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
+   ;
+#endif
+
/* Enable USB host clock. */
at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_UHP);
 #ifdef CONFIG_AT91SAM9261
@@ -51,6 +60,15 @@ int usb_cpu_stop(void)
 #else
at91_sys_write(AT91_PMC_SCDR, AT91_PMC_UHP);
 #endif
+
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
+defined(CONFIG_AT91SAM9263)
+   /* Disable PLLB */
+   at91_sys_write(AT91_CKGR_PLLBR, 0);
+   while ((at91_sys_read(AT91_PMC_SR) & AT91_PMC_LOCKB) != 0)
+   ;
+#endif
+
return 0;
 }
 
diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index 1dbd3a4..47145d8 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -32,6 +32,7 @@
 #define AT91_MAIN_CLOCK1200/* 12 MHz crystal */
 #define AT91_MASTER_CLOCK  1   /* peripheral */
 #define AT91_CPU_CLOCK 2   /* cpu */
+#define CFG_AT91_PLLB  0x10073e01  /* PLLB settings for USB */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
@@ -137,6 +138,8 @@
 #define CFG_USB_OHCI_REGS_BASE 0x0070  /* AT91_BASE_UHP */
 #define CFG_USB_OHCI_SLOT_NAME "at91cap9"
 #define CFG_USB_OHCI_MAX_ROOT_PORTS2
+#define CONFIG_USB_STORAGE 1
+#define CONFIG_CMD_FAT 1
 
 #define CFG_LOAD_ADDR  0x7200  /* load address */
 
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index cb8857a..cd09288 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -32,6 +32,7 @@
 #define AT91_MAIN_CLOCK18432000/* 18.432 MHz crystal */
 #define AT91_MASTER_CLOCK  1   /* peripheral */
 #define AT91_CPU_CLOCK 2   /* cpu */
+#define CFG_AT91_PLLB  0x107c3e18  /* PLLB settings for USB */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
@@ -123,6 +124,7 @@
 #define CFG_USB_OHCI_SLOT_NAME "at91sam9260"
 #define CFG_USB_OHCI_MAX_ROOT_PORTS2
 #define CONFIG_USB_STORAGE 1
+#define CONFIG_CMD_FAT 1
 
 #define CFG_LOAD_ADDR  0x2200  /* load address */
 
diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
index 92e134d..aa6c6ab 100644
--- a/include/configs/at91sam9261ek.h
+++ b/include/configs/at91sam9261ek.h
@@ -137,6 +137,7 @@
 #define CFG_USB_OHCI_SLOT_NAME "at91sam9261"
 #define CFG_USB_OHCI_MAX_ROOT_PORTS2
 #define CONFIG_USB_STORAGE 1
+#define CONFIG_CMD_FAT 1
 
 #define CFG_LOAD_ADDR  0x2200  /* load address */
 
diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index c914571..1e9c5c5 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -32,6 +32,7 @@
 #define AT91_MAIN_CLOCK16367660/* 16.367 MHz crystal */
 #define AT91_MASTER_CLOCK  1   /* peripheral */
 #define AT91_CPU_CLOCK 2   /* cpu */
+#define CFG_AT91_PLLB  0x133a3e8d  /* PLLB settings for USB */
 #define CFG_HZ 100 /* 1us resolution */
 
 #define AT91_SLOW_CLOCK32768   /* slow clock */
@@ -143,6 +144,7 @@
 #define CFG_USB_OHCI_SLOT_NAME "at91sam9263"
 #define CFG_USB_OHCI_MAX_ROOT_PORTS2
 #define CONFIG_USB_STORAGE 1
+#define CONFIG_CMD_FAT 1
 
 #define CFG_LOAD_ADDR  0x2200  /* load address */
 
-- 
1.5.4

[U-Boot] [PATCH ARM/AT91 0/4] AT91CAP9/AT91SAM9 bugfixes for 2008.12

[Stelian Pop]

Hi,

The following patches correct a few issues mainly related to USB and
serial initializations in the various AT91CAP9 / AT91SAM9 boards.

Please merge.

Thanks,

Stelian.

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

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

[Ilko Iliev]

Wolfgang Denk wrote:
> Dear Ilko Iliev,
>
> In message <[EMAIL PROTECTED]> you wrote:
>   
>> This patch allows to have an at91 board specific lowlevel_init.S
>>
>> Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
>>
>> index ec6ad5d..7882e89 100644
>> --- a/cpu/arm926ejs/at91/lowlevel_init.S
>> +++ b/cpu/arm926ejs/at91/lowlevel_init.S
>> @@ -27,7 +27,7 @@
>>  #include 
>>  #include 
>>
>> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
>> +#if !defined(CONFIG_SKIP_LOWLEVEL_INIT) && 
>> !defined(CONFIG_USER_LOWLEVEL_INIT)
>>
>>  .globl lowlevel_init
>>  lowlevel_init:
>> @@ -39,5 +39,5 @@ lowlevel_init:
>> mov pc, lr
>>
>> .ltorg
>> -
>> -#endif /* CONFIG_SKIP_LOWLEVEL_INIT */
>> +
>> +#endif /* !CONFIG_SKIP_LOWLEVEL_INIT && !CONFIG_USER_LOWLEVEL_INIT */
>> 
>
> Maybe instead of adding mor #ifdef'ery here, we can turn
> lowlevel_init() into a "weak" function that can be redefined by board
> specific code?
The lowlevel_init() is an assembler function called from another 
assembler function and the attribute .weak doesn't work.
There are no assembler file in the U-BOOT tree which use weak functions.
Do you know how can I make an assembler function weak?

best regards,
Ilko Iilev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Hangs at relocation on 460EX Target

[Stefan Roese]

On Tuesday 21 October 2008, Ayman M. El-Khashab wrote:
> We've got our custom hardware in and are having trouble getting
> u-boot to start up.  We've modeled our board close to the canyonlands.
> The main differences are no sensors, DIMM at 0x51, and a 16Mb NOR
> flash instead of 64Mb.  We boot and get messages and we've determined
> it is stuck inside the relocation or immediately after it branches
> to the code in RAM.

I suggest that you enable DEBUG in lib_ppc/board.c (define DEBUG before the 
#includes). This will show you a little more.

But you may be correct that U-Boot hangs/crashes upon relocation. This is most 
likely a problem with the DDR2 configuration. You might have noticed the 
latest autocalibration changes for the 4xx DDR2 controller. It's worth to 
give these new methods a try.

> My first thought is that we need to make several changes to handle
> the 16Mb flash since there was some code to handle the movement of
> the 64Mb flash in early_init_r.  It seems for us that is not needed.
>
> Secondly, there might be some changes needed to the EBC Setup in
> the config file.  However I've compared those to the data sheet
> and not seeing anything obvious.  I have disabled early_init_r and
> made the following changes to the configuration
>
> #define CFG_FLASH_BASE  0xFF00   * later mapped to this addr   
> */
>
> #define CFG_FLASH_BASE_PHYS_H   0x0
> #define CFG_FLASH_BASE_PHYS_L   0xFF00
> #define CFG_FLASH_BASE_PHYS (((u64)CFG_FLASH_BASE_PHYS_H << 32) | \
>  (u64)CFG_FLASH_BASE_PHYS_L)
>
> #define CFG_FLASH_SIZE  (16 << 20)
>
>
> Any tips to what else I might be missing?  I don't recall having
> this much difficulty last time u-boot was ported to our boards.

On the 460EX/GT is especially hard to handle bigger boot FLASH sizes because 
of it's restricted boot map size.

But this is most likely not your problem. I'm pretty sure that you are 
experiencing SDRAM problem.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc4xx: New board avnet fx12 minimodule

[Stefan Roese]

On Thursday 16 October 2008, Georg Schardt wrote:
> From: schardt <[EMAIL PROTECTED]>
>
> this patch adds support for the avnet fx12 minimodul
> it needs the "ppc4xx: Generic architecture for xilinx ppc405" patch from
> Ricardo

I just merged u-boot/master into u-boot-ppc4xx/master and pushed it to 
git.denx.de. Please rebase your patch against this repo and resubmit.

Thanks.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc4xx: Generic architecture for xilinx ppc405 (v2)

[Stefan Roese]

On Thursday 16 October 2008, Ricardo Ribalda Delgado wrote:
> As "ppc44x: Unification of virtex5 pp440 boards" did for the xilinx
> ppc440 boards, this patch presents a common architecture for all the
> xilinx ppc405 boards.
>
> Any custom xilinx ppc405 board can be added very easily with no code
> duplicity.
>
> This patch also adds a simple generic board, that can be used on almost
> any design with xilinx ppc405 replacing the file
> ppc405-generic/xparameters.h
>
> This patch is prepared to work with the latest version of EDK (10.1)
>
> Signed-off-by: Ricardo Ribalda Delgado <[EMAIL PROTECTED]>

I just merged u-boot/master into u-boot-ppc4xx/master and pushed it to 
git.denx.de. Please rebase your patch against this repo and resubmit.

Thanks.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git

[Stefan Roese]

The following changes since commit f61f1e150c84f5b9347fca79a4bc5f2286c545d2:
  Stefan Roese (1):
Merge branch 'master' of /home/stefan/git/u-boot/u-boot

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Adam Graham (3):
  ppc4xx: Add AMCC Arches board support (dual 460GT)
  ppc4xx: Add static support for 44x IBM SDRAM Controller
  ppc4xx: Add routine to retrieve CPU number

Dirk Eibach (1):
  ppc4xx: Add GDSys neo 405EP board support

Niklaus Giger (1):
  ppc4xx: Update configs for Netstal boards

Stefan Roese (2):
  ppc4xx: Correctly setup ranges property in ebc node
  ppc4xx: Add 1.0 & 1.066 GHz to canyonlands bootstrap command for PLL setup

 MAINTAINERS  |4 +
 MAKEALL  |2 +
 Makefile |6 +-
 board/amcc/canyonlands/bootstrap.c   |   12 ++
 board/amcc/canyonlands/canyonlands.c |  140 +++
 board/amcc/canyonlands/init.S|   17 +++
 board/gdsys/neo/Makefile |   51 +++
 board/gdsys/neo/config.mk|   24 +++
 board/gdsys/neo/neo.c|  101 +
 board/gdsys/neo/u-boot.lds   |  132 ++
 cpu/ppc4xx/44x_spd_ddr2.c|   71 +++---
 cpu/ppc4xx/cpu.c |   19 +++-
 cpu/ppc4xx/fdt.c |   45 ---
 include/asm-ppc/ppc4xx-ebc.h |   31 
 include/configs/amcc-common.h|   17 ++-
 include/configs/canyonlands.h|  222 +++---
 include/configs/hcu4.h   |  100 ++
 include/configs/hcu5.h   |  118 ++--
 include/configs/mcu25.h  |   94 ++---
 include/configs/neo.h|  231 ++
 include/configs/netstal-common.h |  255 ++
 include/ppc440.h |3 +
 include/ppc4xx.h |3 +
 23 files changed, 1368 insertions(+), 330 deletions(-)
 create mode 100644 board/gdsys/neo/Makefile
 create mode 100644 board/gdsys/neo/config.mk
 create mode 100644 board/gdsys/neo/neo.c
 create mode 100644 board/gdsys/neo/u-boot.lds
 create mode 100644 include/configs/neo.h
 create mode 100644 include/configs/netstal-common.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Hangs at relocation on 460EX Target

[Ayman M. El-Khashab]

Hello,

We've got our custom hardware in and are having trouble getting
u-boot to start up.  We've modeled our board close to the canyonlands.
The main differences are no sensors, DIMM at 0x51, and a 16Mb NOR
flash instead of 64Mb.  We boot and get messages and we've determined
it is stuck inside the relocation or immediately after it branches
to the code in RAM.  

My first thought is that we need to make several changes to handle
the 16Mb flash since there was some code to handle the movement of
the 64Mb flash in early_init_r.  It seems for us that is not needed.

Secondly, there might be some changes needed to the EBC Setup in
the config file.  However I've compared those to the data sheet
and not seeing anything obvious.  I have disabled early_init_r and
made the following changes to the configuration

#define CFG_FLASH_BASE  0xFF00   * later mapped to this addr*/

#define CFG_FLASH_BASE_PHYS_H   0x0
#define CFG_FLASH_BASE_PHYS_L   0xFF00
#define CFG_FLASH_BASE_PHYS (((u64)CFG_FLASH_BASE_PHYS_H << 32) | \
 (u64)CFG_FLASH_BASE_PHYS_L)

#define CFG_FLASH_SIZE  (16 << 20)


Any tips to what else I might be missing?  I don't recall having
this much difficulty last time u-boot was ported to our boards.

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

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Kumar Gala]

On Oct 21, 2008, at 10:06 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message  [EMAIL PROTECTED]> you wrote:
>>
>> If this is desired to be configurable should I introduce a  
>> pci_addr_t/
>> pci_size_t?  Coupling to phys_addr_t/phys_size_t doesn't make sense  
>> to
>> me because its perfectly reasonable to have a 64-bit PCI device work
>> in a 32-bit system.
>
> I  think  using  pci_addr_t/pci_size_t   is   the   most   reasonable
> suggestion, then (but it may turn into fighting a lot of new warnings
> about incompatible types for one board or another).

Ok, I'll switch over to these types and post a new patch.

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

Re: [U-Boot] [PATCH] ppc4xx: Merge Netstal board ports: CFG_ -> CONFIG_SYS_

[Stefan Roese]

On Tuesday 21 October 2008, Wolfgang Denk wrote:
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > ---
> >  include/configs/netstal-common.h |   76
> > +++--- 1 files changed, 38 insertions(+),
> > 38 deletions(-)
>
> Oops? We don't have any such file in the tree.

Those are against my next branch.

But I'm currently squashing those patches with the merge commit, so they won't 
be needed anymore.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Hi Wolfgang,

> Note that I'm not against this in principle. But if it gets changed,
> then not only for a single architecture, but everywhere.
> 
> > Cost: $0.00.  Benefit: $0.02.  Benefit/Cost = priceless.
> 
> Cost: work to implement, review and test.  Benefit: $0.02.
> Benefit/Cost = small ;-)

This PATCH/RFC was only meant as a quick example per the original email
comments.  It sounds like the patch would be worthwhile (let me know if
I'm mistaken) so I'll go ahead and create a proper patch updating
__TIME__/__DATE__ where relevant.

Thanks,
Peter

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

Re: [U-Boot] [PATCH] ppc4xx: Merge Neo board port: CFG_ -> CONFIG_SYS_

[Wolfgang Denk]

Dear Stefan Roese,

In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
>  include/configs/neo.h |   86 
>  1 files changed, 43 insertions(+), 43 deletions(-)

Oops?  We don't have any such file in the tree.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Yes, it's a technical challenge, and  you  have  to  kind  of  admire
people  who go to the lengths of actually implementing it, but at the
same time you wonder about their IQ...
 --  Linus Torvalds in <[EMAIL PROTECTED]>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc4xx: Merge Netstal board ports: CFG_ -> CONFIG_SYS_

[Wolfgang Denk]

Dear Stefan Roese,

In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
>  include/configs/netstal-common.h |   76 
> +++---
>  1 files changed, 38 insertions(+), 38 deletions(-)

Oops? We don't have any such file in the tree.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).   - Bill Joy 6/21/85
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> 
> If this is desired to be configurable should I introduce a pci_addr_t/ 
> pci_size_t?  Coupling to phys_addr_t/phys_size_t doesn't make sense to  
> me because its perfectly reasonable to have a 64-bit PCI device work  
> in a 32-bit system.

I  think  using  pci_addr_t/pci_size_t   is   the   most   reasonable
suggestion, then (but it may turn into fighting a lot of new warnings
about incompatible types for one board or another).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Am I your nanny? The kernel is there to support  user  programs,  but
it's a _resource_ handler, not a baby feeder. - Linus Torvalds in
  <[EMAIL PROTECTED]>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's bu ild timestamp on every compile

[Wolfgang Denk]

Dear Stefan Roese,

In message <[EMAIL PROTECTED]> you wrote:
>
> > I know this patch isn't a big deal, but I think it would be a valuable
> > change.  If others don't agree I'll drop the issue.
> 
> As mentioned above, I think your patch is an improvement. So why not accept 
> it?

Because it changes one place and leaves 43 other, identical places
unchanged.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
It is better to marry than to burn.
- Bible ``I Corinthians'' ch. 7, v. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <[EMAIL PROTECTED]> you wrote:
>
> > Should we not enable this only for such systems that actually need it?
...
> Why would we not use phys_addr_t and phys_size_t for the PCI addresses?

Good point.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.   -- Chinese proverb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <[EMAIL PROTECTED]> you wrote:
>
> > I know this patch isn't a big deal, but I think it would be a valuable
> > change.  If others don't agree I'll drop the issue.
...
> +1
> Call me old fashioned, but I like time/date stamps.  They are more 
> meaningful to me as a quick "did I really load a new u-boot" or "when 
> did I do *that*" than a git hash.

Note that I'm not against this in principle. But if it gets changed,
then not only for a single architecture, but everywhere.

> Cost: $0.00.  Benefit: $0.02.  Benefit/Cost = priceless.

Cost: work to implement, review and test.  Benefit: $0.02.
Benefit/Cost = small ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
"The whole world is about three drinks behind." - Humphrey Bogart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ppc4xx: Merge Neo board port: CFG_ -> CONFIG_SYS_

[Stefan Roese]

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 include/configs/neo.h |   86 
 1 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/include/configs/neo.h b/include/configs/neo.h
index a150cdd..f275c7b 100644
--- a/include/configs/neo.h
+++ b/include/configs/neo.h
@@ -83,34 +83,34 @@
 #define CONFIG_SDRAM_BANK0 1   /* init onboard SDRAM bank 0 */
 
 /* SDRAM timings used in datasheet */
-#define CFG_SDRAM_CL3  /* CAS latency */
-#define CFG_SDRAM_tRP   20 /* PRECHARGE command period */
-#define CFG_SDRAM_tRC   66 /* ACTIVE-to-ACTIVE command period */
-#define CFG_SDRAM_tRCD  20 /* ACTIVE-to-READ delay */
-#define CFG_SDRAM_tRFC 66  /* Auto refresh period */
+#define CONFIG_SYS_SDRAM_CL3   /* CAS latency */
+#define CONFIG_SYS_SDRAM_tRP   20  /* PRECHARGE command period */
+#define CONFIG_SYS_SDRAM_tRC   66  /* ACTIVE-to-ACTIVE command 
period */
+#define CONFIG_SYS_SDRAM_tRCD  20  /* ACTIVE-to-READ delay */
+#define CONFIG_SYS_SDRAM_tRFC  66  /* Auto refresh period */
 
 /*
- * If CFG_EXT_SERIAL_CLOCK, then the UART divisor is 1.
- * If CFG_405_UART_ERRATA_59, then UART divisor is 31.
- * Otherwise, UART divisor is determined by CPU Clock and CFG_BASE_BAUD value.
+ * If CONFIG_SYS_EXT_SERIAL_CLOCK, then the UART divisor is 1.
+ * If CONFIG_SYS_405_UART_ERRATA_59, then UART divisor is 31.
+ * Otherwise, UART divisor is determined by CPU Clock and CONFIG_SYS_BASE_BAUD 
value.
  * The Linux BASE_BAUD define should match this configuration.
  *baseBaud = cpuClock/(uartDivisor*16)
- * If CFG_405_UART_ERRATA_59 and 200MHz CPU clock,
+ * If CONFIG_SYS_405_UART_ERRATA_59 and 200MHz CPU clock,
  * set Linux BASE_BAUD to 403200.
  */
 #undef CONFIG_SERIAL_SOFTWARE_FIFO
-#undef  CFG_EXT_SERIAL_CLOCK   /* external serial clock */
-#undef  CFG_405_UART_ERRATA_59 /* 405GP/CR Rev. D silicon */
-#define CFG_BASE_BAUD  691200
+#undef  CONFIG_SYS_EXT_SERIAL_CLOCK   /* external serial clock */
+#undef  CONFIG_SYS_405_UART_ERRATA_59 /* 405GP/CR Rev. D silicon */
+#define CONFIG_SYS_BASE_BAUD   691200
 
 /*
  * I2C stuff
  */
-#define CFG_I2C_SPEED  10  /* I2C speed and slave address  */
+#define CONFIG_SYS_I2C_SPEED   10  /* I2C speed and slave address  
*/
 
 /* RTC */
 #define CONFIG_RTC_DS1337
-#define CFG_I2C_RTC_ADDR   0x68
+#define CONFIG_SYS_I2C_RTC_ADDR0x68
 
 /* Temp sensor/hwmon/dtt */
 #define CONFIG_DTT_LM631   /* National LM63*/
@@ -122,27 +122,27 @@
 /*
  * FLASH organization
  */
-#define CFG_FLASH_CFI  /* The flash is CFI compatible  
*/
+#define CONFIG_SYS_FLASH_CFI   /* The flash is CFI 
compatible  */
 #define CONFIG_FLASH_CFI_DRIVER/* Use common CFI 
driver*/
 
-#define CFG_FLASH_BASE 0xFC00
-#define CFG_FLASH_BANKS_LIST   { CFG_FLASH_BASE }
+#define CONFIG_SYS_FLASH_BASE  0xFC00
+#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH_BASE }
 
-#define CFG_MAX_FLASH_BANKS1   /* max number of memory banks   
*/
-#define CFG_MAX_FLASH_SECT 512 /* max number of sectors on one chip
*/
+#define CONFIG_SYS_MAX_FLASH_BANKS 1   /* max number of memory banks   
*/
+#define CONFIG_SYS_MAX_FLASH_SECT  512 /* max number of sectors on one 
chip*/
 
-#define CFG_FLASH_ERASE_TOUT   12  /* Timeout for Flash Erase (in ms)  
*/
-#define CFG_FLASH_WRITE_TOUT   500 /* Timeout for Flash Write (in ms)  
*/
+#define CONFIG_SYS_FLASH_ERASE_TOUT12  /* Timeout for Flash Erase (in 
ms)  */
+#define CONFIG_SYS_FLASH_WRITE_TOUT500 /* Timeout for Flash Write (in 
ms)  */
 
-#define CFG_FLASH_USE_BUFFER_WRITE 1   /* use buffered writes (20x faster) 
*/
-#define CFG_FLASH_PROTECTION   1   /* use hardware flash protection
*/
+#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE 1/* use buffered writes (20x 
faster) */
+#define CONFIG_SYS_FLASH_PROTECTION1   /* use hardware flash 
protection*/
 
-#define CFG_FLASH_EMPTY_INFO   /* print 'E' for empty sector on flinfo 
*/
-#define CFG_FLASH_QUIET_TEST   1   /* don't warn upon unknown flash
*/
+#define CONFIG_SYS_FLASH_EMPTY_INFO/* print 'E' for empty sector 
on flinfo */
+#define CONFIG_SYS_FLASH_QUIET_TEST1   /* don't warn upon unknown 
flash*/
 
 #ifdef CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_ENV_SECT_SIZE   0x2 /* size of one complete sector  
*/
-#define CONFIG_ENV_ADDR
((-CFG_MONITOR_LEN)-CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_ADDR
((-CONFIG_SYS_MONITOR_LEN)-CONFIG_ENV_SECT_SIZE)
 #defineCONFIG_ENV_SIZE 0x2000  /* Total Size of Environment 

[U-Boot] [PATCH] ppc4xx: Merge Netstal board ports: CFG_ -> CONFIG_SYS_

[Stefan Roese]

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 include/configs/netstal-common.h |   76 +++---
 1 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/include/configs/netstal-common.h b/include/configs/netstal-common.h
index 59777e4..1fa4b00 100644
--- a/include/configs/netstal-common.h
+++ b/include/configs/netstal-common.h
@@ -26,34 +26,34 @@
 #ifndef __NETSTAL_COMMON_H
 #define __NETSTAL_COMMON_H
 
-#define CFG_SDRAM_BASE 0x  /* _must_ be 0  */
-#define CFG_MONITOR_BASE   TEXT_BASE   /* Start of U-Boot  */
-#define CFG_MONITOR_LEN(320 * 1024)/* Reserve 320 kB for 
Monitor   */
-#define CFG_MALLOC_LEN (256 * 1024)/* Reserve 256 kB for malloc() 
*/
+#define CONFIG_SYS_SDRAM_BASE  0x  /* _must_ be 0  
*/
+#define CONFIG_SYS_MONITOR_BASETEXT_BASE   /* Start of U-Boot  
*/
+#define CONFIG_SYS_MONITOR_LEN (320 * 1024)/* Reserve 320 kB for 
Monitor   */
+#define CONFIG_SYS_MALLOC_LEN  (256 * 1024)/* Reserve 256 kB for 
malloc() */
 
 /*
  * UART
  */
 #define CONFIG_SERIAL_MULTI
-#define CFG_BAUDRATE_TABLE  \
+#define CONFIG_SYS_BAUDRATE_TABLE  \
 {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
 
 /*
  * I2C
  */
 #define CONFIG_HARD_I2C1   /* I2C with hardware support */
-#define CFG_I2C_SPEED  40  /* I2C speed and slave address  */
-#define CFG_I2C_SLAVE  0x7F
+#define CONFIG_SYS_I2C_SPEED   40  /* I2C speed and slave address  
*/
+#define CONFIG_SYS_I2C_SLAVE   0x7F
 
 /* This is the 7bit address of the device, not including P. */
-#define CFG_I2C_EEPROM_ADDR 0x50
-#define CFG_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
 
 /* The EEPROM can do 16byte ( 1 << 4 ) page writes. */
-#define CFG_I2C_EEPROM_ADDR_OVERFLOW   0x07
-#define CFG_EEPROM_PAGE_WRITE_BITS 4
-#define CFG_EEPROM_PAGE_WRITE_DELAY_MS 10
-#define CFG_EEPROM_PAGE_WRITE_ENABLE
+#define CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW0x07
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 4
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 10
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_ENABLE
 
 /*
  * Ethernet/EMAC/PHY
@@ -63,9 +63,9 @@
 #if defined(CONFIG_440)
 #define CONFIG_NET_MULTI   1
 #define CONFIG_NETCONSOLE  /* include NetConsole support   */
-#define CFG_RX_ETH_BUFFER  32  /* number of eth rx buffers */
+#define CONFIG_SYS_RX_ETH_BUFFER   32  /* number of eth rx buffers 
*/
 #else
-#define CFG_RX_ETH_BUFFER  16  /* number of eth rx buffers */
+#define CONFIG_SYS_RX_ETH_BUFFER   16  /* number of eth rx buffers 
*/
 #endif
 #define CONFIG_HAS_ETH0
 
@@ -95,24 +95,24 @@
  * Miscellaneous configurable options
  */
 #define CONFIG_BOOTDELAY   1   /* autoboot after 1 second  */
-#define CFG_LONGHELP   /* undef to save memory */
-#define CFG_PROMPT "=> "   /* Monitor Command Prompt   */
+#define CONFIG_SYS_LONGHELP/* undef to save memory 
*/
+#define CONFIG_SYS_PROMPT  "=> "   /* Monitor Command Prompt   
*/
 #if defined(CONFIG_CMD_KGDB)
-#define CFG_CBSIZE 1024/* Console I/O Buffer Size  */
+#define CONFIG_SYS_CBSIZE  1024/* Console I/O Buffer Size  
*/
 #else
-#define CFG_CBSIZE 256 /* Console I/O Buffer Size  */
+#define CONFIG_SYS_CBSIZE  256 /* Console I/O Buffer Size  
*/
 #endif
-#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)
-#define CFG_MAXARGS16  /* max number of command args   */
-#define CFG_BARGSIZE   CFG_CBSIZE /* Boot Argument Buffer Size */
+#define CONFIG_SYS_PBSIZE  
(CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16)
+#define CONFIG_SYS_MAXARGS 16  /* max number of command args   
*/
+#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot Argument 
Buffer Size  */
 
-#define CFG_MEMTEST_START  0x040 /* memtest works on   */
-#define CFG_MEMTEST_END0x0C0 /* 4 ... 12 MB in DRAM
*/
+#define CONFIG_SYS_MEMTEST_START   0x040 /* memtest works on   
*/
+#define CONFIG_SYS_MEMTEST_END 0x0C0 /* 4 ... 12 MB in DRAM
*/
 
-#define CFG_LOAD_ADDR  0x10  /* default load address   */
-#define CFG_EXTBDINFO  /* To use extended board_into (bd_t) */
+#define CONFIG_SYS_LOAD_ADDR   0x10  /* default load address   
*/
+#define CONFIG_SYS_EXTBDINFO   /* To use extended board_into 
(bd_t) */
 
-#define CFG_HZ 1000/* decrementer freq: 1 ms ticks */
+#define CONFIG_SYS_HZ  1000/* decrementer freq: 1 ms ticks 
*/
 
 #define CONFIG_CMDLINE_EDITING   

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Kumar Gala]

On Oct 21, 2008, at 9:46 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <1224598531-2698-1-git-send-email- 
> [EMAIL PROTECTED]> you wrote:
>> PCI bus is inherently 64-bit.  We should treat all PCI related bus
>> addresses as 64-bit quanities.  This allows us to have the ability
>> to support devices or memory on the PCI bus above the 32-bit  
>> boundary.
>
> I don't think this is a good idea. There are pure 32 bit systems  out
> there which will never use more than 32 bit for the PCI resources, so
> why load them with the additional memory size and execution time?
>
> Should we not enable this only for such systems that actually need it?

We could, however it seems the impact is pretty small on those systems  
with pure 32-bit PCI.  I think the different in testing etc may not be  
worth it:

text   data bss dec hex filename
  350588  44964   41909  437461   6acd5 u-boot (32-bit pci structs)
  351100  44964   42349  438413   6b08d u-boot (64-bit pci structs)
--
 512   0 440 952 3b8

If this is desired to be configurable should I introduce a pci_addr_t/ 
pci_size_t?  Coupling to phys_addr_t/phys_size_t doesn't make sense to  
me because its perfectly reasonable to have a 64-bit PCI device work  
in a 32-bit system.

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

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Kumar Gala]

On Oct 21, 2008, at 9:55 AM, Jerry Van Baren wrote:

> Wolfgang Denk wrote:
>> Dear Kumar Gala,
>> In message <[EMAIL PROTECTED] 
>> > you wrote:
>>> PCI bus is inherently 64-bit.  We should treat all PCI related bus
>>> addresses as 64-bit quanities.  This allows us to have the ability
>>> to support devices or memory on the PCI bus above the 32-bit  
>>> boundary.
>> I don't think this is a good idea. There are pure 32 bit systems  out
>> there which will never use more than 32 bit for the PCI resources, so
>> why load them with the additional memory size and execution time?
>> Should we not enable this only for such systems that actually need  
>> it?
>> Best regards,
>> Wolfgang Denk
>
> Why would we not use phys_addr_t and phys_size_t for the PCI  
> addresses?

Because they aren't coupled.  I can reasonable want 64-bit PCI  
accessible on a pure 32-bit system.

If we want to do this we should introduce a pci_addr_t/pci_size_t.

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

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Wolfgang Denk]

Dear Peter Tyser,

In message <[EMAIL PROTECTED]> you wrote:
> 
> > Actually the time stamp is completely useless in determining  if  the
> > code is the same or different. I can compile the same code many times
> > resulting  in  different time stamps and yet it's the very same code.
> 
> The code won't be the same - the version string will be different and
> the different binaries would have different md5sums.

The *code* will be exactly the same. The binary images may differ in
some strings, but the code is still the same.

But actually you just confirmed my argumnt.

> > U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
> > 
> > This clearly tells you which version the code was based on (and  that
> > it contains local modifications that were not yet checked in).
> 
> Which local modifications though?  Until I make another commit every
> version string will be the same.

Indeed. Which tells you that it is a bad idea to ship any binaries
with uncommitted modifications in your tree.

Hey, we can only provide the best environment for a sane  development
process. If you don't play by the rules you are then not exactly in a
good  position  to complain. Talk to your QA manager, if you doubt my
words ;-)

> > Timestamps are not suitable to provide this type of  information.  If
> > you care about which code you are running, than make sure to use git.
> 
> I do, but the minor annoyance of having the exact same version
> string/time stamp for different code still exists for uncommited
> changes.

You must be doing something awfully wrong when  you  have  uncommited
changes in any form of software you're releasing.

> I use git, but its version strings only change when commits occur.  I

Thisis intentional - commits are the only way  to  change  the  code.
Anything  between  commits is work in progress which you never should
release to anybody, not even your bst friends.

> I know this patch isn't a big deal, but I think it would be a valuable
> change.  If others don't agree I'll drop the issue.

We take great care to generate a useful version ID string that really
gets updated as soon as one of the files changes. The fact that we
apend the __DATE__ and  __TIME__ output to the boot messages is just
for informational purposes (and a relict from earlier times, when git
did not exist yet).1s

Note that there are more than 40 places in the  code  where  __DATE__
and/or __TIME__ get used, in different ways. If you want to put more
meaning into these strings than we have now, you will have to address
all these use cases.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Being schizophrenic is better than living alone.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's bu ild timestamp on every compile

[Stefan Roese]

On Tuesday 21 October 2008, Peter Tyser wrote:
> > Why would that be confusing? It seems natural to me that time changes
> > when  you  do  several  things  sequentially.   If   a   board   used
> > __TIME__/__DATE__   in   more  than  one  location,  then  the  board
> > maintainer either did this intentionally (and thus wants to  acchieve
> > this  result),  or  he  did  it without thinking, in which case it is
> > obviously not an important issue to him).
>
> I agree that its not an important issue, but that's not to say it
> hasn't/won't confused customers/developers.  eg the first time I noticed
> it, it fooled me into thinking my flash wasn't properly programmed after
> updating u-boot.

Happend to me a few times as well. So I like your patch.

> > > the build time were printed in common/lcd.c, it would not be identical
> > > to the time printed on the serial port since lcd.c was not compiled at
> > > the same time as cpu/mpc8xx/start.S.
> >
> > If you care about reliable version information, use the git based ID
> > strings.
>
> I use git, but its version strings only change when commits occur.  I
> think having an accurate build time stamp would be a nice feature.
> FWIW, Linux handles this "issue" very similarly to my proposed solution
> so that it can have its pretty banner.  It even takes it a step further
> and gives a specific compile number (#15):
>
> Linux version 2.6.23.17 ([EMAIL PROTECTED]) (gcc version 4.3.1
> (crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008
>
>
> I know this patch isn't a big deal, but I think it would be a valuable
> change.  If others don't agree I'll drop the issue.

As mentioned above, I think your patch is an improvement. So why not accept 
it?

Acked-by: Stefan Roese <[EMAIL PROTECTED]>

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <[EMAIL PROTECTED]> you wrote:
>> PCI bus is inherently 64-bit.  We should treat all PCI related bus
>> addresses as 64-bit quanities.  This allows us to have the ability
>> to support devices or memory on the PCI bus above the 32-bit boundary.
> 
> I don't think this is a good idea. There are pure 32 bit systems  out
> there which will never use more than 32 bit for the PCI resources, so
> why load them with the additional memory size and execution time?
> 
> Should we not enable this only for such systems that actually need it?
> 
> Best regards,
> 
> Wolfgang Denk

Why would we not use phys_addr_t and phys_size_t for the PCI addresses?

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

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Jerry Van Baren]

Peter Tyser wrote:
> Hi Wolfgang,

[big snip]

> I use git, but its version strings only change when commits occur.  I
> think having an accurate build time stamp would be a nice feature.
> FWIW, Linux handles this "issue" very similarly to my proposed solution
> so that it can have its pretty banner.  It even takes it a step further
> and gives a specific compile number (#15):
> 
> Linux version 2.6.23.17 ([EMAIL PROTECTED]) (gcc version 4.3.1
> (crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008
> 
> 
> I know this patch isn't a big deal, but I think it would be a valuable
> change.  If others don't agree I'll drop the issue.
> 
> Thanks,
> Peter

+1
Call me old fashioned, but I like time/date stamps.  They are more 
meaningful to me as a quick "did I really load a new u-boot" or "when 
did I do *that*" than a git hash.

Cost: $0.00.  Benefit: $0.02.  Benefit/Cost = priceless.

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

Re: [U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Wolfgang Denk]

Dear Kumar Gala,

In message <[EMAIL PROTECTED]> you wrote:
> PCI bus is inherently 64-bit.  We should treat all PCI related bus
> addresses as 64-bit quanities.  This allows us to have the ability
> to support devices or memory on the PCI bus above the 32-bit boundary.

I don't think this is a good idea. There are pure 32 bit systems  out
there which will never use more than 32 bit for the PCI resources, so
why load them with the additional memory size and execution time?

Should we not enable this only for such systems that actually need it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Keep your eyes wide open before marriage, half shut afterwards.
 -- Benjamin Franklin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile

[Peter Tyser]

Hi Wolfgang,

> > __TIME__ and __DATE__ aren't ideal as they are only updated when the
> > file that contains them is recompiled.  For example, during the normal
> > modify/build/test cycle the version string remains the same for an 85xx
> > board as start.S would not be recompiled.  So any number of U-Boot
> > compilations can contain different code, but have the same build
> > time/version string.  eg when a board boots up and spits out:
> 
> Actually the time stamp is completely useless in determining  if  the
> code is the same or different. I can compile the same code many times
> resulting  in  different time stamps and yet it's the very same code.

The code won't be the same - the version string will be different and
the different binaries would have different md5sums.

> 
> > U-Boot 1.3.4 (Aug  7 2008 - 12:32:20)
> ...
> > the code really may not have been compiled on Aug 7th, it could have
> > been compiled today, yesterday, etc.
> 
> Who cares when it was really built? If you are working in the
> recommended environment (i. e. using git) then you can be sure that
> this was the code of the v1.3.4 release; otherwise you would have seen
> something as
> 
> U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
> 
> This clearly tells you which version the code was based on (and  that
> it contains local modifications that were not yet checked in).

Which local modifications though?  Until I make another commit every
version string will be the same.

> > It would be nice in my mind if every compile of U-Boot resulted in a new
> > build time string.  Thus you could easily determine which version is
> > programmed on a board during bootup, by looking at a binary on your host
> 
> Timestamps are not suitable to provide this type of  information.  If
> you care about which code you are running, than make sure to use git.

I do, but the minor annoyance of having the exact same version
string/time stamp for different code still exists for uncommited
changes.

> > Also, if a board used __TIME__/__DATE__ in more than one location, it
> > could be confusing as the times wouldn't be identical.  For example, if
> 
> Why would that be confusing? It seems natural to me that time changes
> when  you  do  several  things  sequentially.   If   a   board   used
> __TIME__/__DATE__   in   more  than  one  location,  then  the  board
> maintainer either did this intentionally (and thus wants to  acchieve
> this  result),  or  he  did  it without thinking, in which case it is
> obviously not an important issue to him).

I agree that its not an important issue, but that's not to say it
hasn't/won't confused customers/developers.  eg the first time I noticed
it, it fooled me into thinking my flash wasn't properly programmed after
updating u-boot.

> > the build time were printed in common/lcd.c, it would not be identical
> > to the time printed on the serial port since lcd.c was not compiled at
> > the same time as cpu/mpc8xx/start.S.
> 
> If you care about reliable version information, use the git based ID
> strings.

I use git, but its version strings only change when commits occur.  I
think having an accurate build time stamp would be a nice feature.
FWIW, Linux handles this "issue" very similarly to my proposed solution
so that it can have its pretty banner.  It even takes it a step further
and gives a specific compile number (#15):

Linux version 2.6.23.17 ([EMAIL PROTECTED]) (gcc version 4.3.1
(crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008


I know this patch isn't a big deal, but I think it would be a valuable
change.  If others don't agree I'll drop the issue.

Thanks,
Peter

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

[U-Boot] [PATCH] pci: Treat all PCI bus addresses as 64-bit

[Kumar Gala]

PCI bus is inherently 64-bit.  We should treat all PCI related bus
addresses as 64-bit quanities.  This allows us to have the ability
to support devices or memory on the PCI bus above the 32-bit boundary.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 drivers/pci/pci.c  |4 ++--
 drivers/pci/pci_auto.c |   10 +-
 include/pci.h  |   16 
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 41780db..253e1f5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -223,7 +223,7 @@ unsigned long pci_hose_phys_to_bus (struct pci_controller 
*hose,
unsigned long flags)
 {
struct pci_region *res;
-   unsigned long bus_addr;
+   u64 bus_addr;
int i;
 
if (!hose) {
@@ -252,7 +252,7 @@ Done:
 }
 
 phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-unsigned long bus_addr,
+u64 bus_addr,
 unsigned long flags)
 {
struct pci_region *res;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 3844359..ea362a9 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -52,7 +52,7 @@ void pciauto_region_align(struct pci_region *res, unsigned 
long size)
 
 int pciauto_region_allocate(struct pci_region* res, unsigned int size, 
unsigned int *bar)
 {
-   unsigned long addr;
+   u64 addr;
 
if (!res) {
DEBUGF("No resource");
@@ -68,7 +68,7 @@ int pciauto_region_allocate(struct pci_region* res, unsigned 
int size, unsigned
 
res->bus_lower = addr + size;
 
-   DEBUGF("address=0x%lx bus_lower=%x", addr, res->bus_lower);
+   DEBUGF("address=0x%llx bus_lower=%llx", addr, res->bus_lower);
 
*bar = addr;
return 0;
@@ -289,7 +289,7 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_mem) {
pciauto_region_init(hose->pci_mem);
 
-   DEBUGF("PCI Autoconfig: Bus Memory region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Memory region: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
hose->pci_mem->bus_start,
hose->pci_mem->bus_start + hose->pci_mem->size - 1,
@@ -300,7 +300,7 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_prefetch) {
pciauto_region_init(hose->pci_prefetch);
 
-   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%llx-%llx],\n"
   "\t\tPhysical Memory [%x-%x]\n",
hose->pci_prefetch->bus_start,
hose->pci_prefetch->bus_start + hose->pci_prefetch->size - 
1,
@@ -312,7 +312,7 @@ void pciauto_config_init(struct pci_controller *hose)
if (hose->pci_io) {
pciauto_region_init(hose->pci_io);
 
-   DEBUGF("PCI Autoconfig: Bus I/O region: [%lx-%lx],\n"
+   DEBUGF("PCI Autoconfig: Bus I/O region: [%llx-%llx],\n"
   "\t\tPhysical Memory: [%x-%x]\n",
hose->pci_io->bus_start,
hose->pci_io->bus_start + hose->pci_io->size - 1,
diff --git a/include/pci.h b/include/pci.h
index 1c8e216..2689640 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -313,12 +313,12 @@
 #include 
 
 struct pci_region {
-   unsigned long bus_start;/* Start on the bus */
-   phys_addr_t phys_start; /* Start in physical address 
space */
-   unsigned long size; /* Size */
-   unsigned long flags;/* Resource flags */
+   u64 bus_start;  /* Start on the bus */
+   phys_addr_t phys_start; /* Start in physical address space */
+   u64 size;   /* Size */
+   unsigned long flags;/* Resource flags */
 
-   unsigned long bus_lower;
+   u64 bus_lower;
 };
 
 #define PCI_REGION_MEM 0x  /* PCI memory space */
@@ -330,9 +330,9 @@ struct pci_region {
 #define PCI_REGION_RO  0x0200  /* Read-only memory */
 
 extern __inline__ void pci_set_region(struct pci_region *reg,
- unsigned long bus_start,
+ u64 bus_start,
  phys_addr_t phys_start,
- unsigned long size,
+ u64 size,
  unsigned long flags) {
reg->bus_start  = bus_start;
reg->phys_start = phys_start;
@@ -433,7 +433,7 @@ extern __inline__ void pci_set_ops(struct pci_controller 
*hose,
 extern void pci_setup_indirect(struct pci_controller* hose, u32 cfg_addr, u32 
cfg_data);
 
 extern phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-

Re: [U-Boot] [PATCH] improved strmhz()

[Ilko Iliev]

Wolfgang Denk wrote:
> Dear Ilko Iliev,
>
> In message <[EMAIL PROTECTED]> you wrote:
>   
>> This patch prevents the displaying of results like this:
>> hz = 199917
>> buf = "200.-83"
>> 
>
> I think you got one '0' too many in your example - the example would
> just print "1999.170" which is correct.
>
>   
>> --- a/lib_generic/strmhz.c
>> +++ b/lib_generic/strmhz.c
>> @@ -28,10 +28,15 @@ char *strmhz (char *buf, long hz)
>> long m;
>>
>> n = DIV_ROUND(hz, 100L);
>> -   l = sprintf (buf, "%ld", n);
>>
>> hz -= n * 100L;
>> m = DIV_ROUND(hz, 1000L);
>> +   if ( m < 0 ) {
>> +   n--;
>> +   m += 1000L;
>> +   }
>> +
>> +   l = sprintf (buf, "%ld", n);
>> if (m != 0)
>> sprintf (buf + l, ".%03ld", m);
>> return (buf);
>> 
>
> That looks overly complex to me. Can you please check if this patch
> fixes the problem for your test cases, too:
>   
Yes, it works.



-- 
Mit freundlichen Grüßen/With best regards,
Ilko Iliev
Ronetix Development Tools GmbH
Waidhausenstrasse 13/5
1140 Vienna, Austria
Tel: +43 1 956 3138 
Tel: +43 720 500 315
Fax: +43 1 8174 955 3464 
E-Mail: [EMAIL PROTECTED]
Web: www.ronetix.at
VAT: ATU63916016
Ronetix GmbH - 1140 Vienna - Geschäftsführer: Ilko Iliev
Registergericht: HG Vienna, FN 304979z


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

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

[Wolfgang Denk]

Dear Ilko Iliev,

In message <[EMAIL PROTECTED]> you wrote:
> This patch allows to have an at91 board specific lowlevel_init.S
> 
> Signed-off-by: Ilko Iliev <[EMAIL PROTECTED]>
> 
> index ec6ad5d..7882e89 100644
> --- a/cpu/arm926ejs/at91/lowlevel_init.S
> +++ b/cpu/arm926ejs/at91/lowlevel_init.S
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
> 
> -#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> +#if !defined(CONFIG_SKIP_LOWLEVEL_INIT) && 
> !defined(CONFIG_USER_LOWLEVEL_INIT)
> 
>  .globl lowlevel_init
>  lowlevel_init:
> @@ -39,5 +39,5 @@ lowlevel_init:
> mov pc, lr
> 
> .ltorg
> -
> -#endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> +
> +#endif /* !CONFIG_SKIP_LOWLEVEL_INIT && !CONFIG_USER_LOWLEVEL_INIT */

Maybe instead of adding mor #ifdef'ery here, we can turn
lowlevel_init() into a "weak" function that can be redefined by board
specific code?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Karl's version of Parkinson's Law: Work expands to  exceed  the  time
alloted it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] improved strmhz()

[Wolfgang Denk]

Dear Ilko Iliev,

In message <[EMAIL PROTECTED]> you wrote:
> This patch prevents the displaying of results like this:
> hz = 199917
> buf = "200.-83"

I think you got one '0' too many in your example - the example would
just print "1999.170" which is correct.

> --- a/lib_generic/strmhz.c
> +++ b/lib_generic/strmhz.c
> @@ -28,10 +28,15 @@ char *strmhz (char *buf, long hz)
> long m;
> 
> n = DIV_ROUND(hz, 100L);
> -   l = sprintf (buf, "%ld", n);
> 
> hz -= n * 100L;
> m = DIV_ROUND(hz, 1000L);
> +   if ( m < 0 ) {
> +   n--;
> +   m += 1000L;
> +   }
> +
> +   l = sprintf (buf, "%ld", n);
> if (m != 0)
> sprintf (buf + l, ".%03ld", m);
> return (buf);

That looks overly complex to me. Can you please check if this patch
fixes the problem for your test cases, too:

>From 963e7db81379225b78bfac0d7457300c86d6b4d6 Mon Sep 17 00:00:00 2001
From: Wolfgang Denk <[EMAIL PROTECTED]>
Date: Tue, 21 Oct 2008 15:53:51 +0200
Subject: [PATCH] Fix strmhz(): avoid printing negative fractions

Signed-off-by: Wolfgang Denk <[EMAIL PROTECTED]>
---
 lib_generic/strmhz.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib_generic/strmhz.c b/lib_generic/strmhz.c
index 342cf2b..d6da1d1 100644
--- a/lib_generic/strmhz.c
+++ b/lib_generic/strmhz.c
@@ -27,7 +27,7 @@ char *strmhz (char *buf, long hz)
long l, n;
long m;
 
-   n = DIV_ROUND(hz, 100L);
+   n = DIV_ROUND(hz, 1000) / 1000L;
l = sprintf (buf, "%ld", n);
 
hz -= n * 100L;
-- 
1.5.5.1


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Good manners are the settled  medium  of  social,  as  specie  is  of
commercial, life; returns are equally expected for both.
   - Lord Chesterfield _Letters to his Son_, 25 December 1753
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot