All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Eric D. Mudama @ 2006-03-31 22:21 UTC (permalink / raw)
  To: Kyle Moffett
  Cc: LKML Kernel, Bartlomiej Zolnierkiewicz, Alan Cox, linux-ide,
	Andrew Morton
In-Reply-To: <9BA602B9-F1DB-4374-A35F-F68F8CB50326@mac.com>

can you please post your dmesg?

On 3/31/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> I haven't received any response to this email over the last several
> days, so I'm resending it in hopes that someone can help me track
> down the problem.  Thanks!
>
> On Mar 28, 2006, at 12:57:29, Kyle Moffett wrote:
> > I'm getting the following errors in my syslog on a fairly regular
> > basis (1 or 2 per hour).  They seem to have started when I upgraded
> > from Debian 2.6.12-1-powerpc (with internal IDE patch) to Debian
> > 2.6.15-1-powerpc.  My best guess is for some reason the kernel
> > started issuing the command MULTWRITE_EXT that it didn't before,
> > and one of my drives doesn't like it.  Two of the drives are
> > attached to a Promise PDC20268 (Rebranded a couple times by
> > different manufacturers and with mac-bootable firmware), the third
> > is attached to the internal ATA66 bus in the 400MHz powermac G4.
> > My apologies if this problem is known and fixed in 2.6.16; if
> > necessary I'll wait until Debian testing gets a 2.6.16 kernel and
> > test that too.
>
> A few extra notes:  The system is a Samba fileserver for a collection
> of Windows XP clients, but the pattern of errors does not seem to be
> triggered by load, including the daily backups.  The hourly smart
> checks also appear to have nothing to do with the error messages;
> sometimes I'll get 10 in the middle of the night, other times almost
> a full day of reasonable load will go by without a single message.
>
> > Thanks for the help!
> >
> > Cheers,
> > Kyle Moffett
> >
> > Begin forwarded message:
> >> Security Events
> >> =-=-=-=-=-=-=-=
> >> Mar 28 03:15:13 penelope kernel: ide: failed opcode was: unknown
> >> Mar 28 03:30:13 penelope kernel: ide: failed opcode was: unknown
> >>
> >> System Events
> >> =-=-=-=-=-=-=
> >> Mar 28 03:15:13 penelope kernel: hdi: status timeout: status=0xd0
> >> { Busy }
> >> Mar 28 03:15:13 penelope kernel: PDC202XX: Secondary channel reset.
> >> Mar 28 03:15:13 penelope kernel: hdi: no DRQ after issuing
> >> MULTWRITE_EXT
> >> Mar 28 03:15:13 penelope kernel: ide4: reset: success
> >> Mar 28 03:30:13 penelope kernel: hdi: status timeout: status=0xd0
> >> { Busy }
> >> Mar 28 03:30:13 penelope kernel: PDC202XX: Secondary channel reset.
> >> Mar 28 03:30:13 penelope kernel: hdi: no DRQ after issuing
> >> MULTWRITE_EXT
> >> Mar 28 03:30:13 penelope kernel: ide4: reset: success
> >
> > smartctl -a:
> >> smartctl version 5.34 [powerpc-unknown-linux-gnu] Copyright (C)
> >> 2002-5 Bruce Allen
> >> Home page is http://smartmontools.sourceforge.net/
> >>
> >> === START OF INFORMATION SECTION ===
> >> Device Model:     SAMSUNG SP0822N
> >> Serial Number:    S06QJ10Y946116
> >> Firmware Version: WA100-32
> >> User Capacity:    80,060,424,192 bytes
> >> Device is:        In smartctl database [for details use: -P show]
> >> ATA Version is:   6
> >> ATA Standard is:  ATA/ATAPI-6 T13 1410D revision 1
> >> Local Time is:    Tue Mar 28 12:54:35 2006 EST
> >> SMART support is: Available - device has SMART capability.
> >> SMART support is: Enabled
> >>
> >> === START OF READ SMART DATA SECTION ===
> >> SMART overall-health self-assessment test result: PASSED
> >>
> >> General SMART Values:
> >> Offline data collection status:  (0x84) Offline data collection
> >> activity
> >>                                         was suspended by an
> >> interrupting command from host.
> >>                                         Auto Offline Data
> >> Collection: Enabled.
> >> Self-test execution status:      (   0) The previous self-test
> >> routine completed
> >>                                         without error or no self-
> >> test has ever
> >>                                         been run.
> >> Total time to complete Offline
> >> data collection:                 (1980) seconds.
> >> Offline data collection
> >> capabilities:                    (0x5b) SMART execute Offline
> >> immediate.
> >>                                         Auto Offline data
> >> collection on/off support.
> >>                                         Suspend Offline collection
> >> upon new
> >>                                         command.
> >>                                         Offline surface scan
> >> supported.
> >>                                         Self-test supported.
> >>                                         No Conveyance Self-test
> >> supported.
> >>                                         Selective Self-test
> >> supported.
> >> SMART capabilities:            (0x0003) Saves SMART data before
> >> entering
> >>                                         power-saving mode.
> >>                                         Supports SMART auto save
> >> timer.
> >> Error logging capability:        (0x01) Error logging supported.
> >>                                         No General Purpose Logging
> >> support.
> >> Short self-test routine
> >> recommended polling time:        (   2) minutes.
> >> Extended self-test routine
> >> recommended polling time:        (  33) minutes.
> >>
> >> SMART Attributes Data Structure revision number: 17
> >> Vendor Specific SMART Attributes with Thresholds:
> >> ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE
> >> UPDATED  WHEN_FAILED RAW_VALUE
> >>   1 Raw_Read_Error_Rate     0x000f   100   099   051    Pre-fail
> >> Always       -       0
> >>   3 Spin_Up_Time            0x0007   252   252   011    Pre-fail
> >> Always       -       0
> >>   4 Start_Stop_Count        0x0032   252   252   000    Old_age
> >> Always       -       0
> >>   5 Reallocated_Sector_Ct   0x0033   252   252   011    Pre-fail
> >> Always       -       0
> >>   7 Seek_Error_Rate         0x000f   252   252   051    Pre-fail
> >> Always       -       0
> >>   8 Seek_Time_Performance   0x0025   092   092   015    Pre-fail
> >> Offline      -       3665
> >>   9 Power_On_Half_Minutes   0x0032   099   099   000    Old_age
> >> Always       -       32h+43m
> >> 10 Spin_Retry_Count        0x0033   252   252   051    Pre-fail
> >> Always       -       0
> >> 11 Calibration_Retry_Count 0x0012   252   252   000    Old_age
> >> Always       -       0
> >> 12 Power_Cycle_Count       0x0032   252   252   000    Old_age
> >> Always       -       0
> >> 190 Unknown_Attribute       0x0022   154   133   000    Old_age
> >> Always       -       33
> >> 194 Temperature_Celsius     0x0022   151   133   000    Old_age
> >> Always       -       34
> >> 195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age
> >> Always       -       0
> >> 196 Reallocated_Event_Count 0x0032   252   252   000    Old_age
> >> Always       -       0
> >> 197 Current_Pending_Sector  0x0012   252   252   000    Old_age
> >> Always       -       0
> >> 198 Offline_Uncorrectable   0x0030   252   252   000    Old_age
> >> Offline      -       0
> >> 199 UDMA_CRC_Error_Count    0x003e   199   199   000    Old_age
> >> Always       -       173
> >> 200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age
> >> Always       -       0
> >> 201 Soft_Read_Error_Rate    0x000a   100   100   000    Old_age
> >> Always       -       0
> >>
> >> Warning! SMART ATA Error Log Structure error: invalid SMART checksum.
> >> SMART Error Log Version: 1
> >> No Errors Logged
> >>
> >> SMART Self-test log structure revision number 0
> >> Warning: ATA Specification requires self-test log structure
> >> revision number = 1
> >> Num  Test_Description    Status                  Remaining
> >> LifeTime(hours)  LBA_of_first_error
> >> # 1  Short offline       Completed without error       00%
> >> 3918         -
> >> # 2  Short offline       Completed without error       00%
> >> 3894         -
> >> # 3  Extended offline    Interrupted (host reset)      30%
> >> 3870         -
> >> # 4  Short offline       Completed without error       00%
> >> 3846         -
> >> # 5  Short offline       Completed without error       00%
> >> 3822         -
> >> # 6  Short offline       Completed without error       00%
> >> 3798         -
> >> # 7  Short offline       Completed without error       00%
> >> 3774         -
> >> # 8  Short offline       Completed without error       00%
> >> 3750         -
> >> # 9  Short offline       Completed without error       00%
> >> 3726         -
> >> #10  Extended offline    Completed without error       00%
> >> 3703         -
> >> #11  Short offline       Completed without error       00%
> >> 3678         -
> >> #12  Short offline       Completed without error       00%
> >> 3654         -
> >> #13  Short offline       Completed without error       00%
> >> 3630         -
> >> #14  Short offline       Completed without error       00%
> >> 3606         -
> >> #15  Short offline       Completed without error       00%
> >> 3582         -
> >> #16  Short offline       Completed without error       00%
> >> 3558         -
> >> #17  Extended offline    Completed without error       00%
> >> 3535         -
> >> #18  Short offline       Completed without error       00%
> >> 3511         -
> >> #19  Short offline       Completed without error       00%
> >> 3487         -
> >> #20  Short offline       Completed without error       00%
> >> 3463         -
> >> #21  Short offline       Completed without error       00%
> >> 3439         -
> >>
> >> SMART Selective Self-Test Log Data Structure Revision Number (0)
> >> should be 1
> >> SMART Selective self-test log data structure revision number 0
> >> Warning: ATA Specification requires selective self-test log data
> >> structure revision number = 1
> >> SPAN          MIN_LBA          MAX_LBA  CURRENT_TEST_STATUS
> >>     1                0                0  Not_testing
> >>     2                0                0  Not_testing
> >>     3  281479271677952                0  Not_testing
> >>     4                0  281479271767952  Not_testing
> >>     5           604800                4  Not_testing
> >> Selective self-test flags (0x0):
> >>   After scanning selected spans, do NOT read-scan remainder of disk.
> >> If Selective self-test is pending on power-up, resume after 0
> >> minute delay.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply

* [DNX#2006040142000848] [U-Boot-Users] [PATCH] cleanup duplicated ARM inte [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply

* [DNX#2006040142000839] [U-Boot-Users] Patch:  Fixes for XES Xpedite1000 B [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply

* [DNX#2006040142000821] [U-Boot-Users] [PATCH] add support for DS1339 RTC
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply

* [DNX#2006040142000795] [U-Boot-Users] [PATCH] fix undefined error on omap [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply

* [DNX#2006040142000811] [U-Boot-Users] Re: [U-Boot-Users][Patch] Cleanup o [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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@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

^ permalink raw reply

* [DNX#2006040142000802] [U-Boot-Users] Re: MIPS LE build problems
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000786] [U-Boot-Users] [PATCH] Add RealView Emulation Base [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply

* [DNX#2006040142000768] [U-Boot-Users] [PATCH 3/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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@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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000777] [U-Boot-Users] Ocotea with 512 megs of ram - ping  [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

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 at lists.sourceforge.net 
> > [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf 
> > Of Dale Dunlea
> > Sent: Tuesday, February 14, 2006 8:32 AM
> > To: u-boot-users at 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 at 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&kid\x103432&bid#0486&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000759] [U-Boot-Users] Bug in DTT for temperatures below z [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000759] was created:

<snip>
> In message <42AFEBD3.3050008@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 at 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&kid\x110944&bid$1720&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000741] [U-Boot-Users] [PATCH-1/8]Blackfin support - Add t [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000741] was created:

<snip>
> The patch is based on following point in the current U-boot git
> repository.
> ============================================================
> commit 6624b687bc2b747233090e67628df37d1c84ed17
> Author: Wolfgang Denk <wd@pollux.(none)>
> Date:   Wed Feb 22 10:25:39 2006 +0100
> 
>     Rename SMMACO4 board into smmaco4 for consistency with Linux.
> ============================================================
> 
> Changelog entry:
> * Add the configuration file of Blackfin
>     Patch by Aubrey.Li <aubreylee@gmail.com>
> 
> Thanks,
> -Aubrey
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000722] [U-Boot-Users] New architecture(Blackfin) porting  [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000722] was created:

<snip>
> On 2/27/06, Wolfgang Denk <wd@denx.de> wrote:
> > In message <6d6a94c50602262335q44711c0epfb3e67fbaa5fd806@mail.gmail.com> you wrote:
> > >
> > > 1) Should the patch be against the latest release version or the
> > > current git repository?
> >
> > Both is acceptable, but a patch against the  latest  git  version  is
> > preferred (please provide the specific commit ID you used).
> 
> aubrey at linux:~/main-line-uboot/patch/work> git log
> commit ad0613982d79dacf965d557589e9a181fee7033b
> Author: Aubrey.Li <aubrey@linux.site>
> Date:   Tue Feb 28 11:09:39 2006 +0800
> 
>     blackfin platform support
> 
> >
> > > 2) Should the patch be an enclosed git-diff format file or plain text
> > > pasted in the mail?
> > > 3) Is there anything else besides coding style?
> >
> > Please see section "Submitting Patches" in the README.
> I also attached the patch compressed, which is the diff in unified git
> format.
> 
> Regards,
> -Aubrey
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000731] [U-Boot-Users] [Patch 4/5] Add USB support for AT9 [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000731] was created:

<snip>
> This patch (4/5) adds USB support for ATMEL AT91SAM9261EK board.
> 
> CHANGELOG
> Patch by Nicolas Lacressonniere 24 January 2006
> * Add USB support for ATMEL AT91SAM9261EK board (arm926ejs)
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000713] [U-Boot-Users] Bug in StrataFlash drivers
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000713] was created:

