Re: [U-Boot] question: multiple serial

2011-02-24 Thread Stefano Babic 
On 02/24/2011 09:53 PM, Ran Shalit wrote:
> Hello,
> 
> I try to understand what is the right way in U-Boot to configure multiple
> serials.

That is correct.

> I use in my board more 3 UART's , one of them is the console.
> Should I define config_serial_multi ?

Yes

> when I did try to do so, I got
> "#error No default console" though UART2 is defined as console. Could it be
> that da850evm does not support configuration of multiple serials ?

The da850evm uses the NS16550 driver, and multiple uarts are supported.
It seems to me you have not set CONFIG_CONS_INDEX in your config file.

Best regards,
Stefano Babic

-- 
=
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: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 14:26, Detlev Zundel a écrit :
> Hi sughosh,
>
>> hi Albert,
>>
>> On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUDwrote:
>>
>>> Le 24/02/2011 12:08, sughosh ganu a écrit :
>>>
>>> I suspect the utility freaks out because it thinks the ELF cannot be
 made into a binary like it would previously, but actually the binary
 generation process did not change when we refactored the relocation
 -- maybe the utility would work on our relocatable ELFs with just
 the check for ELF type bypassed.

 Yes, even i think that would be the case, but i guess that would call
 for changes in the utility. Perhaps someone from TI can look into this.

>>>
>>> Isn't there some official support channel?
>>>
>>
>> I am not sure on this one. Hawkboard was a open source project, so hoping
>> someone from TI on the list can take a look into this.
>>
>> Sandeep, if you can point me to the person/list where this can be taken up,
>> i can follow up. Thanks.
>
> We should really strive to get the functionality of the utility into
> U-Boot itself.  Our mkimage already supports "custom wrappers" for i.MX
> and Kirkwood (cf. tools/{imximage,kwbimage}.c), so why not extend it for
> the AIS stuff?

 From the general search I did while responding in this thread, AIS is 
not documented publically -- but I may have missed it.

> Dependencies on external utilities is always a bad thing and breaks
> easily as was just demonstrated.

Agreed -- although actually, its the dependency on *binary, closed* 
external utilities that causes the issue.

> Cheers
>Detlev

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Wolfgang Denk 
Dear Albert ARIBAUD,

In message <4d674d85.40...@free.fr> you wrote:
> 
> All this, of course, if Wolfgang agrees to this suggestion.

I fully agree.

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: w...@denx.de
The inappropriate cannot be beautiful.
 - Frank Lloyd Wright _The Future of Architecture_ (1953)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] question: multiple serial

2011-02-24 Thread Albert ARIBAUD 
Hi Ran,

Le 24/02/2011 21:53, Ran Shalit a écrit :
> Hello,
>
> I try to understand what is the right way in U-Boot to configure multiple
> serials. I use in my board more 3 UART's , one of them is the console.
> Should I define config_serial_multi ? when I did try to do so, I got
> "#error No default console" though UART2 is defined as console. Could it be
> that da850evm does not support configuration of multiple serials ?

The simplest way I see is to inspect the code and trace back from the 
error message to see what exactly triggers this error and why.

One possible way would be to take the command line that results in this 
error and remplace compiler options to just output preprocessed source 
code instead of object code; you'll be able to see if the .h that 
contains the default console is included, and what parts of it are 
compiled exactly.

> Thank you very much,
>
> Ran

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Hi Po-Yu Chuang,

Le 25/02/2011 03:41, Po-Yu Chuang a écrit :
> Dear Wolfgang and Albert,
>
> On Fri, Feb 25, 2011 at 4:17 AM, Wolfgang Denk  wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4d66a7cd.9020...@free.fr>  you wrote:
>>>
 As far as I can tell, arch/powerpc/lib/board.c ,
 arch/avr32/lib/board.c and examples/standalone/stubs.c actually all
 mean __bss_end, as well as all the start.S files, so this seems to be
 consistently used at least.
>>>
>>> I'd come to the same conclusion on my side. However you don't say how
>>> you would like the change to be done. Would a single commit for renaming
>>> _end into _bss_end and then creating _end after .dynsym be ok for you?
>>
>> Ah, sorry.
>>
>> Well, these are two logically separate things: the first is just a
>> renamer that should basicly result in the very same images built on
>> all systems (which can easily be verified semi-automatically).  The
>> second step would be adding _end at the end of the used data area (end
>> of .dynsym) on ARM only.
>
> I don't have the environment to build other platforms, so... does any
> of you please to provide such patches?

I suggest you do the changes for all of U-Boot and test them on your 
specific board, then submit the patchset and Cc: all architecture 
custodians, who will run tests on their respective architectures.

 will give you all info on 
preparing and sending patches -- remember that's a two-patch set. IMO 
you don't necessarily need a cover letter as long as each patch has a 
clear commit message.

 will give you the list of 
all custodians; you can pick the architecture ones there.

All this, of course, if Wolfgang agrees to this suggestion.

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

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Wolfgang Denk 
Dear Andy Fleming,

In message  you 
wrote:
>
> Yeah, that took me a while, too.  Maybe we should update it to make clear:
>
> 1) The formula ends up being (2^(13 + timeout))/mmc->trans_speed = (1/4) 
> seconds
> --> 2^(13 + timeout) = mmc->trans_speed/4
> --> 13 + timeout = log2(mmc->trans_speed/4)
> ...etc

Does this not depend on the units used for speed, and thus in the end
on CONFIC_SYS_HZ ?

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: w...@denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offence.
  -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add support for the MMC device to the vexpress

2011-02-24 Thread Reinhard Meyer 
Dear matt.wad...@linaro.org,
> From: Matt Waddel
>
> These patches add support for the ARM PrimeCell PL180 MultiMedia Interface.
> The Versatile Express was the test platform for these changes.
>
> Matt Waddel (3):
>MMC: Max blocks value adjustable
>MMC: Add support for PL180 ARM mmc device
>ARMV7: Vexpress: Add MMC support
>
>   board/armltd/vexpress/ca9x4_ct_vxp.c |9 +
>   drivers/mmc/Makefile |1 +
>   drivers/mmc/mmc.c|   19 +-
>   drivers/mmc/mmci.c   |  452 
> ++
>   drivers/mmc/mmci.h   |  181 ++

I would expect something more descriptive like _mmc.[ch] here.
mmci.[ch] does not lead one to think its a hardware specific driver, even less 
for
what specific hardware it is.
The same is true for the exported function name "mmci_init", the macro 
CONFIG_MMCI etc.

Then, in patch 2/3:

+int mmci_init(void)

but in patch 3/3:

+   rc = mmci_init(bis);

Seems you should add a prototype to include/mmc.h to detect such mistakes ;)

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Po-Yu Chuang 
Dear Wolfgang and Albert,

On Fri, Feb 25, 2011 at 4:17 AM, Wolfgang Denk  wrote:
> Dear Albert ARIBAUD,
>
> In message <4d66a7cd.9020...@free.fr> you wrote:
>>
>> > As far as I can tell, arch/powerpc/lib/board.c ,
>> > arch/avr32/lib/board.c and examples/standalone/stubs.c actually all
>> > mean __bss_end, as well as all the start.S files, so this seems to be
>> > consistently used at least.
>>
>> I'd come to the same conclusion on my side. However you don't say how
>> you would like the change to be done. Would a single commit for renaming
>> _end into _bss_end and then creating _end after .dynsym be ok for you?
>
> Ah, sorry.
>
> Well, these are two logically separate things: the first is just a
> renamer that should basicly result in the very same images built on
> all systems (which can easily be verified semi-automatically).  The
> second step would be adding _end at the end of the used data area (end
> of .dynsym) on ARM only.

I don't have the environment to build other platforms, so... does any
of you please
to provide such patches?

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

[U-Boot] [PATCH 3/3] ARMV7: Vexpress: Add MMC support

2011-02-24 Thread matt . waddel 
From: Matt Waddel 

Added the board specific definitions to use the MMCI device.

Signed-off-by: Matt Waddel 
---
 board/armltd/vexpress/ca9x4_ct_vxp.c |9 +
 include/configs/ca9x4_ct_vxp.h   |4 
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c 
b/board/armltd/vexpress/ca9x4_ct_vxp.c
index ce1be1e..73cea1c 100644
--- a/board/armltd/vexpress/ca9x4_ct_vxp.c
+++ b/board/armltd/vexpress/ca9x4_ct_vxp.c
@@ -86,6 +86,15 @@ int board_eth_init(bd_t *bis)
return rc;
 }
 
