Re: [U-Boot] [PATCH] Coding Style cleanup
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, December 19, 2011 9:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] Coding Style cleanup Dear Premi, Sanjeev, In message e28aafd00efaa646ae3df9b89cd24a8909b...@dbde01.ent.ti.com you wrote: @@ -563,6 +556,7 @@ extern unsigned long=20 get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; =09 \ bootm $loadaddr - $fdtaddr =20 + #define CONFIG_RAMBOOTCOMMAND=09 This appears to be a stray addition. ...which appears to be added by your mailer. I don;t see it in the patch. I was referring to the extra line added by the + sign. [quoting from original patch] @@ -563,6 +556,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; \ bootm $loadaddr - $fdtaddr + #define CONFIG_RAMBOOTCOMMAND \ setenv bootargs root=/dev/ram rw \ console=$consoledev,$baudrate $othbootargs; \ [/quote] ~sanjeev 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 When the ax entered the forest, the trees said, The handle is one of us! -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, December 19, 2011 4:41 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] Coding Style cleanup Fix trailing white space, indentation by spaces instead of TABs, excessive blank lines, trailing blank lines. Signed-off-by: Wolfgang Denk w...@denx.de [snip]...[snip] @@ -563,6 +556,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; \ bootm $loadaddr - $fdtaddr + #define CONFIG_RAMBOOTCOMMAND This appears to be a stray addition. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Thierry Reding
Sent: Thursday, November 17, 2011 12:35 PM
To: u-boot@lists.denx.de
Cc: Tom Warren
Subject: [U-Boot] [PATCH] disk: part_efi: Fix parameters
passed to is_gpt_valid().
Something apparently went wrong when the patch in commit deb5ca8 was
applied. Commit f75dd58 changed the type of gpt_head to be a
pointer and
correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
applied, the gpt_head was again reverted to (gpt_head), which was the
state before deb5ca8.
This commit fixes the passing of gpt_head into is_gpt_valid().
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
disk/part_efi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..ddf80a7 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return;
}
@@ -169,7 +169,7 @@ int
get_partition_info_efi(block_dev_desc_t * dev_desc, int part,
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return -1;
}
--
I had already posted 2 revisions of this patch:
http://lists.denx.de/pipermail/u-boot/2011-November/109791.html
http://lists.denx.de/pipermail/u-boot/2011-November/109899.html
And they are included in this pull request:
http://lists.denx.de/pipermail/u-boot/2011-November/110017.html
1.7.7.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
Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 15, 2011 12:15 PM To: Tom Rini Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] Sent: Monday, November 14, 2011 9:05 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions On Mon, Nov 14, 2011 at 8:19 AM, Sanjeev Premi pr...@ti.com wrote: After enabling CONFIG_EFI_PARTITION, following errors were noticed. part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclar ed (first use in this function) part_efi.c:384:18: note: each undeclared identifier is reporte d only once for each function it appears in make[1]: *** [part_efi.o] Error 1 make[1]: Leaving directory `/db/psp_git/users/a0756819/u-boot/ disk' make: *** [disk/libdisk.o] Error 2 Is there a reason EFI doesn't use ARCH_DMA_MINALIGN ? I have no idea, but use of CONFIG_SYS_CACHELINE_SIZE in part_efi.c was introduced in: commit f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4 Author: Anton staaf robot...@chromium.org Date: Wed Oct 12 13:56:04 2011 + ~sanjeev After a bit more digging, I see that ARCH_DMA_MINALIGN is set to 64 OR CONFIG_SYS_CACHELINE_SIZE (if defined) - in this commit: commit 3b75eeef620c018c312e8149246cd330cc27d16d Author: Anton Staaf robot...@chromium.org Date: Mon Oct 17 16:46:03 2011 -0700 arm: cache: define ARCH_DMA_MINALIGN for DMA buffer alignment So, CONFIG_SYS_CACHELINE_SIZE shouldn't really be used in the file. I will submit fresh set soon. ~sanjeev -- Tom ___ 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
Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions
-Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] Sent: Monday, November 14, 2011 9:05 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions On Mon, Nov 14, 2011 at 8:19 AM, Sanjeev Premi pr...@ti.com wrote: After enabling CONFIG_EFI_PARTITION, following errors were noticed. part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclar ed (first use in this function) part_efi.c:384:18: note: each undeclared identifier is reporte d only once for each function it appears in make[1]: *** [part_efi.o] Error 1 make[1]: Leaving directory `/db/psp_git/users/a0756819/u-boot/ disk' make: *** [disk/libdisk.o] Error 2 Is there a reason EFI doesn't use ARCH_DMA_MINALIGN ? I have no idea, but use of CONFIG_SYS_CACHELINE_SIZE in part_efi.c was introduced in: commit f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4 Author: Anton staaf robot...@chromium.org Date: Wed Oct 12 13:56:04 2011 + ~sanjeev -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BeagleBoard: config: Switch to ttyO2
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rini, Tom Sent: Thursday, November 10, 2011 1:01 AM To: u-boot@lists.denx.de Cc: Dirk Behme Subject: [U-Boot] [PATCH] BeagleBoard: config: Switch to ttyO2 This is needed to support the latest kernel versions. Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Sandeep Paulraj s-paul...@ti.com Cc: Dirk Behme dirk.be...@gmail.com Signed-off-by: Tom Rini tr...@ti.com --- include/configs/omap3_beagle.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index ebb572e..15e40c5 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -215,7 +215,7 @@ rdaddr=0x8100\0 \ usbtty=cdc_acm\0 \ bootfile=uImage.beagle\0 \ - console=ttyS2,115200n8\0 \ + console=tty02,115200n8\0 \ mpurate=auto\0 \ buddy=none \ optargs=\0 \ There seems to be too many versions of this patch already! http://patchwork.ozlabs.org/patch/83540/ http://patchwork.ozlabs.org/patch/92358/ http://patchwork.ozlabs.org/patch/110133/ ~sanjeev -- 1.7.0.4 ___ 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
Re: [U-Boot] [PATCH] Reduce build times
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Wednesday, November 02, 2011 12:24 PM To: u-boot@lists.denx.de Cc: Graeme Russ; Kumar Gala; Albert Aribaud; Andy Fleming Subject: [U-Boot] [PATCH] Reduce build times U-Boot Makefiles contain a number of tests for compiler features etc. which so far are executed again and again. On some architectures (especially ARM) this results in a large number of calls to gcc. This patch makes sure to run such tests only once, thus largely reducing the number of execve system calls. Example: number of execve system calls for building the P2020DS (Power Architecture) and qong (ARM) boards, measured as: - strace -f -e trace=execve -o /tmp/foo ./MAKEALL board - grep execve /tmp/foo | wc -l Before: After: Reduction: == P2020DS 20555 15205 -26% qong 31692 14490 -54% As a result, built times are significantly reduced, typically by 30...50%. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala ga...@kernel.crashing.org Cc: Albert Aribaud albert.arib...@free.fr cc: Graeme Russ graeme.r...@gmail.com cc: Mike Frysinger vap...@gentoo.org --- Results for OMAP3EVM. (Tried 5 times just to be sure as I see 50% reduction.) Before After -- -- real109.03 49.78 user 71.43 29.06 sys 26.83 7.66 Compiled u-boot works fine on the board as well. Tested-by: Sanjeev Premi pr...@ti.com [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rini, Tom
Sent: Thursday, October 27, 2011 2:44 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
This introduces 200MHz Micron parts timing information based
on x-loader
and re-organizes the file slightly for grouping. The memory
init logic
is also based on what x-loader does in these cases. Note that while
previously u-boot would be flashed in with SW ECC in this case it now
must be flashed with HW ECC.
Beagleboard rev C5, xM rev A:
Tested-by: Tom Rini tr...@ti.com
Beagleboard xM rev C:
Tested-by: Matt Ranostay mranos...@gmail.com
Beagleboard rev B7, C2, xM rev B:
Tested-by: Matt Porter mpor...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
[snip]...[snip]
+#ifdef CONFIG_SPL_BUILD
+
+#define MICRON_DDR 0
+#define NUMONYX_MCP 1
+#define MICRON_MCP 2
+
+#define NAND_CMD_STATUS 0x70
+#define NAND_CMD_READID 0x90
+#define NAND_CMD_RESET 0xff
+
+#define GPMC_NAND_COMMAND_0 (OMAP34XX_GPMC_BASE+0x7C)
+#define GPMC_NAND_ADDRESS_0 (OMAP34XX_GPMC_BASE+0x80)
+#define GPMC_NAND_DATA_0 (OMAP34XX_GPMC_BASE+0x84)
+
+#define WRITE_NAND_COMMAND(d, adr) \
+ do {*(volatile u16 *)GPMC_NAND_COMMAND_0 = d;} while(0)
+#define WRITE_NAND_ADDRESS(d, adr) \
+ do {*(volatile u16 *)GPMC_NAND_ADDRESS_0 = d;} while(0)
+#define READ_NAND(adr) (*(volatile u16 *)GPMC_NAND_DATA_0)
+
I am not yet familiar with SPL code, but I would suggest using
struct gpmc instead of hardcoded offsets above.
[snip]...[snip]
+
+#define GPMC_CONFIG_CS0_CONFIG1 0x6E60
+#define GPMC_CONFIG_CS0_CONFIG2 0x6E64
+#define GPMC_CONFIG_CS0_CONFIG3 0x6E68
+#define GPMC_CONFIG_CS0_CONFIG4 0x6E6C
+#define GPMC_CONFIG_CS0_CONFIG5 0x6E70
+#define GPMC_CONFIG_CS0_CONFIG6 0x6E74
+#define GPMC_CONFIG_CS0_CONFIG7 0x6E78
+#define OMAP34XX_GPMC_CS0_SIZE 0x8
Suggest using struct gpmc_cs instead of defining offsets.
[snip]...[snip]
+
+static int identify_xm_ddr(void)
+{
+ int mfr, id;
+
+ /* Make sure that we have setup GPMC for NAND correctly. */
+ writel(M_NAND_GPMC_CONFIG1, GPMC_CONFIG_CS0_CONFIG1);
+ writel(M_NAND_GPMC_CONFIG2, GPMC_CONFIG_CS0_CONFIG2);
+ writel(M_NAND_GPMC_CONFIG3, GPMC_CONFIG_CS0_CONFIG3);
+ writel(M_NAND_GPMC_CONFIG4, GPMC_CONFIG_CS0_CONFIG4);
+ writel(M_NAND_GPMC_CONFIG5, GPMC_CONFIG_CS0_CONFIG5);
+ writel(M_NAND_GPMC_CONFIG6, GPMC_CONFIG_CS0_CONFIG6);
+
+ /* Enable the GPMC Mapping */
+ writelOMAP34XX_GPMC_CS0_SIZE 0xF) 8) |
+ ((NAND_BASE 24) 0x3F) |
+ (1 6)), (GPMC_CONFIG_CS0_CONFIG7));
Same comment as before. Looks like there may be few more places
where hardcoded addresses/ offsets are being used.
~sanjeev
[snip]...[snip]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Set environment variable 'ethaddr'
-Original Message-
From: Premi, Sanjeev
Sent: Friday, September 02, 2011 9:27 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH v2] omap3evm: Set environment variable 'ethaddr'
It is now responsibility of the board specific init
code to set the environment variable corresponding
to the MAC address.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Changes in v2:
- Ensure that environment variable is set iff
it wasn't already set earlier.
Tested on omap3evm at against latest master at:
bd061a5 : Merge branch 'master' of git://git.denx.de/u-boot-sh
To build successfully, make this substituion in board/ti/evm/evm.c:
-#include asm/arch/gpio.h
+#include asm/omap_gpio.h
This problem was addressed in separate RFC. Patches
will follow shortly. (Substituion is not real fix).
Sandeep,
Wanted to check the status of this patch.
I believe I have addressed all concerns in v2.
Also, with generic gpio patches merged in, the substitution mentioned
above is not necessary.
I just validated this patch on ti/master. It applies cleanly and works
fine.
~sanjeev
board/ti/evm/evm.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 30c1c57..ae3f713 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -216,7 +216,22 @@ int board_eth_init(bd_t *bis)
{
int rc = 0;
#ifdef CONFIG_SMC911X
+#define STR_ENV_ETHADDR ethaddr
+
+ struct eth_device *dev;
+ uchar eth_addr[6];
+
rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+
+ if (!eth_getenv_enetaddr(STR_ENV_ETHADDR, eth_addr)) {
+ dev = eth_get_dev_by_index(0);
+ if (dev) {
+ eth_setenv_enetaddr(STR_ENV_ETHADDR,
dev-enetaddr);
+ } else {
+ printf(omap3evm: Couldn't get eth device\n);
+ rc = -1;
+ }
+ }
#endif
return rc;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ARM:AM33XX: Add support for TI AM335X EVM
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Igor Grinberg Sent: Wednesday, October 12, 2011 1:24 PM To: Kumar Nath, Chandan Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 5/5] ARM:AM33XX: Add support for TI AM335X EVM Hi Chandan, On 10/11/11 15:51, Chandan Nath wrote: This patch adds basic support for booting the board. This patch adds support for the UART necessary to get to the u-boot prompt. Signed-off-by: Chandan Nath chandan.n...@ti.com --- Support for additional peripherals depends on this patchset. Will be posting them soon. Please, don't forget to specify the dependencies when you post the depending patch sets. Igor, The comment means that there are more patches in the pipeline that depend on this patchset. This patchset doesn't have any dependency. ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel
-Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] Sent: Tuesday, September 27, 2011 9:29 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel On Tue, Sep 27, 2011 at 8:00 AM, Sanjeev Premi pr...@ti.com wrote: In absence of this argument, Linux kernel doesn't boot. Even though many newer boards support 256M, default value has been set to 128M to ensure that default build can boot older EVM variants. Signed-off-by: Sanjeev Premi pr...@ti.com But you aren't addressing the fact you just limited everyone to 128M, which is not right. Please make this set the value to what u-boot detects the board to have at runtime at least. This patch changes the static environment string compiled on the host. These is the default value that gets the board booting up. The environment variable memsize can be overwritten to 256M by the boards that have more memory. So, there is no hard limit. ...which I believe is better than kernel failing to load on old boards; leaving some users clueless about failure. Detecting the actual memory size and then changing the environment variable can be a feature, but it isn't fool proof, because many applications esp on DM3730, use memory hole and would like their bootargs to be different. ~sanjeev -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mmc timeouts on omap3evm
Hi, I am currently building u-boot using u-boot-ti/next at f3340ee : arm, davinci, da8xx: add cpuinfo Reading kernel image from MMC leads to these timeout messages. reading uImage mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! mmc_send_cmd: timedout waiting for stat! 3082808 bytes read I wanted to check if this behavior is observed on other boards as well? OR, am I missing some configuration? I am using SANDISK 4GB (SDHC Class 4). ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Pass 'mem' argument to linux kernel
-Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Tuesday, September 27, 2011 5:35 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Pass 'mem' argument to linux kernel Sorry missed this mail earlier... On 09/27/11 14:21, Sanjeev Premi wrote: In absence of this argument, Linux kernel doesn't boot. Default value has been set to 128M to ensure that Linux kernel boots on older EVMs as well. This change affects all EVMs, unless they explicitly change/remove the memsize variable or change the *args variables. Today without this patch, all EVMs should anyway be broken :( ...but may be working as users may have their own bootargs with mem=XYZM in their bootargs. The patch only ensures that the kernel would boot if there was no saved environment e.g. when environment partition is erased. or when u-boot is flashed on new boards. Can't the get_ram_size() function be used for detecting the actual amount of RAM? and then the memory tag or FDT equivalent (if there is one) used to pass the memory size information? Yes something like this can be done, but that would mean string manipulation at run-time. Question is - when we should/ shouldn't do this manipulation. If user wants to explicitly pass only a portion of memory to Linux using environment variables, we shouldn't be manipulating the bootargs. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel
From: Tom Rini [tom.r...@gmail.com] Sent: Wednesday, September 28, 2011 12:59 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel On Tue, Sep 27, 2011 at 9:43 AM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] Sent: Tuesday, September 27, 2011 9:29 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv2] omap3evm: Pass 'mem' argument to linux kernel On Tue, Sep 27, 2011 at 8:00 AM, Sanjeev Premi pr...@ti.com wrote: In absence of this argument, Linux kernel doesn't boot. Even though many newer boards support 256M, default value has been set to 128M to ensure that default build can boot older EVM variants. Signed-off-by: Sanjeev Premi pr...@ti.com But you aren't addressing the fact you just limited everyone to 128M, which is not right. Please make this set the value to what u-boot detects the board to have at runtime at least. This patch changes the static environment string compiled on the host. These is the default value that gets the board booting up. The environment variable memsize can be overwritten to 256M by the boards that have more memory. So, there is no hard limit. ...which I believe is better than kernel failing to load on old boards; leaving some users clueless about failure. Detecting the actual memory size and then changing the environment variable can be a feature, but it isn't fool proof, because many applications esp on DM3730, use memory hole and would like their bootargs to be different. Thanks for explaining. Given that someone else objected to this on the same grounds against v1 please try and add that type of info to the email in the future. I did miss the mail from Igor, and responded to him later. The patch describes the reason for choosing 128M - which i considered sufficient. It didn't occur to me that changes to CONFIG_BOOTARGS could/ would be considered as hard limit - else I would have described. ~sanjeev -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Faster boot time
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of dtran11 Sent: Monday, September 26, 2011 1:33 AM To: u-boot@lists.denx.de Subject: [U-Boot] Faster boot time I am trying to make uboot boot as fast as possible for my omap3 Overo board. I add the below to my config header file. Does anyone see anything I can add to it to make the build smaller and faster? Thank you. #define CONFIG_FAST_BOOT #define CONFIG_FAST_BOOT_MMC //#define CONFIG_FAST_BOOT_NAND #ifdef CONFIG_FAST_BOOT #define CONFIG_SILENT_CONSOLE 1 #define CONFIG_ENV_IS_NOWHERE 1 #undef CONFIG_ENV_IS_IN_NAND #undef CONFIG_SYS_LONGHELP #undef CONFIG_AUTO_COMPLETE #undef CONFIG_SYS_HUSH_PARSER #undef CONFIG_REVISION_TAG #undef CONFIG_MD5 #undef CONFIG_SHA1 #undef CONFIG_BZIP2 #undef CONFIG_LZMA #undef CONFIG_CMD_BDI #undef CONFIG_CMD_BOOTD #undef CONFIG_CMD_CONSOLE #undef CONFIG_CMD_ECHO #undef CONFIG_CMD_EDITENV #undef CONFIG_CMD_FPGA #undef CONFIG_CMD_FLASH #undef CONFIG_CMD_IMI #undef CONFIG_CMD_IMLS #undef CONFIG_CMD_ITEST #undef CONFIG_CMD_LOADB #undef CONFIG_CMD_LOADS #undef CONFIG_CMD_MEMORY #undef CONFIG_CMD_MISC #undef CONFIG_CMD_NET #undef CONFIG_CMD_NFS #undef CONFIG_CMD_SETGETDCR #undef CONFIG_CMD_SOURCE #undef CONFIG_CMD_XIMG #undef CONFIG_CMD_EXT2 #undef CONFIG_CMD_JFFS2 #undef CONFIG_CMD_USB #undef CONFIG_NET_MULTI #undef CONFIG_SMC911X #undef CONFIG_OF_LIBFDT #undef CONFIG_FIT #undef CONFIG_EXTRA_ENV_SETTINGS #define CONFIG_EXTRA_ENV_SETTINGS \ verify=no\0 \ bootfile=uImage\0 #undef CONFIG_BOOTDELAY #define CONFIG_BOOTDELAY0 #ifdef CONFIG_FAST_BOOT_MMC #undef CONFIG_SYS_NAND_QUIET_TEST #undef CONFIG_NAND_OMAP_GPMC #undef CONFIG_CMD_NAND #undef CONFIG_BOOTCOMMAND #define CONFIG_BOOTCOMMAND \ mmc rescan 0; \ fatload mmc 0 0x8200 uImage; \ bootm 0x8200; #undef CONFIG_BOOTARGS #define CONFIG_BOOTARGS \ console=ttyO2,115200n8\ mpurate=600 \ quiet noinitrd\ root=/dev/mmcblk0p2 rw\ rootfstype=ext3 rootwait #else #undef CONFIG_OMAP3_MMC #undef CONFIG_CMD_MMC #undef CONFIG_CMD_FAT //#undef CONFIG_DOS_PARTITION #undef CONFIG_BOOTCOMMAND #define CONFIG_BOOTCOMMAND \ nand read 0x8200 28 40; \ bootm 0x8200; #undef CONFIG_BOOTARGS #define CONFIG_BOOTARGS \ console=ttyO2,115200n8\ mpurate=600 \ quiet noinitrd\ root=ubi0:rootfs ubi.mtd=4\ rootfstype=ubifs #endif // #ifdef CONFIG_FAST_BOOT_MMC #undef CONFIG_USB_OMAP3 #undef CONFIG_MUSB_HCD #undef CONFIG_USB_STORAGE #undef CONFIG_USB_KEYBOARD #undef CONFIG_SYS_USB_EVENT_POLL #undef CONFIG_PREBOOT #undef CONFIG_MUSB_UDC #undef CONFIG_USB_DEVICE #undef CONFIG_USB_TTY #endif // CONFIG_FAST_BOOT I haven't reviewed all the options in detail, but you can check this link where this topic is discussed in details. http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time BTW, I have few patches ready to post, but ran into issues when booting Linux on omap3evm on FRI - even without these patches. Will try to fix it, before sending the patches tomorrow. ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning
-Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Monday, September 12, 2011 12:06 PM To: U-Boot; Premi, Sanjeev; Paulraj, Sandeep Subject: Warning Sanjeev, Sandeep, I see a lot of this warning in many OMAP boards: - Configuring for omap4_sdp4430 board... gpio.c: In function 'omap_get_gpio_dataout': gpio.c:161: warning: assignment discards qualifiers from pointer target type - Commit 5c2684dbebe9df47ea0a1865ed94db7886ea5941, I assume, is what brought this in, but I cannot verify this right now, as I am in the middle of aMAKEALL arm. Can someone look up what causes this warning? [sp] I just started looking into this. Expect a response in next 30 mins. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning
-Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Monday, September 12, 2011 12:06 PM To: U-Boot; Premi, Sanjeev; Paulraj, Sandeep Subject: Warning Sanjeev, Sandeep, I see a lot of this warning in many OMAP boards: - Configuring for omap4_sdp4430 board... gpio.c: In function 'omap_get_gpio_dataout': gpio.c:161: warning: assignment discards qualifiers from pointer target type - Albert, Which branch are you seeing this warning on? I was able to build the u-boot successfully for omap4_sdp4430 using codesourcery 2011.03-41 and codesourcery2009q1-203 on the u-boot-arm/master at: 4f02fba : omap4: fix pad configuration settings for SDP and Panda 3e90493 : omap4: IO settings a5b6a6c : omap4: make SDRAM init work for ES1.0 silicon e5c06a0 : omap4: factor out common part from board config headers 9a18112 : omap: gpio: Adapt board files to use generic API d7605af : omap: gpio: generic changes after changing API 5b5c435 : omap: gpio: Use generic API c7a993f : led: remove camel casing of led identifiers globally Infact, the function omap_get_gpio_dataout shouldn't exist as it was replaced with generic gpio API in commit 5b5c435 listed above. Believeing that you were trying to build the u-boot master, I tried to check there, but always get stuck with different errors: premi # make omap4_sdp4430_config Configuring for omap4_sdp4430 board... premi # make bld-master.log make[1]: *** No rule to make target `/home/premi/u-boot/include/configs/omap4_common.h', needed by `hello_world.o'. Stop. make: *** [examples/standalone] Error 2 premi # make distclean premi # make omap3_evm_config Configuring for omap3_evm board... premi # make bld-master.log make[1]: *** No rule to make target `/home/premi/u-boot/include/configs/omap4_common.h', needed by `hello_world.o'. Stop. make: *** [examples/standalone] Error 2 Commit 5c2684dbebe9df47ea0a1865ed94db7886ea5941, I assume, is what brought this in, but I cannot verify this right now, as I am in the middle of aMAKEALL arm. Couldn't find this commit in my repo may be, because I am tracking only master. But wasn't able to find via gitweb either on: http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog ~sanjeev Can someone look up what causes this warning? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, September 12, 2011 2:42 PM
To: Albert ARIBAUD; U-Boot; Paulraj, Sandeep
Subject: Re: [U-Boot] Warning
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Monday, September 12, 2011 12:06 PM
To: U-Boot; Premi, Sanjeev; Paulraj, Sandeep
Subject: Warning
Sanjeev, Sandeep,
I see a lot of this warning in many OMAP boards:
-
Configuring for omap4_sdp4430 board...
gpio.c: In function 'omap_get_gpio_dataout':
gpio.c:161: warning: assignment discards qualifiers from
pointer target type
-
Albert,
Which branch are you seeing this warning on?
I was able to build the u-boot successfully for omap4_sdp4430 using
codesourcery 2011.03-41 and codesourcery2009q1-203 on the
u-boot-arm/master
at:
4f02fba : omap4: fix pad configuration settings for SDP and Panda
3e90493 : omap4: IO settings
a5b6a6c : omap4: make SDRAM init work for ES1.0 silicon
e5c06a0 : omap4: factor out common part from board config headers
9a18112 : omap: gpio: Adapt board files to use generic API
d7605af : omap: gpio: generic changes after changing API
5b5c435 : omap: gpio: Use generic API
c7a993f : led: remove camel casing of led identifiers globally
Infact, the function omap_get_gpio_dataout shouldn't exist as it
was replaced with generic gpio API in commit 5b5c435 listed above.
Believeing that you were trying to build the u-boot master, I tried
to check there, but always get stuck with different errors:
premi # make omap4_sdp4430_config
Configuring for omap4_sdp4430 board...
premi # make bld-master.log
make[1]: *** No rule to make target
`/home/premi/u-boot/include/configs/omap4_common.h', needed
by `hello_world.o'. Stop.
make: *** [examples/standalone] Error 2
premi # make distclean
premi # make omap3_evm_config
Configuring for omap3_evm board...
premi # make bld-master.log
make[1]: *** No rule to make target
`/home/premi/u-boot/include/configs/omap4_common.h', needed
by `hello_world.o'. Stop.
make: *** [examples/standalone] Error 2
It appears the .depend files are not getting cleaned by distclean.
When I deleted them manually, I was able to build for omap3_evm_config
but then faced similar problem when building for omap4_sdp4430_config.
~sanjeev
Here is the log from my work session:
premi # make bld-master.log
make[1]: *** No rule to make target
`/home/premi/u-boot/include/configs/omap4_common.h', needed by `hello_world.o'.
Stop.
make: *** [examples/standalone] Error 2
premi # make distclean
premi # make omap3_evm_config
Configuring for omap3_evm board...
premi #
premi # make bld-master.log
make[1]: *** No rule to make target
`/home/premi/u-boot/include/configs/omap4_common.h', needed by `hello_world.o'.
Stop.
make: *** [examples/standalone] Error 2
premi # make examples/standalone/hello_world.o
CORRECT make examples/standalone/hello_world.c (y|n|e)?no
arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__
KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000 -I/home/premi/u-boot/I
nclude -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/2009q1-2
03/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -DCONFIG_ARM -D__A
RM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-p
rototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o
examples/standalone/hello_world.o examples/standalone/hello_world.c -c
premi #
premi #
premi #
premi # make distclean
premi #
premi # pwd
/home/premi/u-boot
premi # make distclean
premi # find . -print | grep depend
./api/.depend
./board/ti/sdp4430/.depend
./common/.depend
./disk/.depend
./drivers/bios_emulator/.depend
./drivers/block/.depend
./drivers/dma/.depend
./drivers/fpga/.depend
./drivers/gpio/.depend
./drivers/hwmon/.depend
[... list of files trimmed here ...]
./spl/drivers/i2c/.depend
./spl/drivers/mmc/.depend
./spl/drivers/serial/.depend
./spl/fs/fat/.depend
./spl/lib/.depend
premi # find . -print | grep depend | xargs rm
CORRECT find . -print | grep depend | xargs arm (y|n|e)?no
premi # make omap3_evm_config
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for omap3_evm board...
premi # make bld-master.log
premi #
premi # make distclean
premi # make omap4_sdp4430_config
Configuring for omap4_sdp4430 board...
premi # make bld-master.log
make[1]: *** No rule to make target
`/home/premi/u-boot/include/asm/arch/omap3.h', needed by `hello_world.o'. Stop.
make: *** [examples/standalone] Error 2
premi # find . -print | grep depend | xargs rm
CORRECT find . -print | grep depend | xargs arm (y|n|e)?no
premi # make omap4_sdp4430_config
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for omap4_sdp4430
Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
-Original Message- From: Stefano Babic [mailto:sba...@denx.de] Sent: Wednesday, September 07, 2011 1:11 PM To: Albert ARIBAUD Cc: Premi, Sanjeev; u-boot@lists.denx.de; Dirk Behme; agnel.j...@gmail.com Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning On 09/07/2011 08:11 AM, Albert ARIBAUD wrote: (Cc:ing Dirk for the non-patch-related error) Hi Albert, Note however that there is an error, independent from this patch, in building this board with ELDK42 and CS 2011q1 : Configuring for omap3_beagle board... beagle.c:532: warning: initialization from incompatible pointer type led.c: In function '__led_toggle': led.c:62: warning: implicit declaration of function 'omap_get_gpio_dataout' board/ti/beagle/libbeagle.o: In function `__led_toggle': /home/uboot/src/u-boot-arm/board/ti/beagle/led.c:62: undefined reference to `omap_get_gpio_dataout' arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu eabi/binutils-2.17.90/bfd/elf32-arm.c:8886 arm-linux-ld: BFD (GNU Binutils) 2.17.90.20070806 assertion fail /opt/eldk/build/arm-2008-11-24/work/usr/src/denx/BUILD/crossto ol-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnu eabi/binutils-2.17.90/bfd/elf32-arm.c:9117 (foillows a linker segmentation error) Anyone can reproduce and tell what the issue is? I can reproduce it. IMHO this issue is introduced with the following commit: commit b8bc8973a1830bb92e7a9bf3356dc209afb2f4e8 Author: Joel A Fernandes agnel.j...@gmail.com Date: Thu Aug 11 23:16:53 2011 -0500 There is no omap_get_gpio_dataout() actually in u-boot, but it is called to get the value of the LED: state = omap_get_gpio_dataout(toggle_gpio); [sp] I reported the missing function few days ago: http://marc.info/?l=u-bootm=131522045310324w=2 ~sanjeev Even if we had this function, it sounds odd to read the status of a LED (or generally from a GPIO set to output), because we should already know which value we have written before. Instead of reading from hardware should we not save the state of the LED in a variable ? 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] [PATCH 0/3] omap: gpio: Use generic API (instead of custom)
-Original Message- From: Luca Ceresoli [mailto:luca.ceres...@comelit.it] Sent: Wednesday, September 07, 2011 2:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/3] omap: gpio: Use generic API (instead of custom) Hi Sanjeev, Sanjeev Premi wrote: The OMAP boards use a custom api for GPIO operations. While it works, it doesn't help when when we don't know existence of the customization. ... Changes since RFC[1]: 1) While the original RFC was based against the master of u-boot.git. This series is based against master of u-boot-arm.git This patchset does not apply on top of current -arm master: commit 1052ea04d60de953f8355eab0e39336974283304 Author: Sanjeev Premi pr...@ti.com Date: Mon Sep 5 00:25:53 2011 + omap3: beagle: Fix build warning With this message: Applying: omap: gpio: Use generic API error: patch failed: arch/arm/cpu/armv7/omap-common/gpio.c:151 error: arch/arm/cpu/armv7/omap-common/gpio.c: patch does not apply error: patch failed: arch/arm/include/asm/omap_gpio.h:49 error: arch/arm/include/asm/omap_gpio.h: patch does not apply Patch failed at 0001 omap: gpio: Use generic API I'm afraid think you need another rebase. When I rebased, arm/master was at: 58c583b : net: Check network device driver name Anyways, fresh rebase coming in next hour... ~sanjeev Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] omap: gpio: Use generic API (instead of custom)
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Wednesday, September 07, 2011 3:10 PM To: Luca Ceresoli Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/3] omap: gpio: Use generic API (instead of custom) -Original Message- From: Luca Ceresoli [mailto:luca.ceres...@comelit.it] Sent: Wednesday, September 07, 2011 2:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/3] omap: gpio: Use generic API (instead of custom) Hi Sanjeev, Sanjeev Premi wrote: The OMAP boards use a custom api for GPIO operations. While it works, it doesn't help when when we don't know existence of the customization. ... Changes since RFC[1]: 1) While the original RFC was based against the master of u-boot.git. This series is based against master of u-boot-arm.git This patchset does not apply on top of current -arm master: commit 1052ea04d60de953f8355eab0e39336974283304 Author: Sanjeev Premi pr...@ti.com Date: Mon Sep 5 00:25:53 2011 + omap3: beagle: Fix build warning With this message: Applying: omap: gpio: Use generic API error: patch failed: arch/arm/cpu/armv7/omap-common/gpio.c:151 error: arch/arm/cpu/armv7/omap-common/gpio.c: patch does not apply error: patch failed: arch/arm/include/asm/omap_gpio.h:49 error: arch/arm/include/asm/omap_gpio.h: patch does not apply Patch failed at 0001 omap: gpio: Use generic API I'm afraid think you need another rebase. When I rebased, arm/master was at: 58c583b : net: Check network device driver name Anyways, fresh rebase coming in next hour... [sp] Actually, I realized that PATCH 1 in the series depends upon: http://marc.info/?l=u-bootm=131515805732292w=2 I had mentioned 2 patches in the cover letter. Of the two, one is already included in u-boot-arm/master. This one is still not. Can you apply this patch and then try to apply this series? ~sanjeev ~sanjeev Luca ___ 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
Re: [U-Boot] [PATCH] OMAP: Add function to get state of a GPIO output
I don't remember seeing any errors/warnings after applying my patches... on all boards listed in the cover letter. ...except for SMSC95x - in case of Panda. Infact, once the patches are applied, this function shouldn't even exist. ~sanjeev From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] On Behalf Of Paulraj, Sandeep Sent: Tuesday, September 06, 2011 9:48 PM To: V, Aneesh Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] OMAP: Add function to get state of a GPIO output This patch added a build warning like this: gpio.c: In function 'omap_get_gpio_dataout': gpio.c:161: warning: assignment discards qualifiers from pointer target type The fix is this: We will have to co ordinate the best way to move forward on this. Sanjeev submitted a patch set to move to the generic GPIO framework. Regards, Sandeep ___ 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] omap3: gpio: build warnings and errors
Sandeep, While trying to build all omap3 boards before I could submit the patches corresponding to RFC for using generic gpio API, I came across few warnings and errors. I have already submitted a patch fixing a warning short while ago: http://marc.info/?l=u-bootm=131521839308281w=2 However, I couldn't find the definition of omap_get_gpio_dataout() used in board/ti/beagle/led.c. The change was introduced in: b8bc8973: led: Remove state-saving of led for... After much search, I did find a patch that contains the defintion of omap_get_gpio_dataout() submitted yesterday: http://marc.info/?l=u-bootm=131515805732292w=2 Can you pull this patch immediately (assuming it is correct)? ... for now, it will assume it right and update my patchset. ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Monday, September 05, 2011 5:06 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Heiko Schocher; Wolfgang Denk
Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
Hi Sanjeev,
Le 05/09/2011 12:25, Sanjeev Premi a écrit :
This patch fixes the warning dure to recent changes to the board
configuration:
cmd_i2c.o cmd_i2c.c -c
cmd_i2c.c:109:1: warning: missing braces around initializer
cmd_i2c.c:109:1: warning: (near initialization for
'i2c_no_probes[0]')
Signed-off-by: Sanjeev Premipr...@ti.com
Cc: Jason Kridnerjkrid...@beagleboard.org
---
Patch was compile tested against the latest u-boot-arm.git at:
58c583b : net: Check network device driver name
include/configs/omap3_beagle.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index 18c6deb..a891246 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -118,7 +118,7 @@
#define CONFIG_I2C_MULTI_BUS 1
/* Probe all devices */
-#define CONFIG_SYS_I2C_NOPROBES{0x0, 0x0}
+#define CONFIG_SYS_I2C_NOPROBES{{0x0, 0x0}}
/* USB */
#define CONFIG_MUSB_UDC 1
Won't all board configs which use CONFIG_SYS_I2C_NOPROBES suffer from
the same bug? I would hate to see an endless trickle of
individual board
config patches, and would much prefer a single patch to fix
all boards
[sp] Actually, not all boards suffer from this issue.
But yes, I can make a single patch and submit it
in next couple of hours.
in one go if you are willing to do it -- yes, it would touch
boards that
you cannot even test, but I'd say the risk is next to zero.
Wolfgang, Heiko, your opinion?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Monday, September 05, 2011 7:01 PM
To: Premi, Sanjeev
Cc: Albert ARIBAUD; u-boot@lists.denx.de; Wolfgang Denk
Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
Hello Sanjeev,
Premi, Sanjeev wrote:
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Monday, September 05, 2011 5:06 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Heiko Schocher; Wolfgang Denk
Subject: Re: [U-Boot] [PATCH] omap3: beagle: Fix build warning
[snip]...[snip]
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -118,7 +118,7 @@
#define CONFIG_I2C_MULTI_BUS1
/* Probe all devices */
-#define CONFIG_SYS_I2C_NOPROBES {0x0, 0x0}
+#define CONFIG_SYS_I2C_NOPROBES {{0x0, 0x0}}
/* USB */
#define CONFIG_MUSB_UDC 1
Won't all board configs which use CONFIG_SYS_I2C_NOPROBES
suffer from
the same bug? I would hate to see an endless trickle of
individual board
config patches, and would much prefer a single patch to fix
all boards
[sp] Actually, not all boards suffer from this issue.
But yes, I can make a single patch and submit it
in next couple of hours.
Isn;t this issue introduced just from commit
authorJason Kridner jkrid...@beagleboard.org
Sat, 23 Jul 2011 04:42:44 + (23:42 -0500)
committer Albert ARIBAUD albert.u.b...@aribaud.net
Sun, 4 Sep 2011 09:36:21 + (11:36 +0200)
commitf74fc4ae6d6257ecdbc0049f6aa2e96212207f05
so ~1day old ... Hmm, I think, this is just a single board bugfix,
as this warning only raises, if CONFIG_I2C_MULTI_BUS and
CONFIG_SYS_I2C_NOPROBES is defined ... as introduced for the beagle
board through above commit ... other boards should be clean, as I tend
to do a MAKEALL after applying patches from ML ... but if you find
[sp] Yes, you are right about the issue, and hence I posted it as
single patch against beagleboard only. The description includes
a bash script that I used to blindly extent the fix to other
boards.
I guess, MAKEALL succeeds because the appropriate config options
may not be enabled for the boards.
Will dig on a few cases (of the ones changed) as to why the build
succeeds.
time and can check this, it would be nice!
[sp] I only have a arm codesourcery toolchain installed. Would be able
to check only ARM boards (of the 31) impacted by the updated patch.
Can do by tomorrow...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c_no_probes: Fix initialization warnings
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Monday, September 05, 2011 7:13 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Albert ARIBAUD
Subject: Re: [U-Boot] [PATCH] i2c_no_probes: Fix
initialization warnings
Hello Sanjeev,
[snip]...[snip]
Compile tested for oma3_beagle only.
Compiling for example for the alpr board with your patch:
[hs@pollux u-boot]$ ./MAKEALL alpr
Configuring for alpr board...
cmd_i2c.c:115: warning: braces around scalar initializer
cmd_i2c.c:115: warning: (near initialization for 'i2c_no_probes[0]')
fpga.c:226: warning: initialization from incompatible pointer type
textdata bss dec hex filename
231746 18612 68328 318686 4dcde ./u-boot
- SUMMARY
Boards compiled: 1
Boards with warnings or errors: 1 ( alpr )
--
[hs@pollux u-boot]$
- so Sorry, NACK for this patch.
[sp] Didn't look at this reponse while I was responding to your
earlier mail.
One difference, I see notice between the warnings I got
while building for beagle and the one you see:
(beagle)
cmd_i2c.c:109:1: warning: missing braces around initializer
(alpr)
cmd_i2c.c:115: warning: braces around scalar initializer
The difference seems to be length of the array.
(beagle)
#define CONFIG_SYS_I2C_NOPROBES {{0x0, 0x0}}
(alpr)
#define CONFIG_SYS_I2C_NOPROBES {{0x69}}
So, temporarily, I changed the definition for beagle as
#define CONFIG_SYS_I2C_NOPROBES {{0x0}}
...but it succeeded.
I am using Codesourcery 2011.03-41. I will try using
an older toolchain as well. Only trying to find of the
original patch itself was right OR not.
~sanjeev
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr'
From: Wolfgang Denk [w...@denx.de] Sent: Saturday, September 03, 2011 3:37 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr' Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930257371...@dbde02.ent.ti.com you wrote: Your patch always and unconditionally overwrites any existing ethaddr settings. This is not acceptable. For the EVM, MAC address is always probed from the chip. Hence, I assumed it safe to set the ethaddr - without checking for env var. This is not what we do in U-Boot, so please fix that. It was unlikely that someone would be setting it - to different value. Unlikely? Not so. This is expected standard behaviour. Please don't try to invent a wheel (in a different shape). [sp] I agreed with your comments in the next para. Had only described my thoughts before creating this patch. You seem to have missed the v2 of the same patch where I believe I have taken care of this behavior: http://marc.info/?l=u-bootm=131497907619918w=2 Do let me know if this is better... ~sanjeev Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap: gpio: User generic (instead of custom) API
-Original Message- From: Luca Ceresoli [mailto:luca.ceres...@comelit.it] Sent: Thursday, September 01, 2011 10:19 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Paulraj, Sandeep; Igor Grinberg; Enric Balletbo i Serra; Sunil Kumar; Shashi Ranjan; Menon, Nishanth; Steve Sakoman Subject: Re: [RFC 0/3] omap: gpio: User generic (instead of custom) API Hi Sanjeev, Sanjeev Premi wrote: The OMAP boards use a custom api for GPIO operations. While it works, it doesn't help when when we don't know existence of the customization. I earlier encountered the problem when looking for GPIO related changes when submitting prev set of patches. Since the search for gpio_request() in omap sources returned empty, I had assumed that it isn't supported. This patchset attempts to adapt the current implementation to use generic API. Since, the changes impact all OMAP boards, and I wouldn't be able to test on all, I decided to submit changes as RFC. Unless any major issue is found, I will be able to submit as formal patch by end of this week. Tested and working on the dig297 board, on top of the master branch in the u-boot-ti repository. I also tried to merge your work on the u-boot-arm repo, but it conflicts with the GPIO work recently committed there. You might want to rebase and resubmit when the -ti repo will be in line with the -arm one. Thanks. I didn't check the -arm repo; had based all patches on the master @ git.denx.de/u-boot.git - assuming there won't been too many changes since recent pull requests. ~sanjeev (PS: Had to trim the cc: list to ensure message gets through...) Anyway, for the current version: Tested-by: Luca Ceresoli luca.ceres...@comelit.it Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr'
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, September 02, 2011 7:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr' Dear Sanjeev Premi, In message 1314967433-14199-1-git-send-email-pr...@ti.com you wrote: It is now responsibility of the board specific init code to set the environment variable corresponding to the MAC address. Signed-off-by: Sanjeev Premi pr...@ti.com This looks all wrong to me. In U-Boot, the ethaddr environment variable is normally the primary storage for the MAC address. Only when this variable is not set, other potential storage locations may be referenced to initialize this value. Your patch always and unconditionally overwrites any existing ethaddr settings. This is not acceptable. For the EVM, MAC address is always probed from the chip. Hence, I assumed it safe to set the ethaddr - without checking for env var. It was unlikely that someone would be setting it - to different value. But, I see your point that I should be checking for existence of a valid ethaddr before setting/overwriting it. ~sanjeev 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 Build a system that even a fool can use and only a fool will want to use it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap: gpio: User generic (instead of custom) API
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, August 31, 2011 1:23 AM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev; Paulraj, Sandeep; Igor Grinberg; Luca
Ceresoli; Enric Balletbo i Serra; Sunil Kumar; Shashi Ranjan;
Menon, Nishanth; Steve Sakoman
Subject: [RFC 0/3] omap: gpio: User generic (instead of custom) API
The OMAP boards use a custom api for GPIO operations. While
it works, it doesn't help when when we don't know existence
of the customization.
I earlier encountered the problem when looking for GPIO
related changes when submitting prev set of patches. Since
the search for gpio_request() in omap sources returned empty,
I had assumed that it isn't supported.
This patchset attempts to adapt the current implementation
to use generic API.
Since, the changes impact all OMAP boards, and I wouldn't be
able to test on all, I decided to submit changes as RFC.
Unless any major issue is found, I will be able to submit
as formal patch by end of this week.
Following bash script was used to replace all occurences of
the custom API with generic equivalent. After the changes, I
have compile tested the OMAP3EVM only. Will be able to test
changes only by FRI.
#!/bin/bash
list=search.lst
[ -f ${list} ] \rm -rf ${list}
grep -l -R omap_.*_gpio . ${list}
sed -i '/\.sh$/d'${list}
sed -i '/\.o$/d' ${list}
sed -i '/\.orig$/d' ${list}
sed -i '/\.rej$/d' ${list}
sed -i '/\.git/d'${list}
sed -i '/patch/d'${list}
sed -i '/diff/d' ${list}
sed -i '/save/d' ${list}
for f in `cat ${list}` ;
do
echo Fixing $f...
sed -r -i
's/omap_request_gpio\s*\((\w+)\)/gpio_request(\1, )/g' $f
sed -r -i 's/omap_free_gpio/gpio_free/g' $f
sed -r -i
's/omap_set_gpio_direction\s*\((\w+),\s*1\)/gpio_direction_inp
ut(\1)/g' $f
sed -r -i
's/omap_set_gpio_direction\s*\((\w+),\s*0\)/gpio_direction_out
put(\1)/g' $f
sed -r -i 's/omap_set_gpio_dataout/gpio_set_value/g' $f
sed -r -i 's/omap_get_gpio_datain/gpio_get_value/g' $f
done
Sanjeev Premi (3):
omap: gpio: Use generic API
omap: gpio: generic changes after changing API
omap: gpio: Adapt board files to use generic API
arch/arm/cpu/armv7/omap-common/gpio.c | 74
+++-
arch/arm/cpu/armv7/omap4/clocks.c |4 +-
arch/arm/include/asm/arch-omap3/gpio.h | 19
arch/arm/include/asm/omap_gpio.h | 13 --
board/cm_t35/leds.c|4 +-
board/comelit/dig297/dig297.c | 10 ++--
board/isee/igep0020/igep0020.c | 10 ++--
board/logicpd/zoom2/debug_board.c |8 ++--
board/logicpd/zoom2/led.c | 36
board/logicpd/zoom2/zoom2.c|8 ++--
board/overo/overo.c| 52 +++---
board/ti/beagle/beagle.c | 34 +++---
board/ti/beagle/led.c | 12 +++---
board/ti/evm/evm.c | 12 +++---
doc/README.omap3 | 20
15 files changed, 177 insertions(+), 139 deletions(-)
create mode 100644 arch/arm/include/asm/arch-omap3/gpio.h
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Luca Ceresoli luca.ceres...@comelit.it
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Sunil Kumar sunilsain...@gmail.com
Cc: Shashi Ranjan shashiranjanmc...@gmail.com
Cc: Nishanth Menon n...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Tested working on the OMAP3EVM.
[bootlog]
U-Boot 2011.06-00396-gfa7a454 (Sep 02 2011 - 10:36:54)
OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 EVM board + LPDDR/NAND
I2C: ready
DRAM: 384 MiB
NAND: 512 MiB
NAND read from offset 26 failed -74
*** Warning - readenv() failed, using default environment
In:serial
Out: serial
Err: serial
Read back SMSC id 0x9220
Die ID #37429ff8015f02690c020022
Net: smc911x-0Warning: failed to set MAC address
Hit any key to stop autoboot: 0
OMAP3_EVM #
[/bootlog]
I was concerned that 2 failures during boot were due to the changes
in this patch set, but foud that they exist on the mainline as well.
Details:
At this commit, omap3_evm_config fails to build:
commit bd061a5214e60c9d1bb24393933323bd1a2dae19
Merge: 98e99e5 fe0ddff
Author: Wolfgang Denk w...@denx.de
Date: Fri Aug 26 15:55:03 2011 +0200
Error is:
make[1]: Entering directory `/home/premi/u-boot/board/ti/evm'
evm.c:36:32: fatal error: asm/arch/omap_gpio.h: No such file or directory
compilation terminated.
This temporary patch patch was required to fix the build issue on the
master branch:
premi # git diff
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 30c1c57..4160cdd 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -33,7 +33,7 @@
#include asm
Re: [U-Boot] [PATCH 3/3] omap: gpio: Adapt board files to use generic API
-Original Message- From: Premi, Sanjeev Sent: Wednesday, August 31, 2011 1:23 AM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Paulraj, Sandeep; Igor Grinberg; Luca Ceresoli; Enric Balletbo i Serra; Sunil Kumar; Shashi Ranjan; Menon, Nishanth; Steve Sakoman Subject: [PATCH 3/3] omap: gpio: Adapt board files to use generic API Sorry, the subject should have read RFC instead of PATCH. ~sanjeev [...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] OMAP3: Remove legacy mmc driver
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rini, Tom Sent: Tuesday, August 23, 2011 3:44 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH 9/9] OMAP3: Remove legacy mmc driver Now that all platforms have been migrated to the new MMC driver, remove the old one. Signed-off-by: Tom Rini tr...@ti.com --- drivers/mmc/Makefile|1 - drivers/mmc/omap3_mmc.c | 570 --- drivers/mmc/omap3_mmc.h | 233 --- 3 files changed, 0 insertions(+), 804 deletions(-) delete mode 100644 drivers/mmc/omap3_mmc.c delete mode 100644 drivers/mmc/omap3_mmc.h Similar patch was posted earlier in the month: http://marc.info/?l=u-bootm=131220851719468w=2 You may still want to keep the legacy mmc driver. Should help the new boards during early development. ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Monday, June 27, 2011 12:17 PM To: Premi, Sanjeev Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board On 06/27/11 08:06, Premi, Sanjeev wrote: -Original Message- From: Premi, Sanjeev Sent: Thursday, June 23, 2011 4:48 PM To: Premi, Sanjeev; Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, June 23, 2011 4:43 PM To: Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Thursday, June 23, 2011 2:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board Hi Sanjeev, On 06/22/11 22:24, Sanjeev Premi wrote: From: Sriramakrishnan s...@ti.com The GPIO pin used for resetting the external LAN chip has changed for Rev.G board. Signed-off-by: Sriramakrishnan s...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) [snip]...[snip] + /* Send a pulse on the GPIO pin */ + writel(pin, gpio_base-setdataout); udelay(1); - writel(GPIO0, gpio3_base-cleardataout); + writel(pin, gpio_base-cleardataout); udelay(1); - writel(GPIO0, gpio3_base-setdataout); + writel(pin, gpio_base-setdataout); Why keep messing with the gpio registers? Why not use gpio framework? Though it is omap specific, but it will be much cleaner then the above. [sp] I guess the intent was to keep code similar. But yes, gpio framework can be used. [sp] Sorry, mail went earlier than I wanted :( The only issue is that I couln't see gpio framework for omap. Let me dig further... [sp] Implementing GPIO for OMAP would be a long task. It should be done for long term; but is it necessary pre-condition for the patch? There is no need to implement GPIO for OMAP. It is already there, you just need to use it instead of writing directly to the GPIO registers. You can find all the implementation in: arch/arm/cpu/armv7/omap3/gpio.c and the header is: arch/arm/include/asm/arch-omap3/gpio.h [sp] No wonder, I couldn't find it in drivers/gpio. (Didn't occur that it could be in ARCH specific dir) Will rebase and send an updated patch soon. ~sanjeev All you need is to include the header, request the appropriate gpio, send the pulse and maybe (if you don't need it anymore) free that gpio. This is not hard or long at all. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message- From: Premi, Sanjeev Sent: Thursday, June 23, 2011 4:48 PM To: Premi, Sanjeev; Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, June 23, 2011 4:43 PM To: Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Thursday, June 23, 2011 2:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board Hi Sanjeev, On 06/22/11 22:24, Sanjeev Premi wrote: From: Sriramakrishnan s...@ti.com The GPIO pin used for resetting the external LAN chip has changed for Rev.G board. Signed-off-by: Sriramakrishnan s...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) [snip]...[snip] + /* Send a pulse on the GPIO pin */ + writel(pin, gpio_base-setdataout); udelay(1); - writel(GPIO0, gpio3_base-cleardataout); + writel(pin, gpio_base-cleardataout); udelay(1); - writel(GPIO0, gpio3_base-setdataout); + writel(pin, gpio_base-setdataout); Why keep messing with the gpio registers? Why not use gpio framework? Though it is omap specific, but it will be much cleaner then the above. [sp] I guess the intent was to keep code similar. But yes, gpio framework can be used. [sp] Sorry, mail went earlier than I wanted :( The only issue is that I couln't see gpio framework for omap. Let me dig further... [sp] Implementing GPIO for OMAP would be a long task. It should be done for long term; but is it necessary pre-condition for the patch? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
~sanjeev
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Thursday, June 23, 2011 4:43 PM
To: Igor Grinberg
Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
[sp] Sorry, mail went earlier than I wanted :(
The only issue is that I couln't see gpio framework for omap.
Let me dig further...
~sanjeev
--
Regards,
Igor.
___
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
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Graeme Russ Sent: Monday, May 16, 2011 11:54 AM To: Wolfgang Denk Cc: U-Boot Mailing List; Simon Schwarz Subject: Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, [snip]...[snip] Well, the timing parser, as you callit, can be written in 10 lines or less of your scripting language of choice. See for example here for a solution in expect/tcl: ftp://ftp.denx.de/pub/tools/time_log We've been using this for about 10 years by now (see for example this 7 year old boot time analysis: http://www.denx.de/wiki/DULG/AN2004_11_BootTimeOptimization). As we can trivially use regular expressions, the effort to implement a timing parser can be ignored. And it is independet of what sort of boot device we are using. Fine if your running Linux - What if the only tool tyou have is Hyperterminal? [sp] I have personally found Realterm quite good specifically for for attaching timing info to the prints received. It is available at: http://realterm.sourceforge.net/ For measurement, I send the output directly to a log file - not displayed on the screen. BTW, Teraterm is my choice for regular use. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dirk Behme Sent: Friday, December 17, 2010 4:10 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions [snip]...[snip] GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot I would really like to nail this down to a specific tool / version. Does this help? Any comments on this? If we would come to a conclusion, soon, I'd like to get a fix integrated for v2010.12. [sp] I had to be away from work for most of this month to attend a personal emergency. Haven't yet followed on this/ related threads to check if the issue has really been taken care of. Will spend next few days to get current on it... ~sanjeev Thanks Dirk ___ 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
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:21 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Wolfgang, Le 02/12/2010 08:34, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf743e6.60...@free.fr you wrote: Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation. Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init. This should be safe. Alright. You could try out what happens if you make get_omap3_evm_rev() static... No change: the warning remains, and so do the two segments. Maybe I should subscribe the binutils list and ask there. Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN. One of the things I did to move it away from .bss BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. Albert, I have already done this - may not be exactly same. while trying to debug linker script problem; did not want to deviate from the current problem so it is in my working code. ~sanjeev 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] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:30 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Wolfgang Denk Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Le 01/12/2010 22:39, Albert ARIBAUD a écrit : This one is a conundrum. Using 2010q1, building omap3_evm causes a linker warning arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps previous sections while building omap3_beagle does not cause any linker warning. Both boards use the same armv7 u-boot.lds and have a .bss which is way bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and .bss, but one gets the warning and one does not. The one difference a readelf shows is that for beagle, there is only one segment: 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym While for evm there is 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym Note that .bss has appeared in segment 00 for evm, whereas it was absent for beagle, and that .dynsym was rejected to a second segment -- why? I don't know. Note: I've tried with putting input sections .rel.dyn and .dynsym into a single output section .rel.dyn: this makes the second segment disappear, but for evm the warning remains and .bss remains in the segment. I have a tiny clue. Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. If this BSS variable is used before relocation (I haven't checked this), then anyway it'll have to move; in that case I'll keep an eye on this linker warning and try to sort it out if I get time. I did explain yesterday that variable is not used in relocation. If you notice the code snippet I sent yesterday, I had removed every assignment to the variable. And 2009q1 was still not happy! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 2:12 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Sanjeev, Le 02/12/2010 09:30, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is. Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Also noticed a difference between the changes I made yesterday; and your mail - maintaining 'u8' vs. 'int' for the omap3_evm_revision. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:09 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you wrote: Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Could you ***please*** be a bit more precise? What EXACTLY was that sort related change? Do you still need to remove the $(sort) call for the LIBS? That should NOT be done. Wolfgang, I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help. ~sanjeev 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 You can't evaluate a man by logic alone. -- McCoy, 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] omap3evm: Clean-up EVM detection code.
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code. Dear Sanjeev Premi, In message 1291288812-12653-1-git-send-email-pr...@ti.com you wrote: This patch does following changes: * Change the type (u8 - int) for omap3_evm_version. * Introduce an 'undefined' board revision for init value. * Use of #define instead of magic numbers Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 39 +++ board/ti/evm/evm.h | 17 +++-- 2 files changed, 30 insertions(+), 26 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 09d14f7..8d9ce73 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -37,36 +37,43 @@ #include asm/mach-types.h #include evm.h -static u8 omap3_evm_version; +static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF; ... +#define OMAP3EVM_BOARD_UNDEF -1 /* EVM revision not detected */ Sorry, but I will not accept this patch. The only purpose of this initialization with a non-zero value is to paper over a problem. As a result, the problem will be left unsolved, so it bites us again elsewhere, and we increase the memory footprint of the U-Boot image without need. At least I haven't deserted the problem; but the patch will help some one to test beyond the basic boot and see if there is any other impact on the functionality. The board has been broken for many weeks. As we see problem with sort($LIBS); there could be more issues that are yet to be discovered. ~sanjeev NAK. 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 You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 30, 2010 7:56 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain [snip]...[snip] I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? No, I'm using ELDk 4.2 [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the Codesourcery Lite edition. There is no difference in the observations between 2009q3 and 2010q1. [snip]...[snip] There were some good patches posted recently esp the bss_debug tool and fix for ARM relocation from Andreas. Applied them in order to get more information. In addition, added print indicating the function being called in for (init_funcptr= ) loop within board_init_f(). Also added a print in the function omap3_evm_get_revision() just to see if it ever gets called in due to incorrect sequencing. I could confirm that functions in init_sequence[] are called and omap3_evm_get_revision() is not called in this sequence. When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. 2) The size of .rodata has increased. (Why? not yet spent time on?) Sending the patch in next few mins: ~sanjeev (Comparison: before and after) 753c753 .rodata 0x80035578 0x9f38 --- .rodata 0x80035578 0x9f46 757c757 .rodata0x8003571c 0xbc arch/arm/lib/libarm.o --- === [contents deleted] === .u_boot_cmd 0x80041aac 0x658 --- .u_boot_cmd 0x80041abc 0x658 === [contents deleted] === 967,968c967,973 .rel.dyn0x80042104 0x5af0 0x80042104__rel_dyn_start = . --- .dynsym 0x80042114 0xa0 0x80042114__dynsym_start = . *(.dynsym) .dynsym0x80042114 0xa0 arch/arm/cpu/armv7/start.o .rel.dyn0x800421b4 0x5af0 0x800421b4__rel_dyn_start = . === [contents deleted] === 984,985c986,987 .bss0x800421040x31ba8 0x80042104__bss_start = . --- .bss0x800421b40x31bb4 load address 0x80047ca4 0x80073d68__bss_start = . === [contents deleted] === .dynbss 0x80073cac0x0 --- .dynbss 0x80073d680x0 load address 0x80079858 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Wednesday, December 01, 2010 8:33 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Wolfgang Denk Subject: Re: [U-Boot] Build failures with older toolchain Le 01/12/2010 15:56, Premi, Sanjeev a écrit : When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! This most probably means some of the code running before relocation uses BSS; see below. I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. This is normal and should not have any negative impact as long as code that runs before relocation does not access BSS -- and it should not, since BSS only exists after relocation. [sp] Yes. This is what I wanted to confirm to ensure that relocation isn't breaking after the changes. In a way it was my testcase to see that I get similar map for omap3_beagle before and after making changes. 2) The size of .rodata has increased. (Why? not yet spent time on?) Weird. Can you provide all necessary info for duplicating these two builds? Sending the patch in next few mins: If that's a patch to remove the overlay in the .lds, it's a Nak from me already. [sp] No. I am not removing relocation. Do look at the patch. I just sent from my Linux box.. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, December 01, 2010 8:47 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premi pr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
[snip]...[snip]
The u-boot built after this change alone gets stuck somewhere after
dram_init(). However, removing the sort from LIBS (as suggested
by Wolfgang), the u-boot comes up fine on the omap3_evm.
[patch]
diff --git a/Makefile b/Makefile
index 87a383d..a530261 100644
--- a/Makefile
+++ b/Makefile
@@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-LIBS := $(addprefix $(obj),$(sort $(LIBS)))
+LIBS := $(addprefix $(obj),$(LIBS))
.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o
[/patch]
U-Boot 2010.12-rc2-00030-g4998cdc-dirty (Dec 01 2010 - 21:09:59)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
OMAP3 EVM board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Read back SMSC id 0x9220
Die ID #6092000404032d460c01201a
Net: smc911x-0
Hit any key to stop autoboot: 0
OMAP3_EVM #
OMAP3_EVM #
Here is my git-log (including the patch above):
premi # g-log-10
4998cdc : ARMv7: Fix linker errors across toolchain versions
49733aa : Merge branch 'master' of /home/wd/git/u-boot/custodians
f8264e0 : Merge branch 'master' of git://git.denx.de/u-boot-arm
b194577 : hwconfig: Fix dummy initialization of {board, cpu}_hwconfig
a55bb83 : powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC
52eb2c7 : Merge branch 'master' of git://git.denx.de/u-boot-samsung
83b622a : Merge branch 'master' of /home/wd/git/u-boot/custodians
3410a99 : Merge branch 'master' of git://git.denx.de/u-boot-sh
a7bf3ec : Merge branch 'master' of /home/wd/git/u-boot/custodians
e45c98a : mpc83xx: Make it boot again
premi #
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD
Sent: Wednesday, December 01, 2010 10:43 PM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premipr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds
b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
-
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
- *(.bss)
-. = ALIGN(4);
- _end = .;
+ OVERLAY : NOCROSSREFS
+ {
+ .rel.dyn {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .bss
+ {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed
to be .rel.dyn and .bss.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
~sanjeev
Also, this change modifies the mapping, so if mi makes an obvious bug
disappear, it may be only because the resulting u-boot corrupts
relocation now in a less obvious way.
Amicalement,
--
Albert.
___
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
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
[sp] I did the same - but focused only on .rel.dyn and .bss
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] I am trying on this. Getting back to linker scripts after many
years. But assuming that there is no way; I am still looking
for an explanation on:
1) why the current metod produces different errors across
different toolchain versions.
2) How does presence of one variable alone breaks the build?
At least, compiler doesn't complain. Even moving it out
of .bss by explicit initialization doesn't help.
BTW, I verified that it is not used anywhere till end of
board_init_f() - didn't go further. Should I?
Can yo help me on these?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] Had a quick question - hence separate mail.
Do we really need to preserve section .dynsym in the final
binary. OR are we okay with single section that contains
contents from both?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:07 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip]...[snip] For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs. Can yo help me on these? As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed). I tried with 2009q1-203, 2009q3-68 and 2010q1-202. But results with 2009q3 and 2010q1 were same - till I tried all three; so, currently using 2009q1 and 2010q1. Yes. I was on latest master when I sent patch. Had included the git log as reference for same reason when I got it running. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, November 29, 2010 8:38 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version from
codesourcery
Albert mentioned he is using it. Are you on the same
version as
well?
No, I'm using ELDk 4.2
[sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the
Codesourcery Lite edition.
There is no difference in the observations between
2009q3 and 2010q1.
[sp] I have been able to narrow down the problem to one variable defined
in board/ti/evm.c - omap3_evm_version - declared as:
static u8 omap3_evm_version;
Any attempt to assign value this variable in omap3_evm_get_revision()
leads to the linker error I noted with Codesourcery 2010q1-202.
With 2009q1-203, definition of variable itself is sufficient to cause
the linker error.
I have pasted a patch below that constructs the testcase I have created
to explain these observations:
1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are undefined, the
problem is - as described.
2) When only macro _EXCLUDE_ME_1 is defined, the compilation succeeds
with Codesourcery 2010q1-202; but fails with 2009q1-203.
3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are defined, the
compilation succeeds with both codesourcery versions.
OMAP3EVM is obviously not the only file using statics. I see their usage
in many files including OMAP3Beagle as well - one reason I did not even
suspect this to be problem.
I haven't yet been able to conclude the cause of failure - but appears
to be related to handling of static variables across compiler versions.
Still need to investigate further on this...
Board revision needs to be detected early during initialization. How is
this handled for other boards? (I am currently trying to browse non-omap
boards for pointers). Any quick suggestions would be helpful.
[patch]
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..e766355 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,15 +37,30 @@
#include asm/mach-types.h
#include evm.h
+/* #define _EXCLUDE_ME_1 *//* Uncomment - works with 2010q1 only */
+/* #define _EXCLUDE_ME_2 *//* Uncomment - works with 2009q3 as well */
+
+#if !defined(_EXCLUDE_ME_2)
static u8 omap3_evm_version;
+#endif
u8 get_omap3_evm_rev(void)
{
+#ifdef _EXCLUDE_ME_2
+ return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use the variable */
+#else
return omap3_evm_version;
+#endif
+
}
static void omap3_evm_get_revision(void)
{
+#ifdef _EXCLUDE_ME_COMPLETELY_
+ /*
+* Original code in the function is being removed completely to reduce
+* scope of the debug exercise.
+*/
#if defined(CONFIG_CMD_NET)
/*
* Board revision can be ascertained only by identifying
@@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
#endif
#endif /* CONFIG_CMD_NET */
+
+#else
+ /*
+* Dummy implementation of function just for testing
+*/
+
+#if !defined(_EXCLUDE_ME_1) !defined(_EXCLUDE_ME_2)
+ /*
+* Dummy assignment just for testing
+*/
+ omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+#endif
+
+#endif /* _EXCLUDE_ME_COMPLETELY_ */
}
#ifdef CONFIG_USB_OMAP3
[/patch]
[snip]
Removed my observations for Codesourcery 2010.09-50.
Did not get chance to look at them so far...
[/snip]
Best regards,
Sanjeev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alexander Holler Sent: Tuesday, November 30, 2010 9:59 PM To: u-boot@lists.denx.de Subject: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...) Hello, browsing through some code searching for a reason why an u-boot compiled with gcc 4.5.1 fails to boot on a beagleboard, I've come through another place where bss is used before relocation: gpmc_init (gpmc_cfg) in arch/arm/cpu/armv7/omap3/mem.c. I haven't fixed it up to now, but I want to inform the people actually working with that board (currently I don't have any to do with that board and just touching at from time to time for fun), that there might be other places than the already mentioned timer_init() and that gpmc_init(). All candidates for such problems could be found in board_init_f() in arch/arm/lib/board.c, escpecially all functions which appear in init_sequence in board.c. For omap3evm - I was getting multiple errors during compilation. Most for undefined symbols - which existed in the compiled objects but, I suspect, not in right sequence. Haven't still been able to look back at these errors; still surprised to find that you had the code running on beagle. ~sanjeev Someone should take the time and check them all. ;) Regards, Alexander ___ 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
Re: [U-Boot] Build failures with older toolchain
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, November 30, 2010 10:15 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
On 30.11.2010 15:25, Premi, Sanjeev wrote:
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, November 29, 2010 8:38 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version from
codesourcery
Albert mentioned he is using it. Are you on the same
version as
well?
No, I'm using ELDk 4.2
[sp] Okay, so I downloaded both 2009-q3 and 2010.09-50
versions of the
Codesourcery Lite edition.
There is no difference in the observations between
2009q3 and 2010q1.
[sp] I have been able to narrow down the problem to one
variable defined
in board/ti/evm.c - omap3_evm_version - declared as:
static u8 omap3_evm_version;
Any attempt to assign value this variable in
omap3_evm_get_revision()
leads to the linker error I noted with Codesourcery
2010q1-202.
With 2009q1-203, definition of variable itself is
sufficient to cause
the linker error.
Maybe CCing Codesourcery's mailing list
http://www.codesourcery.com/archives/arm-gnu-discuss/maillist.html
could help, too? At least it's worth a try?
I was thinking of same - only after we understand if there isn't
something we are, possibly, missing in changes to linker scripts.
Dirk
I have pasted a patch below that constructs the
testcase I have created
to explain these observations:
1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2
are undefined, the
problem is - as described.
2) When only macro _EXCLUDE_ME_1 is defined, the
compilation succeeds
with Codesourcery 2010q1-202; but fails with 2009q1-203.
3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2
are defined, the
compilation succeeds with both codesourcery versions.
OMAP3EVM is obviously not the only file using
statics. I see their usage
in many files including OMAP3Beagle as well - one
reason I did not even
suspect this to be problem.
I haven't yet been able to conclude the cause of
failure - but appears
to be related to handling of static variables across
compiler versions.
Still need to investigate further on this...
Board revision needs to be detected early during
initialization. How is
this handled for other boards? (I am currently trying
to browse non-omap
boards for pointers). Any quick suggestions would be helpful.
[patch]
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..e766355 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,15 +37,30 @@
#includeasm/mach-types.h
#include evm.h
+/* #define _EXCLUDE_ME_1 *//* Uncomment - works
with 2010q1 only */
+/* #define _EXCLUDE_ME_2 *//* Uncomment - works
with 2009q3 as well */
+
+#if !defined(_EXCLUDE_ME_2)
static u8 omap3_evm_version;
+#endif
u8 get_omap3_evm_rev(void)
{
+#ifdef _EXCLUDE_ME_2
+ return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use
the variable */
+#else
return omap3_evm_version;
+#endif
+
}
static void omap3_evm_get_revision(void)
{
+#ifdef _EXCLUDE_ME_COMPLETELY_
+ /*
+* Original code in the function is being removed
completely to reduce
+* scope of the debug exercise.
+*/
#if defined(CONFIG_CMD_NET)
/*
* Board revision can be ascertained only by identifying
@@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
#endif
#endif/* CONFIG_CMD_NET */
+
+#else
+ /*
+* Dummy implementation of function just for testing
+*/
+
+#if !defined(_EXCLUDE_ME_1) !defined(_EXCLUDE_ME_2)
+ /*
+* Dummy assignment just for testing
+*/
+ omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+#endif
+
+#endif /* _EXCLUDE_ME_COMPLETELY_ */
}
#ifdef CONFIG_USB_OMAP3
[/patch]
[snip]
Removed my observations for Codesourcery 2010.09-50.
Did not get chance to look at them so far...
[/snip]
Best regards,
Sanjeev
___
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
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 8:57 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 16:02, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. [sp] Are you referring to this patch? http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b 58be87fa2b165eec5fa947dc86 I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds to be similar. Your commit mentions about the new ld vs. old; I had seen this earlier as well. It was the reason for me to try CodeSourcery Lite 2010-q1 but there I get a different error - mentioned in my first post. Which toolchain version are you using? I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains. Can you compare the ld invocation command lines for a failure case and a success case? The difference could be in the linker options. [sp] Identical :( Would you want me to share the build logs or the last step? The generated u-boot.lds is also same. It was my first step. Then I started looking if there is any forced addition on specific section that may not be going well with linker/ relocation changes - reason for trying a minimal config. Albert, I saw some more - what I believe related changes - since last week; but the linker error still persists. with 2009-q1 toolchain: --- busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c0 - 8007e31f] overlaps section .rel.dyn [8003f5c0 - 80044e4f] arm-none-linux-gnueabi-ld: section .dynsym [80044e50 - 80044eef] overlaps section .bss [8003f5c0 - 8007e31f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections make: *** [u-boot] Error 1 with 2010-q1 toolchain: --- mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin Best regards, Sanjeev ~sanjeev Amicalement, -- Albert. ___ 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
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 29, 2010 4:03 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: Re: Build failures with older toolchain Le 29/11/2010 10:47, Premi, Sanjeev a écrit : Albert, I saw some more - what I believe related changes - since last week; but the linker error still persists. with 2009-q1 toolchain: --- busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c0 - 8007e31f] overlaps section .rel.dyn [8003f5c0 - 80044e4f] arm-none-linux-gnueabi-ld: section .dynsym [80044e50 - 80044eef] overlaps section .bss [8003f5c0 - 8007e31f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections make: *** [u-boot] Error 1 with 2010-q1 toolchain: --- mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin Weird... I've compiled v2010.12-rc2, for boards omap3_evm, omap3_overo and omap3_beagle, with 2010q1, and here is what I get, which is quite different from what you get: alb...@lilith:~/src/u-boot$ ./MAKEALL omap3_evm omap3_overo omap3_beagle Configuring for omap3_evm board... start.S: Assembler messages: start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))' make[1]: *** [start.o] Erreur 1 make: *** [arch/arm/cpu/armv7/start.o] Erreur 2 make: *** Attente des tâches non terminées arm-none-linux-gnueabi-size: './u-boot': No such file Configuring for omap3_overo board... text data bss dec hex filename 21296510840 210624 434429 6a0fd ./u-boot Configuring for omap3_beagle board... text data bss dec hex filename 24318211300 203648 458130 6fd92 ./u-boot - SUMMARY Boards compiled: 3 Boards with warnings or errors: 1 ( omap3_evm ) -- alb...@lilith:~/src/u-boot$ [sp] Did you apply the patch I sent to off-the-list? (pasted below) I had been holding this patch until until the problem is really solved - just in case there was a relation. [patch] diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index aeb45c6..c93f689 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -348,7 +348,9 @@ extern unsigned int boot_flash_type; * Support for relocation */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_D +#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK \ + - GENERATED_GBL_DATA_SIZE) + /* * Define the board revision statically [/patch] Best regards, Sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 4:05 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, can you please quote onlye _relevant_ parts of previous messages? Thanks. [sp] I do try to snip the messages. I didn't do so this time to maintain context - but, may be, I erred on wrong side. In message b85a65d85d7eb246be421b3fb0fbb5930247a0a...@dbde02.ent.ti.com you wrote: [snip] Are you sure these are the only errors you see? Because for me, building for omap3_evm fails like this: start.S: Assembler messages: start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))' make[1]: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 1 make: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 2 make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. And this is a clear indication that the board support code has not been adapted yet (CONFIG_SYS_GBL_DATA_SIZE has been replaced by GENERATED_GBL_DATA_SIZE some time ago). [sp] I just responded to Albert' message on same issue. I stumbled on the current problem while trying to fix just the problem you notice here. Assuming relation, I had not submitted the patch - so far. But it looks to be causing more confusion - so patch follows in next few mins. ~sanjeev 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 You said you didn't want to use CGI.pm, but methinks you are needlessly reinventing the wheel, one spoke at a time. Either you are masochistic, or you just haven't seen enough of what CGI.pm can do for you. -- Randal L. Schwartz in 8cyb81rg81@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 5:00 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain [snip] I had been holding this patch until until the problem is really solved - just in case there was a relation. You mean you are complaining about problems with code you have modified locally, and then expect us to diagnose your problems without even telling us 1) that you changed the code and 2) what exactly you changed? [sp] In my original message I did mention about local change. At least, then, I believed them to be unrelated... and mentioned so. This patch is corrupted.and does not apply. Please see http://www.denx.de/wiki/U-Boot/Patches [sp] I shared the patch with Albert off-the-list as he had planned to work on it... It was to indicate the change that I was doing. BTW, I now notice that few chars on the pasted diff seem to have been trimed (not sure why) therefore patch didn't apply. Should have been more careful... I have posted an updated patch refreshed against the latest master few mins back. I have no idea if it results in a running system (as I have no hardware to test it), but I can confirm that a patch like this: diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 84b2986..f3df8de 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -330,7 +330,7 @@ extern unsigned int boot_flash_type; * Support for relocation */ #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) [sp] Although, you the patch I send earlier didn't apply cleanly, I was making the same change... and noticing the failures. As mentioned earlier, I did not expect to see any errors after making this change. I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? ~sanjeev [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 5:35 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247a0a...@dbde02.ent.ti.com you wrote: I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? No, I'm using ELDk 4.2 [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the Codesourcery Lite edition. There is no difference in the observations between 2009q3 and 2010q1. However, the 2010.09-50 returns with screen pages full of the undefined reference errors and assertion failures in linker - probably due to undefined symbols. I tried to revert sort shared by Wolfgang; even that didn't help. I will start working backwards from the errors I notice with 2010.09-50. Should I post the errors? ~sanjeev 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 Vulcans do not approve of violence. -- Spock, Journey to Babel, stardate 3842.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko Schocher Sent: Monday, November 29, 2010 8:35 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] v2010-rc2: OMAP3 broken [snip] in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets timestamp to 0, before relocation is executed, which leads that the memory @80046d7c gets overwritten to 0, which results in crashing in the fixrel case ... So it seems to me the sort version intermix the rel dyn section entries with normal vars in bss ... Which raises the question: Why is the rel.dyn Section in the bss section? I have been facing the linker errors due to overlap of these sections. Using git-bisect, I was able to narrow down the failure to commit 6d8962e814c15807dd6ac5757904be2a02d187b8. I had the same question above. See these: http://marc.info/?l=u-bootm=129043627514796w=2 http://marc.info/?l=u-bootm=129041727622164w=2 ~sanjeev bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ 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
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 29, 2010 9:04 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Le 29/11/2010 16:08, Premi, Sanjeev a écrit : I will start working backwards from the errors I notice with 2010.09-50. Should I post the errors? You should post patches against the master branch for others to be able to build the same code as you build. Do not post the compile errors, though: rather, try and find why they occur and post your conclusions. [sp] I am working on analysis. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302477ea...@dbde02.ent.ti.com you wrote: This points leads me to this commit: commit 6d8962e814c15807dd6ac5757904be2a02d187b8 Author: Sebastien Carlier sebastien.carl...@gmail.com Date: Fri Nov 5 15:48:07 2010 +0100 Switch from archive libraries to partial linking Is this related to toolchain version? Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle... This commit may require further changes to board specific linker scripts. [sp] Both boards share the same 'u-boot.lds' And there is no board specific lds. Still trying to figure what could be wrong. ~sanjeev 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 anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 2:44 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302477ea...@dbde02.ent.ti.com you wrote: This points leads me to this commit: commit 6d8962e814c15807dd6ac5757904be2a02d187b8 Author: Sebastien Carlier sebastien.carl...@gmail.com Date: Fri Nov 5 15:48:07 2010 +0100 Switch from archive libraries to partial linking Is this related to toolchain version? Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle... This commit may require further changes to board specific linker scripts. [sp] Both boards share the same 'u-boot.lds' And there is no board specific lds. Still trying to figure what could be wrong. Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address but Looking for more pointers! Specifically, a big generic change that somehow didn't touch the omap3evm; but did touch others. ...will start looking at the git-log immediately after this mail. ~sanjeev ~sanjeev 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 anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ 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
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. This should not result in a linker message unless the .lds does not follow the same structure (order and attributes of output sections) as, for instance, the arm926ejs u-boot.lds. [sp] Thanks for the pointer. I will take a look at it. I am still surprised why the problem doesn't show up on beagle and overo which share the same lds. but Looking for more pointers! Specifically, a big generic change that somehow didn't touch the omap3evm; but did touch others. will start looking at the git-log immediately after this mail. ~sanjeev Look up the u-boot.lds files. Are they shared? [sp] Before sending the previous mail. I compared the u-boot.lds generated for omap3_evm and omap3_beagle and they are identical! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 16:02, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. [sp] Are you referring to this patch? http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b 58be87fa2b165eec5fa947dc86 I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds to be similar. Your commit mentions about the new ld vs. old; I had seen this earlier as well. It was the reason for me to try CodeSourcery Lite 2010-q1 but there I get a different error - mentioned in my first post. Which toolchain version are you using? I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains. Can you compare the ld invocation command lines for a failure case and a success case? The difference could be in the linker options. [sp] Identical :( Would you want me to share the build logs or the last step? The generated u-boot.lds is also same. It was my first step. Then I started looking if there is any forced addition on specific section that may not be going well with linker/ relocation changes - reason for trying a minimal config. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap3 booting issues
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Murali K. Vemuri Sent: Friday, November 19, 2010 1:49 PM To: u-boot@lists.denx.de Subject: [U-Boot] omap3 booting issues Hi there, This may not be the ideal place to post this question, but I thought someone might know this. [sp] This is definitely not the right place. The question belongs to linux-omap mailing list. I have custom board using OMAP3 and I have a problem. We have more than one I2C slave connected on I2C1 u-boot was not displaying the slave addresses correctly. I fixed some issues in u-boot and am finally able to see the u-boot displaying the I2C devices correctly. But after this Kernel stopped to boot. It just gives the message: Starting kernel ... Uncompressing Linux. .. done, booting the kernel. and stops. I tried to find out the possible reason, but no use so far (about 2 days). Currently my MLO (x-loader), u-boot.bin, the kernel uImage reside on the SD Card . [sp] You have shared no information on versions of x-loader, u-boot and kernel. How is your custom board different from any known platform omap3evm, beagle, sdp, ... In absence, you should look at your customizations and ensure all board specific hook-ups or changes are properly handled in software. BTW, I found a curious comment in the kernel code: /* First I2C bus is not muxable */ Can this be a problem for the board not booting? As I had been playing with I2C only, I had to dig mainly on the I2C direction. any other pointers will be helpful [sp] Provide more details and move your kernel related queries to linux-omap. Thanks regards Murali ___ 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
Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Enric Balletbò i Serra Sent: Friday, November 19, 2010 2:42 PM To: u-boot@lists.denx.de; Steve Sakoman Subject: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi all, I would ask a question, maybe someone can help, which is the better way to configure the PRCM registers to get 1000MHz on AM/DM37X processor ? You need set the multipliers and dividers apprioriately - based on the sysclk. Would help to understand the context of better? ~sanjeev Thanks in advance, Enric ___ 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
Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Friday, November 19, 2010 6:30 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi, Thanks for your reply 2010/11/19 Premi, Sanjeev pr...@ti.com: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Enric Balletbò i Serra Sent: Friday, November 19, 2010 2:42 PM To: u-boot@lists.denx.de; Steve Sakoman Subject: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi all, I would ask a question, maybe someone can help, which is the better way to configure the PRCM registers to get 1000MHz on AM/DM37X processor ? You need set the multipliers and dividers apprioriately - based on the sysclk. Would help to understand the context of better? I'm thinking in two scenarios : 1. For OMAP35X there are devices that support 600MHz as max frequency but others supports 720MHz, I want to set by default 600MHz and if device supports 720MHz change to this frequency. [sp] You can look at one of my patches on linux kernel to identify the device capability for 600/720MHz. 2. For AM/DM37X, maybe I'm wrong, but the default frequency for AM/DM37X is set to 600MHz, Like OMAP35X i want to set default to 800MHz and i device supports change to 1000MHz. [sp] The device comes up at 600MHz for now, but there is no limitation on device to go all the way to 1GHz. Which is the better way to do this ? [sp] So, you are looking for common mechanism to go to highest supported frequency. Right? Thanks in advance, Enric ~sanjeev Thanks in advance, Enric ___ 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
Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Friday, November 19, 2010 6:43 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz [snip]...[snip] I'm thinking in two scenarios : 1. For OMAP35X there are devices that support 600MHz as max frequency but others supports 720MHz, I want to set by default 600MHz and if device supports 720MHz change to this frequency. [sp] You can look at one of my patches on linux kernel to identify the device capability for 600/720MHz. I''ll do, thanks 2. For AM/DM37X, maybe I'm wrong, but the default frequency for AM/DM37X is set to 600MHz, Like OMAP35X i want to set default to 800MHz and i device supports change to 1000MHz. [sp] The device comes up at 600MHz for now, but there is no limitation on device to go all the way to 1GHz. Which is the better way to do this ? [sp] So, you are looking for common mechanism to go to highest supported frequency. Right? Yes, I think should be interesting for all OMAP35/AM/DM37 a mechanism like this. [sp] I am stuck is a critical activity for next few days; would be able to work on this only next week. However, if you could start on it, I have quick thought process here: 1) Have a function that returns max supported freq for each device. - Function for OMAP35x can internally check the capability bit - While the one for AM37x would return 1GHz. 2) There is a mapping table for freq. and corresponding M, N, M2 values that can be used to pick select the right values. 3) Such a table exists in ASM; I have an intent to make it more readable in C - but always goes low in priority. 4) Another twist to 2) above can be use of env variable that gets pref. e.g. 37x support 1GHz; but you wantto still boot at 800MHz for some reason; then setting env var would make the function return 800 instead of 1000. ~sanjeev Thanks in advance, Enric ~sanjeev Thanks in advance, Enric ___ 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] Build failures with older toolchain
Hi all, I pulled u-boot about an hour ago and master is at this commit: Author: Matthias Weisser weiss...@arcor.de Date: Thu Nov 18 09:35:09 2010 +0100 Makefile: Fix build with USE_PRIVATE_LIBGCC (plus a small change in omap3_config.h - unrelated) When trying to build u-boot I was constantly, getting these errors: arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections Tried to build omap3_beagle and there were no issues; unable to debug for long, I decided to come back on this problem later. Opened a new window and started working on my Linux tree. Returned back to u-boot, and this time build was successful for no evident change. Took me some time to realise that the toolchain I was using to work on Linux repo was different - I use an env script based on activity. To verify the doubts, I explicitly ran this command with two different versions of toolchain in my path and I see different results. Here are last few lines of final build step Failure with Codesourcery 2009q1-203: h/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections make: *** [u-boot] Error 1 premi # pwd /home/premi/git/u-boot premi # Success with Codesourcery 2010q1-202: 19/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e8 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin premi # pwd /home/premi/git/u-boot premi # The configuration for beagle still build successfully for both toolchain versions. Any clues/ suggestions? Is there a recent change which hasn't yet been adapted or ported for omap3evm? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Saturday, November 20, 2010 12:21 AM To: u-boot@lists.denx.de Subject: [U-Boot] Build failures with older toolchain Hi all, I pulled u-boot about an hour ago and master is at this commit: Author: Matthias Weisser weiss...@arcor.de Date: Thu Nov 18 09:35:09 2010 +0100 Makefile: Fix build with USE_PRIVATE_LIBGCC (plus a small change in omap3_config.h - unrelated) When trying to build u-boot I was constantly, getting these errors: arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections Tried to build omap3_beagle and there were no issues; unable to debug for long, I decided to come back on this problem later. Opened a new window and started working on my Linux tree. Returned back to u-boot, and this time build was successful for no evident change. Took me some time to realise that the toolchain I was using to work on Linux repo was different - I use an env script based on activity. To verify the doubts, I explicitly ran this command with two different versions of toolchain in my path and I see different results. Here are last few lines of final build step Failure with Codesourcery 2009q1-203: h/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections make: *** [u-boot] Error 1 premi # pwd /home/premi/git/u-boot premi # Success with Codesourcery 2010q1-202: 19/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e8 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin premi # pwd /home/premi/git/u-boot premi # The configuration for beagle still build successfully for both toolchain versions. Any clues/ suggestions? Is there a recent change which hasn't yet been adapted or ported for omap3evm? Here is my log of git-bisect: Was trying to find if any commit made changes that could be specific to toolchain version. Due to state of the omap3evm, 2 changes in configs/omap3_evm.h had to be done manually at some stage - to avoid compile errors due to undefined symbols. premi # git bisect log git bisect start # good: [e0ccbe367ed4465db930a37a850c889827fb076b] Merge branch 'master' of http://git.denx.de/u-boot git bisect good e0ccbe367ed4465db930a37a850c889827fb076b # bad: [e3dae922877505c89823b17acaefdf83a6d92ce2] work in progress git bisect bad e3dae922877505c89823b17acaefdf83a6d92ce2 # good: [f2b382ea066d02d5ba44870024cc1295e85782ef] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx git bisect good f2b382ea066d02d5ba44870024cc1295e85782ef # good: [d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f] Merge branch 'master' of git://git.denx.de/u-boot-imx git bisect good d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [227b72515546fca535dbd3274f6d875d97f494fe] Merge branch 'master' of git://git.denx.de/u-boot-ti git bisect good 227b72515546fca535dbd3274f6d875d97f494fe # good: [8ad25bf8d9233eb7d0b614612108622a59069354] Net: clarify board/cpu_eth_init calls git bisect good 8ad25bf8d9233eb7d0b614612108622a59069354 # bad: [f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a] net: e1000: typo using wrong argument to sizeof git bisect bad f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a # good: [858ecd9ac3434e011e84d5fd9013bd1ee199dbdc] tx25: fix linker file for newer ld support git bisect good 858ecd9ac3434e011e84d5fd9013bd1ee199dbdc # bad: [6d8962e814c15807dd6ac5757904be2a02d187b8] Switch from archive libraries to partial linking git bisect bad 6d8962e814c15807dd6ac5757904be2a02d187b8 premi # This points leads me
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Nishanth Menon Sent: Tuesday, November 09, 2010 6:09 AM To: Peter Barada Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX Peter Barada wrote, on 11/05/2010 11:59 PM: Personally I'd like to see the kernel and u-boot disconnect on the Looks like we are getting to a consensus - we all seem to dislike the dependency of u-boot and kernel for mux as of today - can we think about [sp] In my opinion, we need to do minimal and necessary MUX settings in u-boot and let kernel manage itself. This also helps ensure that problems noticed in kernel are easy to replicate on other similar platforms. Last year I spent long time in convincing that wake-up on keypad was not working in Linux kernel; but folks using OMAP3430SDP maintained it worked fine. Root cause - relevant PADCONF was set in u-boot for 3430SDP. (not quoting mail-chain) We may not be able to eliminate such instances altogether - but can have less of such instances. post 2011March as a good time to start pushing the relevant changes in? if that is the case, I will start posting RFCs in the coming weeks so [sp] Can you list what chanages you are trying to propose? ...without going as far as RFC. the mails quoted in previous message are again too long and wide in discussion. A concise list will help. ~sanjeev that we can get the relevant changes ready on time. Ofcourse, if there are others wishing to collaborate, folks are more than welcome :) -- Regards, Nishanth Menon ___ 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
Re: [U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, November 08, 2010 3:14 AM To: Steve Sakoman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto Dear Steve Sakoman, In message 1289012370.18546.66.ca...@quadra you wrote: The maximum clock rate for the OMAP3 processors on Overo depends on the processor type and revision. This patch sets the clock rate to the spec sheet maximum if the mpurate environment variable is set to auto. Otherwise it passes the mpurate variable unchanged on the kernel command line. I don't think this is a good idea. This logic does not belong into U-Boot; if anywhere, it belongs into the Linux kernel code. If I want to pass any specific value to the Linux kernel I want that U-Boot does not get in my way. And if I decide to set the mpurate to auto I want that U-Boot keeps this setting and does not change it silently behind my back into something else. [sp] I am in full agreement. It is too difficult to find root cause for transparent changes - usually lead to long debug times first in kernel an then in u-boot. ~sanjeev Both looks conceptually broken to me. 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 It became apparent that one reason why the Ice Giants were known as the Ice Giants was because they were, well, giants. The other was that they were made of ice. -Terry Pratchett, _Sourcery_ ___ 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
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add more expansionboard IDs
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner Sent: Friday, November 05, 2010 11:17 AM To: u-boot@lists.denx.de Cc: Koen Kooi Subject: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add more expansionboard IDs [sp] Is it really necessary to mention ARMV7 in the subject line? OMAP3 BeagbeBoard seem sufficient. From: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- board/ti/beagle/beagle.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index d9b6f01..520e57d 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -48,6 +48,10 @@ #define TINCANTOOLS_TRAINER 0x04000100 #define TINCANTOOLS_SHOWDOG 0x03000100 #define KBADC_BEAGLEFPGA 0x01000600 +#define LW_BEAGLETOUCH 0x01000700 +#define LCDOG_BRAINMUX 0x01000800 +#define LCDOG_BRAINMUXTOUCH 0x02000800 [sp] Don't see any mechanism to read these values. Assuming the detection mechanism is consistent i.e. no difference due to different eeprom etc. etc. +#define SF_HARDHAT 0x01000900 [sp] Don't see this used below #define BEAGLE_NO_EEPROM 0x @@ -223,6 +227,18 @@ int misc_init_r(void) MUX_KBADC_BEAGLEFPGA(); setenv(buddy, beaglefpga); break; + case LW_BEAGLETOUCH: + printf(Recognized Liquidware Beagletouch board\n); + setenv(buddy, beagletouch); + break; + case LCDOG_BRAINMUX: + printf(Recognized Brainmux LCDog board\n); + setenv(buddy, lcdog); + break; + case LCDOG_BRAINMUXTOUCH: + printf(Recognized Brainmux LCDog Touch board\n); + setenv(buddy, lcdogtouch); + break; case BEAGLE_NO_EEPROM: printf(No EEPROM on expansion board\n); setenv(buddy, none); -- 1.5.6.4 ___ 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
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: Enable pullups on i2c2.
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner
Sent: Friday, November 05, 2010 11:24 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Cc: Kipisz, Steven
Subject: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: Enable
pullups on i2c2.
From: Steve Kipisz s-kipi...@ti.com
[sp] Description missing.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
arch/arm/include/asm/arch-omap3/omap3.h |9 +
board/ti/beagle/beagle.c|3 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
b/arch/arm/include/asm/arch-omap3/omap3.h
index 3957c79..1860dff 100644
--- a/arch/arm/include/asm/arch-omap3/omap3.h
+++ b/arch/arm/include/asm/arch-omap3/omap3.h
@@ -50,6 +50,15 @@/ctr
/* CONTROL */
#define OMAP34XX_CTRL_BASE (OMAP34XX_L4_IO_BASE + 0x2000)
+/* Signal Integrity Parameter Control Registers */
+#define CONTROL_PROG_IO0 0x48002444
+#define CONTROL_PROG_IO1 0x48002448
+#define CONTROL_PROG_IO2 0x48002408
+#define CONTROL_PROG_IO_WKUP10x48002A80
[sp] Would be better if they are defined off OMAP34XX_CTRL_BASE
defined just above.
+
+/* Bit definition for CONTROL_PROG_IO1 */
+#define PRG_I2C2_PULLUPRESX 0x0001
+
/* UART */
#define OMAP34XX_UART1
(OMAP34XX_L4_IO_BASE + 0x6a000)
#define OMAP34XX_UART2
(OMAP34XX_L4_IO_BASE + 0x6c000)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index dd7b6b5..6074eca 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -160,6 +160,9 @@ int misc_init_r(void)
struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
+ /* Enable i2c2 pullup resisters */
+ *(ulong *)(CONTROL_PROG_IO1) = ~(PRG_I2C2_PULLUPRESX);
[sp] Direct pointer access is not a good practice.
Can you look at struct ctrl and see whether it can be augmented/
similar approach can be used?
+
switch (get_board_revision()) {
case REVISION_AXBX:
printf(Beagle Rev Ax/Bx\n);
--
1.5.6.4
___
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
Re: [U-Boot] [PATCH] BeagleBoard: Added LED driver
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner
Sent: Friday, November 05, 2010 11:23 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Subject: [U-Boot] [PATCH] BeagleBoard: Added LED driver
Added LED driver using status_led. USR0 is set to monitor the boot
status. USR1 is set to be the green LED.
(cherry picked from commit 048b526fd7cc0c642f27c674b3e235321c880b66)
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
board/ti/beagle/Makefile |4 ++-
board/ti/beagle/beagle.c |7
board/ti/beagle/led.c| 91
++
3 files changed, 101 insertions(+), 1 deletions(-)
create mode 100644 board/ti/beagle/led.c
diff --git a/board/ti/beagle/Makefile b/board/ti/beagle/Makefile
index f797112..4cc675c 100644
--- a/board/ti/beagle/Makefile
+++ b/board/ti/beagle/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).a
-COBJS:= beagle.o
+COBJS-y := $(BOARD).o
+COBJS-$(CONFIG_STATUS_LED) += led.o
+COBJS:= $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 93c452e..dd7b6b5 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -30,6 +30,9 @@
* MA 02111-1307 USA
*/
#include common.h
+#ifdef CONFIG_STATUS_LED
+#include status_led.h
+#endif
#include twl4030.h
#include asm/io.h
#include asm/arch/mmc_host_def.h
@@ -78,6 +81,10 @@ int board_init(void)
/* boot param addr */
gd-bd-bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) defined(STATUS_LED_BOOT)
+ status_led_set (STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/ti/beagle/led.c b/board/ti/beagle/led.c
new file mode 100644
index 000..df26552
--- /dev/null
+++ b/board/ti/beagle/led.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2010 Texas Instruments, Inc.
+ * Jason Kridner jkrid...@beagleboard.org
+ *
+ * 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 common.h
+#include status_led.h
+#include asm/arch/cpu.h
+#include asm/io.h
+#include asm/arch/sys_proto.h
+#include asm/arch/gpio.h
+
+static unsigned int saved_state[2] = {STATUS_LED_OFF,
STATUS_LED_OFF};
+
+/* GPIO pins for the LEDs */
+#define BEAGLE_LED_USR0 149
+#define BEAGLE_LED_USR1 150
+
+#ifdef STATUS_LED_GREEN
+void green_LED_off (void)
+{
+ __led_set (STATUS_LED_GREEN, 0);
+}
+
+void green_LED_on (void)
+{
+ __led_set (STATUS_LED_GREEN, 1);
+}
+#endif
+
+void __led_init (led_id_t mask, int state)
+{
+ __led_set (mask, state);
+}
+
+void __led_toggle (led_id_t mask)
+{
+#ifdef STATUS_LED_BIT
+ if (STATUS_LED_BIT mask) {
+ if (STATUS_LED_ON == saved_state[0])
+ __led_set(STATUS_LED_BIT, 0);
+ else
+ __led_set(STATUS_LED_BIT, 1);
+ }
+#endif
+#ifdef STATUS_LED_BIT1
+ if (STATUS_LED_BIT1 mask) {
+ if (STATUS_LED_ON == saved_state[1])
+ __led_set(STATUS_LED_BIT1, 0);
+ else
+ __led_set(STATUS_LED_BIT1, 1);
+ }
+#endif
+}
+
+void __led_set (led_id_t mask, int state)
+{
+#ifdef STATUS_LED_BIT
+ if (STATUS_LED_BIT mask) {
+ if (!omap_request_gpio(BEAGLE_LED_USR0)) {
+ omap_set_gpio_direction(BEAGLE_LED_USR0, 0);
+ omap_set_gpio_dataout(BEAGLE_LED_USR0, state);
+ }
+ saved_state[0] = state;
+ }
+#endif
+#ifdef STATUS_LED_BIT1
+ if (STATUS_LED_BIT1 mask) {
+ if (!omap_request_gpio(BEAGLE_LED_USR1)) {
+ omap_set_gpio_direction(BEAGLE_LED_USR1, 0);
+ omap_set_gpio_dataout(BEAGLE_LED_USR1, state);
+ }
+ saved_state[1] = state;
+ }
+#endif
+}
[sp] I see too many ifdef blocks in the code above. The also seems to be
repetitive.
Is user really expected to change the u-boot config for each LED bit/color?
Can this be simplified by one
Re: [U-Boot] [RFCv2 0/3] Add support for quick boot
-Original Message- From: Premi, Sanjeev Sent: Friday, October 29, 2010 9:35 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [RFCv2 0/3] Add support for quick boot This series attempts to address specific feedback[1] from Wolfgang Denk to my previous submission. Since this series is based on u-boot master, it is missing these patches for successful build: a) omap3evm: Support relocation http://marc.info/?l=u-bootm=128748423503307w=2 b) omap3evm: Move function to identify board revision http://marc.info/?l=u-bootm=128749414618147w=2 c) omap3evm: Fix mechanism to identify board revision http://marc.info/?l=u-bootm=128757192518074w=2 I am hoping this series illustrates exact changes done. However, my choice of filenames results in rather long config names for two new configurations. I plan to replace quick with simple q. Does it sound ok? References: [1] http://marc.info/?l=u-bootm=128828487429161w=2 [2] http://marc.info/?l=u-bootm=128818733126234w=2 [3] http://marc.info/?l=u-bootm=128818664024766w=2 Patch (a) is required for successful build for current configuration. Patches (b) and (c) were required for successful build of quick configurations. I am yet to test these on this patchset. Will do before final submission. Sanjeev Premi (3): omap3evm: Reorder related config options omap3evm: move common config options to new file omap3evm: Add quick boot configurations Hi Wolfgang, Did you get chance to look at this series? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Fix mechanism to identify board revision
-Original Message- From: Premi, Sanjeev Sent: Wednesday, October 20, 2010 4:21 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Fix mechanism to identify board revision [snip] Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Support relocation
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 4:00 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Support relocation This patch adds relocation support for omap3evm. Content of the patch is based on changes for Beagleboard. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 6:36 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3 The function omap3_evm_need_extvbus() is required only when USB support is configured. Wrapped this function in #ifdef CONFIG_USB_OMAP3. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, October 27, 2010 8:32 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302346c6...@dbde02.ent.ti.com you wrote: This has the additional benefit that you can actually build both configurations without the need to modify any source files. [sp] Was only concerned about possibility of multiple configurations per platform. Keeping them in sync could be pain. Do you have suggestions on this? Well, if the common parts are indeed in some common header file, then the remaining content should all be specific for the selected configuration, so what needs to be kept in sync? I think I have been able to do what you have suggested above. But got a small set of config options that could be duplicated. I am following this mail with an RFC series with specific code changes. Have tried to be explicit in my comments. There is one TBD in 2/3 that indicates possible duplication. Your comments would be really useful. Best regards, Sanjeev 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 I paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, October 28, 2010 10:24 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot Dear Sanjeev Premi, In message 1288283919-3837-1-git-send-email-pr...@ti.com you wrote: This series is based on the comments received [1] on my earlier submission[2]. Intent of sending as RFC is to thrash out the ideas and then send a formal patch. Sorry, as you submitted this I see only 3 completely new files without relation to each other nor with any relation to the existing code. I suggest the following approach: Patch 1: move common code out of include/configs/omap3_evm.h into a new file include/configs/omap3_evm_common.h; this patch should result in exactly the same code for the board as we have now. Do not rename omap3_evm.h into omap3_evm_full.h; this makes no sense to me. omap3_evm.h is and remains the default configuration. [sp] Since I was also moving the related config options next to each other - as against current spread. I couldn't make much sens of patch. Thought it could be confusing to others as well. Appears, I was wrong! Patch 2: Create a new file omap3_evm_quick.h, which contains the speed optimized configuration settings. Get rid of all the #ifndef FOO #define FOO #endif stuff there. This is a plain simple and fixed configuration, so this is not needed. [sp] Sorry, I didn't clean this up considering the focus would be on the first 2 patches. You may even consider to splitting this more - into omap3_evm_quick_nand.h and omap3_evm_quick_mmc.h to eliminate even more of the #ifdeffery. [sp] That's a good idea. Will have it implemented tomorrow morning. best regards, Sanjeev 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 A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, October 27, 2010 7:19 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot [snip]...[snip] +#undef CONFIG_QUICK_BOOT +#undef CONFIG_QUICK_BOOT_MMC +#undef CONFIG_QUICK_BOOT_NAND If you use this here to show the options, then please move it into the comment above. [sp] Will do. Otherwise, it is just dead code as you undefine things that are not defiend anyway. In any case, please remove the #undef's. +#ifdef CONFIG_QUICK_BOOT + /* +* Generic config options +*/ + #ifndef CONFIG_SILENT_CONSOLE + #define CONFIG_SILENT_CONSOLE 1 + #endif + + #ifndef CONFIG_ENV_IS_NOWHERE + #define CONFIG_ENV_IS_NOWHERE 1 + #endif Style issue: Please always start preprocessor commands in column 1. [sp] I was following style from another file which uses nesting. Maybe, my choice of reference was incorect. Will make the change. [snip]...[snip] + #undef CONFIG_CMD_USB I do not like this approach at all. It will make the board config file basicly unreadable - it becomes a mess of defiunitions here and (even conditional) #undef's and re-definitions there. I suggest you chose a different approach, for example move the common (always used) configuration settings into a separate header file, and then provide two separate board configurations (normal and quick boot) which include the common settings. [sp] I did think about it, infact, I was initially planning to follow the config_cmd_default.h; because, same set of changes can apply across multiple boards. I did test the patch against Beagle board as well. This has the additional benefit that you can actually build both configurations without the need to modify any source files. [sp] Was only concerned about possibility of multiple configurations per platform. Keeping them in sync could be pain. Do you have suggestions on 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: w...@denx.de Lack of skill dictates economy of style.- Joey Ramone ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, October 19, 2010 10:25 PM To: Loïc Minier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot -Original Message- From: Loïc Minier [mailto:l...@dooz.org] Sent: Tuesday, October 19, 2010 10:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot On Tue, Oct 19, 2010, Sanjeev Premi wrote: +#undef CONFIG_FAST_BOOT I wonder whether CONFIG_FAST_BOOT would cause confusion if u-boot gains support for Android fastboot someday? http://en.wikipedia.org/wiki/Fastboot http://android-dls.com/wiki/index.php?title=Fastboot [sp] The intent here is to boot faster - hence the name. Wasn't aware of any Android overlap. How about any of these: - CONFIG_SMALL_SIZE - CONFIG_FASTER_BOOT :) ^^ Any other suggestions? [sp] Didn't hear any other suggestions. But I had one more, CONFIG_QUICK_BOOT. Loic, does this seem okay? ~sanjeev ~sanjeev -- Loïc Minier ___ 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
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 8:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote: -Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards to build. Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. Ideally we would have a generic ARMV7 implementation that would work for even non-OMAP ARMV7 processors. Someone who is familiar with the differences in ARMV7 cache implementations from the various silicon vendors would need to do this. This beyond my knowledge. A second best solution would be to have a cache.S that worked for both OMAP3 and OMAP4 in omap-common/ If this isn't possible, then we should add an OMAP4 specific cache.S in omap4/ But until we settle on the proper long term strategy this patch should be applied so that non-OMAP3 ARMV7 boards will build. Can we indicate either in the title/ description that patch is temporary? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. ~sanjeev Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Move function to identify board revision
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 6:37 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Move function to identify board revision Function omap3_evm_get_revision() - to identify the board revision was called at end of setup_net_chip(). Board revision can be ascertained only by identifying the Ethernet chipset - but combining setup operations with revision detection isn;t a good idea. Moved the function and added detailed comment to set the context. Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 73330db..6163b12 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -109,6 +109,12 @@ int misc_init_r(void) #if defined(CONFIG_CMD_NET) setup_net_chip(); + + /* + * Board revision can be ascertained only by identifying + * the Ethernet chipset. + */ + omap3_evm_get_revision(); #endif [sp] While reviewing the code, I realized a latent bug that can hit us when CONFIG_CMD_NET is not defined. omap3_evm_get_revision() never gets called - value of omap3_evm_version is never set. So, value returned by get_omap3_evm_rev() depends upon compiler used. Please disregard this patch. I will submit a cleaned-up patch with takes care of this latent bug as well. ~sanjeev dieid_num_r(); @@ -163,9 +169,6 @@ static void setup_net_chip(void) writel(GPIO0, gpio3_base-cleardataout); udelay(1); writel(GPIO0, gpio3_base-setdataout); - - /* determine omap3evm revision */ - omap3_evm_get_revision(); } int board_eth_init(bd_t *bis) -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
-Original Message- From: Loïc Minier [mailto:l...@dooz.org] Sent: Tuesday, October 19, 2010 10:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot On Tue, Oct 19, 2010, Sanjeev Premi wrote: +#undef CONFIG_FAST_BOOT I wonder whether CONFIG_FAST_BOOT would cause confusion if u-boot gains support for Android fastboot someday? http://en.wikipedia.org/wiki/Fastboot http://android-dls.com/wiki/index.php?title=Fastboot [sp] The intent here is to boot faster - hence the name. Wasn't aware of any Android overlap. How about any of these: - CONFIG_SMALL_SIZE - CONFIG_FASTER_BOOT :) ^^ Any other suggestions? ~sanjeev -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Thursday, September 16, 2010 11:30 PM To: Premi, Sanjeev Cc: Kyungmin Park; Stefan Roese; u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thu, 16 Sep 2010 21:14:57 +0530 Premi, Sanjeev pr...@ti.com wrote: [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB NAND SPL typically needs to fit in just 4 KiB (sometimes even less). In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Those things are configurable. That doesn't mean we don't need makefile infrastructure to build the two (or sometimes three) separate images, or some special code for an extremely minimal image. [sp] Yes. When we need to be extremely small separate infra may be needed. But for rest, I feel we could/ should continue using the generic makefile infra - with more configuration options - that keeps maintenance low. I also feel that needs/requirements for the extremely small images will differ between the users. Maintaining compatibility will be a challenge for a common codebase. ~sanjeev -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Friday, September 17, 2010 12:02 AM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Kyungmin Park; Stefan Roese; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote: But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB the Blackfin one is in the range of 200-600 bytes. i dont care how configurable you make u-boot, it isnt getting to that. In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... yes, we should do this anyways. i have another use of u-boot where i wanted it down to the 30KiB range, and that required posting patches to make things more configurable. most have been merged already. [sp] I will rebase my work on latest and submit patches. ~sanjeev -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park Sent: Tuesday, September 14, 2010 7:48 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese s...@denx.de wrote: Hi Aneesh, On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That's definitely a good idea. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Best regards, Sanjeev Thank you, Kyungmin Park ... Comments welcome. Cheers, 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: off...@denx.de ___ 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
-Original Message-
From: Premi, Sanjeev
Sent: Friday, January 29, 2010 6:44 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev; Hiremath, Vaibhav
Subject: [PATCHv2] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
The function get_osc_clk_speed() is used to determine the master
clock. If SYS_CLK is being divided by 2, the divider is changed
to 1 - without following any sequence.
Before reaching this function, some of the clocks have already
been set (by x-loader or equiv) OR power-on defaults are in use.
This change is too sudden, leading to instability beyond certain
tolerance zone.
The problem was observed with DM3730 (silimar to OMAP3630), on
the OMAP3EVM.
This patch removes the step to change clock divider. Instead,
uses a multiplication factor (if needed). Mathematically, the
formula is unchanged.
Tested on OMAP3EVM with OMAP3530 and DM3730.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Hiremath Vaibhav hvaib...@ti.com
---
cpu/arm_cortexa8/omap3/clock.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/clock.c
b/cpu/arm_cortexa8/omap3/clock.c
index 174c453..e8189b4 100644
--- a/cpu/arm_cortexa8/omap3/clock.c
+++ b/cpu/arm_cortexa8/omap3/clock.c
@@ -40,7 +40,7 @@
**
***/
u32 get_osc_clk_speed(void)
{
- u32 start, cstart, cend, cdiff, val;
+ u32 start, cstart, cend, cdiff, cdiv, val;
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
struct prm *prm_base = (struct prm *)PRM_BASE;
struct gptimer *gpt1_base = (struct gptimer *)OMAP34XX_GPT1;
@@ -48,9 +48,13 @@ u32 get_osc_clk_speed(void)
val = readl(prm_base-clksrc_ctrl);
- /* If SYS_CLK is being divided by 2, remove for now */
- val = (val (~SYSCLKDIV_2)) | SYSCLKDIV_1;
- writel(val, prm_base-clksrc_ctrl);
+ if (val SYSCLKDIV_2)
+ cdiv = 2;
+ else if (val SYSCLKDIV_1)
+ cdiv = 1;
+ else
+ /*Should never reach here! (Assume divider as 1) */
+ cdiv = 1;
/* enable timer2 */
val = readl(prcm_base-clksel_wkup) | CLKSEL_GPT1;
@@ -83,6 +87,9 @@ u32 get_osc_clk_speed(void)
cend = readl(gpt1_base-tcrr); /* get end
sys_clk count */
cdiff = cend - cstart; /* get elapsed ticks */
+ if (cdiv == 2)
+ cdiff *= 2;
+
/* based on number of ticks assign speed */
if (cdiff 19000)
return S38_4M;
--
1.6.2.2
Tom, Sandeep,
Just wanted to check the status of this patch.
Best regards,
Sanjeev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
-Original Message-
From: Tom [mailto:tom@windriver.com]
Sent: Wednesday, January 27, 2010 7:15 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Avoid re-write to PRM_CLKSRC_CTRL
Sanjeev Premi wrote:
In function get_osc_clk_speed(), do not change/ update
the divider for SYS_CLK as it can has cascading effect
on the other derived clocks.
Sudden change in divider value can lead to inconsistent
behavior in the system - often leading to crashes.
The problem was found when working with OMAP3EVM using
DM3730 processor card.
The patch has been tested with OMAP3530 on OMAP3EVM as
well
I believe the intent of this function is only to be
called once early in the clock setup when the
other clocks have not been setup to determine emperically
the master system clock. Can you provide were else it is being
called ?
Tom,
Yes, the intent of function is to determine the master clock.
But, by the time this function is executed, the divider has
a value. (Usually set by the x-loader for OMAP boards).
Before we hit this code, the some clocks are already derived
(either by default OR by x-loader). The function as it exists
Today, does not follow any sequence to contain the effect of
changing the divider.
In case of 3730 (similar to 3630) we are possibly overshooting
the tolerance zone. Using Lauterbach we can see that contents
of each window starts to 'auto-refresh' as soon as the divider
Changes - sometimes after restoring the divider. A clear
indication of system becoming unstable.
Of course, once in 4-5 times this issue was noticed in x-loader
as well which has almost same code for the purpose.
The intent of function is to determine the OSC frequency; which
can be determined without having to change the divider... by
multiplying by the same factor.
Overall, the empirical formula is same; but this patch ensures
that HW need not change for the calculations.
Best regards,
Sanjeev
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Hiremath Vaibhav hvaib...@ti.com
---
cpu/arm_cortexa8/omap3/clock.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/clock.c
b/cpu/arm_cortexa8/omap3/clock.c
index 174c453..6330c9e 100644
--- a/cpu/arm_cortexa8/omap3/clock.c
+++ b/cpu/arm_cortexa8/omap3/clock.c
@@ -40,7 +40,7 @@
**
***/
u32 get_osc_clk_speed(void)
{
- u32 start, cstart, cend, cdiff, val;
+ u32 start, cstart, cend, cdiff, cdiv, val;
struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
struct prm *prm_base = (struct prm *)PRM_BASE;
struct gptimer *gpt1_base = (struct gptimer *)OMAP34XX_GPT1;
@@ -48,9 +48,15 @@ u32 get_osc_clk_speed(void)
val = readl(prm_base-clksrc_ctrl);
- /* If SYS_CLK is being divided by 2, remove for now */
- val = (val (~SYSCLKDIV_2)) | SYSCLKDIV_1;
- writel(val, prm_base-clksrc_ctrl);
+ if (val SYSCLKDIV_2)
+ cdiv = 2;
+ else if (val SYSCLKDIV_1)
+ cdiv = 1;
+ else
+ /*
+* Should never reach here! (Assume divider as 1)
+*/
Could reduce this to a single line,
Good comment.
+ cdiv = 1;
/* enable timer2 */
val = readl(prcm_base-clksel_wkup) | CLKSEL_GPT1;
@@ -61,6 +67,7 @@ u32 get_osc_clk_speed(void)
/* Enable I and F Clocks for GPT1 */
val = readl(prcm_base-iclken_wkup) | EN_GPT1 | EN_32KSYNC;
writel(val, prcm_base-iclken_wkup);
+
Extra space.
Remove.
val = readl(prcm_base-fclken_wkup) | EN_GPT1;
writel(val, prcm_base-fclken_wkup);
@@ -83,6 +90,11 @@ u32 get_osc_clk_speed(void)
cend = readl(gpt1_base-tcrr); /* get end
sys_clk count */
cdiff = cend - cstart; /* get elapsed ticks */
+ if (cdiv == 2)
+ {
+ cdiff *= 2;
+ }
+
Braces not needed
/* based on number of ticks assign speed */
if (cdiff 19000)
return S38_4M;
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] RE: TI:OMAP: [PATCH] Add 720Mhz support for Beagle Rev C4
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Syed
Mohammed, Khasim
Sent: Tuesday, January 12, 2010 11:35 AM
To: beaglebo...@googlegroups.com
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [beagleboard] RE: TI:OMAP: [PATCH] Add
720Mhz support for Beagle Rev C4
On Mon, Jan 11, 2010 at 10:52 PM, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Khasim
Syed Mohammed
Sent: Saturday, January 09, 2010 10:17 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Subject: [U-Boot] TI:OMAP: [PATCH] Add 720Mhz support for
Beagle Rev C4
From e28c5e917f9504b724b6587287ad9e1eb0682b11 Mon Sep 17
00:00:00 2001
From: Syed Mohammed Khasim kha...@ti.com
Date: Sat, 9 Jan 2010 09:40:32 +0530
Subject: [PATCH] Add 720Mhz support for Beagle Rev C4
Use the Generic TWL and Clock APIs to get beagle
Rev C4 running at 720Mhz
Signed-off-by: Syed Mohammed Khasim kha...@ti.com
---
board/ti/beagle/beagle.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 0def5a6..7985ee9 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -122,9 +122,27 @@ int misc_init_r(void)
struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
+ beagle_identify();
+
twl4030_power_init();
twl4030_led_init();
+ if (beagle_revision == REVISION_C4) {
+
+ /* Select TWL4030 VSEL to support 720Mhz */
+
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ VAUX2_VSEL_18,
+
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ DEV_GRP_P1);
+
+
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VDD1_VSEL,
+ VDD1_VSEL_14,
+
TWL4030_PM_RECEIVER_VDD1_DEV_GRP,
+ DEV_GRP_P1);
+
+ prcm_config_720mhz();
+ }
+
/* Configure GPIOs to output */
writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
gpio6_base-oe);
writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22
| GPIO21 |
@@ -136,8 +154,6 @@ int misc_init_r(void)
writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
GPIO15 | GPIO14 | GPIO13 | GPIO12,
gpio5_base-setdataout);
- beagle_identify();
-
dieid_num_r();
Khasim,
I am not clear about the beagle revisions, but I feel it
will be better to
check the silicon capability for 720MHz to do the scaling.
This patch will
need to be updated if there is C5 which also supports 720MHz.
I was looking for documentation / addendum that points to change in
silicon revisions - unfortunately I didn't find any.
I agree that we can base this on Silicon Rev instead of board rev.
Will change this when I get the documentation for the same.
Khasim,
The steps are defined in the latest TRM.
Best regards,
Sanjeev
Thanks for the review.
Regards,
Khasim
return 0;
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
You received this message because you are subscribed to the
Google Groups Beagle Board group.
To post to this group, send email to beaglebo...@googlegroups.com.
To unsubscribe from this group, send email to
beagleboard+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/beagleboard?hl=en.
___
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
Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
-Original Message- From: Paulraj, Sandeep Sent: Thursday, January 07, 2010 9:02 PM To: Premi, Sanjeev; u-boot@lists.denx.de Subject: RE: [PATCH 0/2] omap3: Optimize detection of cpu revision -Original Message- From: Premi, Sanjeev Sent: Tuesday, December 15, 2009 6:48 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH 0/2] omap3: Optimize detection of cpu revision Each call to get_cpu_rev() leads to repetitive execution of code to detect the cpu revision. This patchset ensures that mechanism to detect revision is not executed each time; instead a stored value is returned. Since, revision info is needed in s_init(), the function to identify cpu revision needs to be called twice. At the moment, it is necessary/ unavoidable. Sanjeev Premi (2): omap3: Identify the CPU in arch_cpu_init() omap3: Identify cpu in s_init() cpu/arm_cortexa8/omap3/board.c |2 + cpu/arm_cortexa8/omap3/sys_info.c | 73 ++-- include/asm-arm/arch-omap3/sys_proto.h |3 +- include/configs/omap3_beagle.h |2 + include/configs/omap3_evm.h|2 + include/configs/omap3_overo.h |2 + include/configs/omap3_pandora.h|2 + include/configs/omap3_zoom1.h |2 + include/configs/omap3_zoom2.h |2 + 9 files changed, 66 insertions(+), 24 deletions(-) Sandeep, Tom, Any comments on this series on your queue.. Sanjeev, Wolfgang had some comments on this. http://www.mail-archive.com/u-boot@lists.denx.de/msg26568.html Did not find this mail in my inbox (may be reason to miss it earlier). Anyway, pasting it below to maintain context: Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301e157a...@dbde02.ent.ti.com you wrote: Also, I don't believe there is any complexity added as the contents of register are being read and saved in a global variable for use later. Global variables are a bad thing if there is not really a good reason to hav ethem. Here it makes no sense to me. Execution time seems uncritical, and there is no kind of hardware wear involved with readin the registers, so like Tom I don't see a reason for this optimization. Tom, Denx, As this patch stands, there isn't much code to optimize; but the change was meant as enabler for the next set of processors. The register and mechanism is same ...just interpretation will differ. There is already a patchset for AM35x devices and there will new patches for OMAP36x. Also, I believe faster execution time is always better; not just in critical sections of code. I possibly used global quite loosely; while responding earlier. The variable cpu_revision (being discussed) here is actually a 'static'. (See patch 1/2). But, if we feel otherwise, I can revert to executing detection mechanism each time in the function. However, are their any comments on remainder of the patch e.g. moving the cpu identification eary in the u-boot exectuion. The DPLL settings etc will depend upon the si identification. Best regards, Sanjeev Best regards, Wolfgang Denk Best regards, Sanjeev Best regards, Sanjeev ___ 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
Re: [U-Boot] TI:OMAP: [PATCH] Add 720Mhz support for Beagle Rev C4
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Khasim
Syed Mohammed
Sent: Saturday, January 09, 2010 10:17 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Subject: [U-Boot] TI:OMAP: [PATCH] Add 720Mhz support for
Beagle Rev C4
From e28c5e917f9504b724b6587287ad9e1eb0682b11 Mon Sep 17 00:00:00 2001
From: Syed Mohammed Khasim kha...@ti.com
Date: Sat, 9 Jan 2010 09:40:32 +0530
Subject: [PATCH] Add 720Mhz support for Beagle Rev C4
Use the Generic TWL and Clock APIs to get beagle
Rev C4 running at 720Mhz
Signed-off-by: Syed Mohammed Khasim kha...@ti.com
---
board/ti/beagle/beagle.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 0def5a6..7985ee9 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -122,9 +122,27 @@ int misc_init_r(void)
struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
+ beagle_identify();
+
twl4030_power_init();
twl4030_led_init();
+ if (beagle_revision == REVISION_C4) {
+
+ /* Select TWL4030 VSEL to support 720Mhz */
+
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ VAUX2_VSEL_18,
+
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ DEV_GRP_P1);
+
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VDD1_VSEL,
+ VDD1_VSEL_14,
+
TWL4030_PM_RECEIVER_VDD1_DEV_GRP,
+ DEV_GRP_P1);
+
+ prcm_config_720mhz();
+ }
+
/* Configure GPIOs to output */
writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
gpio6_base-oe);
writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
@@ -136,8 +154,6 @@ int misc_init_r(void)
writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
GPIO15 | GPIO14 | GPIO13 | GPIO12,
gpio5_base-setdataout);
- beagle_identify();
-
dieid_num_r();
Khasim,
I am not clear about the beagle revisions, but I feel it will be better to
check the silicon capability for 720MHz to do the scaling. This patch will
need to be updated if there is C5 which also supports 720MHz.
Best regards,
Sanjeev
return 0;
--
1.5.6.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
Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
-Original Message- From: Paulraj, Sandeep Sent: Thursday, January 07, 2010 9:02 PM To: Premi, Sanjeev; u-boot@lists.denx.de Subject: RE: [PATCH 0/2] omap3: Optimize detection of cpu revision -Original Message- From: Premi, Sanjeev Sent: Tuesday, December 15, 2009 6:48 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH 0/2] omap3: Optimize detection of cpu revision Each call to get_cpu_rev() leads to repetitive execution of code to detect the cpu revision. This patchset ensures that mechanism to detect revision is not executed each time; instead a stored value is returned. Since, revision info is needed in s_init(), the function to identify cpu revision needs to be called twice. At the moment, it is necessary/ unavoidable. Sanjeev Premi (2): omap3: Identify the CPU in arch_cpu_init() omap3: Identify cpu in s_init() cpu/arm_cortexa8/omap3/board.c |2 + cpu/arm_cortexa8/omap3/sys_info.c | 73 ++-- include/asm-arm/arch-omap3/sys_proto.h |3 +- include/configs/omap3_beagle.h |2 + include/configs/omap3_evm.h|2 + include/configs/omap3_overo.h |2 + include/configs/omap3_pandora.h|2 + include/configs/omap3_zoom1.h |2 + include/configs/omap3_zoom2.h |2 + 9 files changed, 66 insertions(+), 24 deletions(-) Sandeep, Tom, Any comments on this series on your queue.. Sanjeev, Wolfgang had some comments on this. http://www.mail-archive.com/u-boot@lists.denx.de/msg26568.html Sorry missed that one. Will respond. ~sanjeev Best regards, Sanjeev ___ 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
Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
-Original Message- From: Premi, Sanjeev Sent: Tuesday, December 15, 2009 6:48 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH 0/2] omap3: Optimize detection of cpu revision Each call to get_cpu_rev() leads to repetitive execution of code to detect the cpu revision. This patchset ensures that mechanism to detect revision is not executed each time; instead a stored value is returned. Since, revision info is needed in s_init(), the function to identify cpu revision needs to be called twice. At the moment, it is necessary/ unavoidable. Sanjeev Premi (2): omap3: Identify the CPU in arch_cpu_init() omap3: Identify cpu in s_init() cpu/arm_cortexa8/omap3/board.c |2 + cpu/arm_cortexa8/omap3/sys_info.c | 73 ++-- include/asm-arm/arch-omap3/sys_proto.h |3 +- include/configs/omap3_beagle.h |2 + include/configs/omap3_evm.h|2 + include/configs/omap3_overo.h |2 + include/configs/omap3_pandora.h|2 + include/configs/omap3_zoom1.h |2 + include/configs/omap3_zoom2.h |2 + 9 files changed, 66 insertions(+), 24 deletions(-) Sandeep, Tom, Any comments on this series on your queue.. Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
