Re: [U-Boot] u-boot 1.1.2 boot latest powerpc based kernel?
On Thu, May 13, 2010 at 7:47 AM, Timur Tabi ti...@freescale.com wrote: The only way to find out for sure is to test it. You'll probably need to enable cuImage support in the kernel, at the very least. No one keeps track of whether newer kernels work with older U-Boots, so there's no way to know in advance whether a specific kernel and a specific device tree and a specific (older) U-Boot will work together. Thanks for the comments. However my concern is specific to the powerpc arch. If I understand correctly, the powerpc arch expects a bootloader provide a DTS file. I'm not sure how the current U-Boot transfers such info to the kernerl. People here can shed some light on this? I'm certain the old U-Boot (e.g. 1.1.2) doesn't have this kind of capability. The bd_info is still one of data transferred to the kernel, right? How does bd_info work with the DTS info? Thanks, -Shawn. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm/pxa-devel: fix and cleanup of pxa_mem_setup macro
* strict following to section 6.4.10 of Intel PXA27xx Developer's Manual. * use r7 to store CONFIG_SYS_MDREFR_VAL as r6 is used in pxa_wait_ticks WARNING: This macro do not assume the values for K0DB4, KxDB2, KxFREE and APD bits of CONFIG_SYS_MDREFR_VAL as it was done early on many pxa platforms. All pxa developers that plan to use this macro should check the validity of their MDREFR values. Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com --- arch/arm/include/asm/arch-pxa/macro.h | 81 +++-- 1 files changed, 56 insertions(+), 25 deletions(-) diff --git a/arch/arm/include/asm/arch-pxa/macro.h b/arch/arm/include/asm/arch-pxa/macro.h index 1f1759b..26d7a8d 100644 --- a/arch/arm/include/asm/arch-pxa/macro.h +++ b/arch/arm/include/asm/arch-pxa/macro.h @@ -102,7 +102,11 @@ /* * This macro sets up the Memory controller of the PXA2xx CPU * - * Clobbered regs: r3, r4, r5 + * Clobbered regs: r3, r4, r5, r6, r7 + * + * See section 6.4.10 of Intel PXA2xx Processor Developer's Manual + * http://www.marvell.com/products/processors/applications/pxa_family/pxa_27x_dev_man.pdf + * http://www.marvell.com/products/processors/applications/pxa_family/PXA3xx_Developers_Manual.zip */ .macro pxa_mem_setup /* This comes handy when setting MDREFR */ @@ -149,27 +153,38 @@ */ /* -* Before accessing MDREFR we need a valid DRI field, so we set -* this to power on defaults + DRI field. +* Before accessing MDREFR we need a valid DRI field. +* Also we must properly configure MDREFR[K0DB2] and MDREFR[K0DB4]. +* Optionaly we can set MDREFR[KxFREE] bits. +* So we set MDREFR to power on defaults + (DRI, K0DB2, K0DB4, KxFREE) +* fields from the config. +* +* WARNING: K0DB2 and K0DB4 bits are usually set, while KxFREE bits +* are usually unser. */ ldr r5, [r3, #MDREFR_OFFSET] - bic r5, r5, #0x0ff - bic r5, r5, #0xf00 /* MDREFR user config with zeroed DRI */ - - ldr r4, =CONFIG_SYS_MDREFR_VAL - mov r6, r4 - lsl r4, #20 - lsr r4, #20 /* Get a valid DRI field */ + ldr r4, =( 0xFFF | MDREFR_K0DB4 | MDREFR_K0DB2 ) + orr r4, #( MDREFR_K0FREE | MDREFR_K1FREE | MDREFR_K2FREE ) + bic r5, r5, r4 /* clear DRI, K0DB2, K0DB4, KxFREE fields */ - orr r5, r5, r4 /* MDREFR user config with correct DRI */ + /* +* r3 is busy with MEMC_BASE, +* r4, r5, r6 used in pxa_wait_ticks and other places, +* so use r7 to store user specified MDREFR_VAL +*/ + ldr r7, =CONFIG_SYS_MDREFR_VAL + and r4, r7, r4 + orr r5, r5, r4 /* use custom DRI, K0DB2, K0DB4, KxFREE */ orr r5, #MDREFR_K0RUN orr r5, #MDREFR_SLFRSH bic r5, #MDREFR_APD bic r5, #MDREFR_E1PIN + bic r5, #MDREFR_K1RUN + bic r5, #MDREFR_K2RUN str r5, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] /* * 5) Initialize Synchronous Static Memory (Flash/Peripherals) @@ -184,16 +199,29 @@ write32rb (MEMC_BASE + SXCNFG_OFFSET), CONFIG_SYS_SXCNFG_VAL /* -* 6) Initialize SDRAM +* 6) Initialize SDRAM, +*also we must properly set MDREFR[K1DB2] and MDREFR[K2DB2] +* +*WARNING: K1DB2 and K2DB2 bits are usually set */ - bic r6, #MDREFR_SLFRSH - str r6, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + and r4, r7, #( MDREFR_K1DB2 | MDREFR_K2DB2 ) + ldr r5, [r3, #MDREFR_OFFSET] + bic r5, #( MDREFR_K1DB2 | MDREFR_K2DB2 ) + orr r5, r5, r4 - orr r6, #MDREFR_E1PIN - str r6, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + orr r5, #MDREFR_K1RUN + orr r5, #MDREFR_K2RUN + str r5, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] + + bic r5, #MDREFR_SLFRSH + str r5, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] + + orr r5, #MDREFR_E1PIN + str r5, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] /* * 7) Write MDCNFG with MDCNFG:DEx deasserted (set to 0), to configure @@ -246,14 +274,17 @@ ldr r4, [r3, #MDMRS_OFFSET] /* -* 11) Enable APD +* 11) Optionaly enable MDREFR[APD] +* +* WARNING: APD bit is usually set. */ - ldr r4, [r3, #MDREFR_OFFSET] - and r6, r6, #MDREFR_APD - orr r4, r4, r6 - str r4, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + and r7, #MDREFR_APD + ldr r5, [r3, #MDREFR_OFFSET] + bic r5,
Re: [U-Boot] u-boot 1.1.2 boot latest powerpc based kernel?
Dear Shawn Jin, In message aanlktik4dbcknikruj4jtmphpqildgbxtw5ihby0x...@mail.gmail.com you wrote: On Thu, May 13, 2010 at 7:47 AM, Timur Tabi ti...@freescale.com wrote: The only way to find out for sure is to test it. You'll probably need to enable cuImage support in the kernel, at the very least. No one ---^^ However my concern is specific to the powerpc arch. If I understand correctly, the powerpc arch expects a bootloader provide a DTS file. Not if you use a cuImage as Timur suggested. I'm not sure how the current U-Boot transfers such info to the kernerl. People here can shed some light on this? I'm certain the old U-Boot (e.g. 1.1.2) doesn't have this kind of capability. The bd_info It would be easier if you upgraded to a recent version of U-Boot of course. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm not a god, I was misquoted. - Lister, Red Dwarf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for LPC2468 from NXP
Add Support for LPC2468 from NXP
Basic startup code
Internal flash is uspported (for environment storage)
---
MAINTAINERS |4 +
MAKEALL |1 +
Makefile |3 +
arch/arm/cpu/arm720t/cpu.c |4 +-
arch/arm/cpu/arm720t/interrupts.c| 43 ++-
arch/arm/cpu/arm720t/lpc24xx/Makefile| 50 +++
arch/arm/cpu/arm720t/lpc24xx/flash.c | 236
arch/arm/cpu/arm720t/lpc24xx/iap_entry.S |7 +
arch/arm/cpu/arm720t/start.S | 12 +-
arch/arm/include/asm/arch-lpc24xx/hardware.h | 32 ++
arch/arm/include/asm/arch-lpc24xx/immap.h| 532 ++
arch/arm/include/asm/config.h|4 +
arch/arm/lib/eabi_compat.c |5 +
drivers/serial/Makefile |1 +
drivers/serial/serial_lpc2468.c | 119 ++
include/flash.h |1 +
16 files changed, 1049 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/Makefile
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/flash.c
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/iap_entry.S
create mode 100644 arch/arm/include/asm/arch-lpc24xx/hardware.h
create mode 100644 arch/arm/include/asm/arch-lpc24xx/immap.h
create mode 100644 drivers/serial/serial_lpc2468.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cbc845..3cdf22d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -708,6 +708,10 @@ Manikandan Pillai mani.pil...@ti.com
omap3_evm ARM CORTEX-A8 (OMAP3xx SoC)
+Remco Poelstra remco.poels...@duran-audio.com
+
+ LPC2468 LPC2468
+
Stelian Pop stelian@leadtechdesign.com
at91cap9adk ARM926EJS (AT91CAP9 SoC)
diff --git a/MAKEALL b/MAKEALL
index bb09627..2f747c6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -540,6 +540,7 @@ LIST_ARM7= \
impa7 \
integratorap\
lpc2292sodimm \
+ LPC2468 \
modnet50\
SMN42 \
diff --git a/Makefile b/Makefile
index 82cbbf4..a4212c8 100644
--- a/Makefile
+++ b/Makefile
@@ -3148,6 +3148,9 @@ evb4510_config : unconfig
lpc2292sodimm_config: unconfig
@$(MKCONFIG) $(@:_config=) arm arm720t lpc2292sodimm NULL lpc2292
+LPC2468_config:unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm720t LPC2468 NULL lpc24xx
+
SMN42_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm720t SMN42 siemens lpc2292
diff --git a/arch/arm/cpu/arm720t/cpu.c b/arch/arm/cpu/arm720t/cpu.c
index 88c71bf..578358c 100644
--- a/arch/arm/cpu/arm720t/cpu.c
+++ b/arch/arm/cpu/arm720t/cpu.c
@@ -63,7 +63,9 @@ int cleanup_before_linux (void)
/* go to high speed */
IO_SYSCON3 = (IO_SYSCON3 ~CLKCTL) | CLKCTL_73;
#endif
-#elif defined(CONFIG_NETARM) || defined(CONFIG_S3C4510B) ||
defined(CONFIG_LPC2292)
+#elif defined(CONFIG_NETARM) || defined(CONFIG_S3C4510B) ||\
+ defined(CONFIG_LPC2000)
+
disable_interrupts ();
/* Nothing more needed */
#elif defined(CONFIG_INTEGRATOR) defined(CONFIG_ARCH_INTEGRATOR)
diff --git a/arch/arm/cpu/arm720t/interrupts.c
b/arch/arm/cpu/arm720t/interrupts.c
index eb8d425..2ef7101 100644
--- a/arch/arm/cpu/arm720t/interrupts.c
+++ b/arch/arm/cpu/arm720t/interrupts.c
@@ -30,6 +30,8 @@
#include clps7111.h
#include asm/proc-armv/ptrace.h
#include asm/hardware.h
+#include asm/io.h
+#include asm/arch/immap.h
#ifndef CONFIG_NETARM
/* we always count down the max. */
@@ -80,6 +82,14 @@ void do_irq (struct pt_regs *pt_regs)
pfnct = (void (*)(void))VICVectAddr;
(*pfnct)();
+#elif defined(CONFIG_LPC2468)
+ void (*pfnct) (void);
+ vic_2468_t *vic = (((immap_t *)CONFIG_SYS_IMMAP)-ahb.vic);
+
+ pfnct = (void (*)(void))((vic-vicaddr));
+
+ (*pfnct) ();
+
#else
#error do_irq() not defined for this CPU type
#endif
@@ -138,6 +148,10 @@ int arch_interrupt_init (void)
int timer_init (void)
{
+#if defined(CONFIG_LPC2468)
+ timer_2468_t *timer0=(((immap_t *)CONFIG_SYS_IMMAP)-apb.timer0);
+#endif
+
#if defined(CONFIG_NETARM)
/* disable all interrupts */
IRQEN = 0;
@@ -191,6 +205,13 @@ int timer_init (void)
PUT32(T0MCR, 0);
PUT32(T0TC, 0);
PUT32(T0TCR, 1);/* enable timer0 */
+#elif defined(CONFIG_LPC2468)
+ writel (0, (timer0-ir)); /*disable all timer0 interupts
*/
+ writel (0, (timer0-tcr)); /*disable timer0 */
+ writel (CFG_SYS_CLK_FREQ / CONFIG_SYS_HZ - 1, (timer0-pr));
+ writel (0, (timer0-mcr));
+ writel (0, (timer0-tc));
+ writel (1, (timer0-tcr));
#else
#error No timer_init() defined for this CPU type
@@ -207,7 +228,8 @@ int timer_init (void)
*/
-#if defined(CONFIG_IMPA7) || defined(CONFIG_EP7312) || defined(CONFIG_NETARM)
|| defined(CONFIG_ARMADILLO) ||
Re: [U-Boot] [PATCH 4/4] Environment in MMC
Hi, I've just send v6 version for review which fixes the coding-style problems. Thanks~~ Yours Terry -Original Message- From: Stefano Babic [mailto:sba...@denx.de] Sent: 2010年5月14日 19:41 To: Alagu Sankar Cc: Stefano Babic; Sudhakar Rajashekhara; u-boot@lists.denx.de; Lv Terry-R65388 Subject: Re: [U-Boot] [PATCH 4/4] Environment in MMC Alagu Sankar wrote: When I searched for the Environment support in MMC, I came across Terry's earlier patches, but they were not cleanly getting applied to the current tree. I have tried to apply again last Terry's patch, I see only a couple of coding-style problems, no errors at all: Applying: Save environment data to mmc. /home/stefano/Projects/imx/u-boot-imx/.git/rebase-apply/patch:21: trailing whitespace. * Thus It is required that operations like pin multiplexer /home/stefano/Projects/imx/u-boot-imx/.git/rebase-apply/patch:54: trailing whitespace. * Thus It is required that operations like pin multiplexer warning: 2 lines add whitespace errors. There is no value add here except fixing the patch errors and generating a new patch for the current tree. Probably not needed. I have not seen the errors you reported. Are you sure you have tested with Terry's last patch ? It seems you submit an earlier version. So there is no question of adding any copyright here. Yes, Wolfgang has already answered. No need to add a copyright for small patches. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] UBI: Ensure that background thread operations are really executed
The current U-Boot UBI implementation is copied from Linux. In this porting the UBI background thread was not handled correctly. Upon write operations ubi_wl_flush() makes sure, that all queued operations, like page-erase, are completed. But this is missing for read operations. This patch now makes sure that such operations (like scrubbing upon bit-flip errors) are not queued, but executed directly. Signed-off-by: Stefan Roese s...@denx.de --- drivers/mtd/ubi/wl.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c index 2f9a5e3..88b867a 100644 --- a/drivers/mtd/ubi/wl.c +++ b/drivers/mtd/ubi/wl.c @@ -696,8 +696,13 @@ static void schedule_ubi_work(struct ubi_device *ubi, struct ubi_work *wrk) list_add_tail(wrk-list, ubi-works); ubi_assert(ubi-works_count = 0); ubi-works_count += 1; - if (ubi-thread_enabled) - wake_up_process(ubi-bgt_thread); + + /* +* U-Boot special: We have no bgt_thread in U-Boot! +* So just call do_work() here directly. +*/ + do_work(ubi); + spin_unlock(ubi-wl_lock); } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] UBI: Fix problem in UBI/Linux compatibility layer
down_write_trylock needs to return 1 instead of 0 for success.
Otherwise copying a block with a read error (e.g. bit-flip on read)
won't work correctly.
Signed-off-by: Stefan Roese s...@denx.de
---
include/ubi_uboot.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 60f6a5f..d2c90a6 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -123,7 +123,7 @@ typedef int wait_queue_head_t;
#define init_rwsem(...)do { } while (0)
#define down_read(...) do { } while (0)
#define down_write(...)do { } while (0)
-#define down_write_trylock(...)0
+#define down_write_trylock(...)1
#define up_read(...) do { } while (0)
#define up_write(...) do { } while (0)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] flash_real_protect() and CFI_CMDSET_AMD_STANDARD
Hi Timur,
On Friday 14 May 2010 21:17:44 Timur Tabi wrote:
I'm trying to add support for AMD manufacturer ID to flash_real_protect().
The code currently does this:
case CFI_CMDSET_AMD_EXTENDED:
case CFI_CMDSET_AMD_STANDARD:
/* U-Boot only checks the first byte */
if (info-manufacturer_id == (uchar)ATM_MANUFACT) {
...
}
break;
Unfortunately, I don't really understand CFI programming that well, but
from my research, it appears to me that AMD chips that implement the AMD
standard command set will work with this code:
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
flash_write_cmd (info, sector, 0,
FLASH_CMD_CLEAR_STATUS);
flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
if (prot)
flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_SET);
else
flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_CLEAR);
break;
Yes, you might be correct here. I have to admit that I never used
CONFIG_SYS_FLASH_PROTECTION on AMD/Spansion type FLASH chips though.
So I don't understand the need for Rafael Campos' patch:
http://lists.denx.de/pipermail/u-boot/2008-July/037419.html
It looks as if Rafael removed support for hardware flash protection from
all AMD standard/extended flash chips that are not made by Atmel.
Yes, it definitely looks that way. I have missed this. Thanks for looking into
this. It would be great if you could send a patch fixing this.
Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hardware flash protect kept during a reboot?
Hi Timur, On Friday 14 May 2010 21:33:28 Timur Tabi wrote: If I enable CONFIG_SYS_FLASH_PROTECTION and have a support flash chipset, are my protected sectors supposed to remain protected during a reboot? That is, if I protect some flash sector, and then reboot U-Boot, I know U-Boot will not show the sector as being protected, because the info-protect[] array is initialized on every boot. However, since I was using hardware protection, I expect the chip will still protect the sector. This protection is chip specific. IIRC, then some Intel (Strata) chips either protect all sectors or have a sectore-wise protection mechanism. You need to check your FLASH documentation for the exact behaviour. Which chip are you using? Please note that we have the special unlock env variable. By setting it to yes, all sectors will be unlocked upon startup. At least on Intel Strata FLASH chips. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Fix building PLU405 board
On Tuesday 11 May 2010 09:54:00 Matthias Fuchs wrote: Due to some overlapping sections it's time to update TEXT_BASE for this board. Applied to u-boot-ppc4xx/master. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ppc4xx/master
The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0: Makefile: fix out-of-tree building of u-boot.img target (2010-05-16 02:18:38 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Matthias Fuchs (1): ppc4xx: Fix building PLU405 board board/esd/plu405/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/pxa-devel: fix and cleanup of pxa_mem_setup macro
Dne Po 17. května 2010 08:28:22 Mikhail Kshevetskiy napsal(a): * strict following to section 6.4.10 of Intel PXA27xx Developer's Manual. * use r7 to store CONFIG_SYS_MDREFR_VAL as r6 is used in pxa_wait_ticks WARNING: This macro do not assume the values for K0DB4, KxDB2, KxFREE and APD bits of CONFIG_SYS_MDREFR_VAL as it was done early on many pxa platforms. All pxa developers that plan to use this macro should check the validity of their MDREFR values. Exactly, I'd rather see the developers fix their configs instead of putting here some weird goo. But I might be wrong ... see below please. Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com --- arch/arm/include/asm/arch-pxa/macro.h | 81 +++-- 1 files changed, 56 insertions(+), 25 deletions(-) diff --git a/arch/arm/include/asm/arch-pxa/macro.h b/arch/arm/include/asm/arch-pxa/macro.h index 1f1759b..26d7a8d 100644 --- a/arch/arm/include/asm/arch-pxa/macro.h +++ b/arch/arm/include/asm/arch-pxa/macro.h @@ -102,7 +102,11 @@ /* * This macro sets up the Memory controller of the PXA2xx CPU * - * Clobbered regs: r3, r4, r5 + * Clobbered regs: r3, r4, r5, r6, r7 + * + * See section 6.4.10 of Intel PXA2xx Processor Developer's Manual + * http://www.marvell.com/products/processors/applications/pxa_family/pxa_27x _dev_man.pdf + * http://www.marvell.com/products/processors/applications/pxa_family/PXA3xx_ Developers_Manual.zip */ Remove this, PXA3xx won't use this macro. .macro pxa_mem_setup /* This comes handy when setting MDREFR */ @@ -149,27 +153,38 @@ */ /* - * Before accessing MDREFR we need a valid DRI field, so we set - * this to power on defaults + DRI field. + * Before accessing MDREFR we need a valid DRI field. + * Also we must properly configure MDREFR[K0DB2] and MDREFR[K0DB4]. + * Optionaly we can set MDREFR[KxFREE] bits. + * So we set MDREFR to power on defaults + (DRI, K0DB2, K0DB4, KxFREE) + * fields from the config. + * + * WARNING: K0DB2 and K0DB4 bits are usually set, while KxFREE bits + * are usually unser. */ ldr r5, [r3, #MDREFR_OFFSET] - bic r5, r5, #0x0ff - bic r5, r5, #0xf00 /* MDREFR user config with zeroed DRI */ - - ldr r4, =CONFIG_SYS_MDREFR_VAL - mov r6, r4 - lsl r4, #20 - lsr r4, #20 /* Get a valid DRI field */ + ldr r4, =( 0xFFF | MDREFR_K0DB4 | MDREFR_K0DB2 ) + orr r4, #( MDREFR_K0FREE | MDREFR_K1FREE | MDREFR_K2FREE ) + bic r5, r5, r4 /* clear DRI, K0DB2, K0DB4, KxFREE fields */ - orr r5, r5, r4 /* MDREFR user config with correct DRI */ You can just wipe all the bits away, can't you ? + /* + * r3 is busy with MEMC_BASE, + * r4, r5, r6 used in pxa_wait_ticks and other places, + * so use r7 to store user specified MDREFR_VAL + */ + ldr r7, =CONFIG_SYS_MDREFR_VAL + and r4, r7, r4 + orr r5, r5, r4 /* use custom DRI, K0DB2, K0DB4, KxFREE */ And replace it with user config (if the user config is done correctly of course. If the user config is incorrect, that's what should be fixed.) orr r5, #MDREFR_K0RUN orr r5, #MDREFR_SLFRSH bic r5, #MDREFR_APD bic r5, #MDREFR_E1PIN + bic r5, #MDREFR_K1RUN + bic r5, #MDREFR_K2RUN Then just fine-tune the bits according 6.4.10 in PXA270 manual. btw. these bic's are unneeded according to the manual. Ok, please try explaining why is this solution better from what was here? I'm kind of missing it, sorry. str r5, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] /* * 5) Initialize Synchronous Static Memory (Flash/Peripherals) @@ -184,16 +199,29 @@ write32rb (MEMC_BASE + SXCNFG_OFFSET), CONFIG_SYS_SXCNFG_VAL /* - * 6) Initialize SDRAM + * 6) Initialize SDRAM, + *also we must properly set MDREFR[K1DB2] and MDREFR[K2DB2] + * + *WARNING: K1DB2 and K2DB2 bits are usually set */ - bic r6, #MDREFR_SLFRSH - str r6, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + and r4, r7, #( MDREFR_K1DB2 | MDREFR_K2DB2 ) + ldr r5, [r3, #MDREFR_OFFSET] + bic r5, #( MDREFR_K1DB2 | MDREFR_K2DB2 ) + orr r5, r5, r4 - orr r6, #MDREFR_E1PIN - str r6, [r3, #MDREFR_OFFSET] - ldr r4, [r3, #MDREFR_OFFSET] + orr r5, #MDREFR_K1RUN + orr r5, #MDREFR_K2RUN No, don't enable this unconditionally. + str r5, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] + + bic r5, #MDREFR_SLFRSH + str r5, [r3, #MDREFR_OFFSET] + ldr r5, [r3, #MDREFR_OFFSET] + + orr r5,
[U-Boot] U-boot Hangs in relocate_code function
Hi Andrew, Now am able to get some messages on serial port but it is hanging after DRAM initialization i.e. during relocate_code function, below is the debug messages on serial port. I tried configuring SDRAM (DDR2) for 256 and 128 MB, but still the problem is same. I am facing one typical problem in u-boot i.e. whenever i power on the board I will get below debug messages on serial port after 5 to 8 seconds and hangs at stack pointer. U-Boot 2010.03 (May 14 2010 - 16:41:46) Linux Advanced AVN Platform CPU: Au1350, id: 0x80, rev: 0x01 DRAM: 256 MB Address value =9000Top of RAM usable for U-Boot at: 9000 Reserving 161k for U-Boot at: 8ffd4000 Reserving 192k for malloc() at: 8ffa4000 Reserving 36 Bytes for Board Info at: 8ffa3fdc Reserving 36 Bytes for Global Data at: 8ffa3fb8 Reserving 128k for boot params() at: 8ff83fb8 Stack Pointer at: 8ff83f98 U-Boot 2010.03 (May 14 2010 - 16:49:00) Linux Advanced AVN Platform CPU: Au1350, id: 0x80, rev: 0x01 DRAM: 128 MB Address value =8800Top of RAM usable for U-Boot at: 8800 Reserving 161k for U-Boot at: 87fd4000 Reserving 192k for malloc() at: 87fa4000 Reserving 36 Bytes for Board Info at: 87fa3fdc Reserving 36 Bytes for Global Data at: 87fa3fb8 Reserving 128k for boot params() at: 87f83fb8 Stack Pointer at: 87f83f98 U-Boot 2010.03 (May 14 2010 - 16:53:58) Linux Advanced AVN Platform CPU: Au1350, id: 0x80, rev: 0x01 DRAM: 256 MB Address value =9000Top of RAM usable for U-Boot at: 9000 Reserving 161k for U-Boot at: 8ffd4000 Reserving 192k for malloc() at: 8ffa4000 Reserving 36 Bytes for Board Info at: 8ffa3fdc Reserving 36 Bytes for Global Data at: 8ffa3fb8 Reserving 128k for boot params() at: 8ff83fb8 Stack Pointer at: 8ff83f98 Can you please share me your board config file and lowlevel_init.S file which you have ported u-boot for Au1550. I need it for the reference. I am doing DDR2 initialization in u-boot as per YAMON source code that will create any problem? please help me out to resolve the above issues. Thanks in Advance Regards, Gurumurthy Gowdar KPIT Cummins Infosystems Pvt Ltd ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Timur Tabi wrote: On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren gvb.ub...@gmail.com wrote: The code has one pre-existing weakness that bothers me: if there is something following the FDT blob, it will get overwritten by the increased blob. One way around this would be to malloc() a new memory space and move and expand the blob to the new space. The first time this was done, the original blob should not be free()ed since it wasn't malloc()ed, but the second and subsequent times it should be free()ed. But then how does the caller know where the new blob is? When I call fdt_increase_size(), I pass it the address of a blob that I'm modifying. After the function returns, my value of 'fdt' is no longer valid. Oops, yes, that is a pretty fatal flaw. I've added this to your patch, but have *NOT* execution tested it. Does this addition (a) make sense and (b) work? I was expecting the caller of fdt_increase_size() to know that the space after the fdt is available. OK. I'll acked-by the original patch. The best way to incorporate the patch would be for Kumar (I assume) to pick up the libfdt change with the Freescale change that needs it so that the changes are inherently coordinated. gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone
Timur Tabi wrote:
The function fdt_increase_size() increases the size of the device tree by the
given amount. This is useful for any code that wants to add a node or large
property, to avoid the possibility of running out of space. It's much smarter
to have U-Boot increase the size of device tree when it knows it's going to
add data, instead of hoping that the DTS was compiled with the right -p value.
Signed-off-by: Timur Tabi ti...@freescale.com
Acked-by: Gerald Van Baren vanba...@cideas.com
---
common/fdt_support.c | 20 ++--
include/fdt_support.h |1 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b6f252a..01d635b 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -645,6 +645,16 @@ int fdt_resize(void *blob)
return actualsize;
}
+int fdt_increase_size(void *fdt, int add_len)
+{
+ int newlen;
+
+ newlen = fdt_totalsize(fdt) + add_len;
+
+ /* Open in place with a new len */
+ return fdt_open_into(fdt, fdt, newlen);
+}
+
#ifdef CONFIG_PCI
#define CONFIG_SYS_PCI_NR_INBOUND_WIN 4
@@ -792,16 +802,6 @@ int fdt_del_subnodes(const void *blob, int parent_offset)
return 0;
}
-int fdt_increase_size(void *fdt, int add_len)
-{
- int newlen;
-
- newlen = fdt_totalsize(fdt) + add_len;
-
- /* Open in place with a new len */
- return fdt_open_into(fdt, fdt, newlen);
-}
-
int fdt_del_partitions(void *blob, int parent_offset)
{
const void *prop;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 9a453af..d70627d 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -78,6 +78,7 @@ void ft_pci_setup(void *blob, bd_t *bd);
void set_working_fdt_addr(void *addr);
int fdt_resize(void *blob);
+int fdt_increase_size(void *fdt, int add_len);
int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for LPC2468 from NXP
Add Support for LPC2468 from NXP
Basic startup code
Internal flash is uspported (for environment storage)
---
MAINTAINERS |4 +
MAKEALL |1 +
Makefile |3 +
arch/arm/cpu/arm720t/cpu.c |4 +-
arch/arm/cpu/arm720t/interrupts.c| 43 ++-
arch/arm/cpu/arm720t/lpc24xx/Makefile| 50 +++
arch/arm/cpu/arm720t/lpc24xx/flash.c | 236
arch/arm/cpu/arm720t/lpc24xx/iap_entry.S |7 +
arch/arm/cpu/arm720t/start.S | 12 +-
arch/arm/include/asm/arch-lpc24xx/hardware.h | 32 ++
arch/arm/include/asm/arch-lpc24xx/immap.h| 532 ++
arch/arm/include/asm/config.h|4 +
arch/arm/lib/eabi_compat.c |5 +
drivers/serial/Makefile |1 +
drivers/serial/serial_lpc2468.c | 119 ++
include/flash.h |1 +
16 files changed, 1049 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/Makefile
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/flash.c
create mode 100644 arch/arm/cpu/arm720t/lpc24xx/iap_entry.S
create mode 100644 arch/arm/include/asm/arch-lpc24xx/hardware.h
create mode 100644 arch/arm/include/asm/arch-lpc24xx/immap.h
create mode 100644 drivers/serial/serial_lpc2468.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cbc845..3cdf22d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -708,6 +708,10 @@ Manikandan Pillai mani.pil...@ti.com
omap3_evm ARM CORTEX-A8 (OMAP3xx SoC)
+Remco Poelstra remco.poels...@duran-audio.com
+
+ LPC2468 LPC2468
+
Stelian Pop stelian@leadtechdesign.com
at91cap9adk ARM926EJS (AT91CAP9 SoC)
diff --git a/MAKEALL b/MAKEALL
index bb09627..2f747c6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -540,6 +540,7 @@ LIST_ARM7= \
impa7 \
integratorap\
lpc2292sodimm \
+ LPC2468 \
modnet50\
SMN42 \
diff --git a/Makefile b/Makefile
index 82cbbf4..a4212c8 100644
--- a/Makefile
+++ b/Makefile
@@ -3148,6 +3148,9 @@ evb4510_config : unconfig
lpc2292sodimm_config: unconfig
@$(MKCONFIG) $(@:_config=) arm arm720t lpc2292sodimm NULL lpc2292
+LPC2468_config:unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm720t LPC2468 NULL lpc24xx
+
SMN42_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm720t SMN42 siemens lpc2292
diff --git a/arch/arm/cpu/arm720t/cpu.c b/arch/arm/cpu/arm720t/cpu.c
index 88c71bf..578358c 100644
--- a/arch/arm/cpu/arm720t/cpu.c
+++ b/arch/arm/cpu/arm720t/cpu.c
@@ -63,7 +63,9 @@ int cleanup_before_linux (void)
/* go to high speed */
IO_SYSCON3 = (IO_SYSCON3 ~CLKCTL) | CLKCTL_73;
#endif
-#elif defined(CONFIG_NETARM) || defined(CONFIG_S3C4510B) ||
defined(CONFIG_LPC2292)
+#elif defined(CONFIG_NETARM) || defined(CONFIG_S3C4510B) ||\
+ defined(CONFIG_LPC2000)
+
disable_interrupts ();
/* Nothing more needed */
#elif defined(CONFIG_INTEGRATOR) defined(CONFIG_ARCH_INTEGRATOR)
diff --git a/arch/arm/cpu/arm720t/interrupts.c
b/arch/arm/cpu/arm720t/interrupts.c
index eb8d425..2ef7101 100644
--- a/arch/arm/cpu/arm720t/interrupts.c
+++ b/arch/arm/cpu/arm720t/interrupts.c
@@ -30,6 +30,8 @@
#include clps7111.h
#include asm/proc-armv/ptrace.h
#include asm/hardware.h
+#include asm/io.h
+#include asm/arch/immap.h
#ifndef CONFIG_NETARM
/* we always count down the max. */
@@ -80,6 +82,14 @@ void do_irq (struct pt_regs *pt_regs)
pfnct = (void (*)(void))VICVectAddr;
(*pfnct)();
+#elif defined(CONFIG_LPC2468)
+ void (*pfnct) (void);
+ vic_2468_t *vic = (((immap_t *)CONFIG_SYS_IMMAP)-ahb.vic);
+
+ pfnct = (void (*)(void))((vic-vicaddr));
+
+ (*pfnct) ();
+
#else
#error do_irq() not defined for this CPU type
#endif
@@ -138,6 +148,10 @@ int arch_interrupt_init (void)
int timer_init (void)
{
+#if defined(CONFIG_LPC2468)
+ timer_2468_t *timer0=(((immap_t *)CONFIG_SYS_IMMAP)-apb.timer0);
+#endif
+
#if defined(CONFIG_NETARM)
/* disable all interrupts */
IRQEN = 0;
@@ -191,6 +205,13 @@ int timer_init (void)
PUT32(T0MCR, 0);
PUT32(T0TC, 0);
PUT32(T0TCR, 1);/* enable timer0 */
+#elif defined(CONFIG_LPC2468)
+ writel (0, (timer0-ir)); /*disable all timer0 interupts
*/
+ writel (0, (timer0-tcr)); /*disable timer0 */
+ writel (CFG_SYS_CLK_FREQ / CONFIG_SYS_HZ - 1, (timer0-pr));
+ writel (0, (timer0-mcr));
+ writel (0, (timer0-tc));
+ writel (1, (timer0-tcr));
#else
#error No timer_init() defined for this CPU type
@@ -207,7 +228,8 @@ int timer_init (void)
*/
-#if defined(CONFIG_IMPA7) || defined(CONFIG_EP7312) || defined(CONFIG_NETARM)
|| defined(CONFIG_ARMADILLO) ||
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi, In message aanlktilprgpuwl630lzsmzkt5bbxfiq6zdpiir3pq...@mail.gmail.com you wrote: I've added this to your patch, but have *NOT* execution tested it. Does this addition (a) make sense and (b) work? I was expecting the caller of fdt_increase_size() to know that the space after the fdt is available. So where is the code that makes sure that there is sufficient space available? 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 At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 1.1.2 boot latest powerpc based kernel?
Shawn Jin wrote: However my concern is specific to the powerpc arch. If I understand correctly, the powerpc arch expects a bootloader provide a DTS file. I'm not sure how the current U-Boot transfers such info to the kernerl. One of the registers (r7 maybe?) contains the address of the device tree. People here can shed some light on this? I'm certain the old U-Boot (e.g. 1.1.2) doesn't have this kind of capability. That's why cuImage was invented. cuImage embeds the device tree in the kernel image. The drawback is that you can't rely on U-Boot to do any fixups. The bd_info is still one of data transferred to the kernel, right? How does bd_info work with the DTS info? That, I don't know. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] hardware flash protect kept during a reboot?
Stefan Roese wrote: This protection is chip specific. IIRC, then some Intel (Strata) chips either protect all sectors or have a sectore-wise protection mechanism. You need to check your FLASH documentation for the exact behaviour. Which chip are you using? I just want to know whether hardware protection works at all for anyone through a reboot. Is the CFI protect sector command persistent through a hardware power reset or power loss? Please note that we have the special unlock env variable. By setting it to yes, all sectors will be unlocked upon startup. At least on Intel Strata FLASH chips. I put a printf() in flash_real_protect(), so I know that's not the problem. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Wolfgang Denk wrote: I was expecting the caller of fdt_increase_size() to know that the space after the fdt is available. So where is the code that makes sure that there is sufficient space available? Well, if I load the fdt to address c, and it's 10KB in size, I'm pretty sure I can expand it to 16KB if I know that there's nothing else between c and c4000. If you're asking about what code do I have that actually calls fdt_increase_size(), that code is currently used for a new board that we're not yet ready to publish. I'd like my patch for fdt_increase_size() included in the next merge window, so that when rebase our internal repository on the next release, this patch will already be available. It makes our internal development easier. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 1.1.2 boot latest powerpc based kernel?
However my concern is specific to the powerpc arch. If I understand correctly, the powerpc arch expects a bootloader provide a DTS file. Not if you use a cuImage as Timur suggested. Wolfgan Timur, thanks for the comments. -Shawn. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][mpc83xx] Removal of checkboard from spl bootstrap build for SIMPC8313
On Fri, 14 May 2010 13:26:44 -0500 Kim Phillips kim.phill...@freescale.com wrote: From 4cb5f50929688d90b68366116713ec735ec51a5f Mon Sep 17 00:00:00 2001 From: Kim Phillips kim.phill...@freescale.com Date: Fri, 14 May 2010 13:18:54 -0500 Subject: [PATCH] mpc83xx: fix NAND bootstrap too big error commit 167cdad1372917bc11c636c359aad02625291fa9 SERIAL: Enable port-mapped access inadvertently broke 83xx nand boards by converting NS16550_init to use io accessors, which expanded the size of the generated code. this patch fixes the problem by removing icache functions from the nand builds, which somewhat follows the icache implementation commit 1a2e203b31d33fb720f2cf1033b241ad36ab405a mpc83xx: turn on icache in core initialization to improve u-boot boot time took. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][mpc83xx] Removal of checkboard from spl bootstrap build for SIMPC8313
On Mon, 10 May 2010 15:23:20 -0700 Ron Madrid ron_mad...@sbcglobal.net wrote: This patch removes the checkboard function from the build of the 4k bootstrap section for the SIMPC8313 as it is not needed in the spl build. This will allow 100 bytes of extra room for other uses. Signed-off-by: Ron Madrid ron_mad...@sbcglobal.net --- applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][mpc83xx] Fix SICRL setting in SIMPC8313
On Fri, 14 May 2010 16:27:48 -0700 Ron Madrid ron_mad...@sbcglobal.net wrote: This patch sets the SICRL_LBC bits in SICRL to change the function of the associated pins to GPIO functionality. Signed-off-by: Ron Madrid ron_mad...@sbcglobal.net --- applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull mpc83xx fixes for nand bootstrap errors
Wolfgang Denk, Please pull a couple of 83xx fixes, most notably for the nand bootstrap too big errors: The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0: Makefile: fix out-of-tree building of u-boot.img target (2010-05-16 02:18:38 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Kim Phillips (1): mpc83xx: fix NAND bootstrap too big error Ron Madrid (2): Removal of checkboard from spl bootstrap build for SIMPC8313 Fix SICRL setting in SIMPC8313 arch/powerpc/cpu/mpc83xx/start.S|2 ++ board/sheldon/simpc8313/simpc8313.c |2 +- include/configs/SIMPC8313.h |3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi, In message 4bf14fbf.3040...@freescale.com you wrote: So where is the code that makes sure that there is sufficient space available? Well, if I load the fdt to address c, and it's 10KB in size, I'm pretty sure I can expand it to 16KB if I know that there's nothing else between c and c4000. Assume the case that the DTB is stored in NOR flash, and I pass the NOR flash address to the bootm command... I'm not sure if there is any guarantee for free room behind the DTB in this case. 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 ... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/ If you can follow that, you can use it. - Randal L. Schwartz in ukpw67rhl3@julie.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 1.1.2 boot latest powerpc based kernel?
On Mon, May 17, 2010 at 09:06:49AM -0500, Timur Tabi wrote: Shawn Jin wrote: However my concern is specific to the powerpc arch. If I understand correctly, the powerpc arch expects a bootloader provide a DTS file. I'm not sure how the current U-Boot transfers such info to the kernerl. One of the registers (r7 maybe?) contains the address of the device tree. r3 People here can shed some light on this? I'm certain the old U-Boot (e.g. 1.1.2) doesn't have this kind of capability. That's why cuImage was invented. cuImage embeds the device tree in the kernel image. The drawback is that you can't rely on U-Boot to do any fixups. U-Boot itself can't do any fixups (because it doesn't know about the device tree), but the cuImage bootwrapper does do some fixups (mainly memory size, clock speed, and MAC address) based on the bd_info that U-Boot passes in. The drawback is that the bd_info is fragile and the information it passes is limited. The bd_info is still one of data transferred to the kernel, right? Not in the new booting scheme. cuImage will accept a bd_info instead of a device tree (and will have a device tree built into the kernel). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message pine.lnx.4.64.1005120458230.12...@localhost.localdomain you wrote: The following changes since commit ab92d0fd9abd0d4726878a80c6baf3a0f94770b8: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Jerry Huang (1): fsl-diu: Using I/O accessor to CCSR space Kumar Gala (3): 85xx: Add is_serdes_configured() support to MPC8536 SERDES 85xx/mpc8536ds: Use is_serdes_configured() to determine of PCIe enabled 85xx/fsl-sata: Use is_serdes_configured() to determine if SATA is enabled York Sun (1): Enabled support for Rev 1.3 SPD for DDR2 DIMMs arch/powerpc/cpu/mpc85xx/cpu_init.c | 14 - arch/powerpc/cpu/mpc85xx/mpc8536_serdes.c | 79 +-- arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |4 +- arch/powerpc/cpu/mpc8xxx/pci_cfg.c | 12 arch/powerpc/include/asm/fsl_serdes.h | 53 board/freescale/common/fsl_diu_fb.c | 55 board/freescale/mpc8536ds/law.c |8 -- board/freescale/mpc8536ds/mpc8536ds.c | 44 common/ddr_spd.c|6 ++- drivers/block/fsl_sata.c| 14 - 10 files changed, 204 insertions(+), 85 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't understand it. I can't even understand the people who can understand it.- Queen Juliana of the Netherlands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx/master
Dear Stefan Roese, In message 201005171102.54560...@denx.de you wrote: The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0: Makefile: fix out-of-tree building of u-boot.img target (2010-05-16 02:18:38 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Matthias Fuchs (1): ppc4xx: Fix building PLU405 board board/esd/plu405/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A complex system that works is invariably found to have evolved from a simple system that worked. - John Gall, _Systemantics_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] please pull mpc83xx fixes for nand bootstrap errors
Dear Kim Phillips, In message 20100517145135.0c71f44a.kim.phill...@freescale.com you wrote: Wolfgang Denk, Please pull a couple of 83xx fixes, most notably for the nand bootstrap too big errors: The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0: Makefile: fix out-of-tree building of u-boot.img target (2010-05-16 02:18:38 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Kim Phillips (1): mpc83xx: fix NAND bootstrap too big error Ron Madrid (2): Removal of checkboard from spl bootstrap build for SIMPC8313 Fix SICRL setting in SIMPC8313 arch/powerpc/cpu/mpc83xx/start.S|2 ++ board/sheldon/simpc8313/simpc8313.c |2 +- include/configs/SIMPC8313.h |3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unser Kopf ist rund, damit das Denken die Richtung wechseln kann. -- Francis Picabia ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] remove useless free(ptr) calls on NULL ptr
Dear Serge Ziryukin, In message 1273502449-26115-1-git-send-email-ftrvxm...@gmail.com you wrote: Signed-off-by: Serge Ziryukin ftrvxm...@gmail.com --- drivers/net/lan91c96.c |1 - drivers/net/smc911x.c |1 - 2 files changed, 0 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If that makes any sense to you, you have a big problem. -- C. Durance, Computer Science 234 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] fsl-diu: Using I/O accessor to CCSR space
Dear Dave Liu, In message 1270713367-542-1-git-send-email-dave...@freescale.com you wrote: From: Jerry Huang chang-ming.hu...@freescale.com Using PPC I/O accessor to DIU I/O space instead of directly read/write. It will prevent the dozen of compiler order issue and PPC hardware order issue for accessing I/O space. Using the toolchain(tc-fsl-x86lnx-e500-dp-4.3.74-2.i386.rpm) can show up the order issue of DIU driver. Signed-off-by: Dave Liu dave...@freescale.com Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com --- * address Timur's comments board/freescale/common/fsl_diu_fb.c | 55 ++- 1 files changed, 28 insertions(+), 27 deletions(-) It seems this commit is causing a lot of build warnings: ... Configuring for aria board... ../../../../board/freescale/common/fsl_diu_fb.c: In function 'fsl_diu_init': ../../../../board/freescale/common/fsl_diu_fb.c:271: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c:272: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c:273: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c:335: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c:336: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c: In function 'fsl_diu_enable_panel': ../../../../board/freescale/common/fsl_diu_fb.c:395: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ../../../../board/freescale/common/fsl_diu_fb.c: In function 'fsl_diu_disable_panel': ../../../../board/freescale/common/fsl_diu_fb.c:406: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast ... Configuring for mpc5121ads board... fsl_diu_fb.c: In function 'fsl_diu_init': fsl_diu_fb.c:271: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c:272: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c:273: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c:335: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c:336: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c: In function 'fsl_diu_enable_panel': fsl_diu_fb.c:395: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast fsl_diu_fb.c: In function 'fsl_diu_disable_panel': fsl_diu_fb.c:406: warning: passing argument 2 of 'out_be32' makes integer from pointer without a cast etc. Patch following, but could you please run MAKEALL on your submissions? 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 Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl_diu_fb.c: fix build warnings
Commit 15351855 fsl-diu: Using I/O accessor to CCSR space caused a number of passing argument 2 of 'out_be32' makes integer from pointer without a cast warnings; fix these. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Dave Liu dave...@freescale.com Cc: Jerry Huang chang-ming.hu...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- board/freescale/common/fsl_diu_fb.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/board/freescale/common/fsl_diu_fb.c b/board/freescale/common/fsl_diu_fb.c index e7f077e..e740ad8 100644 --- a/board/freescale/common/fsl_diu_fb.c +++ b/board/freescale/common/fsl_diu_fb.c @@ -268,9 +268,9 @@ int fsl_diu_init(int xres, memset(info-screen_base, 0, info-smem_len); - out_be32(dr.diu_reg-desc[0], dummy_ad); - out_be32(dr.diu_reg-desc[1], dummy_ad); - out_be32(dr.diu_reg-desc[2], dummy_ad); + out_be32(dr.diu_reg-desc[0], (int)dummy_ad); + out_be32(dr.diu_reg-desc[1], (int)dummy_ad); + out_be32(dr.diu_reg-desc[2], (int)dummy_ad); debug(dummy dr.diu_reg-desc[0] = 0x%x\n, dr.diu_reg-desc[0]); debug(dummy desc[0] = 0x%x\n, hw-desc[0]); @@ -332,8 +332,8 @@ int fsl_diu_init(int xres, /* Program DIU registers */ - out_be32(hw-gamma, gamma.paddr); - out_be32(hw-cursor, cursor.paddr); + out_be32(hw-gamma, (int)gamma.paddr); + out_be32(hw-cursor, (int)cursor.paddr); out_be32(hw-bgnd, 0x007F7F7F); out_be32(hw-bgnd_wb, 0); /* BGND_WB */ out_be32(hw-disp_size, var-yres 16 | var-xres); /* DISP SIZE */ @@ -391,8 +391,8 @@ static int fsl_diu_enable_panel(struct fb_info *info) struct diu_ad *ad = fsl_diu_fb_ad; debug(Entered: enable_panel\n); - if (in_be32(hw-desc[0]) != (u32)ad) - out_be32(hw-desc[0], ad); + if (in_be32(hw-desc[0]) != (unsigned)ad) + out_be32(hw-desc[0], (unsigned)ad); debug(desc[0] = 0x%x\n, hw-desc[0]); return 0; } @@ -402,8 +402,8 @@ static int fsl_diu_disable_panel(struct fb_info *info) struct diu *hw = dr.diu_reg; debug(Entered: disable_panel\n); - if (in_be32(hw-desc[0]) != (u32)dummy_ad) - out_be32(hw-desc[0], dummy_ad); + if (in_be32(hw-desc[0]) != (unsigned)dummy_ad) + out_be32(hw-desc[0], (unsigned)dummy_ad); return 0; } -- 1.6.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] QUICK LOAN OFFER HERE NOW!!!!!APPLY IF INTERESTED.
Dear Sir/Madam, This Is a Finance Lending Organization, we give out loans to all in need of it. Are you looking for funds to pay bills? Do you want to start Or Expand your Business? Do you simply need money for your Personal Needs?Then take Up a Loan here with a very affordable interest rate. We give out home loans in the following categories: Auto Loans, Mortgage loans,Business Loans, Personal Loans.For more information, Contact our representative via: lucypaulloaninvestmentcomp...@gmail.com and fill up the loan application form below it if interested to get a loan here in this great company. BORROWERS DATA FORM 1)FULL NAME.. 2)COUNTRY. 3)YOUR OCCUPATION. 4)YOUR MARITAL STATUS 5)PHONE NUMBER 6)MONTHLY INCOME... 7)ADDRESS... 8)PURPOSE... 9)LOAN REQUEST.. 10)TELEPHONE. 11)LOAN DURATION.. Your loan will be transfered to you,depending on your early response and Interest. Thanks for your co-operation. Mrs Doris lucypaulloaninvestmentcomp...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Does anyone know how to use FIT uImage
Hi, experts,
I've encountered an error in making FIT uImage.
I created an fsl_kernel.its file and run mkimage -f fsl_kernel.its
kernel.itb, the following error happened.
r65...@szx32-17:~/uboot-v2009.08/uboot-imx$ mkimage -f
fsl_kernel.its kernel.itb
FIT format handling
Trying to execute dtc -I dts -O dtb -p 500 fsl_kernel.its
kernel.itb.tmp
DTC: dts-dtb on file fsl_kernel.its
Error: fsl_kernel.its:4.1-2 syntax error
FATAL ERROR: Unable to parse input tree
mkimage: Can't read kernel.itb.tmp: Invalid argument
The fsl_kernel.its file is:
r65...@szx32-17:~/uboot-v2009.08/uboot-imx$ cat ./fsl_kernel.its
/*
* Simple U-boot uImage source file containing a single kernel
*/
/ {
description = Simple image with single Linux kernel;
#address-cells = 1;
images {
ker...@1 {
description = Freescale Linux kernel;
data = /incbin/(./vmlinux);
type = kernel;
arch = arm;
os = linux;
compression = none;
load = 70008000;
entry = 70008000;
};
};
configurations {
default = con...@1;
con...@1 {
description = Boot Linux kernel;
kernel = ker...@1;
};
};
};
Does anyone know what the problem is?
Thanks in advance.
Yours
Terry
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mv78100 board whether can support from the usb start?
I try to start from the usb directly, but mv78100 didn't provide corresponding driving, I found a marvell high version of the usb driver, put it to boot1.1.4, but couldn't find a usb storage, I don't know how to do it, who will give me some advice? Thank you, here is some information to start: Marvell (Re)start USB... USB: scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x8 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=256, index=0 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 EHCI_DEBUG: ehci_submit_root: req=5 (0x5), type=0 (0x0), value=1, index=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=256, index=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=512, index=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=512, index=0 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 EHCI_DEBUG: ehci_submit_root: req=9 (0x9), type=0 (0x0), value=1, index=0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=768, index=0 USB device number 1 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=769, index=1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=128 (0x80), value=770, index=1 Manufacturer Marvell Product EHCI SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=160 (0xa0), value=10496, index=0 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 EHCI_DEBUG: ehci_submit_root: req=6 (0x6), type=160 (0xa0), value=10496, index=0 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 EHCI_DEBUG: ehci_submit_root: req=0 (0x0), type=160 (0xa0), value=0, index=0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 EHCI_DEBUG: ehci_submit_root: req=3 (0x3), type=35 (0x23), value=8, index=1 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 EHCI_DEBUG: ehci_submit_root: req=0 (0x0), type=163 (0xa3), value=0, index=1 1 USB Device(s) found scanning bus for storage devices... i=0 netpower: usb probe fail, bDeviceClass:9, bInterfaceClass:9, bInterfaceSubClass:0, bInterfaceSubClass:0 i=1 //this is my print message 0 Storage Device(s) found Marvell usb info 1: Hub, USB Revision 2.0 - Marvell EHCI - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x Product 0x Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms why bInterfaceClass=9? http://old.nabble.com/file/p28591067/usb_ehci.c usb_ehci.c http://old.nabble.com/file/p28591067/usb_ehci.h usb_ehci.h -- View this message in context: http://old.nabble.com/mv78100-board-whether-can-support-from-the-usb-start--tp28591067p28591067.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does anyone know how to use FIT uImage
Hi Terry, On Tue, 2010-05-18 at 10:59 +0800, Lv Terry-R65388 wrote: Hi, experts, I've encountered an error in making FIT uImage. snip Does anyone know what the problem is? Your .its input file looks OK to me. What version of mkimage are you using? And what version of the dtc is in your path? I'd recommend giving the same steps a try using the tools/mkimage in the latest U-Boot tree as well as the dtc in the latest Linux kernel tree at scripts/dtc/dtc. Best, Peter PS. Just tried it and it looks like it works with the latest mkimage and dtc versions: pty...@petert u-boot $ ./tools/mkimage -f fsl_kernel.its kernel.itb DTC: dts-dtb on file fsl_kernel.its FIT description: Simple image with single Linux kernel Created: Mon May 17 22:12:36 2010 Image 0 (ker...@1) Description: Freescale Linux kernel Type: Kernel Image Compression: uncompressed Data Size:149051 Bytes = 145.56 kB = 0.14 MB Architecture: ARM OS: Linux Load Address: 0x70008000 Entry Point: 0x70008000 Default Configuration: 'con...@1' Configuration 0 (con...@1) Description: Boot Linux kernel Kernel: ker...@1 pty...@petert u-boot $ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Congratulation ***Your E-mail ID Have Won***
Your email address has won,£1,000,000.00 Pounds,in the on going UK promo.send your details: Names... Tele... Age... Address... occupation... country... Mr. Roy Phil Tel:+44 704-571-0545 email:bnlclaimsd...@live.co.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Greetings From Mr. Tomo Sand Nori...
Hello I'm Mr. Tomo Sand Nori Head of Account Dept, Tokyo Mitsubishi Bank,Japan.I have a bussiness proposal for you. If intrested Contact me via my secured email: tomosandno...@w.cn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] flash: Check info pointer in flash_protect().
Some calls to flash_protect() do not check that info is not
NULL. This change prevents this from causing random memory to
be stomped on.
---
common/flash.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/common/flash.c b/common/flash.c
index eb4b2f5..dc376ee 100644
--- a/common/flash.c
+++ b/common/flash.c
@@ -43,15 +43,19 @@ extern flash_info_t flash_info[]; /* info for FLASH chips
*/
void
flash_protect (int flag, ulong from, ulong to, flash_info_t *info)
{
- ulong b_end = info-start[0] + info-size - 1; /* bank end address */
- short s_end = info-sector_count - 1; /* index of last sector */
+ ulong b_end;/* bank end address */
+ short s_end;/* index of last sector */
int i;
/* Do nothing if input data is bad. */
- if (info-sector_count == 0 || info-size == 0 || to from) {
+ if (!info || info-sector_count == 0 || info-size == 0 ||
+ to from) {
return;
}
+ b_end = info-start[0] + info-size - 1;
+ s_end = info-sector_count - 1;
+
debug (flash_protect %s: from 0x%08lX to 0x%08lX\n,
(flag FLAG_PROTECT_SET) ? ON :
(flag FLAG_PROTECT_CLEAR) ? OFF : ???,
--
1.6.3
NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesis Labs.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors
Our hardware has part of the flash mapped in two address ranges. The CONFIG_SYS_MONITOR_BASE is in the upper 'boot' area, whereas the CONFIG_SYS_FLASH_BANKS_LIST has the full flash available at a lower address. This all works fine until the code in cfi_flash.c:flash_init(), which uses flash_get_info() to find the flash_info_t associated with the monitor and environment. These are not in the probed flash range, so flash_get_info() returns NULL. This is not checked and is passed directly to flash_protect(). Since flash_protect() was not checking for this NULL pointer either, random memory would be clobbered causing the device to lock up. This patch changes flash_protect() to check for the NULL, and the error goes unreported. Mark Tomlinson (1): flash: Check info pointer in flash_protect(). common/flash.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesis Labs Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesis Labs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support for MB86R01 cpu
Hi Matthias, We are using MB86R01 processor in our design. We just want to know what emulator/debugger can be used for initial board bring-up activity and also whether the latest u-boot(2010.03) is supporting this processor ? -Thirumalai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for MB86R01 cpu
Hello Thirumalai Am 18.05.2010 07:37, schrieb Thirumalai: Hi Matthias, We are using MB86R01 processor in our design. We just want to know what emulator/debugger can be used for initial board bring-up activity and also whether the latest u-boot(2010.03) is supporting this processor ? I recently posted a patch series adding support for MB86R01 to u-boot. I did not receive any comments on V2 so I thinks its more or less fine and I hope it will be merged within the upcoming merge window. See http://lists.denx.de/pipermail/u-boot/2010-May/071097.html for the initial mail of the patch series. I am using a BDI2000 (http://www.abatron.ch/products/bdi-family.html) for initial flash programming. A Segger JLink (http://www.segger.com/cms/jlink.html) works also. Hope this helped. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