+int cpu_mmc_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_MMCI
+   rc = mmci_init(bis);
+#endif
+   return rc;
+}
+
 static void flash__init(void)
 {
/* Setup the sytem control register to allow writing to flash */
diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h
index 63f003d..47a3bfc 100644
--- a/include/configs/ca9x4_ct_vxp.h
+++ b/include/configs/ca9x4_ct_vxp.h
@@ -86,6 +86,10 @@
 #define CONFIG_MMC 1
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
+#define CONFIG_MMCI
+#define CONFIG_MMC_BASE0x10005000
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT   127
+#define CONFIG_MMCI_CLOCK_FREQ 625
 
 /* BOOTP options */
 #define CONFIG_BOOTP_BOOTFILESIZE
-- 
1.7.1

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

[U-Boot] [PATCH 2/3] MMC: Add support for PL180 ARM mmc device

2011-02-24 Thread matt . waddel 
From: Matt Waddel 

Add support for the ARM PrimeCell MultiMedia Interface - PL180.
Ported from original device driver written by ST-Ericsson.

Signed-off-by: Matt Waddel 
---
 drivers/mmc/Makefile |1 +
 drivers/mmc/mmci.c   |  452 ++
 drivers/mmc/mmci.h   |  181 
 3 files changed, 634 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mmc/mmci.c
 create mode 100644 drivers/mmc/mmci.h

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 3496f0a..70b 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
 COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
 COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
 COBJS-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
+COBJS-$(CONFIG_MMCI) += mmci.o
 COBJS-$(CONFIG_MXC_MMC) += mxcmmc.o
 COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
 COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
diff --git a/drivers/mmc/mmci.c b/drivers/mmc/mmci.c
new file mode 100644
index 000..ba2f335
--- /dev/null
+++ b/drivers/mmc/mmci.c
@@ -0,0 +1,452 @@
+/*
+ * ARM PrimeCell MultiMedia Card Interface - PL180
+ *
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * Author: Ulf Hansson 
+ * Author: Martin Lundholm 
+ * Ported to drivers/mmc/ by: Matt Waddel 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/* #define DEBUG */
+
+#include 
+#include "common.h"
+#include 
+#include 
+#include "mmci.h"
+#include 
+
+struct mmc_host {
+   struct sdi_registers *base;
+};
+
+static int wait_for_command_end(struct mmc *dev, struct mmc_cmd *cmd)
+{
+   u32 hoststatus, statusmask;
+   struct mmc_host *host = dev->priv;
+
+   statusmask = SDI_STA_CTIMEOUT | SDI_STA_CCRCFAIL;
+   if ((cmd->resp_type & MMC_RSP_PRESENT))
+   statusmask |= SDI_STA_CMDREND;
+   else
+   statusmask |= SDI_STA_CMDSENT;
+
+   do
+   hoststatus = readl(&host->base->status) & statusmask;
+   while (!hoststatus);
+
+   writel(statusmask, &host->base->status_clear);
+   if (hoststatus & SDI_STA_CTIMEOUT) {
+   printf("CMD%d time out\n", cmd->cmdidx);
+   return -ETIMEDOUT;
+   } else if ((hoststatus & SDI_STA_CCRCFAIL) &&
+  (cmd->flags & MMC_RSP_CRC)) {
+   printf("CMD%d CRC error\n", cmd->cmdidx);
+   return -EILSEQ;
+   }
+
+   if (cmd->resp_type & MMC_RSP_PRESENT) {
+   cmd->response[0] = readl(&host->base->response0);
+   cmd->response[1] = readl(&host->base->response1);
+   cmd->response[2] = readl(&host->base->response2);
+   cmd->response[3] = readl(&host->base->response3);
+   debug("CMD%d response[0]:0x%08X, response[1]:0x%08X, "
+   "response[2]:0x%08X, response[3]:0x%08X\n",
+   cmd->cmdidx, cmd->response[0], cmd->response[1],
+   cmd->response[2], cmd->response[3]);
+   }
+
+   return 0;
+}
+
+/* send command to the mmc card and wait for results */
+static int do_command(struct mmc *dev, struct mmc_cmd *cmd)
+{
+   int result;
+   u32 sdi_cmd = 0;
+   struct mmc_host *host = dev->priv;
+
+   sdi_cmd = ((cmd->cmdidx & SDI_CMD_CMDINDEX_MASK) | SDI_CMD_CPSMEN);
+
+   if (cmd->resp_type) {
+   sdi_cmd |= SDI_CMD_WAITRESP;
+   if (cmd->resp_type & MMC_RSP_136)
+   sdi_cmd |= SDI_CMD_LONGRESP;
+   }
+
+   writel((u32)cmd->cmdarg, &host->base->argument);
+   udelay(COMMAND_REG_DELAY);
+   writel(sdi_cmd, &host->base->command);
+   result = wait_for_command_end(dev, cmd);
+
+   /* After CMD2 set RCA to a none zero value. */
+   if ((result == 0) && (cmd->cmdidx == MMC_CMD_ALL_SEND_CID))
+   dev->rca = 10;
+
+   /* After CMD3 open drain is switched off and push pull is used. */
+   if ((result == 0) && (cmd->cmdidx == MMC_CMD_SET_RELATIVE_ADDR)) {
+   u32 sdi_pwr = readl(&host->base->power) & ~SDI_PWR_OPD;
+   writel(sdi_pwr, &host->base->power);
+   }
+
+   return result;
+}
+
+static int convert_from_bytes_to_power_of_two(unsigned int x)
+{
+   int y = 0;
+   y = (x & 0x) ? 1 : 0;
+   y |= ((x

[U-Boot] [PATCH 1/3] MMC: Max blocks value adjustable

2011-02-24 Thread matt . waddel 
From: Matt Waddel 

The maximum blocks value was hardcoded to 65535 due to a 16 bit
register length.  The value can change for different platforms.
This patch makes the default the current value of 65535, but it
is configurable for other platforms.

Signed-off-by: Matt Waddel 
---
 drivers/mmc/mmc.c |   19 +--
 1 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 6805b33..d69eaa1 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -33,6 +33,11 @@
 #include 
 #include 
 
+/* Set block count limit because of 16 bit register limit on some hardware*/
+#ifndef CONFIG_SYS_MMC_MAX_BLK_COUNT
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT 65535
+#endif
+
 static struct list_head mmc_devices;
 static int cur_dev_num = -1;
 
@@ -139,11 +144,8 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, 
const void*src)
return 0;
 
do {
-   /*
-* The 65535 constraint comes from some hardware has
-* only 16 bit width block number counter
-*/
-   cur = (blocks_todo > 65535) ? 65535 : blocks_todo;
+   cur = (blocks_todo > CONFIG_SYS_MMC_MAX_BLK_COUNT) ?
+  CONFIG_SYS_MMC_MAX_BLK_COUNT : blocks_todo;
if(mmc_write_blocks(mmc, start, cur, src) != cur)
return 0;
blocks_todo -= cur;
@@ -215,11 +217,8 @@ static ulong mmc_bread(int dev_num, ulong start, lbaint_t 
blkcnt, void *dst)
return 0;
 
do {
-   /*
-* The 65535 constraint comes from some hardware has
-* only 16 bit width block number counter
-*/
-   cur = (blocks_todo > 65535) ? 65535 : blocks_todo;
+   cur = (blocks_todo > CONFIG_SYS_MMC_MAX_BLK_COUNT) ?
+  CONFIG_SYS_MMC_MAX_BLK_COUNT : blocks_todo;
if(mmc_read_blocks(mmc, dst, start, cur) != cur)
return 0;
blocks_todo -= cur;
-- 
1.7.1

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

[U-Boot] [PATCH 0/3] Add support for the MMC device to the vexpress

2011-02-24 Thread matt . waddel 
From: Matt Waddel 

These patches add support for the ARM PrimeCell PL180 MultiMedia Interface.
The Versatile Express was the test platform for these changes.

Matt Waddel (3):
  MMC: Max blocks value adjustable
  MMC: Add support for PL180 ARM mmc device
  ARMV7: Vexpress: Add MMC support

 board/armltd/vexpress/ca9x4_ct_vxp.c |9 +
 drivers/mmc/Makefile |1 +
 drivers/mmc/mmc.c|   19 +-
 drivers/mmc/mmci.c   |  452 ++
 drivers/mmc/mmci.h   |  181 ++
 include/configs/ca9x4_ct_vxp.h   |4 +
 6 files changed, 656 insertions(+), 10 deletions(-)
 create mode 100644 drivers/mmc/mmci.c
 create mode 100644 drivers/mmc/mmci.h

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

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Andy Fleming 
On Thu, Feb 24, 2011 at 3:50 AM, Wolfgang Denk  wrote:
> Dear Kumar Gala,
>
> In message <1298537614-20797-1-git-send-email-ga...@kernel.crashing.org> you 
> wrote:
>>
>> - Timeout counter value is set as DTOCV bits in SYSCTL register
>>   For counter value set as x,
>>   Timeout period = (2^(13+x))/SD_CLOCK
>>
>> - As per 4.6.2.2 section of SD Card specification v2.00, host should
>>   cofigure timeout period value to minimum 250 msec.
>>
>> - SD_CLOCK = mmc->trans_speed
>>
>> - Calculating x based on
>>   250 msec = (2^(13+x))/mmc->trans_speed
>
> OK, here the theory is given...
>
>> +     /* Timeout period = (2^(13+timeout))/mmc->trans_speed
>> +      * Timeout period should be minimum 250msec as per SD Card spec
>> +      */
>> +     timeout = fls(mmc->tran_speed/4);
>>       timeout -= 13;
>
> But how does this translate intothis formula?  I think there must be
> missing something.

Yeah, that took me a while, too.  Maybe we should update it to make clear:

1) The formula ends up being (2^(13 + timeout))/mmc->trans_speed = (1/4) seconds
--> 2^(13 + timeout) = mmc->trans_speed/4
--> 13 + timeout = log2(mmc->trans_speed/4)
...etc

2) We are effectively rounding up to the next highest power of 2 to
make sure the timeout is *at least* 250ms

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

Re: [U-Boot] Problem booting on custom board (85xx)

2011-02-24 Thread Charles Krinke 
Dear Kevin:

The times I have done this it is with a JTAG device, be it a Windriver
Probe, BDI or CodeWarrior USB TAP.

In all cases the JTAG emulator allows one to set the various register in the
chip, especially the DDR registers to get to where one can have *some
semblance* of working memory before attempting u-boot.

Have you not got a JTAG emulator for your project??

Charles

On Thu, Feb 24, 2011 at 3:53 PM, Alden, Kevin  wrote:

> I am still fighting this DDR issue.  Currently, I am trying to get a DDR
> test to run in uboot before the relocation occurs (in board_init_f).  The
> problem is that if I write code to access memory mapped to DDR, I see no DDR
> activity on the logic analyzer.  Unfortunately it took me a few days of
> analyzing memory test results before I realized this :)
>
> It seems like any access to DDR memory actually just accesses cache.
>  Looking at the relocate assembly code seems to verify this.  It looks like
> that assembly loads the cache and then flushes the cache to DDR.
>
> I tried modifying the DDR TLB entry to disable the cache, but that seems to
> hang my memory test before it even starts to write to memory.  Does anyone
> know of a way to get simple memory read/write access working inside
> board_init_f?
>
> Thanks,
> Kevin
>
>
> 
> From: Alden, Kevin
> Sent: Thursday, February 17, 2011 9:24 AM
> To: Jared Lewis
> Cc: u-boot@lists.denx.de
> Subject: RE: [U-Boot] Problem booting on custom board (85xx)
>
> I agree, it does seem like a DDR issue.
>
> I commented out the code below because it seemed unnecessary and I was able
> to get into board_init_r.  Problem now is that the first 3 instructions of
> board_init_r are all 0, so it crashes there.  I looked around in memory and
> this problem is all over the place.  Random instructions set to 0.  There
> must be a time value that is just on the edge of working properly.
>
> -Kevin
>
> -Original Message-
> From: Jared Lewis [mailto:jared.le...@radisys.com]
> Sent: Wednesday, February 16, 2011 4:57 PM
> To: Alden, Kevin
> Subject: RE: [U-Boot] Problem booting on custom board (85xx)
>
> Hello Kevin,
>
> In my experience (I've also worked on P2020s with U-Boot), if you can't
> make it to board_init_r, this is usually a DDR configuration problem.
> It is hard to say definitively from this output though.  Are you using
> the default RDB project for your DDR settings?
>
> Which emulator are you using to incorporate break points?  Are you using
> a BDI or a different emulator?  If you're using a BDI, are you
> configuring the memory controller of the P2020 with your configuration
> file or are you leaving the initialization to the U-Boot code?
>
> Thanks,
> Jared
>
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Alden, Kevin
> Sent: Wednesday, February 16, 2011 8:00 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] Problem booting on custom board (85xx)
>
> Hello,
>
> I have a custom board based on the Freescale P2020 RDB.  I am having
> trouble getting through the entire boot sequence.  Basically, I can't
> get a breakpoint to hit in board_init_r.
>
> I can get a break point in the "in_ram" section of start.s though.  This
> executes all the way to the following loop
>/*
>* Now adjust the fixups and the pointers to the fixups
>* in case we need to move ourselves again.
>*/
>li  r0,__fixup_entries@sectoff@l
>lwz r3,GOT(_FIXUP_TABLE_)
>cmpwi   r0,0
>mtctr r0
>addi   r3,r3,-4
>beq4f
> 3:lwzu   ri4,4(r3)
>lwzuxr0,r4,r11
>addr0,r0,r11
>stw r10,0(r3)
>stw r0,0(r4)
>bdnz  3b
>
> Basically, it spins through this loop for a while and eventually I get a
> TLB exception.  Is this just a cut and dry DDR configuration problem, or
> should I be looking at my Uboot setup?
>
> Thanks,
> Kevin
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



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

Re: [U-Boot] Problem booting on custom board (85xx)

2011-02-24 Thread Alden, Kevin 
I am still fighting this DDR issue.  Currently, I am trying to get a DDR test 
to run in uboot before the relocation occurs (in board_init_f).  The problem is 
that if I write code to access memory mapped to DDR, I see no DDR activity on 
the logic analyzer.  Unfortunately it took me a few days of analyzing memory 
test results before I realized this :)

It seems like any access to DDR memory actually just accesses cache.  Looking 
at the relocate assembly code seems to verify this.  It looks like that 
assembly loads the cache and then flushes the cache to DDR.

I tried modifying the DDR TLB entry to disable the cache, but that seems to 
hang my memory test before it even starts to write to memory.  Does anyone know 
of a way to get simple memory read/write access working inside board_init_f?

Thanks,
Kevin



From: Alden, Kevin
Sent: Thursday, February 17, 2011 9:24 AM
To: Jared Lewis
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] Problem booting on custom board (85xx)

