LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] powerpc: fix idr locking in init_new_context
From: Sonny Rao @ 2006-06-27 12:46 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, linux-kernel, anton


We always need to serialize accesses to mmu_context_idr.

I hit this bug when testing with a small number of mmu contexts.


Signed-off-by: Sonny Rao <sonny@burdell.org>

--- a/arch/powerpc/mm/mmu_context_64.c
+++ b/arch/powerpc/mm/mmu_context_64.c
@@ -44,7 +44,9 @@ again:
                return err;
 
        if (index > MAX_CONTEXT) {
+               spin_lock(&mmu_context_lock);
                idr_remove(&mmu_context_idr, index);
+               spin_unlock(&mmu_context_lock);
                return -ENOMEM;
        }

^ permalink raw reply

* Re: Reg RISC timers in MPC 8260
From: Vitaly Bordug @ 2006-06-27 11:51 UTC (permalink / raw)
  To: Jagan; +Cc: linuxppc-embedded
In-Reply-To: <20060627113137.2386.qmail@web36913.mail.mud.yahoo.com>

На Tue, 27 Jun 2006 04:31:37 -0700 (PDT)
Jagan <morphicsk@yahoo.com> записано:

> Hi all
> 
> We have a requirement of running a periodic timer for
> 5 millisecond using RISC timers in CPM module of
> MPC8260. The OS is monta vista linux and target is
> MPC8260 I have written a sample code to start a
> periodic timer using MPC8260. 
> 
> But it hangs when SET TIMER command is issued to the
> CPCR register. The cross compiler we r using is
> ppc_82xx-gcc.
>  
> Can anyone pls help me in getting this right ?
> 
> I am pasting the code here 
> ------------------------------------------------------
> /*Start of code snippet  ignoring the header files */
> cpm8xx_t	*cpmp;
> 
> volatile immap_t *immap = (immap_t *)IMAP_ADDR;
> 
hrmmm, isn't 8260 CPM2? This is 8xx immap, that is _really_ different
from what 8260 has... Grep for cpm2_immr and look into asm/immap_cpm2.h
for details.

-Vitaly

^ permalink raw reply

* Reg RISC timers in MPC 8260
From: Jagan @ 2006-06-27 11:31 UTC (permalink / raw)
  To: linuxppc-embedded

Hi all

We have a requirement of running a periodic timer for
5 millisecond using RISC timers in CPM module of
MPC8260. The OS is monta vista linux and target is
MPC8260 I have written a sample code to start a
periodic timer using MPC8260. 

But it hangs when SET TIMER command is issued to the
CPCR register. The cross compiler we r using is
ppc_82xx-gcc.
 
Can anyone pls help me in getting this right ?

I am pasting the code here 
------------------------------------------------------
/*Start of code snippet  ignoring the header files */
cpm8xx_t	*cpmp;

volatile immap_t *immap = (immap_t *)IMAP_ADDR;

#define CPCR_OPCODE ( 8 << 8 ) /* CPCR Opcode Field:
SET TIMER */
#define CPCR_CHNUM ( 5 << 4 ) /* CPCR Ch Num Field:
SPI/IDMA2/RISC Timers */
#define CPCR_FLAG ( 1 << 0 ) /* CPCR Flag Field:
Process Command */
#define PROFF_RISCTT	((uint)0x01B0)

void risc_timer_handler(int irq, void *dev_id, struct
pt_regs *regs)
{
 unsigned int i, rter;

 printk("Inside risc timer handler \n");
 /*read RTER to see which timers have caused
interrupts.
 */
 
 rter  = immap->im_cpm.cp_rter ;

 /*The RISC timer event bits are usually cleared
  *by this time
  */
 immap->im_cpm.cp_rter = 0xffff ; 

  
}

int  __init device_init(void)
{
   unsigned int ticks = 0;
   unsigned int interval  = 1000;
   unsigned short prescaler = 0; 
   volatile cpm8xx_t	*cp;


  /* 
   * Write the TIMEP bits of the RCCR with 111111 to
generate the slowest 
   * clock, This value generates a tick every 65,536
clocks, which is every 
   * 2.6 milliseconds at 25 MHz.
   */

   immap->im_cpm.cp_rccr = ( 0x3f << 8 );
   
   /*
    * Configure the TM_BASE in the RISC timer table
parameter RAM to point to a location in the
    * dual-port RAM with 4 bytes available.
    */ 
    


 //  rt_pram_t *rtt_pramp = (rt_pram_t
*)(&cpmp->cp_dparam[PROFF_RISCTT]);


   cp = (cpm8xx_t *)&(immap->im_cpm);

    
   
   rt_pram_t *rtt_pramp = (rt_pram_t *)&cp->cp_dparam;

   /*
   * Assuming the beginning of dual-port RAM is
available,
   * write 0x0000 to TM_BASE.
   */



    rtt_pramp->tm_base = 0x0000; 

 
//   rtt_pramp->tm_base = m8xx_cpm_dpalloc(16);      
logic 1

   /*Write 0x0000 to the TM_CNT field in the RISC
timer table 
    *parameter RAM to see how many ticks elapsed since
the RISC 
    *internal timer was enabled.
   */
   rtt_pramp->tm_cnt  = 0x0;

   /*Write 0xFFFF to the RTER to clear any previous
events.
    */

   immap->im_cpm.cp_rter = 0xffff;

   /* Write 0x0001 to the RTMR to enable RISC timer 0
    *  and timer 1 to generate an interrupt.
    */
   immap->im_cpm.cp_rtmr |= 0x1 ;



   if(
request_irq(SIU_INT_RISC,risc_timer_handler,0,0,0) <
0)
   {
     printk("\n unable to register the RISC timer
\n");
   }

  /*Write 0xC000_080D to the TM_CMD field of the RISC
timer table
    parameter RAM. This enables RISC timer 0 to
timeout after 2,061(decimal)
    ticks of the timer. The timer automatically
restarts after it times out. 	
  */ 

  rtt_pramp->tm_cmd = 0xC000080D ; 

  /* Enter Command:  SET TIMER */

  while (immap->im_cpm.cp_cpcr & CPM_CR_FLG);
         immap->im_cpm.cp_cpcr =
mk_cr_cmd(CPM_CR_CH_SPI, CPM_CR_SET_TIMER) |
CPM_CR_FLG;
  while (immap->im_cpm.cp_cpcr & CPM_CR_FLG);

 
  /* Set RCCR[TIME] to enable the RISC timer to
   * begin operation.  
   */

  immap->im_cpm.cp_rccr = ( 1 << 15 );


  return 0;
}



                                                      
                                                      
               
void cleanup_device(void)
{
 
 
  request_irq(SIU_INT_RISC, NULL, 0, 0,
		0);
                                                      
                                                      
               
  printk(KERN_INFO "cleaned up \n");
}
                                                      
                                                      
               
module_init(device_init);
module_exit(cleanup_device);
                                                      
                                                      
               
                                                      
                                                      
               
MODULE_LICENSE("GPL");
                                                      
                                                      
               
MODULE_AUTHOR("");
MODULE_DESCRIPTION("driver code");
                                                      
                                                      
               
EXPORT_NO_SYMBOLS;
/*End of code snippet  */
-------------------------------------------------------

Thanks in Advance 
Jagan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply

* Re: [PATCH] Remove extra local_bh_disable/enable from arch do_softirq
From: Ingo Molnar @ 2006-06-27 10:08 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: akpm, schwidefsky, linux-kernel, linuxppc-dev
In-Reply-To: <17566.32236.368906.227113@cargo.ozlabs.ibm.com>


* Paul Mackerras <paulus@samba.org> wrote:

