March 2006 - U-Boot

Re: [DNX#2006040142000848] [U-Boot-Users] [PATCH] cleanup duplicated ARM inte [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000848] was created: <snip> > CHANGELOG: > Cleaned up duplicated code: moved common ARM interrupt handling code > from cpu specific interrupts.c files into lib_arm/interrupts.c. > Patch by Andreas Engel, 21 Nov 2005 > > Signed-off-by: Andreas Engel > > Note: there were two cases (cpu/arm720t/ and cpu/sa1100/) where the > disable_interrupts function only disabled IRQ, but not FIQ. I just > ignored this in the generic function in lib_arm/, which disables both > IRQ and FIQ. Perhaps someone with more knowledge of ARM cores can check > whether or not this is ok. > > Regards, > Andreas Engel </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000839] [U-Boot-Users] Patch: Fixes for XES Xpedite1000 B [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000839] was created: <snip> > This patch fixes the flash support for the XES Xpedite1000 PrPMC board. > > Previously only the socketed AMD 1/2MB flash was supported. This patch > adds the intel strata flash and moves the environment from i2c eeprom to > > the first sector of the intel strata flash. > > This patch also addresses the hardware write protect for the socketed > flash introduced on newer xpedite1k boards. > > > CHANGELOG: > * Update XPedite1000 board support to fix flash access and move > the environment from i2c eeprom to flash. > Patch by Travis B. Sawyer, 16 Feb 2006 > > > Regards, > > Travis Sawyer </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000821] [U-Boot-Users] [PATCH] add support for DS1339 RTC
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000821] was created: <snip> > Hi, > > The attached patch add support for DS1339, which directly uses > rtc/ds1337.c. > > CHANGELOG: > * Add support for DS1339 RTC which uses rtc/ds1337.c > > > -- > lark </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000795] [U-Boot-Users] [PATCH] fix undefined error on omap [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000795] was created: <snip> > Hi, > > This patch fixes following error: > > arm-sony-linux-gcc -Wa,-gstabs -D__ASSEMBLY__ -g -Os > -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float > -malignment-traps -D__KERNEL__ -DTEXT_BASE=0x11080000 > -Iu-boot-1.1.4/include -fno-builtin -ffreestanding -nostdinc -isystem > /usr/local/arm-sony-linux/devel/lib/gcc/arm-sony-linux/3.4.4/include > -pipe -DCONFIG_ARM -D__ARM__ -march=armv4 -mapcs-32 -c -o > cpu/arm926ejs/start.o u-boot-1.1.4/cpu/arm926ejs/start.S > u-boot-1.1.4/cpu/arm926ejs/start.S: Assembler messages: > u-boot-1.1.4/cpu/arm926ejs/start.S:169: Error: undefined symbol > CFG_GBL_DATA_SIZE used as an immediate value > u-boot-1.1.4/cpu/arm926ejs/start.S:335: Error: undefined symbol > CFG_GBL_DATA_SIZE used as an immediate value > u-boot-1.1.4/cpu/arm926ejs/start.S:336: Error: undefined symbol > CFG_GBL_DATA_SIZE used as an immediate value > ... > u-boot-1.1.4/cpu/arm926ejs/start.S:391: Error: undefined symbol > CFG_GBL_DATA_SIZE used as an immediate value > make: *** [cpu/arm926ejs/start.o] Error 1 > > > Best Regards, > > HK. > -- </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000811] [U-Boot-Users] Re: [U-Boot-Users][Patch] Cleanup o [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000811] was created: <snip> > Wolfgang Denk ha scritto: > >>Are there any particular reasons why this code should stay in start.S ? > > > > > > Never change a running system without need? > > > Yeah, though not technical is an important one indeed ;-) > But since a SoC structure has been created I thought it was nice to have > all the independent > files cleaned. Just give it a try! Anyway I'll fully understand if you > prefer not to touch > a running system. > > Best regards > -P.Broggini > > > > Signed-off-by: Paolo Broggini <pbroggini(a)softool.ch> > > > CHANGELOG: > Cleanup of cpu/arm920t/start.S, S3C24x0 specific code > moved into boards depended lowlevel_init.s > Affected boards: sdmk2400, sdmk2410, vcma9, trab > Patch by Paolo Broggini, 13 Oct 2005 > > > diff --git a/board/mpl/vcma9/lowlevel_init.S > b/board/mpl/vcma9/lowlevel_init.S > --- a/board/mpl/vcma9/lowlevel_init.S > +++ b/board/mpl/vcma9/lowlevel_init.S > @@ -34,6 +34,10 @@ > > /* some parameters for the board */ > > +#define pWTCON 0x53000000 > +#define INTMSK 0x4A000008 /* Interupt-Controller base addresses */ > +#define INTSUBMSK 0x4A00001C > +#define CLKDIVN 0x4C000014 /* clock divisor register */ > #define BWSCON 0x48000000 > #define PLD_BASE 0x2C000000 > #define SDRAM_REG 0x2C000106 > @@ -132,6 +136,30 @@ _TEXT_BASE: > > .globl lowlevel_init > lowlevel_init: > + > + /* > + * Watchdog disable > + */ > + ldr r0, =pWTCON > + mov r1, #0x0 > + str r1, [r0] > + > + /* > + * mask all IRQs by setting all bits in the INTMR - default > + */ > + mov r1, #0xffffffff > + ldr r0, =INTMSK > + str r1, [r0] > + ldr r1, =0x3ff > + ldr r0, =INTSUBMSK > + str r1, [r0] > + > + /* FCLK:HCLK:PCLK = 1:2:4 */ > + /* default FCLK is 120 MHz ! */ > + ldr r0, =CLKDIVN > + mov r1, #3 > + str r1, [r0] > + > /* memory control configuration */ > /* make r0 relative the current location so that it */ > /* reads SMRDATA out of FLASH rather than memory ! */ > diff --git a/board/smdk2400/lowlevel_init.S > b/board/smdk2400/lowlevel_init.S > --- a/board/smdk2400/lowlevel_init.S > +++ b/board/smdk2400/lowlevel_init.S > @@ -44,9 +44,13 @@ > * > */ > > +#define pWTCON 0x15300000 > +#define INTMSK 0x14400008 /* Interupt-Controller base addresses */ > +#define CLKDIVN 0x14800014 /* clock divisor register */ > + > /* memory controller */ > -#define BWSCON 0x14000000 > -#define BANKCON3 0x14000010 /* for cs8900, ethernet */ > +#define BWSCON 0x14000000 > +#define BANKCON3 0x14000010 /* for cs8900, ethernet */ > > /* Bank0 */ > #define B0_Tacs 0x0 /* 0 clk */ > @@ -127,6 +131,27 @@ _TEXT_BASE: > > .globl lowlevel_init > lowlevel_init: > + > + /* </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000802] [U-Boot-Users] Re: MIPS LE build problems
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000802] was created: <snip> > Hi > > > I have attached the patch. > > Thanks. > Few comments, though. > I use my own toolchain, built with the crosstool and a few patches. > binutils: 2.15 > gcc: 3.3.5 > glibc: 2.3.5 > > > ######################################################################### > > ## MIPS64 5Kc > > diff --git a/cpu/mips/config.mk b/cpu/mips/config.mk > > --- a/cpu/mips/config.mk > > +++ b/cpu/mips/config.mk > > @@ -24,9 +24,17 @@ v=$(shell \ > > mips-linux-as --version|grep "GNU assembler"|awk '{print $$3}'|awk -F . '{print $$2}') > > Should this be, like: > $(CROSS_COMPILE)as --version|grep "GNU assembler"|awk '{print $$3}'|awk > -F . '{print $$2}') > > Because my compiler is: mipsel-linux-gcc > > > > MIPSFLAGS=$(shell \ > > if [ "$v" -lt "14" ]; then \ > > - echo "-mcpu=4kc -EB -mabicalls"; \ > > + echo "-mcpu=4kc"; \ > > else \ > > - echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined -EB -mabicalls"; \ > > + echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined"; \ > > fi) > > The -mips_allow_branch_to_undefined does not work for me :-) > I used this patch: > http://sources.redhat.com/ml/binutils/2004-04/msg00476.html > And I have to use -allow_branch_to_undefined. > Anybody knows why? > > BR, > Matej > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000786] [U-Boot-Users] [PATCH] Add RealView Emulation Base [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000786] was created: <snip> > > The attached gzipped patch was made against the U-Boot GIT head of Oct > 31 2005. > > It is my patch number 013. > The patch is independent of patches 009 & 010, but dependent on patch > 011 & 012 > > The patch adds support for the new RealView Emulation BaseBoard series > of boards. > > CHANGELOG: > Add RealView Emulation BaseBoard. > Patch by Peter Pearse, 31st Oct 2005 </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000768] [U-Boot-Users] [PATCH 3/7] Flat device tree suppor [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000768] was created: <snip> > * Fixed a bug where RAM size was not properly passed to Linux on > 85xx in the flat device tree > Patch by John Traill 17-Mar-2006 > > Signed-off-by: Andy Fleming <afleming(a)freescale.com> > > --- > > diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c > index 62a3de0..3261592 100644 > --- a/cpu/mpc85xx/cpu.c > +++ b/cpu/mpc85xx/cpu.c > @@ -253,6 +253,12 @@ ft_cpu_setup(void *blob, bd_t *bd) > if (p != NULL) > *p = cpu_to_be32(clock); > > + p = ft_get_prop(blob, "/memory/reg", &len); > + if (p != NULL) { > + *p++ = cpu_to_be32(bd->bi_memstart); > + *p = cpu_to_be32(bd->bi_memsize); > + } > + > #if defined(CONFIG_MPC85XX_TSEC1) > p = ft_get_prop(blob, "/" OF_SOC "/ethernet@24000/address", &len); > memcpy(p, bd->bi_enetaddr, 6); > -- > 1.2.4 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000777] [U-Boot-Users] Ocotea with 512 megs of ram - ping [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000777] was created: <snip> > Dale, > > You've run into a problem where U-Boot maps the 2nd 256MB of physical > memory into the same logical space as the 1st 256MB. It's a one line/one > character typo that I've been meaning to post a patch for but I've been > tied up on other projects. Here's the context diff: > > --- ./board/amcc/ocotea/init.S 2005-12-19 18:14:46.000000000 -0800 > +++ ../u-boot-git-ocotea-patch/board/amcc/ocotea/init.S 2005-12-22 > 13:38:38.000000000 -0800 > @@ -92,5 +92,5 @@ > tlbentry( CFG_ISRAM_BASE + 0x1000, SZ_4K, 0x80001000, 0, > AC_R|AC_W|AC_X ) > tlbentry( CFG_SDRAM_BASE, SZ_256M, 0x00000000, 0, > AC_R|AC_W|AC_X|SA_G|SA_I ) > - tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x00000000, 0, > AC_R|AC_W|AC_X|SA_G|SA_I ) > + tlbentry( CFG_SDRAM_BASE+0x10000000, SZ_256M, 0x10000000, 0, > AC_R|AC_W|AC_X|SA_G|SA_I ) > tlbentry( CFG_PCI_BASE, SZ_256M, 0x00000000, 2, AC_R|AC_W|SA_G|SA_I > ) > tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, > AC_R|AC_W|SA_G|SA_I ) > > This should fix your problem. > > Marc > > > -----Original Message----- > > From: u-boot-users-admin(a)lists.sourceforge.net > > [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf > > Of Dale Dunlea > > Sent: Tuesday, February 14, 2006 8:32 AM > > To: u-boot-users(a)lists.sourceforge.net > > Subject: [U-Boot-Users] Ocotea with 512 megs of ram - ping fails > > > > Hi, > > > > I have an Ocotea (AMCC 440GX) test board which I have been > > using happily > > with U-Boot 1.1.4. In it's original configuration, it uses a > > single 256 > > meg dimm. This works fine and my kernel and initrd images are > > downloaded > > happily via tftp. I replaced this dimm with a 512 meg dimm > > and now the > > network interface is no longer functional. Has anyone else > > seen this issue? > > > > Regards, > > Dale > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep > > through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. > > DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486& > > dat=121642 > > _______________________________________________ > > U-Boot-Users mailing list > > U-Boot-Users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users </snip> Your U-Boot support team