I agree, it does seem like a DDR issue.

I commented out the code below because it seemed unnecessary and I was able to 
get into board_init_r.  Problem now is that the first 3 instructions of 
board_init_r are all 0, so it crashes there.  I looked around in memory and 
this problem is all over the place.  Random instructions set to 0.  There must 
be a time value that is just on the edge of working properly.

-Kevin

-Original Message-
From: Jared Lewis [mailto:jared.le...@radisys.com]
Sent: Wednesday, February 16, 2011 4:57 PM
To: Alden, Kevin
Subject: RE: [U-Boot] Problem booting on custom board (85xx)

Hello Kevin,

In my experience (I've also worked on P2020s with U-Boot), if you can't
make it to board_init_r, this is usually a DDR configuration problem.
It is hard to say definitively from this output though.  Are you using
the default RDB project for your DDR settings?

Which emulator are you using to incorporate break points?  Are you using
a BDI or a different emulator?  If you're using a BDI, are you
configuring the memory controller of the P2020 with your configuration
file or are you leaving the initialization to the U-Boot code?

Thanks,
Jared

-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Alden, Kevin
Sent: Wednesday, February 16, 2011 8:00 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] Problem booting on custom board (85xx)

Hello,

I have a custom board based on the Freescale P2020 RDB.  I am having
trouble getting through the entire boot sequence.  Basically, I can't
get a breakpoint to hit in board_init_r.

I can get a break point in the "in_ram" section of start.s though.  This
executes all the way to the following loop
/*
* Now adjust the fixups and the pointers to the fixups
* in case we need to move ourselves again.
*/
li  r0,__fixup_entries@sectoff@l
lwz r3,GOT(_FIXUP_TABLE_)
cmpwi   r0,0
mtctr r0
addi   r3,r3,-4
beq4f
3:lwzu   ri4,4(r3)
lwzuxr0,r4,r11
addr0,r0,r11
stw r10,0(r3)
stw r0,0(r4)
bdnz  3b

Basically, it spins through this loop for a while and eventually I get a
TLB exception.  Is this just a cut and dry DDR configuration problem, or
should I be looking at my Uboot setup?

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

[U-Boot] USBNET in OMAP (beagleboard)

2011-02-24 Thread Rick Bronson 
Hi All,

  I've searched the mailing list archives and couldn't come up with an
answer so I thought I'd try here: Anyone know of any implementations
of USBNET in u-boot for OMAP?  This feature allows the OMAP, as a USB
device (gadget), to do networking over a USB connection with a USB
host.

  Thanks much for any help.

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

[U-Boot] [PATCH] OMAP3 Beagle Pin Mux initialization glitch fix

2011-02-24 Thread Bob Feretich 
The below patch reverses the order of two segments in the board file.
Output pins need to have their values initialized, before they are
exposed to the logic outside the chip.

Signed-off-by: Bob Feretich 
Cc: Wolfgang Denk 
---

diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
--- a/board/ti/beagle/beagle.c  2011-02-23 17:26:27.0 -0800
+++ b/board/ti/beagle/beagle.c  2011-02-23 17:47:44.0 -0800
@@ -239,17 +239,17 @@ int misc_init_r(void)
twl4030_power_init();
twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);

-   /* Configure GPIOs to output */
-   writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe);
-   writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
-   GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe);
-
-   /* Set GPIOs */
+   /* Set GPIO states before they are made outputs */
writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1,
&gpio6_base->setdataout);
writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout);

+   /* Configure GPIOs to output */
+   writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe);
+   writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
+   GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe);
+
dieid_num_r();

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

Re: [U-Boot] [PATCH v4 1/4] Refactor do_reset() into board-specific and CPU-specific portions

2011-02-24 Thread Moffett, Kyle D 
On Feb 24, 2011, at 13:41, Wolfgang Denk wrote:
> In message  you wrote:
>> 
>> Perhaps the default should instead be something like this?
>> 
>> __attribute__((__weak__)) int arch_reset(void)
>> {
>> while(1);
>> }
> 
> No. Please don;t implement something that does not do what it is
> supposed to do. Rather make the problem obvious.
> 
>> Having a default might make it easier to do the initial standup of a new CPU
>> type (less code to write initially), but you wouldn't get any obvious errors
>> about the fact that you are missing functionality.
> 
> That's a fundamentally broken approach.  You know how people work:
> they start, they have something running without too blatant error
> messages, they leave it as is and go on to the next task.
> 
> I rather see a clear unresolved external reference error instead of a
> bad defualt that doesn't work.

Ok, I'm working on an updated patch.

There are a few CPU architectures like the 74xx_7xx which have worrying 
comments like these:
 /* no generic way to do board reset. simply call soft_reset. */

It basically just disables caching and performs a jump to the CPU reset vector.

Several boards already have overrides of various sorts to use board-specific 
reset vectors; from looking at commit logs and configuration for the boards 
based on the 74xx and 7xx I'm not convinced that reset function has ever been 
tested on some of them.

I would almost be willing to argue that if that kind of "soft reset" is a 
desirable feature then U-Boot should support it separately via a 
"kexec()"-style interface.

Anyways, I should be sending out a new patch here shortly.

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

[U-Boot] question: multiple serial

2011-02-24 Thread Ran Shalit 
Hello,