<snip>
> >>>Do you have a spoecific test case that shows the presence of the bug?
> >>
> >>I experience the problem when trying to store in Flash my ramdisk image 
> >>that is 1502693 bytes.
> > 
> > 
> > This will probably also happen with smaller size?
> Yes, I think it will happen with any odd-sized files.
> 
> 
> >>>And can you please provide a  proper  patch,  with  CHANGELOG  entry,
> >>>Signed-off-by line and everything?
> See attached file.
> 
> ChangeLog:
> * Patch by Andrea Marson, 11 November 2005:
> Fixed odd-sized images writing in Zefeer StrataFlash driver.
> 
> 
> Signed-off-by: Andrea Marson <r&d2@dave-tech.it>
> 
> 
> 
> 
> Best regards,
> llandre
> 
> DAVE Electronics System House - R&D Department
> web:   http://www.dave-tech.it
> email: r&d2 at dave-tech.it
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000704] [U-Boot-Users] Re: [PATCH] Make System IO Config R [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000704] was created:

<snip>
> Wolfgang.
> 
> That is very  convincing. So for the special case of setting RCW to boot
> 
> from lowmem vector, all is well.  And I guess there is no great harm in 
> that restriction.
> 
> When RCW set to boot from himem vector though, the 83xx maps in the 
> _last_ 8M of the flash chip, not the first, so the remap_flash_by_law* 
> routines end up mapping u-boot out from under us.  But OK; we just won't
> 
> do that then.
> 
> I still stand by by compaint though: if you're going to remap flash 
> according to CFG_FLASH_BASE in start.S,  then the 8M hardcoded size is 
> annoying.
> 
> >>back to LAW0 on a builtin assumption of 8M size, placing the starting 
> >>address thereof to the CFG_FLASH_BASE location (in their case, 
> >>0xfe00_0000); then do jumping arithmetic based on that value and TEXT_BASE.
> >>
> >>Which works in the Freescale-ADS case, as they have an 8M flash chip.
> > 
> > 
> > It also works in case of the TQM8349 board, which uses 32 MB:
> > 
> > U-Boot 1.1.4 (Nov 17 2005 - 00:14:36) MPC83XX
> > 
> > Clock configuration:
> >   Coherent System Bus:  266 MHz
> >   Core:                 533 MHz
> >   Local Bus:             33 MHz
> > CPU:   MPC83xx, Rev: 1.1 at 533.328 MHz
> > Board: TQM834x
> > PCI1:  32 bit, 33 MHz
> > I2C:   ready
> > DTT:   1 is 28 C
> > DRAM:  256 MB
> > FLASH: 32 MB
> > PCI:   Bus Dev VenId DevId Class Int
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   TSEC0, TSEC1
> > 
> > Type "run flash_nfs" to mount root filesystem over NFS
> > 
> > Hit any key to stop autoboot:  0 
> > => fli
> > 
> > Bank # 1: CFI conformant FLASH (32 x 16)  Size: 32 MB in 256 Sectors
> >  Erase timeout 16384 ms, write timeout 0 ms, buffer write timeout 4096 ms, buffer size 32
> >   Sector Start Addresses:
> >     80000000 (RO) 80020000 (RO) 80040000 (RO) 80060000      80080000     
> >     800A0000      800C0000      800E0000      80100000      80120000     
> >     80140000      80160000      80180000      801A0000      801C0000     
> > ...
> > 
> > Best regards,
> > 
> > Wolfgang Denk
> > 
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000697] [U-Boot-Users] [PATCH]Fix cc-option macro in confi [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000697] was created:

<snip>
> 
> The following patch fix the compilation problem discussed in thread
> "Problem building U-Boot for ARM target"
> 
> Best regards
> -P.Broggini
> 
> 
> 
> Signed-off-by: Paolo Broggini <pbroggini@softool.ch>
> 
> 
> CHANGELOG:
>    Fix cc-option macro in config.mk, $(CFLAGS) dropped.
>    Patch by Paolo Broggini, 12 Oct 2005
> 
> 
> diff --git a/config.mk b/config.mk
> --- a/config.mk
> +++ b/config.mk
> @@ -90,7 +90,7 @@ HOSTSTRIP	= strip
>   # Option checker (courtesy linux kernel) to ensure
>   # only supported compiler options are used
>   #
> -cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc
> /dev/null \
> +cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \
>   		> /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
> 
>   #
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000688] [U-Boot-Users] Re: parse bug in cmd_mii.c
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000688] was created:

<snip>
> Sorry, it looks like I never sent it in.  Here goes:
> 
> CHANGELOG
> * entering 'mii' with no arguments causes a null pointer reference.
> Check argc is >=2 before dereferencing argv[1].  Print the usage message
> if
> not.
> Patch by Andrew Dyer <amdyer@gmail.com>, Sat Mar 11 21:42:12 CST 2006
> 
> Signed-off-by: Andrew Dyer <amdyer@gmail.com>
> 
> Index: cmd_mii.c
> ===================================================================
> RCS file: /home/cvsroot/Projects/u-boot/common/cmd_mii.c,v
> retrieving revision 1.1.1.5
> retrieving revision 1.8
> diff -u -r1.1.1.5 -r1.8
> --- cmd_mii.c   7 Feb 2006 09:51:23 -0000       1.1.1.5
> +++ cmd_mii.c   12 Mar 2006 03:33:56 -0000      1.8
> @@ -61,6 +61,11 @@
>         mii_init ();
>  #endif
> 
> +       if (argc < 2) {
> +               printf ("Usage:\n%s\n", cmdtp->usage);
> +               return 1;
> +       }
> +
>         /*
>          * We use the last specified parameters, unless new ones are
>          * entered.
> @@ -438,6 +443,11 @@
>  #ifdef CONFIG_8xx
>         mii_init ();
>  #endif
> +
> +       if (argc < 2) {
> +               printf ("Usage:\n%s\n", cmdtp->usage);
> +               return 1;
> +       }
> 
>         /*
>          * We use the last specified parameters, unless new ones are
> 
> 
> 
> 
> On 3/11/06, Wolfgang Denk <wd@denx.de> wrote:
> > In message <c166aa9f0506131006ba8f552@mail.gmail.com> you wrote:
> > > I noticed that in do_mii() the code is dereferencing argv[1] without
> > > checking what value argc has.  This leads to an exception if a command
> > > line like 'mii ' is given where argv[1] is NULL.
> > >
> > > I have a patch, but my cmd_mii.c is carrying around some other patches
> > > (some submitted to the list, some local).  Is there a good way to
> > > separate out the patches I want to submit by themselves?
> >
> > Did I miss it, or did you never send a  patch  for  the  problem  you
> > mentioned?
> >
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> > "'Tis true, 'tis pity, and pity 'tis 'tis true."
> >     - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_
> >
> 
> 
> --
> Hardware, n.:
>         The parts of a computer system that can be kicked.
> 
> 
> -------------------------------------------------------
> 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\x110944&bid$1720&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000679] [U-Boot-Users] [Patch 3/5] Add LCD support and ATM [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000679] was created:

<snip>
> This patch (3/5) adds LCD support and logo for ATMEL AT91SAM9261EK
> board.
> 
> atmel.bmp logo should be placed into tools/logos/ directory.
> 
> CHANGELOG
> Patch by Nicolas Lacressonniere 24 January 2006
> * Add LCD support and logo for ATMEL AT91SAM9261EK board (arm926ejs)
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000661] [U-Boot-Users] PATCH - Add support for wrPPMC7xx/7 [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000661] was created:

<snip>
> Please find attached my patch for the Wind River PPMC 7xx/74xx boards. 
> It has been tested with an MPC750 (66MHz bus) and MPC7400 (100MHz bus).
> 
> It adds ppmc7xx to the board directory.
> 
> The following common files have been modified:
> 
> cpu/74xx_7xx/cpu.c
> cpu/74xx_7xx/start.S
> CREDITS
> drivers/pci.c
> include/ns16550.h
> MAKEALL
> Makefile
> 
> This is my first patch so please let me know if I have missed anything.
> 
> Thanks
> Rich
</snip>

Your U-Boot support team

^ permalink raw reply

* [PATCH 2/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:13 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20060331160203.f2bf8b53.moilanen@austin.ibm.com>

This patch hooks our current interrupt subsystem and sets up a single
vector MSI as if it was a LSI.  Multiple MSI vectors is coming in the
future.

The NR_IRQS got bumped up to 1024, as vectors can go much higher.
Unfortunately, this number was arbitrarily picked as there is no claim
at what the max number really is by either the firmware team, or the
PAPR+.

Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>

---

Index: 2.6.16/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/prom.c	2006-03-31 15:11:20.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/prom.c	2006-03-31 15:37:10.000000000 -0600
@@ -88,6 +88,8 @@
 struct device_node *dflt_interrupt_controller;
 int num_interrupt_controllers;
 
+void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only);
+
 /*
  * Wrapper for allocating memory for various data that needs to be
  * attached to device nodes as they are processed at boot or when
@@ -120,6 +122,22 @@
 	return NULL;
 }
 
+int
+property_present(struct device_node *np, const char *name)
+{
+	struct property *pp;
+
+	read_lock(&devtree_lock);
+	for (pp = np->properties; pp != 0; pp = pp->next)
+		if (strcmp(pp->name, name) == 0) {
+			return 1;
+		}
+	read_unlock(&devtree_lock);
+
+	return 0;
+}
+
+
 /*
  * Find the interrupt parent of a node.
  */
