Re: Device Tree setup for 8272-based board
Daniel Ng wrote: Scott Wood freescale.com> writes: cuboot-824x is for 8240, 8245, and similar chips. You want cuboot-pq2. Hi Scott et al, I seem to get further with the cuboot-824x file- with the cuboot-pq2 file Nonetheless, cuboot-pq2 is the correct one. the boot sequence doesn't even reach the 'zImage starting' stage. The machine reboots just before it should be printing out 'zImage starting'. What does it print before it reboots? Try disabling the PCI and localbus setup. Is there a way I can get more detailed debug to see what's happening? printf(). :-) Do settings from bd_info struct override the settings from the DTS file? Yes. Also, a lot of the settings passed from u-boot in our 2.6.14 environment are plain wrong eg. wrong memory, wrong processor speed. In this case, the correct settings are set elsewhere (for memory, it is a kernel parameter ie. mem=32M, and the processor speed is set in the 2.6.14 'make menuconfig'). Therefore, the machine still boots into Linux correctly. For 2.6.27, would these incorrect settings be causing my problems? Yes, if u-boot is providing junk, then you'll probably want to hack up the wrapper to ignore it. Or just upgrade u-boot to one that works. :-) -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: uboot 1.3.0 compatible with linux 2.6.21?
Joe Shmo wrote: I'm using a board that is a derivative of the 8313ERDB board. The freescale BSP for that board included a patched uboot 1.1.6 that works with the 2.6.21 kernel. [snip] I've changed the DTS file describing our hardware and recompiled it, but no luck. I'm wondering if the different versions of uboot manipulate the DTS file in different ways and there may not be a way for these two versions to run together. That's the main question here. Yes, there have been some changes. U-boot is probably looking for network aliases to fill in the MAC addresses. At the very least, use a newer DTS file; better yet, use the latest upstream u-boot and kernel rather than anything from the BSP (unless there's something you really need that isn't upstream). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device Tree setup for 8272-based board
Daniel Ng wrote: Thanks for your helpful responses Scott and Ming Qian. Now, from reading the docco can you please verify my understanding is correct?- First, I need a basic DTS file which will give me a basic Device Tree. The cuboot*.c file takes care of adding other parameters to the Device Tree passed from u-boot via the old bd_info struct. Is this correct? Yes. If so, would it be possible to do away with the DTS file altogether? How, other than by encoding all the information about the board in code rather than data, which would be a step backwards? On the other hand, would it be possible to do away with the cuboot*.c file by providing a complete DTS file? Yes, though that eliminates the ability to dynamically set certain parameters from the firmware. Better is to use an up-to-date u-boot, and have u-boot fill in the dynamic fields (MAC address, clocks, command line, etc) directly. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device Tree setup for 8272-based board
Daniel Ng wrote: We are migrating our PowerPC 8272-based board from 2.6.14 to 2.6.27. One of the big changes is the need for a Device Tree for bootup. So far, my bootup looks like the below (using u-boot). I am just using arch/powerpc/boot/cuboot-824x.c cuboot-824x is for 8240, 8245, and similar chips. You want cuboot-pq2. When I change the settings in mpc8272ads.dts and do a fresh recompile, the settings do not change. However, if I use another cuboot*.c file, I get a different set of printed settings eg. 2 ethernet ports instead of 1. This is fine, but I don't see where in the cuboot*.c file these settings are specified. Can someone suggest where these might be? The cuboot file defines things like TARGET_CPM2 or TARGET_824x, which influences the compilation of the bd_t struct. It's messy, which is why we use device trees now. :-) -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: which irqflag to use with request_irq
liran raz wrote: hi, When using the function: int request_irq (unsigned int irq, irq_handler_t handler, unsigned long irqflags, const char * devname, void * dev_id); To connect an ISR to one of the processor's peripherals irq (SCC in my case). Which value I should use for irqflags, from the list in: interrupt.h file. Just pass zero (or IRQF_SHARED if the IRQ is shared, but it shouldn't be in this case). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help with DTS file on MPC8313e-rdb board
Joe Shmo wrote: What I don't know is what reg = <4> means. Is that the phy address or the interrupt? It's the PHY address. My phy is the National semi dp83848. It does not use an IRQ. Should I replace this with zero? Should I take that line out of the DTS file? You should remove the interrupts and interrupt-parent properties. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Async DMA question regarding dma_async_memcpy_buf_to_buf
[EMAIL PROTECTED] wrote: Maybe (with you clarification) this is starting to make sense. It doesn't matter if the "src" is host memory or PCI space. What the "src" and it's DMA_TO_DEVICE mapping is saying to the kernel is "this data needs to be moved into the DMA engine", while the "dest" and it's DMA_FROM_DEIVCE mapping is telling the kernel "this data needs to be moved from the DMA engine". Right. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Async DMA question regarding dma_async_memcpy_buf_to_buf
[EMAIL PROTECTED] wrote: Hummm, let me try again, I may be tripping up on my ignorance of the kernel. According to Linux Device Drivers 3, the DMA_TO/FROM_DEVICE macros impact when the dma_map/unmap_single functions copy data and do cache flushes to ensure cache coherency. DMA_TO_DEVICE tells dma_map_single() to ensure that all data is copied out to memory and cache is flushed before doing the transfer and DMA_FROM_DEVICE tell dma_unmap_single() to ensure all data is in main memory after the transfer. Right. (My understanding is that this is really only important on archs that use bounce buffers which I'm not). It's also important on architectures where DMA is non-coherent (mpc83xx DMA is coherent). So, no as far as "the device" (and I do mean the DMA engine) is concerned, the "mapping" of the src and dest pointers make zero difference, the hardware doesn't care since it's just acting on raw addresses. However, it does (or at least I think it does) matter to the kernel and making sure that the cache doesn't get screwed up. Right. But it sounds like you're saying those macros are unimportant. No, they're very important on certain hardware. Can dma_async_memcpy_buf_to_buf() _safely_ be used to DMA either direction (CPU <=> peripheral) _without_ cache coherency problems? Any given memcpy operation involves *both* directions. Data is copied out of host memory into the DMA engine's internal buffer (this is the src mapping), and then it its copied back into host memory at a different address (this is the dest mapping). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Async DMA question regarding dma_async_memcpy_buf_to_buf
[EMAIL PROTECTED] wrote: Yes, I understand the directions and what they apply to, that's obvious from the macros themselves. What I don't understand is if it's safe, from a kernel/cache standpoint, to pass to the function a src pointer coming _from_ the device and a dest pointer that's going _to_ the device? In other words, can I use this function to _write_ to a DMA slave? If not, there's a functionality missing from the async DMA engine. What exactly do you mean by "the device"? if it's the DMA engine, then that's a meaningless request, by the definition of "source" and "destination". If you mean some other device that happens to be providing a buffer for you to DMA into or out of, that's irrelevant to the DMA API; it's just memory that happens to live somewhere else (and possibly not be cached). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Async DMA question regarding dma_async_memcpy_buf_to_buf
[EMAIL PROTECTED] wrote: The hardware doesn't care (I'm using an MPC8347E), as far as the DMA engine is concerned these are just addresses. All of this goes to cache coherency. The map/unmap functions are supposed to ensure that data is copied and caches flushed at the right times to ensure cache coherency. So the question is this; is the dma_async_memcpy_buf_to_buf() function intended to be bi-directional and is it safe to pass it a 'src' pointer that's actually coming from the device, or does there need to be a second function for doing a copy from the device to the CPU? The "device" is the DMA engine, thus src is inherently going to the device and dest is inherently coming from the device. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8349 DMA
jay_chen wrote: Thanks for your help. Could you give some hints about how to "map your memory as coherence-required"? The M bit needs to be set in the BATs and PTEs. Current kernels do this; I don't know about really old ones such as 2.6.14. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: command line partition information
Joaquin Luna wrote: U-boot did not accept "ff80.flash" as the MTD ID and could not load the kernel image with that in the command line. Why would u-boot care what you pass to the Linux command line? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: command line partition information
Joaquin Luna wrote: I do not list any partitions in my dts file, though I tried and not seen any change in the behavior. I have enabled the option in the kernel to parse the partition information from the kernel command line, is there something else I need to do to set up the mtdblockX devices? Did you enable CONFIG_MTD_OF_PARTS for device-tree-based partitions? mtdparts=mtdparts=nand0:2m(u-boot),3M(kernel),128K(dtb),30M(jffs2),32M(mycust),90M(myfs),90M(myfs2) Try replacing "nand0" with "ff80.flash". -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ifconfig: SIOCSIFNETMASK: No such device (xupv2p+ppc+linux 2.6.27-rc)
saadia dhouib wrote: Device Tree Probing 'ethernet' xilinx_emac 40c0.ethernet: no IRQ found. This might be a problem. root:~> ifconfig 172.25.49.123 netmask 255.255.255.0 ifconfig: SIOCSIFNETMASK: No such device root:~> ### Application running ... My question is: why I can't assign an IP address ?? ifconfig eth0 172... -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: problems loading 2.6.25 kernel onto PQ2FADS-VR board
Jyotshna Cherukuri wrote: Bytes transferred = 12288 (3000 hex) => bootm 40 - 80 ## Booting image at 0040 ... Image Name: Linux-2.6.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1624845 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x80 Loading Device Tree to 007fc000, end 007fefff ... OK And Then it stops. The board doesn't print anything else. Can anyone please help me to whats going on and to what I need to enable to see some debug info on the serial port ( minicom in my case ). P.S : I did enable all the early level debugging in the kernel but yet I dont see anything on the console. Make sure that CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is set properly for u-boot; it probably wants 0xf088. The default vaule corresponds to cuImage. If that doens't help, try booting the cuImage (without passing a device tree from u-boot); it's what I tested with as there was no device tree aware u-boot for this board at the time. If that works and uImage doesn't, then there may be a mismatch between what u-boot is setting up in the device tree and what the kernel expects. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8349 DMA
jay_chen wrote:
I am using 2.6.14.5 and MPC8349.
I got some DMA problems with PCI devices.
So, I tried to understand the DMA stuff of linux.
That's very old; have you tried the latest kernel?
I have one question about cache coherency.
In dma-mapping.h, I found some functions are defined as NULL.
For example:
#define dma_cache_inv(_start,_size) do { } while (0)
#define dma_cache_wback(_start,_size) do { } while (0)
#define dma_cache_wback_inv(_start,_size) do { } while (0)
#define __dma_alloc_coherent(gfp, size, handle) NULL
#define __dma_free_coherent(size, addr) do { } while (0)
#define __dma_sync(addr, size, rw) do { } while (0)
#define __dma_sync_page(pg, off, sz, rw) do { } while (0)
Does this mean that I don't need to take care of cache coherency in
MPC83xx platform?
So, I could use any range of memory for DMA transferring and the
hardware will take care of the cache coherency for me?
Yes, however it's still a good idea to call the DMA functions in case
the code gets run on hardware that doesn't have coherent DMA, or that
needs special DMA mapping for highmem.
Make sure that the PCI bridge is configured to snoop, and that you map
your memory as coherence-required (normally not necessary on
uniprocessor, but there's some weirdness in the 82xx/83xx PCI controller
that requires it).
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to register an interrupt under linux?
wael showair wrote: Dear all, First here is the setup i've: 1. The board is SPTWIMAX-CC1E board 2. The processor is MPC8555 i found it in the powerpc family NOT ppc family. Also the board contains DSP core. 3. Linux Kernel 2.6.19-rc5 running on the MPC8555 processor side. That's rather old... I aim to let the DSP processor interrupts the MPC8555 processor so i think the first step is to register an interrupt handler for an interrupt number. i found this in the linux API request_irq. so i make a simple module & write in it request_irq(4,my_handler,SA_INTERRUPT,"DSP",NULL); but unfortunately it returns -ENOSYS. If we had a FAQ, this would be entry #1. request_irq() takes virtual IRQ numbers, not hardware numbers of some specific PIC. You need to create a mapping, typically via the device tree. Google should be able to provide more details. i have tracked the error & i found this is because the irq_chip structure was not set. so i added the API of set_irq_chip as follows: irqChip.enable = NULL; irqChip.disable = NULL; irqChip.startup = NULL; irqChip.shutdown = NULL; That's kind of like commenting out every line with an error until the code builds. :-P but unfortunately when i tried to insert my module i got a segmentation fault. That tends to happen if you tell the kernel to call a NULL pointer. i have tracked it & i found this is because of the unmask function of my interrupt irq_chip was not set. so do i have to implement it No, it's already implemented in the MPIC driver. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using DMA
[EMAIL PROTECTED] wrote: In the Cafe driver, Linux Device Drivers 3rd Edition, and DMA-mapping.txt everyone talks about how to allocate buffers using dma/pci_alloc_coherent(), but no one talks about how to actually use it. I'm pretty sure (even in my ignorance) that just allocating a DMA coherent buffer and then copying in and out of it does NOT actually engage the underlying hardware and perform a DMA transfer. Generally, you program the device itself to peform the transfer. I'm assuming that your custom NAND controller can't do DMA by itself, though. With some digging I've found the Freescale Elo/Elo Plus DMA driver which supports my processor. What I'm not clear on is how to actually make use of it. How do I tie my NAND driver to the Freescale DMA driver and actually get the hardware to work? Any pointers are greatly appreciated. Tell the DMA controller where to move data from, and where to move it to. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: i2c driver's probe routine not getting called
Laxmikant Rashinkar wrote: I have linux-2.6.27.1 running on a MPC8347 based board. When my freescale I2C driver is insmoded, it calls platform_driver_register() successfully, but the probe routine doesn't get called. Is "your" freescale I2C driver different from "the" freescale I2C driver in drivers/i2c/busses/i2c-mpc.c? If so, you'll need to update it to be an of_platform driver like the in-tree driver is (or, just switch to the in-tree driver). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8313E RDB: Badness at fs/sysfs/dir.c:463
Joaquin Luna wrote: I am having the same problem with badness at fs/sysfs/dir.c on the MPC8313ERDB. More importantly my custom board based on this development board will not boot past "loading device tree." That's probably unrelated. Are there any other mismerges in this file? Not that I know of. If we fix the dts file how do we fix the official dts file With a patch. and when would that fix be put in place? When the patch is applied. :-) -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8313E RDB: Badness at fs/sysfs/dir.c:463
Mike Dyer wrote: I believe the DMA is being added twice, because it occurs twice within the mpc8313erdb.dts device tree. Once by itself, and once within a sleep-nexus. Is that right / normal ? No, that looks like a mismerge. There should only be the node under sleep-nexus. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: I2C mux and device tree
[added linuxppc-dev for a wider audience] Felix Radensky wrote: I run linux-2.6.26 on custom 460EX based board. This platform has PCA9548 I2C mux on I2C bus 0. I was wondering how can I describe the mux itself and devices behind it (e.g RTC and temperature sensors) in the device tree. Describe it as a node that is both an i2c client and an i2c controller. The Sun i2c binding says that i2c devices should have two reg cells, the first being the bus number within the controller, and the second being a shifted-left-by-one i2c bus address (as opposed to the one-cell non-shifted address we currently use, because the Sun binding wasn't known to us at the time). We could extend of_register_i2c_devices to understand two-cell addresses, and call it once for each sub-bus with the bus number as a parameter. If this is impossible at the moment, what other means exist to work with devices behind the mux ? I have found the pca954x patch and related virtual i2c patch and was able to integrate them intro my kernel. You'll have to update it to be a new-style i2c device, unless there's a newer version floating around that what a quick google search turned up. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ucode/BD conflict on PowerPC 860
Gray, Steve - UK wrote: I have tried a few things, including setting the range of muram to ranges = <0x0 0x3000 0x1000>; Am I correct to assume this will push the muram above the microcode?? No, that will confuse the kernel into thinking that muram starts at IMMR offset 0x3000. You need to change the reg property of the data subnode to <0x1000 0xc00>, so that you restrict the allocation range without affecting the offset that is subtracted from the physical address to obtain the value given to the CPM. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xilininx GPIO
Hello there, I am having difficulties with some xilinx gpios and the xilinx-2.6-xlnx kernel. As far as I can tell the kernel is configured correctly for gpio. I can see that the module_init function "xgpio_init" is called, and that bus_add_driver and driver_add_groups returns without error. But I cannot see that the probe function is called. /proc/misc doesnt list a driver for the gpios. I am not sure where to go next as there is no error printouts. I have seen other peoples consoles stating that the gpio is mapped to xx but this doesn't happen for me. I am using the default bit file for the ml507 board, and have created device files /dev/xgpio0 /dev/xgpio1 etc with major 10 and minor 185 However if I try to open these devices the open fails. I would rally appreciate it if someone could give me some pointers as to what to look for, or how a to go about debugging this. Many thanks Peter Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops in during system run
On Fri, Oct 17, 2008 at 03:49:12PM +0530, Sreejith wrote: > This is a peculiar Oops we are encountering during the running of our board > (sh4) architecture So why are you posting to powerpc lists? > PC : 844240f8 SP : 88d1ff44 SR : 400080f0 TEA : c0169d64Tainted: P With proprietary modules, too. > Give you valuable suggestions!! Debug the code? Switch to powerpc? :-) -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
On Tue, Oct 14, 2008 at 01:39:19PM +1100, Benjamin Herrenschmidt wrote: > So again, let's start by having somebody pick up something that you > believe is worth altivec-ifying, eat the preempt_disable/enable for now, > and if we see that indeed, it's worth the pain, then we can look into > adding a way to context switch altivec in a kernel thread upon explicit > request or something like that. Of course -- my suggestion was predicated on the outcome that the benchmarks do justify it, and was just pointing out that there's no real need to disable preemption. BTW, it's actually simpler than I originally described (I had implemented this years ago in the TimeSys kernel for x86 and some other arches that already use FP or similar resources for memcpy, but the memory was a little fuzzy); the FP restore code doesn't need to test anything, it always restores from the regular spot. The kernel code wishing to use FP saves the user context in an alternate save area (it could even be on the stack, allowing atomic context to use it as well, if it's not too large), and restores it when it's done. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Benjamin Herrenschmidt wrote: It doesn't need to be done in non-preemptible sections, if you have a separate per-thread save area for kernel fp/altivec use (and appropriate flags so an FP unavailable handler knows which regs to restore), and you can avoid using it in a preempting context. Yuck. Hmm? It's simple and achieves the desired result (avoiding non-preemptible regions without unduly restricting the ability to extract performance from the hardware). Would it be nicer to avoid FP/Altivec in the kernel altogether? Sure. If the benchmarking says that we're better off with it, though, then so be it. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
On Sat, Oct 11, 2008 at 09:05:49PM -0500, Matt Sealey wrote: > Benjamin Herrenschmidt wrote: > >The reason where we require a -real-good- reason to do it is > >simply because of the drawbacks. The cost of enabling altivec > >in the kernel can be high (especially if the user is using it) > >and it's not context switched for kernel code (just like the > >FPU) for obvious performance reasons. Thus any use of altivec in the > >kernel must be done within non-preemptible sections, which can > >cause higher latencies in preemptible kernels. It doesn't need to be done in non-preemptible sections, if you have a separate per-thread save area for kernel fp/altivec use (and appropriate flags so an FP unavailable handler knows which regs to restore), and you can avoid using it in a preempting context. In a realtime-configured kernel, preempting contexts should be fairly minimal, so the loss of altivec use is not of critical performance impact (other than one branch to determine if it can be used). In a throughput-configured kernel, do it as you described (disable preemption), and be able to use altivec memcpy in interrupt handlers, and reduce the thread size. > Would the examples (page copy, page clear) be an okay place to do it? > These sections can't be preempted anyway (right?), Why can't they be preempted? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
On Sun, Oct 12, 2008 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2008-10-08 at 12:40 -0500, Scott Wood wrote: > > > > The performance difference most likely comes from the fact that copy > > to/from user can assume that the memory is cacheable, while memcpy is > > occasionally used on cache-inhibited memory -- so dcbz isn't used. We > > may be better off handling the alignment fault on those occasions, and > > we should use dcba on chips that support it. > > Note that the kernel memcpy isn't supposed to be used for non-cacheable > memory. That's what memcpy_to/fromio are for. I agree that it *shouldn't*, but the presence of cacheble_memcpy (used only by the EMAC driver, AFAICT) suggests that it was a concern. > But Paul has a point that for small copies especially, the cost of > the cache instructions outweigh their benefit. Possibly, but what is the overall effect on the system of using them, even if it hurts small copies slightly? How many small copies are of constant size, which could be diverted to another implementation at compile-time? Even run-time diversion may help, as the cost of a small memcpy is only important if you do it many times, in which case the branch will probably be correctly predicted. Given the networking results Dominik posted, I think it's worth a look. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MTD map drivers (FSL UPM NAND)
Alemao wrote: Here is an output from someone using it: - 070500 U-Boot 1.1.2 (May 30 2007 - 20:20:09) Motorola PowerPC Board: GDA Technologies CSC-PP MPC8560 [PowerQUICC III] CPU: 660 MHz CCB: 330 MHz DDR: 165 MHz Creating 7 MTD partitions on "CSC flash": 0x00f8-0x0100 : "uboot" 0x00d0-0x00e0 : "kernel0" 0x00e0-0x00f0 : "kernel1" 0x0070-0x00d0 : "app" 0x-0x0038 : "root0" 0x0038-0x0070 : "root1" 0x00f0-0x00f8 : "env" NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca Scanning device for bad blocks Bad eraseblock 1780 at 0x0de8 Creating 1 MTD partitions on "NAND 256MiB 3,3V 16-bit": 0x-0x1000 : "NAND Partition" - Thats exactly what I want to do. If you say not to use physmap with NAND, how he is doing this? Through the device tree source? I see nothing in that output to suggest that physmap is being used for NAND. NAND is not directly mapped like NOR is; you cannot just give an address range with no knowledge of the controller and expect it to work. Note that if you look in drivers/mtd/maps/physmap.c, the supported probe types are CFI, JEDEC, and ROM. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MTD map drivers (FSL UPM NAND)
Alemao wrote: Hi all, Im trying to use a physmap driver for NOR and NAND flash devices. You can't use physmap with NAND. ranges = <0 0 ff00 100 // nor flash, 16 MB 1 0 6000 400>; // nand flash, 64 MB Is your NAND window really that large? I'm not too familiar with UPM, but typically it'd only be a few KiB. So, how can I load the UPM driver before physmap? Just stop pointing physmap at the NAND. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Failure in re-load module
Duy-Ky Nguyen wrote: release_region(ppc_base,PPC_SIZE); release_region(lbc_base,PPC_SIZE); This should be PPC_BASE/LBC_BASE (the physical address), not ppc_base/lbc_base (the virtual address). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Dominik Bozek wrote: I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313. And the major conclusion is that __copy_tofrom_user is more efficient than memcpy. Sometimes about 40%. If I good understand, the memcpy() just copy the data, while __copy_tofrom_user() take care if the memory wasn't swapped out. There's not much overhead in dealing with bad pointers; it's mostly fixup after the fault. The performance difference most likely comes from the fact that copy to/from user can assume that the memory is cacheable, while memcpy is occasionally used on cache-inhibited memory -- so dcbz isn't used. We may be better off handling the alignment fault on those occasions, and we should use dcba on chips that support it. I'm not sure why we don't use dcbt in memcpy(), as it's just ignored if the memory is cache-inhibited. BTW. The memcpy() maybe optimized as it is on i32 when the size of block is known at compile time. Yes, that would be nice. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: unit name for /soc in device tree
Mike Ditto wrote: I'm starting a scratch port of Linux 2.6 to an MPC8272 board that currently runs 2.4 (MontaVista). Documentation/powerpc/booting-without-of.txt says: The name of an soc node should start with "soc", and the remainder of the name should represent the part number for the soc. For example, the MPC8540's soc node would be called "soc8540". Gah, what's that still doing in there? Ignore it. It's a bad idea, for exactly this reason. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: NOHZ: local_softirq_pending 08
liran raz wrote: hi, I have a driver that uses the scc1 intertupts. After enabling the scc1 interrupts I see this message coming from the kernel for some time: NOHZ: local_softirq_pending 08 1. What is the meaning of this message? does 2. Does it indicate that something is wrong & need a fix? 3. How can I get rid of it? (The interrupt is connected to an ISR by using the standard request_irq() routine). Kernel 2.6.24 Processor: MPC8272 Thanks, Liran. The error comes from generic timer code; I'd test with the latest kernel and then ask on the linux-kernel list. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FS_ENET ERROR(s) 0x12 at second NFS RPC port lookup (100005/1)
Remi Lefevre wrote: Errors encountered are "Underrun" errors (from bd). Try elevating the arbiter priority for the FCC. CPM clock-frequency is not defined in the DTS, neither filled by U-Boot, but it doesn't seem to be needed, does it ? Not for ethernet. I'm a little confused, and find strange that the first UDP request completes correctly, as well as latter ARP ones. If it's bus contention (as underrun implies), then it may happen only under load. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FS_ENET ERROR(s) 0x12 at second NFS RPC port lookup (100005/1)
Remi Lefevre wrote: [5.573391] fs_enet: eth0 FS_ENET ERROR(s) 0x12 This is a transmit error; more detail can be found in the buffer descriptor. Check your pin and clock configuration. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FCC1 failing on large packet PINGS, while FCC2 is successful
embedded wrote: Actually, it may have been a simple fix. Looking at the clocks. We noticed something a little awry; Just rechecking the RM and the code we found that within ep8248.c, the clock setup code had the RX and TX clocks flipped. FCC1 RX CLK should be Clock 10 FCC1 TX CLK should be Clock 11 D'oh! Thanks for finding that. in: arch/powerpc/platforms/82xx/ep8248.c static void __init init_ioports(void) - cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX); - cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX); + cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX); + cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_TX); Acked-by: Scott Wood <[EMAIL PROTECTED]> Post to [EMAIL PROTECTED] and [EMAIL PROTECTED] with a Signed-off-by. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FCC1 failing on large packet PINGS, while FCC2 is successful
embedded wrote: We've found a way to get ping to fail all of the time by increasing the size of the ping messages. When we use the max in Windows of 65500, every ping to the first FCC1 Ethernet is dropped. However, when we ping with a size of 65500 to the second FCC2 Ethernet everything is fine and all echos are successful. In windows: ping -l 64000 172.24.100.11 -t It definitely seems to be a problem with the mpc, but I'm not sure where to look. Board? KErnel? boot loader? The two Ethernet devices should be configured identically, and looking through the kernel code, it seems that there aren't any preferred treatment differences. Could the problem be in the bit-banging mdio control, or should I look within fs_enet? We've got this reproducing on all of our boards and it could also reside in the board setup... Does anyone with experience on the ep8248 and/or mpc8272 family, fs_enet-* code have any ideas where I should look next? It looks very similar to what I was seeing on ep8248 -- the first ethernet port would fail when attempting to receive back-to-back packets. I didn't look into it too closely since I thought it was probably a board issue (I had only one, and the firmware never generated any traffic that resulted in back-to-back receives). I'd be very interested if you ever figure out what's wrong. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Interrupts get disabled on USB access on MPC8272
David Beamonte wrote: I have debugged the kernel and what I can see is that, once the processor tries to send a buffer of the USB controller, interrupts get disabled. And so, there is no ethernet, serial port, or whatever way of communication to the processor. With my debugger I can see that the kernel keeps running and executing cpu_idle() and so on. Furtheremore, jiffies increase, but no other interrupts occur. It's probably waiting for an interrupt that never came. It seems to happen when buffers try to access external memory. Can it be related to bus arbitration? Probably not; usually that sort of problem results in a hard lock-up. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux problem in mpc8260
On Mon, Sep 22, 2008 at 05:37:24PM +0530, VenkataKrishna wrote: > In our target board have two banks of flash device. Which is connected two > Chip select 0(CS0) and Chip select 1 (CS1). In Hardware our target board has > specialty jumper setting change CS0 VsCS1. Booting device always connected > CS0. What is our problem is I want download my Linux uImage in one of flash > device in my board when change jumper setting in hardware the board should > be boot .Board is Powerpc based processor (MPC8260). Any one suggest me > what can I do. Where can I initialization memory device. You need to put a u-boot (or other firmware) image in each bank. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: HRCW on MPC8260
On Fri, Sep 19, 2008 at 05:42:12PM +0530, VenkataKrishna wrote: > I am working ELDK Kit 4.0 versions in Linux. My target Board is MPC8260 > processor. I generated linux uImage with linux-2.6-denx and is it need hard > reset configuration words in linux. I don't find HRCW (Hard reset > configuration word) anywhere in linux. In My target Board we are using Five > memory device (SRAM, SRAM, Flash) and where can I instalization these memory > in linux. The HRCW is generally provided by firmware (U-boot or similar), not the kernel. You cannot boot directly into Linux. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FW: U-Boot 1.3.0 with Linux 2.6.25-11 on MPC8641D - Machine checkexception
On Thu, Sep 18, 2008 at 08:50:33AM -0500, Exchange Admin wrote: > quirk_usb_handoff_ohci: resource start = 0x8000, len = 0x1000 > quirk_usb_handoff_ohci: base = 0xe1056000, offset = 0x0004 > Machine check in kernel mode. > Caused by (from SRR1=149030): Transfer error ack signal > Oops: Machine check, sig: 7 [#1] > TAURUS > NIP: c0297f4c LR: c0297f44 CTR: c00115d0 > REGS: df821e60 TRAP: 0200 Not tainted (2.6.25.11) > MSR: 00149030 CR: 2422 XER: > TASK = df805410[1] 'swapper' THREAD: df82 > GPR00: c0297f44 df821f10 df805410 0042 0001 0001 > 0002 > GPR08: 0036 c0333fe4 6b61 c036 4428 f7fbfffc 0fffac00 > > GPR16: 0080 007fff00 df821f78 c02d c033 c033 > 0fff5464 > GPR24: c033 c02d e1056000 df841218 df841218 > e1056004 > NIP [c0297f4c] 0xc0297f4c > LR [c0297f44] 0xc0297f44 > Call Trace: > [df821f10] [c0297f44] 0xc0297f44 (unreliable) > [df821f40] [c01617dc] pci_fixup_device+0xec/0x140 > [df821f60] [c0295ae0] 0xc0295ae0 > [df821f70] [c030c198] kernel_init+0x9c/0x290 > [df821ff0] [c0010a6c] kernel_thread+0x44/0x60 > Instruction dump: > > > ---[ end trace 97996e90be8a1237 ]--- > Kernel panic - not syncing: Attempted to kill init! > Rebooting in 180 seconds.. > > where resource start = 0x8000 is the physical address of the USB > controller, base = 0xe1056000 is the virtual address. > > Does anyone know this kind of problem and can give me a hint. Check that the PCI controller config matches the MMIO region specified in the device tree. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: confusions of boot sequence in MPC8572?
On Thu, Sep 18, 2008 at 09:49:34PM +0800, Michael.Kang wrote: > And jump to __secondary_start -> call_setup_cpu, source code in > call_setup_cpu as the following: > 112 _GLOBAL(call_setup_cpu) > 113 addis r4,r3,[EMAIL PROTECTED] > 114 addir4,r4,[EMAIL PROTECTED] > 115 lwz r4,0(r4) > 116 add r4,r4,r3 > 117 lwz r5,CPU_SPEC_SETUP(r4) > 118 cmpwi 0,r5,0 > 119 add r5,r5,r3 > 120 beqlr > 121 mtctr r5 > 122 bctr > > here it seems cur_cpu_spec here is not a valid value since > cur_cpu_spec will only be set in identify_cpu() [ > arch/powerpc/kernel/cputable.c: 1301] later. > > So what is my mistake? Who responsible for initialize cur_cpu_spec > variable for second core?? There is only one cur_cpu_spec for all cores, which is initialized by the boot core before it releases the secondaries. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Not probing devices on PowerPC MPC8247 and kernel 2.6.26
Chris Skepper wrote: Hi All, I have an MPC8247 based board. I can get the SMC1 console working, but the other SCCx serial ports and the FCC1 ethernet doesn't work. It appears that a part of the problem is that the probe methods are not called. The "match" table stuff all looks fine and the serial ports and ethernet are defined in the .dts file. The module init function is called, but the probe methods are not reached. It seems driver_register gets called, so why doesn't something call probe? Is there likely to be some problem with the bus setup? Are you calling of_platform_bus_probe() from your platform code, and do the soc and cpm nodes match the bus list (I recommend using compatible = "simple-bus")? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: driver replacements for kmalloc and __pa()
Jeff Brower wrote: What are the up-to-date APIs we should be using for DMA memory allocation and virtual-to-physical address translation? We have another driver for another device that's working fine on this board and it uses pci_alloc_consistent(). What about bus_space_vaddr()? I'm hoping to get a recommendation for what's currently appropriate and most future-proof for drivers that depend on external PCI DMA. Documentation/DMA-API.txt. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 1MB alignment dma_alloc question
Russell McGuire wrote: Putting together a driver, IMA for ATM in a MPC83xx. Anyway the manual states that one of the data structures for the QE needs to be allocated on a 1MB boundary in external memory. Normally these come in 128/64/32byte boundaries and are easy to self align, with some bit logic. However, after reading up on dma_alloc_coherent I see that a limitation is that dma cannot span 64K page boundaries. That sounds like something related to legacy PC DMA. I doubt there's any such limitation in the API itself. So this begs a question is their a better way to get a 1MB aligned table? Other than allocating almost 2MB of memory and then trying to mask off the LSBs? Seems like an awful waste of memory. I guess the real question is there a better kernel call that returns already aligned DMA memory? It looks like allocations will be naturally aligned on powerpc (due to coming straight from alloc_pages), though it's probably not guaranteed by the API. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Host USB issue on MPC8272
David Beamonte wrote: This issue seems to be related to one problem that we have always had. We can't configure buffers of SMCs, SCCs, etc, to be in SDRAM, because the processor hangs. We always have to configure buffers in DPRAM. In other drivers this has not been a problem, because the buffer size is not very large, so we can allocate it in DPRAM, but for this one, the buffer size is 0x8000 (32Kb) which exceeds DPRAM size. Has anybody had the same problem? Can it be an USB specific problem or a general one? Make sure that BCR[PLDP] is not set, as per erratum SIU18. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to access Freesale UPM NAND device
Laxmikant Rashinkar wrote: I have a custom board running MPC8347 on Linux 2.6.27 with Uboot 1.1.4. I also have a NAND device (Micron MT29F2G08AACWP) connected to the LBC and controlled via UPM. fsl_elbc_nand.ko, fsl_upm.ko are loaded. fsl_elbc_nand is for FCM; you only need the latter. I'm wondering how to access the NAND device. Do I need mDOC? TrueFFS? JFFS2 is typically used. I have grep'd for the functions declared in fsl_upm.c and fsl_lbc.c and find that no other code path calls these functions. So it looks like the drivers are loaded but no one calls into them. The init function of the module registers a driver, providing function pointers that are called. You access the device through /dev/mtd*. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
Chris Skepper wrote:
Thanks so much for your help so far. I was able to find out this
address from the bootloader and get some output on the early debug
console which was very pleasing. It now gets as far as console_init()
called from init/main.c, which completes but then any printk seems to
stall it and you get no more output.
I am using SMC1 and have this in the DTS file for the linux,stdout-path:
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8247-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a80 0x20 0x87fc 2>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <0x1d00>;
};
Any ideas what sorts of things I should check next?
Check the BRG frequency (clock-frequency in the brg node), and the baud
rate that the driver is trying to set. As a quick check, you can
disable calls to cpm2_setbrg() to see if that's the problem.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Virtual IRQs on 82xx
Muller, Ralf (NSN - FI/Espoo) wrote: I'm using a 8247 custom board and kernl 2.6.21.7 I strongly recommend using something newer. There was a lot of 82xx work going on around that time. on the arch/powerpc branch. Here the irq are virtualized in the irq map functions now I'm facing several problems. * I have to manually call irq_create_of_mapping for each CPM interrupt What's wrong with irq_of_parse_and_map()? And the major problem is: Now the kernel mixes virtual- and HW-IRQs, e.g. request_irq works with HW_IRQs but the interrupt handler with virtual interrupts, which can't work. No, request_irq works with virtual interrupts as well. For some reason even on a powerpc the first 16 interrupts are reserved for legacy (PC) IRQs, Right, there are powerpc systems with the same legacy interrupts and the same ISA drivers that expect to be able to use ISA IRQs directly as virqs. so the easiest mapping HW-IRQ0 -> VIRQ16 a.s.o The "easiest mapping" is whatever the IRQ subsystem gives you. This isn't something that should be hardcoded. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: cpm_dpalloc questions
bhanu jampala wrote: I am working on MCC HDLC controller on MCC8260. I have two important questions: 1. What is the range of DPRAM from which the cpm_dpalloc allocates memory? How does the cpm_dpalloc work? Assuming you're using arch/powerpc on a recent kernel version, it allocates from the memory specified in the muram node of the device tree. I need this because, I need to reserve the DPRAM memory for MCC2 from (128 * 60) to (255 * 60) for channels ranging from 128 - 255. Why do you need to reserve a specific address? 2. PROFF_SMC1 pointer placed at 0 , 64 offsets. is this not an area of MCC1 controller? No, MCC1 PRAM starts at offset 0x8700. Any other areas used are under software control. how if I want to use the MCC channel on MCC1. In file include/asm-powerpc/cpm2.h. /* The SMCs are relocated to any of the first eight DPRAM pages. * We will fix these at the first locations of DPRAM, until we * get some microcode patches :-). * The parameter ram space for the SMCs is fifty-some bytes, and * they are required to start on a 64 byte boundary. */ #define PROFF_SMC1 (0) #define PROFF_SMC2 (64) This is obsolete arch/ppc stuff and should be removed; the SMC pram is now dynamically allocated and relocated (and before that, it came from the device tree). -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote: > I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2? > Is that likely to be correct for SMC1? (I tried looking in the MPC8272 > reference manual, but couldn't find it.) The value depends on how the port was set up by firmware (or by the bootwrapper). It should be set to wherever the descriptor is, and there should only be one descriptor that loops back on itself. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote: > Is it likely the port isn't set up properly? udbg_early_init and > udbg_init_cpm get called before it probes the machine so there's been no > chance to do cpm2_set_pin or anything. For the early console to work, the pins must have been set up properly by firmware. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
Chris Skepper wrote: On Tue, 26 Aug 2008, Scott Wood wrote: On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote: I'm triggering an LED which is connected to port A. Are you saying that wouldn't work once the caching is enabled? It's quite possible. What other registers are in the same cache line as the LED, and are any of them non-memory-like? There are some ethernet signals, a compact flash card detect, other LEDs and a push button also on port A. Are those what you'd call non-memory-like? Would any of them object to spurious reads, and writebacks of the value that was read? It's usually easiest to just trust that that part of the code works (in my experience, that's rarely where a hang actually occurs when bringing up a new board), and resume tracing after the MMU is on and you've inserted a caching-inhibited BAT entry. Where can I find out how to do that? Since I have this board working with the old ARCH=ppc, can I copy anything from there? See setup_cpm_bat in arch/powerpc/kernel/head_32.S. Also, where would be a good place in the code to resume tracing? As soon as you can set up a BAT -- though first, I would try just enabling the CPM debug console and see if you get anything from that. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote: > >How are you determining that it never gets to that point? If it's via > >serial I/O or similar, be aware that I/O isn't going to work when caches > >are enabled but the MMU is not. > > I'm triggering an LED which is connected to port A. Are you saying that > wouldn't work once the caching is enabled? It's quite possible. What other registers are in the same cache line as the LED, and are any of them non-memory-like? And even if all registers in the cache line are OK with this sort of access, you need to use dcbf afterwards. It's usually easiest to just trust that that part of the code works (in my experience, that's rarely where a hang actually occurs when bringing up a new board), and resume tracing after the MMU is on and you've inserted a caching-inhibited BAT entry. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: virt_to_phys() in drivers w/dma - MPC8xxx
Russell McGuire wrote: So shouldn't we be using like dma_alloc_coherent, and then tracking the dma address separately as a variable, and use it when necessary instead of calling virt_to_phys()? Yes. On 8xxx (but not 8xx, and not with 36-bit memory), there'll be no practical difference, but the DMA mapping API *should* be used. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B
roger blofeld wrote: Hi Since this bug is ATA specific, shouldn't this code be conditioned by CONFIG_IDE ? And then what happens if IDE is built as a module? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting linux 2.6.27 to embedded powerpc board
Laxmikant Rashinkar wrote: When I attempt to boot my image it just hangs w/o any output. I dearly wish I could get some console output. Make sure you have /chosen/linux,stdout-path in your device tree. For output from the kernel itself, make sure the serial clock-frequency is correct. 1) the load address and entry point for the kernel (see above) are non-zero. When we load via uImage, they are always zero. Is this normal? Yes, it's normal. 2) When I build my kernel, I get two warnings. Could these be causing a problem? Probably not. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
Chris Skepper wrote: Using code to flash an LED I have traced execution from the entry point in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling the cache on the CPU: setup_common_caches: mfsprr11,SPRN_HID0 andi.r0,r11,HID0_DCE orir11,r11,HID0_ICE|HID0_DCE orir8,r11,HID0_ICFI bne1f/* don't invalidate the D-cache */ orir8,r8,HID0_DCI/* unless it wasn't enabled */ 1:sync /* Chris: Reaches here. */ mtsprSPRN_HID0,r8/* enable and invalidate caches */ sync mtsprSPRN_HID0,r11/* enable caches */ sync isync /* Chris: Never gets to here. */ blr FWIW, commenting out the lines above causes it to hang when attempting to enable the MMU, which is the next step in the process. How are you determining that it never gets to that point? If it's via serial I/O or similar, be aware that I/O isn't going to work when caches are enabled but the MMU is not. Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 kernel with ARCH=powerpc mode? I think it should be, but it would be good to know that someone has tried it. I've booted an MPC8248 (and some other 82xx) on 2.6.26. MPC8247 should work. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting linux 2.6.27 to embedded powerpc board
David Jander wrote: 4. Be sure that the device(s) necessary to produce output on your console are correctly placed in the DT. Also make sure that u-boot knows about it (#define OF_STDOUT_PATH... in your u-boot board config file) OF_STDOUT_PATH is deprecated; you should enable CONFIG_OF_SERIAL_VIA_ALIAS, and provide aliases in the device tree for serial0, serial1, etc. 6. Remember to always specify the "rootfstype=" option on the commandline if booting from anything other than NFS. This was not necessary back in the 2.6.15-times AFAICR. It still should not be necessary. 7. Boot with a device-tree (in u-boot: "bootm $addrofkernel - $addrofdtb", don't forget the dash if you are not using an initrd). If you don't do this, u-boot can't fix your DT, and the kernel probably won't find it either. s/probably/definitely/ 8. Be sure to use the correct version of the DTC (DT compiler) for your kernel (the sources are included nowadays, somewhere in arch/powerpc/boot IIRC). The command used to compile, should probably be something like this: Or just use the most recent DTC. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
On Tue, Aug 19, 2008 at 03:13:54PM +0400, Matvejchikov Ilya wrote:
> Hi all,
>
> The problem was in incorrect (not full) brg-node definition. Instead of
> [EMAIL PROTECTED] {
> compatible = "fsl,cpm-brg", "fsl,cpm2-brg";
> reg = <119f0 10 115f0 10>;
> };
> there must be:
> [EMAIL PROTECTED] {
> compatible = "fsl,cpm-brg", "fsl,cpm2-brg";
> reg = <119f0 10 115f0 10>;
> clock-frequency = ;
> };
>
> The PQ2 (and some others) DTS files needs to be updated.
No, the DTS files don't need to be updated -- u-boot (or whatever
firmware you use, or the bootwrapper) needs to fill in the frequency.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: flash partitioning
On Fri, Aug 15, 2008 at 10:23:29AM -0400, liran raz wrote:
> [EMAIL PROTECTED] {
> compatible = "fsl,mpc8272-localbus",
>"fsl,pq2-localbus";
> #address-cells = <2>;
> #size-cells = <1>;
> reg = ;
>
> ranges = <0 0 fc00 0400>;
> };
>
> [EMAIL PROTECTED] {
> device_type = "rom";
> compatible = "direct-mapped";
> probe-type = "CFI";
> reg = ;
> bank-width = <4>;
> device-width = <2>;
> #address-cells = <1>;
> #size-cells = <1>;
> partitions = <0 20
> 200 a0
> c00 a0
> 1600 60
> 1c00 e0
> 2a00 60
> 3000 e0
> 3e00 10
> 3f00 8
> 3f80 4
> 3fc0 4>;
> partition-names =
> "part01","part02","part03","part04","part05","part06","part07","part08","part09","part10","part11";
> };
This is an obsolete binding; please use the current one described in
Documentation/powerpc/booting-without-of.txt, and demonstrated in the
current device tree files.
> I can't see the different partitions linked to the /dev/mtd
> devices in the startup messages. When testing the devices
> I see that only /dev/mtd0 is actually linked to the beginning
> of the flash. (other /dev/mtd1 etc.. can't be opened).
> I included below also the relevant startup messages.
> Does anyone have any idea what is wrong with my flash
> configuration format?
> Thanks, Liran.
>
> Linux version: 2.6.24
> Processor: mpc8272
> Startup messages:
> physmap platform flash device: 0400 at fc00
> physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
You're using physmap; you need to use physmap_of. You may need to use a
newer kernel, as well.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Lost time?
- Reyneke wrote: Anyone have any ideas, obvious suspects, or pointers where to go and look? Check the kernel's idea of what the timebase frequency is on both kernels. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
On Wed, Jul 30, 2008 at 01:37:43PM +0400, Matvejchikov Ilya wrote:
> smc1: [EMAIL PROTECTED] {
> device_type = "serial";
> compatible = "fsl,cpm2-smc-uart";
> reg = <11a80 20 0 40>;
> interrupts = <4 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <7>;
> fsl,cpm-command = <1d00>;
> };
>
> };
>
> (muram node for 2.6.25 is differs from muram node for the 2.6.26)
>
> With this device tree I have a warning message from cpm_uart driver
> tells that the dts file needs to be updated.
Right, but does the serial port work? If it works with this tree and not
with the new version, then that points to a problem in the dynamic pram
allocation. Otherwise, I'm not sure what's causing the difference
between the two versions; you may want to bisect.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
On Tue, Jul 29, 2008 at 10:36:30PM +0400, Matvejchikov Ilya wrote: > Have you tired to run 2.6.25 kernel? With 2.6.25.4 my console works > fine! I suspect there is something like a regression Did you use CONFIG_PPC_CPM_NEW_BINDING in 2.6.25? It became mandatory in 2.6.26. Also, try commenting out cpm_setbrg() calls in case the frequency is not being set properly. 2.6.26 introduced the allocation of the CPM2 SMC parameter RAM area; what did your device node look like in 2.6.25? What happens if you use that device tree with 2.6.26? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
On Tue, Jul 29, 2008 at 11:33:47AM -0400, Ben Gardiner wrote: > And my serial console output is stopping around the same point as > Matvejchikov. I have baud 9600, so I'm guessing that it's cutoff because > of this (please excuse me if this is wrong). NB: the console=ttyS0 > bootarg is there to get a working console when I boot back to 2.4. > > Memory <- <0x0 0x800> (128MB) > ENET0: local-mac-address <- 00:11:40:02:00:18 > CPU clock-frequency <- 0x3f940aa (67MHz) > CPU timebase-frequency <- 0x1fce17 (2MHz) > CPU bus-frequency <- 0x1fce170 (33MHz) Try commenting out calls to cpm_setbrg(), to see if the frequency is bad. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SCC1 console
On Tue, Jul 29, 2008 at 08:47:00AM +, Fabien Oriede wrote: > < 6 > cpm_uart : WARNING : no UART devices found on platorm bus! – > < 6 > cpm_uart : the driver will guess configuration, but this mode is no > longer supported. – Enable CONFIG_PPC_CPM_NEW_BINDING (or better, upgrade to the latest kernel), and ensure that the device tree node and pin/brg setup is correct. Try commenting out calls to set the BRG as a test, to see if it's getting a bad frequency. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: No output from SMC1 console with the 2.6.26 kernel (PQ2FADS based board)
Matvejchikov Ilya wrote:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2";
Add "simple-bus" to this compatible list.
Other than that, and that you should be using dts-v1, the tree looks
fine. If adding "simple-bus" doesn't fix it, check your pin setup;
pq2fads doesn't have an SMC serial port, so its platform file doesn't
set up those pins.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with cuImage Linux entry from old U-boot
Mike Timmons wrote: Related question: I'm using a newer U-boot and managing the load of the kernel and the device tree from separate partitions of my boot media. Having the two partitions and managing the kernel and the tree separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can I just use that "static" file name option when I build the kernel, load the cuImage, and just invoke bootm ? Will it work to just leave off the - I think I had it set-p right yesterday and I gave it a try, but no joy. Can it be this simple to statically link the device tree with the kernel build? For my application I don't see a benefit in keeping them separate (the kernel and the tree). Yes, you can use cuImage to bundle the device tree with the kernel (note that the type of image you use *must* match the type of bootm command you use), though it's not recommended if you have a u-boot that can properly pass a device tree. cuImage relies on the bd_t to get information from u-boot, and this is a very fragile structure, and contains less information than the device tree. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with cuImage Linux entry from old U-boot
On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote: > I have made great strides with help from this mailing list and its > archives. I now have a compiled cuImage ready to boot from my older > working u-boot 1.1.2. I now seem to be stuck at the kernel entry point. > I'm not sure if I'm trying to jump into the kernel at the wrong address, > or if I have a serial console issue that prevents me from seeing anymore > progress. Most likely the latter, or some other issue that prevents the kernel from booting to the point where the serial console functions. > Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo > console=ttyMM0,9600n8 > Finalizing device tree... flat tree at 0x7423a0 > > > > -- > > > > If I run 'nm' on my elf image, I expect to find some entry point address > that corresponds to 0x7423a0, but this is not the case. Why would you expect that? It's a dynamically allocated chunk of memory that holds the device tree that is passed to the kernel. It's not an entry point; the entry point to the kernel is zero. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Failure of request_irq() for MPC8313 using arch=powerpc
On Tue, Jul 15, 2008 at 08:43:59PM -0700, Duy-Ky Nguyen wrote: > Hi Dave, > > I've just tried it and it failed. Could you elaborate on exactly what you tried? Did you pass the GPIO device tree node? > Before I had tried using the function > int virq = of_irq_to_resource(GPIO_IRQ, 0, NULL); > and it failed the same way The first argument of of_irq_to_resource is a device node pointer, not an IRQ number. Surely the compiler warned you about this. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: linux/powerpc memory management
sumedh tirodkar wrote: Can anyone give pointers as to how memory management(detailed) is done in linux on powerpc. arch/powerpc/mm (Hey, you wanted a detailed answer to a very broad question...) -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: how to understand pci section in device tree source file
zhanglei459 wrote: I guess which refer to host-pci bridge ATMU,is right? Yes. But how to descripe added-on pci chip,whose BAR0 and BAR1 are IO spaces, BAR2 and BAR3 are MEM spaces. You don't need to -- this can be probed at run-time. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: NAND access fail after MMU enabled when booting linux
Qin, Laigui (GE EntSol, Security) wrote:
I am facing a MMU related problem when porting Linux to my custom board
with Coldfire M5445x processor. The observation is that* the nand Bus
chip select/WE/RE become 100 times longer than normal when MMU enabled*.
I just can not understand this...
Coldfire is m68k; this list is for powerpc.
Look into my driver codes, I use the virtual address (0xe000)
applied from ioremap() kernel function.
136 /* map physical address */
137 this->IO_ADDR_R = this->IO_ADDR_W = ioremap(0x, 1024);
138 if (!this->IO_ADDR_R) {
139 printk(KERN_WARNING "ioremap micron NAND @0x
failed\n");
Is it really at address zero, or is that where your RAM is?
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: u-boot, MPC8313erdb
Nidhi Dua wrote: question 3: After we have set 'ethact' to TSEC1, the kernel is loaded, and we have logged -in, when we try to ping the Host from target it says '100% packet lost'. also we are unable to ping target from the host. Why is it happening so? U-boot does not support responding to pings. Also, please use the u-boot-users list for u-boot questions, use a more descriptive subject, and don't repost the same question multiple times. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PCI DMA Problems With 82xx?
Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Mike Winter wrote: We are developing with an 8248-based platform, and we have a vendor telling us that the PCI hardware is unreliable on this CPU family, in particular the DMA functionality. A quick search of this list doesn't turn up any horror stories, although the processor does have some PCI errata listed. Does anybody have any practical experience using PCI on the 8248 or similar that they can share with me? Thanks. We're using all four PCI DMA's on 8265 and 8280 CPU's. Hmm, did he mean bus-mastering from PCI devices, or the DMA block which is documented as part of PCI on older chips, but really has nothing to do with it that I can figure out? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PCI DMA Problems With 82xx?
Mike Winter wrote: We are developing with an 8248-based platform, and we have a vendor telling us that the PCI hardware is unreliable on this CPU family, in particular the DMA functionality. A quick search of this list doesn't turn up any horror stories, although the processor does have some PCI errata listed. Does anybody have any practical experience using PCI on the 8248 or similar that they can share with me? Thanks. Make sure that you park the bus on PCI, and elevate PCI's arbitration priority. See fixup_pci() in arch/powerpc/boot/cuboot-pq2.c. I haven't had a problem with PCI DMA when that is done, though I haven't done significant stress testing. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reserving small amounts of memory with mem= (MPC85xx, 2.6.15 arch/ppc)
Florian Boelstler wrote: Available system memory is only 384 MB (CAM0+CAM1+CAM2), which explains why Linux "removed" the ramdisk, when it has been copied right below 508M by U-Boot. Because at that time I was using initrd_high @ 1FC0, which is outside of mapped RAM. Is there an option to map less than 64M by a CAM entry? CAM entries can be any power of 4 between 4K and 256M. However, the code currently is hardcoded to use no more than 3 entries. It shouldn't be too hard to change it to use a few more (see cam_mapin_ram(), mmu_mapin_ram(), and adjust_total_lowmem() in arch/powerpc/mm/fsl_booke_mmu.c). Alternately, do you have highmem enabled? That will let you access the rest of the RAM that the CAM doesn't map, though I don't know if an initrd in highmem works. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Freescale MPC8321 support
David Goodenough wrote: This processor is described as an e300c2 core. I found that e300c2 is listed in the arch/powerpc/kernel/cputypes.c file. Does this mean that it is supported, or is that just a place holder? Yes, it is supported. If it is supported (as a core) what about the peripherals built into the MPC8321 are they likely to be supported? The more commonly used ones should be. How about Flash support, or is this very board dependant? Yes, flash (I assume you mean NOR) should work. See the localbus nodes in existing device trees. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question on assigning interrupts in a dts
Michael Galea wrote: Hi All, I'm building a dts for a custom 8360 based board. I'm looking at the mpc8360_mds and mpc8360_rdk dts files, trying to figure out how the UCCs (and all peripherals in general) got the values of their "interrupts" properties chosen. As someone else pointed out, you get the values from the manual. The second cell of the IPIC interrupt specifier is the level/sense information (8 == level triggered, active low, 2 == rising edge). And is there any relationship between the choice of interrupts for ucc1 and the qeic controller.. No. All QE interrupts are multiplexed over either IPIC 32 or IPIC 33. UCC0 and UCC1 just happen to be QEIC 32 and QEIC 33, respectively. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
On Thu, Jun 12, 2008 at 12:33:12PM +0200, David Jander wrote: > On Wednesday 11 June 2008 20:19:17 Scott Wood wrote: > > Please post patches to linuxppc-dev rather than linuxppc-embedded -- > > you'll get a larger reviewing audience. > > Ok, but I thought linuxppc-dev was for all non-embedded development only... No, it's for all Linux/PowerPC development. linuxppc-embedded is more for user questions. > > Can we encode the required alignment for rx and tx in the device tree? > > Hmmm... This actually is a silicon-bug workaround AFAIK. > I agree with you that this solution is not good, but I doubt resolving this > in the device-tree is much better. It will add run-time overhead just because > right now there are some buggy chips around. I think this could better > be a Kconfig option, so people can have faster kernels if they want later. > If you are concerned about multiplatform kernels, this shouldn't harm. OK. > > > -#define __cbd_out32(addr, x) out_be32(addr, x) > > > -#define __cbd_out16(addr, x) out_be16(addr, x) > > > -#define __cbd_in32(addr) in_be32(addr) > > > -#define __cbd_in16(addr) in_be16(addr) > > > +#define __cbd_out32(addr, x) out_be32((volatile void __iomem *)addr, > > > x) > > > +#define __cbd_out16(addr, x) out_be16((volatile void __iomem *)addr, > > > x) > > > +#define __cbd_in32(addr) in_be32((volatile void __iomem *)addr) > > > +#define __cbd_in16(addr) in_be16((volatile void __iomem *)addr) > > > > NACK, please don't remove type checking. > > Ok, but given the macro's further down, I'll have to cast there... > > #define CBDR_BUFADDR(_cbd) __cbd_in32((volatile void __iomem > *)&(_cbd)->cbd_bufaddr) Why? cbd should already have an __iomem annotation, and the volatile is unnecessary. > > > +#ifndef CONFIG_FS_ENET_MPC5121_FEC > > > FW(fecp, r_hash, PKT_MAXBUF_SIZE); > > > +#endif > > > > > > /* get physical address */ > > > rx_bd_base_phys = fep->ring_mem_addr; > > > @@ -320,10 +325,17 @@ static void restart(struct net_device *dev) > > > > > > fs_init_bds(dev); > > > > > > +#ifndef CONFIG_FS_ENET_MPC5121_FEC > > > /* > > >* Enable big endian and don't care about SDMA FC. > > >*/ > > > FW(fecp, fun_code, 0x7800); > > > +#else > > > + /* > > > + * Set DATA_BO and DESC_BO and leave the rest unchanged > > > + */ > > > + FS(fecp, dma_control, 0xc000); > > > +#endif > > I have tried, but it is almost impossible, since both FEC types use a struct > named "fec_t" which very different betwen both types. That means that the code > would have enormous amounts of "if" statements all over. > Any suggestion? OK, I missed that this was FEC-specific code and not general fs-enet. 8xx/512x multiplatform is already unsupported due to core differences, but make sure that 82xx/512x multiplatform doesn't get broken. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
On Thu, Jun 12, 2008 at 08:54:27AM +0200, David Jander wrote:
> On Wednesday 11 June 2008 19:58:32 Scott Wood wrote:
> > > + //[EMAIL PROTECTED] {
> > > + // compatible = "mpc512x-axe";
> > > + // reg = <2000 100>;
> > > + // interrupts = <2a 8>;
> > > + // interrupt-parent = < &ipic >;
> > > + //};
> >
> > Why is this here, but commented out?
>
> Hmm, I know we are going to use it, but there are no drivers still...
> I'll leave it out, and add it again later when axe-support has arrived.
Just uncomment it -- there's no harm in a device node for which Linux has
no driver, and it avoids problems with old device trees being used once a
driver is added.
Compatible should have "fsl," prepended, though, and ideally a concrete
chip should be represented rather than "512x".
> > > + [EMAIL PROTECTED] {
> > > + compatible = "fsl,mpc5121-dma2";
> >
> > Is this DMA controller compatible with drivers/dma/fsldma.c? If so,
> > follow the established binding.
>
> No, it's not compatible with any other dma controller AFAIK. It special for
> this chip. John Rigby is writing the driver for it right now.
OK.
> Btw, is it ok I just re-submit the fixed patches (with cc to linuxppc-dev)?
Yes.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
Please post patches to linuxppc-dev rather than linuxppc-embedded --
you'll get a larger reviewing audience.
David Jander wrote:
+config FS_ENET_MPC5121_FEC
+ bool "Freescale MPC512x FEC driver"
+ depends on PPC_MPC512x
+ select FS_ENET
+ select FS_ENET_HAS_FEC
+ select PPC_CPM_NEW_BINDING
PPC_CPM_NEW_BINDING is default y, and will be going away as an option as
soon as arch/ppc does. In the meantime, instead of selecting it here,
add FS_ENET_MPC5121_FEC to the depends list of PPC_CPM_NEW_BINDING -- or
just remove the depends list altogether.
+ default n
Unnecessary, please omit.
+/*
+ * Define the buffer descriptor structure.
+ */
+typedef struct bufdesc {
+ unsigned short cbd_sc; /* Control and status info */
+ unsigned short cbd_datlen; /* Data length */
+ unsigned long cbd_bufaddr;/* Buffer address */
+} cbd_t;
This can be factored out into a common header -- along with most if not
all of the flag defines.
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 31c9693..4ca8513 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -69,6 +69,7 @@ MODULE_PARM_DESC(fs_enet_debug,
static void fs_enet_netpoll(struct net_device *dev);
#endif
+#define ENET_RX_ALIGN 16
This is already defined in fs_enet.h.
+#define TX_ALIGN_WORKAROUND
+#ifdef TX_ALIGN_WORKAROUND
+static struct sk_buff *aligntxskb(struct net_device *dev, struct sk_buff *skb)
+{
+ struct sk_buff *skbn;
+ skbn = dev_alloc_skb(ENET_RX_FRSIZE+0x20);
+ if (skbn)
+ skb_align(skbn, 0x20);
+
+ if (!skbn) {
+ printk(KERN_WARNING DRV_MODULE_NAME
+ ": %s Memory squeeze, dropping tx packet.\n",
+ dev->name);
+ dev_kfree_skb_any(skb);
+ return NULL;
+ }
+
+ skb_copy_from_linear_data(skb, skbn->data, skb->len);
+ skb_put(skbn, skb->len);
+ dev_kfree_skb_any(skb);
+ return skbn;
+}
+#else
+#define aligntxskb(skb) skb
+#endif
Can we encode the required alignment for rx and tx in the device tree?
@@ -951,7 +980,7 @@ static int fs_ioctl(struct net_device *dev, struct ifreq
*rq, int cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
struct mii_ioctl_data *mii = (struct mii_ioctl_data *)&rq->ifr_data;
-
+ printk("<1> %s: %s (%d)\n",__FILE__,__FUNCTION__,__LINE__);
Please use the KERN_ prefixes rather than hardcoding the number, and put
spaces after commas. Of course, if this is to be here at all, this
should be dev_dbg() rather than KERN_ALERT.
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
/* handy pointer to the immap */
void __iomem *fs_enet_immap = NULL;
@@ -1168,6 +1198,10 @@ static void cleanup_immap(void)
iounmap(fs_enet_immap);
#endif
}
+#else
+#define setup_immap() 0
+#define cleanup_immap() do {} while (0)
+#endif
NACK, this precludes a 52xx/82xx multiplatform kernel.
static struct device_driver fs_enet_fec_driver = {
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
.name = "fsl-cpm-fec",
+#else
+ .name = "fsl-mpc5121-fec",
+#endif
>.bus= &platform_bus_type,
This is non-PPC_CPM_NEW_BINDING stuff which is now for arch/ppc only --
we don't need to support 52xx with it if it didn't already.
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
#include
+#else
+#include "fec_mpc5121.h"
+#endif
Why can't we unconditionally include asm/fs_pd.h?
-#define __cbd_out32(addr, x) out_be32(addr, x)
-#define __cbd_out16(addr, x) out_be16(addr, x)
-#define __cbd_in32(addr) in_be32(addr)
-#define __cbd_in16(addr) in_be16(addr)
+#define __cbd_out32(addr, x) out_be32((volatile void __iomem *)addr, x)
+#define __cbd_out16(addr, x) out_be16((volatile void __iomem *)addr, x)
+#define __cbd_in32(addr) in_be32((volatile void __iomem *)addr)
+#define __cbd_in16(addr) in_be16((volatile void __iomem *)addr)
NACK, please don't remove type checking.
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
FW(fecp, r_hash, PKT_MAXBUF_SIZE);
+#endif
/* get physical address */
rx_bd_base_phys = fep->ring_mem_addr;
@@ -320,10 +325,17 @@ static void restart(struct net_device *dev)
fs_init_bds(dev);
+#ifndef CONFIG_FS_ENET_MPC5121_FEC
/*
* Enable big endian and don't care about SDMA FC.
*/
FW(fecp, fun_code, 0x7800);
+#else
+ /*
+* Set DATA_BO and DESC_BO and leave the rest unchanged
+*/
+ FS(fecp, dma_control, 0xc000);
+#endif
Please do a runtime check for hw type rather than compile-time (here and
elsewhere).
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
David Jander wrote:
arch/powerpc/platforms/512x/mpc5121_ads.c | 104 --
arch/powerpc/platforms/512x/mpc5121_generic.c | 105 ++
Pass -B -M -C to git-format-patch to detect renames, copies, etc.
+ [EMAIL PROTECTED] {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <0xfe00 0x0200>;
+ bank-width = <2>;
+ partitions = <0x 0x0180 // filesystem
+ 0x0180 0x0020 // config0
+ 0x01a0 0x0020 // config1
+ 0x01c0 0x002e // kernel
+ 0x01ee 0x0002 // one sector for device
tree
+ 0x01f0 0x0010>; // u-boot
+ partition-names = "filesystem", "config0", "config1","kernel",
"device-tree", "u-boot";
+ };
This is an old flash binding. Please use the one currently described in
Documentation/booting-without-of.txt.
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr";
Also simple-bus.
+ //[EMAIL PROTECTED] {
+ // compatible = "mpc512x-axe";
+ // reg = <2000 100>;
+ // interrupts = <2a 8>;
+ // interrupt-parent = < &ipic >;
+ //};
Why is this here, but commented out?
+ [EMAIL PROTECTED] {
+ device_type = "mdio";
No device_type.
+ // PSC4 in i2s mode
+ [EMAIL PROTECTED] {
+ device_type = "i2s";
No device_type.
+ // PSC5 in SPI mode for touchscreen
+ [EMAIL PROTECTED] {
+ device_type = "spi";
No device_type.
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-dma2";
Is this DMA controller compatible with drivers/dma/fsldma.c? If so,
follow the established binding.
+config MPC5121_GENERIC
+ bool
+ default n
+
config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on PPC_MULTIPLATFORM && PPC32
select DEFAULT_UIMAGE
select PPC_MPC5121
+ select MPC5121_GENERIC
help
This option enables support for the MPC5121E ADS board.
default n
+
+config PRTLVT
+ bool "Protonic LVT family of MPC5121 based boards"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select DEFAULT_UIMAGE
+ select PPC_MPC5121
+ select MPC5121_GENERIC
+ help
+ This option enables support for the Protonic LVT family (ZANMCU and
VICVT2).
+ default n
Can we leave out the "default n" lines? They're no-ops.
I don't think these configs should depend on an option
(PPC_MULTIPLATFORM) that is described as "Generic desktop/server/laptop"...
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, Jun 11, 2008 at 08:33:57AM -0700, vb wrote: > my favorite was interrupt-map in PCI section: A typical value would > look like this: > > interrupt-map = < > > /* IDSEL 0x10 */ > 08000 0 0 1 &mpic 0 1 > 08000 0 0 2 &mpic 1 1 > 08000 0 0 3 &mpic 2 1 > 08000 0 0 4 &mpic 3 1 > > > [ repeated per IDSEL ] > >> > > I don't see 'interrupt-map' mentioned anywhere in the ./Documentation > tree - it took me a while to find out what these numbers actually > meant. It's documented here: http://playground.sun.com/1275/practice/#imap Once the ePAPR document is released, there'll be an all-in-one document, but for now the documentation is somewhat scattered. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: The 2.6.25 kernel dosen't run on pq2fads based board
Matvejchikov Ilya wrote: Hi all! There is a problem with 2.6.25.4 kernel on the pq2fads based board. Works for me using cuImage. ## Booting kernel from Legacy Image at 0020 ... Image Name: Linux-2.6.25.4 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1534783 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Flattened Device Tree blob at 0080 Booting using the fdt blob at 0x80 Loading Device Tree to 007fe000, end 007f ... OK I don't see FDT support for this board in current u-boot (I should really get around to fixing that...), so I assume you're using a modified u-boot? Xid mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit << the reset was here :( Perhaps your u-boot isn't properly filling in the memory node. Oh, and just in case -- if you're using binutils 2.17, it's buggy. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question about "native" compiling
[EMAIL PROTECTED] wrote: If we do our compiles on a G5 is it really a 'native' compile or is it a cross-compile and we're back in the same boat as we were with the x86? Should we use a G4 instead? You can run 32-bit userspace on a G5 -- it's probably even the default in most distributions. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Running a section of code from internal memory
Sanal Kumar V K wrote:
Now if I make the following entry in the linker script,
/* define L2 scratch here */
. = 0x9FC16800;
.l2_scratch : { *(.l2_scratch) }
it says "collect2: ld returned 1 exit status".
I'm guessing there was an earlier error message printed by ld?
You probably located the L2 section too far away from the main section,
and it's trying to do short branches or other limited relocations.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Running a section of code from internal memory
On Thu, May 08, 2008 at 05:06:46PM +0530, Sanal Kumar V K wrote:
> A small part of the code needs to run from the on-chip "L2 scratch" for
> getting optimum performance. I would really appreciate if some could
> give me some pointers regarding the following questions:
>
> 1. Is #pragma section supported by gcc.
> The compiler prints this warning "ignoring #pragma section" and the
> pragma is ignored indicating that it is not supported. Is there any way
> I can get the pragma working for gcc or any alternative?
__attribute__((section("section name")))
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...
Mike Timmons wrote: If I'm not supposed to read the interrupt using config_read, should I also not be writing to the host register on the coral P to clear the interrupt? Should I instead be using some PCI helper functions? No, clearing interrupts is device-specific. Have you verified that the device does not think it's generating an interrupt during the interrupt storm? Do other PCI cards work? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...
Mike Timmons wrote: pci_read_config_byte(pci_dev, PCI_INTERRUPT_LINE, &irqnum). Don't do this; use pci_dev->irq instead. If that value doesn't work, check your interrupt-map in the pci node of the device tree. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mpc8379e rdb nand flash support
On Thu, Apr 24, 2008 at 09:52:25AM +0800, ??? wrote: >Since our projects need more capability to store filesystems,I changed > nand flash to 1G byte. > I think it is the same to operate nand flash both in u-boot and linux > kernel ,because the code about FCM nand flash control is almost the same.So I > just test it in u-boot. > From the mpc8379e reference manual page 484 : > 21PGS NAND Flash E2PROM page size, buffer size, and block size. > 0 Page size of 512 main area bytes plus 16 spare area bytes > (small page devices); > FCM RAM buffers are 1 Kbyte each; Flash block size of 16 Kbytes. > 1 Page size of 2048 main area bytes plus 64 spare area bytes > (large page devices); > FCM RAM buffers are 4 Kbytes each; Flash block size of 128 > Kbytes. > > Because the 32M nand flash block size is just the 16Kbytes,and it > works well.But the block size of the 1G bytes nand flash is > 256Kbytes,when every time I tried to write to it ,It just can be writed > the first 128kbytes of every 256kbytes.As I wrote in last email. > Below is the linux kernel information when I operate nand flash. Try changing set_addr() to hardcode the shift applied before writing to FBAR to the width of FPAR[PI], rather than basing it on the actual erase block size. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SKB corruption on heavy traffic
On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote: > It't quite dificult to say if the problem exists without our > changes, since the all software is dependent on this changes so > to work with the hardware. I can't answer to that right now on > that, but I forgot to add one thing: we have ring buffer full > problems on our fcc_enet driver from time to time. So, I think > the problem could be on linux configurations (related to hw) > because there is a lot of posts on the web related to problems > similar to this (none of them has really solved the bottom > problem). One thing you could try is to enable slab debugging, rather than your custom debugging code; this will poison the memory upon free, making it more likely that whatever is accessing it will crash immediately rather than just cause corruption. Or, if you want to mantain the delay, do the poisoning yourself. Of course, this won't help if the access is write-only, or if the corruption is happening via DMA. When you say you have a full ring buffer, do you mean tx or rx? Does it recover gracefully? Do you think it's caused by something other than sending data faster than the line can support (tx) or receiving packets faster than the cpu can handle (rx)? Are any of the other problem reports from recent, unmodified kernels (2.4 is very old)? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SKB corruption on heavy traffic
On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote: > We are developing a MPC8247 based telecom board (512MB), using > linux 2.4 with some proprietary changes on IP stack and we are facing > some problems when we have heavy traffic on our Ethernet interfaces... Do you see these problems without the proprietary changes, and with a current kernel? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mpc8379e rdb nand flash support
On Wed, Apr 23, 2008 at 03:47:00PM +0800, ??? wrote: > Dear all: > Did anyone use mpc8379erdb board? I changed nand flash from samsung 32M > to hynix 1G byte.And the 1G byte nand's erase block size is 256KB. > Now the problem is: when I use " nand write.jffs2" command to write jffs2 > filesystems to nand flash ,there is only 128KByte of every erase blocks can > be writed. > From the datasheet of the mpc8379e ,"Page size of 2048 main area bytes > plus 64 spare area bytes (large page devices); > FCM RAM buffers are 4 Kbytes each; Flash block size of 128 Kbytes." > Is it means mpc8379e only support 128Kbytes block size? > Here is the information when I tried to write it : It looks like you're talking about u-boot, not Linux; the FCM NAND driver has not yet been merged. Are you using a Freescale BSP? If so, it's best to go through official support channels. If you're using patches that were recently posted, make sure you have all the bugfixes that recently went into the linux mtd tree. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help! mpc8247 porting kernel 2.6.25 problem.
On Tue, Apr 22, 2008 at 01:10:54PM +0800, 张世乐 wrote:
> Thank you, Doctor Scott. I'm very grateful to you for you kindly help.
>
> I'll try the way you suggested soon.
>
> And, my code for light the led run as follows:
>
> void set_led_a_red(void)
> {
> /*PDIRC: 0xfc010d40*/
> /*PPARC: 0xfc010d44*/
> /*PODRC: 0xfc010d4c*/
> /*PDATC: 0xfc010d50*/
> *((unsigned long *)(0xfb010d40)) |= 0x00d4;
> *((unsigned long *)(0xfb010d44)) &= ~0x00d4;
> *((unsigned long *)(0xfb010d4c)) &= ~0x00d4;
> *((unsigned long *)(0xfb010d50)) |= 0x0004;
> *((unsigned long *)(0xfb010d50)) &= ~0x0010;
> }
Use out_be32(), and put a dcbf at the end. If the dcbf doesn't help, try
not accessing any I/O until after the MMU is set up, and use a
cache-inhibited BAT mapping. It's usually not between enabling caches
and enabling the MMU that something goes wrong, but it is a rather
annoying debug barrier.
As for early debug output not working, another possibility besides the
descriptor address is that ppc_md.probe is failing, or that your board
file doesn't set ppc_md.progress to udbg_progress.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help! mpc8247 porting kernel 2.6.25 problem.
On Mon, Apr 21, 2008 at 11:06:28AM +0800, 张世乐 wrote: > Uncompressing Kernel Image ... OK > Booting using the fdt at 0x60 > > [nothing output and hanging here] > > I use the led on the board to trace the kernel fund it stop in the function > > setup_common_caches in arch/powerpc/kernel/cpu_setup_6xx.S > > Can you give me some ideas? That's probably not where it's actually stopping, but rather where caches are enabled without the MMU, thus making it difficult to access devices. You can try placing a dcbf after each write to the LED register, though this may perturb nearby registers. Have you tried enabling early debug printk? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MVL Linux on MPC8560 Booting goes into infinite loop in early_init memset_io ( )
Deepak Gaur wrote:
Hi all,
While booting MVL linux
Have you talked to MV support? For community support, it's best to use
the latest upstream sources (and arch/powerpc, not arch/ppc).
BTW, it's generally bad form to post the same question repeatedly. If
you have new information regarding your problem, just post a followup in
the same thread containing the new information.
arch/ppc/kernel/setup.c
unsigned long
early_init(int r3, int r4, int r5)
{
unsigned long phys;
unsigned long offset = reloc_offset();
/* Default */
phys = offset + KERNELBASE;
/* First zero the BSS -- use memset, some arches don't have
* caches on yet */
memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
__bss_start is 0xc039b00 and __bss_stop = _end =c03c7d90 _end
Please anyone give me some pointers to understand this i.e use of
PTRRELOC
The kernel hasn't been remapped yet, so the pointer is adjusted manually.
and REASON BEHIND clearing area from __bss_start to _end - __bss_start even
though lot of
symbols and functions are defined here(as per System.map)
That's what the BSS is for -- symbols that are cleared at runtime so as
to eliminate the need to store them in the image. There should be no
functions in there.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Unable to handle kernel paging request for instruction fetch???
郭劲 wrote: Hi,all, I run the iperf tool to test the ethernet throughput for my MPC8360E board, after about 20 minutes, the exception is happened. Could you tell me why? Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x4e800020 Oops: Kernel access of bad area, sig: 11 [#1] MPC836x MDS Modules linked in: encoder mpc_sync k_spi(P) Can you reproduce it with kallsyms enabled, and without the out-of-tree module(s)? NIP: 4e800020 LR: c01a08d4 CTR: Something branched to a bad address from 0xc01a08d0. Can you look up what line that is in your kernel? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