I try to understand what is the right way in U-Boot to configure multiple
serials. I use in my board more 3 UART's , one of them is the console.
Should I define config_serial_multi ? when I did try to do so, I got
"#error No default console" though UART2 is defined as console. Could it be
that da850evm does not support configuration of multiple serials ?

Thank you very much,

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Wolfgang Denk 
Dear Albert ARIBAUD,

In message <4d66a7cd.9020...@free.fr> you wrote:
>
> > As far as I can tell, arch/powerpc/lib/board.c ,
> > arch/avr32/lib/board.c and examples/standalone/stubs.c actually all
> > mean __bss_end, as well as all the start.S files, so this seems to be
> > consistently used at least.
> 
> I'd come to the same conclusion on my side. However you don't say how 
> you would like the change to be done. Would a single commit for renaming 
> _end into _bss_end and then creating _end after .dynsym be ok for you?

Ah, sorry.

Well, these are two logically separate things: the first is just a
renamer that should basicly result in the very same images built on
all systems (which can easily be verified semi-automatically).  The
second step would be adding _end at the end of the used data area (end
of .dynsym) on ARM only.

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: w...@denx.de
G's Third Law: In spite of all evidence  to  the  contra-
ry,  the  entire  universe  is composed of only two basic substances:
magic and bullshit.
H's Dictum:There is no magic ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 19:38, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d6680e4.1070...@free.fr>  you wrote:
>>
>> Do you mean a first commit to turn _end into _bss_end everywhere in
>> U-Boot, then a second commit to reintroduce _end and fix the issue with
>> monitor protection? Or even maybe a single commit for both?
>
> We should re-check if the current use of _end; excluding the linker
> scripts, I see these uses:
>
> arch/powerpc/cpu/74xx_7xx/start.S:GOT_ENTRY(_end)
> arch/powerpc/cpu/74xx_7xx/start.S:lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc512x/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc512x/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc5xx/start.S:  GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc5xx/start.S:  lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc5xxx/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc5xxx/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc8220/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc8220/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc824x/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc824x/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc8260/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc8260/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc83xx/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc83xx/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc85xx/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc85xx/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc86xx/start.S: GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc86xx/start.S: lwz r4,GOT(_end)
> arch/powerpc/cpu/mpc8xx/start.S:  GOT_ENTRY(_end)
> arch/powerpc/cpu/mpc8xx/start.S:  lwz r4,GOT(_end)
> arch/powerpc/cpu/ppc4xx/start.S:  GOT_ENTRY(_end)
> arch/powerpc/cpu/ppc4xx/start.S:  lwz r4,GOT(_end)
> arch/powerpc/lib/board.c:extern ulong _end;
> arch/powerpc/lib/board.c: len = (ulong)&_end - CONFIG_SYS_MONITOR_BASE;
> arch/arm/cpu/arm1136/start.S: .word _end - _start
> arch/arm/cpu/arm1176/start.S: .word _end - _start
> arch/arm/cpu/arm720t/start.S: .word _end - _start
> arch/arm/cpu/arm920t/start.S: .word _end - _start
> arch/arm/cpu/arm925t/start.S: .word _end - _start
> arch/arm/cpu/arm926ejs/start.S:   .word _end - _start
> arch/arm/cpu/arm946es/start.S:.word _end - _start
> arch/arm/cpu/arm_intcm/start.S:   .word _end - _start
> arch/arm/cpu/ixp/start.S: .word _end - _start
> arch/arm/cpu/lh7a40x/start.S: .word _end - _start
> arch/arm/cpu/pxa/start.S: .word _end - _start
> arch/arm/cpu/s3c44b0/start.S: .word _end - _start
> arch/arm/cpu/sa1100/start.S:  .word _end - _start
> arch/arm/cpu/armv7/start.S:   .word _end - _start
> arch/avr32/cpu/start.S:   lda.w   r9, _end
> arch/avr32/include/asm/sections.h:extern char _end[];
> arch/avr32/lib/board.c:   (unsigned long)_data, (unsigned 
> long)_end);
> arch/avr32/lib/board.c:   monitor_len = _end - _text;
> arch/m68k/lib/board.c:extern ulong _end;
> arch/m68k/lib/board.c:len = (ulong)&_end - CONFIG_SYS_MONITOR_BASE;
> arch/microblaze/cpu/start.S:  addir4, r0, __end
> arch/microblaze/cpu/start.S:  rsubr4, r5, r4  /* size = __end - 
> __text_start */
> arch/nios2/cpu/start.S:* and between __bss_start and _end.
> arch/nios2/cpu/start.S:movhi  r6, %hi(_end)
> arch/nios2/cpu/start.S:orir6, r6, %lo(_end)
> board/mousse/u-boot.lds.ram:  _end = . ;
> board/mousse/u-boot.lds.rom:  _end = . ;
> examples/standalone/stubs.c:extern unsigned long __bss_start, _end;
> examples/standalone/stubs.c:  while (cp<  (unsigned char *)&_end) {
>
> As far as I can tell, arch/powerpc/lib/board.c ,
> arch/avr32/lib/board.c and examples/standalone/stubs.c actually all
> mean __bss_end, as well as all the start.S files, so this seems to be
> consistently used at least.

I'd come to the same conclusion on my side. However you don't say how 
you would like the change to be done. Would a single commit for renaming 
_end into _bss_end and then creating _end after .dynsym be ok for you?

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [PATCH v4 1/4] Refactor do_reset() into board-specific and CPU-specific portions

2011-02-24 Thread Wolfgang Denk 
Dear "Moffett, Kyle D",

In message  you wrote:
>
> Perhaps the default should instead be something like this?
> 
>   __attribute__((__weak__)) int arch_reset(void)
>   {
>   while(1);
>   }

No. Please don;t implement something that does not do what it is
supposed to do. Rather make the problem obvious.

> Having a default might make it easier to do the initial standup of a new CPU
> type (less code to write initially), but you wouldn't get any obvious errors
> about the fact that you are missing functionality.

That's a fundamentally broken approach.  You know how people work:
they start, they have something running without too blatant error
messages, they leave it as is and go on to the next task.

I rather see a clear unresolved external reference error instead of a
bad defualt that doesn't work.

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: w...@denx.de
"There is no distinctly American criminal class except Congress."
- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/4] Refactor do_reset() into board-specific and CPU-specific portions

2011-02-24 Thread Moffett, Kyle D 
On Feb 23, 2011, at 14:35, Mike Frysinger wrote:
> On Wednesday, February 23, 2011 14:28:44 Kyle Moffett wrote:
>> +__attribute__((__weak__)) int arch_reset(void)
>> +{
>> +return 0;
>> +}
> 
> is there any cpu which wouldnt provide arch_reset() ?  i dont think it was 
> possible in the past to do this, so i dont see any value in supporting this.

Hmm, good point.

Although, I think there are a few CPUs which fundamentally cannot reset on 
their own (they rely on external board-specific hardware triggered by GPIOs).

Perhaps the default should instead be something like this?

  __attribute__((__weak__)) int arch_reset(void)
  {
  while(1);
  }

Having a default might make it easier to do the initial standup of a new CPU 
type (less code to write initially), but you wouldn't get any obvious errors 
about the fact that you are missing functionality.

I can't really form enough of an opinion to care either way, so if you have any 
strong preferences please let me know.

Thanks for the review!

Cheers,
Kyle Moffett

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Wolfgang Denk 
Dear Albert ARIBAUD,

In message <4d6680e4.1070...@free.fr> you wrote:
>
> Do you mean a first commit to turn _end into _bss_end everywhere in 
> U-Boot, then a second commit to reintroduce _end and fix the issue with 
> monitor protection? Or even maybe a single commit for both?

We should re-check if the current use of _end; excluding the linker
scripts, I see these uses:

