* Re: [PATCH] convert powermac ide blink to new led infrastructure
From: Johannes Berg @ 2006-06-27 17:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Richard Purdie
In-Reply-To: <1151394629.2350.64.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
> 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 ?
I don't know, Richard? But yeah, I can do that too.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Johannes Berg @ 2006-06-27 17:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, alsa-devel, netstar
In-Reply-To: <jey7vjiqwv.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Mon, 2006-06-26 at 22:49 +0200, Andreas Schwab wrote:
> Can we get snd-powermac back as long as snd-aoa is lacking all those
> features from snd-powermac?
I'll be fixing it next week after an exam on Friday, or if I don't go to
Nuremburg next week (4h hacking on train :) ) then the week after.
Until then, you can just revert that patch locally.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-06-27 16:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306D93192@zch01exm40.ap.freescale.net>
Hi,
Zhang Wei-r63237 schrieb:
> 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. :)
We did the hardware fix described in the BSP user's manual to make PCIe
work (according to the manual section 2.1, step 3).
I.e.
1) removed R193 and R194 on the carrier card (rev 1.2)
2) removed RN1 on the CPU daughter card
2a) connected pad3 of RN1 to pin3 of U12 (IRQ0)
2b) connected pad2 of RN1 to pin4 of U12 (IRQ1)
Does this fix the interrupt polarity problem (as well)?
We applied the provided kernel patch as well.
IMHO that patch just moves the local PCIe root-complex "out-of-space" so
no detection of that one occurs any more.
This is what actually happens when "lspci" is run.
However we still don't see any devices behind the PCIe switch (e.g. a
transparent PLX8516). It seems that the enumeration process (traversing
through the bus hierarchy) in the kernel is somehow disabled.
Bottom line: Only one device accessible at all on the PCIe port.
Any further ideas?
Thanks,
Florian
^ permalink raw reply
* Re: 2.6.17-mm2
From: Martin J. Bligh @ 2006-06-27 15:37 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Andrew Morton, linuxppc64-dev, Linux Kernel Mailing List,
Martin J. Bligh
In-Reply-To: <449FF3A2.8010907@mbligh.org>
Martin J. Bligh wrote:
> Martin J. Bligh wrote:
>
>> Panic on PPC64. I'm guessing it's the same as the i386 panics I sent
>> you yesterday, just more cryptic ;-) But for the record ...
>>
>> http://test.kernel.org/abat/37737/debug/console.log
>>
>> cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0]
>> pc: c0000000000c6a34: .s_show+0x178/0x364
>> lr: c0000000000c696c: .s_show+0xb0/0x364
>> sp: c0000000f99f7b40
>> msr: 8000000000001032
>> dar: fd528000
>> dsisr: 40000000
>> current = 0xc0000000f23e0000
>> paca = 0xc00000000046e300
>> pid = 17653, comm = cp
>> enter ? for help
>>
>
> Eeek, this is definitely an intermittent thing. I was trawling older
> results, and it shows up (on PPC only) in 2.6.17-git10, so it's not
> just an -mm thing ;-(
OK, still happens in -mm3, though in a different workload now. I also
get a new panic, that's maybe related but more informative
cpu 0x0: Vector: 700 (Program Check) at [c0000000024938b0]
pc: c0000000000c3218: .free_block+0xe4/0x240
lr: c0000000000c3514: .drain_array+0xf4/0x170
sp: c000000002493b30
msr: 8000000000021032
current = 0xc0000000025457f0
paca = 0xc0000000004f9f00
pid = 14, comm = events/0
kernel BUG in list_del at include/linux/list.h:160!
Plus one with an actual backtrace from PPC64 that looks more like the
i386 ones
SMP NR_CPUS=32 NUMA
Modules linked in:
NIP: C0000000000A311C LR: C0000000000A30D4 CTR: C0000000000A3024
REGS: c0000007725b38d0 TRAP: 0300 Not tainted (2.6.17-mm3-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 28224424 XER: 00000000
DAR: 000000077BCC6180, DSISR: 0000000040000000
TASK = c00000002fc74670[29812] 'cp' THREAD: c0000007725b0000 CPU: 2
GPR00: 0000000000000000 C0000007725B3B50 C00000000063B828 C00000001E303EC0
GPR04: 0000000000000010 0000000000000000 0000000000000000 FFFFFFFFFFFFFFFD
GPR08: 0000000000000001 0000000000000000 000000077BCC6180 0000000000000000
GPR12: 0000000000000000 C00000000051FF80 0000000000000000 0000000000000001
GPR16: 0000000000000000 0000000000000004 0000000000020000 0000000000000000
GPR20: 0000000000000000 0000000000000000 C0000007759F9D00 0000000000000000
GPR24: 0000000000000E42 0000000000000000 000000000000474A C00000001E30F300
GPR28: 0000000000000000 0000000000000000 C000000000537288 C00000001E303E80
NIP [C0000000000A311C] .s_show+0xf8/0x364
LR [C0000000000A30D4] .s_show+0xb0/0x364
Call Trace:
[C0000007725B3B50] [C0000000000A3334] .s_show+0x310/0x364 (unreliable)
[C0000007725B3C20] [C0000000000D5E84] .seq_read+0x2f4/0x450
[C0000007725B3D00] [C0000000000AADF8] .vfs_read+0xe0/0x1b4
[C0000007725B3D90] [C0000000000AAFD4] .sys_read+0x54/0x98
[C0000007725B3E30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump:
3b180001 7c004a78 79290020 7c0bfe70 7f5a4a14 7d600278 7c005850 54000ffe
7c094038 2c090000 41820008 ebbe80b0 <e96a0000> 2fab0000 419e0008 7c005a2c
^ permalink raw reply
* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Andreas Schwab @ 2006-06-27 15:32 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Johannes Berg, alsa-devel, netstar
In-Reply-To: <s5hac7yvfhe.wl%tiwai@suse.de>
Takashi Iwai <tiwai@suse.de> writes:
> At Mon, 26 Jun 2006 22:49:04 +0200,
> Andreas Schwab wrote:
>>
>> 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?
>
> What functions are missing?
Sound on PowerMac7,2, DRC on TAS, probably more.
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: [PATCH] Remove extra local_bh_disable/enable from arch do_softirq
From: Martin Schwidefsky @ 2006-06-27 11:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, mingo, linux-kernel
In-Reply-To: <17566.32236.368906.227113@cargo.ozlabs.ibm.com>
On Sun, 2006-06-25 at 22:13 +1000, Paul Mackerras 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.
Nod, Heiko stumbled over that one as well as he ported the lock
validator patch. Moving the account_system_vtime call is the correct
solution.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Takashi Iwai @ 2006-06-27 14:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Johannes Berg, alsa-devel, netstar
In-Reply-To: <jey7vjiqwv.fsf@sykes.suse.de>
At Mon, 26 Jun 2006 22:49:04 +0200,
Andreas Schwab wrote:
>
> 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?
What functions are missing?
Takashi
^ permalink raw reply
* RE: How to search in this mailing-list?
From: Steven Blakeslee @ 2006-06-27 13:34 UTC (permalink / raw)
To: Stephen Cheng, linuxppc-embedded
=20
=09
> This is maybe a bit silly, but I really don't know:=20
> How to search using some key words in this mailing-list?=20
Go to google and do a site search
example
site:ozlabs.org/pipermail/linuxppc-embedded/ 440EP
=09
=09
^ permalink raw reply
* RE: How to search in this mailing-list?
From: Derycke, Johan @ 2006-06-27 13:40 UTC (permalink / raw)
To: Stephen Cheng, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
hi,
put this google, replace searchstring with whatever you are searching for:
searchstring site:ozlabs.org/pipermail
br,
Johan
_____
From: linuxppc-embedded-bounces+johan.derycke=barco.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+johan.derycke=barco.com@ozlabs.org] On
Behalf Of Stephen Cheng
Sent: dinsdag 27 juni 2006 15:24
To: linuxppc-embedded@ozlabs.org
Subject: How to search in this mailing-list?
hi ALL,
This is maybe a bit silly, but I really don't know:
How to search using some key words in this mailing-list?
Thanks & Best Regards,
Steven C.
- - - - - - - DISCLAIMER- - - - - - - -
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this message and/or
attachments is strictly prohibited. The company accepts no liability for any
damage caused by any virus transmitted by this email. Furthermore, the
company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays. If you have
received this message in error, please contact the sender and delete the
message. Thank you.
[-- Attachment #2: Type: text/html, Size: 3137 bytes --]
^ permalink raw reply
* Re: How to search in this mailing-list?
From: Florian Boelstler @ 2006-06-27 13:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF10AE4861.E394E791-ON4825719A.004971D0-4825719A.004991C4@celestica.com>
Stephen Cheng schrieb:
> This is maybe a bit silly, but I really don't know:
> How to search using some key words in this mailing-list?
You may use one of the options found here:
http://dir.gmane.org/gmane.linux.ports.ppc.embedded
Florian
^ permalink raw reply
* How to search in this mailing-list?
From: Stephen Cheng @ 2006-06-27 13:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1133.1151372366.11183.linuxppc-embedded@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 151 bytes --]
hi ALL,
This is maybe a bit silly, but I really don't know:
How to search using some key words in this mailing-list?
Thanks & Best Regards,
Steven C.
[-- Attachment #2: Type: text/html, Size: 336 bytes --]
^ permalink raw reply
* [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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox