* [PATCH 3/3] Xilinx: hwicap: Use fixed device major.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-3-git-send-email-stephen.neuendorffer@xilinx.com>
Major 259 has been assigned by lanana. Use it. Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 43 +++++++++-------------------
1 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 5b8d646..016f905 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -36,7 +36,7 @@
*****************************************************************************/
/*
- * This is the code behind /dev/xilinx_icap -- it allows a user-space
+ * This is the code behind /dev/icap* -- it allows a user-space
* application to use the Xilinx ICAP subsystem.
*
* The following operations are possible:
@@ -67,7 +67,7 @@
* user-space application code that uses this device. The simplest
* way to use this interface is simply:
*
- * cp foo.bit /dev/xilinx_icap
+ * cp foo.bit /dev/icap0
*
* Note that unless foo.bit is an appropriately constructed partial
* bitstream, this has a high likelyhood of overwriting the design
@@ -105,18 +105,14 @@
#include "buffer_icap.h"
#include "fifo_icap.h"
-#define DRIVER_NAME "xilinx_icap"
+#define DRIVER_NAME "icap"
#define HWICAP_REGS (0x10000)
-/* dynamically allocate device number */
-static int xhwicap_major;
-static int xhwicap_minor;
+#define XHWICAP_MAJOR 259
+#define XHWICAP_MINOR 0
#define HWICAP_DEVICES 1
-module_param(xhwicap_major, int, S_IRUGO);
-module_param(xhwicap_minor, int, S_IRUGO);
-
/* An array, which is set to true when the device is registered. */
static bool probed_devices[HWICAP_DEVICES];
static struct mutex icap_sem;
@@ -605,7 +601,7 @@ static int __devinit hwicap_setup(struct device *dev, int id,
probed_devices[id] = 1;
mutex_unlock(&icap_sem);
- devt = MKDEV(xhwicap_major, xhwicap_minor + id);
+ devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR + id);
drvdata = kzalloc(sizeof(struct hwicap_drvdata), GFP_KERNEL);
if (!drvdata) {
@@ -710,7 +706,7 @@ static int __devexit hwicap_remove(struct device *dev)
dev_set_drvdata(dev, NULL);
mutex_lock(&icap_sem);
- probed_devices[MINOR(dev->devt)-xhwicap_minor] = 0;
+ probed_devices[MINOR(dev->devt)-XHWICAP_MINOR] = 0;
mutex_unlock(&icap_sem);
return 0; /* success */
}
@@ -850,23 +846,12 @@ static int __init hwicap_module_init(void)
icap_class = class_create(THIS_MODULE, "xilinx_config");
mutex_init(&icap_sem);
- if (xhwicap_major) {
- devt = MKDEV(xhwicap_major, xhwicap_minor);
- retval = register_chrdev_region(
- devt,
- HWICAP_DEVICES,
- DRIVER_NAME);
- if (retval < 0)
- return retval;
- } else {
- retval = alloc_chrdev_region(&devt,
- xhwicap_minor,
- HWICAP_DEVICES,
- DRIVER_NAME);
- if (retval < 0)
- return retval;
- xhwicap_major = MAJOR(devt);
- }
+ devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
+ retval = register_chrdev_region(devt,
+ HWICAP_DEVICES,
+ DRIVER_NAME);
+ if (retval < 0)
+ return retval;
retval = platform_driver_register(&hwicap_platform_driver);
@@ -891,7 +876,7 @@ static int __init hwicap_module_init(void)
static void __exit hwicap_module_cleanup(void)
{
- dev_t devt = MKDEV(xhwicap_major, xhwicap_minor);
+ dev_t devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
class_destroy(icap_class);
--
1.5.3.4-dirty
^ permalink raw reply related
* [PATCH 0/3] Xilinx hwicap updates
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
To: grant.likely, git-dev, linuxppc-dev, linux-kernel
The following sequence of patches makes the icap driver more robust,
by making better use of the status information from the cores. In
addition, Lanana has assigned Major 259 for FPGA configuration
interfaces, so we now use it, rather than dynamically finding a major
number.
Grant: please pick these up for 2.6.26. Do you think it's worth
patching virtex_devices.c at this point, or just punt on ARCH=ppc?
Steve
^ permalink raw reply
* [PATCH 2/3] Xilinx: hwicap: Verify sync before reading idcode.
From: Stephen Neuendorffer @ 2008-03-17 17:36 UTC (permalink / raw)
To: grant.likely, git-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1205775392-32222-2-git-send-email-stephen.neuendorffer@xilinx.com>
It appears that in some cases, the sync word might not be recognized
by the hardware correctly. If this happens, then attempting to read
from the port results in an unrecoverable error because of the design
of the FPGA core. This patch updates the code to check the status of
the device before reading the IDCODE, in order to avoid entering this
unrecoverable state. This patch also adds additional NOOP commands
into the sychronization sequence, which appears to be necessary to
avoid the condition on some hardware.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 304727d..5b8d646 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -250,8 +250,26 @@ static int hwicap_get_configuration_register(struct hwicap_drvdata *drvdata,
* Create the data to be written to the ICAP.
*/
buffer[index++] = XHI_DUMMY_PACKET;
+ buffer[index++] = XHI_NOOP_PACKET;
buffer[index++] = XHI_SYNC_PACKET;
buffer[index++] = XHI_NOOP_PACKET;
+ buffer[index++] = XHI_NOOP_PACKET;
+
+ /*
+ * Write the data to the FIFO and initiate the transfer of data present
+ * in the FIFO to the ICAP device.
+ */
+ status = drvdata->config->set_configuration(drvdata,
+ &buffer[0], index);
+ if (status)
+ return status;
+
+ /* If the syncword was not found, then we need to start over. */
+ status = drvdata->config->get_status(drvdata);
+ if ((status & XHI_SR_DALIGN_MASK) != XHI_SR_DALIGN_MASK)
+ return -EIO;
+
+ index = 0;
buffer[index++] = hwicap_type_1_read(reg) | 1;
buffer[index++] = XHI_NOOP_PACKET;
buffer[index++] = XHI_NOOP_PACKET;
--
1.5.3.4-dirty
^ permalink raw reply related
* [PATCH] [POWERPC] Xilinx: Boot: Fix 16550 UART initialization
From: John Linn @ 2008-03-17 16:41 UTC (permalink / raw)
To: linuxppc-dev, jwboyer; +Cc: John Linn
The UART 16550 initialization was not setting up the registers
correctly. Code was added to pull the frequency and speed from
the device tree and initialize the registers using those values.
The boot code was not and is still not using the cmd line
to setup up the uart. The frequency of the clock driving the
UART must be specified in the device tree so that the baud
rate generator can be setup.
---
Please pull this patch for 2.6.26.
---
arch/powerpc/boot/ns16550.c | 69 +++++++++++++++++++++++++++++++++---------
1 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..d8edd48 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -15,23 +15,47 @@
#include "io.h"
#include "ops.h"
-#define UART_DLL 0 /* Out: Divisor Latch Low */
-#define UART_DLM 1 /* Out: Divisor Latch High */
-#define UART_FCR 2 /* Out: FIFO Control Register */
-#define UART_LCR 3 /* Out: Line Control Register */
-#define UART_MCR 4 /* Out: Modem Control Register */
-#define UART_LSR 5 /* In: Line Status Register */
-#define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
-#define UART_LSR_DR 0x01 /* Receiver data ready */
-#define UART_MSR 6 /* In: Modem Status Register */
-#define UART_SCR 7 /* I/O: Scratch Register */
-
-static unsigned char *reg_base;
-static u32 reg_shift;
+#define UART_DLL 0 /* Out: Divisor Latch Low */
+#define UART_DLM 1 /* Out: Divisor Latch High */
+#define UART_FCR 2 /* Out: FIFO Control Register */
+#define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */
+#define UART_FCR_CLEAR_XMIT 0x04 /* Clear the XMIT FIFO */
+#define UART_LCR 3 /* Out: Line Control Register */
+#define UART_MCR 4 /* Out: Modem Control Register */
+#define UART_MCR_RTS 0x02 /* RTS complement */
+#define UART_MCR_DTR 0x01 /* DTR complement */
+#define UART_LSR 5 /* In: Line Status Register */
+#define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
+#define UART_LSR_DR 0x01 /* Receiver data ready */
+#define UART_LCR_DLAB 0x80 /* Divisor latch access bit */
+#define UART_LCR_WLEN8 0x03 /* Wordlength: 8 bits */
+#define UART_MSR 6 /* In: Modem Status Register */
+#define UART_SCR 7 /* I/O: Scratch Register */
+
+volatile static unsigned char *reg_base;
+volatile static u32 reg_shift;
+volatile static u16 divisor;
static int ns16550_open(void)
{
- out_8(reg_base + (UART_FCR << reg_shift), 0x06);
+
+ /* Access baud rate */
+ out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_DLAB);
+
+ /* Baud rate based on input clock */
+ out_8(reg_base + (UART_DLL << reg_shift), divisor & 0xFF);
+ out_8(reg_base + (UART_DLM << reg_shift), divisor >> 8);
+
+ /* 8 data, 1 stop, no parity */
+ out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_WLEN8);
+
+ /* RTS/DTR */
+ out_8(reg_base + (UART_MCR << reg_shift), UART_MCR_RTS | UART_MCR_DTR);
+
+ /* Clear transmitter and receiver */
+ out_8(reg_base + (UART_FCR << reg_shift),
+ UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
+
return 0;
}
@@ -56,6 +80,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 clk, spd;
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,9 +90,23 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
- n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
+ n = getprop(devp, "reg-shift", (void *)®_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
+
+ /* the base address has to change for devices with odd reg spacing */
+ reg_base = reg_base + ((1 << reg_shift) - 1);
+
+ n = getprop(devp, "current-speed", (void *)&spd, sizeof(spd));
+ if (n != sizeof(spd))
+ spd = 9600;
+
+ /* should there be a default clock rate?*/
+ n = getprop(devp, "clock-frequency", (void *)&clk, sizeof(clk));
+ if (n != sizeof(clk))
+ return -1;
+
+ divisor = clk / (16 * spd);
scdp->open = ns16550_open;
scdp->putc = ns16550_putc;
--
1.5.2.1
^ permalink raw reply related
* Re: Interrupt handling documentation
From: Laurent Pinchart @ 2008-03-17 16:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200803131456.26722.laurentp@cse-semaphore.com>
[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]
On Thursday 13 March 2008 14:56, Laurent Pinchart wrote:
> Hi Michael,
>
> On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> > On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > is there any documentation describing interrupt handling for the
> > > powerpc architecture ? I'm writing a driver for a cascaded interrupt
> > > controller and the only source of information I found was the code.
> >
> > I don't think there's much documentation.
>
> I feared so :-)
>
> > You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> > reasonably simple example of how to setup an irq_host and so on - well I
> > think so :D
>
> Thanks for the pointer.
>
> > > I'm particularly interested in information about irq hosts (allocation
> > > and initialisation, especially the map and unmap callbacks) and irq
> > > chaining. Different drivers seem to implement cascaded irqs differently
> > > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > > cascaded irq handler, while
> > > arch/powerpc/platforms/82xx/pq2ads-pci-pic.c uses
> > > set_irq_chained_handler) so I'm a bit lost here.
> >
> > uic.c uses set_irq_chained_handler() now, so that probably answers that
> > question. I don't think it makes all that much difference if you set it
> > up by hand, but set_irq_chained_handler() is the neat way to do it.
>
> That pretty much answers my question. It's always a bit disturbing when
> different drivers use different APIs to accomplish the same task,
> especially when the lack of documentation doesn't clearly state which API
> should be used and which API is internal/deprecated.
I've been struggling with spurious interrupts related to my irq host for a
day. Now that I've been able to solve the problem I thought I'd share the
results here.
The PIC I am working with is linked to a falling-edge external irq on the
CPM2. When the first PIC interrupt was generated the kernel called the PIC
chained irq handler endlessly.
After some investigation it turned out the external interrupt bit in the CPM2
interrupt pending register never got cleared. set_irq_chained_handler()
registers the chained irq handler at the lowest level in the irq stack,
bypassing all the interrupt acknowledgement/masking logic.
The fix was easy, all I had to do was to call desc->chip->ack(irq) at the
beginning on the chained irq handler and desc->chip->eoi(irq) at the end.
However, I'm wondering if this really belongs in the PIC code, or if PICs
shouldn't be registered at a higher level (setup_irq or even request_irq) so
that they would reuse the handle_*_irq handlers. Any opinion on this ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Stephen Neuendorffer @ 2008-03-17 15:58 UTC (permalink / raw)
To: Qin Lin, linuxppc-embedded
In-Reply-To: <16089631.post@talk.nabble.com>
It should... (I use it regularly on the xup board)
Did you remember to connect the interrupt line in your design?
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
> Sent: Monday, March 17, 2008 12:36 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>=20
>=20
> HI all,
>=20
> Is anyone have the opb_emac (no DMA) work with the kernel
linux-2.6-xlnx
> from git.xilinx.com.
> the message seams that it does work ,but the command ping return
nothing!
>=20
> Could you kindly suggest me what to do?
>=20
> ps:
> the kernel booting message
> [ 0.258674] net_namespace: 64 bytes
> [ 0.269780] NET: Registered protocol family 16
> [ 0.290415] Registering device xilinx_emac:0
> [ 0.381687] NET: Registered protocol family 2
> [ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [ 0.399556] TCP established hash table entries: 8192 (order: 4,
65536
> bytes)
> [ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
bytes)
> [ 0.405409] TCP: Hash tables configured (established 8192 bind
8192)
> [ 0.405489] TCP reno registered
> [ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
> strategy
> [ 0.413189] Call Trace:
> [ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
(unreliable)
> [ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
> [ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
> [ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
> [ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
> [ 0.414141] [cf41ff70] [c01e4b1c]
register_ppc_htab_sysctl+0x18/0x2c
> [ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
> [ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>=20
> [ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0:
0: 0:
> 0
> [ 1.123790] XEmac: using fifo mode.
> [ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
> 0x78e2.
> [ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
0xD0020000,
> irq=3D2
> [ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
> [ 1.194661] TCP cubic registered
> [ 1.198647] NET: Registered protocol family 1
> [ 1.203728] NET: Registered protocol family 17
>=20
>=20
> #ping 192.168.26.1 &
> # ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
> inet addr:192.168.26.127 Bcast:192.168.26.255
Mask:255.255.255.0
> UP BROADCAST RUNNING MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
> Interrupt:2 Memory:40c00000-40c0ffff
>=20
> Regards
>=20
> Qin Lin
> --
> View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
> xlnx-tp16089631p16089631.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Stephen Neuendorffer @ 2008-03-17 15:49 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, Koss, Mike (Mission Systems),
linuxppc-embedded
In-Reply-To: <BAY115-W53AE071415B85C1E71AAD1B2050@phx.gbl>
Sorry, but I'm not in a position to discuss product roadmaps. The kinds
of technical questions are best handled by regular sales channels.
Steve
> -----Original Message-----
> From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
> Sent: Monday, March 17, 2008 2:04 AM
> To: Stephen Neuendorffer; Koss, Mike (Mission Systems);
linuxppc-embedded@ozlabs.org
> Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
>=20
> Ok, thanks for guidance,
>=20
> by the way it is interesting for me to hear about EDK 10.1 from u
steve,
> EDK 9.2 has been around just for a little time and you are going to
10.1?
>=20
> What about future plan of xilinx about Virtex-5 FX? does this tool
consider that?
> the future plan is really important for our development team. let me
give a simple example, our dev
> team worked on the design of our system based on PLB and OPB buses for
some thing near 6 month, just
> then EDK 9.2.02 released and suddenly we forced to change all of the
designs and to define new
> activities specially focusing on MPMC. we did never consider MPMC
before, but the release of EDK 9.2
> changed every thing.
>=20
> Now, that would be nice, if we can know your future plan a little,
that would help us to generate
> correct and real gant charts. and to assign human resources correctly.
this is also true for the
> project budget. We know that Virtex-5 devices are really capable of
doing better things than Virtex-
> 4, specially the PCI express option is great and very usable for us,
but we have not moved to virtex-
> 5 yet, because there is no FX series or at least we do not know your
plan about it. Our managers we
> seriously asking us if we have to move to Virtex-5 soon, we did not
have any reasonable answer for
> them because we do not have any info from u at all.
>=20
> thanks
>=20
>=20
>=20
> ________________________________
>=20
> Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
> Date: Sun, 16 Mar 2008 14:43:33 -0700
> From: stephen.neuendorffer@xilinx.com
> To: mike.koss@ngc.com; mamsadegh@hotmail.com;
linuxppc-embedded@ozlabs.org
>=20
>=20
>=20
> Ah, thanks mike... you knocked the answer loose out of my
brain...
>=20
> In EDK 9.2., the ll_temac generates either SDMA or FIFO defines,
as necessary.
> The platform data structure contains entries for both, with the
correct ones being ignored. In
> order to get the code to compile, there are some defines in
xparameters.h which have:
>=20
> #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
> #define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
> #endif
> #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
> #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
> #endif
> #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
> #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
> #endif
>=20
> after including xparameter_ml403.h
>=20
> I'm guessing maybe you overwrote the xparameters.h file and got
rid of these redefines? You
> can define it to be whatever you want, since the value will be ignored
if you are using SDMA.
>=20
> In EDK 10.1, the BSP generator will always generate all the
defines (even ones which are not
> sensible in the current configuration), which avoids the above
annoyances.
>=20
> Steve
>=20
> -----Original Message-----
> From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org on =
behalf
of Koss, Mike
> (Mission Systems)
> Sent: Sat 3/15/2008 9:12 PM
> To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
> Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for
XPS LLTEMAC
>=20
> That interrupt is defined if you build a xps_ll_temac with the
> xps_ll_fifo interface. Since you already stated that you're
using the
> mpmc, I'm going to assume that you have it connected to a SDMA
> controller on the mpmc. As such the driver should be looking for
that
> definition, and not the FIFO interrupt. I don't have your
version of the
> virtex_devices.c to have a reference as to how the platform
device is
> being defined, so hopefully either Stephen N can chime in w/
more
> information, or point me to the version of the virtex_devices.c
that
> you're using and I can try to provide some more assistance.
>=20
> -- Mike
>=20
> ________________________________
>=20
> From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
> Sent: Saturday, March 15, 2008 4:31 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
>=20
>=20
> All,
>=20
> that should be a small problem, and i think that its solution
should be
> simple,
>=20
> I generate a base system using EDK 9.2.02 , the base system
contains
> XPS_LL_TEMAC , MPMC and other components,
> I generate the software libraries and copy xparameters file into
proper
> kernel folder. I configure that kernel and add kernel support
for
> XPS_LL_TEMAC.
>=20
> while doing make I encounter this error:
>=20
> arch/ppc/syslib/virtex_devices.c:455: error:
> 'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not
in a
> function)
>=20
> I think that this definition should be available in
xparameters_ml403.h
> file but i see that there is no such definition.
> I added a dummy definition for myself there to complete kernel
> compilation, don't know the correct value for it of course.
>=20
> thanks
>=20
>=20
>=20
> ________________________________
>=20
> Access your files from anywhere with Windows Live SkyDrive! Sign
up now
> and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
>=20
>=20
>=20
>=20
>=20
> ________________________________
>=20
> Is your lingo strong enough to ace these new word puzzles from Live
Search Games? Click here to test
> your vocab! <http://g.msn.ca/ca55/214>
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Scott Wood @ 2008-03-17 15:33 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803101317.04455.laurentp@cse-semaphore.com>
On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> On Friday 07 March 2008 17:21, Scott Wood wrote:
> > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > (unlike cpm1). This should probably be fixed, though then we'd have to
> > deal with assigning SMC parameter RAM addresses ourselves.
>
> I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any
> reason not to rset the CPM in cpm2_reset() ?
The only issue I'm aware of other than the SMC parameter RAM relocation is
that the reset can't happen if the early udbg printk is being used.
> How should SMC parameter RAM assignment be handled ? I'm not very familiar
> with the CPM1,
CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.
> but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter RAM.
It can, yes. Patches welcome. :-)
-Scott
^ permalink raw reply
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Rick Moleres @ 2008-03-17 15:24 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, Stephen Neuendorffer,
Koss, Mike(Mission Systems), linuxppc-embedded
In-Reply-To: <BAY115-W53AE071415B85C1E71AAD1B2050@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 6184 bytes --]
You should be able to contact your Xilinx sales rep for details on
Virtex-5 FX as well as roadmap information. The Virtex-5 FXT product is
coming soon and should be announced within the next month or so. I
can't provide details, but your technical sales contact should be able
to give you more info on timelines etc...
As for EDK releases, Xilinx typically releases two per year (e.g., EDK
9.1 and 9.2 were both released in 2007). EDK 10.1 is scheduled for
release before summer, and should be the only release in 2008 (with some
service packs throughout the year). There shouldn't be any major
differences from EDK 9.2.02 regarding IP/drivers.
-Rick
________________________________
From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On
Behalf Of Mohammad Sadegh Sadri
Sent: Monday, March 17, 2008 3:04 AM
To: Stephen Neuendorffer; Koss, Mike(Mission Systems);
linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
Ok, thanks for guidance,
by the way it is interesting for me to hear about EDK 10.1 from u steve,
EDK 9.2 has been around just for a little time and you are going to
10.1?
What about future plan of xilinx about Virtex-5 FX? does this tool
consider that?
the future plan is really important for our development team. let me
give a simple example, our dev team worked on the design of our system
based on PLB and OPB buses for some thing near 6 month, just then EDK
9.2.02 released and suddenly we forced to change all of the designs and
to define new activities specially focusing on MPMC. we did never
consider MPMC before, but the release of EDK 9.2 changed every thing.
Now, that would be nice, if we can know your future plan a little, that
would help us to generate correct and real gant charts. and to assign
human resources correctly. this is also true for the project budget. We
know that Virtex-5 devices are really capable of doing better things
than Virtex-4, specially the PCI express option is great and very usable
for us, but we have not moved to virtex-5 yet, because there is no FX
series or at least we do not know your plan about it. Our managers we
seriously asking us if we have to move to Virtex-5 soon, we did not have
any reasonable answer for them because we do not have any info from u at
all.
thanks
________________________________
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
Date: Sun, 16 Mar 2008 14:43:33 -0700
From: stephen.neuendorffer@xilinx.com
To: mike.koss@ngc.com; mamsadegh@hotmail.com;
linuxppc-embedded@ozlabs.org
Ah, thanks mike... you knocked the answer loose out of my brain...
In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as
necessary.
The platform data structure contains entries for both, with the correct
ones being ignored. In order to get the code to compile, there are some
defines in xparameters.h which have:
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif
after including xparameter_ml403.h
I'm guessing maybe you overwrote the xparameters.h file and got rid of
these redefines? You can define it to be whatever you want, since the
value will be ignored if you are using SDMA.
In EDK 10.1, the BSP generator will always generate all the defines
(even ones which are not sensible in the current configuration), which
avoids the above annoyances.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on
behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.
thanks
________________________________
Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
________________________________
Is your lingo strong enough to ace these new word puzzles from Live
Search Games? Click here to test your vocab! <http://g.msn.ca/ca55/214>
[-- Attachment #2: Type: text/html, Size: 11202 bytes --]
^ permalink raw reply
* Re: [PATCH v2] MTD support for the AMCC Taishan
From: Imre Kaloz @ 2008-03-17 14:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <12057617031716-git-send-email-kaloz@openwrt.org>
On Mon, 17 Mar 2008 14:48:23 +0100, Imre Kaloz <kaloz@openwrt.org> wrote:
<snip>
Sorry, forgot to note that this version removes the "kozio" and extends
the "user" partition accordingly, as Stefan asked.
Imre
^ permalink raw reply
* [PATCH v2] MTD support for the AMCC Taishan
From: Imre Kaloz @ 2008-03-17 13:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200802081532.42717.sr@denx.de>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
---
arch/powerpc/boot/dts/taishan.dts | 29 +++++++++++-
arch/powerpc/configs/taishan_defconfig | 79 +++++++++++++++++++++++++++++++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..db102e9 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -174,7 +174,34 @@
interrupts = <5 4>;
interrupt-parent = <&UIC1>;
- /* TODO: Add other EBC devices */
+ nor_flash@0,0 {
+ compatible = "cfi-flash";
+ bank-width = <4>;
+ device-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 180000>;
+ };
+ partition@180000 {
+ label = "root";
+ reg = <180000 200000>;
+ };
+ partition@380000 {
+ label = "user";
+ reg = <380000 3bc0000>;
+ };
+ partition@3f40000 {
+ label = "env";
+ reg = <3f40000 80000>;
+ };
+ partition@3fc0000 {
+ label = "u-boot";
+ reg = <3fc0000 40000>;
+ };
+ };
};
diff --git a/arch/powerpc/configs/taishan_defconfig b/arch/powerpc/configs/taishan_defconfig
index 087aedc..e53c926 100644
--- a/arch/powerpc/configs/taishan_defconfig
+++ b/arch/powerpc/configs/taishan_defconfig
@@ -348,7 +348,83 @@ CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
@@ -660,6 +736,7 @@ CONFIG_TMPFS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
--
1.5.2.5
^ permalink raw reply related
* Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper
From: Alexandr Smirnov @ 2008-03-17 12:19 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080315001036.GA3487@localhost.localdomain>
David,
>> + /* Unfortunately, the specific model number is encoded in the
>> + * soc node name in existing dts files -- once that is fixed,
>> + * this can do a simple path lookup.
>> + */
>>
>
> Since this is a new board, couldn't you name the soc node /soc and
> dispense with this more complicated way of doing things? Or would
> that break other versions of u-boot that are in use?
>
As I understand you would like to rename /soc8548 node to /soc and make
a simple path lookup like following:
- soc = find_node_by_devtype(NULL, "soc");
+ soc = finddevice("/soc");
Is this correct?
But fsl_soc code still uses of_find_node_by_type so we can't remove
device_type property from node /soc and therefor simplify device tree.
Thanks,
Alexandr
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Add compatible "ibm,tah" to tah matching table
From: Jeff Garzik @ 2008-03-17 12:08 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1205423983-21142-1-git-send-email-sr@denx.de>
Stefan Roese wrote:
> Add "ibm,tah" to the compatible matching table of the ibm_newemac
> tah driver. The type "tah" is still preserved for compatibility reasons.
> New dts files should use the compatible property though.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/net/ibm_newemac/tah.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Jeff Garzik @ 2008-03-17 12:08 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <1205488348-22536-1-git-send-email-sr@denx.de>
Stefan Roese wrote:
> From: Pravin M. Bathija <pbathija@amcc.com>
>
> Problem Description and Fix
> ---------------------------
> When a pause packet(with destination as reserved Multicast address) is
> received by the EMAC hardware to control the flow of frames being
> transmitted by it, it is dropped by the hardware unless the reserved
> Multicast address is hashed in to the GAHT[1-4] registers. This code fix
> adds the default reserved multicast address to the GAHT[1-4] registers
> in the EMAC(s) present on the chip. The flow control with Pause packets
> will only work if the following register bits are programmed in EMAC:
> EMACx_MR1[APP] = 1
> EMACx_RMR[BAE] = 1
> EMACx_RMR[MAE] = 1
>
> Behavior that may be observed in a running system
> -------------------------------------------------
> A host transferring data from a PPC based system may send a Pause packet
> to the PPC EMAC requesting it to slow down the flow of packets. If the
> default reserved multicast MAC address is not programmed into the
> GAHT[1-4] registers this Pause packet will be dropped by PPC EMAC and no
> Flow Control will be done.
>
> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/net/ibm_newemac/core.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* [PATCH 11/11] hvcbeat: fix buffer manipulation
From: Ishizaki Kou @ 2008-03-17 10:05 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This patch fixes a potential bug at drivers/char/hvc_beat.c.
- hvc_put_term_char routine will decrement "rest" variable twice,
and forget to advance "buf" pointer by "nlen" bytes.
This bug was not hit because the output handler in
drivers/char/hvc_console.c splits given output into 16 bytes
at maximum.
This patch is one of a series that I posted on Mar.14, "celleb:
patchset for 2.6.26 (take2)". I send this again because it
would be lost.
Reported-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/char/hvc_beat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/char/hvc_beat.c
===================================================================
--- a/drivers/char/hvc_beat.c 2008-03-10 14:11:57.000000000 +0900
+++ b/drivers/char/hvc_beat.c 2008-03-10 14:13:40.000000000 +0900
@@ -78,8 +78,8 @@
for (rest = cnt; rest > 0; rest -= nlen) {
nlen = (rest > 16) ? 16 : rest;
memcpy(kb, buf, nlen);
- beat_put_term_char(vtermno, rest, kb[0], kb[1]);
- rest -= nlen;
+ beat_put_term_char(vtermno, nlen, kb[0], kb[1]);
+ buf += nlen;
}
return cnt;
}
^ permalink raw reply
* [PATCH] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
From: S.Çağlar Onur @ 2008-03-17 9:36 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Andrew Morton, Paul Mackerras
In-Reply-To: <1205746593-24820-3-git-send-email-caglar@pardus.org.tr>
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: linuxppc-dev@ozlabs.org
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
arch/powerpc/platforms/iseries/pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
#undef DEBUG
+#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/string.h>
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
--
1.5.4.3
^ permalink raw reply related
* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-17 9:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <fa686aa40803161301r1685f2cale75d67b8a203cca3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
Grant Likely wrote:
> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
> <Andre.Schwarz@matrix-vision.de> wrote:
>
>> All,
>>
>> I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
>> ... maybe someone could give me some hints.
>> Up to now the systems have been running on 2.6.19 without any problems.
>>
>> This is what I've done so far :
>>
>> - get a recent system with 2.6.19 running and keep the toolchain (gcc
>> 4.0) including RFS uImage.
>> - latest bootloader (u-boot 1.3.2) is running fine with dtb support.
>> - Kernel and RFS images are available via bootp/tftp
>> - device tree blob seems ok, i.e. u-boot can display the blob and fill
>> in all clocks correctly.
>> - Kernel gets called with Kernel, RFS and dtb on suitable adresses
>> (0x100000, 0x600000, 0x5F0000).
>> - nothing more happens. It looks like the console isn't working properly
>> - maybe worse ...
>>
>
> Can you either halt the processor or reset the board and access memory
> after this point? You should see if you can access __log_buf (Look in
> System.map for the address and subtract 0xc0000000 to get the physical
> address). __log_buf should give you clues about how far booting
> progresses.
>
>
As soon as my abatron debugger is back I'll give it a try - currently
it's out for an update ...
Are there any restrictions for the memory locations of the kernel,
initrd and dtb images ?
Thanks for the help. I'll post the __log_buf tomorrow ... propably.
>> The kernel has been build using the "MPC5200 simple" setup. I've added
>> our board identifier "mv,mvbluecougar" to the list of supported boards
>> in the "mpc52xx_simple.c" file. This identifier is used in the dtb as
>> well of course. This should be enough along with a valid device tree
>> blob, isn't it ? Did I miss anything already ?
>>
>
> Yes, this should be enough (on a side note; it should probably be
> "matrix-vision,bluecougar" unless of''mv' is your company's stock
> ticker symbol).
>
>
>> As far as I did understand by reading the docs it should be possible
>> running a general MPC52xx kernel with a custom dtb ? Is this correct ?
>>
>
> That is correct.
>
>
>> The dts file has already been reduced to a minimum, i.e. only the cpu,
>> pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,
>> pci, ata or "advanced" features like mtd partitions. All I want to get
>> working is the serial console on "/dev/ttyPSC0".
>>
>
> Cheers,
> g.
>
>
regards,
André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 3550 bytes --]
^ permalink raw reply
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Mohammad Sadegh Sadri @ 2008-03-17 9:03 UTC (permalink / raw)
To: Stephen Neuendorffer, Koss, Mike (Mission Systems),
linuxppc-embedded
In-Reply-To: <20080316214832.3F77A538046@mail141-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 5247 bytes --]
Ok, thanks for guidance,
by the way it is interesting for me to hear about EDK 10.1 from u steve,
EDK 9.2 has been around just for a little time and you are going to 10.1?
What about future plan of xilinx about Virtex-5 FX? does this tool consider that?
the future plan is really important for our development team. let me give a simple example, our dev team worked on the design of our system based on PLB and OPB buses for some thing near 6 month, just then EDK 9.2.02 released and suddenly we forced to change all of the designs and to define new activities specially focusing on MPMC. we did never consider MPMC before, but the release of EDK 9.2 changed every thing.
Now, that would be nice, if we can know your future plan a little, that would help us to generate correct and real gant charts. and to assign human resources correctly. this is also true for the project budget. We know that Virtex-5 devices are really capable of doing better things than Virtex-4, specially the PCI express option is great and very usable for us, but we have not moved to virtex-5 yet, because there is no FX series or at least we do not know your plan about it. Our managers we seriously asking us if we have to move to Virtex-5 soon, we did not have any reasonable answer for them because we do not have any info from u at all.
thanks
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
Date: Sun, 16 Mar 2008 14:43:33 -0700
From: stephen.neuendorffer@xilinx.com
To: mike.koss@ngc.com; mamsadegh@hotmail.com; linuxppc-embedded@ozlabs.org
RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
Ah, thanks mike... you knocked the answer loose out of my brain...
In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary.
The platform data structure contains entries for both, with the correct ones being ignored. In order to get the code to compile, there are some defines in xparameters.h which have:
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif
after including xparameter_ml403.h
I'm guessing maybe you overwrote the xparameters.h file and got rid of these redefines? You can define it to be whatever you want, since the value will be ignored if you are using SDMA.
In EDK 10.1, the BSP generator will always generate all the defines (even ones which are not sensible in the current configuration), which avoids the above annoyances.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.
thanks
________________________________
Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
_________________________________________________________________
Like solving puzzles? Then you'll love Flexicon! Play now!
http://g.msn.ca/ca55/213
[-- Attachment #2: Type: text/html, Size: 5973 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix PMU + soft interrupt disable bug
From: Benjamin Herrenschmidt @ 2008-03-17 8:51 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080317042709.GA10594@kryten>
On Sun, 2008-03-16 at 23:27 -0500, Anton Blanchard wrote:
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kernel stack SLB into another slot.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> ---
>
> Index: kernel/arch/powerpc/mm/slb.c
> ===================================================================
> --- kernel.orig/arch/powerpc/mm/slb.c 2007-11-05 11:22:03.000000000 -0600
> +++ kernel/arch/powerpc/mm/slb.c 2007-11-05 18:09:45.000000000 -0600
> @@ -113,6 +113,12 @@ void slb_flush_and_rebolt(void)
> slb_shadow_update(get_paca()->kstack, lflags, 2);
> }
>
> + /*
> + * We can't take a PMU exception in the following code, so hard
> + * disable interrupts.
> + */
> + hard_irq_disable();
> +
> /* We need to do this all in asm, so we're sure we don't touch
> * the stack between the slbia and rebolting it. */
> asm volatile("isync\n"
> Index: kernel/arch/powerpc/kernel/process.c
> ===================================================================
> --- kernel.orig/arch/powerpc/kernel/process.c 2007-11-05 18:10:44.000000000 -0600
> +++ kernel/arch/powerpc/kernel/process.c 2007-11-05 18:10:46.000000000 -0600
> @@ -331,6 +331,12 @@ struct task_struct *__switch_to(struct t
> account_process_vtime(current);
> calculate_steal_time();
>
> + /*
> + * We can't take a PMU exception inside _switch() since there is a
> + * window where the kernel stack SLB and the kernel stack are out
> + * of sync. Hard disable here.
> + */
> + hard_irq_disable();
> last = _switch(old_thread, new_thread);
>
> local_irq_restore(flags);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 43, Issue 27
From: Antoine BRUNET @ 2008-03-17 8:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: mamsadegh
In-Reply-To: <mailman.1.1205629203.1697.linuxppc-embedded@ozlabs.org>
Hi,
Your problem is simple, you just have to add one interruption in your BSP
EDK.
Regerate the bitstream and xparamters. And compile your kernel with the new
xparameters file.
And it will be ok.
Date: Sat, 15 Mar 2008 08:30:31 +0000
From: Mohammad Sadegh Sadri <mamsadegh@hotmail.com>
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
To: <linuxppc-embedded@ozlabs.org>
Message-ID: <BAY115-W186EA84A950C17657AD8D9B20B0@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components, I generate the software libraries
and copy xparameters file into proper kernel folder. I configure that kernel
and add kernel support for XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h file
but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel compilation,
don't know the correct value for it of course.
thanks
_________________________________________________________________
Create a handy button so your friends can add U to their buddy list. Try it
now!
http://g.msn.ca/ca55/211
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080315/565821b8
/attachment.html>
------------------------------
^ permalink raw reply
* XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-17 7:35 UTC (permalink / raw)
To: linuxppc-embedded
HI all,
Is anyone have the opb_emac (no DMA) work with the kernel linux-2.6-xlnx
from git.xilinx.com.
the message seams that it does work ,but the command ping return nothing!
Could you kindly suggest me what to do?
ps:
the kernel booting message
[ 0.258674] net_namespace: 64 bytes
[ 0.269780] NET: Registered protocol family 16
[ 0.290415] Registering device xilinx_emac:0
[ 0.381687] NET: Registered protocol family 2
[ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.399556] TCP established hash table entries: 8192 (order: 4, 65536
bytes)
[ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.405409] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.405489] TCP reno registered
[ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.413189] Call Trace:
[ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184 (unreliable)
[ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
[ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
[ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
[ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
[ 0.414141] [cf41ff70] [c01e4b1c] register_ppc_htab_sysctl+0x18/0x2c
[ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
[ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
[ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0: 0: 0:
0
[ 1.123790] XEmac: using fifo mode.
[ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
0x78e2.
[ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
[ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to 0xD0020000,
irq=2
[ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
[ 1.194661] TCP cubic registered
[ 1.198647] NET: Registered protocol family 1
[ 1.203728] NET: Registered protocol family 17
#ping 192.168.26.1 &
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
inet addr:192.168.26.127 Bcast:192.168.26.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
Interrupt:2 Memory:40c00000-40c0ffff
Regards
Qin Lin
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16089631.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Kernel stack overflow in process xxxx
From: jay_chen @ 2008-03-17 7:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <017e01c887fe$41395b20$016ffea9@alphajay>
By the way, is there any skill/tool to avoid/detect/check this kind of
problem?
Jay Chen...
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Monday, March 17, 2008 3:12 PM
To: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] Kernel stack overflow in process xxxx (This message
should be blocked: ctfkl59804)
Hello all:
I am using mpc8548 and, kernel 2.6.14.5.
Recently, my system encounter "Kernel stack overflow in process xxxx"
problem.
How to increase the kernel stack size?
I try to modify THREAD_SIZE in thread_info.h, but my system seems couldn't
boot up anymore!
//#define THREAD_SIZE 8192 /* 2 pages */
#define THREAD_SIZE 16384 /* 4 pages */
Thanks in advance for any kind of advice.
Jay Chen...
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Kernel stack overflow in process xxxx
From: jay_chen @ 2008-03-17 7:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello all:
I am using mpc8548 and, kernel 2.6.14.5.
Recently, my system encounter "Kernel stack overflow in process xxxx"
problem.
How to increase the kernel stack size?
I try to modify THREAD_SIZE in thread_info.h, but my system seems couldn't
boot up anymore!
//#define THREAD_SIZE 8192 /* 2 pages */
#define THREAD_SIZE 16384 /* 4 pages */
Thanks in advance for any kind of advice.
Jay Chen...
^ permalink raw reply
* dtc: Cleanup \nnn and \xNN string escape handling
From: David Gibson @ 2008-03-17 6:03 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Several small cleanups to the handling of octal and hex string
escapes:
- Use strncmp() instead dof what were essentially open-coded
versions of the same, with short fixed lengths.
- The call path to get_oct_char() means an empty escape is not
possible. So replace the error message in this case with an
assert.
- Use die() instead of a non-fatal error message if
get_hex_char() is given an empty escape. Change error
message to close match gcc's in the same circumstance.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
data.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2008-03-17 16:37:04.000000000 +1100
+++ dtc/data.c 2008-03-17 16:37:04.000000000 +1100
@@ -75,16 +75,11 @@ static char get_oct_char(const char *s,
long val;
x[3] = '\0';
- x[0] = s[(*i)];
- if (x[0]) {
- x[1] = s[(*i)+1];
- if (x[1])
- x[2] = s[(*i)+2];
- }
+ strncpy(x, s + *i, 3);
val = strtol(x, &endx, 8);
- if ((endx - x) == 0)
- fprintf(stderr, "Empty \\nnn escape\n");
+
+ assert(endx > x);
(*i) += endx - x;
return val;
@@ -97,13 +92,11 @@ static char get_hex_char(const char *s,
long val;
x[2] = '\0';
- x[0] = s[(*i)];
- if (x[0])
- x[1] = s[(*i)+1];
+ strncpy(x, s + *i, 2);
val = strtol(x, &endx, 16);
- if ((endx - x) == 0)
- fprintf(stderr, "Empty \\x escape\n");
+ if (!(endx > x))
+ die("\\x used with no following hex digits\n");
(*i) += endx - x;
return val;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2.6.26] Update wait_state_cycles in the VPA.
From: Tony Breeds @ 2008-03-17 5:23 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
The hypervisor can look at the value in wait_state_cycles for an estimate of
how busy dedicated processors are. Currently as the kernel never touches this
field so we appear to be 100% busy. Record the duration the kernel is in
powersave and pass that to the HV to provide a reasonable indication of
utilisation.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/setup.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index fdb9b1c..90555a3 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -393,6 +393,7 @@ static void pseries_dedicated_idle_sleep(void)
{
unsigned int cpu = smp_processor_id();
unsigned long start_snooze;
+ unsigned long in_purr, out_purr;
/*
* Indicate to the HV that we are idle. Now would be
@@ -400,6 +401,7 @@ static void pseries_dedicated_idle_sleep(void)
*/
get_lppaca()->idle = 1;
get_lppaca()->donate_dedicated_cpu = 1;
+ in_purr = mfspr(SPRN_PURR);
/*
* We come in with interrupts disabled, and need_resched()
@@ -432,6 +434,8 @@ static void pseries_dedicated_idle_sleep(void)
out:
HMT_medium();
+ out_purr = mfspr(SPRN_PURR);
+ get_lppaca()->wait_state_cycles += out_purr - in_purr;
get_lppaca()->donate_dedicated_cpu = 0;
get_lppaca()->idle = 0;
}
--
1.5.4.3
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply related
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