arch/powerpc/cpu/74xx_7xx/start.S:  GOT_ENTRY(_end)
arch/powerpc/cpu/74xx_7xx/start.S:  lwz r4,GOT(_end)
arch/powerpc/cpu/mpc512x/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc512x/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc5xx/start.S:GOT_ENTRY(_end)
arch/powerpc/cpu/mpc5xx/start.S:lwz r4,GOT(_end)
arch/powerpc/cpu/mpc5xxx/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc5xxx/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc8220/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc8220/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc824x/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc824x/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc8260/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc8260/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc83xx/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc83xx/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc85xx/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc85xx/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc86xx/start.S:   GOT_ENTRY(_end)
arch/powerpc/cpu/mpc86xx/start.S:   lwz r4,GOT(_end)
arch/powerpc/cpu/mpc8xx/start.S:GOT_ENTRY(_end)
arch/powerpc/cpu/mpc8xx/start.S:lwz r4,GOT(_end)
arch/powerpc/cpu/ppc4xx/start.S:GOT_ENTRY(_end)
arch/powerpc/cpu/ppc4xx/start.S:lwz r4,GOT(_end)
arch/powerpc/lib/board.c:extern ulong _end;
arch/powerpc/lib/board.c:   len = (ulong)&_end - CONFIG_SYS_MONITOR_BASE;
arch/arm/cpu/arm1136/start.S:   .word _end - _start
arch/arm/cpu/arm1176/start.S:   .word _end - _start
arch/arm/cpu/arm720t/start.S:   .word _end - _start
arch/arm/cpu/arm920t/start.S:   .word _end - _start
arch/arm/cpu/arm925t/start.S:   .word _end - _start
arch/arm/cpu/arm926ejs/start.S: .word _end - _start
arch/arm/cpu/arm946es/start.S:  .word _end - _start
arch/arm/cpu/arm_intcm/start.S: .word _end - _start
arch/arm/cpu/ixp/start.S:   .word _end - _start
arch/arm/cpu/lh7a40x/start.S:   .word _end - _start
arch/arm/cpu/pxa/start.S:   .word _end - _start
arch/arm/cpu/s3c44b0/start.S:   .word _end - _start
arch/arm/cpu/sa1100/start.S:.word _end - _start
arch/arm/cpu/armv7/start.S: .word _end - _start
arch/avr32/cpu/start.S: lda.w   r9, _end
arch/avr32/include/asm/sections.h:extern char _end[];
arch/avr32/lib/board.c: (unsigned long)_data, (unsigned long)_end);
arch/avr32/lib/board.c: monitor_len = _end - _text;
arch/m68k/lib/board.c:extern ulong _end;
arch/m68k/lib/board.c:  len = (ulong)&_end - CONFIG_SYS_MONITOR_BASE;
arch/microblaze/cpu/start.S:addir4, r0, __end
arch/microblaze/cpu/start.S:rsubr4, r5, r4  /* size = __end - 
__text_start */
arch/nios2/cpu/start.S:  * and between __bss_start and _end.
arch/nios2/cpu/start.S:  movhi  r6, %hi(_end)
arch/nios2/cpu/start.S:  orir6, r6, %lo(_end)
board/mousse/u-boot.lds.ram:  _end = . ;
board/mousse/u-boot.lds.rom:  _end = . ;
examples/standalone/stubs.c:extern unsigned long __bss_start, _end;
examples/standalone/stubs.c:while (cp < (unsigned char *)&_end) {

As far as I can tell, arch/powerpc/lib/board.c ,
arch/avr32/lib/board.c and examples/standalone/stubs.c actually all
mean __bss_end, as well as all the start.S files, so this seems to be
consistently used at least.

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: w...@denx.de
Another dream that failed.  There's nothing sadder.
-- Kirk, "This side of Paradise", stardate 3417.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Board [AR71XX] - WNDR3700 u-Boot USB Support *Will donate one to the interested*

2011-02-24 Thread pete 
Board [AR71XX] - WNDR3700 u-Boot USB Support

Hey i have been playing around with the uboot sources NetGear have
provided with hope to enable USB Support so i can boot direcly from an
USB-Stick.
The sources NetGear have provided is based on u-boot-2006-04-06-1725 where
they have added basic support for AR71XX boards *no USB drivers though*
So the compilation will basicly fail with these errors since there's no
lowlevel usb driver added.

common/libcommon.a(usb.o): In function `usb_stop':
usb.c:(.text+0x9c): undefined reference to `usb_lowlevel_stop'
common/libcommon.a(usb.o): In function `usb_submit_int_msg':
usb.c:(.text+0xd0): undefined reference to `submit_int_msg'
common/libcommon.a(usb.o): In function `usb_control_msg':
usb.c:(.text+0x194): undefined reference to `submit_control_msg'
common/libcommon.a(usb.o): In function `usb_bulk_msg':
usb.c:(.text+0x26c): undefined reference to `submit_bulk_msg'
common/libcommon.a(usb.o): In function `usb_init':
usb.c:(.text+0x2094): undefined reference to `usb_lowlevel_init'
common/libcommon.a(usb_storage.o): In function `usb_stor_CBI_get_status':
usb_storage.c:(.text+0x874): undefined reference to `submit_int_msg'
make: *** [u-boot] Error 1

The code is indeed old - i made a tar.gz file that contains only the
changed & added files over here
http://unlogical.net/files/misc/wndr3700-uboot-diff.tar.gz
However porting this code & adding a proper USB support is a to great task
for me, my programming knowledge is basicly to limited and even more when
it comes to hardware.

Anyhow if anyone would be interested in this task i would DONATE a NEW
WNDR3700 to the one interested. 
Or basicly instead of sending such a device, tell me how much the WNDR3700
would cost nearest your computer shop / internet shop and i would transfer
the money to you through eg paypal. 
*Since i don't know how much work this task would need* I don't know if
the price of a WNDR3700 would be suitable, but since these devices are
pretty expensive that's all i can afford. And if it's just not worth the
time just tell me, i just wanted to ask since i can't possibly suceed with
this at this moment.

Please excuse my limited english.
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 14:41, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d66596...@free.fr>  you wrote:
>>
>> Thanks for pointing this out: indeed, _end is actually used as BSS's
>> end, not as the image's end -- I did not find any other use of it.
>>
>> However, not only ARM uses _end: how do we want to handle the change
>> overall?
>
> Sounds as if we need a little fix/cleanup for _all_ systems...

Do you mean a first commit to turn _end into _bss_end everywhere in 
U-Boot, then a second commit to reintroduce _end and fix the issue with 
monitor protection? Or even maybe a single commit for both?

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Wolfgang Denk 
Dear Albert ARIBAUD,

In message <4d66596...@free.fr> you wrote:
>
> Thanks for pointing this out: indeed, _end is actually used as BSS's 
> end, not as the image's end -- I did not find any other use of it.
> 
> However, not only ARM uses _end: how do we want to handle the change 
> overall?

Sounds as if we need a little fix/cleanup for _all_ systems...

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: w...@denx.de
panic: kernel trap (ignored)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread Detlev Zundel 
Hi sughosh,

> hi Albert,
>
> On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD wrote:
>
>> Le 24/02/2011 12:08, sughosh ganu a écrit :
>>
>>I suspect the utility freaks out because it thinks the ELF cannot be
>>>made into a binary like it would previously, but actually the binary
>>>generation process did not change when we refactored the relocation
>>>-- maybe the utility would work on our relocatable ELFs with just
>>>the check for ELF type bypassed.
>>>
>>> Yes, even i think that would be the case, but i guess that would call
>>> for changes in the utility. Perhaps someone from TI can look into this.
>>>
>>
>> Isn't there some official support channel?
>>
>
> I am not sure on this one. Hawkboard was a open source project, so hoping
> someone from TI on the list can take a look into this.
>
> Sandeep, if you can point me to the person/list where this can be taken up,
> i can follow up. Thanks.

We should really strive to get the functionality of the utility into
U-Boot itself.  Our mkimage already supports "custom wrappers" for i.MX
and Kirkwood (cf. tools/{imximage,kwbimage}.c), so why not extend it for
the AIS stuff?

Dependencies on external utilities is always a bad thing and breaks
easily as was just demonstrated.

Cheers
  Detlev

-- 
Whenever you find yourself on the side of the majority it is
time to pause and reflect.
-- Mark Twain
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 13:58, Po-Yu Chuang a écrit :
> Hi Albert,
>
> On Thu, Feb 24, 2011 at 7:58 PM, Albert ARIBAUD  
> wrote:
>> Le 24/02/2011 10:39, Wolfgang Denk a écrit :
>>>
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4d6611a7.5050...@free.fr>you wrote:

>>> In the U-Boot image itself, knowing the image size could be achieved
>>> in
>>> ARM by using a general _end symbol that would be set after the last
>>> image output section, so _end-_start would equal the image size.
>>
>> we have such a "_end" in u-boot.lds files.

 I *knew* this name did not pop up in my mind without a reason. :)

 Apologies for not having checked.

> I guess we need a __dynsym_end in all u-boot.lds files.

 I'd rather go for "_end", which does not tie the solution to dynsym
 being the last section in the image -- imagine for some reason we move
 dynsym inside the image rather than at the end, end the image size will
 be wrong again. With _end, and a suitable comment in the LD file... this
 will be averted where-ever dynsym ends up.

 After all, the bug you uncovered was due to using the wrong symbol, a
 BSS related one rather than an image-related one, in the first place; so
 let's try and learn from past mistakes.
>>>
>>> I think the location of _end in the linker scripts needs to be changed
>>> - so far it covers the maximum of dynsym and bss, but it should refer
>>> to the end of dynsym only.
>>
>> Po-Yu Chuang, can you verify Wolfgang's suggestion (and make sure no other
>> place depends on _end) and submit a patch? As this is a fix, a quick patch
>> could still be pulled in for the upcoming release.
>
> I think there is a problem in Wolfgang's suggestion.
>
> Those start.S files assume that BSS section is from __bss_start to _end.
> If we change _end to the end of .dynsym, then we will not clear BSS correctly.
>
> I agree with your comment about _end is a better choice than __dynsym_end,
> but if we changed _end, maybe we need __bss_end? Either way, we need to
> modify all the u-boot.lds and/or start.S.
>
> I still don't know what is the best solution.

Thanks for pointing this out: indeed, _end is actually used as BSS's 
end, not as the image's end -- I did not find any other use of it.

However, not only ARM uses _end: how do we want to handle the change 
overall?

> best regards,
> Po-Yu Chuang

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Po-Yu Chuang 
Hi Albert,

On Thu, Feb 24, 2011 at 7:58 PM, Albert ARIBAUD  wrote:
> Le 24/02/2011 10:39, Wolfgang Denk a écrit :
>>
>> Dear Albert ARIBAUD,
>>
>> In message<4d6611a7.5050...@free.fr>  you wrote:
>>>
>> In the U-Boot image itself, knowing the image size could be achieved
>> in
>> ARM by using a general _end symbol that would be set after the last
>> image output section, so _end-_start would equal the image size.
>
> we have such a "_end" in u-boot.lds files.
>>>
>>> I *knew* this name did not pop up in my mind without a reason. :)
>>>
>>> Apologies for not having checked.
>>>
 I guess we need a __dynsym_end in all u-boot.lds files.
