Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Henk, On Freitag, 20. Februar 2009, Henk Stegeman wrote: - Any suggestions to what could be wrong here? Or does the MPC5200 in this case only byte swap u16 reads, but a u8 read is unchanged? You should not follow the Freescale bus signal names when you connect your external little endian device. Otherwise the offsets are always wrong. Do it in this way instead: MPC LE Device D[0..7] - D[24..31] D[8..15] - D[16..23] D[16..23] - D[8..15] D[24..31] - D[0..7] If you connect your device in such a way, just enable CS's byte swap feature depending on your bus size and you are done (no additional software manipulation required). Now you can write bytes, words or longs and you will always write the correct data into the corresponding device register. Hope it helps Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: remove sysfs debug file from GPT driver
On Fri, Mar 06, 2009 at 01:31:41PM -0700, Grant Likely wrote: Wolfram, you were right. This was a bad idea. I just took me a bit longer to clue into it. Instant ACK :D Thanks! Acked-by: Wolfram Sang w.s...@pengutronix.de -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
Hello, But the question remains: Why do you need simpleboot support for Yosemite when you can use a uImage or cuImage with u-boot? We are developing a new board based upon the Yosemite board. Seeing as though the Yosemite board was supported in the mainline kernel I decided to start with that code base. After looking at what different options/images were available for device trees vs open firmware I decided the simpleImage would be the ideal format for our new board. I then read how to build a simpleImage for the Yosemite board, which build without any compiler errors. Although I found the image didn't work, so I figured it might be helpful for others if the image just worked without modifications. Although shortly I will be submitting support for our custom board using this same approach. So if you have any suggestions on this approach using the simpleImage please let me know. On another note, can you tell me/point me to some documentation on how to get a unique machine ID for a new board? -- Best Regards, Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200 16525 East Laser Drive | fax: (480) 837-5300 Fountain Hills, AZ 85268 | web: www.embeddedARM.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
Hello, On a more general note; this patch also diverges from the original model for simple image. The idea behind simpleimage was that it would contain a fully formed device tree, with no fixups necessary. I want to think carefully before diverging from that. I wasn't aware of these design goals... I believe one can also modify the default dts file such that the RAM size is not dynamically detected so the fixups aren't required(although keep in mind I haven't tested this). Although it is quite convenient to add the fixed-head.o so one can jump into the simpleImage at offset 0 rather than having to check what the offset should be each time a change is made. //Eddie ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Sat, Mar 7, 2009 at 8:21 AM, Eddie Dawydiuk ed...@embeddedarm.com wrote: Hello, On a more general note; this patch also diverges from the original model for simple image. The idea behind simpleimage was that it would contain a fully formed device tree, with no fixups necessary. I want to think carefully before diverging from that. I wasn't aware of these design goals... I believe one can also modify the default dts file such that the RAM size is not dynamically detected so the fixups aren't required(although keep in mind I haven't tested this). Just to be clear, I'm not saying 'no'. I'm just not saying 'yes' yet either. However, if you can fully form the dts file then that is definitely my preference. Although it is quite convenient to add the fixed-head.o so one can jump into the simpleImage at offset 0 rather than having to check what the offset should be each time a change is made. The missing fixed-head thing is a bug. I have no issue with that change. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Sat, Mar 7, 2009 at 8:14 AM, Eddie Dawydiuk ed...@embeddedarm.com wrote: Hello, But the question remains: Why do you need simpleboot support for Yosemite when you can use a uImage or cuImage with u-boot? We are developing a new board based upon the Yosemite board. Seeing as though the Yosemite board was supported in the mainline kernel I decided to start with that code base. After looking at what different options/images were available for device trees vs open firmware I decided the simpleImage would be the ideal format for our new board. I then read how to build a simpleImage for the Yosemite board, which build without any compiler errors. Although I found the image didn't work, so I figured it might be helpful for others if the image just worked without modifications. Although shortly I will be submitting support for our custom board using this same approach. So if you have any suggestions on this approach using the simpleImage please let me know. Before I answer this, what bootloader are you using? On another note, can you tell me/point me to some documentation on how to get a unique machine ID for a new board? What do you mean? Are you referring to the top level compatible and model properties? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
Hello, So if you have any suggestions on this approach using the simpleImage please let me know. Before I answer this, what bootloader are you using? We are using a custom bootloader we developed ourselves. The bootloader is very minimal as one of our primary design goals is a fast boot time. We do some basic initialization of the AMCC 440EP, then load the simpleImage into RAM at address 0 and jump into it. In my mind I had considered our code as more of a bootrom and the simpleboot.c as a bootloader ;) On another note, can you tell me/point me to some documentation on how to get a unique machine ID for a new board? What do you mean? Are you referring to the top level compatible and model properties? I think I might be getting ahead of myself, as I'm not yet up to speed on how the powerpc code base identifies unique machines. For instance the ARM codebase required that each new machine have a unique machine ID. When bringing up a new platform one had to request a new unique machine ID. The bootloader was required to pass this unique machine id to the kernel. We're still using quite a bit of the Yosemite code base and so I had assumed we are probably using the Yosemite boards unique machine id for our custom hardware. Although based on your response it sounds like powerpc uses a different approach. //Eddie ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
On Fri, 2009-03-06 at 10:12 -0600, Ben Menchaca wrote: Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. Maybe they got the documentation for that bit backward ? :-) Cheers, Ben. ACR is 0x00030300. - Ben On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 dave...@freescale.com wrote: Did you enable the descriptor bit 3 to have a try? __ From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 2:10 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited I can look at ACR morning...although I can say with a fair amount of certainty that I have not changed it from the POR value. I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me. What is the hope regarding these two? Some combination I am not seeing? On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 dave...@freescale.com wrote: what is the value of ACR register? __ From: Ben Menchaca [mailto:ben.mench...@gmail.com] Sent: Friday, March 06, 2009 1:38 PM To: Liu Dave-R63238 Cc: linuxppc-dev@ozlabs.org Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited 1. BAT2 in linux is set to WIMG=0010, and covers all 64M 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. 4. OWAR0 is set to 0xF005, so NSNP is 0. 5. The DMA descriptor (randomly chosen when I hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. Core is 400MHz, and CSB is 133MHz. - Ben On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 dave...@freescale.com wrote: and what settings is DMA description bit 3? -Original Message- From: linuxppc-dev-bounces +daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces +daveliu=freescale@ozlabs.org] On Behalf Of Liu Dave-R63238 Sent: Friday, March 06, 2009 1:22 PM To: Ben Menchaca; linuxppc-dev@ozlabs.org Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and
Re: [PATCH] powerpc/usb: Fix 440EPx USBH_3 USBH_5 EHCI errata
On Fri, 2009-03-06 at 11:30 +, - Reyneke wrote:
Patch applies to 440EPx devices in USB EHCI host mode (USB 2.0).
From the 440EPx errata:
USBH_3: Host hangs after underrun or overrun occurs
USBH_5: EHCI0_INSNREGxx registers are reset by a Soft or Light Host
Controller Reset
Workround for USBH_3 is to enable Break Memory Transfer (BMT) in INSNREG3.
But the controller is reset after this fix is applied, and thus the current
workround is lost. The following short patch ensures INSNREG3 is correctly
set after reset.
Signed-off-by: Jan Reyneke
Please provide a valid email address here.
---
ehci-hcd.c|7 +++
ehci-ppc-of.c | 30 +++---
ehci.h|5 +
3 files changed, 31 insertions(+), 11 deletions(-)
diff -uprN a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h2009-03-04 01:05:22.0 +
+++ b/drivers/usb/host/ehci.h2009-03-06 10:52:53.0 +
@@ -137,6 +137,11 @@ struct ehci_hcd {/* one per controlle
u8sbrn;/* packed release number */
+#if defined(CONFIG_440EPX)
+#define PPC440EPX_EHCI0_INSREG_BMT(0x1 0)
+__iomem u32 *insn_regs;/* INSNREGx device memory/io */
+#endif
I don't think you need the above based on what you do later on...
(see comments below)
/* irq statistics */
#ifdef EHCI_STATS
struct ehci_statsstats;
diff -uprN a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c2009-03-04 01:05:22.0 +
+++ b/drivers/usb/host/ehci-hcd.c2009-03-06 10:54:36.0 +
@@ -217,6 +217,13 @@ static int ehci_reset (struct ehci_hcd *
if (ehci_is_TDI(ehci))
tdi_reset (ehci);
+#if defined(CONFIG_440EPX)
+/* USBH_5: INSN values are lost on reset - redo USBH_3.
+ See also ppc44x_enable_bmt.*/
+if (ehci-insn_regs)
+out_be32(ehci-insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
+#endif
A few issues here. First, it would be preferable to have this in the
ehci-ppc-of.c file. If you can't stick that in such a place that it will
be called after ehci_reset, then maybe you can add a reset hook so
that ehci-ppc-of.c gets to wrap the real ehci_reset().
Also, while the ifdef CONFIG_440EPX is good to prevent building the code
on machines that don't need it, it's also not enough. We allow building
kernels that support multiple boards and SoC's within the same major CPU
family and thus you -also- need runtime detection. Either using a quirk
(I think the USB drivers have quirk flags) or just always doing the
of_device_is_compatible() thingy which is yet another reason for finding
a way to move that up into ehci-ppc-of.c
That would also avoid some duplication...
/*
- * 440EPx Errata USBH_3
- * Fix: Enable Break Memory Transfer (BMT) in INSNREG3
- */
-#define PPC440EPX_EHCI0_INSREG_BMT(0x1 0)
+ * 440EPx Errata USBH_3 USBH_5
+ * Fix: Enable Break Memory Transfer (BMT) in INSNREG3. Also cache
+ * the registers so we can redo the USBH_3 fix on future resets */
static int __devinit
-ppc44x_enable_bmt(struct device_node *dn)
+ppc44x_enable_bmt(struct device_node *dn, struct ehci_hcd* ehci)
{
-__iomem u32 *insreg_virt;
-insreg_virt = of_iomap(dn, 1);
-if (!insreg_virt)
+#if defined(CONFIG_440EPX)
+
+ehci-insn_regs = of_iomap(dn, 1);
+if (!ehci-insn_regs)
return -EINVAL;
-out_be32(insreg_virt + 3, PPC440EPX_EHCI0_INSREG_BMT);
+out_be32(ehci-insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
-iounmap(insreg_virt);
+#endif
return 0;
+
}
So if you manage to move the quirk here, you can thus re-use the
existing code, or is the reset always called in a context where you
can't iomap ? (ie with a spinlock held).
In any case, I don't like adding a specific field to the generic ehci
structure like that. If that's what it takes, add a void
*platform_private to it, and use -that- to stick a host specific data
structure, but for something not performance sensitive such as a reset,
if you can get away with always mapping/unmapping, it's probably better.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
KGDB over serial on xilinx virtex-5 (ppc440)
Hi all, Has anybody tested KGDBOC in linux-2.6.28 for Xilinx Virtex-5 PowerPC target boards.. I just see that KGDB waits for remote connection from GDB host, but unfortunately Command line arguments were : console=ttyS0 ip=bootp root=/dev/nfs rw kgdboc=ttyS0 kgdbwait The test is been done on xilinx virtex-5 ppc440 target Target side: Serial: 8250/16550 driver4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 16) is a 16550A console [ttyS0] enabled kgdb: Registered I/O driver kgdboc. kgdb: Waiting for connection from remote gdb... -- Host side -- (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Timed out. Timed out. Timed out . . -- Is anything else need to be implemented for ppc44x for KGDB to work ? -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
On Sat, Mar 7, 2009 at 3:51 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-03-06 at 10:12 -0600, Ben Menchaca wrote: Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. Maybe they got the documentation for that bit backward ? :-) For posterity...it does appear that this is the case. I don't have a bus analyzer to watch the transaction, but a JTAG trigger caught the update happening if and only if bit 3 was set in the (R|W)DMA descriptor. My FAE at FS said he is watching this thread, so hopefully some doc errata can be generated so others can avoid my confusion :-). - Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Sat, Mar 7, 2009 at 9:37 AM, Eddie Dawydiuk ed...@embeddedarm.com wrote: Hello, So if you have any suggestions on this approach using the simpleImage please let me know. Before I answer this, what bootloader are you using? We are using a custom bootloader we developed ourselves. The bootloader is very minimal as one of our primary design goals is a fast boot time. We do some basic initialization of the AMCC 440EP, then load the simpleImage into RAM at address 0 and jump into it. In my mind I had considered our code as more of a bootrom and the simpleboot.c as a bootloader ;) On another note, can you tell me/point me to some documentation on how to get a unique machine ID for a new board? What do you mean? Are you referring to the top level compatible and model properties? I think I might be getting ahead of myself, as I'm not yet up to speed on how the powerpc code base identifies unique machines. For instance the ARM codebase required that each new machine have a unique machine ID. When bringing up a new platform one had to request a new unique machine ID. The bootloader was required to pass this unique machine id to the kernel. We're still using quite a bit of the Yosemite code base and so I had assumed we are probably using the Yosemite boards unique machine id for our custom hardware. Although based on your response it sounds like powerpc uses a different approach. The powerpc kernel completely trusts the device tree blob that is passed to it at boot time. Most of the platform support code simply reads the top level 'compatible' property to decide whether or not it can support the board. For example, arch/powerpc/platforms/44x/ppc4xx_simple.c supports a bunch of boards, including yosemite, and arch/powerpc/platforms/44x/ebony.c only supports the ebony board. ppc4xx_simple.c, ebony.c, and other platform support files can selected at the same time to build a kernel which supports multiple boards (multi-platform). Since there is no common boot mechanism shared between all powerpc platforms, the bootwrapper is the adapter layer from whatever data is provided by firmware to the form required by the kernel. As long as the kernel-proper (vmlinux) receives a fully formed device tree at the end, it is happy. Both firmware and the boot wrapper have the option of modifying the device tree before passing it on to the next step. One of the boot methods (uImage) even bypasses the bootwrapper step entirely since U-Boot is able to pass a fully formed device tree directly to the kernel. One of the advantages of the device tree scheme is that the kernel image format no longer needs to be board dependent. There is no need to encode a board specific format anymore. Sure, you *can* use simpleImage or dtbImage to build an image with an embedded dtb, but those images are really just compatibility layers for existing firmware, and using them throws away the advantage of splitting the hardware description from the kernel image. Not to mention that the building of board specific images is a maze of special cases and barely documented heuristics in arch/powerpc/boot/wrapper. If you've got control over your boot firmware, and you don't want to use U-Boot, then I strongly recommend that at the very least you keep the .dtb separate from the kernel image and don't write any board specific code in the boot wrapper. Keep your board specific code in arch/powerpc/platforms/44x/* where it is easy for mere mortals to comprehend. Get the firmware to copy both the dtb and kernel into RAM and pass the dtb pointer to the kernel. Ideally, you should use the existing uImage format so you don't need to define something new (and incompatible with anything else). However, parsing uImage requires your firmware to include gunzip code. Failing that, create a new zImage target (perhaps 'zImage.fdt') that accepts a pointer to the .dtb blob in memory. Use the calling convention described in Documentation/powerpc/booting-without-of.txt for direct flattened device tree booting. At least that way your code has a fighting chance of being useful to someone else. Code to do this should be pretty trivial. In fact the simpleImage platform_init could be refactored to provide a large chunk of common code. Only difference really being the source pointer to the dtb. Heck, you could even eliminate the boot wrapper entirely and use the vmlinux image directly; but the kernel image can be quite large and then you'd probably want it gzipped (which means our firmware must be able to gunzip it). One last think. It's not a good idea to link the .dtb image into the firmware either. Many people have learned the hard way that device trees often need to be tweaked after the firmware is deployed. Make the dtb a separate image that can be updated in the same way that the kernel image can be updated. Have fun, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
