Re: [U-Boot] [PATCH V3] mmc: seperate block number into small parts for multi-write cmd
Hi Wolfgang,
How about merging this patch? I have the same concern with Steve Sakoman on
the point of improving mmc operation performance in UBOOT.
Best regards,
Lei
On Thu, Oct 14, 2010 at 3:57 AM, Wolfgang Denk w...@denx.de wrote:
Dear Lei Wen,
In message 1286811544-9312-1-git-send-email-lei...@marvell.com you wrote:
Constraint the mmc framework to only send no more than 65535
blocks in one go during the multi-write command. This constraint
comes due to the limitation of 16bit width block counter register
at some hardware.
...
@@ -123,7 +111,6 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
const void*src)
data.flags = MMC_DATA_WRITE;
err = mmc_send_cmd(mmc, cmd, data);
-
if (err) {
printf(mmc write failed\n\r);
return err;
Please don;t drop this empty line.
+ do {
+ /* The 65535 constraint comes from some hardware has
+ * only 16 bit width block number counter */
Incorrect multi-line comment style.
+ cur = (blocks_todo 65535) ? 65535 : blocks_todo;
+ if(mmc_write_blocks(mmc, start, cur, src) != cur)
+ return -1;
+ blocks_todo -= cur;
+ start += cur;
+ src += cur * mmc-write_bl_len;
+ } while (blocks_todo 0);
return blkcnt;
Please add a blank line before the return.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The games have always strengthened us. Death becomes a familiar
pattern. We don't fear it as you do.
-- Proconsul Marcus Claudius, Bread and Circuses,
stardate 4041.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, omap3, beagle: initial stack pointer setup
Hello Steve, today morning I tried actual u-boot on the beagle board, and I couldn;t compile it because a problem with the GENERATED_GBL_DATA_SIZE changes. In this context the question raised, if the #define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) setup with using LOW_LEVEL_SRAM_STACK @ 0x4020FFFC is OK? The address a) it is not aligned b) We should use CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR So my question: shouldn;t we add in arch/arm/include/asm/arch-omap3/omap3.h or include/asm/arch/cpu.h? this 2 missing defines (described in b)), and change in all omap3 plattforms #define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) to #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE - \ GENERATED_GBL_DATA_SIZE) With CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x7f0 What do you think? 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] kirkwood: guruplug: Relocate NAND environment area
Ack, Thanks regards.. Prafulla . . -Original Message- From: Gray Remlin [mailto:g_rem...@rocketmail.com] Sent: Wednesday, October 27, 2010 4:31 AM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar Subject: [PATCH] kirkwood: guruplug: Relocate NAND environment area Current default options increase u-boot size to overlap the location of the environment in NAND, move environment higher up Signed-off-by: Gray Remlin g_rem...@rocketmail.com --- include/configs/guruplug.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h index 2c2682c..30a6050 100644 --- a/include/configs/guruplug.h +++ b/include/configs/guruplug.h @@ -72,8 +72,8 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x2 /* 128k */ -#define CONFIG_ENV_ADDR 0x4 -#define CONFIG_ENV_OFFSET0x4 /* env starts here */ +#define CONFIG_ENV_ADDR 0x6 +#define CONFIG_ENV_OFFSET0x6 /* env starts here */ /* * Default environment variables -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] make-asm-offsets: fix sed script
When copying the sed script to generate the asm-offsets.h file from
the Linux Kbuild script into the make-asm-offsets file I missed the
fact that the former runs in a make context and thus uses double
$$ to escape a single $, while the latter is a shell script, where
this must not be done. Unfortunately the problem did not show up
during the initial tests on Power Architecture systems, but on ARM the
generated asm-offsets.h was not correct.
Signed-off-by: Wolfgang Denk w...@denx.de
---
tools/scripts/make-asm-offsets |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/scripts/make-asm-offsets b/tools/scripts/make-asm-offsets
index 61c095f..4c33756 100755
--- a/tools/scripts/make-asm-offsets
+++ b/tools/scripts/make-asm-offsets
@@ -8,8 +8,8 @@ mkdir -p $(dirname $2)
# Default sed regexp - multiline due to syntax constraints
SED_CMD=/^-/{s:-#\(.*\):/* \1 */:; \
- s:^-\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
- s:^-\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
+ s:^-\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
+ s:^-\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:-::; p;}
(set -e
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] tqm85xx: Update PCI code
Dear Peter Tyser, In message 1288156533.1971.6.ca...@ptyser-laptop you wrote: Can you send the entire bootup output? The code is based on Freescale reference boards, eg the mpc8568mds, so I'd guess the problem is not tqm85xx-specific. Sure. Here it is: U-Boot 2010.09-00558-g79e6313 (Oct 26 2010 - 21:31:41) CPU: 8555E, Version: 1.1, (0x80790011) Core: Unknown, Version: 2.0, (0x80200020) Clock Configuration: CPU0:833.333 MHz, CCB:333.333 MHz, DDR:166.667 MHz (333.333 MT/s data rate), LBC:41.667 MHz CPM: 333.333 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: TQM8555, serial# ABC0555 casl=25 I2C: ready DRAM: 128 MiB FLASH: 128 MiB L2:256 KB already enabled PCI1: 32 bit, 33 MHz, sync, host, arbiter Scanning PCI bus 00 PCIE1 on bus 00 - 00 PCI-X will only work at 66 MHz In:serial Out: serial Err: serial DTT: 1 is 41 C Net: FCC1, TSEC0 [PRIME], TSEC1 PS/2: No device found Kbd: reset failed, no ACK Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 = Please also note the Core: Unknown which is new. 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 Hiring experienced unix people is like a built-in filter against idiots. Hiring experienced NT people provides no such guarantee. -- Miguel Cruz in wgl96.349$cc.122...@typhoon2.ba-dsg.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make-asm-offsets: fix sed script
Hello Wolfgang, Wolfgang Denk wrote: When copying the sed script to generate the asm-offsets.h file from the Linux Kbuild script into the make-asm-offsets file I missed the fact that the former runs in a make context and thus uses double $$ to escape a single $, while the latter is a shell script, where this must not be done. Unfortunately the problem did not show up during the initial tests on Power Architecture systems, but on ARM the generated asm-offsets.h was not correct. Signed-off-by: Wolfgang Denk w...@denx.de --- tools/scripts/make-asm-offsets |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Tested on the omap3_beagle board, so: Tested-by: Heiko Schocher h...@denx.de 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] SPI on PPC MPC85xx
Hi again, unfortunately I have to push this message, as I received no comment on it, yet. Is there a reason why the immap_t is not implemented for mpc85xx? I tried to copy it from mpc8360 but there are so many dependent mpc83xx datatypes in that struct that I postponed the work on that, because I think it'll lead to no success... Even trying to use the soft SPI fails, because first thing the code does is using that immap_t datatype... :-( Does anyone have a comment on this? Cheers Matthias Am 25.10.2010 um 13:05 schrieb Matthias: Hi all, I've been trying to setup SPI on our MPC85xx based board. Unfortunately, compilation of mpc8xxx_spi.c fails due to a missing immap_t datatype. I see, that this datatype is defined in the headers immap_83xx.h and immap_86xx.h but it is not in immap_85xx.h. I am using u-boot-2009.11.1 but I also looked into the latest git sources, and there's no immap_t in that specific file neither. Is there a reason why it is not implemented for MPC85xx? Or do I just need some more defines? So far I only have CONFIG_MPC8XXX_SPI and undef CONFIG_SOFT_SPI. Cheers Matthias Dunda ___ 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] current ARM development head
Hello, I noticed that there is a lot of changes in ARM part of u-boot. Especially the new relocation is a bit tricky. So I'm wondering what and where is the current ARM development head, especially the at91 part. Is it u-boot master branch or some other repository/branch? Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE 0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? 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 What is wanted is not the will to believe, but the will to find out, which is the exact opposite. - Bertrand Russell, _Sceptical_Essays_, 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
On 10/26/2010 12:35 PM, Jason Liu wrote: static int fec_set_hwaddr(struct eth_device *dev) @@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) uint32_t base; struct fec_priv *fec = (struct fec_priv *)dev-priv; - /* Initialize MAC address */ - fec_set_hwaddr(dev); - Not sure. Why is this call removed ? We have changed the storage for the MAC address, but we need always to set the FEC controller. What is the reason to drop it ? It's because, it will print some floating value of MAC address when bootup and in fact, we don't need re-set it again here.. The net framework will do that. This is why I remove. it. The call was added one month ago. It sets the MAC address any time the network is used, to be sure that the correct MAC is taken even if the ethaddr variable is changed. You can take a look at the patch: http://www.mail-archive.com/u-boot@lists.denx.de/msg37629.html 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] SPI on PPC MPC85xx
Dear Matthias Dunda, In message 6a334922-e6ee-4dc3-ae44-f43157006...@t1817.greatnet.de you wrote: unfortunately I have to push this message, as I received no comment on it, yet. See http://catb.org/esr/faqs/smart-questions.html#id586288 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 Every living thing wants to survive. -- Spock, The Ultimate Computer, stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MX5: board version not printed corretly on MX51EVK
On 10/26/2010 12:29 PM, Jason Liu wrote: As this is a cpu revision and not a board revision, it is not correct. If the board revision cannot be determined correctly at runtime, we should return a fixed value. but certainly not the cpu revision. Yes, agree. Then we need clean up the code for vision2 board too. Of course. I will fix it in the vision2 board. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] current ARM development head
Dear Alexander Stein, In message 201010270907.54241.alexander.st...@systec-electronic.com you wrote: I noticed that there is a lot of changes in ARM part of u-boot. Especially the new relocation is a bit tricky. So I'm wondering what and where is the current ARM development head, especially the at91 part. Is it u-boot master branch or some other repository/branch? Unless you are looking for some new and special feature (which you understand well and where you are sure you really want and need it) you should always refer to the master branch (or next if it exists, i. e. after -rc1 is out and before the new merge window is open) in the git://git.denx.de/u-boot.git repository. 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 He had quite a powerful intellect, but it was as powerful like a locomotive, and ran on rails and was therefore almost impossible to steer. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Most ARM CPU's have buggy clear_bss?
Hi list, the code for clearing bss section for most ARM cores looks like this or very similar: clear_bss: #ifndef CONFIG_PRELOADER ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs ldr r3, _TEXT_BASE /* Text base */ mov r4, r7 /* reloc addr */ add r0, r0, r4 add r1, r1, r4 mov r2, #0x /* clear*/ clbss_l:str r2, [r0]/* clear loop...*/ add r0, r0, #4 cmp r0, r1 bne clbss_l #endif /* #ifndef CONFIG_PRELOADER */ IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else. Also relocation code looks a bit strange: .globl relocate_code relocate_code: mov r4, r0 /* save addr_sp */ mov r5, r1 /* save addr of gd */ mov r6, r2 /* save addr of destination */ mov r7, r2 /* save addr of destination */ /* Set up the stack */ stack_setup: mov sp, r4 adr r0, _start ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 - source end address */ cmp r0, r6 beq clear_bss r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this: mov sp, r4 adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 - source end address */ Any comments are welcome! Regards, Darius. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
2010/10/27 Stefano Babic sba...@denx.de: On 10/26/2010 12:35 PM, Jason Liu wrote: static int fec_set_hwaddr(struct eth_device *dev) @@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) uint32_t base; struct fec_priv *fec = (struct fec_priv *)dev-priv; - /* Initialize MAC address */ - fec_set_hwaddr(dev); - Not sure. Why is this call removed ? We have changed the storage for the MAC address, but we need always to set the FEC controller. What is the reason to drop it ? It's because, it will print some floating value of MAC address when bootup and in fact, we don't need re-set it again here.. The net framework will do that. This is why I remove. it. The call was added one month ago. It sets the MAC address any time the network is used, to be sure that the correct MAC is taken even if the ethaddr variable is changed. You can take a look at the patch: http://www.mail-archive.com/u-boot@lists.denx.de/msg37629.html Yes, I haved looked it before and I also tested this patch on MX51babbage 3.0 board. It will printting some confusing information with floating value of MAC address when the board boot up after you set the ethaddr enviorment. The reason is that, when it first call fec_init, the eth address of dev is not intialized and then it using the floating memory value. 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] sparc: add asm/unaligned.h
Wolfgang Denk wrote: Dear Daniel Hellstrom, In message 4cc54d00.6040...@gaisler.com you wrote: Mike Frysinger wrote: It isn't possible to build any sparc boards without this ... I'm working on a new patch set with some of the patches going through the net repo instead, according to Wolfgangs comments. It is probably easier for me to make fewer commits every time submitting, and submitting multiple times. But it looks like a serious bug fix, so it should go in _now_, should it not? True, I will send a pull request since this patch have already been sent on the list two or three times. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] current ARM development head
Dear Alexander Stein, I noticed that there is a lot of changes in ARM part of u-boot. Especially the new relocation is a bit tricky. So I'm wondering what and where is the current ARM development head, especially the at91 part. Is it u-boot master branch or some other repository/branch? As Wolfgang pointed out u-boot/master is where to look at. u-boot-atmel/at91 might be a bit ahead (or back since I don't pull from u-boot/master every day); but new things for at91 might be found there for a few days until the are merged into master. u-boot-atmel/wip (top9000 support) is probably the only working AT91SAM9 port based on current TOT. Note that this is not official, it has not been reviewed by anyone and I just have it there as a reference until all new things have settled down a bit. Then I will officially make it a patch. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: sparc
Dear Wolfgang, Please pull the master branch of the sparc repository. Thanks, Daniel The following changes since commit 11c8dd36edcc82564a19dbd0103302df66d66db0: Stefano Babic (1): FAT: buffer overflow with FAT12/16 are available in the git repository at: git://www.denx.de/git/u-boot-sparc.git master Magnus Sjalander (1): SPARC: added unaligned definitions arch/sparc/include/asm/byteorder.h |1 + arch/sparc/include/asm/unaligned.h | 10 ++ 2 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 arch/sparc/include/asm/unaligned.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI on PPC MPC85xx
Hi Matthias, On Wednesday 27 October 2010 08:55:42 Matthias Dunda wrote: unfortunately I have to push this message, as I received no comment on it, yet. Is there a reason why the immap_t is not implemented for mpc85xx? I tried to copy it from mpc8360 but there are so many dependent mpc83xx datatypes in that struct that I postponed the work on that, because I think it'll lead to no success... Even trying to use the soft SPI fails, because first thing the code does is using that immap_t datatype... :-( Does anyone have a comment on this? I took a quick glance at this. There are different versions of SPI controllers in the MPC8xxx SoC's. As it seems mpc8xxx_spi.c does only support the CPU- mode (meaning non-CPM/QE-mode) Freescale SPI controllers. This controller is implemented for example in the MPC8349. For your SoC (MPC8568) you need to implement the QE-mode which is currently not supported. 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
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
hi, On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote: IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else. snip Also relocation code looks a bit strange: snip r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this: mov sp, r4 adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 - source end address */ Any comments are welcome! Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
Hi, On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi, On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote: IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else. snip Also relocation code looks a bit strange: snip r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this: mov sp, r4 adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 - source end address */ Any comments are welcome! Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not. The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC. Darius. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] GRETH: removed unneccesary register write and one clean up.
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 79bc4d9..4f1973c 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -45,7 +45,7 @@
/* ByPass Cache when reading regs */
#define GRETH_REGLOAD(addr)SPARC_NOCACHE_READ(addr)
/* Write-through cache == no bypassing needed on writes */
-#define GRETH_REGSAVE(addr,data) (*(unsigned int *)(addr) = (data))
+#define GRETH_REGSAVE(addr,data) (*(volatile unsigned int *)(addr) = (data))
#define GRETH_REGORIN(addr,data) GRETH_REGSAVE(addr,GRETH_REGLOAD(addr)|data)
#define GRETH_REGANDIN(addr,data) GRETH_REGSAVE(addr,GRETH_REGLOAD(addr)data)
@@ -146,8 +146,6 @@ int greth_init(struct eth_device *dev, bd_t * bis)
printf(greth_init\n);
#endif
- GRETH_REGSAVE(regs-control, 0);
-
if (!greth-rxbd_base) {
/* allocate descriptors */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] GRETH: Added extra RESET, this is needed if GRETH was stopped during an ethernet frame reception.
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index cb68d45..f081855 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -152,6 +152,16 @@ int greth_init(struct eth_device *dev, bd_t * bis)
debug(greth_init\n);
+ /* Reset core */
+ GRETH_REGSAVE(regs-control, (GRETH_RESET | (greth-gb 8) |
+ (greth-sp 7) | (greth-fd 4)));
+
+ /* Wait for Reset to complete */
+ while ( GRETH_REGLOAD(regs-control) GRETH_RESET) ;
+
+ GRETH_REGSAVE(regs-control,
+ ((greth-gb 8) | (greth-sp 7) | (greth-fd 4)));
+
if (!greth-rxbd_base) {
/* allocate descriptors */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] GRETH: fixed 2 decriptor table typos
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index f081855..0566e68 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -168,7 +168,7 @@ int greth_init(struct eth_device *dev, bd_t * bis)
greth-rxbd_base = (greth_bd *)
memalign(0x1000, GRETH_RXBD_CNT * sizeof(greth_bd));
greth-txbd_base = (greth_bd *)
- memalign(0x1000, GRETH_RXBD_CNT * sizeof(greth_bd));
+ memalign(0x1000, GRETH_TXBD_CNT * sizeof(greth_bd));
/* allocate buffers to all descriptors */
greth-rxbuf_base =
@@ -200,7 +200,7 @@ int greth_init(struct eth_device *dev, bd_t * bis)
for (i = 0; i GRETH_TXBD_CNT; i++) {
greth-txbd_base[i].addr = 0;
/* enable desciptor set wrap bit if last descriptor */
- if (i = (GRETH_RXBD_CNT - 1)) {
+ if (i = (GRETH_TXBD_CNT - 1)) {
greth-txbd_base[i].stat = GRETH_BD_WR;
} else {
greth-txbd_base[i].stat = 0;
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] GRETH: Added autodetection of PHY address, or let BSP hardcode it.
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c | 78 ---
1 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 788aac8..cb68d45 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -42,6 +42,13 @@
#define GRETH_PHY_TIMEOUT_MS 3000
#endif
+/* Default to PHY adrress 0 not not specified */
+#ifdef CONFIG_SYS_GRLIB_GRETH_PHYADDR
+#define GRETH_PHY_ADR_DEFAULT CONFIG_SYS_GRLIB_GRETH_PHYADDR
+#else
+#define GRETH_PHY_ADR_DEFAULT 0
+#endif
+
/* ByPass Cache when reading regs */
#define GRETH_REGLOAD(addr)SPARC_NOCACHE_READ(addr)
/* Write-through cache == no bypassing needed on writes */
@@ -102,12 +109,12 @@ typedef struct {
} greth_priv;
/* Read MII register 'addr' from core 'regs' */
-static int read_mii(int addr, volatile greth_regs * regs)
+static int read_mii(int phyaddr, int regaddr, volatile greth_regs * regs)
{
while (GRETH_REGLOAD(regs-mdio) GRETH_MII_BUSY) {
}
- GRETH_REGSAVE(regs-mdio, (0 11) | ((addr 0x1F) 6) | 2);
+ GRETH_REGSAVE(regs-mdio, ((phyaddr 0x1F) 11) | ((regaddr 0x1F)
6) | 2);
while (GRETH_REGLOAD(regs-mdio) GRETH_MII_BUSY) {
}
@@ -119,14 +126,14 @@ static int read_mii(int addr, volatile greth_regs * regs)
}
}
-static void write_mii(int addr, int data, volatile greth_regs * regs)
+static void write_mii(int phyaddr, int regaddr, int data, volatile greth_regs
* regs)
{
while (GRETH_REGLOAD(regs-mdio) GRETH_MII_BUSY) {
}
GRETH_REGSAVE(regs-mdio,
- ((data 0x) 16) | (0 11) | ((addr 0x1F) 6)
- | 1);
+ ((data 0x) 16) | ((phyaddr 0x1F) 11) |
+ ((regaddr 0x1F) 6) | 1);
while (GRETH_REGLOAD(regs-mdio) GRETH_MII_BUSY) {
}
@@ -214,6 +221,26 @@ int greth_init_phy(greth_priv * dev, bd_t * bis)
greth_regs *regs = dev-regs;
int tmp, tmp1, tmp2, i;
unsigned int start, timeout;
+ int phyaddr = GRETH_PHY_ADR_DEFAULT;
+
+#ifndef CONFIG_SYS_GRLIB_GRETH_PHYADDR
+ /* If BSP doesn't provide a hardcoded PHY address the driver will
+* try to autodetect PHY address by stopping the search on the first
+* PHY address which has REG0 implemented.
+*/
+ for (i=0; i32; i++) {
+ tmp = read_mii(i, 0, regs);
+ if ( (tmp != 0) (tmp != 0x) ) {
+ phyaddr = i;
+ break;
+ }
+ }
+#endif
+
+ /* Save PHY Address */
+ dev-phyaddr = phyaddr;
+
+ debug(GRETH PHY ADDRESS: %d\n, phyaddr);
/* X msecs to ticks */
timeout = usec2ticks(GRETH_PHY_TIMEOUT_MS * 1000);
@@ -225,17 +252,21 @@ int greth_init_phy(greth_priv * dev, bd_t * bis)
/* get phy control register default values */
- while ((tmp = read_mii(0, regs)) 0x8000) {
- if (get_timer(start) timeout)
+ while ((tmp = read_mii(phyaddr, 0, regs)) 0x8000) {
+ if (get_timer(start) timeout) {
+ debug(greth_init_phy: PHY read 1 failed\n);
return 1; /* Fail */
+ }
}
/* reset PHY and wait for completion */
- write_mii(0, 0x8000 | tmp, regs);
+ write_mii(phyaddr, 0, 0x8000 | tmp, regs);
- while (((tmp = read_mii(0, regs))) 0x8000) {
- if (get_timer(start) timeout)
+ while (((tmp = read_mii(phyaddr, 0, regs))) 0x8000) {
+ if (get_timer(start) timeout) {
+ debug(greth_init_phy: PHY read 2 failed\n);
return 1; /* Fail */
+ }
}
/* Check if PHY is autoneg capable and then determine operating
@@ -246,16 +277,16 @@ int greth_init_phy(greth_priv * dev, bd_t * bis)
dev-sp = 0;
dev-auto_neg = 0;
if (!((tmp 12) 1)) {
- write_mii(0, 0, regs);
+ write_mii(phyaddr, 0, 0, regs);
} else {
/* wait for auto negotiation to complete and then check
operating mode */
dev-auto_neg = 1;
i = 0;
- while (!(((tmp = read_mii(1, regs)) 5) 1)) {
+ while (!(((tmp = read_mii(phyaddr, 1, regs)) 5) 1)) {
if (get_timer(start) timeout) {
printf(Auto negotiation timed out.
Selecting default config\n);
- tmp = read_mii(0, regs);
+ tmp = read_mii(phyaddr, 0, regs);
dev-gb = ((tmp 6) 1)
!((tmp 13) 1);
dev-sp = !((tmp 6) 1)
@@ -265,8 +296,8 @@ int greth_init_phy(greth_priv * dev, bd_t *
[U-Boot] [PATCH 2/6] GRETH: made debug printouts use common debug() macro.
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c | 66 +++---
1 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 4f1973c..788aac8 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -24,6 +24,8 @@
* MA 02111-1307 USA
*/
+/* #define DEBUG */
+
#include common.h
#include command.h
#include net.h
@@ -33,8 +35,6 @@
#include ambapp.h
#include asm/leon.h
-/* #define DEBUG */
-
#include greth.h
/* Default to 3s timeout on autonegotiation */
@@ -142,9 +142,8 @@ int greth_init(struct eth_device *dev, bd_t * bis)
greth_priv *greth = dev-priv;
greth_regs *regs = greth-regs;
-#ifdef DEBUG
- printf(greth_init\n);
-#endif
+
+ debug(greth_init\n);
if (!greth-rxbd_base) {
@@ -199,9 +198,7 @@ int greth_init(struct eth_device *dev, bd_t * bis)
/* Enable Transmitter, GRETH will now scan descriptors for packets
* to transmitt */
-#ifdef DEBUG
- printf(greth_init: enabling receiver\n);
-#endif
+ debug(greth_init: enabling receiver\n);
GRETH_REGORIN(regs-control, GRETH_RXEN);
return 0;
@@ -306,10 +303,8 @@ int greth_init_phy(greth_priv * dev, bd_t * bis)
}
auto_neg_done:
-#ifdef DEBUG
- printf(%s GRETH Ethermac at [0x%x] irq %d. Running \
+ debug(%s GRETH Ethermac at [0x%x] irq %d. Running \
%d Mbps %s duplex\n, dev-gbit_mac ? 10/100/1000 : 10/100,
(unsigned int)(regs), (unsigned int)(dev-irq), dev-gb ? 1000 : (dev-sp ? 100
: 10), dev-fd ? full : half);
-#endif
/* Read out PHY info if extended registers are available */
if (tmp 1) {
tmp1 = read_mii(2, regs);
@@ -318,10 +313,8 @@ int greth_init_phy(greth_priv * dev, bd_t * bis)
tmp = tmp2 0xF;
tmp2 = (tmp2 4) 0x3F;
-#ifdef DEBUG
- printf(PHY: Vendor %x Device %xRevision %d\n, tmp1,
+ debug(PHY: Vendor %x Device %xRevision %d\n, tmp1,
tmp2, tmp);
-#endif
} else {
printf(PHY info not available\n);
}
@@ -338,9 +331,9 @@ void greth_halt(struct eth_device *dev)
greth_priv *greth;
greth_regs *regs;
int i;
-#ifdef DEBUG
- printf(greth_halt\n);
-#endif
+
+ debug(greth_halt\n);
+
if (!dev || !dev-priv)
return;
@@ -376,9 +369,9 @@ int greth_send(struct eth_device *dev, volatile void
*eth_data, int data_length)
greth_bd *txbd;
void *txbuf;
unsigned int status;
-#ifdef DEBUG
- printf(greth_send\n);
-#endif
+
+ debug(greth_send\n);
+
/* send data, wait for data to be sent, then return */
if (((unsigned int)eth_data (GRETH_BUF_ALIGN - 1))
!greth-gbit_mac) {
@@ -387,9 +380,6 @@ int greth_send(struct eth_device *dev, volatile void
*eth_data, int data_length)
*/
if (!greth-txbuf) {
greth-txbuf = malloc(GRETH_RXBUF_SIZE);
-#ifdef DEBUG
- printf(GRETH: allocated aligned tx-buf\n);
-#endif
}
txbuf = greth-txbuf;
@@ -455,9 +445,7 @@ int greth_recv(struct eth_device *dev)
unsigned char *d;
int enable = 0;
int i;
-#ifdef DEBUG
-/* printf(greth_recv\n); */
-#endif
+
/* Receive One packet only, but clear as many error packets as there are
* available.
*/
@@ -474,10 +462,9 @@ int greth_recv(struct eth_device *dev)
if (status GRETH_BD_EN) {
goto done;
}
-#ifdef DEBUG
- printf(greth_recv: packet 0x%lx, 0x%lx, len: %d\n,
+
+ debug(greth_recv: packet 0x%lx, 0x%lx, len: %d\n,
(unsigned int)rxbd, status, status GRETH_BD_LEN);
-#endif
/* Check status for errors.
*/
@@ -512,12 +499,12 @@ int greth_recv(struct eth_device *dev)
/* Process the incoming packet. */
len = status GRETH_BD_LEN;
d = (char *)rxbd-addr;
-#ifdef DEBUG
- printf
+
+ debug
(greth_recv: new packet, length: %d. data: %x %x
%x %x %x %x %x %x\n,
len, d[0], d[1], d[2], d[3], d[4], d[5], d[6],
d[7]);
-#endif
+
/* flush all data cache to make sure we're not reading
old packet data */
sparc_dcache_flush_all();
@@ -565,10 +552,9 @@ void greth_set_hwaddr(greth_priv * greth, unsigned char
*mac)
greth-regs-esa_msb = (mac[0] 8) | mac[1];
greth-regs-esa_lsb =
(mac[2] 24) | (mac[3] 16) | (mac[4] 8) | mac[5];
-#ifdef DEBUG
- printf(GRETH: New MAC address:
[U-Boot] [PATCH 6/6] GRETH: removed space in network driver device name.
Signed-off-by: Daniel Hellstrom dan...@gaisler.com
---
drivers/net/greth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 0566e68..6c32226 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -644,9 +644,9 @@ int greth_initialize(bd_t * bis)
/* Make descriptor string */
if (greth-gbit_mac) {
- sprintf(dev-name, GRETH 10/100/GB);
+ sprintf(dev-name, GRETH_10/100/GB);
} else {
- sprintf(dev-name, GRETH 10/100);
+ sprintf(dev-name, GRETH_10/100);
}
/* initiate PHY, select speed/duplex depending on connected PHY */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mcu25: fix out of tree building
Out of tree building of the Netstal hcu4 and hcu5 boards failed like that: Configuring for mcu25 board... Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/mcu25/../common/fixed_sdram.o: No such file or directory Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/mcu25/../common/nm_bsp.o: No such file or directory Adapt (and simplify) the Makefile. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Niklaus Giger niklaus.gi...@netstal.com --- board/netstal/mcu25/Makefile | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/board/netstal/mcu25/Makefile b/board/netstal/mcu25/Makefile index 6722d53..cd62642 100644 --- a/board/netstal/mcu25/Makefile +++ b/board/netstal/mcu25/Makefile @@ -19,24 +19,24 @@ # include $(TOPDIR)/config.mk +ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../common) +endif LIB= $(obj)lib$(BOARD).a -# NOBJS : Netstal common objects -NOBJS = fixed_sdram.o nm_bsp.o -COBJS = $(BOARD).o -SOBJS = +COBJS = $(BOARD).o \ + ../common/fixed_sdram.o \ + ../common/nm_bsp.o -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) $(addprefix ../common/,$(NOBJS:.o=.c)) +SRCS := $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) -NOBJS := $(addprefix $(obj)../common/,$(NOBJS)) -SOBJS := $(addprefix $(obj),$(SOBJS)) -$(LIB):$(OBJS) $(SOBJS) $(NOBJS) - $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) $(NOBJS) +$(LIB):$(OBJS) + $(AR) $(ARFLAGS) $@ $^ clean: - rm -f $(SOBJS) $(OBJS) + rm -f $(OBJS) distclean: clean rm -f $(LIB) core *.bak $(obj).depend -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
On 10/27/2010 09:40 AM, Jason Liu wrote: Yes, I haved looked it before and I also tested this patch on MX51babbage 3.0 board. It will printting some confusing information with floating value of MAC address when the board boot up after you set the ethaddr enviorment. The reason is that, when it first call fec_init, the eth address of dev is not intialized and then it using the floating memory value. Dropping the call is not the solution and works only on the MX51 if the MAC is set into the fuse. Even on the MX51, this is not a general case: it should be always possible to set the ethaddr via the environment without using the fuse. As sure, you should at least see a Warning : MAC addresses don't match if the ethaddr is set to a different value as in the fuse. However, I do not yet understand why the address is not set: fec_probe is called before doing something on the network and at this point the address should be set from fuse. 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] Most ARM CPU's have buggy clear_bss?
hi, On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote: Hi, On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not. The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC. Umm. I am not sure i get you here. If CONFIG_SYS_ARM_WITHOUT_RELOC is not defined, it means we have enabled relocation, so all the address calculation should be w.r.t the relocation address. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
On Wed, Oct 27, 2010 at 11:54 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: hi, On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote: Hi, On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsugh...@gmail.com wrote: Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not. The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC. Umm. I am not sure i get you here. If CONFIG_SYS_ARM_WITHOUT_RELOC is not defined, it means we have enabled relocation, so all the address calculation should be w.r.t the relocation address. No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent. Darius. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_sf: updated to the new environment code
Functions to store/retrieve the environment from a SPI flash was not updated
to the new environment code. The non-redundant case was
not working correctly, reporting Environment SPI flash not initialized
and the code was not compiled clean in the redundant case.
The patch fixes these issue and makes the code more coherent
with other environment storage (nand, flash).
Signed-off-by: Stefano Babic sba...@denx.de
---
common/env_sf.c | 172 +--
1 files changed, 77 insertions(+), 95 deletions(-)
diff --git a/common/env_sf.c b/common/env_sf.c
index fb0c39b..a597b24 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -51,7 +51,7 @@ static ulong env_new_offset = CONFIG_ENV_OFFSET_REDUND;
#define ACTIVE_FLAG 1
#define OBSOLETE_FLAG 0
-#endif /* CONFIG_ENV_ADDR_REDUND */
+#endif /* CONFIG_ENV_OFFSET_REDUND */
DECLARE_GLOBAL_DATA_PTR;
@@ -69,13 +69,6 @@ uchar env_get_char_spec(int index)
}
#if defined(CONFIG_ENV_OFFSET_REDUND)
-void swap_env(void)
-{
- ulong tmp_offset = env_offset;
-
- env_offset = env_new_offset;
- env_new_offset = tmp_offset;
-}
int saveenv(void)
{
@@ -89,8 +82,13 @@ int saveenv(void)
charflag = OBSOLETE_FLAG, new_flag = ACTIVE_FLAG;
if (!env_flash) {
- puts(Environment SPI flash not initialized\n);
- return 1;
+ env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS,
+ CONFIG_ENV_SPI_CS,
+ CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
+ if (!env_flash) {
+ set_default_env(!spi_flash_probe() failed);
+ return 1;
+ }
}
res = (char *)env_new.data;
@@ -102,6 +100,14 @@ int saveenv(void)
env_new.crc = crc32(0, env_new.data, ENV_SIZE);
env_new.flags = ACTIVE_FLAG;
+ if (gd-env_valid == 1) {
+ env_new_offset = CONFIG_ENV_OFFSET_REDUND;
+ env_offset = CONFIG_ENV_OFFSET;
+ } else {
+ env_new_offset = CONFIG_ENV_OFFSET;
+ env_offset = CONFIG_ENV_OFFSET_REDUND;
+ }
+
/* Is the sector larger than the env (i.e. embedded) */
if (CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE) {
saved_size = CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SIZE;
@@ -130,27 +136,9 @@ int saveenv(void)
goto done;
puts(Writing to SPI flash...);
- ret = spi_flash_write(env_flash,
- env_new_offset + offsetof(env_t, data),
- sizeof(env_new.data), env_new.data);
- if (ret)
- goto done;
-
- ret = spi_flash_write(env_flash,
- env_new_offset + offsetof(env_t, crc),
- sizeof(env_new.crc), env_new.crc);
- if (ret)
- goto done;
- ret = spi_flash_write(env_flash,
- env_offset + offsetof(env_t, flags),
- sizeof(env_new.flags), flag);
- if (ret)
- goto done;
-
- ret = spi_flash_write(env_flash,
- env_new_offset + offsetof(env_t, flags),
- sizeof(env_new.flags), new_flag);
+ ret = spi_flash_write(env_flash, env_new_offset,
+ CONFIG_ENV_SIZE, env_new);
if (ret)
goto done;
@@ -161,11 +149,18 @@ int saveenv(void)
goto done;
}
- swap_env();
+ ret = spi_flash_write(env_flash,
+ env_offset + offsetof(env_t, flags),
+ sizeof(env_new.flags), flag);
+ if (ret)
+ goto done;
- ret = 0;
puts(done\n);
+ gd-env_valid = (gd-env_valid == 2 ? 1 : 2);
+
+ printf(Valid environment: %d\n, gd-env_valid);
+
done:
if (saved_buffer)
free(saved_buffer);
@@ -178,7 +173,7 @@ void env_relocate_spec(void)
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1 = NULL;
env_t *tmp_env2 = NULL;
- env_t ep;
+ env_t *ep = NULL;
uchar flag1, flag2;
/* current_env is set only in case both areas are valid! */
int current_env = 0;
@@ -219,90 +214,57 @@ void env_relocate_spec(void)
flag2 = tmp_env2-flags;
}
- if (!crc1_ok !crc2_ok)
- goto err_crc;
- else if (crc1_ok !crc2_ok) {
+ if (!crc1_ok !crc2_ok) {
+ free(tmp_env1);
+ free(tmp_env2);
+ set_default_env(!bad CRC);
+ return;
+ } else if (crc1_ok !crc2_ok) {
gd-env_valid = 1;
ep = tmp_env1;
} else if (!crc1_ok crc2_ok) {
gd-env_valid = 1;
- ep = tmp_env2;
- swap_env();
} else if (flag1 == ACTIVE_FLAG flag2 == OBSOLETE_FLAG) {
gd-env_valid = 1;
- ep = tmp_env1;
} else if (flag1 == OBSOLETE_FLAG flag2 == ACTIVE_FLAG) {
-
[U-Boot] Your Mail ID Has Won £1,000,000.0 0. in The BT PROMO.Send
Name:Country___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: fix dependencies for building NAND_SPL
Building of NAND based boards failed sometimes (especially on MP systems) because of incorrect / missing dependencies. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index b50830a..5c83b07 100644 --- a/Makefile +++ b/Makefile @@ -401,7 +401,7 @@ $(LDSCRIPT):depend $(obj)u-boot.lds: $(LDSCRIPT) $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@ -$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk +$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C nand_spl/board/$(BOARDDIR) all $(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: fix dependencies for building NAND_SPL
Hello Wolfgang, Wolfgang Denk wrote: Building of NAND based boards failed sometimes (especially on MP systems) because of incorrect / missing dependencies. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Tested on the tx25 board: Tested-by: Heiko Schocher h...@denx.de 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] Most ARM CPU's have buggy clear_bss?
On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote: No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent. I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
Hi, Stefano, 2010/10/27 Stefano Babic sba...@denx.de: On 10/27/2010 09:40 AM, Jason Liu wrote: Yes, I haved looked it before and I also tested this patch on MX51babbage 3.0 board. It will printting some confusing information with floating value of MAC address when the board boot up after you set the ethaddr enviorment. The reason is that, when it first call fec_init, the eth address of dev is not intialized and then it using the floating memory value. Dropping the call is not the solution and works only on the MX51 if the MAC is set into the fuse. Even on the MX51, this is not a general case: FSL will program all the fuse with MAC address before shipping every chip. This applies to all the i.mx family including imx25/35/51/53/50. it should be always possible to set the ethaddr via the environment without using the fuse. Yes, without call this function, the ethaddr evnviroment still working. It will use the MAC set via ethaddr instead of the mac from FUSE. Net framework will do it. As sure, you should at least see a Warning : MAC addresses don't match if the ethaddr is set to a different value as in the fuse. However, I do not yet understand why the address is not set: fec_probe is called before doing something on the network and at this point the address should be set from fuse. I have tested it and it's no need to add this function call. You can test it and see the result. 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
[U-Boot] [PATCH v2] [RFC] kirkwood: get rid of config.mk files
After moving the definition of CONFIG_SYS_TEXT_BASE to the respective board config files, all Marvell kirkwood board have just a single and common entry in their config.mk files: KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg Replace the only reference to KWD_CONFIG in the top level Makefile by an equivalent setting, and remove all kirkwood config.mk files. Signed-off-by: Wolfgang Denk wd at denx.de http://lists.denx.de/mailman/listinfo/u-boot Cc: Prafulla Wadaskar prafulla at marvell.com http://lists.denx.de/mailman/listinfo/u-boot Cc: Siddarth Gore gores at marvell.com http://lists.denx.de/mailman/listinfo/u-boot Cc: Simon Kagstrom simon.kagstrom at netinsight.net http://lists.denx.de/mailman/listinfo/u-boot Cc: Heiko Schocher hs at denx.de http://lists.denx.de/mailman/listinfo/u-boot Cc: Eric Cooper ecc at cmu.edu http://lists.denx.de/mailman/listinfo/u-boot Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Hi, this is a (basicly untested) proposal how to clean up support for the kirkwood boards. Unfortunately I have no hardware available to test any of this, so I need your help here. Thanks. Wolfgang Denk Change for v2: 1. board config modifications moved in common config files instead of individual 2. CONFIG_SYS_KWD_CONFIG macro used with provision of refination if needed 2. CONFIG_SYS_TEXT_BASE macro used with provision of refination if needed --- Makefile|2 +- board/Marvell/guruplug/config.mk| 27 - board/Marvell/mv88f6281gtw_ge/config.mk | 28 -- board/Marvell/openrd_base/config.mk | 33 --- board/Marvell/rd6281a/config.mk | 28 -- board/Marvell/sheevaplug/config.mk | 28 -- board/keymile/km_arm/config.mk | 28 -- include/configs/keymile-common.h| 16 +++ include/configs/mv-common.h | 16 +++ 9 files changed, 33 insertions(+), 173 deletions(-) delete mode 100644 board/Marvell/guruplug/config.mk delete mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk delete mode 100644 board/Marvell/openrd_base/config.mk delete mode 100644 board/Marvell/rd6281a/config.mk delete mode 100644 board/Marvell/sheevaplug/config.mk delete mode 100644 board/keymile/km_arm/config.mk diff --git a/Makefile b/Makefile index 06c71a2..62377c1 100644 --- a/Makefile +++ b/Makefile @@ -357,7 +357,7 @@ $(obj)u-boot.imx: $(obj)u-boot.bin -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ $(obj)u-boot.kwb: $(obj)u-boot.bin - $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \ + $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ $(obj)u-boot.sha1: $(obj)u-boot.bin diff --git a/board/Marvell/guruplug/config.mk b/board/Marvell/guruplug/config.mk deleted file mode 100644 index 12d7737..000 --- a/board/Marvell/guruplug/config.mk +++ /dev/null @@ -1,27 +0,0 @@ -# -# (C) Copyright 2009 -# Marvell Semiconductor www.marvell.com -# Written-by: Siddarth Gore go...@marvell.com -# -# See file CREDITS for list of people who contributed to this -# project. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# 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., 51 Franklin Street, Fifth Floor, Boston, -# MA 02110-1301 USA -# - -CONFIG_SYS_TEXT_BASE = 0x0060 - -KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk b/board/Marvell/mv88f6281gtw_ge/config.mk deleted file mode 100644 index 761c2bb..000 --- a/board/Marvell/mv88f6281gtw_ge/config.mk +++ /dev/null @@ -1,28 +0,0 @@ -# -# (C) Copyright 2009 -# Marvell Semiconductor www.marvell.com -# Written-by: Prafulla Wadaskar prafu...@marvell.com -# -# See file CREDITS for list of people who contributed to this -# project. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# 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
[U-Boot] [PATCH 2/5] Serial: Add UART support for Marvell ARMADA 100 SoCs.
From: Prafulla WADASKAR prafu...@marvell.com
ARMADA 100 SoCs has NS16550 compatible UART peripheral
This patch enables the same for ARMADA100 platforms
Signed-off-by: Mahavir Jain mj...@marvell.com
Signed-off-by: Prafulla WADASKAR prafu...@marvell.com
---
drivers/serial/ns16550.c | 16
drivers/serial/serial.c |3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 32f24de..e57ed1f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -26,7 +26,15 @@
void NS16550_init (NS16550_t com_port, int baud_divisor)
{
+#ifdef CONFIG_ARMADA100
+ /*
+* For ARMADA 100 Based Processors bit 6 in IER register
+* represents UART Unit Enable bit.
+*/
+ serial_out((1 6), com_port-ier);
+#else
serial_out(0x00, com_port-ier);
+#endif
#if defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)
serial_out(0x7, com_port-mdr1); /* mode select reset TL16C750*/
#endif
@@ -52,7 +60,15 @@ void NS16550_init (NS16550_t com_port, int baud_divisor)
#ifndef CONFIG_NS16550_MIN_FUNCTIONS
void NS16550_reinit (NS16550_t com_port, int baud_divisor)
{
+#ifdef CONFIG_ARMADA100
+ /*
+* For ARMADA 100 Based Processors bit 6 in IER register
+* represents UART Unit Enable bit.
+*/
+ serial_out((1 6), com_port-ier);
+#else
serial_out(0x00, com_port-ier);
+#endif
serial_out(UART_LCR_BKSE | UART_LCRVAL, com_port-lcr);
serial_out(0, com_port-dll);
serial_out(0, com_port-dlm);
diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 1073ac0..f9a964e 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -33,6 +33,9 @@
#ifdef CONFIG_ORION5X
#include asm/arch/orion5x.h
#endif
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#endif
#if defined (CONFIG_SERIAL_MULTI)
#include serial.h
--
1.7.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/gpio/Makefile |1 +
drivers/gpio/mfp.c| 105 +
include/mfp.h | 97 +
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a0f4552..7590b22 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.a
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP)+= mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..a0278db
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,105 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4: Edge detection configuration
+ * Bits 2-0: Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ /* the offset address are divided in three regions and not
+* consecutive, this corrects the same (Ref: Specs: A1.1) */
+ p_mfpr = (u32 *)MFPR_BASE;
+ if ( mfpr_no 37)
+ p_mfpr += (0x004c / 4) + mfpr_no;
+ else if ( mfpr_no = 56)
+ p_mfpr += (0x00e0 / 4) + (mfpr_no - 56);
+ else
+ p_mfpr += (mfpr_no - 37);
+ /*p_mfpr contains address of register to be programmed */
+
+ val = readl(p_mfpr) ~MFP_AF_MASK;
+ /* Abstract and program Afternate-Function Selection from
cfg_val */
+ if (cfg_val MFP_CFG_AF)
+ val |= cfg_val MFP_AF_MASK;
+ /* Abstract and program Edge configuration from
[U-Boot] [PATCH 5/5] Armada100: Add Board Support for Marvell Aspenite-DB
From: Prafulla WADASKAR prafu...@marvell.com Aspenite is a Development Board for ASPEN/ARMADA168 (88AP168) Processor upto 1.2GHz with * Parallel 1Gb x8 DDR2-1066 MHz * 16 Mb x16 NOR, 4Gb x8 SLC NAND, footprint for SPI NOR * Footprints for eMMC/eSD NAND MMC x8 card * 4-in-1 card reader (xD, MMC/SD/MS Pro), CF True IDE socket * SEAF memory board, subset of PISMO2 With Peripherals: * 4.3” WVGA 24-bit LCD * Audio codecs (AC97 I2S), TSI * VGA camera * Video in via 3 RCA jacks, and HDMI type C out * Marvell 88W8688 802.11bg/BT module * GPS RF IC * Dual analog mics speakers, headset jack, LED, ambient light sensor * USB2.0 HS host (A), OTG (micro AB) * FE PHY, PCIE Mini Card slot * GPIO, GPIO expander with DIP switches for easier selection UART serial over USB, CIR This patch adds basic board support with DRAM and UART functionality The patch is tested for boot from DRAM using XDB Signed-off-by: Mahavir Jain mj...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- MAINTAINERS |1 + MAKEALL |1 + board/Marvell/aspenite/Makefile | 52 ++ board/Marvell/aspenite/aspenite.c | 53 +++ board/Marvell/aspenite/config.mk | 26 +++ boards.cfg|1 + include/configs/aspenite.h| 133 + 7 files changed, 267 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/aspenite/Makefile create mode 100644 board/Marvell/aspenite/aspenite.c create mode 100644 board/Marvell/aspenite/config.mk create mode 100644 include/configs/aspenite.h diff --git a/MAINTAINERS b/MAINTAINERS index 2f61776..ea4121b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -831,6 +831,7 @@ Matt Waddel matt.wad...@linaro.org Prafulla Wadaskar prafu...@marvell.com + aspeniteARM926EJS (ARMADA100 88AP168 SoC) mv88f6281gtw_ge ARM926EJS (Kirkwood SoC) rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) diff --git a/MAKEALL b/MAKEALL index 51312dd..345aa3a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -320,6 +320,7 @@ LIST_ARM9= \ ap926ejs\ ap946es \ ap966 \ + aspenite\ cp920t \ cp922_XA10 \ cp926ejs\ diff --git a/board/Marvell/aspenite/Makefile b/board/Marvell/aspenite/Makefile new file mode 100644 index 000..7ec7727 --- /dev/null +++ b/board/Marvell/aspenite/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2010 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.com +# Contributor: Mahavir Jain mj...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := aspenite.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/aspenite/aspenite.c b/board/Marvell/aspenite/aspenite.c new file mode 100644 index 000..e7bc3eb --- /dev/null +++ b/board/Marvell/aspenite/aspenite.c @@ -0,0 +1,53 @@ +/* + * (C) Copyright 2010 + * Marvell Semiconductor www.marvell.com + * Written-by: Prafulla Wadaskar prafu...@marvell.com + * Contributor: Mahavir Jain mj...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation;
Re: [U-Boot] [PATCH 2/5] Serial: Add UART support for Marvell ARMADA 100 SoCs.
Hi Prafulla,
On Wednesday 27 October 2010 15:53:21 Prafulla Wadaskar wrote:
ARMADA 100 SoCs has NS16550 compatible UART peripheral
This patch enables the same for ARMADA100 platforms
Signed-off-by: Mahavir Jain mj...@marvell.com
Signed-off-by: Prafulla WADASKAR prafu...@marvell.com
---
drivers/serial/ns16550.c | 16
drivers/serial/serial.c |3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 32f24de..e57ed1f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -26,7 +26,15 @@
void NS16550_init (NS16550_t com_port, int baud_divisor)
{
+#ifdef CONFIG_ARMADA100
+ /*
+ * For ARMADA 100 Based Processors bit 6 in IER register
+ * represents UART Unit Enable bit.
+ */
+ serial_out((1 6), com_port-ier);
+#else
serial_out(0x00, com_port-ier);
+#endif
These board/platform specific driver additions are really ugly. A better way
to do this would be something like this:
Add this to your board/platform header:
#define CONFIG_SYS_NS16550_IER (1 6)
And then to ns16550.c or even ns16550.h:
#ifndef CONFIG_SYS_NS16550_IER
#define CONFIG_SYS_NS16550_IER 0x00
#endif
This macro can now be used unconditionally when initializing this ier
register:
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
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
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
On Wed, Oct 27, 2010 at 12:09 PM, Sughosh Ganu sugho...@juniper.net wrote: On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote: No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent. I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address. in case of nand_spl you don't need to to relocation twice because it's done by preloader. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx51evk: support new relocation scheme
This patch is to fix build breakage and support new relocatoin
scheme for mx51evk.
- Correct IRAM base address and add size definition
The IRAM starts from 0x1FFE on final revsion i.mx51 than
0x1FFE8000 which is for older revision.
- Include imx-regs.h in mx51evk.h
Definitions like CSD0_BASE_ADDR and IRAM_BASE_ADDR can be
referred to.
- Define CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE
This is something suggested by Wolfgang, and for automatic
calculation of macros like CONFIG_SYS_GBL_DATA_SIZE (done) and
CONFIG_SYS_INIT_SP_ADDR (later).
- Remove comment for CONFIG_SYS_GBL_DATA_SIZE which has been
buried by Wolfgang's commit below
25ddd1fb: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Signed-off-by: Shawn Guo shawn@gmail.com
---
Changes for v2:
- Combine two patches before into one, as the separation is not
so logical.
- Define init stack at the end of init RAM to address comments
from Stefano, Heiko and Wolfgang.
arch/arm/include/asm/arch-mx5/imx-regs.h |3 ++-
board/freescale/mx51evk/mx51evk.c|6 +++---
include/configs/mx51evk.h|9 +++--
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 3ddda40..0b6249a 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -26,7 +26,8 @@
/*
* IRAM
*/
-#define IRAM_BASE_ADDR 0x1FFE8000 /* internal ram */
+#define IRAM_BASE_ADDR 0x1FFE /* internal ram */
+#define IRAM_SIZE 0x0002 /* 128 KB */
/*
* Graphics Memory of GPU
*/
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index c8d7d39..8820698 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -52,9 +52,9 @@ u32 get_board_rev(void)
int dram_init(void)
{
- gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
- gd-bd-bi_dram[0].size = get_ram_size((long *)PHYS_SDRAM_1,
- PHYS_SDRAM_1_SIZE);
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = get_ram_size((volatile void *)CONFIG_SYS_SDRAM_BASE,
+ PHYS_SDRAM_1_SIZE);
return 0;
}
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index f31fc4e..6dc1ffc 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -24,11 +24,11 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include asm/arch/imx-regs.h
/* High Level Configuration Options */
#define CONFIG_MX51/* in a mx51 */
-#define CONFIG_SKIP_RELOCATE_UBOOT
#define CONFIG_SYS_MX5_HCLK2400
#define CONFIG_SYS_MX5_CLK32 32768
@@ -51,7 +51,6 @@
* Size of malloc() pool
*/
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
-/* size in bytes reserved for initial data */
#define BOARD_LATE_INIT
@@ -174,6 +173,12 @@
#define PHYS_SDRAM_1 CSD0_BASE_ADDR
#define PHYS_SDRAM_1_SIZE (512 * 1024 * 1024)
+#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)
+#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
+#define CONFIG_SYS_INIT_RAM_SIZE (IRAM_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR\
+ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
+
#define CONFIG_SYS_DDR_CLKSEL 0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35100
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
Dear Darius Augulis, In message aanlktimwzv=xbc1s1g8-=d6naj09poqhyp9rxhett...@mail.gmail.com you wrote: I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address. in case of nand_spl you don't need to to relocation twice because it's done by preloader. Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed. 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 Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Serial: Add UART support for Marvell ARMADA 100 SoCs.
-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Wednesday, October 27, 2010 3:24 PM
To: u-boot@lists.denx.de; Prabhanjan Sarnaik
Cc: Prafulla Wadaskar; Manas Saksena; Lei Wen; Eric Miao
Subject: Re: [U-Boot] [PATCH 2/5] Serial: Add UART support for Marvell
ARMADA 100 SoCs.
Hi Prafulla,
On Wednesday 27 October 2010 15:53:21 Prafulla Wadaskar wrote:
ARMADA 100 SoCs has NS16550 compatible UART peripheral
This patch enables the same for ARMADA100 platforms
Signed-off-by: Mahavir Jain mj...@marvell.com
Signed-off-by: Prafulla WADASKAR prafu...@marvell.com
---
drivers/serial/ns16550.c | 16
drivers/serial/serial.c |3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 32f24de..e57ed1f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -26,7 +26,15 @@
void NS16550_init (NS16550_t com_port, int baud_divisor)
{
+#ifdef CONFIG_ARMADA100
+ /*
+* For ARMADA 100 Based Processors bit 6 in IER register
+* represents UART Unit Enable bit.
+*/
+ serial_out((1 6), com_port-ier);
+#else
serial_out(0x00, com_port-ier);
+#endif
These board/platform specific driver additions are really ugly. A better
way
to do this would be something like this:
Add this to your board/platform header:
#define CONFIG_SYS_NS16550_IER(1 6)
And then to ns16550.c or even ns16550.h:
#ifndef CONFIG_SYS_NS16550_IER
#define CONFIG_SYS_NS16550_IER0x00
#endif
This macro can now be used unconditionally when initializing this ier
register:
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
Thanks...
I will do it for next version post.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcu25: fix out of tree building
In message 1288168304-2717-1-git-send-email...@denx.de you wrote: Out of tree building of the Netstal hcu4 and hcu5 boards failed like that: Configuring for mcu25 board... Please s/hcu4 and hcu5 boards/mcu25 board/ in the first line of the commit message. [not resending; will fix when applying, assuming no other comments come in.] 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 Insults are effective only where emotion is present. -- Spock, Who Mourns for Adonais? stardate 3468.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH 0/4] Add support for Freescale's 85xx and P1/P2xxx eSPI controller
On 13/10/2010 9:25 PM, Xie Shaohui-B21989 wrote: Hi Can, Are there any differences between your patches and http://lists.denx.de/pipermail/u-boot/2009-March/049093.html ? Best Regards, Shaohui Xie Hello Shaohui, Firstly, I apologize for responding so late, we've been having some issues with our mail server. In terms of differences, the big trivial one is that any modifications to common code such as spi_flash have been removed from the latest iteration of the patch. It is now just an eSPI driver with support added for cmd_spi in P1_P2_RDB.h. You'll note that the more significant change is that the spi_xfer function works quite differently now; the older version called an 80us delay between the tx and rx buffer accesses and always assumed that the rx buffer had valid data, this caused problems when transferring large amounts data at higher clock rates as tx/rx over-/under-flows would cause data corruption. Hence, additional macros have also been defined for the various register fields that need to be checked for tx/rx buffer states during the read/write cycle. Smaller, more cosmetic changes have also been made to reduce magic numbers and such. I've been trying to send in the v3 submission of the patch for a couple of days now but have not, as yet, succeeded in getting it through. Third time lucky I hope. Regards, Can ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
On 10/27/2010 01:40 PM, Wolfgang Denk wrote: Dear Darius Augulis, In messageaanlktimwzv=xbc1s1g8-=d6naj09poqhyp9rxhett...@mail.gmail.com you wrote: I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address. in case of nand_spl you don't need to to relocation twice because it's done by preloader. Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed. I confess I didn't understant you - why relocation could be needed in case of nand or other preloader? I have been thinking that main and single task of preloader is to copy uboot image from flash memory to main memory (SDRAM) where it's linked to (TEXT_BASE). Why one may need to relocate it twice (and where) ? IMO since uboot image is copied to TEXT_BASE it can run normaly, without fixing any address or relocating somewhere? It's enough to have dummy loader which initializes SDRAM and copies few pages from nand to SDRAM, isn't it? Why should it be more clever? Also I've been thinking that relocation is needed only when booting directly from NOR flash, to have possibility to erase and program flash memory. Could you please point me where I'm wrong? Thanks, Darius Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: consolidate env for mmcboot and netboot
Copy Linaro for comments, as Linaro may be concerned by this patch.
On Mon, Oct 25, 2010 at 11:20 PM, Shawn Guo shawn@gmail.com wrote:
This patch is to consolidate default mx51evk env for two primary
boot modes, mmcboot and netboot.
It also cleans some unused env like netdev, uboot and redundant
env like loadaddr since CONFIG_LOADADDR already defines it.
Signed-off-by: Shawn Guo shawn@gmail.com
---
include/configs/mx51evk.h | 50 ++--
1 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 6165473..186cd8c 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -126,18 +126,42 @@
#define CONFIG_LOADADDR 0x9080 /* loadaddr env var */
-#define CONFIG_EXTRA_ENV_SETTINGS
\
- netdev=eth0\0 \
- uboot_addr=0xa000\0 \
- uboot=u-boot.bin\0 \
- loadaddr=0x9080\0 \
- bootargs_base=setenv bootargs console=tty \
- console=ttymxc0,${baudrate}\0\
- bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs \
- ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0\
- bootcmd=run bootcmd_net\0 \
- bootcmd_net=run bootargs_base bootargs_nfs; \
- tftpboot ${loadaddr} ${kernel}; bootm\0
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ script=boot.scr\0 \
+ uimage=uImage\0 \
+ mmcdev=0\0 \
+ mmcpart=2\0 \
+ mmcroot=/dev/mmcblk0p3 rw\0 \
+ mmcrootfstype=ext3 rootwait\0 \
+ mmcargs=setenv bootargs console=ttymxc0,${baudrate} \
+ root=${mmcroot} \
+ rootfstype=${mmcrootfstype}\0 \
+ loadbootscript= \
+ fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ bootscript=echo Running bootscript from mmc ...; \
+ source\0 \
+ loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0
\
+ mmcboot=echo Booting from mmc ...; \
+ run mmcargs; \
+ bootm\0 \
+ netargs=setenv bootargs console=ttymxc0,${baudrate} \
+ root=/dev/nfs \
+ ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
+ netboot=echo Booting from net ...; \
+ run netargs; \
+ dhcp ${uimage}; bootm\0 \
+
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan ${mmcdev}; then \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loaduimage; then \
+ run mmcboot; \
+ else run netboot; \
+ fi; \
+ fi; \
+ else run netboot; fi
#define CONFIG_ARP_TIMEOUT 200UL
@@ -145,6 +169,8 @@
* Miscellaneous configurable options
*/
#define CONFIG_SYS_LONGHELP /* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
+#define CONFIG_SYS_PROMPT_HUSH_PS2
#define CONFIG_SYS_PROMPT MX51EVK U-Boot
#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */
--
1.7.1
--
Regards,
Shawn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
On 10/27/2010 12:12 PM, Shawn Guo wrote: This patch is to fix build breakage and support new relocatoin scheme for mx51evk. - Correct IRAM base address and add size definition The IRAM starts from 0x1FFE on final revsion i.mx51 than 0x1FFE8000 which is for older revision. - Include imx-regs.h in mx51evk.h Definitions like CSD0_BASE_ADDR and IRAM_BASE_ADDR can be referred to. - Define CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE This is something suggested by Wolfgang, and for automatic calculation of macros like CONFIG_SYS_GBL_DATA_SIZE (done) and CONFIG_SYS_INIT_SP_ADDR (later). - Remove comment for CONFIG_SYS_GBL_DATA_SIZE which has been buried by Wolfgang's commit below 25ddd1fb: Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value Signed-off-by: Shawn Guo shawn@gmail.com Applied to u-boot-imx, thanks. 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] Most ARM CPU's have buggy clear_bss?
Dear Darius Augulis, In message 4cc80609.6040...@gmail.com you wrote: Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed. I confess I didn't understant you - why relocation could be needed in case of nand or other preloader? I have been thinking that main and single task of preloader is to copy uboot image from flash memory to main memory (SDRAM) where it's linked to (TEXT_BASE). Why one may need Yes, but this may or may not be the final position. to relocate it twice (and where) ? IMO since uboot image is copied to TEXT_BASE it can run normaly, without fixing any address or relocating somewhere? It's enough to have dummy loader which initializes SDRAM and copies few pages from nand to SDRAM, isn't it? Why should it be more clever? Assume we use the protected RAM feature, i. e. we reserve memory at the top of RAM. The user does a setenv pram 0x40;saveenv to reserve 4 MB, then does a reboot. So next time the system boots U-Boot must respect the new setting, i. e. it has to be loaded 4 MB below top of RAM. Then user decides he needs 8 MB instead... Also I've been thinking that relocation is needed only when booting directly from NOR flash, to have possibility to erase and program flash memory. Could you please point me where I'm wrong? Relocation is needed to allow to put the U-Boot image to any suitable location in RAM, which is NOT known at compile time, as it may depend on the actual memory size (assume systems that come with different configurations, or where the user can plug in additional or bigger memory modules), and on a number of memory reservations that depende for example on environment variable settings. 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 is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
Dear Shawn Guo, In message 1288174358-14896-1-git-send-email-shawn@gmail.com you wrote: This patch is to fix build breakage and support new relocatoin scheme for mx51evk. - Correct IRAM base address and add size definition The IRAM starts from 0x1FFE on final revsion i.mx51 than 0x1FFE8000 which is for older revision. - Include imx-regs.h in mx51evk.h Definitions like CSD0_BASE_ADDR and IRAM_BASE_ADDR can be referred to. - Define CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE This is something suggested by Wolfgang, and for automatic calculation of macros like CONFIG_SYS_GBL_DATA_SIZE (done) and CONFIG_SYS_INIT_SP_ADDR (later). Um... this is NOT what we discussed. +#define CONFIG_SYS_SDRAM_BASE(PHYS_SDRAM_1) +#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR) +#define CONFIG_SYS_INIT_RAM_SIZE (IRAM_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) + No. This is not what I want to se. Memory allocation in the inital ram has the global data at the top. Please use something like #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) 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 Whoever undertakes to set himself up as a judge of Truth and Know- ledge is shipwrecked by the laughter of the gods. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
On Wed, Oct 27, 2010 at 7:46 PM, Wolfgang Denk w...@denx.de wrote: Dear Shawn Guo, In message 1288174358-14896-1-git-send-email-shawn@gmail.com you wrote: This patch is to fix build breakage and support new relocatoin scheme for mx51evk. - Correct IRAM base address and add size definition The IRAM starts from 0x1FFE on final revsion i.mx51 than 0x1FFE8000 which is for older revision. - Include imx-regs.h in mx51evk.h Definitions like CSD0_BASE_ADDR and IRAM_BASE_ADDR can be referred to. - Define CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE This is something suggested by Wolfgang, and for automatic calculation of macros like CONFIG_SYS_GBL_DATA_SIZE (done) and CONFIG_SYS_INIT_SP_ADDR (later). Um... this is NOT what we discussed. Are you saying that automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen? No. This is not what I want to se. Memory allocation in the inital ram has the global data at the top. Please use something like #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) If the automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen, I can send another patch to fix it, since it's been applied by Stefano already. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
On 10/27/2010 01:54 PM, Shawn Guo wrote: On Wed, Oct 27, 2010 at 7:46 PM, Wolfgang Denk w...@denx.de wrote: Dear Shawn Guo, In message 1288174358-14896-1-git-send-email-shawn@gmail.com you wrote: This patch is to fix build breakage and support new relocatoin scheme for mx51evk. - Correct IRAM base address and add size definition The IRAM starts from 0x1FFE on final revsion i.mx51 than 0x1FFE8000 which is for older revision. - Include imx-regs.h in mx51evk.h Definitions like CSD0_BASE_ADDR and IRAM_BASE_ADDR can be referred to. - Define CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE This is something suggested by Wolfgang, and for automatic calculation of macros like CONFIG_SYS_GBL_DATA_SIZE (done) and CONFIG_SYS_INIT_SP_ADDR (later). Um... this is NOT what we discussed. Are you saying that automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen? No. This is not what I want to se. Memory allocation in the inital ram has the global data at the top. Please use something like #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) If the automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen, I can send another patch to fix it, since it's been applied by Stefano already. Sorry for that. I was too fast and I have not read the patch with attention. I revert the patch after I see Wolfgang's comment. You can send V3 version of this patch and you can forget the applied message. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
Dear Shawn Guo, In message aanlkti=7r4mcsfxpssdu3bur_cnmyzey3mluo2t0-...@mail.gmail.com you wrote: Please use something like #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) If the automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen, I can send another patch to fix it, since it's been applied by Stefano already. Yes, it will. But the stack pointer will not start at the end of the initial ram area, but below the global data area which lies at the end. 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 Always leave room to add an explanation if it doesn't work out. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
Hello Steve, Steve Sakoman wrote: On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Ok, thanks! 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 v2] mx51evk: support new relocation scheme
On Wed, Oct 27, 2010 at 8:23 PM, Wolfgang Denk w...@denx.de wrote: Dear Shawn Guo, In message aanlkti=7r4mcsfxpssdu3bur_cnmyzey3mluo2t0-...@mail.gmail.com you wrote: Please use something like #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) If the automatic calculation of CONFIG_SYS_INIT_SP_ADDR will not happen, I can send another patch to fix it, since it's been applied by Stefano already. Yes, it will. But the stack pointer will not start at the end of the initial ram area, but below the global data area which lies at the end. I thought the manual definition of CONFIG_SYS_INIT_SP_ADDR is the near term solution, since it will be replaced by automatic calculation. So I did not put much attention to reflect the layout you want to see. Anyway, v3 is coming soon. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
Dear Steve Sakoman, In message 1288181563.2342.98.ca...@quadra you wrote: Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. Um... on PowerPC, we need to initialize the stack with a final stack frame (on PPC 2 x 32 bit zero) so that stack backtraces terminate cleanly. Eventually the reserved space was intended for similar purposes, but if so, I cannot see that from the code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The first thing we do is kill all the lawyers. (Shakespeare. II Henry VI, Act IV, scene ii) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: support new relocation scheme
Dear Shawn Guo, In message aanlktinamzbqgkitt=bbphqxnwvshcv2=cckhzyct...@mail.gmail.com you wrote: But the stack pointer will not start at the end of the initial ram area, but below the global data area which lies at the end. I thought the manual definition of CONFIG_SYS_INIT_SP_ADDR is the near term solution, since it will be replaced by automatic calculation. So I did not put much attention to reflect the layout you want to see. Well, we can only calculate this automatically if all boards us the same layout of the internal RAM area. That's why this is needed. 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 more we disagree, the more chance there is that at least one of us is right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote: Hello Steve, Steve Sakoman wrote: On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE 0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Ok, thanks! Now that I have some coffee, I think I see the actual reason that the build was broken. If you look at the error output: start.S: Assembler messages: start.S:175: Error: missing ')' start.S:175: Error: missing ')' start.S:175: Error: garbage following instruction -- `ldr sp,=((0x4020f800+0x800-#96))' It is apparent that the assembler does not like that GENERATED_GBL_DATA_SIZE is defined as #96 I tried without the # symbol and the build completes successfully. I'll prepare a patch to use CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE on the OMAP boards with relocation, because that is still a good idea, but we also need to deal with the prepended # symbol. I'm guessing that the PPC tools don't complain about the # symbol? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mail list threading problem or mailer problem?
Hi Shawn, Let's look at this example. Here is what I see on http://lists.denx.de/pipermail/u-boot/2010-October/thread.html. [...] Is this some problem with u-boot mail list threading itself or the gmail mailer? This is a _feature_ of the pipermail component of GNU mailman. It intentionally limits the indentation depth to 4 in order to keep the html pages readable. Researching somewhat I found that this is intentionally not a user-chageable option and at least one guy reported problems on changing it[1], so I prefer to keep the setting as is ;) Cheers Detlev [1] http://mail.python.org/pipermail/mailman-users/2009-March/065473.html -- A change in language can transform our appreciation of the cosmos -- Benjamin Lee Whorf -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
Hello Steve, Steve Sakoman wrote: On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote: Hello Steve, Steve Sakoman wrote: On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE 0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Ok, thanks! Now that I have some coffee, I think I see the actual reason that the build was broken. If you look at the error output: start.S: Assembler messages: start.S:175: Error: missing ')' start.S:175: Error: missing ')' start.S:175: Error: garbage following instruction -- `ldr sp,=((0x4020f800+0x800-#96))' It is apparent that the assembler does not like that GENERATED_GBL_DATA_SIZE is defined as #96 I tried without the # symbol and the build completes successfully. Already fixed here: http://lists.denx.de/pipermail/u-boot/2010-October/080455.html I'll prepare a patch to use CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE on the OMAP boards with relocation, because that is still a good idea, but we also need to deal with the prepended # symbol. Ok, thanks. 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] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi Remy,
On Wed, 1 Sep 2010 10:49:22 +0200
Remy Bohmer li...@bohmer.net wrote:
...
2010/8/31 Anatolij Gustschin ag...@denx.de:
Checking the status field of the qTD token in the current code
do not take into acount cases where endpoint stall (halted) bit
is set together with some other status bits. As a result clearing
stall on an endpoint won't be done if other status bits were set.
Reading this description and this code:
/* special handling of STALL in DATA phase */
- if ((result 0) (us-pusb_dev-status
USB_ST_STALLED)) {
+ if ((result 0)
+ (us-pusb_dev-status (USB_ST_STALLED |
USB_ST_CRC_ERR))) { USB_STOR_PRINTF(DATA:stall\n);
Description and code do not seem to match. The old implementation
explicitly checked if the STALLED bit was set, and if so the endpoint
would be cleared. Now, it seems you are clearing the endpoint _also_
when the CRC_ERR bit is set.
Yes. This was intentional but unfortunately not directly mentioned
in the patch description. The reason is the following:
in all cases where transaction error (XactErr) was reported with
additionally STALLED bit set, the handling of the STALL condition
successfully recovered from the error case and the device was
recognized.
in cases where only transaction error was reported (STALLED bit
not set) the recovery from the error case didn't succeed and
Device NOT ready (Request Sense returned 06 28 00) status was
finally reported. I didn't find the information in the EHCI spec
how the recovery from the XactErr should be done properly. Do
you know how to handle it?
There are a lot more reasons, at least on other host controllers that
set the status USB_ST_CRC_ERR, does this change not break the other
code? (A simple grep will show you the situations where it is
returned.)
This change will probably break other code. I'll drop it here and
additionally set USB_ST_STALLED flag in the ehci driver instead.
E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
issue showed that while bulk IN transfers with length of 13 or
18 the status field of the qTD token sometimes indicates trans-
action error (XactErr) and sometimes additionally endpoint halted
state. In the latter case resetting the USB device in error
recovery code fails as no clear stall request on the endpoint
will be done.
OK
However this fix is not enough to solve 'usb start' problem
with hub/stick combination mentioned above. Running with lot of
debug code in ehci_submit_async() I've never seen the problem
with usb stick recognition. After removing this debug code the
similar problem sometimes showed up again. Therefore the patch
also adds delay in ehci_submit_async() for above-mentioned
hub/stick combination. Even without this delay the fix is an
Why only for these USB sticks? Are these sticks special among the
thousands of different sticks out there?
I do not have the right equipment to analyze this problem properly.
This is the special USB stick-hub combination. The same USB stick
is always recognized properly if it is connected directly. Other
USB sticks also work with this USB hub.
Or could it be more reliable to always do this delay for all USB
sticks? Or even better, what are we missing here that the delay is
needed at all?
Doing this delay for other USB sticks will negatively affect data
transfer speed.
diff --git a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c index 37d056e..7463a75 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
Is this problem only valid for the EHCI code? I can imagine that the
other host controllers (like UHCI and OHCI and so on) code suffer the
same problem and need similar fixes...
(At least I know that I have here a couple of USB sticks that show
similar problems with OHCI ;-) )
Maybe, maybe not. The problem shows up on SheevaPlug and mpc5121ads
boards, both using USB EHCI. I do not have the possibility to test
it on other host controllers currently.
Best regards,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] omap3evm: Support for quick boot
Default configuration enables multiple features that are great for intial development work. But many of them are not useful when time taken to boot kernel is important - and uboot is frozen. This patch attempts to reduce the size of u-boot binary by excluding unused/not-so-commonly used features/commands. It allows initialization of unused devices to be skipped. Less time to load the binary and selective initialization results in considerable reduction in the boot time. Signed-off-by: Sanjeev Premi pr...@ti.com --- v2: Replaced occurences of fast with quick to avoid any confusion with fastboot in Android. include/configs/omap3_evm.h | 138 +++ 1 files changed, 138 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 271c985..ce681b1 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -378,4 +378,142 @@ extern unsigned int boot_flash_type; #define CONFIG_BOOTP_HOSTNAME 0x0004 #define CONFIG_BOOTP_BOOTPATH 0x0010 +/* + * Support for quick boot + * + * In default build, the feature is disabled. To use the feature: + * 1) Define CONFIG_QUICK_BOOT + * 2) Select the device used as boot medium, by defining one of: + *- CONFIG_QUICK_BOOT_MMC + *- CONFIG_QUICK_BOOT_NAND + */ +#undef CONFIG_QUICK_BOOT +#undef CONFIG_QUICK_BOOT_MMC +#undef CONFIG_QUICK_BOOT_NAND + +#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 + + /* +* Exclude unused/rarely used features. +*/ + #undef CONFIG_SYS_LONGHELP + #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_IMI + #undef CONFIG_CMD_ITEST + #undef CONFIG_CMD_LOADB + #undef CONFIG_CMD_LOADS + #undef CONFIG_CMD_NET + #undef CONFIG_CMD_NFS + #undef CONFIG_CMD_SETGETDCR + #undef CONFIG_CMD_SOURCE + #undef CONFIG_CMD_XIMG + #undef CONFIG_CMD_FPGA + #undef CONFIG_CMD_IMLS + #undef CONFIG_CMD_FLASH + #undef CONFIG_CMD_EXT2 + #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 + + /* +* Select options based on choice of boot medium. +*/ + #ifdef CONFIG_QUICK_BOOT_MMC + #undef CONFIG_NAND_OMAP_GPMC + #undef CONFIG_ENV_IS_IN_NAND + #undef CONFIG_CMD_NAND + #endif + + #ifdef CONFIG_QUICK_BOOT_MMC + #undef CONFIG_ENV_IS_IN_NAND + #undef CONFIG_CMD_NAND + + #undef CONFIG_BOOTCOMMAND + #define CONFIG_BOOTCOMMAND \ + mmc init; \ + fatload mmc 0 0x8000 uImage; \ + bootm 0x8000; + + #undef CONFIG_BOOTARGS + #define CONFIG_BOOTARGS \ + console=ttyS0,115200n8\ + mem=128M quiet noinitrd \ + root=/dev/mmcblk0p2 rw\ + rootfstype=ext3 rootwait + #endif + + #ifdef CONFIG_QUICK_BOOT_NAND + # undef CONFIG_OMAP3_MMC + # undef CONFIG_CMD_MMC + # undef CONFIG_DOS_PARTITION + # undef CONFIG_CMD_FAT + + #undef CONFIG_BOOTCOMMAND + #define CONFIG_BOOTCOMMAND \ + nand read.i 0x8000 28 50; \ + bootm 0x8000; + + #undef CONFIG_BOOTARGS + #define CONFIG_BOOTARGS \ + console=ttyS0,115200n8\ + mem=128M quiet noinitrd \ + root=/dev/mtdblock4 rw\ + rootfstype=jffs2 + #endif + + /* +* Board specific features +* Exclude not-so-common features +*/ + #undef CONFIG_USB_OMAP3 + #undef CONFIG_MUSB_HCD + + #undef CONFIG_USB_STORAGE + #undef CONFIG_USB_KEYBOARD +
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
Dear Sanjeev Premi, In message 1288186611-30656-1-git-send-email-pr...@ti.com you wrote: Default configuration enables multiple features that are great for intial development work. But many of them are not useful when time taken to boot kernel is important - and uboot is frozen. This patch attempts to reduce the size of u-boot binary by excluding unused/not-so-commonly used features/commands. It allows initialization of unused devices to be skipped. Less time to load the binary and selective initialization results in considerable reduction in the boot time. Signed-off-by: Sanjeev Premi pr...@ti.com --- v2: Replaced occurences of fast with quick to avoid any confusion with fastboot in Android. include/configs/omap3_evm.h | 138 +++ 1 files changed, 138 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 271c985..ce681b1 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -378,4 +378,142 @@ extern unsigned int boot_flash_type; #define CONFIG_BOOTP_HOSTNAME0x0004 #define CONFIG_BOOTP_BOOTPATH0x0010 +/* + * Support for quick boot + * + * In default build, the feature is disabled. To use the feature: + * 1) Define CONFIG_QUICK_BOOT + * 2) Select the device used as boot medium, by defining one of: + *- CONFIG_QUICK_BOOT_MMC + *- CONFIG_QUICK_BOOT_NAND + */ +#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. 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. + /* + * Exclude unused/rarely used features. + */ + #undef CONFIG_SYS_LONGHELP + #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_IMI + #undef CONFIG_CMD_ITEST + #undef CONFIG_CMD_LOADB + #undef CONFIG_CMD_LOADS + #undef CONFIG_CMD_NET + #undef CONFIG_CMD_NFS + #undef CONFIG_CMD_SETGETDCR + #undef CONFIG_CMD_SOURCE + #undef CONFIG_CMD_XIMG + #undef CONFIG_CMD_FPGA + #undef CONFIG_CMD_IMLS + #undef CONFIG_CMD_FLASH + #undef CONFIG_CMD_EXT2 + #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. This has the additional benefit that you can actually build both configurations without the need to modify any source files. 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 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
[U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and Heiko Schocher. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- Tested on Overo. Will test on all available boards later today. diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 16d9279..a970ad2 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -222,6 +222,10 @@ #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h index d6fbec7..031de35 100644 --- a/include/configs/igep0030.h +++ b/include/configs/igep0030.h @@ -209,6 +209,10 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 10)) #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index e7d5bd0..076dd5a 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -346,8 +346,11 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif -/* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 052d503..79a5b85 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -325,6 +325,10 @@ extern unsigned int boot_flash_type; #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 9dda2a3..76131fd 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -227,6 +227,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030E000 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h index 36471ba..3d4d3a7 100644 --- a/include/configs/omap4_sdp4430.h +++ b/include/configs/omap4_sdp4430.h @@ -245,6 +245,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030E000 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] da850evm: remove GENERATED_GBL_DATA_SIZE from initial stack
Commit 25ddd1fb0a2281b182529afbc8fda5de2dc16d96 broke the da850evm build. The
introduction of GENERATED_GBL_DATA_SIZE led to:
$make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error| warning)'
Generating include/autoconf.mk
Generating include/autoconf.mk.dep
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for da850evm board...
start.S: Assembler messages:
start.S:177: Error: missing ')'
start.S:177: Error: missing ')'
start.S:177: Error: garbage following instruction -- `ldr
sp,=((0xc000+0x1000-#96))'
make[1]: *** [start.o] Error 1
make: *** [arch/arm/cpu/arm926ejs/start.o] Error 2
make: *** Waiting for unfinished jobs
This patch removes from the definition of CONFIG_SYS_INIT_SP_ADDR the
GENERATED_GBL_DATA_SIZE offset -- it doesn't appear to be needed since the
resulting u-boot works fine; tested with NAND, env.oob and tftp.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Sudhakar Rajashekhara sudhakar@ti.com
CC: Sandeep Paulraj s-paul...@ti.com
--
If GENERATED_GBL_DATA_SIZE were defined as '96' and not '#96' this would also
fix the problem. I assumed that the 'immeadiate' prefix is preferred in the
definition of the GENERATED_GBL_DATA_SIZE macro.
---
include/configs/da850evm.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 7b04be0..2695785 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -191,6 +191,5 @@
/* additions for new relocation code, must added to all boards */
#define CONFIG_SYS_SDRAM_BASE 0xc000
-#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000
- /* Fix this */ \
- GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000)
#endif /* __CONFIG_H */
--
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 RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
Hello Steve, Steve Sakoman wrote: This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and Heiko Schocher. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- Tested on Overo. Will test on all available boards later today. Test this patch on my beagle board, works fine: Tested-by: Heiko Schocher h...@denx.de 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 V3] imx25: Fix reset
Dear Matthias Weisser,
struct wdog_regs {
- u32 wcr;/* Control */
- u32 wsr;/* Service */
- u32 wrsr; /* Reset Status */
- u32 wicr; /* Interrupt Control */
- u32 wmcr; /* Misc Control */
+ u16 wcr;/* Control */
+ u16 wsr;/* Service */
+ u16 wrsr; /* Reset Status */
+ u16 wicr; /* Interrupt Control */
+ u16 wmcr; /* Misc Control */
};
What catches my ARM-aware eye:
I do not know the hardware, but are those registers really
arranged on 2 byte boundaries (00, 02, 04, 06, 08, 0a, .. offsets)?
Probably yes, assuming your code is tested ;)
Or should there be a u16 filler between each register?
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make-asm-offsets: fix sed script
On Wed, Oct 27, 2010 at 2:37 AM, Wolfgang Denk w...@denx.de wrote: When copying the sed script to generate the asm-offsets.h file from the Linux Kbuild script into the make-asm-offsets file I missed the fact that the former runs in a make context and thus uses double $$ to escape a single $, while the latter is a shell script, where this must not be done. Unfortunately the problem did not show up during the initial tests on Power Architecture systems, but on ARM the generated asm-offsets.h was not correct. Signed-off-by: Wolfgang Denk w...@denx.de Applies cleanly to 79e63139368eb7233b738d3d5a0df018a1287e3b of git://git.denx.de/u-boot.git and fixes da850evm build there since 25ddd1fb0a2281b182529afbc8fda5de2dc16d96. Tested on da850evm with NAND, env.oob and tftp. Tested-by: Ben Gardiner bengardi...@nanometrics.ca Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] VoVPN-GW_100MHz: drop unsupported board configuration
[looks like this message got lost, resending] On 2010/10/24 4:00 PM, Wolfgang Denk wrote: The 100MHz configuation of the VoVPN-GW has never been supported, so drop it now. Signed-off-by: Wolfgang Denk w...@denx.de --- This commit shows a problem with the concept of the README.scrapyard file: I'm supposed to enter the commit ID for the commit I'm just about to check in; this cannot work. Hope we remember to clean this up when making the next entries... Anybody having any better ideas? Some clever git attributes trick? How about documenting a git command line for showing when a particular set of lines is added? e.g. git blame doc/README.scrapyard This will show the revision at which a particular line was introduced, and will therefore provide a guide to when the feature was removed. Include the cmdline at the top of the scrapyard file, and it should be fairly self-evident, I would hope. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
Hello Steve, Steve Sakoman wrote: This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and Heiko Schocher. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- Tested on Overo. Will test on all available boards later today. Test this patch on my beagle board, works fine: Tested-by: Heiko Schocher h...@denx.de Should I consider this a bug fix and add it to my tree? I believe the patch itself came after the merge window ended Thanks, Sandeep ___ 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
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? 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] [PATCH] VoVPN-GW_100MHz: drop unsupported board configuration
Dear Rogan Dawes, In message 4cc83d9d@dawes.za.net you wrote: [looks like this message got lost, resending] No, it was not lost, just unreplied. Include the cmdline at the top of the scrapyard file, and it should be fairly self-evident, I would hope. Agreed that this is one of the possible workarounds. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If all the Chinese simultaneously jumped into the Pacific off a 10 foot platform erected 10 feet off their coast, it would cause a tidal wave that would destroy everything in this country west of Nebraska. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
Dear Paulraj, Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5da9d89...@dlee01.ent.ti.com you wrote: Test this patch on my beagle board, works fine: Tested-by: Heiko Schocher h...@denx.de Should I consider this a bug fix and add it to my tree? I believe the patch itself came after the merge window ended Yes, all these are bug fixes needed to get the current code working as expected. Please apply. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A great many people think they are thinking when they are merely re- arranging their prejudices. - William James ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote: Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. Maybe this is the same problem I reported here (commands not found): http://lists.denx.de/pipermail/u-boot/2010-October/080198.html -- Eric Cooper e c c @ c m u . e d u ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] VoVPN-GW_100MHz: drop unsupported board configuration
On 2010/10/27 5:10 PM, Wolfgang Denk wrote: Dear Rogan Dawes, In message 4cc83d9d@dawes.za.net you wrote: [looks like this message got lost, resending] No, it was not lost, just unreplied. Ok, I didn't see it on gmane, so I assumed it had gone astray. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ICACHE in core initialization to improve u-boot boot time: Breaks booting with i2c code while executing in flash.
On 10/20/10 15:50, Wolfgang Denk wrote: Dear Richard Retanubun, In message4cbdc153.30...@ruggedcom.com you wrote: It does not work on our platform (similar to MPC8360EMDS). I think this is specific to our platform because we need to initialize i2c and use i2c while still executing from flash in checkboard()) to read and parse a board-id i2c-eeprom to support a unified uboot binary for multiple board flavors. Many boards do that. Some keep the environment in I2C EEPROM as well. This should not collide With instruction caches on. Just an FYI mostly, I am okay with not having ICACHE for our board while in uboot. Just curious if you know of a reason from the limited explanation I've provided. Check how your boot device (NOR flash) is mapped - make sure it has the BI (burst inhibit) bit set (or whatever it may be called on that CPU). Thanks for taking the time Wolfgang, now you got me curious, so I did a little reading. For MPC8360MDS reference board access the NOR flash in GPCM (General Purpose Control Machine) mode which does not have a burst inhibit bit, only the UPM mode of the local bus controller have this. The only other place 'inhibit' is mentioned that would make sense is the Block Address Translation (BAT) my settings are identical to MPC8360MDS with one exception, MDS maps flash to BAT3 (considered low-BAT) mine is on BAT6 (considered high-BAT), and yes my HID1 register setting enables the high-BATs. Not sure how any of these matters, though. Another observation I've made is by turning on CONFIG_DISPLAY_AER_FULL or CONFIG_DISPLAY_AER_BRIEF and printing it from cpu_init.c:prt_83xx_rsr() causes the same checkboard() function to fail accessing the i2c-eeprom, even though the contents are correct. However, if I move the printf of: printf(AEATR=0x%08lX, AEADR=0x%08lX\n, gd-arbiter_event_attributes, gd-arbiter_event_address); Into checkboard() (before i2c early init, all works okay) So there seems to be a sensitivity in fsl-i2c drive while running from flash during early init although I am too ignorant to suspect anything right now. Thanks for everyone's time... - Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
On Wed, Oct 27, 2010 at 5:21 AM, Jason Liu liu.h.ja...@gmail.com wrote: Hi, Stefano, 2010/10/27 Stefano Babic sba...@denx.de: On 10/27/2010 09:40 AM, Jason Liu wrote: Yes, I haved looked it before and I also tested this patch on MX51babbage 3.0 board. It will printting some confusing information with floating value of MAC address when the board boot up after you set the ethaddr enviorment. The reason is that, when it first call fec_init, the eth address of dev is not intialized and then it using the floating memory value. Dropping the call is not the solution and works only on the MX51 if the MAC is set into the fuse. Even on the MX51, this is not a general case: FSL will program all the fuse with MAC address before shipping every chip. This applies to all the i.mx family including imx25/35/51/53/50. it should be always possible to set the ethaddr via the environment without using the fuse. Yes, without call this function, the ethaddr evnviroment still working. It will use the MAC set via ethaddr instead of the mac from FUSE. Net framework will do it. As sure, you should at least see a Warning : MAC addresses don't match if the ethaddr is set to a different value as in the fuse. However, I do not yet understand why the address is not set: fec_probe is called before doing something on the network and at this point the address should be set from fuse. I have tested it and it's no need to add this function call. You can test it and see the result. 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 The patch fixes the particular case where you have no ethaddr in fuse, nor persistent env. The case is a board where the only persistent storage is an SD card and you set load a boot script from file in a FAT partition that has a setenv ethaddr in it. The other case is if a user sets the ethaddr at the command line it will not take effect until reboot in the case of persistent env or never in the case of no persistent env. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
Dear John, In message aanlktikmzvasvw1wtwg7od9qyeaphhwdbc+3ox5ak...@mail.gmail.com you wrote: The patch fixes the particular case where you have no ethaddr in fuse, nor persistent env. The case is a board where the only persistent storage is an SD card and you set load a boot script from file in a Well, if ther eis no MAC address in the fuse, and there is no ethaddr setting in the current environment, then nothing should happen until you try to run the first network command, at wich point the command should fail because the MAC address is unset. FAT partition that has a setenv ethaddr in it. The other case is if a user sets the ethaddr at the command line it will not take effect until reboot in the case of persistent env or never in the case of no persistent env. This is broken behaviour; in this case, the network driver needs to be fixed. The driver initialization takes place when you start a network command, and it should pick up the MAC address setting then, mo matter if this was permanently stored or just entered on the command line. 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 child is a person who can't understand why someone would give away a perfectly good kitten. - Doug Larson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] post/drivers/i2c.c: fix compile error
In message 1288128370-2556-1-git-send-email...@denx.de you wrote: Commit 7e263ce post/i2c: Clean up detection logic added a const qualifier to the declaration of i2c_addr_list[], missing the fact that the list gets modified later in the code, which results in build errors like these: i2c.c: In function 'i2c_post_test': i2c.c:88: error: assignment of read-only location Remove the incorrect const. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Peter Tyser pty...@xes-inc.com Cc: Heiko Schocher h...@denx.de --- post/drivers/i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs. - Joseph Weizenbaum, _Computer Power and Human Reason_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Most ARM CPU's have buggy clear_bss?
Hi Eric, On 10/27/2010 06:12 PM, Eric Cooper wrote: On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote: Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. Maybe this is the same problem I reported here (commands not found): http://lists.denx.de/pipermail/u-boot/2010-October/080198.html looks similar, but not exactly the same. Mine output: U-Boot 2010.09-00560-g5b4d583-dirty (Oct 27 2010 - 21:00:13) for MINI6410 U-Boot code: 57E0 - 57E2BDE4 BSS: - 57E31680 CPU: s3c6...@532mhz Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz (SYNC Mode) Board: MINI6410 monitor len: 00031680 ramsize: 0800 TLB table at: 57ff Top of RAM usable for U-Boot at: 57ff Reserving 197k for U-Boot at: 57fbe000 Reserving 1280k for malloc() at: 57e7e000 Reserving 24 Bytes for Board Info at: 57e7dfe8 Reserving 92 Bytes for Global Data at: 57e7df8c New Stack Pointer is: 57e7df88 RAM Configuration: Bank #0: 5000 128 MiB relocation Offset is: 001be000 monitor flash len: 0002BDE4 Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught 256 MiB Using default environment Destroy Hash Table: 57e31568 table = (null) Create Hash Table: N=79 INSERT: table 57e31568, filled 1/79 rv 57e7f42c == name=bootargs value=console=ttySAC,115200 INSERT: table 57e31568, filled 2/79 rv 57e7f348 == name=bootcmd value=nand read 0x50018000 0x6 0x1c;bootm 0x50018000 INSERT: table 57e31568, filled 3/79 rv 57e7f438 == name=bootdelay value=3 INSERT: table 57e31568, filled 4/79 rv 57e7f378 == name=baudrate value=115200 INSERT: free(data = 57e7f2a0) INSERT: done In:serial Out: serial Err: serial Net: dm9000 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd=nand read 0x50018000 0x6 0x1c;bootm 0x50018000 Hit any key to stop autoboot: 0 MINI6410 # help Unknown command 'help' - try 'help' MINI6410 # I'm doing support for new board, so there could be some bugs in its config. But I still thinking that clear_bss code is buggy, because uboot reboots is DEBUG if defined and following simple patch isn't applied: diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 7f32db7..8337c4b 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -379,13 +379,16 @@ clear_bss: #ifndef CONFIG_PRELOADER ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs - ldr r3, _TEXT_BASE /* Text base */ +#ifdef CONFIG_SKIP_RELOCATE_UBOOT + ldr r4, _TEXT_BASE /* Text base */ +#else mov r4, r7 /* reloc addr */ +#endif add r0, r0, r4 add r1, r1, r4 - mov r2, #0x /* clear */ + mov r2, #0x /* clear */ -clbss_l:strr2, [r0]/* clear loop... */ +clbss_l:strr2, [r0]/* clear loop */ add r0, r0, #4 cmp r0, r1 bne clbss_l If DEBUG isn't defined then it does not reboot, but commands are missing in both cases. Unfortunately this patch does not solve this problem. I've calculated bss start and end addresses with and without '#ifdef CONFIG_SKIP_RELOCATE_UBOOT' and they are wrong without it. Darius. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcu25: fix out of tree building
Dear Wolfgang Denk, In message 1288168304-2717-1-git-send-email...@denx.de you wrote: Out of tree building of the Netstal hcu4 and hcu5 boards failed like that: Configuring for mcu25 board... Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/mcu25/../common/fixed_sdram.o: No such file or directory Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/mcu25/../common/nm_bsp.o: No such file or directory Adapt (and simplify) the Makefile. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Niklaus Giger niklaus.gi...@netstal.com --- board/netstal/mcu25/Makefile | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) Applied (with the ...of the Netstal mcu25 board... fix) 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 Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, The City on the Edge of Forever, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make-asm-offsets: fix sed script
In message 1288161467-2979-1-git-send-email...@denx.de you wrote: When copying the sed script to generate the asm-offsets.h file from the Linux Kbuild script into the make-asm-offsets file I missed the fact that the former runs in a make context and thus uses double $$ to escape a single $, while the latter is a shell script, where this must not be done. Unfortunately the problem did not show up during the initial tests on Power Architecture systems, but on ARM the generated asm-offsets.h was not correct. Signed-off-by: Wolfgang Denk w...@denx.de --- tools/scripts/make-asm-offsets |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de None of our men are experts. We have most unfortunately found it necessary to get rid of a man as soon as he thinks himself an expert -- because no one ever considers himself expert if he really knows his job. A man who knows a job sees so much more to be done than he has done, that he is always pressing forward and never gives up an instant of thought to how good and how efficient he is. Thinking always ahead, thinking always of trying to do more, brings a state of mind in which nothing is impossible. The moment one gets into the expert state of mind a great number of things become impossible. - From Henry Ford Sr., My Life and Work, p. 86 (1922) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: fix dependencies for building NAND_SPL
In message 1288170898-3332-1-git-send-email...@denx.de you wrote: Building of NAND based boards failed sometimes (especially on MP systems) because of incorrect / missing dependencies. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Intel told us the Pentium would have RISK features... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] add Multi Fnction Pin configuration support for ARMADA100
Dear Prafulla Wadaskar, In message 1288187604-3371-5-git-send-email-prafu...@marvell.com you wrote: This patch adds the support MFP support for Marvell ARMADA100 SoCs Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- There is a typo in the Subject: please s/Fnction/Function/ [No need to repost beause of this; this can be fixed when the patch gets comitted.] 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 My challenge to the goto-less programmer is to recode tcp_input() without any gotos ... without any loss of efficiency (there has to be a catch). - W. R. Stevens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Armada100: Add Board Support for Marvell Aspenite-DB
Dear Prafulla Wadaskar, In message 1288187604-3371-6-git-send-email-prafu...@marvell.com you wrote: ... --- MAINTAINERS |1 + MAKEALL |1 + board/Marvell/aspenite/Makefile | 52 ++ board/Marvell/aspenite/aspenite.c | 53 +++ board/Marvell/aspenite/config.mk | 26 +++ boards.cfg|1 + include/configs/aspenite.h| 133 + 7 files changed, 267 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/aspenite/Makefile create mode 100644 board/Marvell/aspenite/aspenite.c create mode 100644 board/Marvell/aspenite/config.mk create mode 100644 include/configs/aspenite.h Please don't create a config.mk file any more (move CONFIG_SYS_TEXT_BASE setting to board config file), and please also do not create an entry to MAKEALL (gets auto-generated from boards.cfg). Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is not that the nature of men and women -- that the pleasure is in the learning of each other? -- Natira, the High Priestess of Yonada, For the World is Hollow and I Have Touched the Sky, stardate 5476.3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_sf: updated to the new environment code
Dear Stefano Babic, In message 1288170380-32580-1-git-send-email-sba...@denx.de you wrote: Functions to store/retrieve the environment from a SPI flash was not updated to the new environment code. The non-redundant case was not working correctly, reporting Environment SPI flash not initialized and the code was not compiled clean in the redundant case. The patch fixes these issue and makes the code more coherent with other environment storage (nand, flash). Signed-off-by: Stefano Babic sba...@denx.de --- common/env_sf.c | 172 +-- 1 files changed, 77 insertions(+), 95 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This is an unauthorized cybernetic announcement. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: sparc
Dear Daniel Hellstrom, In message 4cc7da61.5010...@gaisler.com you wrote: The following changes since commit 11c8dd36edcc82564a19dbd0103302df66d66db0: Stefano Babic (1): FAT: buffer overflow with FAT12/16 are available in the git repository at: git://www.denx.de/git/u-boot-sparc.git master Magnus Sjalander (1): SPARC: added unaligned definitions arch/sparc/include/asm/byteorder.h |1 + arch/sparc/include/asm/unaligned.h | 10 ++ 2 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 arch/sparc/include/asm/unaligned.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Humanity has the stars in its future, and that future is too important to be lost under the burden of juvenile folly and ignorant superstition. - Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] mmc: seperate block number into small parts for multi-write cmd
Dear Lei Wen, In message 1287034691-26278-1-git-send-email-lei...@marvell.com you wrote: Constraint the mmc framework to only send no more than 65535 blocks in one go during the multi-write command. This constraint comes due to the limitation of 16bit width block counter register at some hardware. Signed-off-by: Lei Wen lei...@marvell.com Cc: Reinhard Meyer u-b...@emk-elektronik.de --- V4: clean patch V3: return to the V1 solution that keep the 65535 constraint, but cut the 512KiB dma limitation V2: add additional members in mmc structure drivers/mmc/mmc.c | 54 ++-- 1 files changed, 39 insertions(+), 15 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have made mistakes, but have never made the mistake of claiming I never made one. - James G. Bennet ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Dear Alessandro Rubini, In message 20101026214042.ga2...@morgana.i.gnudd.com you wrote: I am not convinced, as we don't have an array context here. But sizeof(struct x) doesn't depend on how struct x is used. You can declare a pointer and then allocate for an array. I don't see that with struct foo x; struct foo y[N]; we have a guarantee that sizeof(x) == sizeof(y[0]). Yes, I see this requirement. But maybe we're already bikeshedding: I won't get offended if you keep the global +15 ~15. Please let me get -rc1 out, and all the urgent problems fixed first. I will try to keep this in mind and re-check when there is a little more time. Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm growing older, but not up. - Jimmy Buffett ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] cmd_onenand.c: Fix command usage help.
Dear Enric Balletbo i Serra, In message 1287479602-21721-2-git-send-email-eballe...@iseebcn.com you wrote: Running the onenand command without arguments does nothing, with this patch shows the command usage. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- common/cmd_onenand.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This all sounds complicated, but it mostly does excatly what you ex- pect. It's just difficult for us to explain what you expect... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10 v2] net: rtl8169: Add initialized eth_device structure
Dear Nobuhiro Iwamatsu, In message aanlktintt5pd40-z+rvywyf303ng9cmte6wpao_r2...@mail.gmail.com you wrote: Could you take in these patches? Are these bug fixes, or can they wait for the next branch? 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 One friend in a lifetime is much; two are many; three are hardly possible. Friendship needs a certain parallelism of life, a community of thought, a rivalry of aim. - Henry Brook Adams ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
On Wed, Oct 27, 2010 at 2:06 PM, Wolfgang Denk w...@denx.de wrote: Dear John, In message aanlktikmzvasvw1wtwg7od9qyeaphhwdbc+3ox5ak...@mail.gmail.com you wrote: The patch fixes the particular case where you have no ethaddr in fuse, nor persistent env. The case is a board where the only persistent storage is an SD card and you set load a boot script from file in a Well, if ther eis no MAC address in the fuse, and there is no ethaddr setting in the current environment, then nothing should happen until you try to run the first network command, at wich point the command should fail because the MAC address is unset. FAT partition that has a setenv ethaddr in it. The other case is if a user sets the ethaddr at the command line it will not take effect until reboot in the case of persistent env or never in the case of no persistent env. This is broken behaviour; in this case, the network driver needs to be fixed. The driver initialization takes place when you start a network command, and it should pick up the MAC address setting then, mo matter if this was permanently stored or just entered on the command line. Thanks for saying this because this is exactly what my original patch fixes. So the fix should stay. 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 child is a person who can't understand why someone would give away a perfectly good kitten. - Doug Larson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI on PPC MPC85xx
On Wed, 27 Oct 2010 08:55:42 +0200 Matthias Dunda user...@t1817.greatnet.de wrote: Hi again, unfortunately I have to push this message, as I received no comment on it, yet. Is there a reason why the immap_t is not implemented for mpc85xx? immap_t gets to be a mess of ifdefs when you're trying to support a bunch of different chips with slight differences, not to mention having to manage all the reserved regions with obscure size values to keep everything in the right spot (versus a simple offset of the start of a register block that can be easily compared to the manual). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] mmc: seperate block number into small parts for multi-write cmd
On Wed, Oct 27, 2010 at 11:39 AM, Wolfgang Denk w...@denx.de wrote: Dear Lei Wen, In message 1287034691-26278-1-git-send-email-lei...@marvell.com you wrote: Constraint the mmc framework to only send no more than 65535 blocks in one go during the multi-write command. This constraint comes due to the limitation of 16bit width block counter register at some hardware. Signed-off-by: Lei Wen lei...@marvell.com Cc: Reinhard Meyer u-b...@emk-elektronik.de --- V4: clean patch V3: return to the V1 solution that keep the 65535 constraint, but cut the 512KiB dma limitation V2: add additional members in mmc structure drivers/mmc/mmc.c | 54 ++-- 1 files changed, 39 insertions(+), 15 deletions(-) Applied, thanks. Thanks Wolfgang! I'll get to work on a revised multi-block read implementation. A 4x speedup in large MMC reads is worth the effort! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Standalone Apps: Standalone apps should need only exports.h.
Modify exports.h to remove its dependencies on other files, thus enabling standalone apps to require only exports.h from the U-Boot source tree. This appears to be the intent based on the following note: http://lists.denx.de/pipermail/u-boot/2010-January/067174.html Signed-off-by: Mike Partington mpart...@lexmark.com --- Changes for v2: - Replace domain specific email address with generic address examples/standalone/atmel_df_pow2.c |1 + examples/standalone/stubs.c |1 + include/exports.h |5 + 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/examples/standalone/atmel_df_pow2.c b/examples/standalone/atmel_df_pow2.c index b5b4503..2e14aba 100644 --- a/examples/standalone/atmel_df_pow2.c +++ b/examples/standalone/atmel_df_pow2.c @@ -8,6 +8,7 @@ #include common.h #include exports.h +#include spi.h #define CMD_ID0x9f #define CMD_STAT 0xd7 diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c index 2d2e709..1ebe43b 100644 --- a/examples/standalone/stubs.c +++ b/examples/standalone/stubs.c @@ -1,3 +1,4 @@ +#include common.h #include exports.h #ifndef GCC_VERSION diff --git a/include/exports.h b/include/exports.h index 7404a7c..01b83dc 100644 --- a/include/exports.h +++ b/include/exports.h @@ -3,8 +3,6 @@ #ifndef __ASSEMBLY__ -#include common.h - /* These are declarations of exported functions available in C code */ unsigned long get_version(void); int getc(void); @@ -12,7 +10,7 @@ int tstc(void); void putc(const char); void puts(const char*); int printf(const char* fmt, ...); -void install_hdlr(int, interrupt_handler_t*, void*); +void install_hdlr(int, void (*interrupt_handler_t)(void *), void*); void free_hdlr(int); void *malloc(size_t); void free(void*); @@ -30,7 +28,6 @@ int ustrtoul(const char *cp, char **endp, unsigned int base); int i2c_write (uchar, uint, int , uchar* , int); int i2c_read (uchar, uint, int , uchar* , int); #endif -#include spi.h void app_startup(char * const *); -- 1.7.3.5.g4a3b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