>>>
>>> I'd rather go for "_end", which does not tie the solution to dynsym
>>> being the last section in the image -- imagine for some reason we move
>>> dynsym inside the image rather than at the end, end the image size will
>>> be wrong again. With _end, and a suitable comment in the LD file... this
>>> will be averted where-ever dynsym ends up.
>>>
>>> After all, the bug you uncovered was due to using the wrong symbol, a
>>> BSS related one rather than an image-related one, in the first place; so
>>> let's try and learn from past mistakes.
>>
>> I think the location of _end in the linker scripts needs to be changed
>> - so far it covers the maximum of dynsym and bss, but it should refer
>> to the end of dynsym only.
>
> Po-Yu Chuang, can you verify Wolfgang's suggestion (and make sure no other
> place depends on _end) and submit a patch? As this is a fix, a quick patch
> could still be pulled in for the upcoming release.

I think there is a problem in Wolfgang's suggestion.

Those start.S files assume that BSS section is from __bss_start to _end.
If we change _end to the end of .dynsym, then we will not clear BSS correctly.

I agree with your comment about _end is a better choice than __dynsym_end,
but if we changed _end, maybe we need __bss_end? Either way, we need to
modify all the u-boot.lds and/or start.S.

I still don't know what is the best solution.

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

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread sughosh ganu 
hi Albert,

On Thu, Feb 24, 2011 at 4:58 PM, Albert ARIBAUD wrote:

> Le 24/02/2011 12:08, sughosh ganu a écrit :
>
>I suspect the utility freaks out because it thinks the ELF cannot be
>>made into a binary like it would previously, but actually the binary
>>generation process did not change when we refactored the relocation
>>-- maybe the utility would work on our relocatable ELFs with just
>>the check for ELF type bypassed.
>>
>> Yes, even i think that would be the case, but i guess that would call
>> for changes in the utility. Perhaps someone from TI can look into this.
>>
>
> Isn't there some official support channel?
>

I am not sure on this one. Hawkboard was a open source project, so hoping
someone from TI on the list can take a look into this.

Sandeep, if you can point me to the person/list where this can be taken up,
i can follow up. Thanks.

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

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 10:39, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d6611a7.5050...@free.fr>  you wrote:
>>
> In the U-Boot image itself, knowing the image size could be achieved in
> ARM by using a general _end symbol that would be set after the last
> image output section, so _end-_start would equal the image size.

 we have such a "_end" in u-boot.lds files.
>>
>> I *knew* this name did not pop up in my mind without a reason. :)
>>
>> Apologies for not having checked.
>>
>>> I guess we need a __dynsym_end in all u-boot.lds files.
>>
>> I'd rather go for "_end", which does not tie the solution to dynsym
>> being the last section in the image -- imagine for some reason we move
>> dynsym inside the image rather than at the end, end the image size will
>> be wrong again. With _end, and a suitable comment in the LD file... this
>> will be averted where-ever dynsym ends up.
>>
>> After all, the bug you uncovered was due to using the wrong symbol, a
>> BSS related one rather than an image-related one, in the first place; so
>> let's try and learn from past mistakes.
>
> I think the location of _end in the linker scripts needs to be changed
> - so far it covers the maximum of dynsym and bss, but it should refer
> to the end of dynsym only.

Po-Yu Chuang, can you verify Wolfgang's suggestion (and make sure no 
other place depends on _end) and submit a patch? As this is a fix, a 
quick patch could still be pulled in for the upcoming release.

> Best regards,
>
> Wolfgang Denk

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

[U-Boot] [PATCHv2 1/2] ARM: OMAP3: Revamp IGEP v2 default configuration

2011-02-24 Thread Enric Balletbo i Serra 
The default IGEP configuration doesn't do anything useful; using some
boot.scr search logic like BeagleBoard is much more useful.

Signed-off-by: Loïc Minier 
Signed-off-by: Enric Balletbo i Serra 
---
 include/configs/igep0020.h |   57 
 1 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h
index c19ecc0..fc15a9c 100644
--- a/include/configs/igep0020.h
+++ b/include/configs/igep0020.h
@@ -129,14 +129,61 @@
  */
 #define CONFIG_TWL4030_POWER   1
 
-/* Environment information */
-#define CONFIG_BOOTCOMMAND \
-   "mmc init 0 ; fatload mmc 0 0x8000 setup.ini ; source \0"
-
 #define CONFIG_BOOTDELAY   3
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "usbtty=cdc_acm\0"
+   "usbtty=cdc_acm\0" \
+   "loadaddr=0x8200\0" \
+   "usbtty=cdc_acm\0" \
+   "console=ttyS2,115200n8\0" \
+   "mpurate=500\0" \
+   "vram=12M\0" \
+   "dvimode=1024x768MR-16@60\0" \
+   "defaultdisplay=dvi\0" \
+   "mmcdev=0\0" \
+   "mmcroot=/dev/mmcblk0p2 rw\0" \
+   "mmcrootfstype=ext3 rootwait\0" \
+   "nandroot=/dev/mtdblock4 rw\0" \
+   "nandrootfstype=jffs2\0" \
+   "mmcargs=setenv bootargs console=${console} " \
+   "mpurate=${mpurate} " \
+   "vram=${vram} " \
+   "omapfb.mode=dvi:${dvimode} " \
+   "omapfb.debug=y " \
+   "omapdss.def_disp=${defaultdisplay} " \
+   "root=${mmcroot} " \
+   "rootfstype=${mmcrootfstype}\0" \
+   "nandargs=setenv bootargs console=${console} " \
+   "mpurate=${mpurate} " \
+   "vram=${vram} " \
+   "omapfb.mode=dvi:${dvimode} " \
+   "omapfb.debug=y " \
+   "omapdss.def_disp=${defaultdisplay} " \
+   "root=${nandroot} " \
+   "rootfstype=${nandrootfstype}\0" \
+   "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+   "bootscript=echo Running bootscript from mmc ...; " \
+   "source ${loadaddr}\0" \
+   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "mmcboot=echo Booting from mmc ...; " \
+   "run mmcargs; " \
+   "bootm ${loadaddr}\0" \
+   "nandboot=echo Booting from onenand ...; " \
+   "run nandargs; " \
+   "onenand read ${loadaddr} 28 40; " \
+   "bootm ${loadaddr}\0" \
+
+#define CONFIG_BOOTCOMMAND \
+   "if mmc rescan ${mmcdev}; then " \
+   "if run loadbootscript; then " \
+   "run bootscript; " \
+   "else " \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
+   "else run nandboot; " \
+   "fi; " \
+   "fi; " \
+   "else run nandboot; fi"
 
 #define CONFIG_AUTO_COMPLETE   1
 
-- 
1.7.0.4

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

[U-Boot] [PATCHv2 2/2] ARM: OMAP3: Revamp IGEP module default configuration

2011-02-24 Thread Enric Balletbo i Serra 
The default IGEP configuration doesn't do anything useful; using some
boot.scr search logic like BeagleBoard is much more useful.

Signed-off-by: Enric Balletbo i Serra 
---
 include/configs/igep0030.h |   57 
 1 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h
index 1325bfa..713b1b9 100644
--- a/include/configs/igep0030.h
+++ b/include/configs/igep0030.h
@@ -127,14 +127,61 @@
  */
 #define CONFIG_TWL4030_POWER   1
 
-/* Environment information */
-#define CONFIG_BOOTCOMMAND \
-   "mmc init 0 ; fatload mmc 0 0x8000 setup.ini ; source \0"
-
 #define CONFIG_BOOTDELAY   3
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "usbtty=cdc_acm\0"
+   "usbtty=cdc_acm\0" \
+   "loadaddr=0x8200\0" \
+   "usbtty=cdc_acm\0" \
+   "console=ttyS2,115200n8\0" \
+   "mpurate=500\0" \
+   "vram=12M\0" \
+   "dvimode=1024x768MR-16@60\0" \
+   "defaultdisplay=dvi\0" \
+   "mmcdev=0\0" \
+   "mmcroot=/dev/mmcblk0p2 rw\0" \
+   "mmcrootfstype=ext3 rootwait\0" \
+   "nandroot=/dev/mtdblock4 rw\0" \
+   "nandrootfstype=jffs2\0" \
+   "mmcargs=setenv bootargs console=${console} " \
+   "mpurate=${mpurate} " \
+   "vram=${vram} " \
+   "omapfb.mode=dvi:${dvimode} " \
+   "omapfb.debug=y " \
+   "omapdss.def_disp=${defaultdisplay} " \
+   "root=${mmcroot} " \
+   "rootfstype=${mmcrootfstype}\0" \
+   "nandargs=setenv bootargs console=${console} " \
+   "mpurate=${mpurate} " \
+   "vram=${vram} " \
+   "omapfb.mode=dvi:${dvimode} " \
+   "omapfb.debug=y " \
+   "omapdss.def_disp=${defaultdisplay} " \
+   "root=${nandroot} " \
+   "rootfstype=${nandrootfstype}\0" \
+   "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+   "bootscript=echo Running bootscript from mmc ...; " \
+   "source ${loadaddr}\0" \
+   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "mmcboot=echo Booting from mmc ...; " \
+   "run mmcargs; " \
+   "bootm ${loadaddr}\0" \
+   "nandboot=echo Booting from onenand ...; " \
+   "run nandargs; " \
+   "onenand read ${loadaddr} 28 40; " \
+   "bootm ${loadaddr}\0" \
+
+#define CONFIG_BOOTCOMMAND \
+   "if mmc rescan ${mmcdev}; then " \
+   "if run loadbootscript; then " \
+   "run bootscript; " \
+   "else " \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
+   "else run nandboot; " \
+   "fi; " \
+   "fi; " \
+   "else run nandboot; fi"
 
 #define CONFIG_AUTO_COMPLETE   1
 
-- 
1.7.0.4

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