1 0

Re: [DNX#2006040142000759] [U-Boot-Users] Bug in DTT for temperatures below z [...]
by DENX Support System 01 Apr '06

01 Apr '06

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2006040142000759] was created: <snip> > In message <42AFEBD3.3050008(a)imc-berlin.de> you wrote: > > > > there's a terrible bug in the current U-Boot CVS concerning DDT: > > > > For temperature below zero the function dtt_get_temp() (at least for lm75) > > returns wrong values! > > > > ... > > DTT: 1 is 235 C > > LCD: Hitachi TX14D11 5,7" 320x240 TFT (235°C) > > WDT: disabled > > > > This is because of the use of an "int" although the lm75 only returns two > > byte ("signed short"). > > Ummm... > > > This trivial fix is needed: > > Wait a moment... > > > --- u-boot/dtt/lm75.c 27 Jun 2003 21:32:38 -0000 1.2 > > +++ u-boot/dtt/lm75.c 15 Jun 2005 08:44:21 -0000 > > @@ -174,7 +170,7 @@ > > > > int dtt_get_temp(int sensor) > > { > > - return (dtt_read(sensor, DTT_READ_TEMP) / 256); > > + return ( ((signed short) dtt_read(sensor, DTT_READ_TEMP)) / 256); > > This is not the right way to fix it. I reject this patch. > > dtt_read() is declared to return "int", so no such cast should be > needed, i. e. you fix the symptoms instead of the cause. > > > I think the patch must be done in dtt_read(); IMO the line > > return ((int)((short)data[1] + (((short)data[0]) << 8))); > > is wrong; it should read > > return ((short)((short)data[1] + (((short)data[0]) << 8))); > > or, even better, > > short rc_s; > ... > rc_s = (short)data[1] + (((short)data[0]) << 8); > return (rc_s); > > And the same problem is with dlen == 1 - it should read > > return ((signed char)data[0]); > > > Do you agree with this assessment? And can you please confirm that my > suggested patch fixes your problem, too? > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > Of all possible committee reactions to any given agenda item, the > reaction that will occur is the one which will liberate the greatest > amount of hot air. -- Thomas L. Martin > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users </snip> Your U-Boot support team

1 0