* Re: [JOB] Senior Embedded Linux Video Engineer
From: Christoph Hellwig @ 2006-07-14 8:07 UTC (permalink / raw)
To: Davenport, Richard; +Cc: linuxppc-dev
In-Reply-To: <44FA7A8E32709444A9078DA2E1C027FD0489B9E6@USCSCMSC8.na.entroot.biz>
On Thu, Jul 13, 2006 at 04:33:06PM -0400, Davenport, Richard wrote:
> Senior Embedded Linux Video Engineer
>
>
>
> Responsible for the technical leadership in design and development of embedded OS features for Cisco's next generation Audio/Video application which will change the entire video conferencing industry.
Please stop spamming people, especially on public mailinglists.
^ permalink raw reply
* Failed to bring up the kernel on PPC440GP
From: Denny @ 2006-07-14 7:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
The system hangs, after it print "## Transferring control to Linux (at address 00000000) ..."
I dump the log buf, but still can't find the root cause, can anyone give some advice, thanks.
dump:
BDI>md 0x012c5c4
0012c5c4 : 20322e36 2e313420 08726f6f 73696f6e 2.6.14 .roosion
0012c5d4 : 20322e36 2e313420 08726f6f 74406c6f 2.6.14 .root@lo
0012c5e4 : 63616c68 6f73742e 6c6f6361 6c646f6d calhost.localdom
0012c5f4 : 61696e29 20286763 63207665 5820454c ain) (gcc veX EL
0012c604 : 444b2034 2e302034 2e302e30 5820454c DK 4.0 4.0.0X EL
0012c614 : 444b2034 2e302034 2e302e30 2031b43a DK 4.0 4.0.0 1.:
0012c624 : 35353a32 30200353 54203230 2031b43a 55:20 .ST 20 1.:
0012c634 : 35353a32 30200353 54203230 6e452063 55:20 .ST 20nE c
0012c644 : 6865636b 20696e20 6b65726e 6e452063 heck in kernnE c
0012c654 : 6865636b 20696e20 6b65726e 656c206d heck in kernel m
0012c664 : 6f64652e 0a3c343e 504c4230 3a204245 ode..<4>PLB0: BE
0012c674 : 41523d30 78303030 30303030 32306563 AR=0x000000020ec
0012c684 : 30303030 36204143 523d2020 30783962 00006 ACR= 0x9b
0012c694 : 30303030 30302042 4553523d 20307830 000000 BESR= 0x0
0012c6a4 : 63303030 3030300a 3c343e50 4f42303a c000000.<4>POB0:
0012c6b4 : 20424541 523d3078 30303030 30303030 BEAR=0x00000000
BDI>
Thanks in advance!
- Denny
[-- Attachment #2: Type: text/html, Size: 2165 bytes --]
^ permalink raw reply
* Re: Re: Want to port a linux in V4-FX
From: Grant Likely @ 2006-07-14 5:28 UTC (permalink / raw)
To: 杨强浩, linuxppc-embedded list
In-Reply-To: <200607141248212381692@neusoft.com>
T24gNy8xMy8wNiwg0e7Hv7rGIDx5YW5nLXFoQG5ldXNvZnQuY29tPiB3cm90ZToKPiBHcmFudCBM
aWtlbHksCj4KPiBQbHMgdGVsbCBtZSB0aGUgbWFpbGJveCBvZiAgbGludXhwcGMtZW1iZWRkZWQg
bWFpbGluZyBsaXN0LCB0aGVuIEkgY2FuIGNjIHRvIGl0LgoKbGludXhwcGMtZW1iZWRkZWRAb3ps
YWJzLm9yZwoKUGVvcGxlIGZhciBzbWFydGVyIHRoYW4gbWUgaGFuZyBvdXQgdGhlcmUuICBJdCdz
IGEgYmV0dGVyIHdheSB0byBnZXQgYW5zd2Vycy4KCmcuCgotLSAKR3JhbnQgTGlrZWx5LCBCLlNj
LiBQLkVuZy4KU2VjcmV0IExhYiBUZWNobm9sb2dpZXMgTHRkLgpncmFudC5saWtlbHlAc2VjcmV0
bGFiLmNhCig0MDMpIDM5OS0wMTk1Cg==
^ permalink raw reply
* [PATCH] iseries: Move iommu_table_cb into platforms/iseries
From: Michael Ellerman @ 2006-07-14 4:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20060713075223.D1FC767BCD@ozlabs.org>
Although we pass the address of an iommu_table_cb to HvCallXm_getTceTableParms,
we don't actually need the structure definition anywhere except in the
iseries iommu code, so move the struct in there.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/iommu.c | 17 +++++++++++++++++
include/asm-powerpc/iseries/hv_call_xm.h | 17 -----------------
2 files changed, 17 insertions(+), 17 deletions(-)
Index: to-merge/arch/powerpc/platforms/iseries/iommu.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/iommu.c
+++ to-merge/arch/powerpc/platforms/iseries/iommu.c
@@ -88,6 +88,23 @@ static void tce_free_iSeries(struct iomm
}
/*
+ * Structure passed to HvCallXm_getTceTableParms
+ */
+struct iommu_table_cb {
+ unsigned long itc_busno; /* Bus number for this tce table */
+ unsigned long itc_start; /* Will be NULL for secondary */
+ unsigned long itc_totalsize; /* Size (in pages) of whole table */
+ unsigned long itc_offset; /* Index into real tce table of the
+ start of our section */
+ unsigned long itc_size; /* Size (in pages) of our section */
+ unsigned long itc_index; /* Index of this tce table */
+ unsigned short itc_maxtables; /* Max num of tables for partition */
+ unsigned char itc_virtbus; /* Flag to indicate virtual bus */
+ unsigned char itc_slotno; /* IOA Tce Slot Index */
+ unsigned char itc_rsvd[4];
+};
+
+/*
* Call Hv with the architected data structure to get TCE table info.
* info. Put the returned data into the Linux representation of the
* TCE table data.
Index: to-merge/include/asm-powerpc/iseries/hv_call_xm.h
===================================================================
--- to-merge.orig/include/asm-powerpc/iseries/hv_call_xm.h
+++ to-merge/include/asm-powerpc/iseries/hv_call_xm.h
@@ -16,23 +16,6 @@
#define HvCallXmSetTce HvCallXm + 11
#define HvCallXmSetTces HvCallXm + 13
-/*
- * Structure passed to HvCallXm_getTceTableParms
- */
-struct iommu_table_cb {
- unsigned long itc_busno; /* Bus number for this tce table */
- unsigned long itc_start; /* Will be NULL for secondary */
- unsigned long itc_totalsize; /* Size (in pages) of whole table */
- unsigned long itc_offset; /* Index into real tce table of the
- start of our section */
- unsigned long itc_size; /* Size (in pages) of our section */
- unsigned long itc_index; /* Index of this tce table */
- unsigned short itc_maxtables; /* Max num of tables for partition */
- unsigned char itc_virtbus; /* Flag to indicate virtual bus */
- unsigned char itc_slotno; /* IOA Tce Slot Index */
- unsigned char itc_rsvd[4];
-};
-
static inline void HvCallXm_getTceTableParms(u64 cb)
{
HvCall1(HvCallXmGetTceTableParms, cb);
^ permalink raw reply
* JTAG PPC info ?
From: David H. Lynch Jr. @ 2006-07-13 23:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1152782030.3534.27.camel@petra.pixel>
Has anyone not covered by non-disclosure deciphered the JTAG codes
for the PowerPC ?
I have a situation using a custom JTAG interface that is looking to
impliment host side PPC debugging. JTAG access and manipulation of most
all other JTAG devices on the target is working.
Right now the problem is deciphering the JTAG commands etc to the
PPC itself.
Ria Roy wrote:
> Hi,
>
> Does anyone know if Macriagor's mpDemon is capable of debugging the
> linux kernel via the JTAG interface.
>
> Thanks in advance,
> Ria
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Xilinx hard TEMAC
From: David H. Lynch Jr. @ 2006-07-13 23:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44B671D2.304@gmail.com>
I am trying to get the Xilinx TEMAC working. I am getting an education
in Xilinx, TEMAC's, PHY's, ... in the process.
The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
It is my understanding that this is the TEMAC builtin to the FX parts,
not one that is created in the FPGA.
Is anyone else working to support that configuration ? I think that is
basically the same as the GRSD TEMAC.
Is it sane to try to adapt the soft TEMAC patch from the list ?
I have a driver that works under uCos as a starting point. It initially
appeared to use basically the same xilinx_edk code that the linux temac
driver patch that has been the subject of a number of messages uses. But
on deeper inspection that dependence appears to be very shallow - mostly
using the edk macros to read the PHY and registers in the MAC.
Am I correct that the TEMAC patch floating arround is not for that TEMAC ?
I am also trying to digest the paternity of the TEMAC. Is the basic
programming of the hard TEMAC and the IP TEMAC the same ? i.e. does the
fact that the both have TEMAC in their name actually express some
commonality ? TEMAC means Tri-Mode EMAC - does that mean there is some
commonality with the IBM EMAC ?
I have a driver in the works that is based on the working uCos code I
mentioned, as well as I think the pcnet32 driver as a very basic template.
I seem to got the PHY portions working, but then addapted to the
separate PHY driver model with the MAC driver providing routines to
access the PHY registers. I may have that working. I think I have DCR
access to the MAC registers working. I am just starting on getting the
TX and RX code working.
I actually started trying to get the posted TEMAC patch working but that
quickly went off the rails - I presumed because the hard and soft
TEMAC's are just too different, or because the xilinx_edk really does
not support the hard TEMAC.
The xilinx_edk based driver seems incredibly complex. I think the OS
independent xilinx_edk incurrs a high cost in obscurity - but I am not
looking to gore someone elses ox, just solve my problem.
If the edk based driver is going to make it into the kernel, and
somebody who understands better than I beleives that it is reasonable to
adapt that to support the hard TEMAC too, I am willing to pursue that
approach.
Regardless. I need to get a driver working, and I am not looking to
duplicate effort.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Knowing kernel module load address (insmod hasn't -m)
From: Ben Warren @ 2006-07-13 21:42 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200607132327.58708.antonio.dibacco@aruba.it>
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
/proc/modules support is in 2.4, but the other stuff is 2.6 only (I
believe somewhere around 2.6.11 or so?) You should be able to 'insmod
-m' in 2.4. You may need to reconfigure busybox or use a non-busybox
'insmod', though.
cheers,
Ben
On Thu, 2006-07-13 at 23:27 +0200, Antonio Di Bacco wrote:
> > cat /proc/modules
> >
> > If you want more detailed information about a module (locations
> > of .text, .data, .bss etc), enable CONFIG_KALLSYMS in your kernel and
>
> Does this option exist in kernel 2.4 too? I didn't find it!
>
> Thank you,
> Antonio.
[-- Attachment #2: Type: text/html, Size: 1067 bytes --]
^ permalink raw reply
* Re: some problems on the SystemACE driver.
From: Ming Liu @ 2006-07-13 21:41 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
In-Reply-To: <44B671D2.304@gmail.com>
Dear Ameet,
>1. Which TEMAC patch are you using?
>(http://source.mvista.com/~ank/paulus-powerpc/20060309/ppc32_xilinx_edk_temac.patch)
There are five patches in the directory 20060309 whose address is listed
above by you. I applied all of them in my system, because without any there
will be problems.
>2. After applying the patch, is the driver getting compiled directly
>without having to select it via "make menuconfig"?
No. there is an option named "xilinx 10/100/1000 Mbit TEMAC support" in the
menuconfig. I must select it and then compile the kernel.
>3. I don't see a Makefile in the drivers/net/xilinx_temac/ folder?
I have checked. In my kernel, there is the Makefile. I don't know why this
happened to you.
Let me describe the detailed process I did. First, download the kernel
2.6.17.1 (or 2.6.16-rc5). Then apply the five patches for Temac.(If I use
2.6.17.1, I need to upgrade some files manually. For 2.6.16, there is no
problem.) And then apply the patch for SystemACE. Also copy and replace the
xparameters_ml403.h by my own file generated by EDK. Then make menuconfig,
selecting both Temac and SystemACE and other basic options. Then make dep
and make zImage. During this process, I need to modify some little problems
which are about the inclusion of some header files, or specify some lib
inclusion directories instead. Then that problem appears. There are some
main points: 1. configured for ml403 board. 2.both Temac and SystemACE are
selected. 3. 5 patches for Temac and 1 patch for SystemACE. 4. linux
version is 2.6.17 or 2.6.16. I really have no idea why this still happens
after your modification. So I have to ask you again.
>Ofcourse, I can work my way to compile the driver. But is there any doc.
>present explaining this?
Sorry that there is no doc to explain this. I just did following the
procedure described above. I am totally lost. The strange thing is, when I
select only one of these two drivers, no problem, but if both, problem.
By the way, I noticed that in the address where I get your patch, there is
also a patch called linuxppc-2.6.17.1-sysace-1.0.patch which is much larger
than the 1.1 one. I needn't apply the 1.0 one, right?
Thanks for your hard work. Hopefully we can solve the problem.
Regards
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn
^ permalink raw reply
* Re: Knowing kernel module load address (insmod hasn't -m)
From: Antonio Di Bacco @ 2006-07-13 21:27 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1152824648.5238.12.camel@saruman.qstreams.net>
> cat /proc/modules
>
> If you want more detailed information about a module (locations
> of .text, .data, .bss etc), enable CONFIG_KALLSYMS in your kernel and
Does this option exist in kernel 2.4 too? I didn't find it!
Thank you,
Antonio.
^ permalink raw reply
* Re: Knowing kernel module load address (insmod hasn't -m)
From: Ben Warren @ 2006-07-13 21:04 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200607132238.11177.antonio.dibacco@aruba.it>
cat /proc/modules
If you want more detailed information about a module (locations
of .text, .data, .bss etc), enable CONFIG_KALLSYMS in your kernel and
you'll see lots of goodness in the /sys/module/<YOUR MODULE>/sections
directory.
Do yourself a favor and browse http://lwn.net/Articles/driver-porting/
where Jon Corbet has written a really good series of articles about
modules and device drivers in the 2.6 kernel.
cheers,
Ben
On Thu, 2006-07-13 at 22:38 +0200, Antonio Di Bacco wrote:
> Hi all,
>
> where can be read at which memory address a module was loaded. I use the bb
> insmod that doesn't provide -m option.
>
> Bye,
> Antonio.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [JOB] Senior Embedded Linux Video Engineer
From: Davenport, Richard @ 2006-07-13 20:51 UTC (permalink / raw)
To: linuxppc-embedded
Senior Embedded Linux Video Engineer=20
=20
Responsible for the technical leadership in design and development of =
embedded OS features for Cisco's next generation Audio/Video application =
which will change the entire video conferencing industry.
=20
Please check out these links for an overview of the project:
=20
http://www.humanproductivitylab.com/archive_blogs/2006/03/26/ciscos_chann=
el_partners_should_1.php
=20
http://www.msnbc.msn.com/id/11768174/site/newsweek/
=20
Requirements:
=B7 Strong technical skills with an emphasis on Embedded Linux, =
Operating System interfaces, and Platform Software and Services.=20
=B7 5-7 years of embedded C programming.
=B7 4 years Linux experience with at least 2 years embedded =
Linux.
=B7 Linux expertise on PowerPC architecture.
=B7 Experience in Linux internals such as file systems, device =
drivers, network interfaces.
=B7 Thorough understanding of Linux utilities such as system =
logging and run time options.
=B7 Experience in building BSP packaging
=B7 Familiar with gcc/gdb toolchain=20
=B7 Excellent written and verbal communication skills
=B7 Permanent US work authorization or transferable H1b with a =
minimum of two years remaining eligibility.
=20
Desired Skills/Experience:=20
=B7 Experience in providing Technical and team leadership=20
=B7 Experience in GPL compliance=20
=B7 Build systems, tool chain, executable/library structures and =
makefile=20
=B7 Background in a startup or dynamic working environment
=B7 Strong understanding of operating system Kernel internals=20
=B7 Experience with writing/debugging BSP's for Linux=20
=B7 Background in VoIP Audio/Video systems=20
=20
Typically requires MSEE/CS combined with 5-7 years of related =
experience, or
BSEE/CS combined with 7-10+ yrs related experience.
=20
Opportunity is in San Jose, CA. (Relocation assistance is not available)
=20
If interested, please respond with a copy of your resume and the best =
numbers and times for a follow-up phone conversation.
=20
Thank you,
=20
Richard Davenport
Recruiter=20
Cisco Recruiting Team
(888) 329-3480 or (501) 351-7396
richarddavenport@spherion.com
^ permalink raw reply
* [JOB] Senior Embedded Linux Video Engineer
From: Davenport, Richard @ 2006-07-13 20:33 UTC (permalink / raw)
To: linuxppc-dev
Senior Embedded Linux Video Engineer=20
=20
Responsible for the technical leadership in design and development of =
embedded OS features for Cisco's next generation Audio/Video application =
which will change the entire video conferencing industry.
=20
Please check out these links for an overview of the project:
=20
http://www.humanproductivitylab.com/archive_blogs/2006/03/26/ciscos_chann=
el_partners_should_1.php
=20
http://www.msnbc.msn.com/id/11768174/site/newsweek/
=20
Requirements:
=B7 Strong technical skills with an emphasis on Embedded Linux, =
Operating System interfaces, and Platform Software and Services.=20
=B7 5-7 years of embedded C programming.
=B7 4 years Linux experience with at least 2 years embedded =
Linux.
=B7 Linux expertise on PowerPC architecture.
=B7 Experience in Linux internals such as file systems, device =
drivers, network interfaces.
=B7 Thorough understanding of Linux utilities such as system =
logging and run time options.
=B7 Experience in building BSP packaging
=B7 Familiar with gcc/gdb toolchain=20
=B7 Excellent written and verbal communication skills
=B7 Permanent US work authorization or transferable H1b with a =
minimum of two years remaining eligibility.
=20
Desired Skills/Experience:=20
=B7 Experience in providing Technical and team leadership=20
=B7 Experience in GPL compliance=20
=B7 Build systems, tool chain, executable/library structures and =
makefile=20
=B7 Background in a startup or dynamic working environment
=B7 Strong understanding of operating system Kernel internals=20
=B7 Experience with writing/debugging BSP's for Linux=20
=B7 Background in VoIP Audio/Video systems=20
=20
Typically requires MSEE/CS combined with 5-7 years of related =
experience, or
BSEE/CS combined with 7-10+ yrs related experience.
=20
Opportunity is in San Jose, CA. (Relocation assistance is not available)
=20
If interested, please respond with a copy of your resume and the best =
numbers and times for a follow-up phone conversation.
=20
Thank you,
=20
Richard Davenport
Recruiter=20
Cisco Recruiting Team
(888) 329-3480 or (501) 351-7396
richarddavenport@spherion.com <mailto:richarddavenport@spherion.com>=20
^ permalink raw reply
* Knowing kernel module load address (insmod hasn't -m)
From: Antonio Di Bacco @ 2006-07-13 20:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
where can be read at which memory address a module was loaded. I use the bb
insmod that doesn't provide -m option.
Bye,
Antonio.
^ permalink raw reply
* Re: new IRQ stuff : some details?
From: Benjamin Herrenschmidt @ 2006-07-13 19:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060713220628.54c2912d@vitb.ru.mvista.com>
On Thu, 2006-07-13 at 22:06 +0400, Vitaly Bordug wrote:
> Hi Ben,
>
> As your irq rewrite touched mainstream, I am wondering about some details/directions to move fw and
> update the boards up to it. Currently, the irq numbers are messed (since the board has 2 Int controllers), and I am assuming some touch to devicetree is needed, but not sure what exactly.
>
>
> Sorry if it have been brought up somewhere...
It certainly needs some documentation update... I'm travelling at the
moment, but soon. Discussion is welcome :)
Ben.
^ permalink raw reply
* Re: Maple platform - adding graphics to IBM PIBS firmware
From: Benjamin Herrenschmidt @ 2006-07-13 19:43 UTC (permalink / raw)
To: jf simon; +Cc: linuxppc-dev
In-Reply-To: <44B4D2A4.7090204@yahoo.fr>
> I was (naively) thinking that if I could access the legacy VGA register
> set, I could set the graphic card to text mode and use the graphic
> screen as a alphanumeric console, until linux soft boots the graphic
> card . Do you think this is doable? I haven't been able to locate that
> VGA register set yet.
The legacy VGA operations also require the card to be fully initialized
by the BIOS. In addition to that, there is an issue with using VGA text
mode on machines using the CPC925 bridge as it doesn't have a legacy
memory window: It doesn't have a facility to generate PCI or HT memory
cycles in the low addresses required for VGA.
You can still hack-around in a somewhat card-specific way using the main
memory apperture and doing your onw interleaving of characters and
attributes but it's dodgy.
In any case, you still need the card to be initialized.
Ben.
^ permalink raw reply
* Re: [PATCH] reorg RTAS delay code
From: Nathan Lynch @ 2006-07-13 18:20 UTC (permalink / raw)
To: John Rose; +Cc: External List, Paul Mackerras
In-Reply-To: <1149543108.17307.6.camel@sinatra.austin.ibm.com>
Hi folks-
John Rose wrote:
> This patch attempts to handle RTAS "busy" return codes in a more simple
> and consistent manner. Typical callers of RTAS shouldn't have to
> manage wait times and delay calls.
>
> This patch also changes the kernel to use msleep() rather than udelay()
> when a runtime delay is necessary. This will avoid CPU soft lockups
> for extended delay conditions.
...
> +/* For an RTAS busy status code, perform the hinted delay. */
> +unsigned int rtas_busy_delay(int status)
> +{
> + unsigned int ms;
>
> - /* Use microseconds for reasonable accuracy */
> - for (ms = 1; order > 0; order--)
> - ms *= 10;
> + might_sleep();
> + ms = rtas_busy_delay_time(status);
> + if (ms)
> + msleep(ms);
>
> - return ms;
> + return ms;
> }
So I managed to test this with cpu hotplug recently and the
might_sleep warning triggers in the cpu offline path (I had to
reconstruct this from xmon due to the kernel crashing later on for a
different reason, so it might be a little off):
BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:463.
in_atomic():1, irqs_disabled():1.
Call Trace:
[C0000000AAD379A0] [C000000000010ADC] .show_stack+0x68/0x1b4 (unreliable)
[C0000000AAD37A50] [C000000000050C98] .__might_sleep+0xd0/0xec
[C0000000AAD37AE0] [C00000000001DF5C] .rtas_busy_delay+0x20/0x54
[C0000000AAD37B70] [C00000000001E2D0] .rtas_set_indicator+0x70/0xd4
[C0000000AAD37C10] [C0000000000491C8] .xics_migrate_irqs_away+0x78/0x228
[C0000000AAD37CD0] [C000000000047C14] .pSeries_cpu_disable+0x98/0xb4
[C0000000AAD37D50] [C000000000029A5C] .__cpu_disable+0x4c/0x60
[C0000000AAD37DC0] [C000000000080834] .take_cpu_down+0x10/0x38
[C0000000AAD37E40] [C00000000008D1C0] .do_stop+0x198/0x248
[C0000000AAD37EE0] [C000000000078124] .kthread+0x124/0x174
[C0000000AAD37F90] [C000000000026568] .kernel_thread+0x4c/0x68
As it turns out, set-indicator is not allowed to return a busy delay
in this context, so we're actually safe here. Maybe we need an
rtas_set_indicator_fast which could take that into account, e.g.
int rtas_set_indicator_fast(int indicator, int index, int new_value)
{
int token = rtas_token("set-indicator");
int rc;
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
WARN_ON(rc == -2 || rc >= 9000 || rc <= 9005);
if (rc < 0)
return rtas_error_rc(rc);
return rc;
}
^ permalink raw reply
* new IRQ stuff : some details?
From: Vitaly Bordug @ 2006-07-13 18:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben,
As your irq rewrite touched mainstream, I am wondering about some details/directions to move fw and
update the boards up to it. Currently, the irq numbers are messed (since the board has 2 Int controllers), and I am assuming some touch to devicetree is needed, but not sure what exactly.
Sorry if it have been brought up somewhere...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: cpm_uart_port_map not initialised before serial console setup
From: Vitaly Bordug @ 2006-07-13 17:05 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200607131655.35899.laurent.pinchart@tbox.biz>
On Thu, 13 Jul 2006 16:55:35 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> while trying to use SCC1 as a serial console, I found a bug in the cpm_uart
> driver.
>
> The cpm_uart_port_map table is initialised by cpm_uart_count() which is called
> in cpm_uart_init() at module_init() time. cpm_uart_console_setup(), called at
> console_initcall() time, accesses cpm_uart_port_map, leading to a crash when
> using any serial port except SMC1 as the serial console.
>
> I attached a very simple patch to fix the problem, but it might be subject to
> race conditions. Could anyone familiar with the cpm_uart driver have a look
> at it ?
>
Ugh, you're right.
But I think we need to finally get rid of the stupid count/port_map creation based on #ifdefs.
I'll have a look at it immediately as time permits
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: some problems on the SystemACE driver.
From: Ameet Patil @ 2006-07-13 16:16 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F40A48564C0A5B30AB0DCCB2690@phx.gbl>
Hi Ming,
Instead of bouncing emails to and forth, lets do all at one place:
1. Which TEMAC patch are you using?
(http://source.mvista.com/~ank/paulus-powerpc/20060309/ppc32_xilinx_edk_temac.patch)
2. After applying the patch, is the driver getting compiled directly
without having to select it via "make menuconfig"?
3. I don't see a Makefile in the drivers/net/xilinx_temac/ folder?
Ofcourse, I can work my way to compile the driver. But is there any doc.
present explaining this?
-Ameet
Ming Liu wrote:
> Dear Ameet,
> Unfortunately, I tried the new patch and the same problem happened. Here
> is the information:
>
> CC drivers/xilinx_edk/xdmav2_simple.o
> LD drivers/xilinx_edk/built-in.o
> LD drivers/built-in.o
> drivers/xilinx_edk/built-in.o(.sdata+0x0): In function `XAssert':
> drivers/xilinx_edk/xbasic_types.c:105: multiple definition of
> `XWaitInAssert'
> drivers/block/built-in.o(.sdata+0x4):drivers/block/rd.c:103: first
> defined here
> drivers/xilinx_edk/built-in.o(.sbss+0x4): In function `XAssert':
> drivers/xilinx_edk/xbasic_types.c:105: multiple definition of
> `XAssertStatus'
> drivers/block/built-in.o(.sbss+0x3c):include/asm-generic/bitops/non-atomic.h:108
>
>
> : first defined here
> drivers/xilinx_edk/built-in.o(.text+0x44): In function
> `XAssertSetCallback':
> drivers/xilinx_edk/xbasic_types.c:134: multiple definition of
> `XAssertSetCallbac
> k'
> drivers/block/built-in.o(.text+0x38d0):drivers/block/xilinx_sysace/xbasic_types.
>
>
> c:117: first defined here
> drivers/xilinx_edk/built-in.o(.text+0x0): In function `XAssert':
> drivers/xilinx_edk/xbasic_types.c:105: multiple definition of `XAssert'
> drivers/block/built-in.o(.text+0x388c):drivers/block/xilinx_sysace/xbasic_types.
>
>
> c:87: first defined here
> drivers/xilinx_edk/built-in.o(.text+0x50): In function `XNullHandler':
> drivers/xilinx_edk/xbasic_types.c:153: multiple definition of
> `XNullHandler'
> drivers/block/built-in.o(.text+0x38dc):drivers/block/xilinx_sysace/xbasic_types.
>
>
> c:136: first defined here
> make[1]: *** [drivers/built-in.o] Error 1
> make: *** [drivers] Error 2
>
> This time I only tried on linux 2.6.17.1 version. Please check again and
> modify it. Thank you.
>
> Regards
> Ming
>
>
>> From: Ameet Patil <ammubhai@gmail.com>
>> To: Ming Liu <eemingliu@hotmail.com>
>> CC: akonovalov@ru.mvista.com, linuxppc-embedded@ozlabs.org
>> Subject: Re: some problems on the SystemACE driver.
>> Date: Wed, 12 Jul 2006 19:22:08 +0100
>>
>> Hi Ming,
>> Thanks for testing the driver patch! The errors you get when
>> compiling both - SysAce and TEMAC are reasonable. My ignorance or call
>> it me being lazy. I recollect now... I was also working on the Xilinx
>> Ethernet driver and forgot to cleanup that code before creating the
>> patch for the SysAce driver. Thus, it so happens that code for the
>> ethernet driver in my patch also gets compiled along with the TEMAC. I
>> have deleted the unnecessary code files and updated the patch (name
>> changed). Find the new one here:
>> https://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.1.patch
>>
>
>>
>> Let me know if it works for you now?
>>
>> -Ameet
>>
>> Ming Liu wrote:
>> > Dear Ameet (and Andrei),
>> > I have tested the new patch for SystemACE driver. With respect to the
>> > single SystemACE driver, it works well. I can boot my linux in ML403
>> > board. (I tried both 2.6.16-rc5 and 2.6.17.1 versions) So first
>> > congratulations and thanks for your hard work!
>> >
>> > However, when I tried to implemented Temac (with and without SystemACE.
>> > TWO conditions.), some errors happened. Here is the compilation
>> > information:
>> >
>> > CC init/do_mounts.o
>> > LD init/mounts.o
>> > CC init/initramfs.o
>> > LD init/built-in.o
>> > LD .tmp_vmlinux1
>> > drivers/built-in.o(.sdata+0x2c): multiple definition of `XWaitInAssert'
>> > arch/ppc/platforms/4xx/built-in.o(.sdata+0x0): first defined here
>> > drivers/built-in.o(.text+0x3e480): In function
> `XPacketFifoV200a_WriteDre':
>> > : multiple definition of `XPacketFifoV200a_WriteDre'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1b14): first defined here
>> > drivers/built-in.o(.text+0x3e158): In function
> `XPacketFifoV200a_SelfTest':
>> > : multiple definition of `XPacketFifoV200a_SelfTest'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x17ec): first defined here
>> > drivers/built-in.o(.sbss+0x18c): multiple definition of `XAssertStatus'
>> > arch/ppc/platforms/4xx/built-in.o(.sbss+0x8): first defined here
>> > drivers/built-in.o(.text+0x3e798): In function
> `XPacketFifoV200a_L0Write':
>> > : multiple definition of `XPacketFifoV200a_L0Write'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1e2c): first defined here
>> > drivers/built-in.o(.text+0x3e280): In function `XPacketFifoV200a_Read':
>> > : multiple definition of `XPacketFifoV200a_Read'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1914): first defined here
>> > drivers/built-in.o(.text+0x3e55c): In function
> `XPacketFifoV200a_L0Read':
>> > : multiple definition of `XPacketFifoV200a_L0Read'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1bf0): first defined here
>> > drivers/built-in.o(.text+0x3e380): In function
> `XPacketFifoV200a_Write':
>> > : multiple definition of `XPacketFifoV200a_Write'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1a14): first defined here
>> > drivers/built-in.o(.text+0x3e0cc): In function `XAssertSetCallback':
>> > : multiple definition of `XAssertSetCallback'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x44): first defined here
>> > drivers/built-in.o(.text+0x3e9fc): In function
>> > `XPacketFifoV200a_L0WriteDre':
>> > : multiple definition of `XPacketFifoV200a_L0WriteDre'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x2090): first defined here
>> > drivers/built-in.o(.text+0x3e0dc): In function
>> > `XPacketFifoV200a_Initialize':
>> > : multiple definition of `XPacketFifoV200a_Initialize'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x1770): first defined here
>> > drivers/built-in.o(.text+0x3e088): In function `XAssert':
>> > : multiple definition of `XAssert'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x0): first defined here
>> > drivers/built-in.o(.text+0x3e0d8): In function `XNullHandler':
>> > : multiple definition of `XNullHandler'
>> > arch/ppc/platforms/4xx/built-in.o(.text+0x50): first defined here
>> > make: *** [.tmp_vmlinux1] Error 1
>> >
>> > It looks like that your patch affect some symbols which are used by
>> > Temac. (When I use the old patch for SystemACE, there is no problem
> like
>> > this if I only choose Temac. ) So let's find out the problem together.
>> > Also, I don't know if this is a problem from SystemACE or Temac , I
>> > would like to invite Andrei to look at this altogether. If any
>> > suggestion, please feel free to announce. Thanks for both your help.
>> > Regards
>> > Ming
>> >
>> >
>> >
>> >> From: Ameet Patil <ammubhai@gmail.com>
>> >> To: Ming Liu <eemingliu@hotmail.com>
>> >> CC: linuxppc-embedded@ozlabs.org
>> >> Subject: Re: some problems on the SystemACE driver.
>> >> Date: Wed, 12 Jul 2006 10:54:13 +0100
>> >>
>> >> Hi Ming,
>> >>
>> >> > I heard that you have tested this driver. Have you got this problem?
>> >> > Why there are so many strange problems for me while you have tested
>> >> > without problem?
>> >>
>> >> Yes, that is right! When I say... I have tested - "it really means I
>> >> have tested". So what's the problem? It works for me but not you? The
>> >> obvious difference: mine is a ML300 configuration and yours ML403.
>> >>
>> >> There were some files which unknowing were made dependant on ML300
>> >> target. I have now made them compile for both targets. It should work
>> >> fine for you now (Hopefully!). Download the updated patch from the
> same
>> >> location.
>> >>
>> >>
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17_sysace.patch
>
>
>> >>
>> >
>> >>
>> >> Since I don't have ML403 board, theres no way I can test this patch on
>> >> it. I rely on you in doing this... and thanks for letting me know the
>> >> issues.
>> >>
>> >> WARNING: There might be more issues. :-)
>> >>
>> >> Please DONOT hesitate to raise any issues with the driver. I am more
>> >> than happy to fix them.
>> >>
>> >> -Ameet
>> >>
>> >> Ming Liu wrote:
>> >> > Dear Ameet,
>> >> > Sorry to bother you again but I am totally confused on the systemACE
>> >> > driver. First let me show you the problem.
>> >> >
>> >> > 1. I downloaded the linux kernel of 2.6.17.1, also the patch for
>> >> > SystemACE driver. Applied the patch to the kernel. Replaced the
>> >> > xparameters_ml403.h with the generated file xparameters_ml300.h from
>> >> > Xilinx EDK. Make menuconfig, make dep and make zImage. Then the
> error
>> >> > shows like this:
>> >> >
>> >> > drivers/block/xilinx_sysace/xsysace.c:120:6: warning:
>> >> > "XPAR_XSYSACE_MEM_WIDTH" is not defined
>> >> > drivers/block/xilinx_sysace/xsysace.c: In function
>> > `XSysAce_LookupConfig':
>> >> > drivers/block/xilinx_sysace/xsysace.c:366: error:
>> >> > `XPAR_XSYSACE_NUM_INSTANCES' undeclared (first use in this function)
>> >> > drivers/block/xilinx_sysace/xsysace.c:366: error: (Each undeclared
>> >> > identifier is reported only once
>> >> > drivers/block/xilinx_sysace/xsysace.c:366: error: for each function
> it
>> >> > appears in.)
>> >> > make[3]: *** [drivers/block/xilinx_sysace/xsysace.o] Error 1
>> >> > make[2]: *** [drivers/block/xilinx_sysace] Error 2
>> >> > make[1]: *** [drivers/block] Error 2
>> >> > make: *** [drivers] Error 2
>> >> >
>> >> > I think this is because of the no inclusion of the xparameters
> header
>> >> > file. So I change #include "xparameters.h" into #include "
>> >> >
>> >
> /home/mingliu/linux-2.6.17.1/arch/ppc/platforms/4xx/xparameters/xparameters.h"
>
>
>> >
>> >
>> >> > in the files of xsysace.c and xsysace_g.c, using the full address to
>> >> > specify the header file. In fact, this is not a serious problem and
> it
>> >> > often happens. But, after the modification, another problem
> happened:
>> >> > GEN .version
>> >> > CHK include/linux/compile.h
>> >> > UPD include/linux/compile.h
>> >> > CC init/version.o
>> >> > LD init/built-in.o
>> >> > LD .tmp_vmlinux1
>> >> > drivers/built-in.o(.text+0x2234a): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x2235e): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x22364): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssert'
>> >> > drivers/built-in.o(.text+0x22372): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x2237a): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x22394): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssert'
>> >> > drivers/built-in.o(.text+0x223a2): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x223aa): In function `XSysAce_GetCfgAddr':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x22cd6): In function `XSysAce_Initialize':
>> >> > : undefined reference to `XAssertStatus'
>> >> > drivers/built-in.o(.text+0x22cdc): In function `XSysAce_Initialize':
>> >> > : undefined reference to `XAssert'
>> >> > drivers/built-in.o(.text+0x22cea): In function `XSysAce_Initialize':
>> >> > : undefined reference to `XAssertStatus'
>> >> >
>> >> > ......( a long information to say that undefined reference to the
>> >> > XAssert things.)
>> >> >
>> >> > Also, I tried this in the kernel 2.6.16-rc5. (In fact I prefer this
>> >> > version because the temac driver is for this version. ) The same
>> > problem
>> >> > happened. I checked the source code. The problem happened in the
> file
>> >> > driver/block/xilinx_sysace/adapter.c, etc. Also, the XAssert things
> are
>> >> > defined in the file
> arch/ppc/platforms/4xx/xilinx_ocp/xbasic_types.c.
>> >> > (In 2.6.16 kernel, it is also defined in
>> >> > driver/xilinx_edk/xbasic_types.c. There are two copies of this file.
> )
>> > I
>> >> > think the problem is, the systemACE files cannot link together with
> the
>> >> > xbasic_types.c file.
>> >> > I heard that you have tested this driver. Have you got this problem?
>> > Why
>> >> > there are so many strange problems for me while you have tested
> without
>> >> > problem? Without the CF card, I cannot try the Temac driver and my
> work
>> >> > is totally blocked. So I have to ask for your suggestion. Really
>> > anxious
>> >> > for your useful guidance. Thanks a lot!!!!!!
>> >> >
>> >> > Regards
>> >> > Ming
>> >> >
>> >> > _________________________________________________________________
>> >> > 与联机的朋友进行交流，请使用 MSN Messenger:
>> > http://messenger.msn.com/cn
>> >> >
>> >
>> > _________________________________________________________________
>> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
>> >
>
> _________________________________________________________________
> 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
>
^ permalink raw reply
* RE: Linux on Virtex4
From: Rick Moleres @ 2006-07-13 15:46 UTC (permalink / raw)
To: Aleš Gorkič, linuxppc-embedded
Ales,
Hmmmm... No, I've not done anything with the Avnet MM board. I may =
have responded to somebody who was working with that board on this list. =
We work a lot with PLB TEMAC and MV Linux, but do very little with GSRD =
(it's a reference design that's not officially supported through the =
EDK). On the surface, I don't think I can help much here, but feel free =
to directly send me a more detailed email and maybe I can point you to =
someone who can help.
-Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On =
Behalf Of Ale=B9 Gorkic
Sent: Wednesday, July 12, 2006 7:13 AM
To: linuxppc-embedded@ozlabs.org
Subject: re:Linux on Virtex4
Hi Rick,
I saw on linuxppc-embedded at ozlabs.org that you are trying to port (or =
better you did) monta vista linux to Avnet's V4FX Mini-Module. I will =
try to deal with the same thing. My design is basically the same: all =
features of MM incorporated in CoreConnect style architecture. I also =
tried with Multi Port Memory Controller (MPMC2) and ported (memory =
works, but for LAN I still need phy datasheet) the Gigabit System =
Reference Design (GSRD2) to Mini-Module.
By using the MPMC2 memory core you can connect PPC directly to memory =
using two PLBs (data and instruction separated). This way you might =
solve the CPU cache errata. The problem with MPMC2 is that it consumes A =
LOT of BRAM and logic. I tried to build a full featured system, but =
V4FX12 lacks logic for the purpose.
Is there a way that you can help me with running MV linux on my system?
Cheers,
Ales Gorkic
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* cpm_uart_port_map not initialised before serial console setup
From: Laurent Pinchart @ 2006-07-13 14:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
Hi everybody,
while trying to use SCC1 as a serial console, I found a bug in the cpm_uart
driver.
The cpm_uart_port_map table is initialised by cpm_uart_count() which is called
in cpm_uart_init() at module_init() time. cpm_uart_console_setup(), called at
console_initcall() time, accesses cpm_uart_port_map, leading to a crash when
using any serial port except SMC1 as the serial console.
I attached a very simple patch to fix the problem, but it might be subject to
race conditions. Could anyone familiar with the cpm_uart driver have a look
at it ?
Best regards,
Laurent Pinchart
[-- Attachment #2: cpm_uart.patch --]
[-- Type: text/x-diff, Size: 403 bytes --]
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index a632897..a3c30f5 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1240,6 +1240,7 @@ static struct console cpm_scc_uart_conso
int __init cpm_uart_console_init(void)
{
+ cpm_uart_count();
register_console(&cpm_scc_uart_console);
return 0;
}
^ permalink raw reply related
* Re: some problems on the SystemACE driver.
From: Ming Liu @ 2006-07-13 11:57 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
In-Reply-To: <44B53DD0.5020006@gmail.com>
Dear Ameet,
Have you seen the response I sent to you last night? The content is that
there is still the same problem in the newly updated patch for SystemACE. I
forgot to CC a copy to the maillist so I don't know if you have received
it. I don't mean to push you. :)
Any progress on the patch? If yes, please tell me a.s.a.p. and I am anxious
for testing it.
Regards
Ming
>From: Ameet Patil <ammubhai@gmail.com>
>To: Ming Liu <eemingliu@hotmail.com>
>CC: akonovalov@ru.mvista.com, linuxppc-embedded@ozlabs.org
>Subject: Re: some problems on the SystemACE driver.
>Date: Wed, 12 Jul 2006 19:22:08 +0100
>
>Hi Ming,
> Thanks for testing the driver patch! The errors you get when
>compiling both - SysAce and TEMAC are reasonable. My ignorance or call
>it me being lazy. I recollect now... I was also working on the Xilinx
>Ethernet driver and forgot to cleanup that code before creating the
>patch for the SysAce driver. Thus, it so happens that code for the
>ethernet driver in my patch also gets compiled along with the TEMAC. I
>have deleted the unnecessary code files and updated the patch (name
>changed). Find the new one here:
>https://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.1.patch
>
>Let me know if it works for you now?
>
>-Ameet
>
>Ming Liu wrote:
> > Dear Ameet (and Andrei),
> > I have tested the new patch for SystemACE driver. With respect to the
> > single SystemACE driver, it works well. I can boot my linux in ML403
> > board. (I tried both 2.6.16-rc5 and 2.6.17.1 versions) So first
> > congratulations and thanks for your hard work!
> >
> > However, when I tried to implemented Temac (with and without SystemACE.
> > TWO conditions.), some errors happened. Here is the compilation
> > information:
> >
> > CC init/do_mounts.o
> > LD init/mounts.o
> > CC init/initramfs.o
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > drivers/built-in.o(.sdata+0x2c): multiple definition of `XWaitInAssert'
> > arch/ppc/platforms/4xx/built-in.o(.sdata+0x0): first defined here
> > drivers/built-in.o(.text+0x3e480): In function
`XPacketFifoV200a_WriteDre':
> > : multiple definition of `XPacketFifoV200a_WriteDre'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1b14): first defined here
> > drivers/built-in.o(.text+0x3e158): In function
`XPacketFifoV200a_SelfTest':
> > : multiple definition of `XPacketFifoV200a_SelfTest'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x17ec): first defined here
> > drivers/built-in.o(.sbss+0x18c): multiple definition of `XAssertStatus'
> > arch/ppc/platforms/4xx/built-in.o(.sbss+0x8): first defined here
> > drivers/built-in.o(.text+0x3e798): In function
`XPacketFifoV200a_L0Write':
> > : multiple definition of `XPacketFifoV200a_L0Write'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1e2c): first defined here
> > drivers/built-in.o(.text+0x3e280): In function `XPacketFifoV200a_Read':
> > : multiple definition of `XPacketFifoV200a_Read'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1914): first defined here
> > drivers/built-in.o(.text+0x3e55c): In function
`XPacketFifoV200a_L0Read':
> > : multiple definition of `XPacketFifoV200a_L0Read'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1bf0): first defined here
> > drivers/built-in.o(.text+0x3e380): In function
`XPacketFifoV200a_Write':
> > : multiple definition of `XPacketFifoV200a_Write'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1a14): first defined here
> > drivers/built-in.o(.text+0x3e0cc): In function `XAssertSetCallback':
> > : multiple definition of `XAssertSetCallback'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x44): first defined here
> > drivers/built-in.o(.text+0x3e9fc): In function
> > `XPacketFifoV200a_L0WriteDre':
> > : multiple definition of `XPacketFifoV200a_L0WriteDre'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x2090): first defined here
> > drivers/built-in.o(.text+0x3e0dc): In function
> > `XPacketFifoV200a_Initialize':
> > : multiple definition of `XPacketFifoV200a_Initialize'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x1770): first defined here
> > drivers/built-in.o(.text+0x3e088): In function `XAssert':
> > : multiple definition of `XAssert'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x0): first defined here
> > drivers/built-in.o(.text+0x3e0d8): In function `XNullHandler':
> > : multiple definition of `XNullHandler'
> > arch/ppc/platforms/4xx/built-in.o(.text+0x50): first defined here
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > It looks like that your patch affect some symbols which are used by
> > Temac. (When I use the old patch for SystemACE, there is no problem
like
> > this if I only choose Temac. ) So let's find out the problem together.
> > Also, I don't know if this is a problem from SystemACE or Temac , I
> > would like to invite Andrei to look at this altogether. If any
> > suggestion, please feel free to announce. Thanks for both your help.
> > Regards
> > Ming
> >
> >
> >
> >> From: Ameet Patil <ammubhai@gmail.com>
> >> To: Ming Liu <eemingliu@hotmail.com>
> >> CC: linuxppc-embedded@ozlabs.org
> >> Subject: Re: some problems on the SystemACE driver.
> >> Date: Wed, 12 Jul 2006 10:54:13 +0100
> >>
> >> Hi Ming,
> >>
> >> > I heard that you have tested this driver. Have you got this problem?
> >> > Why there are so many strange problems for me while you have tested
> >> > without problem?
> >>
> >> Yes, that is right! When I say... I have tested - "it really means I
> >> have tested". So what's the problem? It works for me but not you? The
> >> obvious difference: mine is a ML300 configuration and yours ML403.
> >>
> >> There were some files which unknowing were made dependant on ML300
> >> target. I have now made them compile for both targets. It should work
> >> fine for you now (Hopefully!). Download the updated patch from the
same
> >> location.
> >>
> >>
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17_sysace.patch
> >>
> >
> >>
> >> Since I don't have ML403 board, theres no way I can test this patch on
> >> it. I rely on you in doing this... and thanks for letting me know the
> >> issues.
> >>
> >> WARNING: There might be more issues. :-)
> >>
> >> Please DONOT hesitate to raise any issues with the driver. I am more
> >> than happy to fix them.
> >>
> >> -Ameet
> >>
> >> Ming Liu wrote:
> >> > Dear Ameet,
> >> > Sorry to bother you again but I am totally confused on the systemACE
> >> > driver. First let me show you the problem.
> >> >
> >> > 1. I downloaded the linux kernel of 2.6.17.1, also the patch for
> >> > SystemACE driver. Applied the patch to the kernel. Replaced the
> >> > xparameters_ml403.h with the generated file xparameters_ml300.h from
> >> > Xilinx EDK. Make menuconfig, make dep and make zImage. Then the
error
> >> > shows like this:
> >> >
> >> > drivers/block/xilinx_sysace/xsysace.c:120:6: warning:
> >> > "XPAR_XSYSACE_MEM_WIDTH" is not defined
> >> > drivers/block/xilinx_sysace/xsysace.c: In function
> > `XSysAce_LookupConfig':
> >> > drivers/block/xilinx_sysace/xsysace.c:366: error:
> >> > `XPAR_XSYSACE_NUM_INSTANCES' undeclared (first use in this function)
> >> > drivers/block/xilinx_sysace/xsysace.c:366: error: (Each undeclared
> >> > identifier is reported only once
> >> > drivers/block/xilinx_sysace/xsysace.c:366: error: for each function
it
> >> > appears in.)
> >> > make[3]: *** [drivers/block/xilinx_sysace/xsysace.o] Error 1
> >> > make[2]: *** [drivers/block/xilinx_sysace] Error 2
> >> > make[1]: *** [drivers/block] Error 2
> >> > make: *** [drivers] Error 2
> >> >
> >> > I think this is because of the no inclusion of the xparameters
header
> >> > file. So I change #include "xparameters.h" into #include "
> >> >
> >
/home/mingliu/linux-2.6.17.1/arch/ppc/platforms/4xx/xparameters/xparameters.h"
> >
> >
> >> > in the files of xsysace.c and xsysace_g.c, using the full address to
> >> > specify the header file. In fact, this is not a serious problem and
it
> >> > often happens. But, after the modification, another problem
happened:
> >> > GEN .version
> >> > CHK include/linux/compile.h
> >> > UPD include/linux/compile.h
> >> > CC init/version.o
> >> > LD init/built-in.o
> >> > LD .tmp_vmlinux1
> >> > drivers/built-in.o(.text+0x2234a): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x2235e): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x22364): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssert'
> >> > drivers/built-in.o(.text+0x22372): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x2237a): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x22394): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssert'
> >> > drivers/built-in.o(.text+0x223a2): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x223aa): In function `XSysAce_GetCfgAddr':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x22cd6): In function `XSysAce_Initialize':
> >> > : undefined reference to `XAssertStatus'
> >> > drivers/built-in.o(.text+0x22cdc): In function `XSysAce_Initialize':
> >> > : undefined reference to `XAssert'
> >> > drivers/built-in.o(.text+0x22cea): In function `XSysAce_Initialize':
> >> > : undefined reference to `XAssertStatus'
> >> >
> >> > ......( a long information to say that undefined reference to the
> >> > XAssert things.)
> >> >
> >> > Also, I tried this in the kernel 2.6.16-rc5. (In fact I prefer this
> >> > version because the temac driver is for this version. ) The same
> > problem
> >> > happened. I checked the source code. The problem happened in the
file
> >> > driver/block/xilinx_sysace/adapter.c, etc. Also, the XAssert things
are
> >> > defined in the file
arch/ppc/platforms/4xx/xilinx_ocp/xbasic_types.c.
> >> > (In 2.6.16 kernel, it is also defined in
> >> > driver/xilinx_edk/xbasic_types.c. There are two copies of this file.
)
> > I
> >> > think the problem is, the systemACE files cannot link together with
the
> >> > xbasic_types.c file.
> >> > I heard that you have tested this driver. Have you got this problem?
> > Why
> >> > there are so many strange problems for me while you have tested
without
> >> > problem? Without the CF card, I cannot try the Temac driver and my
work
> >> > is totally blocked. So I have to ask for your suggestion. Really
> > anxious
> >> > for your useful guidance. Thanks a lot!!!!!!
> >> >
> >> > Regards
> >> > Ming
> >> >
> >> > _________________________________________________________________
> >> > 与联机的朋友进行交流，请使用 MSN Messenger:
> > http://messenger.msn.com/cn
> >> >
> >
> > _________________________________________________________________
> > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> >
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Macraigor mpDemon
From: Ria Roy @ 2006-07-13 9:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Does anyone know if Macriagor's mpDemon is capable of debugging the
linux kernel via the JTAG interface.
Thanks in advance,
Ria
^ permalink raw reply
* help regarding powerpc and vga card
From: sudheer @ 2006-07-13 8:42 UTC (permalink / raw)
To: linuxppc-embedded, ilugc
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
Hello All
I am working on a powerpc board. I have placed the board on a PCI
backplane and connected a PCI VGA card to the same. PCI enumuration from
u-boot does not detect my VGA card whereas it detects other cards like
ethernet in the same slot.
The VGA card details are as follows.
Vendor ID=0x1002 Device ID= 0x4752
Name: ATI Technologies Inc Rage XL
The VGA card is universal compatible. It is working with X86 PC.
In my target system , I have tested adding the vendor id and and device
id in the u-boot/include/pci_ids.h and declared the pci_device_id
structure
in a new header file. uboot/include/vga_ragexl.h . Even then card is
not getting detected.
Anyone please help me if i am missing anything.
Thanks & Regards
Sudheer.A
[-- Attachment #2: Type: text/html, Size: 1209 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] iseries: Use device tree /system-id in /proc/iSeries/config
From: Stephen Rothwell @ 2006-07-13 8:30 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1152777121.430402.3949688126.qpush@concordia>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Hi Paulus,
On Thu, 13 Jul 2006 17:52:01 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> ...
I can stage all these iSeries patches through my git tree if you like
(after Michael fixes 7/7), as I have some other iSeries patches that I
need to send you as well (some already sent yesterday).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 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