* [PATCH 6/7] iseries: Move ItLpNaca into platforms/iseries
From: Michael Ellerman @ 2006-07-13 7:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <1152777121.430402.3949688126.qpush@concordia>
Move ItLpNaca into platforms/iseries now that it's not used elsewhere.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 1
arch/powerpc/platforms/iseries/hvlpconfig.c | 2
arch/powerpc/platforms/iseries/it_lp_naca.h | 80 ++++++++++++++++++++++++++++
arch/powerpc/platforms/iseries/lpardata.c | 3 -
arch/powerpc/platforms/iseries/lpevents.c | 2
arch/powerpc/platforms/iseries/setup.c | 2
include/asm-powerpc/iseries/it_lp_naca.h | 80 ----------------------------
7 files changed, 84 insertions(+), 86 deletions(-)
Index: to-merge/arch/powerpc/kernel/setup_64.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/setup_64.c
+++ to-merge/arch/powerpc/kernel/setup_64.c
@@ -56,7 +56,6 @@
#include <asm/page.h>
#include <asm/mmu.h>
#include <asm/lmb.h>
-#include <asm/iseries/it_lp_naca.h>
#include <asm/firmware.h>
#include <asm/xmon.h>
#include <asm/udbg.h>
Index: to-merge/arch/powerpc/platforms/iseries/hvlpconfig.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/hvlpconfig.c
+++ to-merge/arch/powerpc/platforms/iseries/hvlpconfig.c
@@ -18,7 +18,7 @@
#include <linux/module.h>
#include <asm/iseries/hv_lp_config.h>
-#include <asm/iseries/it_lp_naca.h>
+#include "it_lp_naca.h"
HvLpIndex HvLpConfig_getLpIndex_outline(void)
{
Index: to-merge/arch/powerpc/platforms/iseries/it_lp_naca.h
===================================================================
--- /dev/null
+++ to-merge/arch/powerpc/platforms/iseries/it_lp_naca.h
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2001 Mike Corrigan IBM Corporation
+ *
+ * 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. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef _PLATFORMS_ISERIES_IT_LP_NACA_H
+#define _PLATFORMS_ISERIES_IT_LP_NACA_H
+
+#include <linux/types.h>
+
+/*
+ * This control block contains the data that is shared between the
+ * hypervisor (PLIC) and the OS.
+ */
+
+struct ItLpNaca {
+// CACHE_LINE_1 0x0000 - 0x007F Contains read-only data
+ u32 xDesc; // Eye catcher x00-x03
+ u16 xSize; // Size of this class x04-x05
+ u16 xIntHdlrOffset; // Offset to IntHdlr array x06-x07
+ u8 xMaxIntHdlrEntries; // Number of entries in array x08-x08
+ u8 xPrimaryLpIndex; // LP Index of Primary x09-x09
+ u8 xServiceLpIndex; // LP Ind of Service Focal Pointx0A-x0A
+ u8 xLpIndex; // LP Index x0B-x0B
+ u16 xMaxLpQueues; // Number of allocated queues x0C-x0D
+ u16 xLpQueueOffset; // Offset to start of LP queues x0E-x0F
+ u8 xPirEnvironMode; // Piranha or hardware x10-x10
+ u8 xPirConsoleMode; // Piranha console indicator x11-x11
+ u8 xPirDasdMode; // Piranha dasd indicator x12-x12
+ u8 xRsvd1_0[5]; // Reserved for Piranha related x13-x17
+ u8 flags; // flags, see below x18-x1F
+ u8 xSpVpdFormat; // VPD areas are in CSP format ...
+ u8 xIntProcRatio; // Ratio of int procs to procs ...
+ u8 xRsvd1_2[5]; // Reserved ...
+ u16 xRsvd1_3; // Reserved x20-x21
+ u16 xPlicVrmIndex; // VRM index of PLIC x22-x23
+ u16 xMinSupportedSlicVrmInd;// Min supported OS VRM index x24-x25
+ u16 xMinCompatableSlicVrmInd;// Min compatible OS VRM index x26-x27
+ u64 xLoadAreaAddr; // ER address of load area x28-x2F
+ u32 xLoadAreaChunks; // Chunks for the load area x30-x33
+ u32 xPaseSysCallCRMask; // Mask used to test CR before x34-x37
+ // doing an ASR switch on PASE
+ // system call.
+ u64 xSlicSegmentTablePtr; // Pointer to Slic seg table. x38-x3f
+ u8 xRsvd1_4[64]; // x40-x7F
+
+// CACHE_LINE_2 0x0080 - 0x00FF Contains local read-write data
+ u8 xRsvd2_0[128]; // Reserved x00-x7F
+
+// CACHE_LINE_3-6 0x0100 - 0x02FF Contains LP Queue indicators
+// NB: Padding required to keep xInterrruptHdlr at x300 which is required
+// for v4r4 PLIC.
+ u8 xOldLpQueue[128]; // LP Queue needed for v4r4 100-17F
+ u8 xRsvd3_0[384]; // Reserved 180-2FF
+
+// CACHE_LINE_7-8 0x0300 - 0x03FF Contains the address of the OS interrupt
+// handlers
+ u64 xInterruptHdlr[32]; // Interrupt handlers 300-x3FF
+};
+
+extern struct ItLpNaca itLpNaca;
+
+#define ITLPNACA_LPAR 0x80 /* Is LPAR installed on the system */
+#define ITLPNACA_PARTITIONED 0x40 /* Is the system partitioned */
+#define ITLPNACA_HWSYNCEDTBS 0x20 /* Hardware synced TBs */
+#define ITLPNACA_HMTINT 0x10 /* Utilize MHT for interrupts */
+
+#endif /* _PLATFORMS_ISERIES_IT_LP_NACA_H */
Index: to-merge/arch/powerpc/platforms/iseries/lpardata.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/lpardata.c
+++ to-merge/arch/powerpc/platforms/iseries/lpardata.c
@@ -13,7 +13,6 @@
#include <asm/processor.h>
#include <asm/ptrace.h>
#include <asm/abs_addr.h>
-#include <asm/iseries/it_lp_naca.h>
#include <asm/lppaca.h>
#include <asm/iseries/it_lp_reg_save.h>
#include <asm/paca.h>
@@ -27,6 +26,7 @@
#include "processor_vpd.h"
#include "release_data.h"
#include "it_exp_vpd_panel.h"
+#include "it_lp_naca.h"
/* The HvReleaseData is the root of the information shared between
* the hypervisor and Linux.
@@ -127,7 +127,6 @@ struct ItLpNaca itLpNaca = {
(u64)instruction_access_slb_iSeries /* 0x480 I-SLB */
}
};
-EXPORT_SYMBOL(itLpNaca);
/* May be filled in by the hypervisor so cannot end up in the BSS */
struct ItIplParmsReal xItIplParmsReal __attribute__((__section__(".data")));
Index: to-merge/arch/powerpc/platforms/iseries/lpevents.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/lpevents.c
+++ to-merge/arch/powerpc/platforms/iseries/lpevents.c
@@ -20,7 +20,7 @@
#include <asm/iseries/it_lp_queue.h>
#include <asm/iseries/hv_lp_event.h>
#include <asm/iseries/hv_call_event.h>
-#include <asm/iseries/it_lp_naca.h>
+#include "it_lp_naca.h"
/*
* The LpQueue is used to pass event data from the hypervisor to
Index: to-merge/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/setup.c
+++ to-merge/arch/powerpc/platforms/iseries/setup.c
@@ -48,7 +48,6 @@
#include <asm/iseries/hv_call_event.h>
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/it_lp_queue.h>
-#include <asm/iseries/it_lp_naca.h>
#include <asm/iseries/mf.h>
#include <asm/iseries/hv_lp_event.h>
#include <asm/iseries/lpar_map.h>
@@ -60,6 +59,7 @@
#include "irq.h"
#include "vpd_areas.h"
#include "processor_vpd.h"
+#include "it_lp_naca.h"
#include "main_store.h"
#include "call_sm.h"
#include "call_hpt.h"
Index: to-merge/include/asm-powerpc/iseries/it_lp_naca.h
===================================================================
--- to-merge.orig/include/asm-powerpc/iseries/it_lp_naca.h
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * Copyright (C) 2001 Mike Corrigan IBM Corporation
- *
- * 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. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#ifndef _ASM_POWERPC_ISERIES_IT_LP_NACA_H
-#define _ASM_POWERPC_ISERIES_IT_LP_NACA_H
-
-#include <linux/types.h>
-
-/*
- * This control block contains the data that is shared between the
- * hypervisor (PLIC) and the OS.
- */
-
-struct ItLpNaca {
-// CACHE_LINE_1 0x0000 - 0x007F Contains read-only data
- u32 xDesc; // Eye catcher x00-x03
- u16 xSize; // Size of this class x04-x05
- u16 xIntHdlrOffset; // Offset to IntHdlr array x06-x07
- u8 xMaxIntHdlrEntries; // Number of entries in array x08-x08
- u8 xPrimaryLpIndex; // LP Index of Primary x09-x09
- u8 xServiceLpIndex; // LP Ind of Service Focal Pointx0A-x0A
- u8 xLpIndex; // LP Index x0B-x0B
- u16 xMaxLpQueues; // Number of allocated queues x0C-x0D
- u16 xLpQueueOffset; // Offset to start of LP queues x0E-x0F
- u8 xPirEnvironMode; // Piranha or hardware x10-x10
- u8 xPirConsoleMode; // Piranha console indicator x11-x11
- u8 xPirDasdMode; // Piranha dasd indicator x12-x12
- u8 xRsvd1_0[5]; // Reserved for Piranha related x13-x17
- u8 flags; // flags, see below x18-x1F
- u8 xSpVpdFormat; // VPD areas are in CSP format ...
- u8 xIntProcRatio; // Ratio of int procs to procs ...
- u8 xRsvd1_2[5]; // Reserved ...
- u16 xRsvd1_3; // Reserved x20-x21
- u16 xPlicVrmIndex; // VRM index of PLIC x22-x23
- u16 xMinSupportedSlicVrmInd;// Min supported OS VRM index x24-x25
- u16 xMinCompatableSlicVrmInd;// Min compatible OS VRM index x26-x27
- u64 xLoadAreaAddr; // ER address of load area x28-x2F
- u32 xLoadAreaChunks; // Chunks for the load area x30-x33
- u32 xPaseSysCallCRMask; // Mask used to test CR before x34-x37
- // doing an ASR switch on PASE
- // system call.
- u64 xSlicSegmentTablePtr; // Pointer to Slic seg table. x38-x3f
- u8 xRsvd1_4[64]; // x40-x7F
-
-// CACHE_LINE_2 0x0080 - 0x00FF Contains local read-write data
- u8 xRsvd2_0[128]; // Reserved x00-x7F
-
-// CACHE_LINE_3-6 0x0100 - 0x02FF Contains LP Queue indicators
-// NB: Padding required to keep xInterrruptHdlr at x300 which is required
-// for v4r4 PLIC.
- u8 xOldLpQueue[128]; // LP Queue needed for v4r4 100-17F
- u8 xRsvd3_0[384]; // Reserved 180-2FF
-
-// CACHE_LINE_7-8 0x0300 - 0x03FF Contains the address of the OS interrupt
-// handlers
- u64 xInterruptHdlr[32]; // Interrupt handlers 300-x3FF
-};
-
-extern struct ItLpNaca itLpNaca;
-
-#define ITLPNACA_LPAR 0x80 /* Is LPAR installed on the system */
-#define ITLPNACA_PARTITIONED 0x40 /* Is the system partitioned */
-#define ITLPNACA_HWSYNCEDTBS 0x20 /* Hardware synced TBs */
-#define ITLPNACA_HMTINT 0x10 /* Utilize MHT for interrupts */
-
-#endif /* _ASM_POWERPC_ISERIES_IT_LP_NACA_H */
^ permalink raw reply
* [PATCH 7/7] iseries: Move iommu_table_cb into platforms/iseries
From: Michael Ellerman @ 2006-07-13 7:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <1152777121.430402.3949688126.qpush@concordia>
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 | 1 +
arch/powerpc/platforms/iseries/iommu.h | 17 +++++++++++++++++
include/asm-powerpc/iseries/hv_call_xm.h | 17 -----------------
3 files changed, 18 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
@@ -36,6 +36,7 @@
#include <asm/pci-bridge.h>
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
+#include "iommu.h"
static void tce_build_iSeries(struct iommu_table *tbl, long index, long npages,
unsigned long uaddr, enum dma_data_direction direction)
Index: to-merge/arch/powerpc/platforms/iseries/iommu.h
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/iommu.h
+++ to-merge/arch/powerpc/platforms/iseries/iommu.h
@@ -32,4 +32,21 @@ extern void iommu_table_getparms_iSeries
unsigned char slotno, unsigned char virtbus,
struct iommu_table *tbl);
+/*
+ * 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];
+};
+
#endif /* _PLATFORMS_ISERIES_IOMMU_H */
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
* [PATCH 1/3] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
From: Michael Ellerman @ 2006-07-13 7:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
iSeries_Get_Location_Code() has error paths, but currently returns void, so
give it a return code and only print the output if it returns successfully.
Gcc isn't smart enough to be quiet though, so set frame to 0 to shut it up.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/vpdinfo.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
Index: to-merge/arch/powerpc/platforms/iseries/vpdinfo.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/vpdinfo.c
+++ to-merge/arch/powerpc/platforms/iseries/vpdinfo.c
@@ -205,15 +205,16 @@ static void __init iSeries_Parse_Vpd(u8
}
}
-static void __init iSeries_Get_Location_Code(u16 bus, HvAgentId agent,
+static int __init iSeries_Get_Location_Code(u16 bus, HvAgentId agent,
u8 *frame, char card[4])
{
+ int status = 0;
int BusVpdLen = 0;
u8 *BusVpdPtr = kmalloc(BUS_VPDSIZE, GFP_KERNEL);
if (BusVpdPtr == NULL) {
printk("PCI: Bus VPD Buffer allocation failure.\n");
- return;
+ return 0;
}
BusVpdLen = HvCallPci_getBusVpd(bus, iseries_hv_addr(BusVpdPtr),
BUS_VPDSIZE);
@@ -228,8 +229,10 @@ static void __init iSeries_Get_Location_
goto out_free;
}
iSeries_Parse_Vpd(BusVpdPtr, BusVpdLen, agent, frame, card);
+ status = 1;
out_free:
kfree(BusVpdPtr);
+ return status;
}
/*
@@ -246,7 +249,7 @@ void __init iSeries_Device_Information(s
struct device_node *DevNode = PciDev->sysdata;
struct pci_dn *pdn;
u16 bus;
- u8 frame;
+ u8 frame = 0;
char card[4];
HvSubBusNumber subbus;
HvAgentId agent;
@@ -262,10 +265,11 @@ void __init iSeries_Device_Information(s
subbus = pdn->bussubno;
agent = ISERIES_PCI_AGENTID(ISERIES_GET_DEVICE_FROM_SUBBUS(subbus),
ISERIES_GET_FUNCTION_FROM_SUBBUS(subbus));
- iSeries_Get_Location_Code(bus, agent, &frame, card);
- printk("%d. PCI: Bus%3d, Device%3d, Vendor %04X Frame%3d, Card %4s ",
- count, bus, PCI_SLOT(PciDev->devfn), PciDev->vendor,
- frame, card);
- printk("0x%04X\n", (int)(PciDev->class >> 8));
+ if (iSeries_Get_Location_Code(bus, agent, &frame, card)) {
+ printk("%d. PCI: Bus%3d, Device%3d, Vendor %04X Frame%3d, "
+ "Card %4s 0x%04X\n", count, bus,
+ PCI_SLOT(PciDev->devfn), PciDev->vendor, frame,
+ card, (int)(PciDev->class >> 8));
+ }
}
^ permalink raw reply
* [PATCH 2/3] Fix a compiler warning in mm/tlb_64.c
From: Michael Ellerman @ 2006-07-13 7:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <1152777279.500377.573076823663.qpush@concordia>
The compiler doesn't understand that BUG() never returns, so complains that
psize isn't set. Just set it to the normal value, which seems to produce nice
code and keeps gcc happy.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/tlb_64.c | 1 +
1 file changed, 1 insertion(+)
Index: to-merge/arch/powerpc/mm/tlb_64.c
===================================================================
--- to-merge.orig/arch/powerpc/mm/tlb_64.c
+++ to-merge/arch/powerpc/mm/tlb_64.c
@@ -146,6 +146,7 @@ void hpte_update(struct mm_struct *mm, u
psize = mmu_huge_psize;
#else
BUG();
+ psize = pte_pagesize_index(pte); /* shutup gcc */
#endif
} else
psize = pte_pagesize_index(pte);
^ permalink raw reply
* [PATCH 3/3] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
From: Michael Ellerman @ 2006-07-13 7:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <1152777279.500377.573076823663.qpush@concordia>
PhbId might be used unitialised, so set it to 0xff (nothing) always.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/vpdinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: to-merge/arch/powerpc/platforms/iseries/vpdinfo.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/vpdinfo.c
+++ to-merge/arch/powerpc/platforms/iseries/vpdinfo.c
@@ -188,7 +188,7 @@ static void __init iSeries_Parse_Vpd(u8
{
u8 *TagPtr = VpdData;
int DataLen = VpdDataLen - 3;
- u8 PhbId;
+ u8 PhbId = 0xff;
while ((*TagPtr != VpdEndOfAreaTag) && (DataLen > 0)) {
int AreaLen = *(TagPtr + 1) + (*(TagPtr + 2) * 256);
^ permalink raw reply
* RE: Problems of Compiling Kernel with linux-2.4.27 and linux-2.6.17 for PowerPC405EP Board (Gerhard Jaeger)
From: zhangshaobo @ 2006-07-13 8:14 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
gvb mention that "machine check exception" is caused by memory map problems
which lead to bus error , now I meet a problem under MPC5200, there is a
peripherally pci netcard named "e100" , when application to use it,
sometimes system will enter into machine check .
would you meet the same problem, can you give me a more detail ?
thanks!
[-- Attachment #2: Type: text/html, Size: 2492 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
* 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
* 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
* 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
* 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: 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
* 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: 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
* 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: [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
* 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: 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
* 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
* [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
* [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
* 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
* 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: 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: 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
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