Re: 8xx: Work around CPU15 erratum.
On May 14, 2008, at 10:52 AM, Ben Gardiner wrote: So there likely are reasons why the following is not possible: That's way too much code for a tlb exception handler. From a system resource perspective, you are much better off with a small and efficient piece of tlb loading code, always invalidating pages on both ends and taking the tlb exception fault. Unfortunately, this could cause some thrashing edge cases, so a little intelligence would be needed. Exception processing isn't free, and it quickly destroys the cache footprint of your application, further slowing down the entire system. The tlb reload handler goal should be maximum of 8 instructions and 4 memory accesses, not 4K of elaborate conditional testing. :-) Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to map addresses beyond 4GB
On Nov 22, 2007, at 2:42 AM, Dell Query wrote: May I know how to map this one? Just call ioremap() as usual. It will understand the 4G physical address and return a useful virtual address to you. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mpc 860 boot linux2.6.23 problem
On Oct 16, 2007, at 12:18 PM, Scott Wood wrote: Upgrading to the latest u-boot certainly shouldn't hurt, but I don't think there's any device tree support for 8xx yet, Have you tried it? Works for me. In fact, most of the development you see today was done by Pantelis on the 8xx. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
On Sep 24, 2007, at 11:22 AM, Scott Wood wrote: cpmp is a physical address on arch/ppc? No, it's a well known ioremaped() address into the IMMR space. The only physical addresses in any of the CPM/CPM2 are those required to by the buffer descriptors. There are DPRAM offsets, but they should be just that, offsets from either a virtual or physical base address as required. Too many people screw around in this CPM support code without fully understanding the original implementation or its intended use with the peripheral drivers. A better idea often breaks all drivers except the one that is being changed. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Breakpoint is not hitting for Kernel Debugging
On Sep 3, 2007, at 7:02 AM, dnl wrote: Hi all, I am using uboot and montavista kernel for our custom MPC8555CDS board. You should contact MontaVista first, since we really don't know what your source code looks like. I'm assuming it's a ppc, not powerpc, although the patch is similar for either choice. I'd suggest this as a starting point: diff -Naru linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S linux-2.6.21- dbg/arch/ppc/kernel/head_fsl_booke.S --- linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S 2007-07-05 13:08:16.0 -0800 +++ linux-2.6.21-dbg/arch/ppc/kernel/head_fsl_booke.S 2007-07-10 03:45:33.0 -0800 @@ -317,6 +322,16 @@ /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 +#else + /* Enable BDI200 debugging beyond this point for normal +* kernel debugging. If you are debugging code prior to this +* point, it needs to be done with more specific set up +* of configuration files and boot rom. +*/ + mfmsr r2 + ori r2, r2, MSR_DE + mtmsr r2 + isync #endif Your first breakpoint should be a hard breakpoint at the label start_kernel. You can then switch to soft breakpoints and continue your debugging. Ultimate Solutions have some useful white papers on kernel debugging with the BDI2000 (that some people have plagiarized). Check out ultsol.com Good Luck. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: my cpu is MPC860, kernel version is 2.6.20.14, the kernel start info in the mail. why does the kernel panic?
On Aug 6, 2007, at 8:52 AM, Scott Wood wrote: It wouldn't surprise me if the 8xx code has issues with PREEMPT; try turning it off for now. What is your reason that 8xx would be any different? -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Memory coherency on MPC8272
On Jun 22, 2007, at 10:28 AM, Dmitri Petchkine wrote: My understanding that the security hardware of MPC8272 uses DMA to write results into the memory which may cause a coherency problem. Where did you get such an (incorrect) understanding? I suggest you acquire your understanding from reading the MPC8272 reference manual, since it describes the cache and snooping options between the SEC and memory, as well as among the SEC units. My exposure to such hardware issues is very limited, so I appreciate any advice on how to fix it. The code snippet clearly shows you don't understand the user/kernel interface, since your access to param isn't correct. The SEC is complex and has subtle control considerations, any part of this could be incorrect. I suspect your coding errors are hidden/highlighted by adding the code for the printing, not the actual operation itself. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ttyS0 ttyS1
On Mar 23, 2007, at 3:43 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, i have problems to use ttyS1 on my TQM885 Board. fd1 = open(/dev/ttyS0,O_RDWR); fd2 = open(/dev/ttyS1,O_RDWR); If you are using 2.6 kernels /dev/ttyCPM0 and /dev/ttyCPM1 Otherwise, ensure additional serial ports are configured in your kernel and the device nodes exist. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote: Since you say no one has ever used more than 4 UARTs, there are two options: People have used more than 4, but we just allocated the additional /dev entries to cover them. I know of only one time this has happened. It's such a custom case that the other device names didn't matter. - Cap the driver at 4 UARTs; Let's do this, but design the code to allow more by just changing a #define. Just randomly using some extra minors that aren't assigned to you isn't such a great idea. Maybe for a desktop or generic server where you don't know what's going to be configured, but it's not unusual to do so with custom embedded systems. The small experimental or user allocations often don't cover what is needed, so we just grab some allocation from a device that isn't ever going to be used on the system. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
Since I'm probably the only one that really uses the driver for custom uses and cares.. On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote: Ok guys, I need a consensus here. Are we going to allocate a second block of 4 minor numbers for the QE/CPM UART or not? not. My driver already has a macro that limits the number of UARTS to 4, perfect. I'll add a second TTY struct... Don't worry about it for now. We'll just keep this in mind when we make a major change someday in the future. We may have a better solution then. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote: 46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). It's obvious it shouldn't be 47, but it's not obvious it should be 49 instead. I don't know the origin of this thread, but none of that looks correct. Today, there can be up to 8 CPM UART devices, 6 on CPM/CPM2 and 8 on the QE. If ttyCPM0 starts at minor 46, they should be at least monotonically incrementing up to ttyCPM7 with minor 53. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote: ... However, ttyCPM0 is currently assigned to 46, and device 50 is an Altix serial card. The only way to give the CPM 6 or 8 slots without moving it is to overlap the Altix card. Then, this is currently broken in all cases and needs to be fixed since the CPM/CPM2 could have up to six UART ports. Now I don't know anything about the Altix card, so I don't know if it's possible to use that card on a system with a CPM or a QE. If it isn't, then I don't know if overlapping minor numbers is still a problem. I don't think that would be a problem, and I'd like the CPM/QE to share devices because it makes the software distributions common to all Freescale embedded processors. If we move CPM/QE to 192, then I can change the CPM device driver to reflect that, but I don't know what that means for older kernels. That would be bad. It has nothing to do with the kernel, but we have finally survived the distribution updates to ttyCPM, and I don't want to go through that again just because of QE. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote: An alternative idea, which one person already shot down, was to allow only 4 devices normally, but allow more devices if you use udev, since udev doesn't care about minor number assignments. This eliminates the overlap and encourages people to use udev. I'd shoot that down, too. Using udev in an embedded, reliable environment is very troublesome. Although, products I've developed using more than 4 UARTs had some custom /dev work done to it just to get everything mapped. My only concern is we don't add a new range for QE UARTs, that we use the same minors for both CPM and QE. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 1:00 PM, H. Peter Anvin wrote: I would much rather see these devices moved to a different minor range. No. We just did that all too recently, and i don't know why the minors didn't get allocated properly. I don't want to have to update all of our embedded software distributions just because someone doesn't like minor numbers that aren't causing trouble. If we allocate unique spaces for all of the possible UART variations, there isn't going to be enough space. Just allocate the four slots and we'll deal with anything above this in custom products. Using more than four of these processor resources as UARTs isn't likely to happen because there won't be anything left for the interesting communication ports. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote: What about major number 205? It also has the screwed-up /dev/ ttyCPM entries, but it has more room, and the CPM driver doesn't actually use it. At least, I can't see where it uses it. Please, let's just leave the four we have and let the driver just allocate increasing minor numbers. If anyone has a product with more than 4 UARTs, they will have to figure out what to do with the additional minors. We are making a very complicated problem out of nothing. This hasn't caused any problems in the past, and changing the existing names and minors will cause problems for everyone today. Just leave it alone, fix up the documentation, and have the driver print some warning if it allocates more than 4 UARTs. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: question about m8260_cpm_hostalloc
On Feb 9, 2007, at 4:58 AM, stefania magistrali wrote: Hi! I am using the m8260_cpm_hostalloc function. My question is: does this function return cached or uncached memory? It returns a cache coherent address space. Whether it's cached or uncached is determined by the capabilities of the processor. I need to have uncached memory, Why? The CPM on the 82xx performs cache coherent data transfers with the G2 core. Make sure you are using the proper memory allocation functions. The XXX_cpm_hostalloc() function is intended to provide an efficient allocator for the small memory resident FIFOs or control structures needed by the CPM. It's not a data transfer buffer allocator. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mpc875 Ethernet does not work under linux.
On Feb 8, 2007, at 5:00 AM, Cem Vedat ISIK wrote: I'm having a problem using ethernet with denx-provided kernel: linuxppc_2_4_devel-2006-04-06-1735 on mpc875 (a member of mpc885 family). Sounds like you didn't properly port your kernel. I use both 2.4 and 2.6 on 875 and 885 every day. Works fine. Take a look at your clock routing and PHY support functions to ensure that's all correct. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
On Jan 25, 2007, at 1:56 PM, Ramirez-Ortiz, Jorge wrote: We are currently using two BDI-2000s to debug 2.6.18 kernels on the ppc8545 rev(2) devices with no problems reported so far (apart from a minor patch required in the kernel to set up breakpoints). I'm working on a proper patch to add all of this formally to the sources. It's been irritating me for a long time, so I'm reworking some of these jtag debugger options. Unfortunately, it touches more than just 85xx to get it right. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Have anyone ever done migrating SCC Ethernet drivers and SMC UART drivers from 2.4 to 2.6
On Jan 11, 2007, at 6:08 AM, Aung Soe wrote: Have anyone ever done porting Power PC SCC Ethernet drivers and SMC UART drivers from Linux Kernel 2.4.20 to 2.6.x? We have done this long ago. What's your concern? -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MMU issue on mpc8270
On Nov 23, 2006, at 11:13 PM, Lei Sun wrote: Hi all: While trying to bring up the kernel-2.4.30, my debugger failed to show memory content after MMU is turned on. Sounds like a debugger configuration problem. ... So I added some debug serial_putc() function copied from u-boot. (since u-boot has intialized the UART). You don't need to do this. There is sufficient and working early serial debug in the kernel that is started as early as possible. The code did printed out the debug message untill it reached mapin_ram() function. To be precise, in map_page() funcion, after pte_alloc() , serial_putc() doesn't work anymore. There are times during the kernel initialization when all of the MMU mapping is being configured, that you have to be cognisant of the mapping changes. Early mappings disappear in favor of more operational ones, so the serial port mapping is going to change as well. The call to pte_alloc() is irrelevant, except that it affects the MMU configuration and likely removes the old mappings. The 82xx boot up initialization works fine, and is completely generic to any board at this point. Rigth now, my kernel does seems to be running, but i just couldn't see anything on the serial console, Fix your debugger configuration so it works in this environment, or use xmon or early serial debug options that are built into the kernel. I have examined the serial console portion of the code for many times, couldn't seems any thing wrong. Have you selected the proper kernel configuration or passed the proper console= parameter to the kernel? Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: BDI2000 with MPC5200 and userspace programs
On Nov 15, 2006, at 9:25 AM, Grant Likely wrote: I don't think so, but why would you need to? That's true. It's so much easier to use gdbserver or even native gdb on the system. Unlike some other embedded environments that require you are tethered to the hardware debugger for all development, Linux has the flexibility to provide more powerful and easier to use tools. The reason I added the BDI_SWITCH was to track the user application page table of the active thread. This way, if you are debugging some driver, you can trace back into the application and glean some knowledge about what the application did to get there. Ultimate solutions has a product that does this. Which is really nice because you can get all of the BDI support for kernel debugging, then use the same IDE to support gdbserver for application debugging. Although the back ends are different, the debugging environment is consistent. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Performance on PowerQuicc8280 linux based
On Nov 15, 2006, at 11:21 AM, Jeff Mock wrote: I'm no big help, but the problem might be TLB related instead of cache related. The performance of embedded PPCs with small TLBs requiring software assist for TLB misses can be performance sensitive to TLB misses. The 82xx is fully cache coherent and has BATs for mapping the kernel space. This is not a PPC with a small TLB, but rather one of the most efficient. The TLBs are not an issue, and I doubt the caches are as well. I don't know what kind of test is used to measure this performance, but the first thing you must always scrutinize are your testing methods and procedures. Just using a user application to measure network performance enables a large number of variables that must be properly understood and controlled. Some other thread could have switched in and stolen CPU cycles, you could have some sampling rate and time measurement hysteresis due to buffering, you need to find and control such things. Can you undo the changes and get the old results? That's the first thing I would verify, and then verify the results are repeatable. If that's the case, I'd carefully try to understand what this unrelated change really affects in terms of using CPU cycles. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Possibly OT: bdi2000 virtual memory on 2.6 kernel
On Nov 13, 2006, at 10:17 PM, Robin Gilks wrote: Debugging a 2.6.18 kernel on a powerpc target Which processor, specifically? What do your MMU XLAT and PTBASE configuration lines look like? Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM_UART: tcdrain() is broken
On Nov 13, 2006, at 10:56 AM, Laurent Pinchart wrote: There is, however, a problem left. The SCC controllers have a 32- byte FIFO between the buffer descriptors and the wires. cpm_uart_tx_empty() checks if all buffer descriptors have been processed, but doesn't check if the transmit FIFO is actually empty. There is no way to determine if the hardware FIFO is empty. It's buried under the CPM microcode. . I can't figure out how to do so from the datasheet. Does anyone have an idea ? The original versions of the SCC UART driver used to have a timeout based on the maximum depth of this FIFO and baud rate. After the last BD was empty, it would further wait this amount of time. Lots of these little details seem to have been lost over the years of making a better driver :-) -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
On Oct 24, 2006, at 5:16 AM, KRONSTORFER Horst wrote: i therefore 'simply' removed the mdio bus and phy support and tested with ping over tsec0. My experience with similar designs is you can't just remove the knowledge of the phy from the driver. You have to fake some kind of phy that causes the driver to initialize the tsec properly. With more people using this kind of design, it would be nice if we could extend the phy support to more generally allow this. For now, you will have to make some code modifications that basically result in the phy functions finding a phy and properly initializing the data structure information to match the connection between the tsec and the switch. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ioremap() fails for 64 MB
On Aug 23, 2006, at 6:00 AM, Phil Nitschke wrote: Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit processor, why do I need high memory at all? Because the processor used virtual memory addressing, and we divide this 4G virtual space up among application, kernel, IO mapping, etc. The kernel can't map the whole 4G (or even the 2G) physical space at one time. I avoided this simply because I wanted to load/unload my driver (during development), My personal preference is to debug drivers in a development mode by building them into the kernel. I find it easier to debug, and you are also likely to be rebooting anyway :-) -- Dan
ioremap() twice on same memory mapped area?
On Aug 19, 2006, at 2:52 AM, Parav Pandit wrote: Question is: Can both the driver call the ioremap() on the same space and get the different virtual address? Yes, and depending upon the implementation and optimizations, they may also get the same virtual address. It will work as you intend. -- Dan
CPM2 UARTs: Won't work under low (= 1200BD) baudrates?
On Aug 15, 2006, at 3:52 PM, David Tao wrote: Under 2400 baud or above the UARTs work fine, but once the baudrate set to 1200 or below, there is NO data can be sent out or received even programed to do so. It doesn't look like we check the baud rate and add the preceding divide-by-16 clock for the low baud rates like we did on the original CPM. You can add this, test it, and submit a patch if you like :-) Thanks. -- Dan
multicast for 8260 for 2.6.13
On Jul 20, 2006, at 10:45 AM, Harnois Anne-Sophie wrote: In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list function is commented out and I can't figure out why. Read the mailing list archives. I checked the code, removed the comments and tried it, and multicast seemed to work properly. Sorry, but that code will never work on a 82xx. What am I missing? Could someone explain me why this is commented out? Because it was copied from the 8xx many years ago when I ported the driver, and the 82xx lacks the CRC generator support. You can enable promiscuous mode, which is what I suspect you did, and then the Linux IP stack will do the multicast filtering. By the way, this driver is obsolete and you should be using the version in drivers/net/fs_enet. Thanks. -- Dan
rs232 endianness on PPC
On Jul 1, 2006, at 4:53 AM, White wrote: PowerPC is only Byte swaped, not bit-swaped :) PowerPC isn't byte swapped, the other world is :-) The second: I think the bitorder on the rs232 is standarized :) and should be the same ... :) RS-232 is LS bit first. -- Dan
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
On Jun 7, 2006, at 8:34 AM, Laurent Pinchart wrote: I'm not sure how to fix the problem They way this _used_ to work is the DPRAM memory allocator knew the SMCs had allocated the lower 128 bytes of DPRAM and it never would allocate this space to anyone else (and it should not free it either). The constant #defined values for the SMC base address would work just fine and could be assigned as part of the SMC uart initialization. Due to the alignment restrictions and no reason to relocate this space anywhere else, this still seems to be the most efficient method. -- Dan
Can't get CoralP drivers to work
On May 24, 2006, at 12:54 PM, jourdan at enib.fr wrote: I have a MPC8260 processor card with a Coral-P evaluation board (rev 4.0). Are you sure? The 8260 does not have a PCI bus and the Coral-P is a PCI card :-) Good Luck. -- Dan
IMAP_ADDR on PPC 8xx
On May 10, 2006, at 12:49 PM, Walter L. Wimer III wrote: FYI, here's a table from the MPC885ADS PowerQUICC(tm) Application Development System User's Guide, available on Freescale's website. This table seems to confirm how they've configured their U-Boot -- the IMMR is set to 0x0220... Freescale never ported U-Boot to the MPC855ADS platform, and I don't believe it came with any software at all. This IMMR value was chosen to be backward compatible with some old software tools to get a compact address space without the need of using the MMU, long before we had Linux running on the platform. This may be fine for non-Linux purposes, but it looks like we need to spread some gospel to Freescale regarding the correct IMMR address for U-Boot / Linux I think you better be pointing fingers at the clueless person that provided the software you have, as it didn't come from Freescale nor any of the public U-Boot sources. Thanks. -- Dan
IMAP_ADDR on PPC 8xx
On May 9, 2006, at 3:52 PM, Walter L. Wimer III wrote: Exactly. I think this kind of automatic adaption to the particular platform is what should be in the vanilla kernel. This does not mean you can choose some arbitrary value. There is a small range of high memory addresses that will work successfully for IMMR. You may not see any problems right away, but depending upon drivers selected and the software features used, some problems will crop up. There are also MMU performance enhancements that may be used with certain values, and guaranteed kernel crashes at some point in the future when abused. With Linux, the IMMR should always have a value of 0xf000 or 0xff00 for best results. This was the second major part of our 2.6.11.7-based patch. It performed a single ioremap(), stored the result in a global pointer, and then used that pointer in all the drivers instead of using IMAP_ADDR directly. This is not an acceptable practice. We are removing all global pointers like this, and any driver that needs access to some or all of the IMMR space should be individually mapping those regions it needs. Under the covers of ioremap() we are performing various alignment and reuse of address spaces in order to support things like performance enhancements and cache coherent regions. Thanks. -- Dan
Linux 2.6 sources for MPC852T processor
On Apr 26, 2006, at 7:50 AM, David Jander wrote: Yes, MPC852T is supported, although I might add that I have been using 2.6.14 and 2.6.15 sucessfully with our own MPC852T-based board, but 2.6.16 did not boot and as of today I don't know why, or whether this is an issue at all with boards other than ours. There is a horrible bug in the 8xx TLB miss handler that is in the 2.6.16 sources. I don't know when it appeared. Enable the CPU6 Errata workaround to see if that solves the problem and please report back to me. I'm working on a solution. Thanks. -- Dan
kernel 2.6.15: cpm_uart driver broken?
On Apr 19, 2006, at 3:24 PM, Kenneth Poole wrote: /* get pointer */ - cp = cpm2cpu_addr(bdp-cbd_bufaddr); + cp = (unsigned char *)pinfo-mem_addr + (bdp-cbd_bufaddr - pinfo-dma_addr); Ummm, no. Keep the cpm2cpu_addr() and pass it some driver data structure pointer so it does the computes, or better, keep the phys/virt addresses in a handy data structure you can easily access and work with offsets within the different address spaces. The test of addr = CPM_ADDR is critically important to early boot and kgdb support and can't be removed. - bdp-cbd_bufaddr = cpu2cpm_addr(mem_addr); + bdp-cbd_bufaddr = dma_addr; This kind of initialization is broken, too. You have to test that memory address and return the proper space. Thanks. -- Dan
kernel 2.6.15: cpm_uart driver broken?
On Apr 19, 2006, at 4:40 PM, Kenneth Poole wrote: . we avoid having to do those conversions all of the time. You are still doing a very similar conversion, only with different addresses and offsets, and more compute operations. I assumed that this test was simply to exclude console ports from conversion. Bad assumption. It's done to be able to use buffers allocated out of the CPM memory or before the VM is sufficiently configured to relocate the buffers. This is needed for early debug prints, xmon, and kgdb. These modifications further remove features that have been part of past kernels, and it has to stop. Thanks. -- Dan
mpc5200b and floating point
On Mar 31, 2006, at 1:27 PM, Roger Larsson wrote: Since a lot of PowerPC do not have floating point processor your tools might be setup to compile without it (compare with sse2 on x86). Nearly all of the PowerPC do have floating point, only a few do not. It's highly unlikely to find a PowerPC tool set that was custom built to not enable floating point. Don't forget that the compiler flags are only a small part of the picture, you need matching compiler run time support and application libraries as well. Just using the compiler flags and not selecting the proper libraries will not be a positive experience. -- Dan
Stable Linux kernel 2.6 for MPC8XX
On Mar 14, 2006, at 2:50 AM, David Jander wrote: I don't know why, but while everyone still says 2.6 is slower, I am consistently getting results that seem to prove the opposite. Why? Because this is a compiler test and not an OS test. The newer ELDK with 2.6 has better compilers. -- Dan
Stable Linux kernel 2.6 for MPC8XX
On Mar 10, 2006, at 2:22 AM, David Jander wrote: I believe most of those observations and measurements are not valid anymore. Kernel 2.6 for 8xx has come a long way since this article was written. They are still valid, we just have more knowledge about how to configure the kernels and have added some features you can use to mitigate the performance issues. The Linux 2.6 kernel is simply bigger than 2.4, and on these small, resource challenged processors, you need to very carefully configure the kernels to your requirements. Thanks. -- Dan
GNU and Freescale MPC83xx / e300 core support?
On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote: . The most obvious core difference is the Floating Point unit; the MPC8280, 603e or G2LE core had no floating point ability at all. I just want to state for archive purposes this simply isn't true. All of those processors had hardware FPUs. If you would take a few seconds and read the product overviews for these parts, you can make your own informed decision. The person you are talking to doesn't seem to have all of the facts in order. -- Dan
Different Page Size Support in Linux on PPC870
On Mar 3, 2006, at 9:38 PM, atul.sabharwal at exgate.tek.com wrote: On PPC870, does the kernel only support 4K pages? The CONFIG_PIN_TLB will get you 8M pages for the kernel space, and likely be a good solution for you. We have experimented with various dynamic replace methods for the past several years, but I still haven't found a solution I like. -- Dan
u-boot 1.1.4 using two fecs
On Feb 22, 2006, at 12:50 PM, dibacco@@inwind..it wrote: Is it possible in your opinion to use both the fecs on a board in the u-boot? I read something saying only one can be the active one. Yes, it works just fine, and you should be asking such questions on the u-boot mailing list, not here -- Dan
SCCx UART status on 8xx
On Feb 20, 2006, at 3:15 PM, Wolfgang Denk wrote: All UARTS (up to 2 x SMC + 4 x SCC, depending on CPU model) can be used with our tree, including hardware handshake. Except that you have to be careful about BRG allocation. At most, the 8xx will have 4 BRGs, some only have 2. There have been various implementations to work with this, some forced the BRGs to be multiply mapped (where more than one UART had to run at the same rate) while others silently returned errors and the UARTs were non-functional although appeared for use. Thanks. -- Dan
arch/ppc/82xx_io/uart.c bug found
On Feb 13, 2006, at 8:51 AM, Wojciech Kromer wrote: here is orignal uart.c Three things One, this code is obsolete and isn't used any more. Two, it's not a bug, just a feature enhancement. Three, if you want us to actually do something about this I need a real patch against an up to date public source tree and indication it was actually tested on some platform. Thanks. -- Dan
Linux MontaVista Fujitsu CoralP SDL - Please help
On Feb 9, 2006, at 2:15 PM, Eli Orr wrote: I was goggling around and found you listed as people who somehow related to Fujitsu CoralP. Well, I think Wolfgang Denk gets all of the credit for originally writing the software. I've used it to enable the STx GT3D CoralP board on the MEN5200 board with various Linux kernel distributions. I need help to find a source code /? object for: Fujitsu CoralP SDL for Linux MontaVista 3.1 Kernel 2.6.x There are a few of us here in the business of providing such services :-) Somehow MontaVista 3.1 and Linux 2.6 don't seem like a match. Have you asked them? Thanks. -- Dan
MPC875 using SCC4 together with both FECs
On Feb 7, 2006, at 5:24 PM, dibacco@@inwind..it wrote: Someone knows if, in MPC875, SCC4 can be used together with the two FECs? I saw that RXD4(input SCC4) shares the same GPIO with MII-TXD0 (output of FEC0). That's a correct observation, you can't do it. I don't remember and don't have documentation handy, but would it work in RMII mode? Otherwise, you will have to step up to the MPC870. -- Dan
Floating point math in kernel interrupt -- am I doing this right? (repost)
On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
and the mixing is done inside an
interrupt routine that runs 6000 times per second, and calculates 8
samples
per interrupt.
Bad news. No Floating Point allowed in the kernel.
In order to do the necessary floating point math, without corrupting
the state
of any other processes that might be using the FPU, the interrupt
routine
first saves the state of the FPU registers to the stack, then does the
math,
then restores FPU registers again, before returning.
Not on 82xx. All floating point is done in hardware.
The oops
looks like this:
These aren't helpful without some supporting information, like
symbols, or learn to use ksymoops.
So my question is, is there some minor detail that my
FPU-state-save/restore
code is missing, that would cause these sort of symptoms?
Just get all of this out of the kernel. If you used the standard ALSA
drivers and framework, lots of mixing features are available to you.
If you need some custom mixing, just write a plug-in to do it.
Your data rates are so low they don't justify making any hacks
like this.
Thanks.
-- Dan
Gdb with MPC85xx
On Feb 3, 2006, at 3:46 PM, atul.sabharwal at exgate.tek.com wrote: To the best of my knowledge, I had could single step but not run to a breakpoint in the initial u-boot code on PPC8540( an E500 core based) This is a problem with many processors and has been discussed at length too often. The quick response is that various initialization code in both boot roms and Linux will disable/reset or otherwise mess up debug registers the BDI has configured for it's use. So, it isn't the fault of the BDI2000, you may have to temporarily disable or modify the code under test in such a way to not do this. There are several tricky places to debug code, that are completely inaccessible without the use of the BDI2000, but that also require some common sense and minor environment changes to properly debug. The e500 core (and Book-E in general) significantly complicated the ability to debug in some modes of development, so you are most likely to see problems with these processors than others. Thanks. -- Dan
Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
On Feb 2, 2006, at 10:42 AM, Laurent Pinchart wrote: The new fs_enet driver internally maps CPM_MAP_ADDR. Should every driver create an internal CPM mapping ? Yes, they should. All drivers should do the ioremap() and stash the pointer internally. Why was the old fec_enet driver able to access the CPM through CPM_MAP_ADDR without ioremap()ing it first ? Because that's a long left over performance hack from many years ago when I first implemented the 8xx software. The IMMR used to be mapped to a well known virtual address, the board initialization did this early, and everyone (ab)used it. This was way back in the 2.0/2.1 days when it was acceptable to do such things :-) Due to the CPM2 now being used on may different Freescale parts, and mapped in various ways, the internal mapping should be done by every driver. Thanks. -- Dan
2.4.x vs 2.6.x performance
On Jan 22, 2006, at 8:24 PM, Frank wrote: I remember reading a while back that the 2.6 kernel is considerably slower I wouldn't say considerably slower, but there are some performance differences. It's most evident on the smaller, slower processors, like the 8xx, but we have taken steps to alleviate that. The problem is 2.6 is just bigger with more stuff in it. You want the new features, you have to pay for that somewhere. I think it would help if the kernel was a little more configurable for embedded systems. It seems there is just too much stuff in a basic kernel that I wish could be stripped out. I'm thinking about moving to 2.6 since a lot of open source projects have stopped suporting the 2.4 kernel. You know, this is a community effort, not when are you going to fix it for me :-) Use 2.6, measure it using your application, and submit updates that improve it. Some of us have already done quite a bit, so do your part, too. Thanks. -- Dan
[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
On Jan 25, 2006, at 3:15 AM, Laurent Pinchart wrote: Should I submit a patch, or leave the code as it is ? Port Das U-Boot. -- Dan
Question about SCC Ethernet driver
On Jan 17, 2006, at 8:28 PM, David Tao wrote: Present MPC8260 SCC Ethernet driver supports?one 10M Ethernet port for SCC1 or SCC2. Not any more. Take a look at drivers/net/fs_enet in the 2.6 kernels. I'm sure Pantelis will have more information when he reads this. 1. Is it possible to?implement 7 Ethernet ports (3 FCCs and 4 SCCs) on a MPC8270? I didn't see any hardware restriction on this. Performance may be an issue?? Depends what you want to do with the data in the CPU core and the clock speeds you have chosen. The CPM can handle the data traffic on the wires if you run it over 133 MHz. Thanks. -- Dan
TLB preloading on 8xx
On Dec 20, 2005, at 12:37 PM, Marcelo Tosatti wrote: Sum up the costs of disabling interrupts and disabling translation, and you end up with a slow dog. Damn, the TLB exceptions are indeed efficient. Like I've always said, make the TLB miss exception path very short and efficient. You have to consider the total system impact of running this code, which includes replacing lots of cache lines that will affect the performance of the application. Don't be looking for tricks in the exception path, look for ways outside of that we can better structure the page tables so we can _remove_ code from the exception handler, not add to it. What you are doing here is an attempt to do that, but you are executing lots more code to do this preload than the TLB miss exception would do. Keep trying, though, this was a good idea to test :-) Thanks. -- Dan
82xx IRQ handling
On Dec 11, 2005, at 9:42 PM, Dmytro Bablinyuk wrote: immap-im_intctl.ic_simrh = ~(0x0800); You should not be messing around with this register in your code. The generic 82xx interrupt functions will properly manage this for you. request_irq(IRQ, irq_handler, /* our handler */ irq_flags, interrupt_test, NULL); This is all you should do. Thanks. -- Dan
[PATCH] Support 8xx based Silicon Turnkey XTc
On Dec 6, 2005, at 9:41 AM, Pantelis Antoniou wrote: Unfortunately is not possible. Due to the way the flash is mapped on boot it is not possible to have it continuous. Believe me I've tried :) I can take the blame for this :-) We used the high boot address mode which isn't good for the larger flashes due to the address aliasing. I'm going to make an even bigger mess and in the next round of boards will change to the low boot memory. Fortunately, there aren't too many of this first version of boards, and those of us that have them will just have to adapt. :-) Thanks. -- Dan
MPC8245 with its internal UART
On Dec 6, 2005, at 7:44 PM, HappyPhot wrote: Who can tell me which flatform is similar to mine ? I've tried make sandpoint_defconfig, but seems not the right one. That's the one I would have recommended. I don't think there is any Linux platform port that uses the 8245 internal DUART, at least not in the public source tree. The DUART is actually pretty easy, just use the generic 8250 driver and point the address to the Embedded Utilities Block DUART. -- Dan
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Dec 1, 2005, at 7:17 AM, Marcelo Tosatti wrote: snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works. Since I'm probably the only one left in the world with this hardware, it probably doesn't make sense to keep it around. I know people have used it in the past as an example of how to program the TDM on the 8xx, but it's not necessary to keep it around for that reason. Thanks. -- Dan
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Nov 23, 2005, at 7:00 AM, Marcelo Tosatti wrote: The files in arch/ppc/8xx_io/ (which is what I think you refer to as candidates for drivers/), are: I don't particularly like these macros, but I'm tired of fighting about it. If you follow the usage path, you will see it's only used in the CPM drivers, and I wish people would just use the data structure pointers to access these ports/bits with standard C code and then place any synchronization instructions properly. There are some cases where you have to be quite careful about how you read and write some control registers, and I think this opens the possibility to just be sloppy and make mistakes since the read/write is hidden within the macro. Does anyone have hardware to test it? Dan? Yes, I have hardware to test it. I will do that one of these days. Thanks. -- Dan
[PATCH] 8xx PCMCIA: support for MPC885ADS and MPC866ADS
On Nov 23, 2005, at 7:53 AM, Marcelo Tosatti wrote: Shouldnt you handle ioremap() failure? Most 85xx code written by Kumar also does not. And do what if it fails? Chances are you don't have any way to report an error message or panic at this point. In fact, there are a few silly tests like this where the failure tries to panic or print some message that will never be seen. Fortunately, the code will never fail and we will never take such code paths. -- Dan
[EMAIL PROTECTED]: Re: BDI and 85xx]
On Nov 14, 2005, at 5:50 PM, Kumar Gala wrote: I'm not 100% sure this is even possible on some of the book-e variants. I suspect we could if we didn't just keep whacking the MSR with some constant value :-) What happens if we just leave DE set all of the time? I know as part of ptrace, etc. it can get manipulated, but if we are debugging through COP we shouldn't get to these software functions. -- Dan
fix swapping on 8xx?
On Nov 8, 2005, at 12:56 PM, Tom Rini wrote: I think Dan might be in the camp that says a properly designed embedded system won't need to swap. I'm actually in the camp that knows the majority of systems running Linux aren't workstations and don't have disk drives. It would be nice to have selectable features for such applications. It sounds tempting indeed, but should you really notice a performance increase out of this? Yes. Most importantly it adds some predictability which is quite measurable on this class of processor. It was a coding mistake way back in 2.2 that actually exposed this. I was taking some liberties by updating more status in the PTE than I should have, and Paulus made me fix it in 2.4 :-) It basically eliminates TLB faults associated with system status tracking, since we aren't paging there isn't any need to track page aging and such. If you are paging, it still functions properly, you may just not pick the most suitable pages to steal. Thanks. -- Dan
fix swapping on 8xx?
On Nov 8, 2005, at 3:52 PM, Wolfgang Denk wrote: Please do not remove stuff that is needed and used to work (in 2.4). I'm not proposing we remove anything :-) It would just be nice to eliminate the overhead of managing the PTEs if we don't need such a feature. The complexity of the TLB miss handler just keeps growing to add/fix this stuff, and it really shouldn't be in that code path. All of this support should be pushed into the error path, and if it was somewhat configurable we wouldn't be in that path if not necessary. Thanks. -- Dan
fix swapping on 8xx?
On Nov 8, 2005, at 5:46 PM, Wolfgang Denk wrote: Hm... as far as I can remember Yes, your patch looks correct. I'll just map these changes on top of the PTEs to verify there aren't some status bits that we may still incorrectly update. When I originally selected the bit positions for the PTEs I didn't properly consider the usage of the PTE during swap (nor did I always have the options I wanted :-)) Among everything else I promised, I'll try to get all of these updates quickly sorted out. Thanks for all of these pointers to old patches, saves me time looking them up :-) -- Dan
[PATCH 2.6.14] mm: 8xx MM fix for
On Nov 7, 2005, at 3:44 AM, Marcelo Tosatti wrote: Dan, I wonder why we just don't go back to v2.4 behaviour. It is not very clear to me that two exception speedup offsets the additional code required for one exception version. Have you actually done any measurements? No, and I didn't actually make these changes, either :-) I'm working on some 8xx debugging right now, so let's experiment with some changes. I don't understand why other processors, especially G2 cores like 82xx, aren't finding the same problems we are having with 8xx. Logically, we are all doing the same thing, unless there are some tlb invalidates on these other processors that I'm forgetting about. We just seem to be running into stale entries, and we have to fix it. Thanks. -- Dan
[PATCH 2.6.14] mm: 8xx MM fix for
On Nov 7, 2005, at 3:50 PM, Pantelis Antoniou wrote: Yep. That should be the target. Remember the poor 8xx is not exactly a speed demon :). It really isn't a big speed difference. The context save/restore is minimal. The original thought was ...well, I'm already here, I know we will take another exception, so may as well fake the error case and call do_page_fault. However, I really do like a minimal TLB miss case for valid PTEs, and push everything else to the heavyweight functions. Thanks. -- Dan
[PATCH 2.6.14] mm: 8xx MM fix for
On Nov 7, 2005, at 1:22 PM, Tom Rini wrote: Assuming Dan doesn't come up with a more simple better fix, maybe we should go back to the original patch I made? I'm working on it. It'll look more like 2.4. Thanks. -- Dan
fix swapping on 8xx?
On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote: The following is an attempt to fix swapping on 8xx by not touching _PAGE_ACCESSED bit if the page is not present. Ugh I suppose. I hate assembler code macros ... Somehow, swapping and 8xx just don't belong together. I'm tempted to add a configuration option that is the complete opposite of this and assumes are really embedded system. Mark pages as always accessed, data pages as always dirty, and you can eliminate lots of TLB faults in systems that are fairly static. None of this should really be done in a TLB miss handler, if there is anything that needs to be updated in a PTE, it should be pushed out to an error function. A TLB miss handler should fit in a cache line .. -- Dan
SM501 Frame Buffer driver on PPC
On Nov 2, 2005, at 8:40 PM, Absolut Hunter wrote: Has anyone used the SM501 driver with this type of NON-Unified memory architecture? What do you mean, non-unified? I am guessing this can be confusing to the driver since the frame buffer registers inside the SM501 need to be using offset ZERO instead of the 0xF800 like the MPC8280 sees. The SM501 PCI driver assumes the addresses are from the PCI base address, not from zero. Properly using the local bus address in a similar way should work just fine. Thanks. -- Dan
MPC8xx soft-float userspace ...
On Oct 21, 2005, at 5:31 AM, Schaefer-Hutter, Peter wrote: Due to the fact that the in-kernel FPU emulation looks broken on MPC8xx i want to build a complete soft-float userspace. How does it look broken? It's always worked for me :-) Does anybody have some pointers what else needs to be removed? Well, if you found it, you should be able to trace this to a source file and remove it, right? Thanks. -- Dan
[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
On Oct 19, 2005, at 8:29 PM, Christopher Cordahi wrote: I don't understand in what way Marcelo wants to use it, but from my understanding and a quick look of the Freescale product summary pages it's the opposite of what you're indicating. OK. I can't find an up to date one any more. From the processor manuals there are overlapping numbers (unless that was just an oversight during editing). Also just because a feature isn't supposed to be present doesn't mean it's not. Yeah, some people have tried probing peripherals to discover the type of processor, but that was quickly proven to not work. Thanks. -- Dan
[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote: For 8xx, I was wondering if the PARTNUM field of the IMMR (section 10.4.1 of MPC860UM.pdf) does have meaningful information which could be used to identify the CPU. It has meaningful information, but not the way you want to use it :-) The PARTNUM/MASKNUM is only useful once you know the type of processor (like 823, 850, 885, etc) The PARTNUM is only useful within the family. For example, the 860 and 880 are two different families, and will contain the similar PARTNUM values through their life. I believe it's tied to the fabrication process. You may as well stop looking for an easy (or possibly any) way to differentiate these parts in software, but due to they way they are fabricated, I don't think that's ever going to happen. :-) -- Dan
CPM2 early console
On Oct 4, 2005, at 1:13 AM, Kalle Pokki wrote: .. This errata should probably be included in the Linux kernel, since it really depends on it. Everything depends on that, and it should be done in the boot rom as part of the processor initialization after reset. Thanks. -- Dan
CPM2 early console
On Oct 1, 2005, at 1:57 AM, Kalle Pokki wrote: Yes I'm sure the code in Linux is right. It may be missing some initialisation it depends on, but anyway. Did you mention in the past you have a custom boot loader? Is this something other than the PlanetCore boot rom? My board is an Embedded Planet EP8248 that came with a pre-installed version of Linux 2.4. That version works ok, though I don't know what modifications were made to the kernel. The source wasn't included... I doubt they made any modifications to the generic driver. The only thing they may have done is added some board control register/GPIO to enable the RS-232 transceiver. If you don't have their board initialization functions, though, this would be useful. Currently I boot with PlanetCore, load my own boot loader (I'm going to use it exclusively when my own custom board based on 8247 comes out) via tftp, and start the most recent kernel.org kenel from it. What about just trying to boot the new kernel from PlanetCore boot rom? Of course, if you are doing your own boot rom and have a board to bring up, you should have invested in something like a BDI2000 long ago because it will have paid for itself many times over by the time you are done :-) It would have also allowed you to debug this problem rather quickly. You are going to have to investigate your processor state prior to calling Linux (HIDx registers, cache and MMU state, SIU configuration, etc) to see how it differs from what PlanetCore does. There are lots and lots of options on these processors, and one bit in one configuration register that is incorrect can cause lots of grief. -- Dan
CPM2 early console
On Sep 30, 2005, at 4:10 PM, Kalle Pokki wrote: . Still, there must be a correct way of doing this, but I think I have already tried modifying every register that sounds related. The errata doesn't list anything useful. I just built an 8250. 8260, and 8270 from a very recent 2.6 tree today and they all worked fine. They all had different serial port configurations (SMC1, SCC1 and SCC2). Two were u-boot and one was a proprietary boot rom. So, the problem seems to be related to something unique with your system. I successfully tried this in another application without Linux. This is code that has existed for many years in Linux and appears to continue to work fine. We need to identify what is causing the problem in your environment, not look for some hack around it. Thanks. -- Dan
AW: mpc8xx and LCD
On Sep 30, 2005, at 7:07 AM, Fend, Matthias wrote: As I know at least the S1D13700 is brand new (the people from Epson are working on a Linux driver at the moment). OK. Do you think it's possible to write the device driver in such a way that he also translates the pixel data into the indirect register mode of the S1D13700 ? The only way I can think of is to access protect the frame buffer, trap all accesses and then do some translation in software. Very, very slow and inefficient. The most efficient way is for applications (like X) to do this internally. ? You mean the 823 has an internal LCD controller - Yes. . I know that but I want to use a 860 or 855 (we already use them in other products). Oh well :-) Do you think it would be the best way to use an 823 and a driver-only display ? I don't understand the question. As there are so many devices with LCD display in use, I thought there could be a an easy going standard solution for this, but it seems to be a little bit tricky There is a standard. Attach your graphics device to the processor bus as a memory mapped device and use a Linux frame buffer :-) The complexity of your graphics requirements will determine how much additional software you have to write. Since I like to use X-windows, most of the software I end up writing is in that server, not the Linux driver. Thanks. -- Dan
CPM2 early console
On Sep 30, 2005, at 9:22 AM, Alex Zeffertt wrote: Are there any drawbacks to this approach? The general system performance is going to suffer, and if you really have a cache coherency problem it only solves the write case and not the read case. -- Dan
BRG setting error
On Sep 29, 2005, at 5:06 AM, Borsodi Petr wrote: I found an error in Baud Rate Generator setting for MPC82XX processors. How about a patch we can apply? Declaring a bug and hoping someone else will fix it isn't likely to happen :-) Thanks. -- Dan
CPM2 early console
On Sep 29, 2005, at 8:24 AM, Kalle Pokki wrote: flags |= _PAGE_WRITETHRU | _PAGE_COHERENT; in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on this kind of a hack, should it? This is clearly wrong since other 82xx processors work fine. Something is amiss with your boot rom or other setup of this processor. Thanks. -- Dan
mpc8xx and LCD
On Sep 29, 2005, at 2:53 AM, Fend, Matthias wrote: At the moment I think we should use a lcd controller from Epson (S1D13700 or S1D13305) since they are working on Linux framebuffer device driver for it. Well, check carefully. As I recall, those parts have been discontinued. Although there is software, you may not be able to build products once it is done. I'd suggest looking first at Fujitsu, and second at Silicon Motion. Both of these companies have claimed to be dedicated to providing the embedded parts for a long time. Has anybody else implemented a LCD into a mpc8xx (not 823) board successfully ? Of course. It has an internal LCD/video controller, and there should be drivers in various kernels. Thanks. -- Dan
CPM2 early console
On Sep 27, 2005, at 10:11 AM, Kalle Pokki wrote: Is the alloc_bootmem() function in e.g. cpm_uart_allocbuf() supposed to give non-cached memory? In my 8248 board it seems not to. It provides cache coherent memory, whether it is cached or not depends upon the capabilities of the cache controller and peripherals. On the 82xx, it is supposed to be cached. Only using DPRAM as buffer storage allows booting to proceed without hanging right in the beginning. The only thing that would cause a problem is an incorrect CPM configuration. Any ideas what can set the bootmem memory as cached? All of memory is always cached on 82xx. Which is fine since the cache controller keeps the processor core and peripherals coherent in hardware. Thanks. -- Dan
CPM2 early console
On Sep 27, 2005, at 4:35 PM, Kalle Pokki wrote: OK. Then the question really is why isn't the cache controller enforcing coherency between the G2_LE core and the CPM. Is the GBL and DTB set properly in the function code registers of the SCC parameter ram? -- Dan
bseip config doesn't build
On Sep 16, 2005, at 12:41 PM, Kumar Gala wrote: Anyone have any ideas why the bseip_defconfig doesnt build. I get the following error: I'll look into it. CC arch/ppc/8xx_io/enet.o I thought we are should be using the drivers/net/* version of this? Thanks. -- Dan
PPC4xx cleanup
On Sep 15, 2005, at 12:25 PM, Matt Porter wrote: Sounds great to me. This will have to wait to go in mainline until after 2.6.14 is out though. If you are considering this, I think you should be looking at the recent U-Boot discussion and patches for the flat OF tree and follow that path. Thanks. -- Dan
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
On Sep 8, 2005, at 12:27 AM, Paul Mackerras wrote: Given how long it takes to access I/O devices, I don't believe an extra instruction or two is going to make a measurable difference. That's kind of true. However, the access to the CPM is nearly instruction speed, except in the case when you actually use a real IO register (like a GPIO on a port), then it's a little slower. -- Dan
cpu features testing 32 vs 64 bit
On Sep 8, 2005, at 5:20 PM, Kumar Gala wrote: if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) __flush_icache_range(start, stop); } If we #define CPU_FTR_xxx as a 0 or all 1's for processors that have or don't have these features, will the compiler be smart enough to recognize an always true or false condition and remove the test (or code as appropriate)? Thanks. -- Dan
cpu features testing 32 vs 64 bit
On Sep 8, 2005, at 6:02 PM, Kumar Gala wrote: The compiler is smart enough in this case since cpu_has_feature() is an inline function. I guess I didn't read Becky's comments close enough, but she did suggest this. I was trying to eliminate the #ifdef, but I guess we will need it some place. Thanks. -- Dan
[PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
On Sep 7, 2005, at 8:28 PM, Benjamin Herrenschmidt wrote: I'm not fan of the approach. You should use in_/out_ macros for IOs. If you don't need eieio on 8xx , then just #ifdef it out of the implementation of these. Yeah, #ifdef :-) That patch wouldn't go anywhere (well, to /dev/null perhaps). We can just use the in_/out_ macros that are there. The eieio doesn't hurt anything on the 8xx. Thanks. -- Dan
[PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 11:02 PM, Li Tony-r64360 wrote: I think it is OK. The external interrupt can be edged. And it works well in my board. No, it can't. PCI interrupts must be level sensitive because multiple slots can share an interrupt. Thanks. -- Dan
[PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 1:42 PM, Kumar Gala wrote:
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory; /* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error PCI is not supported
-/* NEED mpc83xx_map_irq mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * PCI IDSEL/INTPIN-INTLINE
+ * A B C D
+ */
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+ };
+
+ const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn)
+{
+ return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
Shouldn't this be in the PQ2FADS board specific file? Not everyone
is going to map IDSELs and IRQs this way.
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR ((uint)0xfe00)
#define BCSR_PHYS_ADDR ((uint)0xf800)
-#define BCSR_SIZE((uint)(32 * 1024))
+#define BCSR_SIZE((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF 0x08
#define BCSR_MISC_REG3_CNFLOCK 0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQAMPC83xx_IRQ_EXT4
+#define PIRQBMPC83xx_IRQ_EXT5
+#define PIRQCMPC83xx_IRQ_EXT6
+#define PIRQDMPC83xx_IRQ_EXT7
The same thing with these BCSRs and IRQ mappings FADS specific.
+
+#define MPC83xx_PCI1_LOWER_IO0x
+#define MPC83xx_PCI1_UPPER_IO0x00ff
+#define MPC83xx_PCI1_LOWER_MEM 0x8000
+#define MPC83xx_PCI1_UPPER_MEM 0x9fff
+#define MPC83xx_PCI1_IO_BASE 0xe200
+#define MPC83xx_PCI1_MEM_OFFSET 0x
+#define MPC83xx_PCI1_IO_SIZE 0x0100
+
+#define MPC83xx_PCI2_LOWER_IO0x
+#define MPC83xx_PCI2_UPPER_IO0x00ff
+#define MPC83xx_PCI2_LOWER_MEM 0xa000
+#define MPC83xx_PCI2_UPPER_MEM 0xbfff
+#define MPC83xx_PCI2_IO_BASE 0xe300
+#define MPC83xx_PCI2_MEM_OFFSET 0x
+#define MPC83xx_PCI2_IO_SIZE 0x0100
These should be generic to everyone, and could be
in the ppc83xx_pci.h file. Maybe surround them with
#ifndef so a board specific file could move the addresses
if they wanted? I don't think an #ifndef is needed for each
define, maybe just #fndef MPC83xx_PCI1_LOWER_MEM
and let the board define everything if they want anything different.
Thanks.
-- Dan
Enabling 8xx debug mode
On Aug 22, 2005, at 10:20 PM, Marcelo Tosatti wrote: I know now that the BDI automatically enables debug mode by asserting the DSCK signal (available through the JTAG port). Is there any way to enable debugging mode purely via software? I'm not sure I really understand the question, but I'll give some answers anyway :-) The 8xx has the development/debug support, which is a bunch of registers that allow setting instruction/data breakpoints and so on. These are accessible from software, along with other standard PowerPC debug (like single step). The DSCK is a BDM/JTAG clock signal, and along with the other signals allow the clocking of instructions and data through the BDM pins. One of the things you can do is strobe in instructions that will set these same breakpoint or other debug registers as are accessible from software running on the part. So, if you have software running on the processor, you can do the same things. Obviously, if you are stuck someplace you need to get the attention of the processor. You can do this with some interrupt like kgdb does, then use the debug interface to help. Does this make sense? Thanks. -- Dan
mmap nocache on PPC, 2.4
On Aug 22, 2005, at 10:35 AM, Stephen Williams wrote: In an embedded system, I want a big chunk of virtual memory in the user process to be uncached. Why? What processor it this? Who else touches this memory? I've created a virtual device driver that has this mmap method: Even if this did what you thought it should, I'm not sure you would be happy with the results. The challenge is ensuring anyone that touches these physical pages also does so uncached. Depending upon the processor, this isn't something that is trivial to change in the kernel, since we always map all of memory as efficiently as possible with a cached mapping. The caching of memory has many desirable performance side effects, making the trade off the manage coherency in software if needed an overall system gain. Thanks. -- Dan
[PATCH] ppc32: 8xx pq platform system descriptions
On Aug 21, 2005, at 7:55 PM, Marcelo Tosatti wrote: - Do you have any plans on actually using device model information by drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very clear to me what are the the practical advantages of that? It may be nice if we can do that. We have to be careful about sharing CPM drivers between the 8xx and CPM2 (82xx/83xx/85xx). It's tempting, but I still believe the differences outweigh the similarities. The overhead of trying to use common drivers would be quite costly on the 8xx. - I don't know whether its possible to retrieve 8xx CPUID information (if there is any). Can't find anything in the manual. We really can't. The PVR only represents the processor core information, and for the most part they are all the same. It used to be we could use the CPM microcode version, but these are now nearly the same. Some attempts have been made to probe for CPM peripherals that don't exist, but it seems on some parts the CPM is the same and the signals just aren't bonded out of the chip. For the most part, the person doing the kernel configuration just simply has to know what part they are using. You have to select the proper peripherals, and you need the board support for the IO pin routing. In an embedded environment where resources still need to be carefully managed, I don't think this is unrealistic. Thanks. -- Dan
[RFC][PATCH] [1/2] 8xx platform definitions
On Aug 19, 2005, at 8:44 AM, Vitaly Bordug wrote: +#define MPC8xx_INT_FEC1 SIU_LEVEL1 +#define MPC8xx_INT_FEC2 SIU_LEVEL3 + +#define MPC8xx_INT_SCC1 (CPM_IRQ_OFFSET + CPMVEC_SCC1) +#define MPC8xx_INT_SCC2 (CPM_IRQ_OFFSET + CPMVEC_SCC2) +#define MPC8xx_INT_SCC3 (CPM_IRQ_OFFSET + CPMVEC_SCC3) +#define MPC8xx_INT_SCC4 (CPM_IRQ_OFFSET + CPMVEC_SCC4) +#define MPC8xx_INT_SMC1 (CPM_IRQ_OFFSET + CPMVEC_SMC1) +#define MPC8xx_INT_SMC2 (CPM_IRQ_OFFSET + CPMVEC_SMC2) + +/* Offset from IMMAP base address */ +#define MPC8xx_SCC1_OFFSET (0xa00) +#define MPC8xx_SCC1_SIZE (0x18) +#define MPC8xx_SCC2_OFFSET (0xa20) +#define MPC8xx_SCC2_SIZE (0x18) +#define MPC8xx_SCC3_OFFSET (0xa40) +#define MPC8xx_SCC3_SIZE (0x18) +#define MPC8xx_SCC4_OFFSET (0xa60) +#define MPC8xx_SCC4_SIZE (0x18) +#define MPC8xx_SMC1_OFFSET (0xa82) +#define MPC8xx_SMC1_SIZE (0x0f) +#define MPC8xx_SMC2_OFFSET (0xa92) +#define MPC8xx_SMC2_SIZE (0x0d) +#define MPC8xx_FEC1_OFFSET (0xe00) +#define MPC8xx_FEC1_SIZE (0x88) +#define MPC8xx_FEC2_OFFSET (0x1e00) +#define MPC8xx_FEC2_SIZE (0x88) + +#define MPC8xx_DPARAM_SCC1_OFFSET(0x3C00) +#define MPC8xx_DPARAM_SCC1_SIZE (0x80) +#define MPC8xx_DPARAM_SCC2_OFFSET(0x3D00) +#define MPC8xx_DPARAM_SCC2_SIZE (0x80) +#define MPC8xx_DPARAM_SCC3_OFFSET(0x3E00) +#define MPC8xx_DPARAM_SCC3_SIZE (0x80) +#define MPC8xx_DPARAM_SCC4_OFFSET(0x3F00) +#define MPC8xx_DPARAM_SCC4_SIZE (0x80) +#define MPC8xx_DPARAM_SMC1_OFFSET(0x3E80) +#define MPC8xx_DPARAM_SMC1_SIZE (0x40) +#define MPC8xx_DPARAM_SMC2_OFFSET(0x3F80) +#define MPC8xx_DPARAM_SMC2_SIZE (0x40) All of these #defines should already be in a header file somewhere, and if they aren't, should be in the generic CPM header file. Please clean this up. Thanks. -- Dan
8260 fcc_enet driver newbie question
On Aug 11, 2005, at 1:47 AM, Vijay Kumar wrote: I was going through the fcc_enet driver (linux-2.6.12.2/arch/ppc/8260_io/fcc_enet.c). This has been replaced by the new net/fs_enet, right? The driver accesses the CPM memory map using immap = (cpm2_map_t *)CPM_MAP_ADDR; Yes, and that's wrong. You should at least use ioremap(), and we recently had discussions about whether to create some properly named functions or macros to return common addresses like the CPM space. There is also a global variable cpm2_immr defined in arch/ppc/syslib/cpm2_common.c I know, but we shouldn't be doing that any longer. If I were to write a new driver which one should I use to access the CPM memory map? For now, at least ioremap() the space in your driver and cache the pointer. I'd like to quickly get a couple of these other supporting functions done to use, though. Thanks. -- Dan
How to disable dcache on MPC82xx platform
On Aug 8, 2005, at 10:30 PM, Prashant Alange wrote: I am using alloc_bootmem_page() function to allocate memory required in my custom ethernet driver. Why? Just use the normal Linux memory allocators. So I am thinking this could be because of cache since this driver is working fine on non-os platform. I want to disable the dcache for this memory region. This is a fully cache coherent processor, there is no need to disable caching, nor is there any easy way to do this in the current Linux implementation. This would require a custom kernel, and you couldn't take advantage of the general performance gain using BATs. Thanks. -- Dan
How to disable dcache on MPC82xx platform
On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote: Since the existing UART/ethernet drivers are using cpm_hostalloc() so I am also using the same function. As I have said too many times before, cpm_hostalloc() is only used to allocate small memory regions that would otherwise be wasteful with the normal Linux memory allocators. This function does not do anything special with the memory, aside from allowing us have multiple drivers share a page for efficiency. Then can I use kmalloc() to alloc such huge memory. Yes, and you should. If at all I have to configure BATx to just test how it behaves. No, that's not all you have to do. It's not a trivial process easily described here. . One more thing is that totally I am allocating about 1MB memory in a chunk of 200K. I can't comprehend a reason why you need to allocate so much space in a driver, especially for CPM devices. The driver is just a temporary FIFO for data flowing to/from other consumer/producers of the data in the system. If the software above a driver needs that kind of buffering, it should manage that itself. If you do need so much space, use the beauty of the CPM and link multiple BDs with reasonable sized buffers more easily managed by the existing Linux allocators. The other alternative is just reserve memory using the 'mem=' start parameter so it isn't know to Linux, and manage entirely yourself. -- Dan
How to disable dcache on MPC82xx platform
On Aug 9, 2005, at 5:50 PM, Prashant Alange wrote: ... I am linking multiple BDs only but no of BDs are very large in my case so I am allocating the memory and updating the BD pointer for all BDs. I don't understand what you mean here. If i use mem= option as kernel command line argument then I will have to just ioremap() this reserved address in my driver and start accessing the memory. I do not have to worry about cache related things. right? Yes. -- Dan
[PATCH] 8xx: add cpm_get_cpmp()
On Aug 6, 2005, at 7:42 PM, Aristeu Sergio Rozanski Filho wrote: but not with EXPORT_SYMBOL(). I noticed this while compiling i2c stuff as module. also, I think it's better add a function to do this instead doing EXPORT_SYMBOL() in a variable. Right. We should just ioremap() :-) Thanks. -- Dan
[PATCH] 8xx: add cpm_get_cpmp()
On Aug 7, 2005, at 12:31 AM, Marcelo Tosatti wrote: Aris, sounds like you should proceed with cpm_get_cpmp() and change all other drivers using it also. It depends how you define the semantics of this function call. Can you call it any (and all of the) time you need it, or does it actually perform an ioremap() and you only want to call it once? I guess implemented properly it doesn't matter. On the first call it should do the ioremap() and on subsequent calls it just returns the mapping. This is one of those common functions that should be in commproc.c. Thanks. -- Dan