[U-Boot] [PATCHv2 0/2] ARM: OMAP3: Revamp IGEP default configuration

2011-02-24 Thread Enric Balletbo i Serra 
Hi,

This is the second version of patch series to revamp the default configuration
for all IGEP boards. The purpose of these patches is use the boot script used
in others OMAP3-based boards.

Tested on IGEP v2 board and IGEP module.

* changes since version 1:
  * Fix nandboot: should be 'onenand read' instead of 'nand read'
  * Also revamp default configuration on IGEP module

Enric Balletbo i Serra (2):
  ARM: OMAP3: Revamp IGEP v2 default configuration
  ARM: OMAP3: Revamp IGEP module default configuration

 include/configs/igep0020.h |   57 
 include/configs/igep0030.h |   57 
 2 files changed, 104 insertions(+), 10 deletions(-)

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

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 12:08, sughosh ganu a écrit :
> hi Albert,
>
> On Thu, Feb 24, 2011 at 4:27 PM, Albert ARIBAUD  > wrote:
>
> Hi Sughosh,
>
> Le 24/02/2011 11:01, sughosh ganu a écrit :
>
> Can you please tell me what could have caused this change. I
> compiled
> u-boot for a powerpc board, and found that the file type in that
> case is
> 'ELF Executable'. Is there any specific reason why the file type has
> changed for ARM, as powerpc also supports relocation.
>
>
> You have already answered your own question: the move to relocatable
> executable caused the change you see.
>
>
> Yes, this is true, what i wanted to understand was the reason why the
> 'Type'  field is different for ARM now, compared to the u-boot elf image
> for powerpc. Not sure if i am missing something, but powerpc also
> supports relocation, so  what is the reason for the difference in the
> two image types. Prior to relocation, we used to get the file type as
> 'Executable', same as powerpc.

PPC and ARM have different architectures, different toolchains, 
different methods for relocation -- that explains the different ELF type.

> I suspect the utility freaks out because it thinks the ELF cannot be
> made into a binary like it would previously, but actually the binary
> generation process did not change when we refactored the relocation
> -- maybe the utility would work on our relocatable ELFs with just
> the check for ELF type bypassed.
>
> Yes, even i think that would be the case, but i guess that would call
> for changes in the utility. Perhaps someone from TI can look into this.

Isn't there some official support channel?

> -sughosh

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

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread sughosh ganu 
hi Albert,

On Thu, Feb 24, 2011 at 4:27 PM, Albert ARIBAUD wrote:

> Hi Sughosh,
>
> Le 24/02/2011 11:01, sughosh ganu a écrit :
>
> Can you please tell me what could have caused this change. I compiled
>> u-boot for a powerpc board, and found that the file type in that case is
>> 'ELF Executable'. Is there any specific reason why the file type has
>> changed for ARM, as powerpc also supports relocation.
>>
>
> You have already answered your own question: the move to relocatable
> executable caused the change you see.


Yes, this is true, what i wanted to understand was the reason why the
'Type'  field is different for ARM now, compared to the u-boot elf image for
powerpc. Not sure if i am missing something, but powerpc also supports
relocation, so  what is the reason for the difference in the two image
types. Prior to relocation, we used to get the file type as 'Executable',
same as powerpc.

I suspect the utility freaks out because it thinks the ELF cannot be made
> into a binary like it would previously, but actually the binary generation
> process did not change when we refactored the relocation -- maybe the
> utility would work on our relocatable ELFs with just the check for ELF type
> bypassed.
>

Yes, even i think that would be the case, but i guess that would call for
changes in the utility. Perhaps someone from TI can look into this.

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

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Stefano Babic 
On 02/24/2011 11:37 AM, Kumar Gala wrote:
> 
> On Feb 24, 2011, at 2:53 AM, Kumar Gala wrote:
> 
>> From: Priyanka Jain 
>>
>> - Timeout counter value is set as DTOCV bits in SYSCTL register
>>  For counter value set as x,
>>  Timeout period = (2^(13+x))/SD_CLOCK
>>
>> - As per 4.6.2.2 section of SD Card specification v2.00, host should
>>  cofigure timeout period value to minimum 250 msec.
>>
>> - SD_CLOCK = mmc->trans_speed
>>
>> - Calculating x based on
>>  250 msec = (2^(13+x))/mmc->trans_speed
>>
>> Signed-off-by: Priyanka Jain 
>> Signed-off-by: Andy Fleming 
>> Signed-off-by: Kumar Gala 
>> ---
>> drivers/mmc/fsl_esdhc.c |5 -
>> 1 files changed, 4 insertions(+), 1 deletions(-)
> 
> Stefano,
> 
> Can you test this on iMX to make sure we didnt break anything there.

Yes, I will test it and I will send my tested-by if everything is ok.

Stefano
-- 
=
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: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread Albert ARIBAUD 
Hi Sughosh,

Le 24/02/2011 11:01, sughosh ganu a écrit :
> hi Albert,
> I am facing an issue with generation of AIS signed binaries for
> hawkboard. The aisgen utility takes the u-boot elf file as input and
> generates a ais binary, which is the file format recognised by the
> hawkboard's RBL(rom bootloader). After the relocation support for ARM,
> the elf file generated has file type as 'DYN (shared object)'. With
> this, the aisgen tool rejects the file as not being an elf file.
>
> Can you please tell me what could have caused this change. I compiled
> u-boot for a powerpc board, and found that the file type in that case is
> 'ELF Executable'. Is there any specific reason why the file type has
> changed for ARM, as powerpc also supports relocation.

You have already answered your own question: the move to relocatable 
executable caused the change you see.

I suspect the utility freaks out because it thinks the ELF cannot be 
made into a binary like it would previously, but actually the binary 
generation process did not change when we refactored the relocation -- 
maybe the utility would work on our relocatable ELFs with just the check 
for ELF type bypassed.

In any case, you should see with the makers of the utility how it should 
be updated to handle -pie generated elf files.

> -sughosh

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

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Kumar Gala 

On Feb 24, 2011, at 2:53 AM, Kumar Gala wrote:

> From: Priyanka Jain 
> 
> - Timeout counter value is set as DTOCV bits in SYSCTL register
>  For counter value set as x,
>  Timeout period = (2^(13+x))/SD_CLOCK
> 
> - As per 4.6.2.2 section of SD Card specification v2.00, host should
>  cofigure timeout period value to minimum 250 msec.
> 
> - SD_CLOCK = mmc->trans_speed
> 
> - Calculating x based on
>  250 msec = (2^(13+x))/mmc->trans_speed
> 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Andy Fleming 
> Signed-off-by: Kumar Gala 
> ---
> drivers/mmc/fsl_esdhc.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)

Stefano,

Can you test this on iMX to make sure we didnt break anything there.

> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index c6de751..6f8a09d 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -210,7 +210,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
> mmc_data *data)
>   esdhc_write32(®s->blkattr, data->blocks << 16 | data->blocksize);
> 
>   /* Calculate the timeout period for data transactions */
> - timeout = fls(mmc->tran_speed/10) - 1;
> + /* Timeout period = (2^(13+timeout))/mmc->trans_speed
> +  * Timeout period should be minimum 250msec as per SD Card spec
> +  */
> + timeout = fls(mmc->tran_speed/4);
>   timeout -= 13;
> 
>   if (timeout > 14)
> -- 
> 1.7.2.3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] [ARM]: File type for u-boot elf file

2011-02-24 Thread sughosh ganu 
hi Albert,
I am facing an issue with generation of AIS signed binaries for hawkboard.
The aisgen utility takes the u-boot elf file as input and generates a ais
binary, which is the file format recognised by the hawkboard's RBL(rom
bootloader). After the relocation support for ARM, the elf file generated
has file type as 'DYN (shared object)'. With this, the aisgen tool rejects
the file as not being an elf file.

Can you please tell me what could have caused this change. I compiled u-boot
for a powerpc board, and found that the file type in that case is 'ELF
Executable'. Is there any specific reason why the file type has changed for
ARM, as powerpc also supports relocation.

sughosh@Hardy:/tmp/u-boot$
/home/sughosh/hawk/tools/arm-2009q3/bin/arm-none-linux-gnueabi-readelf -h
u-boot
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0xc108
  Start of program headers:  52 (bytes into file)
  Start of section headers:  488968 (bytes into file)
  Flags: 0x502, has entry point, Version5
EABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 2
  Size of section headers:   40 (bytes)
  Number of section headers: 24
  Section header string table index: 21

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

Re: [U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Wolfgang Denk 
Dear Kumar Gala,

In message <1298537614-20797-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> 
> - Timeout counter value is set as DTOCV bits in SYSCTL register
>   For counter value set as x,
>   Timeout period = (2^(13+x))/SD_CLOCK
> 
> - As per 4.6.2.2 section of SD Card specification v2.00, host should
>   cofigure timeout period value to minimum 250 msec.
> 
> - SD_CLOCK = mmc->trans_speed
> 
> - Calculating x based on
>   250 msec = (2^(13+x))/mmc->trans_speed

OK, here the theory is given...

> + /* Timeout period = (2^(13+timeout))/mmc->trans_speed
> +  * Timeout period should be minimum 250msec as per SD Card spec
> +  */
> + timeout = fls(mmc->tran_speed/4);
>   timeout -= 13;

But how does this translate intothis formula?  I think there must be
missing something.

Also, should there not be some checking for valid input data ranges?


Nitpick: incorrect multi-line comment style.

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: w...@denx.de
"There's always been Tower of Babel sort of  bickering  inside  Unix,
but  this  is the most extreme form ever. This means at least several
years of confusion." - Bill Gates, founder and chairman of Microsoft,
about the Open Systems Foundation
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Wolfgang Denk 
Dear Albert ARIBAUD,

In message <4d6611a7.5050...@free.fr> you wrote:
> 
> >>> In the U-Boot image itself, knowing the image size could be achieved in
> >>> ARM by using a general _end symbol that would be set after the last
> >>> image output section, so _end-_start would equal the image size.
> >>
> >> we have such a "_end" in u-boot.lds files.
> 
> I *knew* this name did not pop up in my mind without a reason. :)
> 
> Apologies for not having checked.
> 
> > I guess we need a __dynsym_end in all u-boot.lds files.
> 
> I'd rather go for "_end", which does not tie the solution to dynsym 
> being the last section in the image -- imagine for some reason we move 
> dynsym inside the image rather than at the end, end the image size will 
> be wrong again. With _end, and a suitable comment in the LD file... this 
> will be averted where-ever dynsym ends up.
> 
> After all, the bug you uncovered was due to using the wrong symbol, a 
> BSS related one rather than an image-related one, in the first place; so 
> let's try and learn from past mistakes.

