[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
omap3_evm ARM CORTEX-A8 (OMAP3xx SoC)
+Remco Poelstra
+
+ LPC2468 LPC2468
+
Stelian Pop
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
#include
#include
+#include
+#include
#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) || defined(CONFIG_LPC2292)
+#ifdefined(CONFIG_IMPA7) || defined(CONFIG_EP7312) ||
defined(CONFIG_NETARM) ||\
+ define
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 --- 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
---
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 > --- > 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,
[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 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 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
Acked-by: Gerald Van Baren
> ---
>
> 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
omap3_evm ARM CORTEX-A8 (OMAP3xx SoC)
+Remco Poelstra
+
+ LPC2468 LPC2468
+
Stelian Pop
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
#include
#include
+#include
+#include
#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) || defined(CONFIG_LPC2292)
+#ifdefined(CONFIG_IMPA7) || defined(CONFIG_EP7312) ||
defined(CONFIG_NETARM) ||\
+ define
Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Dear Timur Tabi, In message 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 wrote: > From 4cb5f50929688d90b68366116713ec735ec51a5f Mon Sep 17 00:00:00 2001 > From: Kim Phillips > 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 > --- 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 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 > --- 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 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 > --- 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 ___ 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
[U-Boot] [PATCH] NAND: Support dynamic location of enviromnent (CONFIG_ENV_OFFSET_OOB)
This is a re-submission of the patch by Harald Welte
with minor modifications for rebase and changes as suggested by Scott Wood
in
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/43916.
This patch was made against master branch of
git://git.denx.de/u-boot-nand-flash.git with the recent patch from Wolfgang Denk
to fix the undefined __aeabi_unwind_cpp_pr0() problem:
http://download.gmane.org/gmane.comp.boot-loaders.u-boot/78612/78613
Testing was performed with the patch applied to the master branch of
git://arago-project.org/git/people/sekhar/u-boot-omapl1.git , which is forked
from
uboot's v2009.11 a200a7c04d89853d2a1395b96d8ca5e3dd754551 tag -- this is
because
the board I am actually using -- the da850 / OMAP L138 -- does not have config.
This patch enables the environment parttion to have a run-time dynamic location
(offset) in the NAND flash. The reason for this is simply that all NAND
flashes have factory-default bad blocks, and a fixed compile time offset would
mean that sometimes the environment partition would live inside factory bad
blocks. Since the number of factory default blocks can be quite high (easily
1.3MBytes in current standard components), it is not economic to keep that many
spare blocks inside the environment partition.
With this patch and CONFIG_ENV_OFFSET_OOB enabled, the location of the
environment
partition is stored in the out-of-band (OOB) data of the first block in flash.
Since the first block is where most systems boot from, the vendors guarantee
that the first block is not a factory default block.
This patch introduces the 'dynenv' command, which can be called from the u-boot
command line. 'dynenv get' reads the address of the environment partition from
the OOB data, 'dynenv set {offset,partition-name}' allows the setting of the
marker by specifying a numeric offset or a partition name.
Signed-off-by: Ben Gardiner
---
common/Makefile |1 +
common/cmd_dynenv.c | 112 +
common/cmd_nand.c | 10 ++--
common/cmd_nand.h | 33 ++
common/env_nand.c | 52 +++
include/environment.h | 21 +++---
include/nand.h|6 +++
7 files changed, 224 insertions(+), 11 deletions(-)
create mode 100644 common/cmd_dynenv.c
create mode 100644 common/cmd_nand.h
diff --git a/common/Makefile b/common/Makefile
index dbf7a05..83520d7 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -85,6 +85,7 @@ COBJS-$(CONFIG_CMD_DIAG) += cmd_diag.o
endif
COBJS-$(CONFIG_CMD_DISPLAY) += cmd_display.o
COBJS-$(CONFIG_CMD_DTT) += cmd_dtt.o
+COBJS-$(CONFIG_ENV_OFFSET_OOB) += cmd_dynenv.o
COBJS-$(CONFIG_CMD_ECHO) += cmd_echo.o
COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += cmd_eeprom.o
COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o
diff --git a/common/cmd_dynenv.c b/common/cmd_dynenv.c
new file mode 100644
index 000..5167875
--- /dev/null
+++ b/common/cmd_dynenv.c
@@ -0,0 +1,112 @@
+/*
+ * (C) Copyright 2006-2007 OpenMoko, Inc.
+ * Author: Harald Welte
+ * (C) Copyright 2008 Harald Welte
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "cmd_nand.h"
+#include
+
+unsigned long env_offset;
+
+int do_dynenv(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ int ret;
+ uint32_t *oob_buf;
+
+ char *cmd = argv[1];
+
+ if (!strcmp(cmd, "get")) {
+ ret = get_dynenv(&CONFIG_ENV_OFFSET);
+ if(!ret) {
+ printf("0x%08lx\n", CONFIG_ENV_OFFSET);
+ }
+ else {
+ return 1;
+ }
+ }
+ else if (!strcmp(cmd, "set")) {
+ ulong addr, dummy_size;
+ struct mtd_info *mtd = &nand_info[0];
+ struct mtd_oob_ops ops;
+
+ if (argc < 3)
+ goto usage;
+
+ if (nand_arg_off_size(argc-2, argv + 2, mtd, &addr,
&dummy_size, 1) < 0) {
+ printf("Offset or partition name expected\n");
+ return 1;
+ }
+
+ if(mtd->oobavail < CONFIG_ENV_OFFSET_SIZE){
+ printf("Insufficient available OOB bytes: %d OOB bytes
available but %d required for dy
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message 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 > --- > 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 > > 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 > Signed-off-by: Jerry Huang > --- > * 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
Cc: Dave Liu
Cc: Jerry Huang
Cc: Kumar Gala
---
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. > 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
Re: [U-Boot] U-Boot "public API" example desired
This is a reposted and slightly reformatted version of a previous post, please see http://lists.denx.de/pipermail/u-boot/2010-May/071243.html. I did not receive a response to my previous post, so I am trying again. >Dear jimc at sdateam.com, > >In message <8139.1273161587 at sdateam.com> you wrote: >> >> Is there an example available of the use of the U-Boot "public API" >> or of a "stand-alone application", that can be, or is, sanctioned by >> someone who would definitely know (for example, Wolfgang Denk) as >> being not a derived work? > >The code in the examples/standalone/ is supposed to provide example >code, and doc/README.standalone is supposed to provide documentation. I appreciate the answer, I think this topic has been discussed several times, so thanks for spending time re-visiting it once again. I have looked at both the examples/standalone code and the README.standalone. >> I've seen several discussions in various mailing lists about these >> interfaces but I have not seen a definite example that qualifies. It > >What are these "various mailing lists", and what exactluy is not clear >to you? I have also seen 1) http://old.nabble.com/-U-Boot--How-to-get-GPL-free-standalone-programs-with-u-boot-td27182861.html 2) http://lists.denx.de/pipermail/u-boot/2009-August/058650.html 3) http://osdir.com/ml/boot-loaders.u-boot/2003-11/msg00072.html 4) http://osdir.com/ml/freebsd.embedded/2008-01/msg00019.html 5) http://old.nabble.com/Re%3A--U-Boot--How-to-get-GPL-free-standalone-programs-with-u-boot-p27338654.html Some of these are forums, rather that mailing lists, I apologize for not being specific in my previous message. >Best regards, > >Wolfgang Denk The part that is not clear to me is if a conclusion has ever been reached as to the availability of a set of GPL-free headers that can be included in a stand-alone application. I think the GPL is quite valuable, but there are situations involving closed-source software where GPL licensed source files must be avoided (I'm sure this is news to nobody). Has such a set of GPL-free headers been developed, or must I develop them myself if I want to use them? In 5) above, you write >In message you wrote: >> >> I have a question concerning standalone programs based on u-boot and >> GPL, since I'm not really sure whether the way how the u-boot source >> files are set up allows GPL free standalone programs. > >This is the intention; if the current code or documentation should >conflict with this intention, it should be fixed. and >"exports.h" should be added to the "allowed" file list; there should >be no need to include "common.h". Eventually this needs fixing. >Patches are welcome. In the latest U-Boot sources, this issue seems to still exist; headers available for inclusion in stand-alone application seem to include the GPL license language. I can't find equivalent headers that are "GPL-free", but maybe I am looking in the wrong place. This last comment includes mention of the "allowed" file list; I can't locate anything of this nature either. Again, thank you for your time and best regards, Jim -- James E. Chargin Jr. Sierra Design Associates(530) 478-6689 117 New Mohawk Rd, Suite H jimc at sdateam.com [13] Nevada City, CA 95959 USA http:\www.sdateam.com [14] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for MB86R01 cpu
Hi Matthias, I am going to use u-boot alone for my development. Which debugger is suitable for debugging u-boot and initial board bringup activity? My choice is BDI2000. Is it ok. Also tell me what toolchains need to be used. Is ELDK supports? Whether the video driver is available on u-boot ? -Thirumalai - Original Message - From: "Matthias Weißer" To: "Thirumalai" Cc: Sent: Tuesday, May 18, 2010 11:18 AM Subject: 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