> At the moment, powerpc and s390 have their own versions of do_softirq 
> which include local_bh_disable() and __local_bh_enable() calls.  They 
> end up calling __do_softirq (in kernel/softirq.c) which also does 
> local_bh_disable/enable.
> 
> Apparently the two levels of disable/enable trigger a warning from 
> some validation code that Ingo is working on, and he would like to see 
> the outer level removed.  But to do that, we have to move the 
> account_system_vtime calls that are currently in the arch do_softirq() 
> implementations for powerpc and s390 into the generic __do_softirq() 
> (this is a no-op for other archs because account_system_vtime is 
> defined to be an empty inline function on all other archs).  This 
> patch does that.
> 
> Signed-off-by: Paul Mackerras <paulus@samba.org>

thanks - this solves the problem nicely.

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

^ permalink raw reply

* RE: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Zhang Wei-r63237 @ 2006-06-27  9:28 UTC (permalink / raw)
  To: Florian Boelstler, linuxppc-embedded

> 
> Is there a publicly available source for patches to the current BSP?
> Are there any other PCIe-related fixes?

It's an add-on PCIe patch. We have tested it on MPC8641, but we have no PCIe-PCI bridge on MPC8548 platform to do more test. So if you verify it, I'll commit it. :)

> 
> Best regards,
> 
>    Florian
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

^ permalink raw reply

* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-06-27  8:39 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306D9253D@zch01exm40.ap.freescale.net>

Hi,

thanks for your quick response.
I'll try the proposed changes today.

Zhang Wei-r63237 schrieb:
> Trying to apply below patch code:
 > [...]

Is there a publicly available source for patches to the current BSP?
Are there any other PCIe-related fixes?

Best regards,

   Florian

^ permalink raw reply

* Re: [PATCH] convert powermac ide blink to new led infrastructure
From: Benjamin Herrenschmidt @ 2006-06-27  7:50 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1150884676.23386.6.camel@johannes>

On Wed, 2006-06-21 at 12:11 +0200, Johannes Berg wrote:
> This should address all the objections you voiced: it now is backward
> compatible with the old (and now deprecated) Kconfig option by using a
> bunch of select Kconfig statements and adding a single line of code in
> #ifdef :)
> 
> Please pass on for 2.6.18.

Looks good. Only one nit: in pmu_led_set(), you should be able to test
if the requested state is identical to the current one and do nothing
without taking the lock no ?

Or does the upper level LED infrastructure takes care of it ?

Ben.

