Re: [U-Boot] Timer implementations
Dear J. William Campbell, Hi All, I am pretty sure the migration to 64 bits was caused by 1) people not understanding that the timer operating on time DIFFERENCES would work fine even if the underlying timer wrapped around (most probable problem) and possibly 2) broken timer functions causing bogus timeouts, improperly fixed by switching to 64 bits. I think u-boot could get along just fine with only 2 time related functions, uint_32 get_timer(uint_32 base) and udelay(uint 32 delay). udelay will only work on small values of delay, on the order of milliseconds. It is to be used when a short but precise delay in microsecond resolution is required. Users of get_timer must understand that it is only valid if it is called often enough, i.e. at least once per period of the underlying timer. This is required because u-boot does not want to rely on interrupts as a timer update method. Therefore, all uses of get_timer must 1) call it once initially to get a start value, and 2) call get_timer at least once per period of the underlying hardware counter. This underlying period is guaranteed to be at least 4.29 seconds (32 bit counter at 4 GHz). Note that this does NOT mean that the total wait must be less than 4.29 seconds, only that the rate at which the elapsed time is TESTED must be adequate. In order to implement this functionality, at least one hardware timer of some kind is required. An additional software timer in 1 ms resolution may be useful in maintaining the software time. If the hardware timer update rate is programmable, u-boot MAY set the update rate on initialization On initialization, u-boot MAY reset the hardware timer and MAY reset any associated software timer. The hardware timer MAY be started on initialization. On each call to get_timer(), u-boot MUST start the hardware timer if it was not started already. On calls to get_timer, u-boot MUST NOT reset the hardware timer if it was already started. The software timer MAY be reset if u-boot can unambiguously determine that more than 4.29 seconds has elapsed since the last call to get_timer. The simplest case for implementing this scheme is if two programmable timers exist that can be set to 1ms and 1us. The timers are initialized at start-up, get_timer just returns the 32 bit 1 ms timer and udelay just waits for the number of ticks required on the second timer to elapse. The most common harder case is where there is only one timer available, it is running at 1 us per tick or faster, and we cannot control the rate. udelay is still easy, because we can convert the (small) delay in us to a delay in ticks by a 32 bit multiply that will not overflow 32 bits even if we have quite a few fractional bits in the tics per microsecond value. The elapsed ticks required is the (delay in us * us/per tick) # fractional bits in us/per tick. If that is not close enough for you, you can do it as (delay in us * (integer part of us/tick)) + ((delay in us * (fractional part)us/tick) # fraction bits). For nice numbers, like any integral number of MHz, there is no fractional part. Only numbers like 66 MHz, or 1.666 GHz require messing with the fractional part. For get_timer, it is a bit harder. The program must keep two 32 bit global variables, the timer reading last time and the software timer in 1 ms resolution. Whenever get_timer is called, it must increase the software timer by the number of ms that have elapsed since the previous update and record the corresponding timer reading as the new last time. Note that if the number of ms elapsed is not an integer (a common case), the value recorded as the last time must be decreased by the number of ticks not included in the 1 ms resolution software timer. There are many different ways to accomplish update, depending on what hardware math capabilities are available, and whether one thinks efficiency is important here. Conceptually, you convert the elapsed time in ticks into an equivalent number of ms, add that number to the software timer, store the current value of the hardware timer in last time, and subtract any remainder ticks from that value. If the elapsed time is les s that one ms, do no update of last hardware time and return the current software counter. If the elapsed time is greater than 4.29 seconds, reset the software counter to 0, record the current hardware counter time and return the current software counter. In between, do the math, which will fit into 32 bits. If this idea seems like a good one, I can provide more detail on the conversions for various hardware capabilities is people want. Comments welcome. To get the timer mess cleaned up three things have to happen: 1. A consensus and documentation how it MUST be handled 2. Fix all timer implementations to adhere to that 3. Fix all timer uses to adhere to that To start, RFC: a) udelay(u32) MUST NOT interfere with other
Re: [U-Boot] [STATUS] v2010.12-rc1 released
Dear Heiko Schocher, In message 4cc9113d.4090...@denx.de you wrote: I miss this patch: http://lists.denx.de/pipermail/u-boot/2010-October/079340.html Acked and tested from Steve here: http://lists.denx.de/pipermail/u-boot/2010-October/079395.html Yes, I miss that, too. But it's strictly OMAP related, so it has to go through Sandeep's tree. He hasn't sent a pull request yet. 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 Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this res- pect they outnumber all the other known creatures about four to one. -- Professor Snope's Encyclopedia of Animal ___ 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, Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature) I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working before relocation. Have a look at your timer implementation. Best Regards, Reinhard ___ 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?
Hello Darius, Darius Augulis wrote: 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? Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Here you are right. I think r3 is an artifact from the GOT relocation. This should be reworked (added Albert Aribaud to cc, because he did the elf relocation work) 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. If you have defined CONFIG_SKIP_RELOCATE_UBOOT, yes. Please remove this define. 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! Yep, please send a patch for this issue. 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?
Hello Reinhard, Reinhard Meyer wrote: Dear Darius, Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature) I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working before relocation. Have a look at your timer implementation. Huh.. thought the elf relocation fixed this problem? 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 28.10.2010 08:17, Heiko Schocher wrote: Hello Reinhard, Reinhard Meyer wrote: Dear Darius, Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature) I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation. Huh.. thought the elf relocation fixed this problem? 2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue. Reinhard ___ 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 28.10.2010 08:20, Reinhard Meyer wrote: On 28.10.2010 08:17, Heiko Schocher wrote: Hello Reinhard, Reinhard Meyer wrote: Dear Darius, Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature) I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation. Huh.. thought the elf relocation fixed this problem? 2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue. OK, I should have mentioned, that those variables are values that are calculated _before_ relocation in timer_init and needed to have those values for any subsequent timer use before and after relocation... Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
The following changes since commit 908614f20f7f0f5df736eed21b88e81ebbf14e86: Prepare v2010.12-rc1 (2010-10-27 22:49:13 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Mike Frysinger (2): Blackfin: fix building after asm-offsets.h intro Blackfin: config.mk: drop manual stripping of config vars arch/blackfin/config.mk|2 -- arch/blackfin/include/asm/config.h |3 +++ 2 files changed, 3 insertions(+), 2 deletions(-) ___ 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?
Hello Reinhard, Reinhard Meyer wrote: On 28.10.2010 08:20, Reinhard Meyer wrote: On 28.10.2010 08:17, Heiko Schocher wrote: Hello Reinhard, Reinhard Meyer wrote: Dear Darius, Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature) I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation. Huh.. thought the elf relocation fixed this problem? 2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue. OK, I should have mentioned, that those variables are values that are calculated _before_ relocation in timer_init and needed to have those values for any subsequent timer use before and after relocation... Ah, ok! 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?
Dear Heiko Schocher, Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files? All unmaintained ARM boards are now broken anyway, and those that are fixed are using elf relocation. (I know that there is a 'promise' to keep ARM_WITHOUT_RELOC until next March, but does that really make sense anymore?) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Add generic support for samsung s3c2440
Dear C Nauman, On 26 October 2010 23:04, C Nauman cnau...@diagraph.com wrote: This patch adds generic support for the Samsung s3c2440 processor. Global s3c24x0 changes to struct members converting from upper case to lower case. Signed-off-by: Craig Nauman cnau...@diagraph.com Cc: kevin.morf...@fearnside-systems.co.uk --- - v5 Resend - v4 Further cosmetic changes - v3 Fixup style problems checkpatch.pl yields one error from David's name - v2 Fix global s3c24x0 struct members to lower case as requested by Minkyu - v1 Start from patch posted by Kevin Morfitt 2009-06-19 arch/arm/cpu/arm920t/s3c24x0/speed.c | 30 +- arch/arm/cpu/arm920t/s3c24x0/timer.c | 23 +- arch/arm/cpu/arm920t/s3c24x0/usb.c | 10 +- arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c | 12 +- arch/arm/include/asm/arch-s3c24x0/s3c2440.h | 161 ++ arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 672 +-- arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h | 2 + board/mpl/vcma9/vcma9.c | 41 +- board/samsung/smdk2400/smdk2400.c | 28 +- board/samsung/smdk2410/smdk2410.c | 36 +- board/sbc2410x/sbc2410x.c | 44 +- board/trab/cmd_trab.c | 28 +- board/trab/rs485.c | 40 +- board/trab/trab.c | 67 ++-- board/trab/trab_fkt.c | 142 +++--- board/trab/tsc2000.c | 39 +- board/trab/tsc2000.h | 86 ++-- board/trab/vfd.c | 90 ++-- drivers/i2c/s3c24x0_i2c.c | 102 ++-- drivers/mtd/nand/s3c2410_nand.c | 25 +- drivers/rtc/s3c24x0_rtc.c | 52 +- drivers/serial/serial_s3c24x0.c | 26 +- 22 files changed, 1016 insertions(+), 740 deletions(-) create mode 100644 arch/arm/include/asm/arch-s3c24x0/s3c2440.h applied to u-boot-samsung Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ 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, Stefan Roese schrieb: 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. I didn't compare the MPC85xx QE SPI controller with the MPC8xx CPM SPI controller, but maybe a look at arch/powerpc/cpu/mpc8xx/spi.c could help you as a base for porting/creating a driver? -- Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
-Original Message- From: Kristoffer Ericson kristoffer.eric...@gmail.com Reply-to: Kristoffer Ericson kristoffer.eric...@gmail.com To: w...@denx.de Cc: u-boot@lists.denx.de Subject: [U-Boot] Kernel OOPS on memcpy - bad memory setup? Date: Wed, 27 Oct 2010 23:46:41 +0200 Greetings, Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere else, but dont have any large binaries (busybox). So, I assume I have made some memory error in u-boot? Best wishes Kristoffer Dear Kristoffer, I experienced a similar problem when U-Boot configured the SDRAM controller incorrectly, so only half of the memory was being refreshed. Regards, Chris. -- Chris Isbell Systems Integration Manager, CDSRail Fareham, Hampshire, UK. ___ 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/28/2010 09:36 AM, Reinhard Meyer wrote: Dear Heiko Schocher, Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files? All unmaintained ARM boards are now broken anyway, and those that are fixed are using elf relocation. (I know that there is a 'promise' to keep ARM_WITHOUT_RELOC until next March, but does that really make sense anymore?) Are we going to drop possibility to avoid relocation at all? In spite of there are some simple systems which would never need relocation and which prefer fast boot up time and simplicity rather than features like PRAM or dynamically changing memory size? Also there are lot of boards booting from nand, and very likely there would appear more such systems in future. They do relocation already in preloader and there are no chance to avoid to do it twice. In this case U-Boot is going to become big, fat and slow, high featured bootloader suitable for complex systems but not for simple ones which in most cases need only to boot kernel as fast as possible. I would prefer to think about reworking existing code rather than removing it at all. Darius. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6] MTD/SPI: add support for Ramtron FRAMs
On Thursday, October 14, 2010 20:43:13 Mike Frysinger wrote: On Thursday, October 14, 2010 09:33:21 Reinhard Meyer wrote: Supports most types that support Read-Id and the FM25H20. Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- changes since V5: rebased on current MASTER this matches what's already in my branch, so if you've tested this, i'll push it over to Wolfgang ping ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6] MTD/SPI: add support for Ramtron FRAMs
Dear Mike Frysinger, On Thursday, October 14, 2010 20:43:13 Mike Frysinger wrote: On Thursday, October 14, 2010 09:33:21 Reinhard Meyer wrote: Supports most types that support Read-Id and the FM25H20. Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de --- changes since V5: rebased on current MASTER this matches what's already in my branch, so if you've tested this, i'll push it over to Wolfgang ping ... Sorry I missed that this was a question :) Sure it works here, and I would not post patches that are not tested :) However do to current lack of boards equipped with a range of different Ramtron parts I could only test the FM25H20 case which is the non-jedec variant. As soon as I get hold of another jedec conformant Ramtron part, I'll try it, and if that unexpectedly does not get recognized I'll submit a fix. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-samsung/master
Dear Wolfgang Denk, Please pull u-boot-samsung/master. Thanks The following changes since commit b485556be51d1edae0a2c0065e2f572ca42a1eee: John Rigby (1): ARM: enable device tree for beagle are available in the git repository at: git://git.denx.de/u-boot-samsung master C Nauman (1): Add generic support for samsung s3c2440 Jaehoon Chung (1): s5p_mmc: support 8-bit bus width Minkyu Kang (1): ARMV7: S5P: serial: support the s5pc210 arch/arm/cpu/arm920t/s3c24x0/speed.c| 30 +- arch/arm/cpu/arm920t/s3c24x0/timer.c| 23 +- arch/arm/cpu/arm920t/s3c24x0/usb.c | 10 +- arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c | 12 +- arch/arm/include/asm/arch-s3c24x0/s3c2440.h | 161 ++ arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 672 +-- arch/arm/include/asm/arch-s3c24x0/s3c24x0_cpu.h |2 + arch/arm/include/asm/arch-s5pc1xx/mmc.h |2 +- arch/arm/include/asm/arch-s5pc1xx/uart.h| 14 +- board/mpl/vcma9/vcma9.c | 41 +- board/samsung/goni/goni.c |2 +- board/samsung/smdk2400/smdk2400.c | 28 +- board/samsung/smdk2410/smdk2410.c | 36 +- board/sbc2410x/sbc2410x.c | 44 +- board/trab/cmd_trab.c | 28 +- board/trab/rs485.c | 40 +- board/trab/trab.c | 67 ++-- board/trab/trab_fkt.c | 142 +++--- board/trab/tsc2000.c| 39 +- board/trab/tsc2000.h| 86 ++-- board/trab/vfd.c| 90 ++-- drivers/i2c/s3c24x0_i2c.c | 102 ++-- drivers/mmc/s5p_mmc.c | 19 +- drivers/mtd/nand/s3c2410_nand.c | 25 +- drivers/rtc/s3c24x0_rtc.c | 52 +- drivers/serial/serial_s3c24x0.c | 26 +- drivers/serial/serial_s5p.c |6 +- 27 files changed, 1048 insertions(+), 751 deletions(-) create mode 100644 arch/arm/include/asm/arch-s3c24x0/s3c2440.h ___ 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 4cc91e8e.8030...@gmail.com you wrote: Are we going to drop possibility to avoid relocation at all? In spite of Yes, definitely. We will keep the handling of the special case thatthe relocation offset is zero, so that an additional copy can be avoided, but that's all. there are some simple systems which would never need relocation and which prefer fast boot up time and simplicity rather than features like PRAM or dynamically changing memory size? When the relocation offset is zero there shouldnot be any significant delay. Also there are lot of boards booting from nand, and very likely there would appear more such systems in future. They do relocation already in preloader and there are no chance to avoid to do it twice. Same argument. In this case U-Boot is going to become big, fat and slow, high featured bootloader suitable for complex systems but not for simple ones which in most cases need only to boot kernel as fast as possible. If you make such a statement I would like that you come up with proven, measured facts, i. e. how much time / size does it cost on your specific small system? 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 For every complex problem, there is a solution that is simple, neat, and wrong. - Mark Twain ___ 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 Heiko Schocher, In message 4cc914d8.4070...@denx.de you wrote: Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. ___ 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?
Hello Wolfgang, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc914d8.4070...@denx.de you wrote: Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other? I thought, that with relocation we always relocate, so we don;t need longer CONFIG_SKIP_RELOCATE_UBOOT ... ? 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?
Am 28.10.2010 11:03, schrieb Alexander Holler: Hello, Am 27.10.2010 09:26, schrieb Darius Augulis: the code for clearing bss section for most ARM cores looks like this or very similar: ... [some code from start.S] Currently I'm analyzing the same problem (on a kirkwood based hw). It turns out not to be a problem of clear_bss, but a problem of the relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along with binutils 2.20.1 and it seems that some stuff is not relocated. It looks like the BSS before relocation is used (e.g. for nand_chip in drivers/mtd/nand.c), but the BSS after relocation might be cleared (in start.S). I assume it's because of some fixups start.S doesn't know about. But I don't know anything about those fixups, and have to read. So I still have no solution. Just as a pointer. To verify the problem: Add #define DEBUG in top of arch/arm/lib/board.c and printf(nand_chip: %p\n,, nand_chip[0]); in nand_init() in drivers/mtd/nand/nand.c and have a look at the output when u-boot comes up. Regards, Alexander ___ 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?
Hello, Am 27.10.2010 09:26, schrieb Darius Augulis: the code for clearing bss section for most ARM cores looks like this or very similar: ... [some code from start.S] Currently I'm analyzing the same problem (on a kirkwood based hw). It turns out not to be a problem of clear_bss, but a problem of the relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along with binutils 2.20.1 and it seems that some stuff is not relocated. It looks like the BSS before relocation is used (e.g. for nand_chip in drivers/mtd/nand.c), but the BSS after relocation might be cleared (in start.S). I assume it's because of some fixups start.S doesn't know about. But I don't know anything about those fixups, and have to read. So I still have no solution. Just as a pointer. Regards, Alexander ___ 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
-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 -- Applied to u-boot-marvell.git master branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] Kirkwood: bugfix: broken early console messages
-Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Wednesday, October 20, 2010 11:25 PM To: u-boot@lists.denx.de Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH V2] Kirkwood: bugfix: broken early console messages It has been observed that, the complete u-boot banner does not appear on the console when the system is booted from NAND/NOR/SPI flash. This patch fixes this issue on all Marvell boards by adding board_early_init_f() support Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: Whitespace removed from configuration comments board/Marvell/guruplug/guruplug.c |6 +- board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |6 +- board/Marvell/openrd_base/openrd_base.c |6 +- board/Marvell/rd6281a/rd6281a.c |6 +- board/Marvell/sheevaplug/sheevaplug.c |6 +- include/configs/mv-common.h |1 + 6 files changed, 26 insertions(+), 5 deletions(-) Applied to u-boot-marvell.git master branch Regards.. Prafulla. . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [RFC] kirkwood: get rid of config.mk files
-Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Wednesday, October 27, 2010 7:18 PM To: u-boot@lists.denx.de Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH v2] [U-Boot] [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 Applied to u-boot-marvell.git master branch with modifications to cc info Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Does U-boot supports STM28W160C NOR Flash?
Hello, I am having a board with MCF5485 Coldfire processor. I cannot save the parameters in uboot. Whether Uboot support STM28W160C NOR flash. I having a error shown below while saving the uboot parameters. - save Saving Environment to Flash... . done Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... Flash not Erased . done Protected 1 sectors U-Boot 2010.06-rc2 (Oct 26 2010 - 13:23:00) CPU: Freescale MCF5485 CPU CLK 200 MHz BUS CLK 100 MHz Board: Freescale FireEngine 5485 EVB I2C: ready DRAM: 64 MiB FLASH: 18 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: FEC0, FEC1 regards, Sudeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is the Numonyx's M29W128 fully supported in U-Boot?
txema lopez tlopez at aotek.es writes: Hi all, We have a MPC5200B custom board and we are evaluating the Numonyx M29W128 Flash as a second source for the Spansion's S29GL128. I've checked the top of the tree version of the U-Boot (u-boot.git) CFI driver and the Numonyx Flash is not detected. This is the U-Boot debug output: Hi, Did you manage to solve this problem eventually? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Kirkwood: bugfix: DRAM size initialization
-Original Message-
From: Tanmay Upadhyay [mailto:tanmay.upadh...@einfochips.com]
Sent: Friday, October 15, 2010 5:28 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Tanmay Upadhyay
Subject: [PATCH v2] Kirkwood: bugfix: DRAM size initialization
If start of any DRAM bank is greater than total DDR size, remaining
DDR banks' start address size were left un-initialized in dram_init
function. This could break other functions who uses array
'gd-bd-bi_dram'. Kirkwood network driver is one example. This also
stops Linux kernel from booting.
v2 - Set start address also to 0. Without this Linux kernel couldn't
boot up
Signed-off-by: Tanmay Upadhyay tanmay.upadh...@einfochips.com
---
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 7439c87..a4344b8 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -81,6 +81,16 @@ int dram_init(void)
gd-ram_size += gd-bd-bi_dram[i].size;
}
+
+ for (; i CONFIG_NR_DRAM_BANKS; i++) {
+ /* If above loop terminated prematurely, we need to set
+ * remaining banks' start address size as 0. Otherwise other
+ * u-boot functions and Linux kernel gets wrong values which
+ * could result in crash */
+ gd-bd-bi_dram[i].start = 0;
+ gd-bd-bi_dram[i].size = 0;
+ }
+
return 0;
}
Applied to u-boot-marvell.git master branch
Regards..
Prafulla . .
___
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?
Hello, Am 28.10.2010 10:39, schrieb Wolfgang Denk: Dear Heiko Schocher, In message4cc914d8.4070...@denx.de you wrote: Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other? I've got confused by that too. Currently there are 3 defines in regard to relocation: CONFIG_SYS_ARM_WITHOUT_RELOC CONFIG_RELOC_FIXUP_WORKS CONFIG_SKIP_RELOCATE_UBOOT Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_sf: remove warning introduced with last patch
Signed-off-by: Stefano Babic sba...@denx.de --- common/env_sf.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/env_sf.c b/common/env_sf.c index a597b24..e5e0166 100644 --- a/common/env_sf.c +++ b/common/env_sf.c @@ -272,7 +272,7 @@ int saveenv(void) u32 saved_size, saved_offset; char *saved_buffer = NULL; u32 sector = 1; - int ret; + int ret = 1; env_t env_new; char*res; ssize_t len; -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX51: remove warning in clock.c
The patch removes the warning:
clock.c:291: warning: initialization from incompatible pointer type
after constification of args[]
Signed-off-by: Stefano Babic sba...@denx.de
---
arch/arm/cpu/armv7/mx5/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 00f649c..0b04a88 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -269,7 +269,7 @@ u32 imx_get_fecclk(void)
/*
* Dump some core clockes.
*/
-int do_mx5_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mx5_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
u32 freq;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Small default of 8MB for CONFIG_SYS_BOOTM_LEN
Hello, is there a reason why CONFIG_SYS_BOOTM_LEN is defined to 8MB by default? I've build me a kernel containing a small initramfs (just busybox and some modules) and already hit that limit (for having a bootable kernel which doesn't need anything else). If raising that limit doesn't consume any memory, I would like it to have something around 16MB or even larger. That would eleminate the need to rebuild u-boot just for such a use case. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
Hi Sughosh, [...] * hawkboard_nand_config - Used to generate the secondary bootloader(nand_spl) image. This creates an elf file u-boot-spl under nand_spl/. Create an AIS signed image using this file, and flash it to the nand flash at address 0x2. The ais file should fit in one block. Could you elaborate on create an AIS signed image a little bit for people who are not intimately familiar with this architecture? Maybe you can add a small doc/README.da8xx for that purpose? * hawkboard_uart_config - This is same as the first image, but with the TEXT_BASE as expected by the RBL(0xc108). Create the AIS Signed bin, as use the normal UART boot procedure to boot the image. Again a short step-by-step instruction in a readme file would be a very valuable addition. Thanks Detlev -- UN Resolution by the General Assembly on December 31, 1988 condemning Terrorism Wherever and by Whomever Committed: 153 votes to 2. The two voting /against/ the resolution were the US and Israel... -- 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] Small default of 8MB for CONFIG_SYS_BOOTM_LEN
Am 28.10.2010 12:46, schrieb Alexander Holler: Hello, is there a reason why CONFIG_SYS_BOOTM_LEN is defined to 8MB by default? I've build me a kernel containing a small initramfs (just busybox and some modules) and already hit that limit (for having a bootable kernel which doesn't need anything else). If raising that limit doesn't consume any memory, I would like it to have something around 16MB or even larger. That would eleminate the need to rebuild u-boot just for such a use case. Sorry, I'm thinking to slowly, so I have to send another mail. Maybe (size of available DRAM)/2 or something similiar would be reasonable. Having looked at some code, it seems it's nowhere checked if that limit hits any other limits (e.g. on machines which just have 8MB). Regards, Alexander ___ 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 Alexander Holler, Am 28.10.2010 10:39, schrieb Wolfgang Denk: Dear Heiko Schocher, In message4cc914d8.4070...@denx.de you wrote: Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete? sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other? I've got confused by that too. Currently there are 3 defines in regard to relocation: CONFIG_SYS_ARM_WITHOUT_RELOC Introduced by Heiko as a try to unbreak old boards that are not converted to relocation yet. Basically it #else's between the old code and the new code. As far as I understand that define won't work anymore because of several other changes in u-boot that necessitate fixing the affected boards. CONFIG_RELOC_FIXUP_WORKS Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice. CONFIG_SKIP_RELOCATE_UBOOT The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address. In an up to date ARM system all those defines MUST NOT be set. Best Regards, Reinhard ___ 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
On 10/27/2010 04:34 PM, Matthias Weisser wrote: This patch fixes the reset command on imx25. The watchdog registers are 16 bits in size and not 32. This patch also adds the service register codes as constants. Signed-off-by: Matthias Weisser weiss...@arcor.de --- Changes since V2 - Using 16 bit constants Changes since V1 - Corrected whitespace - Leaving reset sequence as it originally was arch/arm/cpu/arm926ejs/mx25/reset.c |8 arch/arm/include/asm/arch-mx25/imx-regs.h | 14 -- 2 files changed, 12 insertions(+), 10 deletions(-) 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] [PATCH] mx51evk: consolidate env for mmcboot and netboot
On 10/25/2010 05:20 PM, Shawn Guo 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 --- 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] [PATCH] mx51evk: Fix 2 hours reset issue
On 10/27/2010 05:36 PM, shawn@freescale.com wrote: From: Shawn Guo shawn@gmail.com The mx51evk u-boot has an issue that system will get reset every 2 hours. MC13892 has an inside charge timer which expires in 120 minutes. If ICHRG and CHGAUTOB are not set properly, this timer expiration will get system power recycled. Since mx51evk has no Li-Ion battery on board, the patch sets ICHRG in externally powered mode and sets CHGAUTOB bit to avoid automatic charging, so that system will not get reset by this timer expiration. The patch also corrects the bit field definition of register 48 (Charger 0) per latest MC13892 Reference Manual. 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] [PATCH v3] mx51evk: support new relocation scheme
On 10/28/2010 04:13 AM, shawn@freescale.com wrote: From: Shawn Guo shawn@gmail.com This patch is to fix build breakage and support new relocation 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 They are used to define init RAM layout. - 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
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Wolfgang, please pull from u-boot-imx The following changes since commit 908614f20f7f0f5df736eed21b88e81ebbf14e86: Prepare v2010.12-rc1 (2010-10-27 22:49:13 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Jason Liu (1): MX5:use common u-boot.lds of cpu layer Matthias Weisser (1): imx25: Fix reset Shawn Guo (3): mx51evk: Fix 2 hours reset issue mx51evk: consolidate env for mmcboot and netboot mx51evk: support new relocation scheme Stefano Babic (2): MX51: add CONFIG_SYS_TEXT_BASE to vision2 board, use general ld script MX51: remove warning in clock.c arch/arm/cpu/arm926ejs/mx25/reset.c |8 ++-- arch/arm/cpu/armv7/mx5/clock.c|2 +- arch/arm/cpu/armv7/mx5/u-boot.lds | 73 - arch/arm/include/asm/arch-mx25/imx-regs.h | 14 +++-- arch/arm/include/asm/arch-mx5/imx-regs.h |3 +- board/freescale/mx51evk/config.mk |1 - board/freescale/mx51evk/mx51evk.c | 14 +++--- board/ttcontrol/vision2/config.mk |4 +- include/configs/mx51evk.h | 62 +++-- include/mc13892.h | 16 +++--- 10 files changed, 80 insertions(+), 117 deletions(-) delete mode 100644 arch/arm/cpu/armv7/mx5/u-boot.lds -- = 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 Reinhard Meyer, In message 4cc95b9e.3040...@emk-elektronik.de you wrote: I've got confused by that too. Currently there are 3 defines in regard to relocation: CONFIG_SYS_ARM_WITHOUT_RELOC Introduced by Heiko as a try to unbreak old boards that are not converted to relocation yet. Basically it #else's between the old code and the new code. As far as I understand that define won't work anymore because of several other changes in u-boot that necessitate fixing the affected boards. CONFIG_RELOC_FIXUP_WORKS Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice. Sure? My understanding is that it MUST be set since we have elf_reloc? And I see this: arch/arm/include/asm/config.h:#define CONFIG_RELOC_FIXUP_WORKS CONFIG_SKIP_RELOCATE_UBOOT The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address. In an up to date ARM system all those defines MUST NOT be set. My understanding is that CONFIG_SYS_ARM_WITHOUT_RELOC and CONFIG_SKIP_RELOCATE_UBOOT should not be set (and I don;t know what happens if you do), but CONFIG_RELOC_FIXUP_WORKS is automaticlly set for all ARM systems now. 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 Two wrongs don't make a right, but three rights make a left. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?
Am 28.10.2010 13:16, schrieb Reinhard Meyer: CONFIG_SKIP_RELOCATE_UBOOT The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address. In an up to date ARM system all those defines MUST NOT be set. Thanks for that explanation. In regard to CONFIG_SKIP_RELOCATE_UBOOT I've hit a typo in arch/arm/cpu/arm926ejs/start.S while trying to use this define to build a non relocatable u-boot. In line 383 there is ldr pc, r0 which seems to should be ldr pc, [r0] But after fixing that I've just run into other problems compiling u-boot with CONFIG_SKIP_RELOCATE_UBOOT defined. I don't send a patch, because I assume that code is just dead will be eliminated in the near future. Regards, Alexander ___ 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 Wolfgang Denk, CONFIG_RELOC_FIXUP_WORKS Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice. Sure? My understanding is that it MUST be set since we have elf_reloc? Sorry, of course that *MUST* be set. My mistake. The Logic is inverted here: FIXUP_WORKS = do not do any extra fixups ;) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] UBIFS: Add padded size to ubifsload output
ubifsload pads with 0's to a multiple of 4096 bytes while reading a file to memory. This patch adds this additional output to the command output. Example: = ubifsload 100 test.txt Loading file 'test.txt' to addr 0x0100 with size 25 (padded to 4096)... Done Signed-off-by: Stefan Roese s...@denx.de --- fs/ubifs/ubifs.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c index 3fc7990..8215443 100644 --- a/fs/ubifs/ubifs.c +++ b/fs/ubifs/ubifs.c @@ -677,8 +677,8 @@ int ubifs_load(char *filename, u32 addr, u32 size) size = inode-i_size; count = (size + UBIFS_BLOCK_SIZE - 1) UBIFS_BLOCK_SHIFT; - printf(Loading file '%s' to addr 0x%08x with size %d (0x%08x)...\n, - filename, addr, size, size); + printf(Loading file '%s' to addr 0x%08x with size %d (padded to %d)...\n, + filename, addr, size, count * UBIFS_BLOCK_SIZE); page.addr = (void *)addr; page.index = 0; -- 1.7.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] UBIFS: Add ubifsumount command to unmount an active volume
This new ubifsumount command allows the user to unmount a previously
mounted UBIFS volume.
Signed-off-by: Stefan Roese s...@denx.de
---
common/cmd_ubifs.c | 31 +++
fs/ubifs/super.c |2 +-
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index a0ec184..30b23d3 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -33,12 +33,17 @@
#include config.h
#include command.h
+#include ../fs/ubifs/ubifs.h
+
static int ubifs_initialized;
static int ubifs_mounted;
+extern struct super_block *ubifs_sb;
+
/* Prototypes */
int ubifs_init(void);
int ubifs_mount(char *vol_name);
+void ubifs_umount(struct ubifs_info *c);
int ubifs_ls(char *dir_name);
int ubifs_load(char *filename, u32 addr, u32 size);
@@ -67,6 +72,26 @@ int do_ubifs_mount(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return 0;
}
+int do_ubifs_umount(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ if (argc != 1)
+ return cmd_usage(cmdtp);
+
+ if (ubifs_initialized == 0) {
+ printf(No UBIFS volume mounted!\n);
+ return -1;
+ }
+
+ if (ubifs_sb)
+ ubifs_umount(ubifs_sb-s_fs_info);
+
+ ubifs_sb = NULL;
+ ubifs_mounted = 0;
+ ubifs_initialized = 0;
+
+ return 0;
+}
+
int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
char *filename = /;
@@ -132,6 +157,12 @@ U_BOOT_CMD(
);
U_BOOT_CMD(
+ ubifsumount, 1, 0, do_ubifs_umount,
+ unmount UBIFS volume,
+ - unmount current volume
+);
+
+U_BOOT_CMD(
ubifsls, 2, 0, do_ubifs_ls,
list files in a directory,
[directory]\n
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 39e3efe..63b2164 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -824,7 +824,7 @@ out_free:
* through mounting (error path cleanup function). So it has to make sure the
* resource was actually allocated before freeing it.
*/
-static void ubifs_umount(struct ubifs_info *c)
+void ubifs_umount(struct ubifs_info *c)
{
dbg_gen(un-mounting UBI device %d, volume %d, c-vi.ubi_num,
c-vi.vol_id);
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] UBIFS: Change ubifs mount to ubifsmount in ubifsls output
Signed-off-by: Stefan Roese s...@denx.de
---
common/cmd_ubifs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index 30b23d3..9526780 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -98,7 +98,7 @@ int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
int ret;
if (!ubifs_mounted) {
- printf(UBIFS not mounted, use ubifs mount to mount volume
first!\n);
+ printf(UBIFS not mounted, use ubifsmount to mount volume
first!\n);
return -1;
}
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ftpmu010: move ftpmu010 power controller to drivers/power folder
Move the header file and definitions of ftpmu010
power control unit from a320 SoC folder to
drivers/power folder.
This change will let other SoC which also use ftpmu010
could share the same header file.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
arch/arm/cpu/arm920t/a320/timer.c |2 +-
arch/arm/include/asm/arch-a320/ftpmu010.h | 146 -
drivers/power/ftpmu010.h | 146 +
3 files changed, 147 insertions(+), 147 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-a320/ftpmu010.h
create mode 100644 drivers/power/ftpmu010.h
diff --git a/arch/arm/cpu/arm920t/a320/timer.c
b/arch/arm/cpu/arm920t/a320/timer.c
index d2e316f..4718ae6 100644
--- a/arch/arm/cpu/arm920t/a320/timer.c
+++ b/arch/arm/cpu/arm920t/a320/timer.c
@@ -19,7 +19,7 @@
#include common.h
#include asm/io.h
-#include asm/arch/ftpmu010.h
+#include ../../../../../drivers/power/ftpmu010.h
#include asm/arch/fttmr010.h
static ulong timestamp;
diff --git a/arch/arm/include/asm/arch-a320/ftpmu010.h
b/arch/arm/include/asm/arch-a320/ftpmu010.h
deleted file mode 100644
index 8ef7a37..000
--- a/arch/arm/include/asm/arch-a320/ftpmu010.h
+++ /dev/null
@@ -1,146 +0,0 @@
-/*
- * (C) Copyright 2009 Faraday Technology
- * Po-Yu Chuang ratb...@faraday-tech.com
- *
- * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-/*
- * Power Management Unit
- */
-#ifndef __FTPMU010_H
-#define __FTPMU010_H
-
-struct ftpmu010 {
- unsigned intIDNMBR0;/* 0x00 */
- unsigned intreserved0; /* 0x04 */
- unsigned intOSCC; /* 0x08 */
- unsigned intPMODE; /* 0x0C */
- unsigned intPMCR; /* 0x10 */
- unsigned intPED;/* 0x14 */
- unsigned intPEDSR; /* 0x18 */
- unsigned intreserved1; /* 0x1C */
- unsigned intPMSR; /* 0x20 */
- unsigned intPGSR; /* 0x24 */
- unsigned intMFPSR; /* 0x28 */
- unsigned intMISC; /* 0x2C */
- unsigned intPDLLCR0;/* 0x30 */
- unsigned intPDLLCR1;/* 0x34 */
- unsigned intAHBMCLKOFF; /* 0x38 */
- unsigned intAPBMCLKOFF; /* 0x3C */
- unsigned intDCSRCR0;/* 0x40 */
- unsigned intDCSRCR1;/* 0x44 */
- unsigned intDCSRCR2;/* 0x48 */
- unsigned intSDRAMHTC; /* 0x4C */
- unsigned intPSPR0; /* 0x50 */
- unsigned intPSPR1; /* 0x54 */
- unsigned intPSPR2; /* 0x58 */
- unsigned intPSPR3; /* 0x5C */
- unsigned intPSPR4; /* 0x60 */
- unsigned intPSPR5; /* 0x64 */
- unsigned intPSPR6; /* 0x68 */
- unsigned intPSPR7; /* 0x6C */
- unsigned intPSPR8; /* 0x70 */
- unsigned intPSPR9; /* 0x74 */
- unsigned intPSPR10; /* 0x78 */
- unsigned intPSPR11; /* 0x7C */
- unsigned intPSPR12; /* 0x80 */
- unsigned intPSPR13; /* 0x84 */
- unsigned intPSPR14; /* 0x88 */
- unsigned intPSPR15; /* 0x8C */
- unsigned intAHBDMA_RACCS; /* 0x90 */
- unsigned intreserved2; /* 0x94 */
- unsigned intreserved3; /* 0x98 */
- unsigned intJSS;/* 0x9C */
- unsigned intCFC_RACC; /* 0xA0 */
- unsigned intSSP1_RACC; /* 0xA4 */
- unsigned intUART1TX_RACC; /* 0xA8 */
- unsigned intUART1RX_RACC; /* 0xAC */
- unsigned intUART2TX_RACC; /* 0xB0 */
- unsigned intUART2RX_RACC; /* 0xB4 */
- unsigned intSDC_RACC; /* 0xB8 */
- unsigned intI2SAC97_RACC; /* 0xBC */
- unsigned intIRDATX_RACC;/* 0xC0 */
- unsigned intreserved4; /* 0xC4 */
- unsigned intUSBD_RACC; /* 0xC8 */
- unsigned intIRDARX_RACC;/* 0xCC */
- unsigned intIRDA_RACC; /* 0xD0 */
- unsigned intED0_RACC; /* 0xD4 */
- unsigned intED1_RACC; /* 0xD8 */
-};
-
-/*
- * ID Number 0 Register
[U-Boot] [PATCH 3/3] ftsdmc020: move ftsdmc020 sdram controller to driver/misc folder
Move the header file and definitions of ftsdmc020 sdram control unit from a320 SoC folder to drivers/misc folder. This change will let other SoC which also use ftsdmc020 could share the same header file. Signed-off-by: Macpaul Lin macp...@andestech.com --- arch/arm/include/asm/arch-a320/ftsdmc020.h | 103 board/faraday/a320evb/lowlevel_init.S |2 +- drivers/misc/ftsdmc020.h | 103 3 files changed, 104 insertions(+), 104 deletions(-) delete mode 100644 arch/arm/include/asm/arch-a320/ftsdmc020.h create mode 100644 drivers/misc/ftsdmc020.h diff --git a/arch/arm/include/asm/arch-a320/ftsdmc020.h b/arch/arm/include/asm/arch-a320/ftsdmc020.h deleted file mode 100644 index 0699772..000 --- a/arch/arm/include/asm/arch-a320/ftsdmc020.h +++ /dev/null @@ -1,103 +0,0 @@ -/* - * (C) Copyright 2009 Faraday Technology - * Po-Yu Chuang ratb...@faraday-tech.com - * - * 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., 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -/* - * SDRAM Controller - */ -#ifndef __FTSDMC020_H -#define __FTSDMC020_H - -#define FTSDMC020_OFFSET_TP0 0x00 -#define FTSDMC020_OFFSET_TP1 0x04 -#define FTSDMC020_OFFSET_CR0x08 -#define FTSDMC020_OFFSET_BANK0_BSR 0x0C -#define FTSDMC020_OFFSET_BANK1_BSR 0x10 -#define FTSDMC020_OFFSET_BANK2_BSR 0x14 -#define FTSDMC020_OFFSET_BANK3_BSR 0x18 -#define FTSDMC020_OFFSET_BANK4_BSR 0x1C -#define FTSDMC020_OFFSET_BANK5_BSR 0x20 -#define FTSDMC020_OFFSET_BANK6_BSR 0x24 -#define FTSDMC020_OFFSET_BANK7_BSR 0x28 -#define FTSDMC020_OFFSET_ACR 0x34 - -/* - * Timing Parametet 0 Register - */ -#define FTSDMC020_TP0_TCL(x) ((x) 0x3) -#define FTSDMC020_TP0_TWR(x) (((x) 0x3) 4) -#define FTSDMC020_TP0_TRF(x) (((x) 0xf) 8) -#define FTSDMC020_TP0_TRCD(x) (((x) 0x7) 12) -#define FTSDMC020_TP0_TRP(x) (((x) 0xf) 16) -#define FTSDMC020_TP0_TRAS(x) (((x) 0xf) 20) - -/* - * Timing Parametet 1 Register - */ -#define FTSDMC020_TP1_REF_INTV(x) ((x) 0x) -#define FTSDMC020_TP1_INI_REFT(x) (((x) 0xf) 16) -#define FTSDMC020_TP1_INI_PREC(x) (((x) 0xf) 20) - -/* - * Configuration Register - */ -#define FTSDMC020_CR_SREF (1 0) -#define FTSDMC020_CR_PWDN (1 1) -#define FTSDMC020_CR_ISMR (1 2) -#define FTSDMC020_CR_IREF (1 3) -#define FTSDMC020_CR_IPREC (1 4) -#define FTSDMC020_CR_REFTYPE (1 5) - -/* - * SDRAM External Bank Base/Size Register - */ -#define FTSDMC020_BANK_ENABLE (1 28) - -#define FTSDMC020_BANK_BASE(addr) (((addr) 20) 16) - -#define FTSDMC020_BANK_DDW_X4 (0 12) -#define FTSDMC020_BANK_DDW_X8 (1 12) -#define FTSDMC020_BANK_DDW_X16 (2 12) -#define FTSDMC020_BANK_DDW_X32 (3 12) - -#define FTSDMC020_BANK_DSZ_16M (0 8) -#define FTSDMC020_BANK_DSZ_64M (1 8) -#define FTSDMC020_BANK_DSZ_128M(2 8) -#define FTSDMC020_BANK_DSZ_256M(3 8) - -#define FTSDMC020_BANK_MBW_8 (0 4) -#define FTSDMC020_BANK_MBW_16 (1 4) -#define FTSDMC020_BANK_MBW_32 (2 4) - -#define FTSDMC020_BANK_SIZE_1M 0x0 -#define FTSDMC020_BANK_SIZE_2M 0x1 -#define FTSDMC020_BANK_SIZE_4M 0x2 -#define FTSDMC020_BANK_SIZE_8M 0x3 -#define FTSDMC020_BANK_SIZE_16M0x4 -#define FTSDMC020_BANK_SIZE_32M0x5 -#define FTSDMC020_BANK_SIZE_64M0x6 -#define FTSDMC020_BANK_SIZE_128M 0x7 -#define FTSDMC020_BANK_SIZE_256M 0x8 - -/* - * Arbiter Control Register - */ -#define FTSDMC020_ACR_TOC(x) ((x) 0x1f) -#define FTSDMC020_ACR_TOE (1 8) - -#endif /* __FTSDMC020_H */ diff --git a/board/faraday/a320evb/lowlevel_init.S b/board/faraday/a320evb/lowlevel_init.S index 97718c0..416e87c 100644 --- a/board/faraday/a320evb/lowlevel_init.S +++ b/board/faraday/a320evb/lowlevel_init.S @@ -21,7 +21,7 @@ #include version.h #include asm/macro.h -#include asm/arch/ftsdmc020.h +#include ../../../drivers/misc/ftsdmc020.h /* * parameters for the SDRAM controller diff --git a/drivers/misc/ftsdmc020.h b/drivers/misc/ftsdmc020.h new file mode 100644 index 000..0699772 --- /dev/null +++ b/drivers/misc/ftsdmc020.h @@ -0,0 +1,103 @@ +/* + * (C) Copyright 2009 Faraday Technology
Re: [U-Boot] [PATCH 0/3] Share header files of Faraday controllers from a320 SoC.
[deleted] arch/arm/include/asm/arch-a320/ftsdmc020.h | 103 --- arch/arm/include/asm/arch-a320/fttmr010.h | 73 -- board/faraday/a320evb/lowlevel_init.S |2 +- create mode 100644 drivers/misc/ftsdmc020.h create mode 100644 drivers/power/ftpmu010.h create mode 100644 drivers/timer/fttmr010.h -- 1.7.3.2 Sorry for forgetting to remove these duplicate stuffs in cover letter. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
hi Detlev, On Thu Oct 28, 2010 at 12:52:31PM +0200, Detlev Zundel wrote: Hi Sughosh, [...] * hawkboard_nand_config - Used to generate the secondary bootloader(nand_spl) image. This creates an elf file u-boot-spl under nand_spl/. Create an AIS signed image using this file, and flash it to the nand flash at address 0x2. The ais file should fit in one block. Could you elaborate on create an AIS signed image a little bit for people who are not intimately familiar with this architecture? Maybe you can add a small doc/README.da8xx for that purpose? AIS is a format used to package an image which is to be copied to the memory to be run. The format consists of a series of commands which are parsed and executed by the RBL(primary boot loader) to get the image copied to the memory, and then jump to the image's entry point(also specified as part of the format). I will add more info on this in the document, as you suggest. * hawkboard_uart_config - This is same as the first image, but with the TEXT_BASE as expected by the RBL(0xc108). Create the AIS Signed bin, as use the normal UART boot procedure to boot the image. Again a short step-by-step instruction in a readme file would be a very valuable addition. Will add this to the readme. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is the Numonyx's M29W128 fully supported in U-Boot?
Txema López tlopez at fagorautomation.es writes: Great ! Thanks a lot :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, October 27, 2010 8:32 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302346c6...@dbde02.ent.ti.com you wrote: This has the additional benefit that you can actually build both configurations without the need to modify any source files. [sp] Was only concerned about possibility of multiple configurations per platform. Keeping them in sync could be pain. Do you have suggestions on this? Well, if the common parts are indeed in some common header file, then the remaining content should all be specific for the selected configuration, so what needs to be kept in sync? I think I have been able to do what you have suggested above. But got a small set of config options that could be duplicated. I am following this mail with an RFC series with specific code changes. Have tried to be explicit in my comments. There is one TBD in 2/3 that indicates possible duplication. Your comments would be really useful. Best regards, Sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
This series is based on the comments received [1] on my earlier submission[2]. Intent of sending as RFC is to thrash out the ideas and then send a formal patch. More details in individual patch description. [1] http://marc.info/?l=u-bootm=128818733126234w=2 [2] http://marc.info/?l=u-bootm=128818664024766w=2 There could be compilation issues as I have not tried building the u-boot with these changes; but will sort them (if any) for final submission. Sanjeev Premi (3): omap3evm: Move generic config options in common file omap3evm: Update configuration to use common definitions omap3evm: Add support for quick boot include/configs/omap3_evm_common.h | 269 include/configs/omap3_evm_full.h | 160 + include/configs/omap3_evm_quick.h | 155 + 3 files changed, 584 insertions(+), 0 deletions(-) create mode 100644 include/configs/omap3_evm_common.h create mode 100644 include/configs/omap3_evm_full.h create mode 100644 include/configs/omap3_evm_quick.h -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/3] omap3evm: Move generic config options in common file
This patch moves the most common config options into one file. In addition to movement, attempt has been made to consolidate related config options together. Ideally, this patch should contain deletion from current omap3_evm.h. But for this RFC, I am maintaining current file and adding (only for example) another file omap3_evm_full.h in next patch. Signed-off-by: Sanjeev Premi pr...@ti.com --- include/configs/omap3_evm_common.h | 269 1 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 include/configs/omap3_evm_common.h diff --git a/include/configs/omap3_evm_common.h b/include/configs/omap3_evm_common.h new file mode 100644 index 000..1d12153 --- /dev/null +++ b/include/configs/omap3_evm_common.h @@ -0,0 +1,269 @@ +/* + * Common configuration settings for the TI OMAP3 EVM board. + * + * Copyright (C) 2006-2010 Texas Instruments Incorporated - http://www.ti.com/ + * + * Author : + * Manikandan Pillai mani.pil...@ti.com + * Derived from Beagle Board and 3430 SDP code by + * Richard Woodruff r-woodru...@ti.com + * Syed Mohammed Khasim kha...@ti.com + * + * 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 as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __OMAP3_EVM_COMMON_H +#define __OMAP3_EVM_COMMON_H + +/* + * Common options for all OMAP3 + */ +#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ +#define CONFIG_OMAP1 /* in a TI OMAP core */ +#define CONFIG_OMAP34XX1 /* which is a 34XX */ +#define CONFIG_OMAP34301 /* which is in a 3430 */ +#define CONFIG_OMAP3_EVM 1 /* working with EVM */ + + +#include asm/arch/cpu.h /* get chip and board defs */ +#include asm/arch/omap3.h + +#undef CONFIG_USE_IRQ /* no support for IRQs */ + +/* + * Clock related definitions + */ +#define V_OSCK 2600 +#define V_SCLK (V_OSCK 1) + +/* + * OMAP3 has 12 GP timers, they can be driven by the system clock + * (12/13/16.8/19.2/38.4MHz) or by 32KHz clock. We use 13MHz (V_SCLK). + * This rate is divided by a local divisor. + */ +#define CONFIG_SYS_TIMERBASE OMAP34XX_GPT2 +#define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) = 8 */ +#define CONFIG_SYS_HZ 1000 + +/* + * Size of malloc() pool + */ +#define CONFIG_ENV_SIZE(128 10) /* 128 KiB */ + /* Sector */ +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 10)) +#define CONFIG_SYS_GBL_DATA_SIZE 128 /* bytes reserved for */ + /* initial data */ +/* + * Stack sizes + * + * The stack sizes are set up in start.S using the settings below + */ +#define CONFIG_STACKSIZE (128 10) /* regular stack 128 KiB */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ (4 10) /* IRQ stack 4 KiB */ +#define CONFIG_STACKSIZE_FIQ (4 10) /* FIQ stack 4 KiB */ +#endif + +/* + * Physical Memory Map + * Note 1: CS1 may or may not be populated + * Note 2: SDRAM size is expected to be at least 32MB + */ +#define CONFIG_NR_DRAM_BANKS 2 +#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0 +#define PHYS_SDRAM_1_SIZE (32 20) +#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1 + +/* Limits for memtest */ +#define CONFIG_SYS_MEMTEST_START (OMAP34XX_SDRC_CS0) +#define CONFIG_SYS_MEMTEST_END (OMAP34XX_SDRC_CS0 + \ + 0x01F0) /* 31MB */ +/* + * SDRAM Bank Allocation method + */ +#define SDRC_R_B_C 1 + +/* + * Default load address + */ +#define CONFIG_SYS_LOAD_ADDR (OMAP34XX_SDRC_CS0) + +/* + * Support for relocation + */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - \ + CONFIG_SYS_GBL_DATA_SIZE) + +/* + * NS16550 Configuration + */ +#define V_NS16550_CLK 4800/* 48MHz (APLL96/2) */ + +#define CONFIG_SYS_NS16550 +#define CONFIG_SYS_NS16550_SERIAL +#define CONFIG_SYS_NS16550_REG_SIZE(-4) +#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK + +/* + * select serial console configuration + */ +#define CONFIG_CONS_INDEX 1 +#define CONFIG_SERIAL1 1 /* UART1 on OMAP3 EVM */ +#define CONFIG_SYS_NS16550_COM1
[U-Boot] [RFC 2/3] omap3evm: Update configuration to use common definitions
This patch moves the most common config options into one file.
In addition to movement, attempt has been made to consolidate
related config options together.
In final version, this file won't exist. The contents of this
patch would change existing omap3_evm.h and should be merged
with previous patch in this series.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Unlike previous patch, contents of this file are yet to be
moved (based on relation). Shall be done in final patch.
include/configs/omap3_evm_full.h | 160 ++
1 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 include/configs/omap3_evm_full.h
diff --git a/include/configs/omap3_evm_full.h b/include/configs/omap3_evm_full.h
new file mode 100644
index 000..1633835
--- /dev/null
+++ b/include/configs/omap3_evm_full.h
@@ -0,0 +1,160 @@
+/*
+ * Common configuration settings for the TI OMAP3 EVM board.
+ *
+ * Copyright (C) 2006-2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author :
+ * Manikandan Pillai mani.pil...@ti.com
+ * Derived from Beagle Board and 3430 SDP code by
+ * Richard Woodruff r-woodru...@ti.com
+ * Syed Mohammed Khasim kha...@ti.com
+ *
+ * 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 as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __OMAP3_EVM_H
+#define __OMAP3_EVM_H
+
+#include omap3_evm_common.h
+
+/*
+ * Display CPU and Board information
+ */
+#define CONFIG_DISPLAY_CPUINFO 1
+#define CONFIG_DISPLAY_BOARDINFO 1
+
+#define CONFIG_MISC_INIT_R
+
+/*
+ * Default commands to include
+ */
+#include config_cmd_default.h
+
+/*
+ * Ethernet (SMSC9115 from SMSC9118 family)
+ */
+#if defined(CONFIG_CMD_NET)
+
+#define CONFIG_NET_MULTI
+#define CONFIG_SMC911X
+#define CONFIG_SMC911X_32_BIT
+#define CONFIG_SMC911X_BASE0x2C00
+
+#endif /* (CONFIG_CMD_NET) */
+
+/*
+ * TBD: This is one block where i feel duplication may be required
+ * between this regular configuration and quick configuration.
+ */
+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_OMAP_GPMC
+#define GPMC_NAND_ECC_LP_x16_LAYOUT1
+#define CONFIG_ENV_IS_IN_NAND
+#elif defined(CONFIG_CMD_ONENAND)
+#define CONFIG_ENV_IS_IN_ONENAND 1
+#endif /* (CONFIG_CMD_NAND) */
+
+/*
+ * Hardware drivers
+ */
+
+#define CONFIG_MMC 1
+#define CONFIG_OMAP3_MMC 1
+#define CONFIG_DOS_PARTITION 1
+
+/* USB
+ * Enable CONFIG_MUSB_HCD for Host functionalities MSC, keyboard
+ * Enable CONFIG_MUSB_UDD for Device functionalities.
+ */
+#define CONFIG_USB_OMAP3 1
+#define CONFIG_MUSB_HCD1
+/* #define CONFIG_MUSB_UDC 1 */
+
+#ifdef CONFIG_USB_OMAP3
+
+#ifdef CONFIG_MUSB_HCD
+#define CONFIG_CMD_USB
+
+#define CONFIG_USB_STORAGE
+#define CONGIG_CMD_STORAGE
+#define CONFIG_CMD_FAT
+
+#ifdef CONFIG_USB_KEYBOARD
+#define CONFIG_SYS_USB_EVENT_POLL
+#define CONFIG_PREBOOT usb start
+#endif /* CONFIG_USB_KEYBOARD */
+
+#endif /* CONFIG_MUSB_HCD */
+
+#ifdef CONFIG_MUSB_UDC
+/* USB device configuration */
+#define CONFIG_USB_DEVICE 1
+#define CONFIG_USB_TTY 1
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1
+/* Change these to suit your needs */
+#define CONFIG_USBD_VENDORID 0x0451
+#define CONFIG_USBD_PRODUCTID 0x5678
+#define CONFIG_USBD_MANUFACTURER Texas Instruments
+#define CONFIG_USBD_PRODUCT_NAME EVM
+#endif /* CONFIG_MUSB_UDC */
+
+#endif /* CONFIG_USB_OMAP3 */
+
+
+#define CONFIG_CMD_EXT2/* EXT2 Support */
+#define CONFIG_CMD_FAT /* FAT support */
+#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/
+
+#define CONFIG_CMD_MMC /* MMC support */
+#define CONFIG_CMD_NAND/* NAND support */
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_PING
+
+#undef CONFIG_CMD_FLASH/* flinfo, erase, protect */
+#undef CONFIG_CMD_FPGA /* FPGA configuration Support */
+#undef CONFIG_CMD_IMI /* iminfo */
+#undef CONFIG_CMD_IMLS /* List all found images*/
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ loadaddr=0x8200\0 \
+ usbtty=cdc_acm\0 \
+ console=ttyS2,115200n8\0 \
+ mmcargs=setenv bootargs console=${console} \
+ root=/dev/mmcblk0p2 rw \
+ rootfstype=ext3 rootwait\0 \
+ nandargs=setenv bootargs console=${console} \
+ root=/dev/mtdblock4 rw \
+
[U-Boot] [RFC 3/3] omap3evm: Add 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 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 overall boot time. Signed-off-by: Sanjeev Premi pr...@ti.com --- include/configs/omap3_evm_quick.h | 155 + 1 files changed, 155 insertions(+), 0 deletions(-) create mode 100644 include/configs/omap3_evm_quick.h diff --git a/include/configs/omap3_evm_quick.h b/include/configs/omap3_evm_quick.h new file mode 100644 index 000..3703535 --- /dev/null +++ b/include/configs/omap3_evm_quick.h @@ -0,0 +1,155 @@ +/* + * Configuration settings for quick boot on OMAP3 EVM. + * + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ + * + * Author : + * Sanjeev Premi pr...@ti.com + * + * 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 as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __OMAP3_EVM_QUICK_H +#define __OMAP3_EVM_QUICK_H + +#include omap3_evm_common.h + +/* + * 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 + +#undef CONFIG_SYS_LONGHELP +#undef CONFIG_SYS_HUSH_PARSER + +/* + * Exclude unused/rarely used features. + */ +#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_BOOTDELAY 0 + +/* + * 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 /* CONFIG_QUICK_BOOT_MMC */ + +#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 /* CONFIG_QUICK_BOOT_NAND */ + +/* + * Board specific features + * Exclude not-so-common features + */ +#undef CONFIG_USB_OMAP3 +#undef CONFIG_MUSB_HCD + +#undef CONFIG_USB_STORAGE +#undef CONFIG_USB_KEYBOARD +#undef CONFIG_SYS_USB_EVENT_POLL +#undef CONFIG_PREBOOT + +#undef CONFIG_MUSB_UDC +#undef CONFIG_USB_DEVICE +#undef CONFIG_USB_TTY + +#endif /* __OMAP3_EVM_QUICK_H */ + + -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] GENERATED_GBL_DATA_SIZE problem
Hi List, Day before I reported the problem with declarations of CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. In the following patch GENERATED_GBL_DATA_SIZE is defined as #96. The pound size before the number is cauing the assembler go mad. It doesn't compile. Remove the pound and its okay. Is the pound sign really required or is this problem with the sed script being used for it? diff --git a/include/configs/versatile.h b/include/configs/versatile.h index 45d8434..5156589 100644 --- a/include/configs/versatile.h +++ b/include/configs/versatile.h @@ -231,4 +231,7 @@ #define CONFIG_SYS_FLASH_PROTECTION/* The devices have real protection */ #define CONFIG_SYS_FLASH_EMPTY_INFO/* flinfo indicates empty blocks */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE - GENERATED_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ Thanks Regards Himanshu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
Dear Sanjeev Premi, In message 1288283919-3837-1-git-send-email-pr...@ti.com you wrote: This series is based on the comments received [1] on my earlier submission[2]. Intent of sending as RFC is to thrash out the ideas and then send a formal patch. Sorry, as you submitted this I see only 3 completely new files without relation to each other nor with any relation to the existing code. I suggest the following approach: Patch 1: move common code out of include/configs/omap3_evm.h into a new file include/configs/omap3_evm_common.h; this patch should result in exactly the same code for the board as we have now. Do not rename omap3_evm.h into omap3_evm_full.h; this makes no sense to me. omap3_evm.h is and remains the default configuration. Patch 2: Create a new file omap3_evm_quick.h, which contains the speed optimized configuration settings. Get rid of all the #ifndef FOO #define FOO #endif stuff there. This is a plain simple and fixed configuration, so this is not needed. You may even consider to splitting this more - into omap3_evm_quick_nand.h and omap3_evm_quick_mmc.h to eliminate even more of the #ifdeffery. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] GENERATED_GBL_DATA_SIZE problem
Dear Himanshu Chauhan, In message 20101028164616.ga3...@pnq-hchauhan-vm you wrote: Hi List, Day before I reported the problem with declarations of CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. In the following patch GENERATED_GBL_DATA_SIZE is defined as #96. The pound size before the number is cauing the assembler go mad. It doesn't compile. Remove the pound and its okay. Is the pound sign really required or is this problem with the sed script being used for it? Please update your code. This has been fixed yesterday morning. Patch is in mainline since last night. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When a woman marries again it is because she detested her first hus- band. When a man marries again, it is because he adored his first wife. -- Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] mmc: Clean up generic mmc driver multi-block write functions
The current mmc write implementation is type ulong, but returns int values.
Some of the printf's are terminated with /n/r, one has none.
This patch fixes these issues and also removes some unnecessary local
variables.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index eb7bfb3..00fe867 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -82,12 +82,9 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
{
struct mmc_cmd cmd;
struct mmc_data data;
- int blklen, err;
-
- blklen = mmc-write_bl_len;
if ((start + blkcnt) mmc-block_dev.lba) {
- printf(MMC: block number 0x%lx exceeds max(0x%lx),
+ printf(MMC: block number 0x%lx exceeds max(0x%lx)\n,
start + blkcnt, mmc-block_dev.lba);
return 0;
}
@@ -100,21 +97,19 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
if (mmc-high_capacity)
cmd.cmdarg = start;
else
- cmd.cmdarg = start * blklen;
+ cmd.cmdarg = start * mmc-write_bl_len;
cmd.resp_type = MMC_RSP_R1;
cmd.flags = 0;
data.src = src;
data.blocks = blkcnt;
- data.blocksize = blklen;
+ data.blocksize = mmc-write_bl_len;
data.flags = MMC_DATA_WRITE;
- err = mmc_send_cmd(mmc, cmd, data);
-
- if (err) {
- printf(mmc write failed\n\r);
- return err;
+ if (mmc_send_cmd(mmc, cmd, data)) {
+ printf(mmc write failed\n);
+ return 0;
}
if (blkcnt 1) {
@@ -122,10 +117,9 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
cmd.flags = 0;
- err = mmc_send_cmd(mmc, cmd, NULL);
- if (err) {
- printf(mmc fail to send stop cmd\n\r);
- return err;
+ if (mmc_send_cmd(mmc, cmd, NULL)) {
+ printf(mmc fail to send stop cmd\n);
+ return 0;
}
}
@@ -135,18 +129,14 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
static ulong
mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
{
- int err;
- struct mmc *mmc = find_mmc_device(dev_num);
lbaint_t cur, blocks_todo = blkcnt;
+ struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
- return -1;
+ return 0;
- err = mmc_set_blocklen(mmc, mmc-write_bl_len);
- if (err) {
- printf(set write bl len failed\n\r);
- return err;
- }
+ if (mmc_set_blocklen(mmc, mmc-write_bl_len))
+ return 0;
do {
/*
@@ -155,7 +145,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
*/
cur = (blocks_todo 65535) ? 65535 : blocks_todo;
if(mmc_write_blocks(mmc, start, cur, src) != cur)
- return -1;
+ return 0;
blocks_todo -= cur;
start += cur;
src += cur * mmc-write_bl_len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] mmc: Add multi-block read support to the generic mmc driver
From: Alagu Sankar alagusankar at embwise.com
This patch adds multi-block read support for the generic MMC
driver. Large reads are broken into chunks of 65535 blocks to
ensure that the code works with controllers having a 16 bit block counter.
This patch results in a significant performance improvement.
Time to read a 45 MB file went from 36 seconds to 9 seconds on Overo
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
This is based on Alagu's original patch, but heavily modified to reflect
recent changes in the driver and to remove the CONFIG option as
requested in the earlier discussion of the patch:
http://www.mail-archive.com/u-boot@lists.denx.de/msg32319.html
It also incorporates feedback on my previously submitted RFC multi-block
read patch. I am leaving authorship with Alagu since he did the original
work, but will leave it up to him to add his Signed-off-by
---
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 00fe867..6805b33 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -154,110 +154,78 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
const void*src)
return blkcnt;
}
-int mmc_read_block(struct mmc *mmc, void *dst, uint blocknum)
+int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt)
{
struct mmc_cmd cmd;
struct mmc_data data;
- cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
+ if (blkcnt 1)
+ cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
+ else
+ cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
if (mmc-high_capacity)
- cmd.cmdarg = blocknum;
+ cmd.cmdarg = start;
else
- cmd.cmdarg = blocknum * mmc-read_bl_len;
+ cmd.cmdarg = start * mmc-read_bl_len;
cmd.resp_type = MMC_RSP_R1;
cmd.flags = 0;
data.dest = dst;
- data.blocks = 1;
+ data.blocks = blkcnt;
data.blocksize = mmc-read_bl_len;
data.flags = MMC_DATA_READ;
- return mmc_send_cmd(mmc, cmd, data);
-}
-
-int mmc_read(struct mmc *mmc, u64 src, uchar *dst, int size)
-{
- char *buffer;
- int i;
- int blklen = mmc-read_bl_len;
- int startblock = lldiv(src, mmc-read_bl_len);
- int endblock = lldiv(src + size - 1, mmc-read_bl_len);
- int err = 0;
-
- /* Make a buffer big enough to hold all the blocks we might read */
- buffer = malloc(blklen);
-
- if (!buffer) {
- printf(Could not allocate buffer for MMC read!\n);
- return -1;
- }
-
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc-read_bl_len);
-
- if (err)
- goto free_buffer;
-
- for (i = startblock; i = endblock; i++) {
- int segment_size;
- int offset;
-
- err = mmc_read_block(mmc, buffer, i);
-
- if (err)
- goto free_buffer;
-
- /*
-* The first block may not be aligned, so we
-* copy from the desired point in the block
-*/
- offset = (src (blklen - 1));
- segment_size = MIN(blklen - offset, size);
-
- memcpy(dst, buffer + offset, segment_size);
+ if (mmc_send_cmd(mmc, cmd, data))
+ return 0;
- dst += segment_size;
- src += segment_size;
- size -= segment_size;
+ if (blkcnt 1) {
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.flags = 0;
+ if (mmc_send_cmd(mmc, cmd, NULL)) {
+ printf(mmc fail to send stop cmd\n);
+ return 0;
+ }
}
-free_buffer:
- free(buffer);
-
- return err;
+ return blkcnt;
}
static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void *dst)
{
- int err;
- int i;
- struct mmc *mmc = find_mmc_device(dev_num);
+ lbaint_t cur, blocks_todo = blkcnt;
+
+ if (blkcnt == 0)
+ return 0;
+ struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
return 0;
if ((start + blkcnt) mmc-block_dev.lba) {
- printf(MMC: block number 0x%lx exceeds max(0x%lx),
+ printf(MMC: block number 0x%lx exceeds max(0x%lx)\n,
start + blkcnt, mmc-block_dev.lba);
return 0;
}
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc-read_bl_len);
- if (err) {
+ if (mmc_set_blocklen(mmc, mmc-read_bl_len))
return 0;
- }
- for (i = start; i start + blkcnt; i++, dst += mmc-read_bl_len) {
- err = mmc_read_block(mmc, dst, i);
-
-
Re: [U-Boot] [PATCH] env_sf: remove warning introduced with last patch
On Thu, Oct 28, 2010 at 6:39 AM, Stefano Babic wrote:
Signed-off-by: Stefano Babic sba...@denx.de
---
common/env_sf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/env_sf.c b/common/env_sf.c
index a597b24..e5e0166 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -272,7 +272,7 @@ int saveenv(void)
u32 saved_size, saved_offset;
char *saved_buffer = NULL;
u32 sector = 1;
- int ret;
+ int ret = 1;
env_t env_new;
char *res;
ssize_t len;
if you're going to start at 1, shouldnt you then drop the redundant
assignment to 1 ?
if (!saved_buffer) {
ret = 1;
goto done;
}
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
On Tue, 26 Oct 2010 23:28:05 +0530 Sughosh Ganu urwithsugh...@gmail.com wrote: diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index d41579c..ad70dd9 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -635,6 +635,7 @@ void davinci_nand_init(struct nand_chip *nand) nand-write_buf = nand_davinci_write_buf; nand-dev_ready = nand_davinci_dev_ready; + nand-select_chip = NULL; Shouldn't it already be NULL from the BSS? There are many other fields where this is relied on... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
hi Scott, On Thu, Oct 28, 2010 at 11:23 PM, Scott Wood scottw...@freescale.comwrote: On Tue, 26 Oct 2010 23:28:05 +0530 Sughosh Ganu urwithsugh...@gmail.com wrote: diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index d41579c..ad70dd9 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -635,6 +635,7 @@ void davinci_nand_init(struct nand_chip *nand) nand-write_buf = nand_davinci_write_buf; nand-dev_ready = nand_davinci_dev_ready; + nand-select_chip = NULL; Shouldn't it already be NULL from the BSS? There are many other fields where this is relied on... This is needed when building for nand_spl, where the nand_boot function in nand_boot.c declares the chip object as a local variable. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
On Thu, 28 Oct 2010 23:59:10 +0530 sughosh ganu urwithsugh...@gmail.com wrote: hi Scott, On Thu, Oct 28, 2010 at 11:23 PM, Scott Wood scottw...@freescale.comwrote: On Tue, 26 Oct 2010 23:28:05 +0530 Sughosh Ganu urwithsugh...@gmail.com wrote: diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index d41579c..ad70dd9 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -635,6 +635,7 @@ void davinci_nand_init(struct nand_chip *nand) nand-write_buf = nand_davinci_write_buf; nand-dev_ready = nand_davinci_dev_ready; + nand-select_chip = NULL; Shouldn't it already be NULL from the BSS? There are many other fields where this is relied on... This is needed when building for nand_spl, where the nand_boot function in nand_boot.c declares the chip object as a local variable. Ah. In that case nand_boot() should probably clear select_chip before calling board_nand_init(). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
hi Scott, On Fri, Oct 29, 2010 at 12:02 AM, Scott Wood scottw...@freescale.comwrote: On Thu, 28 Oct 2010 23:59:10 +0530 sughosh ganu urwithsugh...@gmail.com wrote: This is needed when building for nand_spl, where the nand_boot function in nand_boot.c declares the chip object as a local variable. Ah. In that case nand_boot() should probably clear select_chip before calling board_nand_init(). Will move this to the nand_boot function. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, October 28, 2010 10:24 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot Dear Sanjeev Premi, In message 1288283919-3837-1-git-send-email-pr...@ti.com you wrote: This series is based on the comments received [1] on my earlier submission[2]. Intent of sending as RFC is to thrash out the ideas and then send a formal patch. Sorry, as you submitted this I see only 3 completely new files without relation to each other nor with any relation to the existing code. I suggest the following approach: Patch 1: move common code out of include/configs/omap3_evm.h into a new file include/configs/omap3_evm_common.h; this patch should result in exactly the same code for the board as we have now. Do not rename omap3_evm.h into omap3_evm_full.h; this makes no sense to me. omap3_evm.h is and remains the default configuration. [sp] Since I was also moving the related config options next to each other - as against current spread. I couldn't make much sens of patch. Thought it could be confusing to others as well. Appears, I was wrong! Patch 2: Create a new file omap3_evm_quick.h, which contains the speed optimized configuration settings. Get rid of all the #ifndef FOO #define FOO #endif stuff there. This is a plain simple and fixed configuration, so this is not needed. [sp] Sorry, I didn't clean this up considering the focus would be on the first 2 patches. You may even consider to splitting this more - into omap3_evm_quick_nand.h and omap3_evm_quick_mmc.h to eliminate even more of the #ifdeffery. [sp] That's a good idea. Will have it implemented tomorrow morning. best regards, Sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
On Thu, Oct 28, 2010 at 07:55:49AM +0100, Chris Isbell wrote: -Original Message- From: Kristoffer Ericson kristoffer.eric...@gmail.com Reply-to: Kristoffer Ericson kristoffer.eric...@gmail.com To: w...@denx.de Cc: u-boot@lists.denx.de Subject: [U-Boot] Kernel OOPS on memcpy - bad memory setup? Date: Wed, 27 Oct 2010 23:46:41 +0200 Greetings, Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere else, but dont have any large binaries (busybox). So, I assume I have made some memory error in u-boot? Best wishes Kristoffer Dear Kristoffer, I experienced a similar problem when U-Boot configured the SDRAM controller incorrectly, so only half of the memory was being refreshed. I was thinking somewhere in those lines, since linux pretty much assumes that the bootloader already have the memory fully setup. It could also be some cpufreq thing where I havent added the correct memory settings yet (testing it now). Thanks Regards, Chris. -- Chris Isbell Systems Integration Manager, CDSRail Fareham, Hampshire, UK. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb593023475e...@dbde02.ent.ti.com you wrote: Do not rename omap3_evm.h into omap3_evm_full.h; this makes no sense to me. omap3_evm.h is and remains the default configuration. [sp] Since I was also moving the related config options next to each other - as against current spread. I couldn't make much sens of patch. Thought it could be confusing to others as well. Appears, I was wrong! Please don't do this in the same patch. Do it as a separate commit either before or after splitting the config 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 You can observe a lot just by watching. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
On Thu, Oct 28, 2010 at 12:04:56AM +0200, Wolfgang Denk wrote: Dear Kristoffer Ericson, In message 20101027214641.gc...@boggieman.bredbandsbolaget.se you wrote: Greetings, Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere else, but dont have any large binaries (busybox). So, I assume I have made some memory error in u-boot? No. U-Boot is long dead and gone when Linux boots. Is that true even if I were to setup the memory registers incorrect? I thought that linux pretty much expected the bootloader to setup everything regarding the memory settings? Oh, and IF I configured the memory incorrect, I should be able to see somekind of fault when doing a memtest in u-boot, correct? Or atleast that the write != read values? And if I dont see that, then its linux kernel problem? Linux kernel oopses are a Linux issue. 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 Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC 0/3] ARM Relocation Config Cleanup
Reinhard Meyer provided a good summary of the current mess of ARM relocation related config options we have at the moment, cf. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/87679/focus=87842 Given the fact that ARM boards need to be adapted to the new relocation support anyway, we may as well take this opportunity and make the code a bit cleaner and easier to read. It is supposed that this will make the neccessary adapptions just easier. NOTE: this patch series is in violation with the grace period announced in doc/feature-removal-schedule.txt, but actually we don;t make the situation any worse, as CONFIG_SYS_ARM_WITHOUT_RELOC does not work anyway. Wolfgang Denk (3): Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_BROKEN_RELOC_FIXUP Drop support for CONFIG_SYS_ARM_WITHOUT_RELOC Drop support for CONFIG_SKIP_RELOCATE_UBOOT Makefile |1 - README | 18 +-- arch/arm/config.mk |5 - arch/arm/cpu/arm1136/start.S | 131 arch/arm/cpu/arm1176/start.S | 218 -- arch/arm/cpu/arm720t/start.S | 107 - arch/arm/cpu/arm920t/start.S | 146 -- arch/arm/cpu/arm925t/start.S | 123 --- arch/arm/cpu/arm926ejs/orion5x/dram.c | 15 -- arch/arm/cpu/arm926ejs/start.S | 100 arch/arm/cpu/arm946es/start.S | 87 --- arch/arm/cpu/arm_intcm/start.S | 89 --- arch/arm/cpu/armv7/omap3/emif4.c | 24 --- arch/arm/cpu/armv7/omap3/sdrc.c| 28 arch/arm/cpu/armv7/omap4/board.c |5 - arch/arm/cpu/armv7/start.S | 117 -- arch/arm/cpu/ixp/start.S | 205 - arch/arm/cpu/lh7a40x/start.S | 115 -- arch/arm/cpu/pxa/start.S | 32 +--- arch/arm/cpu/s3c44b0/start.S | 87 --- arch/arm/cpu/sa1100/start.S| 90 --- arch/arm/include/asm/config.h |3 - arch/arm/include/asm/global_data.h |2 - arch/arm/include/asm/u-boot-arm.h |6 - arch/arm/lib/board.c | 260 arch/arm/lib/cache-cp15.c | 19 --- arch/arm/lib/interrupts.c |6 - arch/avr32/include/asm/config.h|2 + arch/avr32/lib/board.c |4 +- arch/blackfin/include/asm/config.h |3 - arch/i386/include/asm/config.h |2 - arch/m68k/include/asm/config.h |2 + arch/m68k/lib/board.c |4 +- arch/microblaze/include/asm/config.h |3 - arch/mips/include/asm/config.h |2 + arch/mips/lib/board.c |4 +- arch/nios2/include/asm/config.h|3 - arch/powerpc/include/asm/config.h |3 - arch/sh/include/asm/config.h |3 - arch/sparc/include/asm/config.h|2 + arch/sparc/lib/board.c |4 +- board/davinci/common/misc.c| 10 -- board/keymile/km_arm/km_arm.c | 15 -- board/ttcontrol/vision2/vision2.c | 14 -- common/cmd_bdinfo.c|2 - common/cmd_bmp.c |2 +- common/cmd_bootm.c |2 +- common/cmd_date.c |6 +- common/cmd_i2c.c |2 +- common/cmd_nvedit.c|2 +- common/cmd_onenand.c |2 +- common/command.c |2 +- common/dlmalloc.c |2 +- common/env_common.c|2 +- common/hush.c |4 +- common/image.c |8 +- common/serial.c|2 +- common/stdio.c |4 +- disk/part.c|4 +- doc/README.arm-relocation |8 - doc/feature-removal-schedule.txt | 27 drivers/mtd/nand/nand.c|2 +- drivers/net/phy/miiphybb.c |2 +- fs/ubifs/ubifs.c |2 +- include/command.h |2 +- include/configs/SMN42.h|1 - include/configs/afeb9260.h |1 - include/configs/at91cap9adk.h |1 - include/configs/at91rm9200dk.h |2 - include/configs/at91sam9260ek.h|1 - include/configs/at91sam9261ek.h|1 - include/configs/at91sam9263ek.h|1 - include/configs/at91sam9m10g45ek.h |1 - include/configs/at91sam9rlek.h |1 - include/configs/cmc_pu2.h |2 - include/configs/colibri_pxa270.h |1 - include/configs/cpuat91.h |1 - include/configs/csb637.h |2 - include/configs/da830evm.h |1 -
[U-Boot] [PATCH RFC 1/3] Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_BROKEN_RELOC_FIXUP
By now, the majority of architectures have working relocation support, so the few remaining architectures have become exceptions. To make this more obvious, we make working relocation now the default case, and flag the remaining cases with CONFIG_BROKEN_RELOC_FIXUP. Signed-off-by: Wolfgang Denk w...@denx.de --- arch/arm/include/asm/config.h|3 --- arch/arm/lib/board.c | 32 arch/avr32/include/asm/config.h |2 ++ arch/avr32/lib/board.c |4 ++-- arch/blackfin/include/asm/config.h |3 --- arch/i386/include/asm/config.h |2 -- arch/m68k/include/asm/config.h |2 ++ arch/m68k/lib/board.c|4 ++-- arch/microblaze/include/asm/config.h |3 --- arch/mips/include/asm/config.h |2 ++ arch/mips/lib/board.c|4 ++-- arch/nios2/include/asm/config.h |3 --- arch/powerpc/include/asm/config.h|3 --- arch/sh/include/asm/config.h |3 --- arch/sparc/include/asm/config.h |2 ++ arch/sparc/lib/board.c |4 ++-- common/cmd_bmp.c |2 +- common/cmd_bootm.c |2 +- common/cmd_date.c|6 +++--- common/cmd_i2c.c |2 +- common/cmd_nvedit.c |2 +- common/cmd_onenand.c |2 +- common/command.c |2 +- common/dlmalloc.c|2 +- common/env_common.c |2 +- common/hush.c|4 ++-- common/image.c |8 common/serial.c |2 +- common/stdio.c |4 ++-- disk/part.c |4 ++-- doc/README.arm-relocation|5 ++--- drivers/mtd/nand/nand.c |2 +- drivers/net/phy/miiphybb.c |2 +- fs/ubifs/ubifs.c |2 +- include/command.h|2 +- include/post.h |2 +- post/post.c |2 +- 37 files changed, 46 insertions(+), 91 deletions(-) diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index 4124f0a..c60dba2 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -21,9 +21,6 @@ #ifndef _ASM_CONFIG_H_ #define _ASM_CONFIG_H_ -/* Relocation to SDRAM works on all ARM boards */ -#define CONFIG_RELOC_FIXUP_WORKS - #define CONFIG_LMB #define CONFIG_SYS_BOOT_RAMDISK_HIGH #endif diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index af9a414..33b3694 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -679,15 +679,6 @@ void board_init_r (gd_t *id, ulong dest_addr) #if !defined(CONFIG_SYS_NO_FLASH) ulong flash_size; #endif -#if !defined(CONFIG_RELOC_FIXUP_WORKS) - extern void malloc_bin_reloc (void); -#if defined(CONFIG_CMD_BMP) - extern void bmp_reloc(void); -#endif -#if defined(CONFIG_CMD_I2C) - extern void i2c_reloc(void); -#endif -#endif gd = id; bd = gd-bd; @@ -704,39 +695,16 @@ void board_init_r (gd_t *id, ulong dest_addr) debug (Now running in RAM - U-Boot at: %08lx\n, dest_addr); -#if !defined(CONFIG_RELOC_FIXUP_WORKS) - /* -* We have to relocate the command table manually -*/ - fixup_cmdtable(__u_boot_cmd_start, - (ulong)(__u_boot_cmd_end - __u_boot_cmd_start)); -#if defined(CONFIG_CMD_BMP) - bmp_reloc(); -#endif -#if defined(CONFIG_CMD_I2C) - i2c_reloc(); -#endif -#if defined(CONFIG_CMD_ONENAND) - onenand_reloc(); -#endif -#endif /* !defined(CONFIG_RELOC_FIXUP_WORKS) */ - #ifdef CONFIG_LOGBUFFER logbuff_init_ptrs (); #endif #ifdef CONFIG_POST post_output_backlog (); -#ifndef CONFIG_RELOC_FIXUP_WORKS - post_reloc (); -#endif #endif /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN; mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN); -#if !defined(CONFIG_RELOC_FIXUP_WORKS) - malloc_bin_reloc (); -#endif #if !defined(CONFIG_SYS_NO_FLASH) puts (FLASH: ); diff --git a/arch/avr32/include/asm/config.h b/arch/avr32/include/asm/config.h index 049c44e..612f655 100644 --- a/arch/avr32/include/asm/config.h +++ b/arch/avr32/include/asm/config.h @@ -21,4 +21,6 @@ #ifndef _ASM_CONFIG_H_ #define _ASM_CONFIG_H_ +#define CONFIG_BROKEN_RELOC_FIXUP + #endif diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c index 96ccc7f..1c5b711 100644 --- a/arch/avr32/lib/board.c +++ b/arch/avr32/lib/board.c @@ -272,13 +272,13 @@ void board_init_r(gd_t *new_gd, ulong dest_addr) monitor_flash_len = _edata - _text; -#if !defined(CONFIG_RELOC_FIXUP_WORKS) +#if defined(CONFIG_BROKEN_RELOC_FIXUP) /* * We have to relocate the command table manually
[U-Boot] [PATCH RFC 3/3] Drop support for CONFIG_SKIP_RELOCATE_UBOOT
For ARM systems, before ELF relocation was introduced, CONFIG_SKIP_RELOCATE_UBOOT coul be used to prevent *COPYING* the U-Boot image from whereever it was loaded to it's link address (CONFIG_SYS_TEXT_BASE). The name was badly chosen, as no relocation was performed at all, it was just a memcpy(). With ELF relocation, this does not work like that any more, and related boards need to be fixed anyway. So don't keep this relict any longer. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |1 - README | 18 -- arch/arm/cpu/arm1136/start.S |4 arch/arm/cpu/arm1176/start.S |4 arch/arm/cpu/arm720t/start.S |2 -- arch/arm/cpu/arm920t/start.S |2 -- arch/arm/cpu/arm925t/start.S |2 -- arch/arm/cpu/arm926ejs/start.S |4 arch/arm/cpu/arm946es/start.S |2 -- arch/arm/cpu/arm_intcm/start.S |2 -- arch/arm/cpu/armv7/start.S |4 arch/arm/cpu/ixp/start.S |2 -- arch/arm/cpu/lh7a40x/start.S |2 -- arch/arm/cpu/pxa/start.S |4 arch/arm/cpu/s3c44b0/start.S |2 -- arch/arm/cpu/sa1100/start.S|2 -- include/configs/SMN42.h|1 - include/configs/afeb9260.h |1 - include/configs/at91cap9adk.h |1 - include/configs/at91rm9200dk.h |2 -- include/configs/at91sam9260ek.h|1 - include/configs/at91sam9261ek.h|1 - include/configs/at91sam9263ek.h|1 - include/configs/at91sam9m10g45ek.h |1 - include/configs/at91sam9rlek.h |1 - include/configs/cmc_pu2.h |2 -- include/configs/colibri_pxa270.h |1 - include/configs/cpuat91.h |1 - include/configs/csb637.h |2 -- include/configs/da830evm.h |1 - include/configs/davinci_dm355evm.h |1 - include/configs/davinci_dm355leopard.h |1 - include/configs/davinci_dm365evm.h |1 - include/configs/davinci_dm6467evm.h|1 - include/configs/davinci_dvevm.h|3 --- include/configs/davinci_schmoogie.h|1 - include/configs/davinci_sffsdr.h |1 - include/configs/davinci_sonata.h |3 --- include/configs/dnp1110.h |1 - include/configs/gcplus.h |1 - include/configs/kb9202.h |2 -- include/configs/lpc2292sodimm.h|1 - include/configs/meesc.h|1 - include/configs/mp2usb.h |2 -- include/configs/mx31pdk.h |1 - include/configs/mx51evk.h |1 - include/configs/netstar.h |3 --- include/configs/otc570.h |1 - include/configs/pm9261.h |1 - include/configs/pm9263.h |1 - include/configs/pm9g45.h |1 - include/configs/pxa255_idp.h |1 - include/configs/s5p_goni.h |2 -- include/configs/sbc35_a9g20.h |1 - include/configs/shannon.h |1 - include/configs/smdk6400.h |2 -- include/configs/smdkc100.h |2 -- include/configs/tny_a9260.h|1 - include/configs/vision2.h |2 -- include/configs/zipitz2.h |1 - include/configs/zylonite.h |1 - 61 files changed, 8 insertions(+), 109 deletions(-) diff --git a/Makefile b/Makefile index b187611..ae36ea5 100644 --- a/Makefile +++ b/Makefile @@ -1067,7 +1067,6 @@ mx31pdk_nand_config : unconfig echo #define CONFIG_NAND_U_BOOT $(obj)include/config.h; \ else \ echo #define CONFIG_SKIP_LOWLEVEL_INIT $(obj)include/config.h; \ - echo #define CONFIG_SKIP_RELOCATE_UBOOT $(obj)include/config.h;\ fi @$(MKCONFIG) -n $@ -a mx31pdk arm arm1136 mx31pdk freescale mx31 diff --git a/README b/README index f559811..1acf9a3 100644 --- a/README +++ b/README @@ -2836,19 +2836,17 @@ Low Level (hardware related) configuration options: globally (CONFIG_CMD_MEM). - CONFIG_SKIP_LOWLEVEL_INIT -- CONFIG_SKIP_RELOCATE_UBOOT +[ARM only] If this variable is defined, then certain +low level initializations (like setting up the memory +controller) are omitted and/or U-Boot does not +relocate itself into RAM. - [ARM only] If these variables are defined, then - certain low level initializations (like setting up - the memory controller) are omitted and/or U-Boot does - not relocate itself into RAM. - Normally these variables MUST NOT be
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
Dear Kristoffer Ericson, In message 20101028190714.gd...@boggieman.bredbandsbolaget.se you wrote: No. U-Boot is long dead and gone when Linux boots. Is that true even if I were to setup the memory registers incorrect? It is truye that U-Boot ceases to exist as soon as Linux starts executing. I thought that linux pretty much expected the bootloader to setup everything regarding the memory settings? Of course Linux relies on proper hardware initialization by the boot loader. Oh, and IF I configured the memory incorrect, I should be able to see somekind of fault when doing a memtest in u-boot, correct? No. Usually this is NOT the case. Or atleast that the write != read values? No. Please read the FAQ: http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation 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 was so narrow minded he could see through a keyhole with both eyes ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] CONFIG_SYS_SDRAM and CONFIG_SYS_INIT_SP_ADDR defines for versatile boards.
Following is the patch for defining the subject line mentioned configuration defines for versatile boards. Signed-off-by: Himanshu Chauhan hschau...@nulltrace.org --- include/configs/versatile.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/versatile.h b/include/configs/versatile.h index 45d8434..2da567a 100644 --- a/include/configs/versatile.h +++ b/include/configs/versatile.h @@ -231,4 +231,7 @@ #define CONFIG_SYS_FLASH_PROTECTION/* The devices have real protection */ #define CONFIG_SYS_FLASH_EMPTY_INFO/* flinfo indicates empty blocks */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE \ +- GENERATED_GBL_DATA_SIZE) #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] GENERATED_GBL_DATA_SIZE problem
On Thu, Oct 28, 2010 at 06:55:14PM +0200, Wolfgang Denk wrote: Dear Himanshu Chauhan, In message 20101028164616.ga3...@pnq-hchauhan-vm you wrote: Hi List, Day before I reported the problem with declarations of CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. In the following patch GENERATED_GBL_DATA_SIZE is defined as #96. The pound size before the number is cauing the assembler go mad. It doesn't compile. Remove the pound and its okay. Is the pound sign really required or is this problem with the sed script being used for it? Please update your code. This has been fixed yesterday morning. Patch is in mainline since last night. Thanks Wolfgang, It works. Regards Himanshu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 V4] Move and rename common headers from under board/davinci.
Move the davinci common headers to the architecture specific include file path. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com --- Changes since V3: * No change in this patch of the patchset .../arm/include/asm/arch-davinci/da8xx_common.h|0 .../arm/include/asm/arch-davinci/davinci_misc.h|0 board/davinci/common/misc.c|2 +- board/davinci/da8xxevm/common.c|2 +- board/davinci/da8xxevm/da830evm.c |4 ++-- board/davinci/da8xxevm/da850evm.c |4 ++-- board/davinci/dm355evm/dm355evm.c |2 +- board/davinci/dm355leopard/dm355leopard.c |2 +- board/davinci/dm365evm/dm365evm.c |2 +- board/davinci/dvevm/dvevm.c|2 +- board/davinci/schmoogie/schmoogie.c|2 +- board/davinci/sffsdr/sffsdr.c |2 +- board/davinci/sonata/sonata.c |2 +- 13 files changed, 13 insertions(+), 13 deletions(-) rename board/davinci/da8xxevm/common.h = arch/arm/include/asm/arch-davinci/da8xx_common.h (100%) rename board/davinci/common/misc.h = arch/arm/include/asm/arch-davinci/davinci_misc.h (100%) diff --git a/board/davinci/da8xxevm/common.h b/arch/arm/include/asm/arch-davinci/da8xx_common.h similarity index 100% rename from board/davinci/da8xxevm/common.h rename to arch/arm/include/asm/arch-davinci/da8xx_common.h diff --git a/board/davinci/common/misc.h b/arch/arm/include/asm/arch-davinci/davinci_misc.h similarity index 100% rename from board/davinci/common/misc.h rename to arch/arm/include/asm/arch-davinci/davinci_misc.h diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c index b60a46e..71e7822 100644 --- a/board/davinci/common/misc.c +++ b/board/davinci/common/misc.c @@ -29,7 +29,7 @@ #include net.h #include asm/arch/hardware.h #include asm/io.h -#include misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c index 9cd5204..36bf693 100644 --- a/board/davinci/da8xxevm/common.c +++ b/board/davinci/da8xxevm/common.c @@ -20,7 +20,7 @@ #include asm/io.h #include asm/arch/hardware.h -#include common.h +#include asm/arch/da8xx_common.h #ifndef CONFIG_USE_IRQ void irq_init(void) diff --git a/board/davinci/da8xxevm/da830evm.c b/board/davinci/da8xxevm/da830evm.c index 8a9f988..b6b7e37 100644 --- a/board/davinci/da8xxevm/da830evm.c +++ b/board/davinci/da8xxevm/da830evm.c @@ -40,8 +40,8 @@ #include asm/arch/emif_defs.h #include asm/arch/emac_defs.h #include asm/io.h -#include ../common/misc.h -#include common.h +#include asm/arch/davinci_misc.h +#include asm/arch/da8xx_common.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c index c8c5e1b..0420ad5 100644 --- a/board/davinci/da8xxevm/da850evm.c +++ b/board/davinci/da8xxevm/da850evm.c @@ -29,8 +29,8 @@ #include asm/arch/emif_defs.h #include asm/arch/emac_defs.h #include asm/io.h -#include ../common/misc.h -#include common.h +#include asm/arch/davinci_misc.h +#include asm/arch/da8xx_common.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/dm355evm/dm355evm.c b/board/davinci/dm355evm/dm355evm.c index 87f284c..b9260b8 100644 --- a/board/davinci/dm355evm/dm355evm.c +++ b/board/davinci/dm355evm/dm355evm.c @@ -22,7 +22,7 @@ #include asm/arch/hardware.h #include asm/arch/emif_defs.h #include asm/arch/nand_defs.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h #include net.h #include netdev.h diff --git a/board/davinci/dm355leopard/dm355leopard.c b/board/davinci/dm355leopard/dm355leopard.c index e89786e..0ee0d11 100644 --- a/board/davinci/dm355leopard/dm355leopard.c +++ b/board/davinci/dm355leopard/dm355leopard.c @@ -22,7 +22,7 @@ #include asm/arch/hardware.h #include asm/arch/gpio_defs.h #include asm/arch/nand_defs.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h #include net.h #include netdev.h diff --git a/board/davinci/dm365evm/dm365evm.c b/board/davinci/dm365evm/dm365evm.c index 85dbe2a..bc681f7 100644 --- a/board/davinci/dm365evm/dm365evm.c +++ b/board/davinci/dm365evm/dm365evm.c @@ -24,7 +24,7 @@ #include asm/arch/nand_defs.h #include asm/arch/gpio_defs.h #include netdev.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/dvevm/dvevm.c b/board/davinci/dvevm/dvevm.c index 073c21a..d5c851b 100644 --- a/board/davinci/dvevm/dvevm.c +++ b/board/davinci/dvevm/dvevm.c @@ -27,7 +27,7 @@ #include common.h #include i2c.h #include asm/arch/hardware.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/schmoogie/schmoogie.c b/board/davinci/schmoogie/schmoogie.c index 80a0f9f..8b615a9 100644 --- a/board/davinci/schmoogie/schmoogie.c +++
[U-Boot] [PATCH 2/3 V4] Remove board_nand_init from nand_boot.c
Remove the board_init_f function from nand_spl/nand_boot.c. This
function is to be defined by all boards using the nand_spl
functionality in their individual board directory.
Currently this function was being used by the smdk6400 board. Added
the board specific function definition.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
Changes since V3:
* Removed the board_init_f function from the nand_boot.c instead of
adding a weak declaration.
* Added a corresponding function definition for the smdk6400 board.
The changes for smdk6400 have not been tested as it is currently
broken due to the relocation and ELF-RELOC changes.
board/samsung/smdk6400/smdk6400_nand_spl.c | 37
nand_spl/board/samsung/smdk6400/Makefile |6 -
nand_spl/nand_boot.c |8 --
3 files changed, 42 insertions(+), 9 deletions(-)
create mode 100644 board/samsung/smdk6400/smdk6400_nand_spl.c
diff --git a/board/samsung/smdk6400/smdk6400_nand_spl.c
b/board/samsung/smdk6400/smdk6400_nand_spl.c
new file mode 100644
index 000..a023284
--- /dev/null
+++ b/board/samsung/smdk6400/smdk6400_nand_spl.c
@@ -0,0 +1,37 @@
+/*
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * (C) Copyright 2002
+ * David Mueller, ELSOFT AG, d.muel...@elsoft.ch
+ *
+ * (C) Copyright 2008
+ * Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+void board_init_f(unsigned long bootflag)
+{
+ relocate_code(CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
+ CONFIG_SYS_TEXT_BASE);
+}
diff --git a/nand_spl/board/samsung/smdk6400/Makefile
b/nand_spl/board/samsung/smdk6400/Makefile
index 2111e57..18cee10 100644
--- a/nand_spl/board/samsung/smdk6400/Makefile
+++ b/nand_spl/board/samsung/smdk6400/Makefile
@@ -35,7 +35,7 @@ AFLAGS+= -DCONFIG_NAND_SPL
CFLAGS += -DCONFIG_NAND_SPL
SOBJS = start.o cpu_init.o lowlevel_init.o
-COBJS = nand_boot.o nand_ecc.o s3c64xx.o
+COBJS = nand_boot.o nand_ecc.o s3c64xx.o smdk6400_nand_spl.o
SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
@@ -93,6 +93,10 @@ $(obj)s3c64xx.c:
@rm -f $@
@ln -s $(TOPDIR)/drivers/mtd/nand/s3c64xx.c $@
+$(obj)smdk6400_nand_spl.c:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/smdk6400/smdk6400_nand_spl.c $@
+
#
$(obj)%.o: $(obj)%.S
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index ccd0af2..b9fd6f5 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -221,14 +221,6 @@ static int nand_load(struct mtd_info *mtd, unsigned int
offs,
return 0;
}
-#if defined(CONFIG_ARM) !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-void board_init_f (ulong bootflag)
-{
- relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
- CONFIG_SYS_TEXT_BASE);
-}
-#endif
-
/*
* The main entry for NAND booting. It's necessary that SDRAM is already
* configured and available since this code loads the main U-Boot image
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 V4] Add board support for hawkboard
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
Changes since V3
* Added README.hawkboard
* Moved setting of select_chip to nand_boot function
* Removed the superfluous entry in board/davinci/da8xxevm/Makefile
added earlier.
MAINTAINERS |5 +
arch/arm/include/asm/arch-davinci/da8xx_common.h |3 +
arch/arm/include/asm/arch-davinci/hardware.h |5 +-
board/davinci/common/Makefile|2 +-
board/davinci/common/davinci_pinmux.c| 105 +++
board/davinci/common/misc.c | 75
board/davinci/da8xxevm/Makefile |1 +
board/davinci/da8xxevm/hawkboard.c | 69
board/davinci/da8xxevm/hawkboard_nand_spl.c | 164 +
boards.cfg |3 +
doc/README.hawkboard | 93 ++
include/configs/hawkboard.h | 204 ++
nand_spl/board/davinci/da8xxevm/Makefile | 141 +++
nand_spl/board/davinci/da8xxevm/u-boot.lds | 75
nand_spl/nand_boot.c |1 +
15 files changed, 869 insertions(+), 77 deletions(-)
create mode 100644 board/davinci/common/davinci_pinmux.c
create mode 100644 board/davinci/da8xxevm/hawkboard.c
create mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
create mode 100644 doc/README.hawkboard
create mode 100644 include/configs/hawkboard.h
create mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
create mode 100644 nand_spl/board/davinci/da8xxevm/u-boot.lds
diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..2a7d23d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -851,6 +851,11 @@ Alex Z
lartSA1100
dnp1110 SA1110
+Syed Mohammed Khasim sm.kha...@gmail.com
+Sughosh Ganu urwithsugh...@gmail.com
+
+ hawkboard ARM926EJS (OMAP-L138)
+
-
Unknown / orphaned boards:
diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
index 7ae63a6..bc3092d 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx_common.h
@@ -19,6 +19,9 @@
#ifndef __COMMON_H
#define __COMMON_H
+#defineHAWKBOARD_KICK0_UNLOCK 0x83e70b13
+#defineHAWKBOARD_KICK1_UNLOCK 0x95a4f1e0
+
struct lpsc_resource {
const int lpsc_no;
};
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..d006ac1 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -379,7 +379,10 @@ int clk_get(enum davinci_clk_ids id);
/* Boot config */
struct davinci_syscfg_regs {
dv_reg revid;
- dv_reg rsvd[71];
+ dv_reg rsvd[13];
+ dv_reg kick0;
+ dv_reg kick1;
+ dv_reg rsvd1[56];
dv_reg pinmux[20];
dv_reg suspsrc;
dv_reg chipsig;
diff --git a/board/davinci/common/Makefile b/board/davinci/common/Makefile
index 8d9ea00..dd022f6 100644
--- a/board/davinci/common/Makefile
+++ b/board/davinci/common/Makefile
@@ -29,7 +29,7 @@ endif
LIB= $(obj)lib$(VENDOR).a
-COBJS := misc.o
+COBJS := misc.o davinci_pinmux.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/davinci/common/davinci_pinmux.c
b/board/davinci/common/davinci_pinmux.c
new file mode 100644
index 000..ce58f71
--- /dev/null
+++ b/board/davinci/common/davinci_pinmux.c
@@ -0,0 +1,105 @@
+/*
+ * DaVinci pinmux functions.
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc Ltd, nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ * Copyright (C) 2008 Lyrtech www.lyrtech.com
+ * Copyright (C) 2004 Texas Instruments.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include asm/arch/hardware.h
+#include asm/io.h
+#include asm/arch/davinci_misc.h
+
+/*
+ * Change the setting of a pin multiplexer field.
+ *
+ * Takes an array
Re: [U-Boot] [PATCH 2/3 V4] Remove board_nand_init from nand_boot.c
On Fri, 29 Oct 2010 01:00:07 +0530 Sughosh Ganu urwithsugh...@gmail.com wrote: Remove the board_init_f function from nand_spl/nand_boot.c. This function is to be defined by all boards using the nand_spl functionality in their individual board directory. Currently this function was being used by the smdk6400 board. Added the board specific function definition. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com --- Changes since V3: * Removed the board_init_f function from the nand_boot.c instead of adding a weak declaration. * Added a corresponding function definition for the smdk6400 board. The changes for smdk6400 have not been tested as it is currently broken due to the relocation and ELF-RELOC changes. board/samsung/smdk6400/smdk6400_nand_spl.c | 37 nand_spl/board/samsung/smdk6400/Makefile |6 - nand_spl/nand_boot.c |8 -- 3 files changed, 42 insertions(+), 9 deletions(-) create mode 100644 board/samsung/smdk6400/smdk6400_nand_spl.c Acked-by: Scott Wood scottw...@freescale.com -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
On Thu, Oct 28, 2010 at 09:15:55PM +0200, Wolfgang Denk wrote: Dear Kristoffer Ericson, In message 20101028190714.gd...@boggieman.bredbandsbolaget.se you wrote: No. U-Boot is long dead and gone when Linux boots. Is that true even if I were to setup the memory registers incorrect? It is truye that U-Boot ceases to exist as soon as Linux starts executing. I thought that linux pretty much expected the bootloader to setup everything regarding the memory settings? Of course Linux relies on proper hardware initialization by the boot loader. alright. Oh, and IF I configured the memory incorrect, I should be able to see somekind of fault when doing a memtest in u-boot, correct? No. Usually this is NOT the case. Or atleast that the write != read values? No. Please read the FAQ: http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation Very useful information. So in short (just to make it crystal clear): Even if u-boot works fine and linux starts without any issues and can run some binaries (busybox from what I see) okey. If I am seeing some kernel oops when running bigger binaries (e.g apt/ipkg) / doing heavier stuff (trying to ftp/lynx through pcmcia card), it could be cause by bad memory configuration and/or bad initialization? 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 was so narrow minded he could see through a keyhole with both eyes ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware
Previously fsl_pci_init_port() always assumed that a port was a PCIe
port and would incorrectly print messages for a PCI port such as the
following on bootup:
PCI1: 32 bit, 33 MHz, sync, host, arbiter
Scanning PCI bus 00
PCIE1 on bus 00 - 00
This change corrects the output of fsl_pci_init_port():
PCI1: 32 bit, 33 MHz, sync, host, arbiter
Scanning PCI bus 00
PCI1 on bus 00 - 00
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Tested on a MPC8548 with PCI, and a MPC8640 with PCIe
drivers/pci/fsl_pci_init.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 1f02103..45794da 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -441,6 +441,8 @@ int fsl_pci_init_port(struct fsl_pci_info *pci_info,
{
volatile ccsr_fsl_pci_t *pci;
struct pci_region *r;
+ pci_dev_t dev = PCI_BDF(busno,0,0);
+ u8 pcie_cap;
pci = (ccsr_fsl_pci_t *) pci_info-regs;
@@ -479,7 +481,9 @@ int fsl_pci_init_port(struct fsl_pci_info *pci_info,
hose-last_busno = hose-first_busno;
}
- printf(PCIE%x on bus %02x - %02x\n, pci_info-pci_num,
+ pci_hose_read_config_byte(hose, dev, FSL_PCIE_CAP_ID, pcie_cap);
+ printf(PCI%s%x on bus %02x - %02x\n, pcie_cap == PCI_CAP_ID_EXP ?
+ E : , pci_info-pci_num,
hose-first_busno, hose-last_busno);
return(hose-last_busno + 1);
--
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 3/3] tqm85xx: Update PCI code
On Wed, 2010-10-27 at 08:47 +0200, Wolfgang Denk wrote: 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: Thanks. 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 Its unclear what the correct behavior is here. I just did a quick sample of recent Freescale reference boards and generally see: p1020ds/p2020dsmpc8572: printf(PCIE%u connected to %s as %s (base addr %lx)\n, Older boards with PCI often look like: mpc8548/mpc8568mds: printf (\nPCI: %d bit, %s MHz, %s, %s, %s (base address %lx)\n, The TQM boards, socrates, and mpc8349 are/were: printf (PCI1: %d bit, %s MHz, %s, %s, %s\n); So the original behavior of the TQM board was out of sync with the majority of other boards, and some boards have a newline. I agree we should get rid of the newline on all these printfs, but the indentation issue is murkier to me. The common Freescale PCI code currently assumes there is an indentation, so we should really sync boards'/FSL indentation up to be consistent. Anyone have a strong preference for the indentation? p2020 way, or socrates way above? Scanning PCI bus 00 PCIE1 on bus 00 - 00 I just sent a patch to address this issue. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/3] ARM Relocation Config Cleanup
Dear Wolfgang Denk, Wolfgang Denk (3): Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_BROKEN_RELOC_FIXUP Seems a slight misnomer to me, and a bit hides what it really does. What about CONFIG_NEEDS_DATA_RELOC_FIXUP ? arch/arm/cpu/arm1136/start.S | 131 arch/arm/cpu/arm1176/start.S | 218 -- arch/arm/cpu/arm720t/start.S | 107 - arch/arm/cpu/arm920t/start.S | 146 -- arch/arm/cpu/arm925t/start.S | 123 --- arch/arm/cpu/arm926ejs/orion5x/dram.c | 15 -- arch/arm/cpu/arm926ejs/start.S | 100 arch/arm/cpu/arm946es/start.S | 87 --- arch/arm/cpu/arm_intcm/start.S | 89 --- arch/arm/cpu/armv7/omap3/emif4.c | 24 --- arch/arm/cpu/armv7/omap3/sdrc.c| 28 arch/arm/cpu/armv7/omap4/board.c |5 - arch/arm/cpu/armv7/start.S | 117 -- arch/arm/cpu/ixp/start.S | 205 - arch/arm/cpu/lh7a40x/start.S | 115 -- arch/arm/cpu/pxa/start.S | 32 +--- arch/arm/cpu/s3c44b0/start.S | 87 --- arch/arm/cpu/sa1100/start.S| 90 --- Maybe for a future patch series: Move all not ARM variant/not SoC specific parts (setting up stack, calling C functions, relocation and relocation fixup) to a common file (arch/arm/lib/generic_start.S), basically leaving only specific parts in the various arch/arm/cpu/*/start.S files. This would highly ease maintenance. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
Dear Kristoffer Ericson, In message 20101028195324.gf...@boggieman.bredbandsbolaget.se you wrote: Very useful information. So in short (just to make it crystal clear): Even if u-boot works fine and linux starts without any issues and can run some binaries (busybox from what I see) okey. If I am seeing some kernel oops when running bigger binaries (e.g apt/ipkg) / doing heavier stuff (trying to ftp/lynx through pcmcia card), it could be cause by bad memory configuration and/or bad initialization? Yes, especially that are such symptoms. Of course, broken hardware is also an option. 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 will also, for an appropriate fee, certify that your keyboard is object-oriented, and that the bits on your hard disk are template- compatible.- Jeffrey S. Haemer in 411akr$...@cygnus.com ___ 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 1288298646.8967.130.ca...@petert you wrote: So the original behavior of the TQM board was out of sync with the majority of other boards, and some boards have a newline. Let's say a large number of board maintainers do not care about nice formatting of the output. So if we use common code for a certain set, please let's not use the lowest common denominator. I agree we should get rid of the newline on all these printfs, but the indentation issue is murkier to me. The common Freescale PCI code currently assumes there is an indentation, so we should really sync boards'/FSL indentation up to be consistent. Anyone have a strong preference for the indentation? p2020 way, or socrates way above? Why should the PCI output be indented? It is not so on any other board I ever had my fingers on. Example - all APM boards look like that: CPU: AMCC PowerPC 460EX Rev. B at 1066.667 MHz (PLB=266 OPB=88 EBC=88) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter enabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 1*PCIe/1*SATA, Rev. 16 I2C: ready DRAM: 512 MiB (ECC not enabled, 533 MHz, CL4) FLASH: 64 MiB NAND: 128 MiB PCI: Bus Dev VenId DevId Class Int PCIE1: link is not up. DTT: 1 is 27 C Net: ppc_4xx_eth0, ppc_4xx_eth1 ... Output starts in the first column, all nicely aligned. Scanning PCI bus 00 PCIE1 on bus 00 - 00 I just sent a patch to address this issue. 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 Boykottiert Microsoft - Kauft Eure Fenster bei OBI! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/3] ARM Relocation Config Cleanup
Dear Reinhard Meyer, In message 4cc9e2a7.3080...@emk-elektronik.de you wrote: Wolfgang Denk (3): Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_BROKEN_RELOC_FIXUP Seems a slight misnomer to me, and a bit hides what it really does. What about CONFIG_NEEDS_DATA_RELOC_FIXUP ? I'm open for suggestions... Maybe for a future patch series: Move all not ARM variant/not SoC specific parts (setting up stack, calling C functions, relocation and relocation fixup) to a common file (arch/arm/lib/generic_start.S), basically leaving only specific parts in the various arch/arm/cpu/*/start.S files. This would highly ease maintenance. Agreed. But that needs to be done by someone who has a clue about ARM; I'm just an old patch-monkey when it comes to that. 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 price of curiosity is a terminal experience. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Adds general Freescale CodeWarrior debug support
This patch adds general CodeWarrior debug support. Patch is tested on 85xx/QorIQ platforms in u-boot. CONFIG_DEBUG_CODEWARRIOR should be defined if the u-boot needs to be debugged by CodeWarrior. To use the CodeWarrior debug funciton, the make command can be just as make CONFIG_DEBUG_CODEWARRIOR=1 Signed-off-by: Roy Zang tie-fei.z...@freescale.com Signed-off-by: adrian bogdan adrian.bog...@freescale.com Cc: Wood Scott-B07421 b07...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- config.mk |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/config.mk b/config.mk index ce8e5f2..4d4bb59 100644 --- a/config.mk +++ b/config.mk @@ -189,6 +189,10 @@ else CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes endif +ifdef CONFIG_DEBUG_CODEWARRIOR +CFLAGS += -ggdb +endif + CFLAGS += $(call cc-option,-fno-stack-protector) # $(CPPFLAGS) sets -g, which causes gcc to pass a suitable -gformat @@ -202,6 +206,10 @@ AFLAGS_DEBUG := -Wa,-gstabs,-S endif endif +ifdef CONFIG_DEBUG_CODEWARRIOR +AFLAGS_DEBUG := -Wa,-gdwarf2 +endif + AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS) -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adds general Freescale CodeWarrior debug support
Dear Roy Zang, In message 1288322837-17193-1-git-send-email-tie-fei.z...@freescale.com you wrote: This patch adds general CodeWarrior debug support. Patch is tested on 85xx/QorIQ platforms in u-boot. CONFIG_DEBUG_CODEWARRIOR should be defined if the u-boot needs to be debugged by CodeWarrior. To use the CodeWarrior debug funciton, the make command can be just as make CONFIG_DEBUG_CODEWARRIOR=1 I don't like that approach, for a number of reasons. First, I don't want to see the code sprinkled with a growing list of CONFIG_DEBUG_CODEWARRIOR, CONFIG_DEBUG_BDI, CONFIG_DEBUG_PEEDIE, CONFIG_DEBUG_TRACE32, CONFIG_DEBUG_OCD, CONFIG_DEBUG_CORELIS, ... defines. What in your additions is actually specific to the CW debugger? config.mk |8 Second, I understand that this has been tested with and is intended for (a certain class of) Power Architecture systems only. Then why do you add it to the top level Makefile? +ifdef CONFIG_DEBUG_CODEWARRIOR +CFLAGS += -ggdb +endif Are you sure that CFLAGS is OK here? I would expect to see this with PLATFORM_CPPFLAGS instead. 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 Minds are like parachutes - they only function when open. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/3] ARM Relocation Config Cleanup
Hello Reinhard, Reinhard Meyer wrote: [...] Maybe for a future patch series: Move all not ARM variant/not SoC specific parts (setting up stack, calling C functions, relocation and relocation fixup) to a common file (arch/arm/lib/generic_start.S), basically leaving only specific parts in the various arch/arm/cpu/*/start.S files. This would highly ease maintenance. Yep, I thought about this too, as I made the relocation stuff, but I decided to think about that in a second step... 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