@@ -341,6 +359,14 @@
 		return 0;
 	}
 
+#ifdef CONFIG_PPC_PSERIES
+	if(property_present(np, "ibm,req#msi")) {
+		printk(KERN_EMERG "Found MSI\n");
+		finish_msi_node(np, mem_start, measure_only);
+		return 0;
+	}
+#endif
+
 	ints = (unsigned int *) get_property(np, "interrupts", &intlen);
 	TRACE("ints=%p, intlen=%d\n", ints, intlen);
 	if (ints == NULL)
@@ -503,6 +529,80 @@
 	DBG(" <- finish_device_tree\n");
 }
 
+void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only)
+{
+	static int seq_num = 1;
+	int i;
+	int rc;
+	int query_token = rtas_token("ibm,query-interrupt-source-number");
+	int devfn;
+	int busno;
+	u32 *reg;
+	int reglen;
+	int ret[3];
+	unsigned int virq;
+	unsigned int addr;
+	unsigned long buid = -1;
+	unsigned long wait_time;
+
+	reg = (u32 *) get_property(dn, "reg", &reglen);
+	if (reg == NULL || reglen < 20)
+		return;
+
+	devfn = (reg[0] >> 8) & 0xff;
+	busno = (reg[0] >> 16) & 0xff;
+
+	buid = get_phb_buid(dn->parent);
+	addr = (busno << 16) | (devfn << 8);
+
+	while (1) {
+		rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+			       buid >> 32, buid & 0xffffffff,
+			       1, 1, seq_num);
+
+		if (!rc)
+			break;
+		else if (rc == RTAS_BUSY)
+			udelay(1);
+		else if (rtas_is_extended_busy(rc)) {
+			wait_time = rtas_extended_busy_delay_time(rc);
+			udelay(wait_time * 1000);
+		} else {
+			printk(KERN_WARNING "error[%d]: getting the number of"
+			       "MSI interrupts for %s\n", rc, dn->name);
+			return;
+		}
+
+		seq_num = ret[1];
+	}
+
+	dn->n_intrs = ret[0];
+
+	dn->intrs = prom_alloc(dn->n_intrs * sizeof(*(dn->intrs)), mem_start);
+	if (!dn->intrs) {
+		printk(KERN_EMERG "finish_msi_node: can't allocate space\n");
+		return;
+	}
+
+	if (measure_only)
+		return;
+
+	for (i = 0; i < dn->n_intrs; i++) {
+		rc = rtas_call(query_token, 4, 3, ret, addr, buid >> 32, buid & 0xffffffff, i);
+
+		if (!rc) {
+			virq = virt_irq_create_mapping(ret[0]);
+
+			dn->intrs[i].line = irq_offset_up(virq);
+			dn->intrs[i].sense = ret[1];
+		} else {
+			printk(KERN_WARNING "error[%d]: query-interrupt-source-number for %s\n",
+			       rc, dn->name);
+		}
+	}
+
+}
+
 static inline char *find_flat_dt_string(u32 offset)
 {
 	return ((char *)initial_boot_params) +
Index: 2.6.16/include/asm-powerpc/irq.h
===================================================================
--- 2.6.16.orig/include/asm-powerpc/irq.h	2006-03-31 15:11:12.000000000 -0600
+++ 2.6.16/include/asm-powerpc/irq.h	2006-03-31 15:15:46.000000000 -0600
@@ -47,7 +47,7 @@
 /*
  * Maximum number of interrupt sources that we can handle.
  */
-#define NR_IRQS		512
+#define NR_IRQS		1024
 
 /* Interrupt numbers are virtual in case they are sparsely
  * distributed by the hardware.
Index: 2.6.16/include/asm-powerpc/pci-bridge.h
===================================================================
--- 2.6.16.orig/include/asm-powerpc/pci-bridge.h	2006-03-31 15:11:36.000000000 -0600
+++ 2.6.16/include/asm-powerpc/pci-bridge.h	2006-03-31 15:34:50.000000000 -0600
@@ -141,6 +141,7 @@
 void pcibios_fixup_new_pci_devices(struct pci_bus *bus, int fix_bus);
 
 extern int pcibios_remove_root_bus(struct pci_controller *phb);
+extern unsigned long __devinit get_phb_buid (struct device_node *phb);
 
 static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
 {

^ permalink raw reply

* [DNX#2006040142000651] [U-Boot-Users] [PATCH] CFI: fix timeout calculatio [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000651] was created:

<snip>
> This patch fixes two problems with the cfi_flash timeout handling:
> 1) Correctly handle the cases where CFG_HZ != 1000 (several XScale-based
> boards)
> 2) Fix the timeout calculation of buffered writes (off by a factor of
> 1000)
> 
> Additionally, the patch trivially removes a redundant call of getenv()
> 
> Signed-off-by: Anders Larsen <al@alarsen.net>
> 
> ---
> 
>  drivers/cfi_flash.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c
> index a989d34..c7c9983 100644
> --- a/drivers/cfi_flash.c
> +++ b/drivers/cfi_flash.c
> @@ -360,7 +360,7 @@ #ifdef CFG_FLASH_PROTECTION
>  		else {
>  			char *s = getenv("unlock");
>  
> -			if (((s = getenv("unlock")) != NULL) && (strcmp(s, "yes") == 0)) {
> +			if ((s != NULL) && (strcmp(s, "yes") == 0)) {
>  				/*
>  				 * Only the U-Boot image and it's environment is protected,
>  				 * all other sectors are unprotected (unlocked) if flash
> @@ -746,6 +746,10 @@ static int flash_status_check (flash_inf
>  {
>  	ulong start;
>  
> +#if CFG_HZ != 1000
> +	tout *= CFG_HZ/1000;
> +#endif
> +
>  	/* Wait for command completion */
>  	start = get_timer (0);
>  	while (flash_is_busy (info, sector)) {
> @@ -1160,8 +1164,9 @@ #endif
>  		info->buffer_size = (1 << flash_read_ushort (info, 0,
> FLASH_OFFSET_BUFFER_SIZE));
>  		tmp = 1 << flash_read_uchar (info, FLASH_OFFSET_ETOUT);
>  		info->erase_blk_tout = (tmp * (1 << flash_read_uchar (info,
> FLASH_OFFSET_EMAX_TOUT)));
> -		tmp = 1 << flash_read_uchar (info, FLASH_OFFSET_WBTOUT);
> -		info->buffer_write_tout = (tmp * (1 << flash_read_uchar (info,
> FLASH_OFFSET_WBMAX_TOUT)));
> +		tmp = (1 << flash_read_uchar (info, FLASH_OFFSET_WBTOUT)) *
> +		      (1 << flash_read_uchar (info, FLASH_OFFSET_WBMAX_TOUT));
> +		info->buffer_write_tout = tmp / 1000 + (tmp % 1000 ? 1 : 0); /* round
> up when converting to ms */
>  		tmp = (1 << flash_read_uchar (info, FLASH_OFFSET_WTOUT)) *
>  		      (1 << flash_read_uchar (info, FLASH_OFFSET_WMAX_TOUT));
>  		info->write_tout = tmp / 1000 + (tmp % 1000 ? 1 : 0); /* round up
> when converting to ms */
> 
> 
> 
> -------------------------------------------------------
> 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\x110944&bid$1720&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000642] [U-Boot-Users] [PATCH 0/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000642] was created:

<snip>
> Seven patches on the way which add support for using the Flat device
> tree 
> in u-boot to pass device initialization information to Linux, which is 
> used for 85xx support in the arch/powerpc tree.
> 
> These patches build on the previous patches, which add 8540 ADS support 
> (without PCI).
> 
> In addition, as part of the update, PCI initialization has been moved 
> fully into u-boot, so all PCI busses are now scanned and configured.
> 
> Here's the index of the patches:
> 
> 1: Fix prefetch disabling code in drivers/pci_auto.c so it sets the
> memory 
> limit to 0 (instead of 0x1000)
> 2: Adds PCI-X #defines for PCI-X initialization
> 3: Fixes a bug in the fdt setup code for 85xx, where memory size was not
> 
> updated based on reality
> 4: Adds support for initializing the second PCI bus
> 5: Adds PCI and I2C fdt support for 8540ADS
> 6: Adds PCI and I2C fdt support for 85xx CDS
> 7: Changes the 8540 ADS PCI speed back to 66 MHz, and adds warnings and 
> comments to the effect that PCI-X will not work unless it's running at 
> 66 MHz.
> 
> 
> -------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply

* [U-Boot-Users] Re: [DNX#2006040142000624] Bug fix on cmd_nand.c
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000624] was created:

<snip>
> Hello, Wolfgang!
> 
> I found two bugs in common/cmd_nand.c when debugging nand flash, which
> is from u-boot-1.1.4 and the same with git tree:
> 
> 1. there are 3 places using "not exact" or "wrong" parameters in 
> strncmp() function.
> 
> strncmp(cmdtail, ".oob", 2)    ==> strncmp(cmdtail, ".oob", 4)
> strncmp(cmdtail, ".jffs2", 2)  ==> strncmp(cmdtail, ".jffs2", 6)
> strncmp(cmdtail, ".jffs2s", 2) ==> strncmp(cmdtail, ".jffs2s", 7)
> 
> 2. "nand read.jffs2" command will bypass "nand read.jffs2s" command
> for the else-if branch.
> 
> FYI, the attachment is a diff patch with "-purN" options.
> 
> Best regards,
> Dongyan Chai
</snip>

Your U-Boot support team

^ permalink raw reply

* [DNX#2006040142000633] [U-Boot-Users] i.MX support for scb9328 cleaned up [...]
From: DENX Support System @ 2006-03-31 22:20 UTC (permalink / raw)
  To: u-boot

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000633] was created:

<snip>
> At Tue, 11 Oct 2005 22:34:24 +0200,
> Wolfgang Denk <wd@denx.de> wrote:
> 
> > Does that mean that I should  ignore  the  link  you  posted  earlier
> > today?
> 
> I cleared up the structure now.
> 
> http://www.ludenkalle.de/u-boot/
> 
> Has my last clean up effort and the old stuff in deprecated.
> The u-boot-git-20051012.diff is a diff between yesterdays git checkout
> and my actual modifications. the directory content of
> u-boot-git-20051012/ is the same splittet with splitdiff vor viewing
> convenience on a per file basis (so pretty redundant).
> 
> > Make sure to include or exactly the needed features only. "all but X"
> > is asking for problems when a new feature Y gets added which  is  not
> > supported  by  your  board. Rather use "default - M - N + X + Y".
> 
> But is
> 
> +#define CONFIG_COMMANDS \
> 	 (CONFIG_CMD_DFL\
> 	& ~CFG_CMD_NET\
> 	& ~CFG_CMD_IMLS\
> 
> [...]
> 
> 	& ~CFG_CMD_MISC\
> 	| CFG_CMD_CACHE)
> 
> not your described way to do this?
> 
> > Yes, there are several of these stupidly configured  boards  which  I
> > have to cleanup nearly each time a new command gets added. See
> 
> Do you have an example in mind where I should have a look at?
> 
> Regards, Konsti
> 
> -- 
> GPG KeyID EF62FCEF
> Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>

Your U-Boot support team

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.