> ---
> This patch removes the old pmac ide led blink code and
> adds generic LED subsystem support for the LED.
> 
> It maintains backward compatibility with the old
> BLK_DEV_IDE_PMAC_BLINK Kconfig option which now
> simply selects the new code and influences the
> default trigger.
> 
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> 
> --- linux-2.6.orig/drivers/ide/Kconfig	2006-06-20 16:56:01.589161721 +0200
> +++ linux-2.6/drivers/ide/Kconfig	2006-06-21 12:02:08.878721123 +0200
> @@ -774,11 +774,18 @@ config BLK_DEV_IDEDMA_PMAC
>  	  performance.
>  
>  config BLK_DEV_IDE_PMAC_BLINK
> -	bool "Blink laptop LED on drive activity"
> +	bool "Blink laptop LED on drive activity (DEPRECATED)"
>  	depends on BLK_DEV_IDE_PMAC && ADB_PMU
> +	select ADB_PMU_LED
> +	select LEDS_TRIGGERS
> +	select LEDS_TRIGGER_IDE_DISK
>  	help
>  	  This option enables the use of the sleep LED as a hard drive
>  	  activity LED.
> +	  This option is deprecated, it only selects ADB_PMU_LED and
> +	  LEDS_TRIGGER_IDE_DISK and changes the code in the new led class
> +	  device to default to the ide-disk trigger (which should be set
> +	  from userspace via sysfs).
>  
>  config BLK_DEV_IDE_SWARM
>  	tristate "IDE for Sibyte evaluation boards"
> --- linux-2.6.orig/drivers/ide/ppc/pmac.c	2006-06-20 16:56:01.659161721 +0200
> +++ linux-2.6/drivers/ide/ppc/pmac.c	2006-06-20 16:56:03.219161721 +0200
> @@ -421,107 +421,6 @@ static void pmac_ide_kauai_selectproc(id
>  #endif /* CONFIG_BLK_DEV_IDEDMA_PMAC */
>  
>  /*
> - * Below is the code for blinking the laptop LED along with hard
> - * disk activity.
> - */
> -
> -#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> -
> -/* Set to 50ms minimum led-on time (also used to limit frequency
> - * of requests sent to the PMU
> - */
> -#define PMU_HD_BLINK_TIME	(HZ/50)
> -
> -static struct adb_request pmu_blink_on, pmu_blink_off;
> -static spinlock_t pmu_blink_lock;
> -static unsigned long pmu_blink_stoptime;
> -static int pmu_blink_ledstate;
> -static struct timer_list pmu_blink_timer;
> -static int pmu_ide_blink_enabled;
> -
> -
> -static void
> -pmu_hd_blink_timeout(unsigned long data)
> -{
> -	unsigned long flags;
> -	
> -	spin_lock_irqsave(&pmu_blink_lock, flags);
> -
> -	/* We may have been triggered again in a racy way, check
> -	 * that we really want to switch it off
> -	 */
> -	if (time_after(pmu_blink_stoptime, jiffies))
> -		goto done;
> -
> -	/* Previous req. not complete, try 100ms more */
> -	if (pmu_blink_off.complete == 0)
> -		mod_timer(&pmu_blink_timer, jiffies + PMU_HD_BLINK_TIME);
> -	else if (pmu_blink_ledstate) {
> -		pmu_request(&pmu_blink_off, NULL, 4, 0xee, 4, 0, 0);
> -		pmu_blink_ledstate = 0;
> -	}
> -done:
> -	spin_unlock_irqrestore(&pmu_blink_lock, flags);
> -}
> -
> -static void
> -pmu_hd_kick_blink(void *data, int rw)
> -{
> -	unsigned long flags;
> -	
> -	pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
> -	wmb();
> -	mod_timer(&pmu_blink_timer, pmu_blink_stoptime);
> -	/* Fast path when LED is already ON */
> -	if (pmu_blink_ledstate == 1)
> -		return;
> -	spin_lock_irqsave(&pmu_blink_lock, flags);
> -	if (pmu_blink_on.complete && !pmu_blink_ledstate) {
> -		pmu_request(&pmu_blink_on, NULL, 4, 0xee, 4, 0, 1);
> -		pmu_blink_ledstate = 1;
> -	}
> -	spin_unlock_irqrestore(&pmu_blink_lock, flags);
> -}
> -
> -static int
> -pmu_hd_blink_init(void)
> -{
> -	struct device_node *dt;
> -	const char *model;
> -
> -	/* Currently, I only enable this feature on KeyLargo based laptops,
> -	 * older laptops may support it (at least heathrow/paddington) but
> -	 * I don't feel like loading those venerable old machines with so
> -	 * much additional interrupt & PMU activity...
> -	 */
> -	if (pmu_get_model() != PMU_KEYLARGO_BASED)
> -		return 0;
> -	
> -	dt = of_find_node_by_path("/");
> -	if (dt == NULL)
> -		return 0;
> -	model = (const char *)get_property(dt, "model", NULL);
> -	if (model == NULL)
> -		return 0;
> -	if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
> -	    strncmp(model, "iBook", strlen("iBook")) != 0) {
> -		of_node_put(dt);
> -	    	return 0;
> -	}
> -	of_node_put(dt);
> -
> -	pmu_blink_on.complete = 1;
> -	pmu_blink_off.complete = 1;
> -	spin_lock_init(&pmu_blink_lock);
> -	init_timer(&pmu_blink_timer);
> -	pmu_blink_timer.function = pmu_hd_blink_timeout;
> -
> -	return 1;
> -}
> -
> -#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
> -
> -/*
>   * N.B. this can't be an initfunc, because the media-bay task can
>   * call ide_[un]register at any time.
>   */
> @@ -1192,23 +1091,6 @@ pmac_ide_do_suspend(ide_hwif_t *hwif)
>  	pmif->timings[0] = 0;
>  	pmif->timings[1] = 0;
>  	
> -#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> -	/* Note: This code will be called for every hwif, thus we'll
> -	 * try several time to stop the LED blinker timer,  but that
> -	 * should be harmless
> -	 */
> -	if (pmu_ide_blink_enabled) {
> -		unsigned long flags;
> -
> -		/* Make sure we don't hit the PMU blink */
> -		spin_lock_irqsave(&pmu_blink_lock, flags);
> -		if (pmu_blink_ledstate)
> -			del_timer(&pmu_blink_timer);
> -		pmu_blink_ledstate = 0;
> -		spin_unlock_irqrestore(&pmu_blink_lock, flags);
> -	}
> -#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
> -
>  	disable_irq(pmif->irq);
>  
>  	/* The media bay will handle itself just fine */
> @@ -1376,13 +1258,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
>  		hwif->selectproc = pmac_ide_selectproc;
>  	hwif->speedproc = pmac_ide_tune_chipset;
>  
> -#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> -	pmu_ide_blink_enabled = pmu_hd_blink_init();
> -
> -	if (pmu_ide_blink_enabled)
> -		hwif->led_act = pmu_hd_kick_blink;
> -#endif
> -
>  	printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq %d\n",
>  	       hwif->index, model_name[pmif->kind], pmif->aapl_bus_id,
>  	       pmif->mediabay ? " (mediabay)" : "", hwif->irq);
> --- linux-2.6.orig/drivers/macintosh/Kconfig	2006-06-20 16:56:01.689161721 +0200
> +++ linux-2.6/drivers/macintosh/Kconfig	2006-06-20 16:56:03.219161721 +0200
> @@ -78,6 +78,17 @@ config ADB_PMU
>  	  this device; you should do so if your machine is one of those
>  	  mentioned above.
>  
> +config ADB_PMU_LED
> +	bool "Support for the Power/iBook front LED"
> +	depends on ADB_PMU
> +	select LEDS_CLASS
> +	help
> +	  Support the front LED on Power/iBooks as a generic LED that can
> +	  be triggered by any of the supported triggers. To get the
> +	  behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
> +	  and the ide-disk LED trigger and configure appropriately through
> +	  sysfs.
> +
>  config PMAC_SMU
>  	bool "Support for SMU  based PowerMacs"
>  	depends on PPC_PMAC64
> --- linux-2.6.orig/drivers/macintosh/Makefile	2006-06-20 16:56:01.729161721 +0200
> +++ linux-2.6/drivers/macintosh/Makefile	2006-06-21 11:49:11.698721123 +0200
> @@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID)	+= adbhid.o
>  obj-$(CONFIG_ANSLCD)		+= ans-lcd.o
>  
>  obj-$(CONFIG_ADB_PMU)		+= via-pmu.o
> +obj-$(CONFIG_ADB_PMU_LED)	+= via-pmu-led.o
>  obj-$(CONFIG_ADB_CUDA)		+= via-cuda.o
>  obj-$(CONFIG_PMAC_APM_EMU)	+= apm_emu.o
>  obj-$(CONFIG_PMAC_SMU)		+= smu.o
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6/drivers/macintosh/via-pmu-led.c	2006-06-21 12:09:50.778721123 +0200
> @@ -0,0 +1,144 @@
> +/*
> + * via-pmu LED class device
> + *
> + * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT.  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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> + *
> + */
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +#include <linux/adb.h>
> +#include <linux/pmu.h>
> +#include <asm/prom.h>
> +
> +static spinlock_t pmu_blink_lock;
> +static struct adb_request pmu_blink_req;
> +/* -1: no change, 0: request off, 1: request on */
> +static int requested_change;
> +static int sleeping;
> +
> +static void pmu_req_done(struct adb_request * req)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&pmu_blink_lock, flags);
> +	/* if someone requested a change in the meantime
> +	 * (we only see the last one which is fine)
> +	 * then apply it now */
> +	if (requested_change != -1 && !sleeping)
> +		pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
> +	/* reset requested change */
> +	requested_change = -1;
> +	spin_unlock_irqrestore(&pmu_blink_lock, flags);
> +}
> +
> +static void pmu_led_set(struct led_classdev *led_cdev,
> +			enum led_brightness brightness)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&pmu_blink_lock, flags);
> +	switch (brightness) {
> +	case LED_OFF:
> +		requested_change = 0;
> +		break;
> +	case LED_FULL:
> +		requested_change = 1;
> +		break;
> +	default:
> +		goto out;
> +		break;
> +	}
> +	/* if request isn't done, then don't do anything */
> +	if (pmu_blink_req.complete && !sleeping)
> +		pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
> + out:
> + 	spin_unlock_irqrestore(&pmu_blink_lock, flags);
> +}
> +
> +static struct led_classdev pmu_led = {
> +	.name = "pmu-front-led",
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> +	.default_trigger = "ide-disk",
> +#endif
> +	.brightness_set = pmu_led_set,
> +};
> +
> +#ifdef CONFIG_PM
> +static int pmu_led_sleep_call(struct pmu_sleep_notifier *self, int when)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&pmu_blink_lock, flags);
> +
> +	switch (when) {
> +	case PBOOK_SLEEP_REQUEST:
> +		sleeping = 1;
> +		break;
> +	case PBOOK_WAKE:
> +		sleeping = 0;
> +		break;
> +	default:
> +		/* do nothing */
> +		break;
> +	}
> +	spin_unlock_irqrestore(&pmu_blink_lock, flags);
> +
> +	return PBOOK_SLEEP_OK;
> +}
> +
> +static struct pmu_sleep_notifier via_pmu_led_sleep_notif = {
> +	.notifier_call = pmu_led_sleep_call,
> +};
> +#endif
> +
> +static int __init via_pmu_led_init(void)
> +{
> +	struct device_node *dt;
> +	const char *model;
> +
> +	/* only do this on keylargo based models */
> +	if (pmu_get_model() != PMU_KEYLARGO_BASED)
> +		return -ENODEV;
> +
> +	dt = of_find_node_by_path("/");
> +	if (dt == NULL)
> +		return -ENODEV;
> +	model = (const char *)get_property(dt, "model", NULL);
> +	if (model == NULL)
> +		return -ENODEV;
> +	if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
> +	    strncmp(model, "iBook", strlen("iBook")) != 0) {
> +		of_node_put(dt);
> +		/* ignore */
> +		return -ENODEV;
> +	}
> +	of_node_put(dt);
> +
> +	spin_lock_init(&pmu_blink_lock);
> +	/* no outstanding req */
> +	pmu_blink_req.complete = 1;
> +	pmu_blink_req.done = pmu_req_done;
> +#ifdef CONFIG_PM
> +	pmu_register_sleep_notifier(&via_pmu_led_sleep_notif);
> +#endif
> +	return led_classdev_register(NULL, &pmu_led);
> +}
> +
> +late_initcall(via_pmu_led_init);
> 

^ permalink raw reply

* Re: [linux-pm] windfarm got signal
From: Benjamin Herrenschmidt @ 2006-06-27  7:44 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Rafael J. Wysocki, linuxppc-dev list, linux-pm
In-Reply-To: <1150976092.16258.33.camel@johannes>

On Thu, 2006-06-22 at 13:34 +0200, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> 
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
> 
> Ah. The code is just in the wrong order:

The code should be

while (!kthread_should_stop()) {
  try_to_freeze();
  ...
  schedule_timeout_interruptible(...);
}

That is, I think we just don't care about the signal stuff.

Care to do a new patch ?

Cheers,
Ben.

^ permalink raw reply

* Re: Need help ragarding MPC8360 Kernel bootup failure - got solved
From: sudheer @ 2006-06-27  6:53 UTC (permalink / raw)
  To: linuxppc-embedded, dwh
In-Reply-To: <44A00EF4.6000109@gmail.com>

Hello All,

I got this problem sorted out.
I have changed the bootargs at u-boot to
setenv bootargs root=/dev/ram rw console=uart,io,0xfe004500
Now i could boot the linux and login.

Thanks & Regards
Sudheer



sudheer wrote:

>Hello all,
>
>I need help regarding the bootup of linux on MPC8360 MDS Board.
>
>After doing tftp the uImage from u-boot, with the bootm command  the 
>kernel gets uncompressed and stops there.
>The serial output from kernel could  not be seen.
>
>Source being used:
> uboot - U-Boot-1.1.3
> linux - Linux-2.6.11 supporting mpc8360epb.
>board - MPC8360 MDS
>
>The dump is below:
>
>U-Boot 1.1.3 (ppc83xx-20050315-dev) (Dec 14 2005 - 09:37:59) MPC83XX
>
>Clock configuration:
>  Coherent System Bus:  264 MHz
>  Core:                 528 MHz
>  QE:                   396 MHz
>  Local Bus Controller: 264 MHz
>  Local Bus:             66 MHz
>  DDR:                  264 MHz
>  DDR Secondary:        264 MHz
>  I2C:                  264 MHz
>CPU: MPC83xx, Rev: 20 at 528 MHz
>Board: Freescale MPC8360EPB
>I2C:   ready
>DRAM:
>   SDRAM on Local Bus: 64 MB
>   DDR RAM: 256 MB
>FLASH: 16 MB
>In:    serial
>Out:   serial
>Err:   serial
>Net:   FSL GETH0
>Hit any key to stop autoboot:  0
>=> printenv
>bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
>ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrramboot=setenv
>bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp
>$ramdiskaddr $ramdiskfile;tftp $loarnfsboot=setenv bootargs root=/dev/nfs
>rw nfsroot=$serverip:$rootpath
>ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrbootdelay=6
>baudrate=115200
>loads_echo=1
>ethaddr=00:04:9f:11:22:33
>eth1addr=00:E0:0C:00:7D:01
>hostname=unknown
>loadaddr=200000
>netdev=eth0
>consoledev=ttyS0
>ramdiskaddr=400000
>ramdiskfile=ramfs.83xx
>ethact=FSL GETH0
>filesize=2d030a
>fileaddr=20000
>gatewayip=192.168.3.1
>netmask=255.255.255.0
>serverip=192.168.3.81
>bootfile=/tftpboot/vmlinux.gz
>ipaddr=192.168.3.253
>stdin=serial
>stdout=serial
>stderr=serial
>
>Environment size: 1005/8188 bytes
>=> setenv bootargs console=ttyS1 root=/dev/ram
>=> tftp 200000 uImage_test
>Auto negotiating done
>switching to rgmii 100
>duplexity: full
>mac speed set to: 100
>Using FSL GETH0 device
>TFTP from server 192.168.3.81; our IP address is 192.168.3.253
>Filename 'uImage_test'.
>Load address: 0x200000
>Loading: #################################################################
>         #################################################################
>         #################################################################
>         #######
>done
>Bytes transferred = 1033098 (fc38a hex)
>=> bootm 200000
>## Booting image at 00200000 ...
>   Image Name:   Linux-2.6.11.12
>   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>   Data Size:    1033034 Bytes = 1008.8 kB
>   Load Address: 00000000
>   Entry Point:  00000000
>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... OK
>
> CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.00.0 | VT102 |      Offline
>
>------------
>After Uncompressing kernel, nothing comes onto the minicom.
>I have tried the console env in bootargs to ttyS0,  ttyS1, ttyCPM0, ttyCPM1, ttyUCC0. But could not succeed.
>
>Anyone Please help me in this regard.
>
>Thanks & Regards
>Sudheer
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>  
>

^ permalink raw reply

* Re: Re: Need help on ftp and telnet in my Ramdisk
From: Denny @ 2006-06-27  6:23 UTC (permalink / raw)
  To: lee revell; +Cc: de, linuxppc-embedded
In-Reply-To: <1151373673.26257.194.camel@mindpipe>

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

Yes, it is the root cause, thanks Lee!
 
Thanks & Regards!
- Denny
 
 
 