I think the location of _end in the linker scripts needs to be changed
- so far it covers the maximum of dynsym and bss, but it should refer
to the end of dynsym only.

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: w...@denx.de
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fsl_esdhc: Correcting esdhc timeout counter calculation

2011-02-24 Thread Kumar Gala 
From: Priyanka Jain 

- Timeout counter value is set as DTOCV bits in SYSCTL register
  For counter value set as x,
  Timeout period = (2^(13+x))/SD_CLOCK

- As per 4.6.2.2 section of SD Card specification v2.00, host should
  cofigure timeout period value to minimum 250 msec.

- SD_CLOCK = mmc->trans_speed

- Calculating x based on
  250 msec = (2^(13+x))/mmc->trans_speed

Signed-off-by: Priyanka Jain 
Signed-off-by: Andy Fleming 
Signed-off-by: Kumar Gala 
---
 drivers/mmc/fsl_esdhc.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c6de751..6f8a09d 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -210,7 +210,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
esdhc_write32(®s->blkattr, data->blocks << 16 | data->blocksize);
 
/* Calculate the timeout period for data transactions */
-   timeout = fls(mmc->tran_speed/10) - 1;
+   /* Timeout period = (2^(13+timeout))/mmc->trans_speed
+* Timeout period should be minimum 250msec as per SD Card spec
+*/
+   timeout = fls(mmc->tran_speed/4);
timeout -= 13;
 
if (timeout > 14)
-- 
1.7.2.3

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

[U-Boot] Change drive strength of my LPDDR

2011-02-24 Thread Martin Sjölund 
Hi,

I am using a i.MX27 connected to a LPDDR from Micron (se link). I need to
lower the drive strength of the memory to half as described at the memory
datasheet on page 55 Extended Mode Register (
http://download.micron.com/pdf/datasheets/dram/mobile/512mb_ddr_mobile_sdram_t47m.pdf
)

In U-Boot in lowlevel_init.S (/board/logicpd/imx27lite/) there is a line

#define SDRAM_MODE_REGISTER_VAL 0x10

Which I assume is the value written to the Extended Mode Register. Honestly
I really do not know what value I should change the 0x10 to. Some how I
would like to think it would be 0x120 but I really could not say that is
correct. Do any of you have any idea I would be very grateful.

Kind Regards
Martin Sjölund
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] armv7: s5p: pwm driver support

2011-02-24 Thread Donghwa Lee 
This is common pwm driver of S5P.

Signed-off-by: Donghwa Lee 
Signed-off-by: Kyungmin Park 

---
 arch/arm/cpu/armv7/s5p-common/Makefile  |1 +
 arch/arm/cpu/armv7/s5p-common/pwm.c |  214 +++
 arch/arm/include/asm/arch-s5pc1xx/pwm.h |   14 ++
 arch/arm/include/asm/arch-s5pc2xx/pwm.h |   14 ++
 include/pwm.h   |   21 +++
 5 files changed, 264 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/s5p-common/pwm.c
 create mode 100644 include/pwm.h

diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile 
b/arch/arm/cpu/armv7/s5p-common/Makefile
index 922cd95..da5623d 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -28,6 +28,7 @@ LIB   = $(obj)libs5p-common.o
 COBJS-y+= cpu_info.o
 COBJS-y+= timer.o
 
+COBJS-$(CONFIG_PWM)+= pwm.o
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
 
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c 
b/arch/arm/cpu/armv7/s5p-common/pwm.c
new file mode 100644
index 000..eed2206
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -0,0 +1,214 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * Donghwa Lee 
+ *
+ * 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
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PRESCALER_0(8 - 1) /* prescaler of timer 0, 1 */
+#define PRESCALER_1(16 - 1)/* prescaler of timer 2, 3, 4 */
+#define MUX_DIV_1  0   /* 1/1 period */
+#define MUX_DIV_2  1   /* 1/2 period */
+#define MUX_DIV_4  2   /* 1/4 period */
+#define MUX_DIV_8  3   /* 1/8 period */
+#define MUX_DIV_16 4   /* 1/16 period */
+
+#define MUX_DIV_SHIFT(x)   ((x) * 4)
+
+#define TCON0_TIMER_SHIFT  0
+#define TCON_TIMER_SHIFT(x)(8 + ((x - 1) * 4))
+
+
+int pwm_enable(int pwm_id)
+{
+   const struct s5p_timer *pwm = (struct s5p_timer 
*)samsung_get_base_timer();
+   unsigned long tcon;
+
+   tcon = readl(&pwm->tcon);
+
+   if (pwm_id == 0)
+   tcon |= TCON0_START;
+   else
+   tcon |= TCON_START(pwm_id);
+   writel(tcon, &pwm->tcon);
+
+   return 0;
+}
+
+void pwm_disable(int pwm_id)
+{
+   const struct s5p_timer *pwm = (struct s5p_timer 
*)samsung_get_base_timer();
+   unsigned long tcon;
+
+   tcon = readl(&pwm->tcon);
+   if (pwm_id == 0)
+   tcon &= ~TCON0_START;
+   else
+   tcon &= ~TCON_START(pwm_id);
+
+   writel(tcon, &pwm->tcon);
+
+}
+
+static unsigned long pwm_calc_tin(int pwm_id, unsigned long freq)
+{
+   unsigned long tin_parent_rate;
+   unsigned int div;
+
+   tin_parent_rate = get_pwm_clk();
+
+   for (div = 2; div <= 16; div *= 2) {
+   if ((tin_parent_rate / (div << 16)) < freq)
+   return tin_parent_rate / div;
+   }
+
+   return tin_parent_rate / 16;
+}
+
+#define NS_IN_HZ (10UL)
+
+int pwm_config(int pwm_id, int duty_ns, int period_ns)
+{
+   const struct s5p_timer *pwm = (struct s5p_timer 
*)samsung_get_base_timer();
+   unsigned int offset;
+   unsigned long tin_rate;
+   unsigned long tin_ns;
+   unsigned long period;
+   unsigned long tcon;
+   unsigned long tcnt;
+   unsigned long timer_rate_hz;
+
+   long tcmp;
+
+   /* We currently avoid using 64bit arithmetic by using the
+* fact that anything faster than 1GHz is easily representable
+* by 32bits. */
+   if (period_ns > NS_IN_HZ || duty_ns > NS_IN_HZ)
+   return -ERANGE;
+
+   if (duty_ns > period_ns)
+   return -EINVAL;
+
+   period = NS_IN_HZ / period_ns;
+
+   /* Check to see if we are changing the clock rate of the PWM */
+   tin_rate = pwm_calc_tin(pwm_id, period);
+   timer_rate_hz = tin_rate;
+
+   tin_ns = NS_IN_HZ / tin_rate;
+   tcnt = period_ns / tin_ns;
+
+   /* Note, counters count down */
+   tcmp = duty_ns / tin_ns;
+   tcmp = tcnt - tcmp;
+
+

Re: [U-Boot] ARM: Incorrect ROM protection range?

2011-02-24 Thread Albert ARIBAUD 
Le 24/02/2011 08:40, Po-Yu Chuang a écrit :
> Hi Heiko,
>
> On Thu, Feb 24, 2011 at 3:33 PM, Heiko Schocher  wrote:
>> Albert ARIBAUD wrote:
>> The bin length is calculated in arch/arm/lib/board.c, but it seems
>> to me not correct ... :-(
>>
>> in board_init_f():
>>
>> gd->mon_len = _bss_end_ofs;
>>
>> that seems correct to me, but later in board_init_r()
>>
>> monitor_flash_len = _bss_start_ofs;
>>
>> which is used for example in ./drivers/mtd/cfi_flash.c for protecting
>> the flash sectors ... so this should be fixed.

Correct.

>>> In the U-Boot image itself, knowing the image size could be achieved in
>>> ARM by using a general _end symbol that would be set after the last
>>> image output section, so _end-_start would equal the image size.
>>
>> we have such a "_end" in u-boot.lds files.

I *knew* this name did not pop up in my mind without a reason. :)

Apologies for not having checked.

> I guess we need a __dynsym_end in all u-boot.lds files.

I'd rather go for "_end", which does not tie the solution to dynsym 
being the last section in the image -- imagine for some reason we move 
dynsym inside the image rather than at the end, end the image size will 
be wrong again. With _end, and a suitable comment in the LD file... this 
will be averted where-ever dynsym ends up.

After all, the bug you uncovered was due to using the wrong symbol, a 
BSS related one rather than an image-related one, in the first place; so 
let's try and learn from past mistakes.

> best regards,
> Po-Yu Chuang

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