[-- Attachment #2: Type: text/html, Size: 611 bytes --]

^ permalink raw reply

* [PATCH] Assume we're on cpu 0 in early boot
From: Michael Ellerman @ 2006-06-27  4:00 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <787248AD-2E47-454E-9F56-7E5350A9F184@watson.ibm.com>

There's a small period early in boot where we don't know which cpu we're
running on. That's ok, except that it means we have no paca, or more
correctly that our paca pointer points somewhere random.

So that we can safely call things like smp_processor_id(), we need a paca,
so just assume we're on cpu 0. No code should _write_ to the paca before
we've set the correct one up.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---

 arch/powerpc/kernel/head_64.S |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: to-merge/arch/powerpc/kernel/head_64.S
===================================================================
--- to-merge.orig/arch/powerpc/kernel/head_64.S
+++ to-merge/arch/powerpc/kernel/head_64.S
@@ -1583,9 +1583,6 @@ _GLOBAL(__start_initialization_multiplat
 	/* Setup some critical 970 SPRs before switching MMU off */
 	bl	.__970_cpu_preinit
 
-	/* cpu # */
-	li	r24,0
-
 	/* Switch off MMU if not already */
 	LOAD_REG_IMMEDIATE(r4, .__after_prom_start - KERNELBASE)
 	add	r4,r4,r30
@@ -1908,6 +1905,13 @@ _STATIC(start_here_multiplatform)
 	bl	.__save_cpu_setup
 	sync
 
+	/* Assume we're on cpu 0 for now, we don't actually know yet.
+	 * The early setup code should not write to any paca fields until
+	 * after we've setup the correct paca. See early_setup() */
+	li	r24,0
+	li	r3,0
+	bl	.setup_paca
+
 	/* Do very early kernel initializations, including initial hash table,
 	 * stab and slb setup before we turn on relocation.	*/
 

^ permalink raw reply

* RE: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Zhang Wei-r63237 @ 2006-06-27  2:44 UTC (permalink / raw)
  To: Florian Boelstler, linuxppc-embedded

Hi, 

Please see inline comments.

Best Regards,
Zhang Wei

> -----Original Message-----
> From: 
> linuxppc-embedded-bounces+wei.zhang=freescale.com@ozlabs.org 
> [mailto:linuxppc-embedded-bounces+wei.zhang=freescale.com@ozla
> bs.org] On Behalf Of Florian Boelstler
> Sent: Monday, June 26, 2006 6:48 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
> 
> Hi,
> 
> I am currently working on a MPC8548-based development system.
> Linux kernel version is 2.6.11 with patches delivered from 
> Freescale (BSP MPC8548CDS 02/24/2006).
> 
> Kernel configuration contains a warning message for CONFIG_PEX:
> "This requires hardware modification to work correctly if 
> your CPU version < 2.0 and will break the PCI bus. [...]"
> 
> I was wondering whether enabling PCIe makes PCI bus 
> functionality unusable at all (including kernel functionality 
> for detecting devices behind a transparent PCI-to-PCI bridge).

The interrupts polarity of MPC8548 PCIe controller is reversed to PCI. That's an errata of MPC8548.
So you must rework to fix them. You can find the detail from user manual of bsp.

> 
> Our setup connects a transparent PLX8516 PCI-to-PCI bridge to 
> the PCIe port of the MPC8548 daughter board. Behind that 
> bridge is another PCIe capable device.
> MPC8548 is configured to run as PCIe host mode.
> 
> When trying to lookup the PCIe devices using lspci I can only 
> see the PPC itself and the bridge.
> However I cannot see the device(s) behind the bridge.

Yes, that's also an errata to MPC8548 PCIe controller.
Trying to apply below patch code:

diff -u -r1.1.1.2.2.3 ppc85xx_setup.c
--- arch/ppc/syslib/ppc85xx_setup.c	7 Apr 2006 08:57:50 -0000	1.1.1.2.2.3
+++ arch/ppc/syslib/ppc85xx_setup.c	27 Jun 2006 02:45:54 -0000
@@ -256,6 +256,7 @@
 {
 	volatile struct ccsr_pex *pex;
 	unsigned short temps;
+	unsigned int pribus;
 	bd_t *binfo = (bd_t *) __res;
 
 	pex = ioremap(binfo->bi_immr_base + MPC85xx_PEX_OFFSET,
@@ -265,6 +266,11 @@
 	temps |= PCI_COMMAND_SERR | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
 	early_write_config_word(hose, 0, 0, PCI_COMMAND, temps);
 	early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0x80);
+
+	/* PCIE Bus, Fix the MPC8548 host bridge's location to bus 0xFF. */
+	early_read_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, &pribus);
+	pribus = (pribus & 0xff000000) | (0xff) | (0x0 << 8) | (0xfe << 16);
+	early_write_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, pribus);
 
 	/* Disable all windows (except powar0 since its ignored) */
 	pex->pexowar1 = 0; 
> 
> Is there another method for detecting PCI(e) devices?
> Is "BSP MPC8548CDS 02/24/2006" the latest version 
> corresponding to that hardware?

Yes, it's the last version.

> 
> Thanks in advance,
> 
>    Florian
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

^ permalink raw reply

* Re: Need help on ftp and telnet in my Ramdisk
From: Lee Revell @ 2006-06-27  2:01 UTC (permalink / raw)
  To: Denny; +Cc: de, linuxppc-embedded
In-Reply-To: <44A08AEC.000113.30549@bj163app63.163.com>

On Tue, 2006-06-27 at 09:33 +0800, Denny wrote:
> bash-3.00# ftp 192.168.65.143
> ftp: ftp/tcp: unknown service
> bash-3.00# telnet 192.168.65.143
> telnet: telnet: bad port 

These sound like /etc/services is missing?

Consider adding strace to your build, it saves a LOT of guessing.

Lee

^ permalink raw reply

* Need help on adding a command to my ramdi sk
From: Denny @ 2006-06-27  1:38 UTC (permalink / raw)
  To: wd; +Cc: linuxppc-embedded
In-Reply-To: <44A08BA0.000020.01911@bj163app63.163.com>

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

 
 

Hi, 
 
   Since there is no "ldd" command in busybox1.1.3, so I copied it from ELDK4.0 to my bin,
but it didn't work, can anybody tell me how to add a new command to my ramdisk ?
 
bash-3.00# ldd /bin/ftp
sh: applet not found
bash-3.00# 
 
 
- Denny
 

[-- Attachment #2: Type: text/html, Size: 889 bytes --]

^ permalink raw reply

* Need help on adding a command to my ramdi sk
From: Denny @ 2006-06-27  1:36 UTC (permalink / raw)
  To: de; +Cc: linuxppc-embedded
In-Reply-To: <44A08AEC.000113.30549@bj163app63.163.com>

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

Hi, 
 
   Since there is no "ldd" command in busybox1.1.3, so I copied it from ELDK4.0 to my bin,
but it didn't work, can anybody tell me how to add a new command to my ramdisk ?
 
bash-3.00# ldd /bin/ftp
sh: applet not found
bash-3.00# 
 
 
- Denny
 
 
 

[-- Attachment #2: Type: text/html, Size: 876 bytes --]

^ permalink raw reply

* Need help on ftp and telnet in my Ramdisk
From: Denny @ 2006-06-27  1:33 UTC (permalink / raw)
  To: de; +Cc: linuxppc-embedded
In-Reply-To: <44A01925.9050100@ovro.caltech.edu>

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Hi,
 
   1. I copied the ftp and telnet commands to my /bin, and the needed library is also copied to my /lib, but they still don't work so far, can anybody tell me why, thanks!
 
 
logs:
...
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
init started:  BusyBox v1.1.3 (2006.06.23-09:32+0000) multi-call binary
Bad inittab entry: :reth0: link is up, 100 FDX
Starting pid 23, console /dev/ttyS1: '/bin/application'
Starting pid 24, console /dev/ttyS1: '/bin/bash'
### Application running ...
bash-3.00# ]
bash: ]: command not found
bash-3.00# 
bash-3.00# 
bash-3.00# 
bash-3.00# 
bash-3.00# ftp 192.168.65.143
ftp: ftp/tcp: unknown service
bash-3.00# telnet 192.168.65.143
telnet: telnet: bad port
Starting pid 29, console /dev/ttyS1: '/bin/application'
Starting pid 30, console /dev/ttyS1: '/bin/bash'
### Application running ...
Starting pid 33, console /dev/ttyS1: '/bin/bash'
Starting pid 32, console /dev/ttyS1: '/bin/application'
### Application running ...
bash-3.00# 
 
Thanks!
- Denny

[-- Attachment #2: Type: text/html, Size: 1803 bytes --]

^ permalink raw reply

* Need help on ftp and telnet in my Ramdisk
From: Denny @ 2006-06-27  1:39 UTC (permalink / raw)
  To: wd; +Cc: linuxppc-embedded
In-Reply-To: <44A08AEC.000113.30549@bj163app63.163.com>

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

 
 

Hi,
 
   1. I copied the ftp and telnet commands to my /bin, and the needed library is also copied to my /lib, but they still don't work so far, can anybody tell me why, thanks!
 
 
logs:
...
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
init started:  BusyBox v1.1.3 (2006.06.23-09:32+0000) multi-call binary
Bad inittab entry: :reth0: link is up, 100 FDX
Starting pid 23, console /dev/ttyS1: '/bin/application'
Starting pid 24, console /dev/ttyS1: '/bin/bash'
### Application running ...
bash-3.00# ]
bash: ]: command not found
bash-3.00# 
bash-3.00# 
bash-3.00# 
bash-3.00# 
bash-3.00# ftp 192.168.65.143
ftp: ftp/tcp: unknown service
bash-3.00# telnet 192.168.65.143
telnet: telnet: bad port
Starting pid 29, console /dev/ttyS1: '/bin/application'
Starting pid 30, console /dev/ttyS1: '/bin/bash'
### Application running ...
Starting pid 33, console /dev/ttyS1: '/bin/bash'
Starting pid 32, console /dev/ttyS1: '/bin/application'
### Application running ...
bash-3.00# 
 
Thanks!
- Denny
 

[-- Attachment #2: Type: text/html, Size: 1873 bytes --]

^ permalink raw reply

* Re: [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Andreas Schwab @ 2006-06-26 20:49 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel, netstar
In-Reply-To: <20060607130910.156412000@sipsolutions.net>

Johannes Berg <johannes@sipsolutions.net> writes:

> This patch removes from snd-powermac the code that check for the layout-id
> and instead adds code that makes it refuse loading when a layout-id property
> is present, nothing that snd-aoa should be used.

Can we get snd-powermac back as long as snd-aoa is lacking all those
features from snd-powermac?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply

* Re: zero-copy support on TSEC?
From: Andy Fleming @ 2006-06-26 19:56 UTC (permalink / raw)
  To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA9112796415019ED1C6@xmb-sjc-212.amer.cisco.com>


On Jun 26, 2006, at 13:26, Bizhan Gholikhamseh ((bgholikh)) wrote:

> Hi ALL,
> We have developed a custom board mother board based on
> MPC8541 processor running Linux 2.6.11.
>
> In our system, most of the ingress UDP packets  are retransmitted
> with one modification to data portion of the packet (one byte). As you
> see there are many copy overhead due to copy from system to userland
> and vise versa which has impacted our system performance.
>
> Is there a zero-copy support for TSEC
> to eliminate the buffer copy from kernel to userland and vise versa?


I'm not sure there's any way, at present, in Linux to avoid the user/ 
kernel copying.  You might want to ask on the netdev@vger.kernel.org  
list, though.

Andy

^ permalink raw reply

* [PATCH] powerpc: build fix for ppc32 with CONFIG_KEXEC
From: Haren Myneni @ 2006-06-26 19:14 UTC (permalink / raw)
  To: vgoyal
  Cc: linuxppc-dev, Fastboot mailing list, linux-kernel,
	Troy Benjegerdes, ellerman
In-Reply-To: <20060626135801.GC8985@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Vivek Goyal wrote:

>On Mon, Jun 26, 2006 at 01:31:28AM -0500, Troy Benjegerdes wrote:
>  
>
>>various things like 'reserve_crashkernel' are referenced, but only
>>exist in arch/powerpc/kernel/machine_kexec_64.c.
>>
>>    
>>
>
>I think for ppc32 the framework is present for kexec/kdump but nobody 
>is actively testing/maintaining it as of today.
>  
>
At present, even though kexec support is included for PPC32, I believe, 
it has been actively tested/maintained only on gamecube.

Michael, if you are OK with this patch, please send it to upstream.
Thanks
Haren

arch/powerpc/kernel/built-in.o(.init.text+0x1c98): In function 
`early_init_devtree':
: undefined reference to `reserve_crashkernel'
arch/powerpc/kernel/built-in.o(.init.text+0x1d90): In function 
`early_init_devtree':
: undefined reference to `overlaps_crashkernel'
 This patch will fix the above build errors on ppc32 with CONFIG_KEXEC.  
Both reserve_crashkernel() and overlaps_crashkernel() should be moved to 
machine_kexec.c() after the kdump support is included on ppc32.

Signed-off-by: Haren Myneni <haren@us.ibm.com>





>Thanks
>Vivek
>_______________________________________________
>fastboot mailing list
>fastboot@lists.osdl.org
>https://lists.osdl.org/mailman/listinfo/fastboot
>  
>


[-- Attachment #2: ppc32-kexec-build-fix.patch --]
[-- Type: text/x-patch, Size: 527 bytes --]

--- linux-2.6.17-git10/arch/powerpc/kernel/machine_kexec_32.c.orig	2006-06-26 05:33:51.000000000 -0700
+++ linux-2.6.17-git10/arch/powerpc/kernel/machine_kexec_32.c	2006-06-26 05:47:04.000000000 -0700
@@ -63,3 +63,16 @@ int default_machine_kexec_prepare(struct
 {
 	return 0;
 }
+
+/*
+ * FIXME: Move the following functions to machine_kexec.c after
+ * kdump support is included on ppc32.
+ */
+void __init reserve_crashkernel(void)
+{
+}
+
+int overlaps_crashkernel(unsigned long start, unsigned long size)
+{
+	return 0;
+}

^ permalink raw reply

* zero-copy support on TSEC?
From: Bizhan Gholikhamseh (bgholikh) @ 2006-06-26 18:26 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Hi ALL,
We have developed a custom board mother board based on
MPC8541 processor running Linux 2.6.11.
 
In our system, most of the ingress UDP packets  are retransmitted
with one modification to data portion of the packet (one byte). As you 
see there are many copy overhead due to copy from system to userland 
and vise versa which has impacted our system performance. 
 
Is there a zero-copy support for TSEC 
to eliminate the buffer copy from kernel to userland and vise versa?
 
Are there any other technique that we need to do to eliminate packet
coping?
 
Many thanks in advance,
Bizhan

[-- Attachment #2: Type: text/html, Size: 3018 bytes --]

^ permalink raw reply

* Re: Need help ragarding MPC8360 Kernel bootup failure
From: David Hawkins @ 2006-06-26 17:28 UTC (permalink / raw)
  To: sudheer; +Cc: linuxppc-embedded
In-Reply-To: <44A00EF4.6000109@gmail.com>



>  CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.00.0 | VT102 |      Offline

Your minicom is set to 115200, so your U-Boot must be using that,
but you'll need to tell Linux too, try:

console=ttyS0,115200

Dave

^ permalink raw reply

* Need help ragarding MPC8360 Kernel bootup failure
From: sudheer @ 2006-06-26 16:44 UTC (permalink / raw)
  To: linuxppc-embedded

Hello all,

I need help regarding the bootup of linux on MPC8360 MDS Board.

After doing tftp the uImage from u-boot, with the bootm command  the 
kernel gets uncompressed and stops there.
The serial output from kernel could  not be seen.

Source being used:
 uboot - U-Boot-1.1.3
 linux - Linux-2.6.11 supporting mpc8360epb.
board - MPC8360 MDS

The dump is below:

U-Boot 1.1.3 (ppc83xx-20050315-dev) (Dec 14 2005 - 09:37:59) MPC83XX

Clock configuration:
  Coherent System Bus:  264 MHz
  Core:                 528 MHz
  QE:                   396 MHz
  Local Bus Controller: 264 MHz
  Local Bus:             66 MHz
  DDR:                  264 MHz
  DDR Secondary:        264 MHz
  I2C:                  264 MHz
CPU: MPC83xx, Rev: 20 at 528 MHz
Board: Freescale MPC8360EPB
I2C:   ready
DRAM:
   SDRAM on Local Bus: 64 MB
   DDR RAM: 256 MB
FLASH: 16 MB
In:    serial
Out:   serial
Err:   serial
Net:   FSL GETH0
Hit any key to stop autoboot:  0
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrramboot=setenv
bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp
$ramdiskaddr $ramdiskfile;tftp $loarnfsboot=setenv bootargs root=/dev/nfs
rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrbootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:11:22:33
eth1addr=00:E0:0C:00:7D:01
hostname=unknown
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=ramfs.83xx
ethact=FSL GETH0
filesize=2d030a
fileaddr=20000
gatewayip=192.168.3.1
netmask=255.255.255.0
serverip=192.168.3.81
bootfile=/tftpboot/vmlinux.gz
ipaddr=192.168.3.253
stdin=serial
stdout=serial
stderr=serial

Environment size: 1005/8188 bytes
=> setenv bootargs console=ttyS1 root=/dev/ram
=> tftp 200000 uImage_test
Auto negotiating done
switching to rgmii 100
duplexity: full
mac speed set to: 100
Using FSL GETH0 device
TFTP from server 192.168.3.81; our IP address is 192.168.3.253
Filename 'uImage_test'.
Load address: 0x200000
Loading: #################################################################
         #################################################################
         #################################################################
         #######
done
Bytes transferred = 1033098 (fc38a hex)
=> bootm 200000
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.11.12
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1033034 Bytes = 1008.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

 CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.00.0 | VT102 |      Offline

------------
After Uncompressing kernel, nothing comes onto the minicom.
I have tried the console env in bootargs to ttyS0,  ttyS1, ttyCPM0, ttyCPM1, ttyUCC0. But could not succeed.

Anyone Please help me in this regard.

Thanks & Regards
Sudheer

^ permalink raw reply

* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-06-26 14:36 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20060626172546.6bc37173@vitb.ru.mvista.com>

Vitaly Bordug schrieb:
> From what I know, yes, 2/24 is the latest. But you'll need some tricks in order to utilize PCI-xp...

Thanks for your response. I will contact FSL.
May you share those tricks for PCIe utilization? :)

   Florian

^ permalink raw reply

* Re: [PATCH 6/6] [RFC] POWERPC: Add mpc8560 board support
From: Kumar Gala @ 2006-06-26 13:35 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060624211708.0d6039b2@localhost.localdomain>

[snip]

>>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
>>> Makefile
>>> index cef95b0..75dfe12 100644
>>> --- a/arch/powerpc/sysdev/Makefile
>>> +++ b/arch/powerpc/sysdev/Makefile
>>> @@ -12,3 +12,10 @@ obj-$(CONFIG_U3_DART)		+=
>>> dart_iommu.o obj-$(CONFIG_MMIO_NVRAM)	+= mmio_nvram.o
>>>  obj-$(CONFIG_PPC_83xx)		+= ipic.o
>>>  obj-$(CONFIG_FSL_SOC)		+= fsl_soc.o
>>> +
>>> +# Temporary hack until we have migrated to asm-powerpc
>>> +ifeq ($(ARCH),powerpc)
>>> +obj-$(CONFIG_CPM2)		+= cpm2_common.o cpm2_pic.o
>>> +endif
>>
>> See earlier comments about just building in arch/powerpc
>>
> Hrm, here I am not completely sure it's a good thing. The point is  
> that
> currently some OF-specific stuff is under construction to go into
> cpm2_common at least (for instance, getting rid of CPM_MAP_ADDR
> ioremap because the offset is available via oftree, and things like
> that).

If that's the case, make a duplicate of cpm2_common.c, however I dont  
think you need the ifeq... to make that work.

>>> +
>>> +#obj-$(CONFIG_CPM2)		+= cpm2/

what's in the cpm2 directory?

[snip]

>>> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
>>> fsl_soc.c
>>> index ceb5846..bab202d 100644
>>> --- a/arch/powerpc/sysdev/fsl_soc.c
>>> +++ b/arch/powerpc/sysdev/fsl_soc.c
>>> @@ -21,6 +21,8 @@ #include <linux/module.h>
>>>  #include <linux/device.h>
>>>  #include <linux/platform_device.h>
>>>  #include <linux/fsl_devices.h>
>>> +#include <linux/fs_enet_pd.h>
>>> +#include <linux/fs_uart_pd.h>
>>>
>>>  #include <asm/system.h>
>>>  #include <asm/atomic.h>
>>> @@ -30,6 +32,10 @@ #include <asm/prom.h>
>>>  #include <sysdev/fsl_soc.h>
>>>  #include <mm/mmu_decl.h>
>>>
>>> +#ifdef CONFIG_CPM2
>>> +#include <asm/cpm2.h>
>>> +#endif
>>> +
>>>  static phys_addr_t immrbase = -1;
>>>
>>>  phys_addr_t get_immrbase(void)
>>> @@ -43,7 +49,9 @@ phys_addr_t get_immrbase(void)
>>>  	if (soc) {
>>>  		unsigned int size;
>>>  		void *prop = get_property(soc, "reg", &size);
>>> -		immrbase = of_translate_address(soc, prop);
>>> +
>>> +		if (prop)
>>> +			immrbase = of_translate_address(soc, prop);
>>>  		of_node_put(soc);
>>>  	};
>>>
>>> @@ -51,7 +59,79 @@ phys_addr_t get_immrbase(void)
>>>  }
>>>
>>>  EXPORT_SYMBOL(get_immrbase);
>>> +
>>> +static u32 brgfreq = -1;
>>> +
>>> +u32 get_brgfreq(void)
>>> +{
>>> +	struct device_node *node;
>>> +
>>> +	if (brgfreq != -1)
>>> +		return brgfreq;
>>> +
>>> +	node = of_find_node_by_type(NULL, "serial");
>>> +	if (node) {
>>> +		unsigned int size;
>>> +		unsigned int *prop = (unsigned
>>> int*)get_property(node, "clock- frequency", &size);
>>> +
>>> +		if (prop)
>>> +			brgfreq = *prop;
>>> +		of_node_put(node);
>>> +	};
>>> +
>>> +	return brgfreq;
>>> +}
>>
>> These seems broken on a system w/both CPM & 8250 style uarts.
>>
> Yeah, missed that.
>
>>> +
>>> +EXPORT_SYMBOL(get_brgfreq);
>>> +
>>> +static u32 fs_baudrate = -1;
>>> +
>>> +u32 get_baudrate(void)
>>> +{
>>> +	struct device_node *node;
>>>
>>> +	if (fs_baudrate != -1)
>>> +		return fs_baudrate;
>>> +
>>> +	node = of_find_node_by_type(NULL, "serial");
>>> +	if (node) {
>>> +		unsigned int size;
>>> +		unsigned int *prop = (unsigned
>>> int*)get_property(node, "current- speed", &size);
>>> +
>>> +		if (prop)
>>> +			fs_baudrate = *prop;
>>> +		of_node_put(node);
>>> +	};
>>> +
>>> +	return fs_baudrate;
>>> +}
>>> +
>>> +EXPORT_SYMBOL(get_baudrate);
>>> +
>>> +static u32 intfreq = -1;
>>> +
>>> +u32 get_intfreq(void)
>>> +{
>>> +	struct device_node *node;
>>> +
>>> +	if (intfreq != -1)
>>> +		return intfreq;
>>> +
>>> +	node = of_find_node_by_type(NULL, "cpu");
>>> +	if (node) {
>>> +		unsigned int size;
>>> +		unsigned int *prop = (unsigned
>>> int*)get_property(node, "clock- frequency", &size);
>>> +		if (prop)
>>> +			intfreq = *prop;
>>> +		of_node_put(node);
>>> +	}
>>> +
>>> +	return intfreq;
>>> +}
>>> +
>>> +EXPORT_SYMBOL(get_intfreq);
>>> +
>>
>> Don't we have something that reports "clock-frequency" elsewhere?
>>
>
> If yes, I haven't found... Mind pointing where to look at?

ppc_proc_freq in kernel/time.c

>>> +
>>>  static int __init gfar_mdio_of_init(void)
>>>  {
>>>  	struct device_node *np;
>>> @@ -491,3 +571,211 @@ err:
>>>  }
>>>
>>>  arch_initcall(fsl_usb_dr_of_init);
>>> +
>>> +static const char *fcc_regs = "fcc_regs";
>>> +static const char *fcc_regs_c = "fcc_regs_c";
>>> +static const char *fcc_pram = "fcc_pram";
>>> +static char bus_id[9][BUS_ID_SIZE];
>>> +
>>> +static int __init fs_enet_of_init(void)
>>> +{
>>> +	struct device_node *np;
>>> +	unsigned int i;
>>> +	struct platform_device *fs_enet_dev;
>>> +	struct resource res;
>>> +	int ret;
>>> +
>>> +	for (np = NULL, i = 0;
>>> +	     (np = of_find_compatible_node(np, "network",
>>> "fs_enet")) != NULL;
>>> +	     i++) {
>>> +		struct resource r[4];
>>> +		struct device_node *phy, *mdio;
>>> +		struct fs_platform_info fs_enet_data;
>>> +		unsigned int *id, *phy_addr;
>>> +		void *mac_addr;
>>> +		phandle *ph;
>>> +		char *model;
>>> +
>>> +		memset(r, 0, sizeof(r));
>>> +		memset(&fs_enet_data, 0, sizeof(fs_enet_data));
>>> +
>>> +		ret = of_address_to_resource(np, 0, &r[0]);
>>> +		if (ret)
>>> +			goto err;
>>> +		r[0].name = fcc_regs;
>>> +
>>> +		ret = of_address_to_resource(np, 1, &r[1]);
>>> +		if (ret)
>>> +			goto err;
>>> +		r[1].name = fcc_pram;
>>> +
>>> +		ret = of_address_to_resource(np, 2, &r[2]);
>>> +		if (ret)
>>> +			goto err;
>>> +		r[2].name = fcc_regs_c;
>>> +
>>> +		r[3].start = np->intrs[0].line;
>>> +		r[3].end = np->intrs[0].line;
>>> +		r[3].flags = IORESOURCE_IRQ;
>>> +
>>> +		fs_enet_dev =
>>> +		    platform_device_register_simple("fsl-cpm-fcc",
>>> i, &r[0], 4); +
>>> +		if (IS_ERR(fs_enet_dev)) {
>>> +			ret = PTR_ERR(fs_enet_dev);
>>> +			goto err;
>>> +		}
>>> +
>>> +		model = get_property(np, "model", NULL);
>>> +		if (model == NULL) {
>>> +			ret = -ENODEV;
>>> +			goto unreg;
>>> +		}
>>> +
>>> +		mac_addr = get_property(np, "mac-address", NULL);
>>> +		memcpy(fs_enet_data.macaddr, mac_addr, 6);
>>> +
>>> +		ph = (phandle *) get_property(np, "phy-handle",
>>> NULL);
>>> +		phy = of_find_node_by_phandle(*ph);
>>> +
>>> +		if (phy == NULL) {
>>> +			ret = -ENODEV;
>>> +			goto unreg;
>>> +		}
>>> +
>>> +		phy_addr = (u32 *) get_property(phy, "reg", NULL);
>>> +		fs_enet_data.phy_addr = *phy_addr;
>>> +
>>> +		id = (u32 *) get_property(np, "device-id", NULL);
>>> +		fs_enet_data.fs_no = *id;
>>> +
>>> +		mdio = of_get_parent(phy);
>>> +                ret = of_address_to_resource(mdio, 0, &res);
>>> +                if (ret) {
>>> +                        of_node_put(phy);
>>> +                        of_node_put(mdio);
>>> +                        goto unreg;
>>> +                }
>>> +
>>> +		switch (*id) {
>>> +		case fsid_fcc1:
>>> +			fs_enet_data.mem_offset = FCC1_MEM_OFFSET,
>>> +			snprintf((char*)&bus_id[2], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> +			fs_enet_data.bus_id = (char*)&bus_id[2];
>>> +			fs_enet_data.cp_page = CPM_CR_FCC1_PAGE;
>>> +			fs_enet_data.cp_block = CPM_CR_FCC1_SBLOCK;
>>> +			break;
>>> +		case fsid_fcc2:
>>> +			fs_enet_data.mem_offset = FCC2_MEM_OFFSET,
>>> +			snprintf((char*)&bus_id[3], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> +			fs_enet_data.bus_id = (char*)&bus_id[3];
>>> +			fs_enet_data.cp_page = CPM_CR_FCC2_PAGE;
>>> +			fs_enet_data.cp_block = CPM_CR_FCC2_SBLOCK;
>>> +			break;
>>> +		case fsid_fcc3:
>>> +			fs_enet_data.mem_offset = FCC3_MEM_OFFSET,
>>> +			snprintf((char*)&bus_id[4], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> +			fs_enet_data.bus_id = (char*)&bus_id[4];
>>> +			fs_enet_data.cp_page = CPM_CR_FCC3_PAGE;
>>> +			fs_enet_data.cp_block = CPM_CR_FCC3_SBLOCK;
>>> +			break;
>>> +		}
>>
>> this looks like a lot of effort to just encode a single integer (1,
>> 2, 3) and then lookup the other information based on it.
>>
>
> Not sure I am following what is suggested here. Could it be elaborated
> a little bit ?

I saying all you need to store is the fact that its a FCC and its  
number 1, 2, 3... after which we can have some table in cpm2_common.c  
that provides back cp_page, cp_block based on type and number.   
Encoding it fs_enet_data is just a duplication.

>>> +
>>> +		if (strstr(model, "FCC")) {
>>> +			fs_enet_data.dpram_offset =
>>> (u32)cpm2_immr->im_dprambase;
>>> +			fs_enet_data.rx_ring = 32;
>>> +			fs_enet_data.tx_ring = 32;
>>> +			fs_enet_data.rx_copybreak = 240;
>>> +			fs_enet_data.use_napi = 0;
>>> +			fs_enet_data.napi_weight = 17;
>>> +		}
>>> +
>>> +		of_node_put(phy);
>>> +		of_node_put(mdio);
>>> +
>>> +		ret = platform_device_add_data(fs_enet_dev,
>>> &fs_enet_data,
>>> +					     sizeof(struct
>>> +
>>> fs_platform_info));
>>> +		if (ret)
>>> +			goto unreg;
>>> +	}
>>> +	return 0;
>>> +
>>> +unreg:
>>> +	platform_device_unregister(fs_enet_dev);
>>> +err:
>>> +	return ret;
>>> +}
>>> +
>>> +arch_initcall(fs_enet_of_init);
>>> +
>>> +static const char *scc_regs = "regs";
>>> +static const char *scc_pram = "pram";
>>> +
>>> +static int __init cpm_uart_of_init(void)
>>> +{
>>> +	struct device_node *np;
>>> +	unsigned int i;
>>> +	struct platform_device *cpm_uart_dev;
>>> +	int ret;
>>> +
>>> +
>>> +	for (np = NULL, i = 0;
>>> +	     (np = of_find_compatible_node(np, "serial",
>>> "cpm_uart")) != NULL;
>>> +	     i++) {
>>> +		struct resource r[3];
>>> +		struct fs_uart_platform_info cpm_uart_data;
>>> +		int *id;
>>> +
>>> +		memset(r, 0, sizeof(r));
>>> +		memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
>>> +
>>> +		ret = of_address_to_resource(np, 0, &r[0]);
>>> +		if (ret)
>>> +			goto err;
>>> +
>>> +		r[0].name = scc_regs;
>>> +
>>> +		ret = of_address_to_resource(np, 1, &r[1]);
>>> +		if (ret)
>>> +			goto err;
>>> +		r[1].name = scc_pram;
>>> +
>>> +		r[2].start = np->intrs[0].line;
>>> +		r[2].end = np->intrs[0].line;
>>> +		r[2].flags = IORESOURCE_IRQ;
>>> +
>>> +		cpm_uart_dev =
>>> +
>>> platform_device_register_simple("fsl-cpm-scc:uart", i, &r [0], 3);
>>> +
>>> +		if (IS_ERR(cpm_uart_dev)) {
>>> +			ret = PTR_ERR(cpm_uart_dev);
>>> +			goto err;
>>> +		}
>>> +
>>> +		id = get_property(np, "device-id", NULL);
>>> +		cpm_uart_data.fs_no = *id;
>>> +		cpm_uart_data.uart_clk = get_intfreq();
>>> +
>>> +		cpm_uart_data.tx_num_fifo = 4;
>>> +		cpm_uart_data.tx_buf_size = 32;
>>> +		cpm_uart_data.rx_num_fifo = 4;
>>> +		cpm_uart_data.rx_buf_size = 32;
>>> +
>>> +		ret =
>>> +		    platform_device_add_data(cpm_uart_dev,
>>> &cpm_uart_data,
>>> +					     sizeof(struct
>>> +
>>> fs_uart_platform_info));
>>> +		if (ret)
>>> +			goto unreg;
>>> +	}
>>> +
>>> +	return 0;
>>> +
>>> +unreg:
>>> +	platform_device_unregister(cpm_uart_dev);
>>> +err:
>>> +	return ret;
>>> +}
>>> +
>>> +arch_initcall(cpm_uart_of_init);
>>> diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
>>> index f6a7ff0..8e6840b 100644
>>> --- a/include/asm-ppc/cpm2.h
>>> +++ b/include/asm-ppc/cpm2.h
>>> @@ -1186,7 +1186,7 @@ #define PC3_DIRC1	(PC3_TXDAT)
>>>  #define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
>>>  #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
>>>  #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
>>> -#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
>>> +#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
>>>
>>>  #endif /* __CPM2__ */
>>>  #endif /* __KERNEL__ */
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox