Re: mpc744x, Marvell mv6446x kernel guidance please
On Thu, Jul 10, 2008 at 10:46:49PM -0500, Stephen Horton wrote: Hello folks, In a current work project, I have inherited a compactPCI board that has an mpc7447/7448 powerpc processor as well as a Marvell system controller, model mv64462 (stripped down mv64460). The board has a somewhat working Gentoo Linux port running on it from long ago and a company far far away (kernel version 2.6.9 built using arch/ppc). To prepare for an upcoming deployment, I would like to bring the OS up-to-date on this board with a newer kernel (targeting Gentoo 2008), but I am unsure of the approach to take. I am a software developer, but normally do not work on kernel porting / board integration. I have researched the arch/ppc to arch/powerpc migration, but I'm a bit intimidated by the 'new' device tree symantics and other changes to the stream. Here are some questions: 1.Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use arch/ppc for this platform architecture? I've tried to get this to compile, but am having trouble with files from arch/powerpc getting pulled in; then I read some comments (from I believe this forum) that indicated that arch/ppc is not longer supposed to compile arch/ppc is gone now. You should spend you effort working in arch/powerpc. 2.Does anyone have example code for this platform architecture? Any freebees I could use for creating my device tree? You can use prpmc2800 as an example. 3.Any advice of any kind? Its not as bad as it looks. Just dig into it and don't give up. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Thu, Jan 31, 2008 at 09:33:09PM -0600, Kumar Gala wrote: On Jan 31, 2008, at 4:54 PM, Mark A. Greer wrote: On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. /me's $0.02. this is where I poke you about the sandpoint port ;) Heh, I know, I know. jdl was asking me about it a few days ago too. I haven't forgotten, it just never makes it to the top of my stack. RSN tho... :) ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. /me's $0.02. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 03:43:39PM -0500, Rune Torgersen wrote: Is there an easy way to use something other than the decrementer for the timer interrupt? Reason i'm asking is tha t on our board, the decrementer cannot be divided to 1khz evenly, so we have rounding errors for time, but we do have a 1KHz timer interrupt from an FPGA that is source of a T1 clock. Right now I let the decrementer interrupt do nothing, and made my own timer interrupt handler that calls the stuff the timer_interrupt usually does. This works, but there are some instability (ie unexplained hangs) that showed up when I did this. Check out the clocksource stuff. It let's you set up numerous clock sources and set the rating of each one. You can start looking in arch/powerpc/kernel/time.c for example code. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 04:39:53PM -0500, Rune Torgersen wrote: From: Mark A. Greer Is there an easy way to use something other than the decrementer for the timer interrupt? Check out the clocksource stuff. It let's you set up numerous clock sources and set the rating of each one. You can start looking in arch/powerpc/kernel/time.c for example code. Thanks I will. Currently our board port lives in /arch/ppc (2.6.18) but I will take a look in powerpc. Okay. Just an FYI, arch/ppc will evaporate next summer. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote: On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote: On Thu, 27 Sep 2007 12:53:51 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I personally don't care either way. I'm already subscribed to both lists. Makes sense to go to linuxppc-dev given the arch/powerpc migration. I thought the -embedded list was created in the first place to keep some of the noise off of -dev (i.e. I can't get interface foo to work on my custom embedded eval board-lookalike board, HELP!). If people still care about keeping that on a separate list, then we shouldn't change it. Yes, IIRC, that was the reason but now with the merge and low volume on this list, it makes sense to me to just get rid of -embedded. I think the relevant people probably monitor this list (maybe not quite as frequently) to catch things. I even caught the first PWRficient-related question in a timely manner the other day. :-) :) Still, that being said, patches will clearly get better exposure on -dev, especially device tree crap. Definitely. I'll propose this on -dev and see what people say. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Mon, Oct 01, 2007 at 02:59:11PM -0500, Josh Boyer wrote: On Mon, 01 Oct 2007 15:49:22 -0400 Ben Warren [EMAIL PROTECTED] wrote: Perhaps my perspective is unique, but I doubt it. I find it nice that this list is low volume and not filled with endless patches about CHRP and P series and open firmware syntax blah blah blah... No offense intended to all the people who are doing wonderful work expanding the Linux universe, but for your average dude or dudette working on embedded boards that happen to have a PowerPC processor, this list is a pretty good forum. I think the original thought was to have patches go to linuxppc-dev. Not necessarily all discussion. That's where I started but I moved to completely getting of linuxppc-embedded. As Ben points out, I may have gone too far. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Thu, Sep 27, 2007 at 02:22:31PM -0400, [EMAIL PROTECTED] wrote: From: Joe D'Abbraccio [EMAIL PROTECTED] The MPC837x RDB is a new member of the Freescale MPC83xx reference design boards. FYI, if you have patches for arch/powerpc, I recommend that you submit them to linuxppc-dev. linuxppc-embedded is not monitored by many important people including paulus. Since these are 8xxx patches, chances are Kumar will see them and take them but you're still better off submitting to linuxppc-dev. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote: Isn't the ethernet the same on the 64260, 64360, 64460? There's definitely a driver for 6436x and above.. I just try it, it doesn't work, I receive without end the message: mv643xx PHY read timeout, port 0 I believe that Steve Hill [EMAIL PROTECTED] has patched the mv643xx_eth driver to work with the 64260 and plans to submit the patches. That's means the patch isn't yet ready? It probably means you don't something set up for whatever PHY you're using. I will try to contact him. A good idea. It's nevertheless odd, I read about a file named gt64260_eth.c during my search on the internet.But I wasn't able to find it :(. There was one for 2.4 that was in the ppc devel tree but it never went mainline. Hopefully, Steve can help you from here. Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
On Wed, Jan 24, 2007 at 09:19:17AM -0800, Eugene Surovegin wrote: On Wed, Jan 24, 2007 at 12:06:17PM +0100, Laurent Pinchart wrote: snip I had a look at U-Boot code and tried to initialize the processor registers with the same values, without luck. I asked Abatron's French distributor for technical support, and they haven't been able to help me. They made me try lots of different initialization sequences. Several people online sent me their configuration file, and none of them worked for me. So, there must be a configuration problem somewhere, but even Abatron's technical support haven't been able to find it. That's why I complained about their support in my e-mail. In your original e-mail you made it look like BDI has a bug in it, which in fact isn't true. Bad support might be a concern, I agree, but this doesn't make a tool bad, IMHO. FWIW, I've had top-notch support from Abatron. Also, back when my company bought a bunch of BDI's they were around half the price of the nearest competitor and less cumbersome to use. Maybe there are cheaper alternatives now, I don't know. Obviously, YMMV. And no, I don't get a kickback from them... :) Mark ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Serial problem with MPC8241-based board
On Sun, Sep 03, 2006 at 09:58:25PM +0200, Guennadi Liakhovetski wrote: Hi Guennadi, Mark, may I use this opportunity to ask you for your current consistent snapshot of both powerpc/boot and powerpc/platforms and whatever others? I can compile a kernel with ARCH=powerpc for linkstation, now I have to find a way to boot it. My choices are kexec or u-boot. Neither will run out-of-the-box, so... I'm in the middle of making a bunch of changes to the bootwrapper patches so I don't have a good set of patches for you. Hopefully in a day or two at which time I'll be happy to share them with you. BTW, I would be greatful for any help with setting up kexec. I can't help you there. You could try asking Milton Miller. Mark
[PATCH] Add adder87x board support to 2.6.x
On Sun, Aug 20, 2006 at 08:36:49PM +0100, Bryan O'Donoghue wrote: Greetings all. This set of patches adds support for the Analogue Micro Adder87x to Linux. The port is based on mpc885ads in the 2.6.18-rc4 tree. The patches are very simple really consisting of a stripped down version of mpc885ads renamed to adder87x*blah, a defconfig and appropriate entries in arch/ppc/Kconfig, arch/ppc/platforms/Makefile and include/asm-ppc/mpc8xx.h. I've spent a bit of time testing this out, and I'm reasonably happy that this should be useful to others using this development board. Signed-off-by: Bryan O'Donoghue bodonoghue at codehermit.ie Bryan, If you're not already on the linuxppc-dev mailing list, you should be. The 'ppc' tree is deprecated and all new work should be happening in the 'powerpc' tree (as in arch/powerpc). The odds of this being accepted are slim but either way, you should read the mail archive and get involved in the powerpc migration. Mark
[RFC] consolidated libdt proposal
On Tue, Aug 08, 2006 at 01:25:10PM -0500, Hollis Blanchard wrote: On Tue, 2006-08-08 at 11:04 -0700, Mark A. Greer wrote: Except for not being able to extend a property (see below), I think it does meet my needs (at least as I know them today). Great. However, I was hoping to keep the interfaces in the bootwrapper similar to the ones used in the kernel. To that end, I had a routine to find a device node and other routines to find and modify a property within that node. I didn't notice a finddevice type of function to find a device node. Would you have a problem adding one? The way property modification works now is this: p = ft_get_prop(tree, /xen/console/interrupts, len); if ((NULL == p) || (len != foolen)) return; *p = cpu_to_be32(foo); (That does need to be hidden in a yet-to-be-written ft_set_prop().) If necessary, it looks like it would be possible to modify ft_get_prop() to return a pointer to the beginning of the node structure, but is it really necessary? No, its just a preference to have it look similar to kernel code. Do you have code that would be difficult to convert to using ft_set_prop(tree, /node/prop, buf, buflen); ? No. One limitation of the attached code is that it doesn't support changing the *size* of properties, though I don't think that would be too difficult to add if needed. If we're going to allow cmdline editing in the bootwrapper, we would need to extend the size of a property. We've never really talked about cmdline editing in the powerpc branch but I assume that its a good thing(tm). I know I would like to have it so, IMHO, I think we should add it (and therefore require extending a property). I agree, and it shouldn't be too much work. I'll take a look later this week, if nobody else has. OK. Mark
Boot problem on Sandpoint
On Fri, Jul 21, 2006 at 11:49:14AM -0700, Benoit Lajoie-Dorval wrote: Hi all, I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on. Tell your boss that it'll take 3 months including lots of overtime, then crack open a beer! The sandpoint/8241 has been working for years. built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also minimized everything in the .config file to only have what is really necessary (serial port, 6xx processor, etc). The communication is made with the board by its internal serial port and Dink32 is used to do everything else. The problem is that when I execute the loaded zImage.initrd.elf, the boot sequence just hangs there and I just don't see anything happening. There is nothing that is displayed. I know that the elf file as an offset header of 0X1, so the problem is not there. I also put some breakpoints and trace using Dink32 to see where it stops and it may have something to do with the disable_6xx_mmu in the utils.S file. I just really don't know what's wrong in my config and I hope someone could help me on this. Well, you did lots of things that could have broken it. Go back to square one: default .config with nfs mounted rootfs. Get that to work then tune the .config and add a ramdisk. Also, if you have a bdi2000 or some other jtag/cops debugger, you can dump __log_buf and see if there is anything there. Mark
Setting ID cache enable in the same mtspr instruction
On Mon, May 29, 2006 at 02:15:14PM +0200, Roger Larsson wrote: Is the patch reversed? Sure looks like it. diff -Naur old new patch And what about comments, are they all still valid? enable and invalidate caches is now only Data cache... In cases when I am writing code like this I try to include the reason why it is not optimized together in one write... (or soon someone will do that optimization). Good point. /RogerL Also, please send the patches *inline*. Mark
pmppc7448/mv64x60 DMA from PCI to memory
On Wed, May 24, 2006 at 11:53:54AM +0930, Phil Nitschke wrote: On Tue, 2006-05-23 at 16:54 -0700, Mark A. Greer wrote: You say that you don't see any PCI traffic. Does that mean you have a PCI analyzer and that you are sure that its set up correctly? I don't have a PCI analyzer, however the JTAG used to program the PCI device has been configured to display 4 K samples of PCI bus signals (about 20 microsecs?) around the time of an interrupt which results in the DMA being requested. Since my last post, I have managed to see some traffic, but the PCI STOP# line is asserted, so I'm not seeing any data being read. I'll investigate further... OK If so, then you have something botched in your IDMA-PCI window setup Quite possibly. The patch below shows how I've set this window up. It is not intended as a 'final' piece of code, so please forgive the magic numbers. Could you review this for me? Sure. or in the pgming of the DMA itself (e.g., in your descriptor(s)). Well the memory to memory DMA is working OK. I just didn't know what the correct procedure was for determining the bus address of the FIFO. For example, this mapping returns a dma handle which does not work: fifo_dma_handle = pci_map_single(dev, my_card.bar1+fifo_address[0], FIFO_SIZE, PCI_DMA_FROMDEVICE); Whereas without DMA I would just use this: ioread32_rep(my_card.bar1 + fifo_address[0], buf, 6); Was I misguided in trying to use pci_map_single in this way? Yes. Use pci_map_single() to map an already allocated, physically contiguous memory buffer not pci memory. Try pci_iomap() instead. You should read Documentation/DMA-API.txt DMA-mapping.txt thoroughly then look at the many pci drivers that already exist as examples. Also, set the SrcHold bit [3] of the channel control reg (low). If its really a FIFO, you are--or will be once you get your windows and descriptors set up correctly--reading the FIFO once then incrementing past it. I can either address it as a FIFO, or as a memory range. I can read from any address in the range and it returns the next FIFO value. Anyway, I've tried both src address hold settings... OK For this scenario, can anyone tell me: * Should I be using the same src address as that reported via the 'lspci' command - this _is_ the PCI bus address, isn't it? man lspci (read up on the '-b' option) I cannot see any difference with the '-b' flag. Maybe that is the way of things on my architecture? That probably means that your pci io mem space are mapped at the same addrs in pci io mem space and phys cpu space. If that's not the case, something may be wrong. * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4 of the 8 possible IDMA address windows are configured (for each of the 512 MB DRAM on our processor card). No they aren't. They're configured (or not) according to the setup info that you pass in. OK. I also note there are several cases where this is used in mv64x60.c: for (i=0; i3; i++) Why is 3 used in these loops, and not some other constant like MV64360_x_WINDOWS (which are usually 4, not 3)? Different things. The i3; are when looping through windows that are related to a struct pci_controller's mem_resource. From the definition of pci_controller: struct resource mem_resources[3]; Do I need to add tests to my source and destination regions, to determine if they cross one of the 512 MB regions, and hence will require a different CSx line (and thus the DMA will need to be broken into two transactions), or does kernel already take care to ensure allocated regions will not cross these boundaries? No. You need to do what's appropriate for the hardware that you are essentially writing a driver for. YOU are supposed to know what the limitations of your hardware are. OK, I know how my hardware is configured, but when trying to write a generic driver, perhaps I need to have the mv64x60.c code remember the CSx barriers, e.g. in the mv64x60_chip_info, so the IDMA engine can access it. Do you think this would be possible/beneficial? No. Just set up and enable an IDMA window to access all of pci mem space and be done with it. Thanks again, -- Phil Here is the patch to configure IDMA to PCI window(s): --- linux-2.6.16/arch/ppc/syslib/mv64x60.c 2006-03-20 16:23:29.0 +1030 +++ linux-2.6.16-patched/arch/ppc/syslib/mv64x60.c 2006-05-23 16:33:52.0 +0930 @@ -535,6 +581,7 @@ mv64x60_config_pci_params(bh-hose_a, si-pci_0); mv64x60_config_cpu2pci_windows(bh, si-pci_0, 0); +mv64x60_config_idma2pci_windows(bh, si-pci_0, 0); mv64x60_config_pci2mem_windows(bh, bh-hose_a, si-pci_0, 0
Setting ID cache enable in the same mtspr instruction
On Tue, May 23, 2006 at 12:55:46PM +0300, Assaf Hoffman wrote: Attached. Thanks. Er, how about a *patch* place inline (as in, not as an attachment). Thanks, Mark
pmppc7448/mv64x60 DMA from PCI to memory
Hi Phil, On Wed, May 24, 2006 at 12:20:04AM +0930, Phil Nitschke wrote: I've written a collection of simple routines to program the Marvell IDMA controller, for example: mv64x6x_init_dma_channel(); mv64x6x_set_dma_mode(); mv64x6x_set_src_addr(); mv64x6x_set_dst_addr(); mv64x6x_set_dma_count(); mv64x6x_enable_dma(); or rather more simply: mv64x6x_memcpy_dma(dst_handle, src_handle, size); Listing routine names but no code doesn't really help. This works OK for copying from a memory to memory, where the buffers are allocated using: src = dma_alloc_noncoherent(NULL, BUF_SZ, src_handle, GFP_KERNEL); The src_handle is passed directly to mv64x6x_set_src_addr(); But when the src address is the FIFO on the PCI bus, I don't know how to Do you really mean a FIFO? If so, that would explain a lot... get the IDMA controller to play nicely. The FIFO sits in the middle of the PCI device's I/O mem range 0x9fe0 - 0x9fff. I've programmed and enabled a 5th address window in the IDMA controller which encompasses the 0x20 bytes of the PCI memory range, and I'm not seeing any address violation or address miss errors. The PCI-memory DMA completes without any traffic every touching the PCI bus, so obviously I need to do something else/differently. You say that you don't see any PCI traffic. Does that mean you have a PCI analyzer and that you are sure that its set up correctly? If so, then you have something botched in your IDMA-PCI window setup or in the pgming of the DMA itself (e.g., in your descriptor(s)). Also, set the SrcHold bit [3] of the channel control reg (low). If its really a FIFO, you are--or will be once you get your windows and descriptors set up correctly--reading the FIFO once then incrementing past it. For this scenario, can anyone tell me: * Should I be using the same src address as that reported via the 'lspci' command - this _is_ the PCI bus address, isn't it? man lspci (read up on the '-b' option) * Do I have to do anything special to tell the IDMA controller to source data from the PCI bus and shift it into memory? You're talking to a *FIFO* which means you read all the data from one address and write all the data to one, probably different, address. Its not normal PCI memory, you don't increment through it. Its a register of a FIFO that's in PCI memory space. That's why you need to tell the IDMA ctlr to hold and read/write to the same address each time. * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4 of the 8 possible IDMA address windows are configured (for each of the 512 MB DRAM on our processor card). No they aren't. They're configured (or not) according to the setup info that you pass in. Do I need to add tests to my source and destination regions, to determine if they cross one of the 512 MB regions, and hence will require a different CSx line (and thus the DMA will need to be broken into two transactions), or does kernel already take care to ensure allocated regions will not cross these boundaries? No. You need to do what's appropriate for the hardware that you are essentially writing a driver for. YOU are supposed to know what the limitations of your hardware are. Even if you don't have a manual... ;) Mark
Setting ID cache enable in the same mtspr instruction
On Mon, May 08, 2006 at 01:39:13PM +0300, Assaf Hoffman wrote: Hi, I think the implementation of setup_common_caches() in file cpu_setup_6xx.S; not according to the spec as far as MPC74xx concerns. Looking in the spec (MPC7450 RISC Microprocessor Family Reference Manual, MPC7450UM Rev. 5 1/2005) section 3.4.1.5 L1 Instruction and Data Cache Flash Invalidation it says: Note that HID0[ICFI] and HID0[DCFI] must not both be set with the same mtspr instruction, due to the synchronization requirements described in Section 2.4.2.4.1, Context Synchronization. But in the code those two do set together. Also, the same section says: An isync must precede the setting of the HID0[ICFI] in order for the setting to take effect. But in the code, only 'sync' can be found. /* Enable caches for 603's, 604, 750 7400 */ setup_common_caches: mfspr r11,SPRN_HID0 andi. r0,r11,HID0_DCE ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1:sync mtspr SPRN_HID0,r8/* enable and invalidate caches */ ^^^ Here we set both ICFI and DCFI in the same mtspr instruction. Also, no isync before setting ICFI. sync mtspr SPRN_HID0,r11 /* enable caches */ sync isync blr Please advice. Thanks. Yep, looks like a bug. How about a patch? :) Mark
Sandpoint X3B and 7447 - boot problems
On Wed, May 03, 2006 at 01:45:19PM -0500, Simon Smith wrote:
Hi,
I'm a new member on this list. I've been trying to get my Sandpoint
X3B/mpmc7447 to boot a stock Linux kernel from kernel.org (tried 2.6.14 and
2.6.16). I'm running into a boot issue, I load zImage.elf (using DINK32
v13.1.1) - I get the Linux/PPC load: prompt and then nothing (no more
text, and no more serial port response).
I been searching through the archives - I did come across one email that
mentioned that Motorola(Freescale) started to ship Sandpoint X3B's with
serial #'s 6000 with different switch settings (my board has a serial #
greater than 6000). I haven't changed any switch settings from the
defaults, the comments in arch/ppc/platforms/sandpoint.c seem to make
reference to switch settings for the X1/2 board - but nothing about the X3B.
In all my searching I have yet to find any reference to what the switch
settings for the X3B rev should be for Linux.
If anyone has any pointers regarding the switch settings for the X3B - or
anything else that might help - I would appreciate any help I can get.
I just booted last night's kernel.org tree on a sandpoint 7447A X3B
with serial # 6000. I used the default config file, just like you.
The switches on the processor card are set as shown below. The on and
off match the physical markings on the switches as you look at them.
SW1: on,off,off,off,off,off,off,on
SW2: on,off,on,off,off,on,on,on
SW3: on,off,off,off,on,on,on,off
FYI, this is the info printed by dink for you to compare with:
I/O system initialized...
Memory Enabled: [ 128MB at CL=2 ]
Caches Enabled: [ L1I(32K), L1D(32K) ]
Register Inits: [ 32 GPRs, 32 FPRs, 224 SPRs, 32 VPRs ]
## ####
## ####
####
### ## ### ####
#### ## #### ## ##
#### ## #### ##
#### ## #### ## ##
## ## #### ####
((( ( (AltiVec) ) )))
Version : 13.1.1, Metaware Build
Released : INTERIM( build 784 on Dec 16 2003 15:50:00 )
Written by : Motorola CPD/NCSG PowerPC Applications, Austin, TX
System : Sandpoint X3 with Valis (MPMC7447A)
Processor : MPC7447A V1.1 @ 1000 MHz, 100 MHz memory
Memory : Map B (CHRP) 128MB at CL=2
Copyright 1993-2003, by Motorola Inc.
DINK32[MPC7447A] {1}
RTC/I2C on 82xx with Linux 2.6.x
On Fri, Apr 07, 2006 at 10:57:25AM +0200, Claus Gindhart wrote: Laurent, attached you find a rtc-driver for 2.6.13. I ported it from 2.4 myself, because i didnt find any 2.6-port out in the world. the ppc_md-structure entries are initialized within the driver itself. This is propably not 100% consistent with the coding conventions, but it works fro me. This i2c-layer can still be used with this driver; i have a LM75 and an EEPROM on the same bus, which i operate via LM-Sensors and the i2c-dev driver. Note that there is a drivers/rtc directory that new (and old) rtc drivers should be ported to. Mark
scatter/gather DMA and cache coherency
Hi Phil, On Fri, Feb 17, 2006 at 11:52:31AM +1030, Phil Nitschke wrote: MAG == Mark A Greer mgreer at mvista.com writes: snip MAG It would have been useful if you had given the actual hardware MAG you're using. Processor: http://www.artesyncp.com/products/PmPPC7448.html Okay but since its a ppmc module, the motherboard its installed on would be useful info too. Don't worry about it now, more for future reference. MAG For the record, don't assume that this is Artesyn's fault. MAG Artesyn says that the erratum workaround is impractical and they MAG may be right. I don't know, I just write software... I don't know either. I don't have a problem with Artesyn; they've always been nice to me ;-) Here's what one of their engineers had to say on the topic: Artesyn I stated in a previous email that our boards must have the Artesyn CONFIG_NOT_COHERENT_CACHE option turned on. This is because Artesyn or our history with the Discovery family of bridges. Artesyn Initially it was reported that the hardware cache coherency Artesyn (snooping) was known to be not functional. Then at a later Artesyn date when it was supposed to be fixed, we found that it was Artesyn not completely dependable so Artesyn has taken a stance to Artesyn not trust snooping on the Discovery chips and to always use Artesyn software cache coherency methods. Yep. I didn't mean to implicate Artesyn. Marvell bridges [so far] have all had problems with coherency so I definitely believe what's written above. So if I understand my situation correctly, the device driver must use software-enforced coherency to avoid data corruption. Is this correct? MAG It looks like Eugene is guiding you on this. Listen to him. I MAG will add that you should align your buffers on cacheline MAG boundaries and make the allocation sizes multiples of the MAG cacheline size otherwise you could have other data sharing the MAG first and/or last cacheline of your buffers and mess up your MAG software cache mgmt. It might well be that the third party driver isn't enforcing the cacheline boundary alignment. If it isn't, then you have a bug and it will bite you. Artesyn tell me that it is stated in the MV64460 Users Manual that when interfacing cache coherent DRAM or integrated SRAM, the maximum write burst size must be set to 32 bytes. Yes, but you [should] have coherency off so this isn't an issue for you. So I guess this is that cacheline size? Correct, the cacheline size of the 7448 is 32 bytes. Anyway, we don't see any corruption when the DMA buffer size is 32 bytes, but we do see it for 24 bytes, 36 bytes, etc. This sounds like what I was referring to. Do you see the problem? If you have some other data in the same cacheline as your buffers (or buffer descriptors) then whenever that other data is read/written you have the potential for it to screw up the manual cache mgmt you *thought* you did for your buffers/buf desc's. Mark
scatter/gather DMA and cache coherency
On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote: The problem is, that sometimes the data is corrupt (usually on the first transfer). We've concluded that the problem is related to cache coherency. The Artesyn 2.6.10 reference kernel (branched from the kernel at penguinppc.org) must be built with CONFIG_NOT_COHERENT_CACHE=y, as Artesyn have never successfully verified operation with hardware coherency enabled. My understanding is that their Marvel system controller (MV64460) supports cache snooping, but their Linux kernel support hasn't caught up yet. It would have been useful if you had given the actual hardware you're using. It sure sounds like you're using a katana or a very similar board. Coherency can't work on the katana b/c there is a hw erratum of the bridge that is not implemented on that board so CONFIG_NOT_COHERENT_CACHE=y is the only option. Fix the hardware and the kernel will work with coherency enabled with a flip of a switch (on the latest kernel). For the record, don't assume that this is Artesyn's fault. Artesyn says that the erratum workaround is impractical and they may be right. I don't know, I just write software... So if I understand my situation correctly, the device driver must use software-enforced coherency to avoid data corruption. Is this correct? It looks like Eugene is guiding you on this. Listen to him. I will add that you should align your buffers on cacheline boundaries and make the allocation sizes multiples of the cacheline size otherwise you could have other data sharing the first and/or last cacheline of your buffers and mess up your software cache mgmt. Mark
About MMU setting in MPC8245
On Wed, Jan 11, 2006 at 06:26:18PM +0800, happa at wmlab.csie.ncu.edu.tw wrote: Hi, Sorry, I have very basic question about PPC MMU setting. In http://www.denx.de/wiki/PPCEmbedded/Kernel#BOOTLOADER;, chapter 10.2. Memory Map, I get the following information. The bootloader is responsible for configuring the memory map before jumping to the Linux kernel. Is anyone know what memory map should be done in bootloader? Are you in PCI host mode? If so, the first sentence of chapter 3-- Address Maps of the 8245 manual states: The MPC8245 in PCI host mode supports an address mapping configuration that is designated as address map B. Map B == CHRP mapping. If I'm using ICE to load linux kernel, what kind of CPU registers need be configured first? Is IBAT/DBAT and Segment register need be set? Why don't you just use U-boot or look at the U-Boot code to see how its done? Mark
linux DMA capabilities in MV64460
On Tue, Dec 20, 2005 at 09:27:35AM -0500, Brian Waite wrote: On Monday 19 December 2005 8:01 pm, Mark A. Greer wrote: up the mv64460. One source told me: In order to do PCI bursts, you'll need to use a DMA engine. The MV64460 does contain a DMA engine, but you'd need to write a driver to access it. That is not correct (assuming the quote is not out of context). The bridge supports bursting on the PCI bus as long as the bridge is configured correctly and the PCI device is making an appropriate request. Note, however, that there are many errata for the Marvell parts including some with cache coherency. There are many many errata regarding cache coherency. Also, the PCI bandwidth the bridge is capable of with coherency enabled is very small. You will most likely need to use sw coherency for any real speed. I've managed to get reasonable speed with coherency on but you have to jack the burst sizes to the max (see my comment below). The speed was hugely affected by the burst size; coherency enabled had only a minor impact. The problem for me, however, was the board(s) I have do not have the necessary hw coherency errata workarounds implemented so the bridge eventually hangs with coherency enabled. Unfortunately, I think I deleted the file with my performance results in one of my cleanup binges. IIRC, though, I got ~750 Mbps with coherency off and ~725 Mbps with it on using an e1000 a 750fx or gx clocked around 800 MHz. If your system is running with coherency on, you may have to limit your bursts to 32 bytes (i.e., the size of one cache line). You will have to limit your self to 32 byte bursts with coherency. This is a requirement not an errata. That is only true for the 64360. The 64460 does not have that restriction AFAICT. snip Mark
linux DMA capabilities in MV64460
Hi Phil, [Note: I'm cc'ing linuxppc-embedded for others to reference and to add their thoughts.] --- On Tue, Dec 20, 2005 at 10:49:58AM +1030, Phil Nitschke wrote: Hi Mark, I'm developing a device driver to run in the 2.6.10 kernel. I want to That's a pretty old kernel. Do you have the option of using a more recent one like 2.6.14? get large amounts of data from a custom peripheral on the PCI bus. The software is running on an Artesyn PmPPC7448, which includes a Discovery III bridge. Can you share exact platform you're using? The custom device is a digitizer, which runs at over 200 million samples per second, so we're looking to use a fair amount of PCI bandwidth to get the data into main memory. Burst reads/writes seem like the only way. I have seen that you wrote some code for the mainstream kernel that sets up the mv64460. One source told me: In order to do PCI bursts, you'll need to use a DMA engine. The MV64460 does contain a DMA engine, but you'd need to write a driver to access it. That is not correct (assuming the quote is not out of context). The bridge supports bursting on the PCI bus as long as the bridge is configured correctly and the PCI device is making an appropriate request. Note, however, that there are many errata for the Marvell parts including some with cache coherency. If your system is running with coherency on, you may have to limit your bursts to 32 bytes (i.e., the size of one cache line). You can see how the bursting is set up on the bridge by looking at the platform file for your board (e.g., file:arch/ppc/platforms/katana.c in the latest linux kernel)--search for 'BURST'. Is there a summary of what is possible and/or not possible with the 4 IDMA channels on the mv64460? The only real documentation is the bridge's user manual from Marvell. Unfortunately, you must sign an NDA to get access to it so I can't share mine with you. You will need access to that info to get very far so I recommend you contact the people in your company that can make that happen, ASAP. For example, if the device that I'm trying to get data from supported a DMA engine capable of initiating bursts on the PCI bus (it currently can't do this), does the current kernel code support that? That's a hardware feature so its not really an issue of kernel support other than ensuring that the firmware and/or kernel configures the bridge correctly. IOW, it can be supported by software but its an issue of whether your hardware supports it (and it actually works). Or if I wanted to suck the data into main memory using the mv64460 IDMA controller (assuming the device couldn't initiate its own burst writes), is there a standard kernel interface to allow me to do this? Yes. You would make a dma ctlr driver for the dma ctlr(s). I don't know what the best example would be but hopefully someone else has a suggestion. Sorry if the questions are silly or inappropriately directed. Not at all. Those were good questions. At the moment I'm still trying to understand some really basic things, like what determines the difference between burst reads and ordinary reads, and what is the difference between SDMA and IDMA, etc ;-) You may want to pick up PCI System Architecture from Mindshare, Inc. There are ones for PCI-X and PCI-Express too, I think. Well worth the money. Many thanks for any help/suggestions/information you can offer. -- Phil I hope this helps, Mark
SMP on MV64460
Hi Lance, On Fri, Dec 16, 2005 at 05:03:14PM -0500, Lance Ware wrote: Hello group, I am currently working on a board which has MV64460 linked between two 7447a processors. I wanted to know if someone has been able to get the Linux 2.6 kernel working with any MV64xxx bridge. I think there are people out there that have made this work. However, I haven't b/c I do not have access to any SMP hardware that has all of the necessary h/w errata implemented. Perhaps others that have hardware will speak up? Mark
Board based on MPC7447 and MV64462
On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote: Hi, I've added platform support for a board based on MPC7447A and MV64462 Marvell Discovery III system controller. I modified code for Katana to make it work for this board. The ethernet and serial are working fine but I don't see anything in lspci output. Do you have any pci devices? If not, then that's to be expected. If you do, then you have something messed up in your code and they aren't being found. Also I don't see timer in cat /proc/interrupts. Neither do I... :) Mark
Board based on MPC7447 and MV64462
On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote: On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote: On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote: Hi, I've added platform support for a board based on MPC7447A and MV64462 Marvell Discovery III system controller. I modified code for Katana to make it work for this board. The ethernet and serial are working fine but I don't see anything in lspci output. Do you have any pci devices? If not, then that's to be expected. If you do, then you have something messed up in your code and they aren't being found. They should at least shgow the northbridge pci ids, no ? No b/c the regs for the bridge are not pci compliant so the bridge is excluded or hidden from the generic pci code (which is where lspci gets its info from). If it wasn't, the generic pci code would get confused as would the bridge. Mark
Board based on MPC7447 and MV64462
On Thu, Oct 27, 2005 at 01:04:47PM -0700, Mark A. Greer wrote: On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote: On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote: On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote: Hi, I've added platform support for a board based on MPC7447A and MV64462 Marvell Discovery III system controller. I modified code for Katana to make it work for this board. The ethernet and serial are working fine but I don't see anything in lspci output. Do you have any pci devices? If not, then that's to be expected. If you do, then you have something messed up in your code and they aren't being found. They should at least shgow the northbridge pci ids, no ? No b/c the regs for the bridge are not pci compliant so the bridge is excluded or hidden from the generic pci code (which is where lspci gets its info from). If it wasn't, the generic pci code would get confused as would the bridge. Actually, I guess this is more to hide the bridge from the pci_auto when it walks the pci buses. If the pci resources are already allocated correctly (as in pegasos?) it may not confuse the generic pci code. Even if it doesn't get confused, its by luck. The bridge's pci regs are NOT pci compliant and, IMHO, its iffy to assume that things woun't get messed up. Mark
Board based on MPC7447 and MV64462
All, For the record, Sven, Matt Porter, and I talked about this some more on IRC. I think we agreed that the best solution would be to register a pci quirk for the bad regs and no longer hide the bridge. Anyone think that's a bad idea? Mark
MPC7447A based board with MV64462 Marvell Discovery III controller
On Thu, Oct 20, 2005 at 05:04:50PM +0200, Sven Luther wrote: Hey, we have code to boot the Freeserv with chrp/Of, need to clean it up and merge it though. Would this be a good thing to submit for mainline inclusion, it is a couple of lines at most, altough there is some reuse of the interrupt controller code i think, which needs some cleanup. I don't know what a Freeserv is but, sure, push it on up once you're happy with it. The more code the merrier. :) Mark
Announce: MPC8272ADS platform support added to mpc8260sar project.
On Tue, Oct 18, 2005 at 09:47:30AM +0100, Alex Zeffertt wrote: On Mon, 17 Oct 2005 11:44:41 -0700 Mark A. Greer mgreer at mvista.com wrote: On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote: Hi lists, I'm writing to let anybody (who may be interested) know that I've added support for the MPC8272ADS platform to the mpc8260sar ATM device driver: http://mpc8260sar.sourceforge.net There is already an ads8272_defconfig in the kernel.org tree and AFAIK it works. Did you add some functionality or change something? Or am I missing something? I've added support for this platform to the ATM driver. ^ Oh, duh. Sorry 'bout that. Mark
Announce: MPC8272ADS platform support added to mpc8260sar project.
On Mon, Oct 17, 2005 at 12:35:43PM +0100, Alex Zeffertt wrote: Hi lists, I'm writing to let anybody (who may be interested) know that I've added support for the MPC8272ADS platform to the mpc8260sar ATM device driver: http://mpc8260sar.sourceforge.net There is already an ads8272_defconfig in the kernel.org tree and AFAIK it works. Did you add some functionality or change something? Or am I missing something? Mark
MPC7447A based board with MV64462 Marvell Discovery III controller
On Thu, Oct 13, 2005 at 01:12:19PM +0530, Ashish Bijlani wrote: Hi, I'm trying to bring MPC7447A based board with MV64462 Marvell Discovery III controller up. Can you guide me to Linux-2.6 sources with support for MV64462 Marvell Discovery III controller and MPC7447A PowerPC processor. Support for I2c, dual 10/100/1000 ethernet ports, and relevant platform should be there. I cannot access the bit keeper repositories so please guide me to the linux-2.6 kernel source tree if you can. Ashish, Support for both the 7447A and mv64x6x is in the latest 2.6 mainline kernel source at kernel.org. If your board is a chrp/openfirmware board, then you probably want to use the Pegasos code as an example. If your board has U-boot or some other non-OF firmware, then use the katana or chestnut as an example (katana is more up-to-date than the chestnut). The ev64360 code may help too. There are i2c and enet drivers (and mpsc and wdt) in that source as well. Note that I've never had a 64462 to test with. Since the '2' means it has less functionality than the '0', you may run into some problems. If you do, please let me know what they are. Mark
porting Linux on ppc7a
On Tue, Sep 20, 2005 at 05:50:23PM +0530, smiling_23 wrote: Hi all, I am tryin to port Linux on ppc7a radstone board. I have seen two threads on porting linux on ppc7a, There he mentioned ppc7a board is similar to EV64260 board. I tried to get the data sheets of EV64620, i failed to found this board data sheets. If any one has this board data sheets , web link or any information please send the information to me. Thanks and regards, Venkata jagadish.p. Before you go too far, did you look to see what already in the community source? There is a port to the radstone ppc7d. I don't know but I wouldn't be surprised if its pretty close to your ppc7a. If you want docs on Marvell products like the ev64260, you need to sign an NDA (last time I checked). Mark
Marvell MV64360 interrupt question
On Fri, Sep 09, 2005 at 01:49:55PM -0700, Dale Farnsworth wrote: On Fri, Sep 09, 2005 at 08:20:20PM +, Walter L. Wimer III wrote: On Fri, 2005-09-09 at 12:27 -0700, Dale Farnsworth wrote: No additional locking is necessary. In fact, it seems to me that the 32-bit register reads and writes are already atomic and all of the locking using mv64x60_lock is superfluous. Ah ha. mv64x60.h also defines an mv64x60_modify() function that isn't intrinsically atomic, so it needs the spinlock. That in turn requires mv64x60_read() and mv64x60_write() to play along too. Yes, the lock is needed for mv64x60_modify(), mv64x60_write(). I still don't think it's needed for mv64x60_read(). IMHO, the mv64x60_read/write/modify routines should be deleted and the locking + I/O done explicitly. That makes it more obvious, more efficient in places where there are multiple writes, etc. in a row (not as much grabbing/releasing of the spinlock), and is the preferred way to do things in linux. A few times now, I almost started to do that...looked at it and went off to do something else. :) Yes, I'm lazy. Yes, I should do it. Eventually, I will (however, if you want to, I won't complain ;). Mark
[PATCH 2.6.13-mm1] ppc32: mv64x60 updates enhancements
Updates and enhancement to the ppc32 mv64x60 code:
- move code to get mem size from mem ctlr to bootwrapper
- address some errata in the mv64360 pic code
- some minor cleanups
- export one of the bridge's regs via sysfs so user daemon can watch for
extraction events
Signed-off-by: Mark A. Greer mgreer at mvista.com
--
diff -Nur linux-2.6.13-mm1/arch/ppc/boot/simple/misc-mv64x60.c
linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-mv64x60.c
--- linux-2.6.13-mm1/arch/ppc/boot/simple/misc-mv64x60.c2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-mv64x60.c2005-09-01
16:56:42.0 -0700
@@ -19,6 +19,33 @@
extern struct bi_record *decompress_kernel(unsigned long load_addr,
int num_words, unsigned long cksum);
+
+u32 size_reg[MV64x60_CPU2MEM_WINDOWS] = {
+ MV64x60_CPU2MEM_0_SIZE, MV64x60_CPU2MEM_1_SIZE,
+ MV64x60_CPU2MEM_2_SIZE, MV64x60_CPU2MEM_3_SIZE
+};
+
+/* Read mem ctlr to get the amount of mem in system */
+unsigned long
+mv64360_get_mem_size(void)
+{
+ u32 enables, i, v;
+ u32 mem = 0;
+
+ enables = in_le32((void __iomem *)CONFIG_MV64X60_NEW_BASE +
+ MV64360_CPU_BAR_ENABLE) 0xf;
+
+ for (i=0; iMV64x60_CPU2MEM_WINDOWS; i++)
+ if (!(enables (1i))) {
+ v = in_le32((void __iomem *)CONFIG_MV64X60_NEW_BASE
+ + size_reg[i]) 0x;
+ v = (v + 1) 16;
+ mem += v;
+ }
+
+ return mem;
+}
+
void
mv64x60_move_base(void __iomem *old_base, void __iomem *new_base)
{
diff -Nur linux-2.6.13-mm1/arch/ppc/Kconfig.debug
linux-2.6.13-mm1-mag/arch/ppc/Kconfig.debug
--- linux-2.6.13-mm1/arch/ppc/Kconfig.debug 2005-08-28 16:41:01.0
-0700
+++ linux-2.6.13-mm1-mag/arch/ppc/Kconfig.debug 2005-09-01 16:56:42.0
-0700
@@ -62,7 +62,8 @@
config SERIAL_TEXT_DEBUG
bool Support for early boot texts over serial port
- depends on 4xx || GT64260 || LOPEC || PPLUS || PRPMC800 || PPC_GEN550
|| PPC_MPC52xx
+ depends on 4xx || LOPEC || MV64X60 || PPLUS || PRPMC800 || \
+ PPC_GEN550 || PPC_MPC52xx
config PPC_OCP
bool
diff -Nur linux-2.6.13-mm1/arch/ppc/syslib/mv64360_pic.c
linux-2.6.13-mm1-mag/arch/ppc/syslib/mv64360_pic.c
--- linux-2.6.13-mm1/arch/ppc/syslib/mv64360_pic.c 2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/syslib/mv64360_pic.c 2005-09-01
16:56:42.0 -0700
@@ -366,10 +366,16 @@
return IRQ_HANDLED;
}
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64360_PCI0_ERR_MASK_VAL 0x00a50c24
+
static int __init
mv64360_register_hdlrs(void)
{
- u32 mask;
int rc;
/* Clear old errors and register CPU interface error intr handler */
@@ -387,17 +393,6 @@
mv64360_sram_error_int_handler,SA_INTERRUPT,SRAM_INTR_STR, 0)))
printk(KERN_WARNING Can't register SRAM error handler: %d,rc);
- /*
-* Bit 0 reserved on 64360 and erratum FEr PCI-#11 (PCI internal
-* data parity error set incorrectly) on rev 0 1 of 64460 requires
-* bit 0 to be cleared.
-*/
- mask = 0x00a50c24;
-
- if ((mv64x60_get_bridge_type() == MV64x60_TYPE_MV64460)
- (mv64x60_get_bridge_rev() 1))
- mask |= 0x1;/* enable DPErr on 64460 */
-
/* Clear old errors and register PCI 0 error intr handler */
mv64x60_write(bh, MV64x60_PCI0_ERR_CAUSE, 0);
if ((rc = request_irq(MV64360_IRQ_PCI0 + mv64360_irq_base,
@@ -407,7 +402,11 @@
rc);
mv64x60_write(bh, MV64x60_PCI0_ERR_MASK, 0);
- mv64x60_write(bh, MV64x60_PCI0_ERR_MASK, mask);
+ mv64x60_write(bh, MV64x60_PCI0_ERR_MASK, MV64360_PCI0_ERR_MASK_VAL);
+
+ /* Erratum FEr PCI-#16 says to clear bit 0 of PCI SERRn Mask reg. */
+ mv64x60_write(bh, MV64x60_PCI0_ERR_SERR_MASK,
+ mv64x60_read(bh, MV64x60_PCI0_ERR_SERR_MASK) ~0x1UL);
/* Clear old errors and register PCI 1 error intr handler */
mv64x60_write(bh, MV64x60_PCI1_ERR_CAUSE, 0);
@@ -418,7 +417,11 @@
rc);
mv64x60_write(bh, MV64x60_PCI1_ERR_MASK, 0);
- mv64x60_write(bh, MV64x60_PCI1_ERR_MASK, mask);
+ mv64x60_write(bh, MV64x60_PCI1_ERR_MASK, MV64360_PCI0_ERR_MASK_VAL);
+
+ /* Erratum FEr PCI-#16 says to clear bit 0 of PCI Intr Mask reg. */
+ mv64x60_write(bh, MV64x60_PCI1_ERR_SERR_MASK,
+ mv64x60_read(bh, MV64x60_PCI1_ERR_SERR_MASK) ~0x1UL);
return 0;
}
diff -Nur linux-2.6.13-mm1/arch/ppc/syslib/mv64x60.c
linux-2.6.13-mm1-mag/arch/ppc/syslib/mv64x60.c
--- linux-2.6.13-mm1/arch/ppc/syslib/mv64x60.c 2005-09-01 16:26
[PATCH 2.6.13-mm1] ppc32: katana updates
Update the katana platform support code:
- if booted as zImage, pass mem size in via bi_req from bootwrapper
- if booted as uImage, get mem size from bd_info passed in from u-boot
- add support for 82544 present on katana 752i's
- set cacheline size on pci devices
- some minor fixups
Signed-off-by: Mark A. Greer mgreer at mvista.com
--
diff -Nur linux-2.6.13-mm1/arch/ppc/boot/simple/misc-katana.c
linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-katana.c
--- linux-2.6.13-mm1/arch/ppc/boot/simple/misc-katana.c 2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-katana.c 2005-09-01
17:00:31.0 -0700
@@ -26,6 +26,8 @@
#definemin(a,b)(((a) (b)) ? (a) : (b))
#endif
+unsigned long mv64360_get_mem_size(void);
+
void
mv64x60_board_init(void __iomem *old_base, void __iomem *new_base)
{
@@ -35,3 +37,9 @@
min(katana_bus_freq((void __iomem *)KATANA_CPLD_BASE),
MV64x60_TCLK_FREQ_MAX);
}
+
+unsigned long
+get_mem_size(void)
+{
+ return mv64360_get_mem_size();
+}
diff -Nur linux-2.6.13-mm1/arch/ppc/configs/katana_defconfig
linux-2.6.13-mm1-mag/arch/ppc/configs/katana_defconfig
--- linux-2.6.13-mm1/arch/ppc/configs/katana_defconfig 2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/configs/katana_defconfig 2005-09-01
17:16:09.0 -0700
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.11
-# Tue Mar 8 17:31:00 2005
+# Linux kernel version: 2.6.13-mm1
+# Thu Sep 1 17:16:03 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
@@ -11,6 +11,7 @@
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
#
# Code maturity level options
@@ -18,28 +19,31 @@
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
+CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
-CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
+CONFIG_INITRAMFS_SOURCE=
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
@@ -68,15 +72,23 @@
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
+# CONFIG_E200 is not set
# CONFIG_E500 is not set
+CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
# CONFIG_TAU is not set
+# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
-# CONFIG_83xx is not set
+# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_PPC_STD_MMU=y
CONFIG_NOT_COHERENT_CACHE=y
#
+# Performance-monitoring counters support
+#
+# CONFIG_PERFCTR is not set
+
+#
# Platform options
#
# CONFIG_PPC_MULTIPLATFORM is not set
@@ -84,21 +96,18 @@
CONFIG_KATANA=y
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
-# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_CHESTNUT is not set
# CONFIG_SPRUCE is not set
+# CONFIG_HDPU is not set
# CONFIG_EV64260 is not set
# CONFIG_LOPEC is not set
-# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_RADSTONE_PPC7D is not set
-# CONFIG_ADIR is not set
-# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
@@ -109,6 +118,8 @@
# CONFIG_ADS8272 is not set
# CONFIG_PQ2FADS is not set
# CONFIG_LITE5200 is not set
+# CONFIG_MPC834x_SYS is not set
+# CONFIG_EV64360 is not set
CONFIG_MV64360=y
CONFIG_MV64X60=y
@@ -118,12 +129,28 @@
CONFIG_MV64X60_BASE=0xf810
CONFIG_MV64X60_NEW_BASE=0xf810
# CONFIG_SMP is not set
+CONFIG_HIGHMEM=y
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
-# CONFIG_HIGHMEM is not set
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE=console=ttyMM0,9600 ip=on
+CONFIG_CMDLINE=console=ttyMM0 ip=on
+# CONFIG_PM is not set
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
#
# Bus options
@@ -132,7 +159,6 @@
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_LEGACY_PROC=y
-CONFIG_PCI_NAMES=y
#
# PCCARD (PCMCIA/CardBus) support
@@ -140,13 +166,10 @@
# CONFIG_PCCARD is not set
#
-# PC-card bridges
-#
-
-#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
[PATCH 2.6.13-mm1] ppc32: cpci690 updates
Update the cpci690 platform code:
- pass mem size in from bootwrapper via bi_rec
- some minor fixups
Signed-off-by: Mark A. Greer mgreer at mvista.com
--
diff -Nur linux-2.6.13-mm1/arch/ppc/boot/simple/misc-cpci690.c
linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-cpci690.c
--- linux-2.6.13-mm1/arch/ppc/boot/simple/misc-cpci690.c2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/boot/simple/misc-cpci690.c2005-09-01
17:00:39.0 -0700
@@ -12,16 +12,56 @@
*/
#include linux/types.h
+#include asm/io.h
#include platforms/cpci690.h
+#defineKB (1024UL)
+#defineMB (1024UL*KB)
+#defineGB (1024UL*MB)
+
extern u32 mv64x60_console_baud;
extern u32 mv64x60_mpsc_clk_src;
extern u32 mv64x60_mpsc_clk_freq;
+u32 mag = 0x;
+
+unsigned long
+get_mem_size(void)
+{
+ u32 size;
+
+ switch (in_8(((void __iomem *)CPCI690_BR_BASE + CPCI690_BR_MEM_CTLR))
+0x07) {
+ case 0x01:
+ size = 256*MB;
+ break;
+ case 0x02:
+ size = 512*MB;
+ break;
+ case 0x03:
+ size = 768*MB;
+ break;
+ case 0x04:
+ size = 1*GB;
+ break;
+ case 0x05:
+ size = 1*GB + 512*MB;
+ break;
+ case 0x06:
+ size = 2*GB;
+ break;
+ default:
+ size = 0;
+ }
+
+ return size;
+}
+
void
mv64x60_board_init(void __iomem *old_base, void __iomem *new_base)
{
mv64x60_console_baud = CPCI690_MPSC_BAUD;
mv64x60_mpsc_clk_src = CPCI690_MPSC_CLK_SRC;
- mv64x60_mpsc_clk_freq = CPCI690_BUS_FREQ;
+ mv64x60_mpsc_clk_freq =
+ (get_mem_size() = (1*GB)) ? 1 : 1;
}
diff -Nur linux-2.6.13-mm1/arch/ppc/configs/cpci690_defconfig
linux-2.6.13-mm1-mag/arch/ppc/configs/cpci690_defconfig
--- linux-2.6.13-mm1/arch/ppc/configs/cpci690_defconfig 2005-08-28
16:41:01.0 -0700
+++ linux-2.6.13-mm1-mag/arch/ppc/configs/cpci690_defconfig 2005-09-01
17:10:44.0 -0700
@@ -1,15 +1,17 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.10-rc2
-# Fri Dec 3 15:56:10 2004
+# Linux kernel version: 2.6.13-mm1
+# Thu Sep 1 17:10:37 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
#
# Code maturity level options
@@ -17,33 +19,38 @@
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
+CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
-CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
+CONFIG_INITRAMFS_SOURCE=
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
#
# Loadable module support
@@ -65,38 +72,42 @@
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
+# CONFIG_E200 is not set
# CONFIG_E500 is not set
+CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
# CONFIG_TAU is not set
+# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
+# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_PPC_STD_MMU=y
# CONFIG_NOT_COHERENT_CACHE is not set
#
+# Performance-monitoring counters support
+#
+# CONFIG_PERFCTR is not set
+
+#
# Platform options
#
# CONFIG_PPC_MULTIPLATFORM is not set
# CONFIG_APUS is not set
# CONFIG_KATANA is not set
-# CONFIG_DMV182 is not set
# CONFIG_WILLOW is not set
CONFIG_CPCI690=y
-# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
-# CONFIG_EV64260 is not set
-# CONFIG_DB64360 is not set
# CONFIG_CHESTNUT is not set
# CONFIG_SPRUCE is not set
+# CONFIG_HDPU is not set
+# CONFIG_EV64260 is not set
# CONFIG_LOPEC is not set
-# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
-# CONFIG_PRPMC880 is not set
# CONFIG_SANDPOINT is not set
-# CONFIG_ADIR is not set
-# CONFIG_K2 is not set
+# CONFIG_RADSTONE_PPC7D is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
@@ -105,22 +116,41 @@
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_ADS8272 is not set
+# CONFIG_PQ2FADS is not set
# CONFIG_LITE5200 is not set
bd_t Cleaning: Board Changes
On Wed, Jun 01, 2005 at 11:10:48AM -0700, Mark A. Greer wrote: Jon Loeliger wrote: snip Part Two of Four, the Board Changes. ppc/platforms/4xx/ash.h | 21 - ... snip again snip All, So is this patch going to go in? I haven't seen anyone push it up. The reason I'm asking is that I have a couple patches that I would like to push up but they will collide with this one so I need to know if it (or a variation thereof) is going to go in or not. Thanks, Mark Jon, Any news on this patch? Mark
MPC8245 reboot
On Wed, Aug 03, 2005 at 03:40:18PM +0900, Daniel Ann wrote: Absolutely not. Very much like sandpoint except, we dont use SIO at all. FYI, most of sandpoint code from the kernel is function the board very well at the moment. Only big issue lies with REBOOT at this stage:( Daniel, IIRC, the sandpoint uses the PC style port 92 mechanism to reset the board. You need to look at your hardware docs to see how your board can be reset. Don't expect the sandpoint reset code to work for you. Mark
MPC8245 reboot
On Thu, Aug 04, 2005 at 09:16:23AM +0900, Daniel Ann wrote: Mark, Guess I'll have to walk the uncharted area again :P Thanks anyway tho. I'll start by looking at what that port 92 mechanism is first, and see where in our hw designer have put that in. Personally, I wouldn't waste my time on the port 92 stuff. I really doubt the hw engr did that unless your board is very PC-ish. Does your board have any board regs (e.g., some regs on a pld or something)? If so, look through those for a bit in a register that resets the system. Mark
Reply: Bad Magic Number when boot linux kernel with ppcboot (PPC860 board)
On Tue, Aug 02, 2005 at 09:15:22AM +0200, Wolfgang Denk wrote: In message A9DE2BAF233E444FA9C5E77A5825A01E8652FA at ydmail.sbell.com.cn you wrote: = bootm 0x18 ## Booting image at ... Bad Magic Number = The funny thing is that you seem to enter 0x18 but the address printed is . make sure you have no funny characters or control keys in this number. Re-type it carefully. Omit the 0x part, i. e. try a plain bootm 18' Plus, use 'bootm' for a .uboot file, 'bootelf' for a zImage.
Getting ownership for various boards/platforms configs
Two things: 1) What is common in your list? 2) On a slightly different note...if no one volunteers to look after the following ones, I vote to remove them: k2 lopec mcpn765 menf1Dead (Matt Porter) pmac :) Are there others? Mark
bd_t Cleaning: Board Changes
Jon Loeliger wrote: snip Part Two of Four, the Board Changes. ppc/platforms/4xx/ash.h | 21 - ppc/platforms/4xx/bubinga.c |4 ppc/platforms/4xx/bubinga.h | 23 - ppc/platforms/4xx/cpci405.h |2 ppc/platforms/4xx/ebony.c |9 ppc/platforms/4xx/ep405.c | 12 ppc/platforms/4xx/ep405.h | 13 ppc/platforms/4xx/luan.c|7 ppc/platforms/4xx/oak.c | 15 ppc/platforms/4xx/oak.h | 19 - ppc/platforms/4xx/oak_setup.h |2 ppc/platforms/4xx/ocotea.c | 13 ppc/platforms/4xx/redwood5.h| 13 ppc/platforms/4xx/redwood6.c| 27 - ppc/platforms/4xx/redwood6.h| 13 ppc/platforms/4xx/sycamore.h| 22 - ppc/platforms/4xx/walnut.h | 22 - ppc/platforms/4xx/xilinx_ml300.h| 12 ppc/platforms/83xx/mpc834x_sys.c| 49 +- ppc/platforms/83xx/mpc834x_sys.h|1 ppc/platforms/85xx/mpc8540_ads.c| 57 ++- ppc/platforms/85xx/mpc8560_ads.c| 21 - ppc/platforms/85xx/mpc85xx_ads_common.c | 10 ppc/platforms/85xx/mpc85xx_ads_common.h |1 ppc/platforms/85xx/mpc85xx_cds_common.c | 48 +- ppc/platforms/85xx/mpc85xx_cds_common.h |1 ppc/platforms/85xx/sbc8560.c| 19 - ppc/platforms/85xx/sbc85xx.c| 14 ppc/platforms/85xx/sbc85xx.h|1 ppc/platforms/85xx/stx_gp3.c| 34 - ppc/platforms/85xx/stx_gp3.h|1 ppc/platforms/bseip.h | 13 ppc/platforms/ccm.h |2 ppc/platforms/cpci690.h | 10 ppc/platforms/est8260.h | 18 ppc/platforms/fads.h|2 ppc/platforms/hdpu.c| 13 ppc/platforms/hermes.h |2 ppc/platforms/ip860.h |2 ppc/platforms/ivms8.h |2 ppc/platforms/katana.c |6 ppc/platforms/lantec.h |2 ppc/platforms/lite5200.c|9 ppc/platforms/lwmon.h |2 ppc/platforms/mbx.h | 22 - ppc/platforms/pcu_e.h |2 ppc/platforms/pq2ads.c |1 ppc/platforms/pq2ads.h |2 ppc/platforms/radstone_ppc7d.c | 32 - ppc/platforms/radstone_ppc7d.h |2 ppc/platforms/rpx8260.h | 19 - ppc/platforms/rpxclassic.h | 13 ppc/platforms/rpxlite.h | 13 ppc/platforms/sandpoint.c | 11 ppc/platforms/sandpoint.h |2 ppc/platforms/sbc82xx.c |6 ppc/platforms/sbc82xx.h |2 ppc/platforms/sbs8260.h | 18 ppc/platforms/spd8xx.h |2 ppc/platforms/tqm8260.h |2 ppc/platforms/tqm8260_setup.c |1 ppc/platforms/tqm8xx.h |2 snip All, So is this patch going to go in? I haven't seen anyone push it up. The reason I'm asking is that I have a couple patches that I would like to push up but they will collide with this one so I need to know if it (or a variation thereof) is going to go in or not. Thanks, Mark
RFC: Deprecating io_block_mapping
Benjamin Herrenschmidt wrote: - There is _one_ important point to keep in mind, but that has always been true: None of this work before MMU_init(), This is very true and raises a couple issues that we should fix while we're at it: 1) There are progress calls in MMU_init which will try to access the uart before its possible to create a mapping to the uart's regs (assuming you don't make a hack to map them and that you set up ppc_md.progress in your platform_init routine). We should either get rid of those calls in MMU_init, provide an acceptable way to make temporary pre-MMU_init mappings, or make sure nobody sets up ppc_md.progress until ioremap is working (and also get rid of the calls in MMU_init b/c they're never used). 2) Some firmwares don't provide any info on how much memory is in the system but MMU_init needs to know that. So the platform code has to read the SPD from the mem sticks via i2c, read the mem ctlr, or read a board reg that has the info. All of those require access to hw regs before or during MMU_init. I should be able to get rid of this one by figuring out the amount of memory in the bootwrapper and passing it in to the kernel. I am assuming that all the boards with this problem use the bootwrapper. I think that's a safe assumption but I'll have to verify. BTW, these are the reasons that I made that set_bat hack that Dan is so fond of. :) I'll get rid of that hack but I need an answer to 1) first. Mark
RFC: Deprecating io_block_mapping
Benjamin Herrenschmidt wrote: On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote: Benjamin Herrenschmidt wrote: - There is _one_ important point to keep in mind, but that has always been true: None of this work before MMU_init(), This is very true and raises a couple issues that we should fix while we're at it: 1) There are progress calls in MMU_init which will try to access the uart before its possible to create a mapping to the uart's regs (assuming you don't make a hack to map them and that you set up ppc_md.progress in your platform_init routine). We should either get rid of those calls in MMU_init, provide an acceptable way to make temporary pre-MMU_init mappings, or make sure nobody sets up ppc_md.progress until ioremap is working (and also get rid of the calls in MMU_init b/c they're never used). Or have the implementation of progress() check if the mapping was done or not ... Doesn't seem worth it to me. In any ways, I always disliked ppc_md.progress deeply. It's ugly and clutters the code. It has never proven very useful to me vs. having an early console. Okay, let's rip it out of MMU_init then. Anyone have a problem with that? Mark
824x sandpoint and 2.6.x
Sam Song wrote: If possible, could you pls show me a right 2.6 boot process of sandpoint X3/2? I wanna to find out some nice hints of it. This is the first time to me so hard to debug a kernel before normal console. Here is the output of a 7457 sandpoint on a very old root filesystem. Output for any other processor will be the same. -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: sandpoint.log Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050428/d3d9dcd8/attachment.txt
MPC8245 custom board, Linux 2.4 kernel hangs after uncompressing
Sam Song wrote: had, is it possible to flush the content of __log_buf after reset? Sam, I thought I finally noticed yesterday that you're using 2.4. If that is the case, you want to dump log_buf not __log_buf. Mark
824x Sandpoint with 2.6.x
Sam Song wrote: You can even use the progress facility to dump the __log_buf. I don't have such experience. If possible, could u give me a linkage or doc for me to have a look? The doc is the source code. BTW, Could I use KGDB to try it? It may help but it depends on how far you're getting and what your problem is. Mark
824x Sandpoint with 2.6.x
Sam Song wrote: Mark A. Greer mgreer at mvista.com wrote: Kernel command line: console=uart,mmio,0xfdfce500,115200n8 console=ttyS0,115200 root=/dev/ram rw ramdisk_size=20 ip=192.168.0.3:192.168..2:::sandpoint:et h0:off panic=1 snip Get rid of the console=uart,mmio,0xfdfce500,115200n8 part of the cmdline and see what happens (keep the console=ttyS0,115200 part). If so, kernel will hang after loading the kernel.. Okay, obviously something is wrong. Adding another console line isn't fixing anything, its just allowing you to flounder on a little further. IMHO, adding another console line isn't going to help and will only add confusion. I cannot see any active info.Is early console output message not enough to find out something useful? Sure it does. You have to enable it, then add some progress lines to help narrow down where you're panic'ing/hanging. You can even use the progress facility to dump the __log_buf. I'm taking your unwillingness to use a jtag/cops debugger as indication that you don't have such a tool!?!? Mark
Marvell 64360, MPSC Serial Console Problem
Suresh Chandra Mannava wrote: snip We faced a problem in MPSC serial console part. The problem is, in Serial console data is received once after 32 characters are typed. Any thing less than 32 characters is not echoed or not transmitted till the 32 character count is reached. After carefully reviewing the code. We found that the receive buffer size is initialised to 32 bytes. We made a small correction in the code by making the receive buffer size to 1 rxre-bufsize = 1; snip Suresh, I think you fixed a symptom but not the problem. By default, the rx buffers are indeed 32 bytes long (i.e., a cacheline in size). When receiving, the mpsc will generate an interrupt when there is an error, when the buffer is full (32 bytes--unlikely if you're typing), or after a timeout. I suspect your timeout value is bogus so you don't get the interrupt until you fill the buffer with 32 bytes. Please compare the platform_data that you pass to the mpsc driver to other, working systems that use the mpsc (e.g., katana and cpci690). In particular, look at your 'max_idle' value. Mark
824x Sandpoint with 2.6.x
Sam Song wrote: snip OK, I am now up to the joint of early_console and normal console. Switch problem. Perhaps I miss sth or what? snip Kernel command line: console=uart,mmio,0xfdfce500,115200n8 console=ttyS0,115200 root=/dev/ram rw ramdisk_size=20 ip=192.168.0.3:192.168..2:::sandpoint:et h0:off panic=1 snip Get rid of the console=uart,mmio,0xfdfce500,115200n8 part of the cmdline and see what happens (keep the console=ttyS0,115200 part). Mark
824x Sandpoint with 2.6.x
Mark A. Greer wrote: RAMDISK support kernel. The console setting was ttyS0,115200. But hanged after loading the kernel... What could the problem be? Also, are you sure 115200 is the correct baud rate?
Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
Daniel Ann wrote: On Apr 9, 2005 3:32 AM, Mark A. Greer mgreer at mvista.com wrote: Also, 33MHz does not sound right but then you don't say what processor you're using so who knows. You need to find the bus freq used by the cpu/system. Try looking for the freq of the processor's SYSCLK input. Then you probably have to divide that by 4 to get the frequency that the decrementer runs at. That's the value that you should use for the 'freq' variable in the example code you included in your email. Okay guess I had all these things mixed up in head. What I should have said is, source to PCI_SYNC_IN is 33MHz. Ah, that sounds reasonable. ;) Anyway, following the MPC8245 hardware Spec pdf file, I was able to find the peripheral logic/memory bus clock to be 99,000,000. Dividing that by 4 like you said, gave me the value of 24,750,000. Which is I've used it to get very real 1 second :) Cool. BTW, why do you have to divide it by 4 ? Because the internally kept time in ppc linux is based on the decrementer counter and, according to the manual for the 8245, the decrementer counter is decremented once every four sys_logic_clk cycles. Therefore, you need to divide by 4. Mark
824x Sandpoint with 2.6.x
Sam Song wrote: Hi all, I'd like to know where I could get a good start on 824x Sandpoint board with 2.6.x? Is linuxppc-2.5 BK tree nice for me to work? No. Use linux-2.5/6. Mark
Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
Daniel, Daniel Ann wrote: Hey folks, I seem to have problem getting 1 second right. Board has no RTC so I've basically NULLed all the todc_XXX functions except todc_calibrate_decr. If you don't have an RTC, you shouldn't be using any todc_xxx routines. Now question is, what value should I be assigning it to tb_ticks_per_jiffy ? I was able to dig up some info from the archive, and it read, =-=-=-FROM ARCHIVE =-=-=- You must find this value by yourself but a good starting point is your frequency in Hz (I think) Example of the code unsigned int freq = 2800; tb_tick_per_jiffy = freq/HZ; tb_to_us = mulhwu_scale_factor(freq,100); =-=-=-END OF ARCHIVE =-=-=- I'm fine with working it out myself but where do I start ? My board has 33MHz OSC, so I've trie freq = 33 * 100 (where HZ is defined 100) but it turned out to be little short. I could have just tried few more trial and error, but I prefer knowing what I'm doing so.. :) There are several platform files that explicitly set tb_ticks_per_jiffy and tb_to_us. Did you try looking at those? Also, 33MHz does not sound right but then you don't say what processor you're using so who knows. You need to find the bus freq used by the cpu/system. Try looking for the freq of the processor's SYSCLK input. Then you probably have to divide that by 4 to get the frequency that the decrementer runs at. That's the value that you should use for the 'freq' variable in the example code you included in your email. Mark
MTD Mapping driver - out of vmalloc space
Ho Lee wrote: Hi Chris, How about setting PAGE_OFFSET to 0x8000, that is 2G/2G split? It would make enough virtual address space. I've never tried on PPC, so I don't know the side effect of this. -- Ho Chris, Like Ho says, you need to lower PAGE_OFFSET (although you may not want to drop it all the way to 0x8000). That will increase your vmalloc space. On ppc, you do this via the 'Advanced setup' config menu. Mark
[PATCH 2.6.12] ppc32: Fix Sandpoint Soft Reboot
ppc32: Fix Sandpoint Soft Reboot This patch allows the Freescale Sandpoint to perform soft reboots. A write of 0x00 to the Winbond's Chip Select Control Register was clearing the Upper BIOS Chip Select Enable bit which unmaps the boot flash. The comment associated with the write noted that it was enabling the RTC and Keyboard address locations, but the bits in question (1 and 0) are reserved when the Winbond chip is in PowerPC mode. Also, the bits are 1 for enable, 0 for disable, therefore the original code was actually disabling the address locations. The patch also corrects errors in the definitions of 2 configuration bits in the Tundra Tsi107 bridge's MAPB Options register. Signed-off-by Randy Vinson rvinson at mvista.com Signed-off-by Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: sandpoint.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050323/8cade076/attachment.txt
PCI problem
srinivas.surabhi at wipro.com wrote: Hi, We are facing the problem with MVlinux3.1 having kernel 2.4.20 booting once the PCI is enabled in config kernel. First Question is it any where required in linux kernel sources to make the PCI configuration changes...IF so please let me know in which file ?? Even the message linux kernel banner which is at the beginning of the start_kernel function is not seen. Once the multi image( kernel + ram disk File system) is extracted into RAM. After that it hangs bootm 0xfef8 ## Booting image at fef8 ... Image Name: MultiImage Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:4647626 Bytes = 4.4 MB Load Address: Entry Point: Contents: Image 0: 551181 Bytes = 538.3 kB Image 1: 4096430 Bytes = 3.9 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... =0= OK Booting Linux Loading Ramdisk to 07417000, end 077ff1ae ... OK ...Then hangs SO please help me out in finding out the relation of PCI and the start_kernel. As per my knowledge once the kernel_init is entered then the pci_init is invoked. But strangely I am seeing with pci enabled, hang at the very beginning.. Thanks Rgds SS -Original Message- From: wd at denx.de [mailto:wd at denx.de] Sent: Thursday, February 17, 2005 5:13 PM To: Srinivas Surabhi (WT01 - EMBEDDED PRODUCT ENGINEERING SOLUTIONS) Cc: linuxppc-embedded at ozlabs.org Subject: Re: Mounta Vista Linux prompt on serial console In message EF9B29C78F41FA488927FCBC7750AF0E08DA14 at hyd-mdp-msg.wipro.com you wrote: But the problem is that it was stopping at No init found. Try passing init= option to kernel. Before that there were no errors. Everthing looks fine Mounted VFS root file system was also Fine. So you can mount the root filesystem, but it obviously does not contain all the required files. seen. From the net I understood is that the fstab file was the cause. So edited the filesytem parameter for / as /dev/ram earlier it used to be /dev/root. No. /etc/fstab has absolutley nothing to do with your problem. The kernel cannot start the init porocess - make sure init is in the filesystem, plus all required libraries. So please tell me whether the given fstab file will suffice? The filesystem This is completley unrelated. 2. I have one more doubt /sbin/init utility comes with what package? Because in /sbin directory although the init binary is present, not shown in the file system heirarchy view. For eg. if I select DHCPD package then able to see dhcpd related binary in the /sbin similarly my question was which package has to be selected to have init included. Please contact MV support. I have no idea how they package their distribution, or how their config tools might work. You paid for their stuff, so ask _them_. Best regards, Wolfgang Denk Srinivas, 1) Please don't post the same question twice to the same mailing list. 2) Please stop replying to a msg in an existing thread when you start a new thread. Go look at http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/thread.html. Your new thread appear as though its part of 440GX 2.6 NAP thread. It looks like you've done that in other threads too. 3) When you ask a question, please provide enough detail so that there is at least the possibility that someone else can help you. What platform is this on? Did this kernel ever work for you on that platform? If so, then what have you changed? 4) Heed Wolfgang's advice...if you actually did pay MontaVista for support then you should be contacting them. Mark
[PATCH 2.6.12] ppc32: Fix mv64x60 internal SRAM size
ppc32: Fix wrong size for mv64[34]60's internal SRAM. - Fix incorrect SRAM size - Minor Kconfig cleanups for mv64x60 platforms Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: mv64x60_sram_size.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050318/737305ff/attachment.txt
[PATCH 2.6.12] ppc32: Fix mv64x60 internal SRAM size
Yes, it looks correct to me. Sorry for the bad patch. Mark -- Andrew Morton wrote: Mark A. Greer mgreer at mvista.com wrote: ppc32: Fix wrong size for mv64[34]60's internal SRAM. This got a reject against other ppc32 patches which I had (they've all just been flushed to Linus). The reject was in arch/ppc/Kconfig. Please check that I fixed it up correctly. From: Mark A. Greer mgreer at mvista.com ppc32: Fix wrong size for mv64[34]60's internal SRAM. - Fix incorrect SRAM size - Minor Kconfig cleanups for mv64x60 platforms Signed-off-by: Mark A. Greer mgreer at mvista.com Signed-off-by: Andrew Morton akpm at osdl.org --- 25-akpm/arch/ppc/Kconfig | 10 ++ 25-akpm/arch/ppc/platforms/chestnut.h |4 ++-- 25-akpm/arch/ppc/platforms/katana.h|2 +- 25-akpm/include/asm-ppc/mv64x60_defs.h |2 +- 4 files changed, 6 insertions(+), 12 deletions(-) diff -puN arch/ppc/Kconfig~ppc32-fix-mv64x60-internal-sram-size arch/ppc/Kconfig --- 25/arch/ppc/Kconfig~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/Kconfig 2005-03-18 13:42:57.0 -0800 @@ -577,7 +577,6 @@ config SANDPOINT config RADSTONE_PPC7D bool Radstone Technology PPC7D board - select MV64360 config ADIR bool SBS-Adirondack @@ -753,16 +752,11 @@ config GT64260 depends on EV64260 || CPCI690 default y -config MV64360 +config MV64360# Really MV64360 MV64460 bool - depends on KATANA || RADSTONE_PPC7D || HDPU + depends on CHESTNUT || KATANA || RADSTONE_PPC7D || HDPU default y -config MV64360 - bool - depends on CHESTNUT - default y - config MV64X60 bool depends on (GT64260 || MV64360) diff -puN arch/ppc/platforms/chestnut.h~ppc32-fix-mv64x60-internal-sram-size arch/ppc/platforms/chestnut.h --- 25/arch/ppc/platforms/chestnut.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/platforms/chestnut.h 2005-03-18 13:41:27.0 -0800 @@ -28,8 +28,8 @@ *0xffd0-0xffd4 - CPLD *0xffc0-0xffcf - UART *0xffb0-0xffb07fff - FRAM - *0xffa0-0xffaf - *** HOLE *** - *0xff80-0xff9f - MV64460 Integrated SRAM + *0xff84-0xffaf - *** HOLE *** + *0xff80-0xff83 - MV64460 Integrated SRAM *0xfe00-0xff8f - *** HOLE *** *0xfc00-0xfdff - 32bit Flash *0xf101-0xfbff - *** HOLE *** diff -puN arch/ppc/platforms/katana.h~ppc32-fix-mv64x60-internal-sram-size arch/ppc/platforms/katana.h --- 25/arch/ppc/platforms/katana.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/arch/ppc/platforms/katana.h2005-03-18 13:41:27.0 -0800 @@ -24,7 +24,7 @@ * on a boundary that is a multiple of the window size): * *0xff80-0x - Boot window - *0xf840-0xf85f - Internal SRAM + *0xf840-0xf843 - Internal SRAM *0xf820-0xf83f - CPLD *0xf810-0xf810 - MV64360 Registers (CONFIG_MV64X60_NEW_BASE) *0xf800-0xf80f - Socketed FLASH diff -puN include/asm-ppc/mv64x60_defs.h~ppc32-fix-mv64x60-internal-sram-size include/asm-ppc/mv64x60_defs.h --- 25/include/asm-ppc/mv64x60_defs.h~ppc32-fix-mv64x60-internal-sram-size 2005-03-18 13:41:27.0 -0800 +++ 25-akpm/include/asm-ppc/mv64x60_defs.h 2005-03-18 13:41:27.0 -0800 @@ -347,7 +347,7 @@ #define MV64360_SRAM_ERR_DATA_HI0x03a0 #define MV64360_SRAM_ERR_PARITY 0x03a8 -#define MV64360_SRAM_SIZE 0x0020 /* 2 MB of SRAM */ +#define MV64360_SRAM_SIZE 0x0004 /* 2Mb/256KB SRAM */ /* * _
Problems with MontaVista Linux on a Memec Virtex-II pro ff672 board
S. van Beek wrote: Hello there, This is our first post on this list, hi all! We're two Dutch students working with a Virtex-II pro ff672 board from Memec with the Communications 2 module. We've compiled a simple kernel wich comes with MontaVista Linux 3.1 (2.4.20) with ethernet and a serial port. It mounts its root filesystem over NFS and everything seems to work nicely. The next step we wanted to make was adding support for the Flash on the com board. We added the IP to the hardware and loaded the new bitstream in the FPGA. Next thing, we enabled support for MTD devices in the kernel. After that, the kernel did not seem to boot anymore. It stopped at the message 'Now booting the kernel'. So we read some documentation about debugging. We recompiled this kernel with the -g -ggdb options and removed the -O (optimalization) flag. Then we did not even see the ppc boot loader messages anymore when trying to boot. So we tried to compile the first kernel (with only serial and ethernet support) -wich worked fine before- with debugging and it gave us the same result.. no output at all. Can anyone give us some hints on what we can try more to find out what is going wrong? There are lots of possible problems that may be causing this but my guess is that you are accessing some piece of hardware that you don't have ioremap'd/io_block_mapping'd. IOW, you don't have a virt-phys translation set up for the hardware register you're trying to access. If you can find a COPS/JTAG debugger and your board has a connector, set it up and run your kernel again. When it hangs stop the processor and dump the 'log_buf' that's in memory (you can get the address from your System.map file). That's where printk msgs are logged before the console is set up. In there you will likely see a panic msg and a register dump. That should point you to where things went wrong. If you don't have access to a debugger like that, you could try running KGDB. If the kernel is running long enough to reach the initial breakpoint and you have correctly configured your code so that KGDB will work, that can be big help too. Mark
[PATCH] ppc32: 0/2 add support for Sky Computers HDPU Compute blade
Brian Waite wrote: +#define HDPU_INTERNAL_SRAM_BASE 0xfbfc +#define HDPU_INTERNAL_SRAM_SIZE 0x0004 I haven't gone through in detail yet but one thing I did notice was that you don't have the proper SRAM alignment or size. The SRAM on the 64[34]60 is 2MB so it must be aligned on a boundary that's a multiple of 2MB. Mark
[PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
J?rn Engel wrote: On Fri, 11 March 2005 17:40:55 -0700, Mark A. Greer wrote: Remove Chestnut mtd map file. The chestnut now sets up its MTD map from its platform-specific file so the map file drivers/mtd/maps/chestnut.c is no longer needed. This patch removes the file the Kconfig/Makefile hooks. Please apply. Applied to mtd cvs. It will make its way to Linus eventually... Thanks! J?rn, Thanks for looking into this but Andrew has already pushed that through from his end. (I had posted an earler patch with the map removal in it before I broke it out and sent that part to you and the rest to Andrew again.) Sorry for wasting your time. Mark
[PATCH] ppc32: 0/2 add support for Sky Computers HDPU Compute blade
Brian Waite wrote: On Thursday 17 March 2005 12:44, Mark A. Greer wrote: Brian Waite wrote: +#define HDPU_INTERNAL_SRAM_BASE 0xfbfc +#define HDPU_INTERNAL_SRAM_SIZE 0x0004 I haven't gone through in detail yet but one thing I did notice was that you don't have the proper SRAM alignment or size. The SRAM on the 64[34]60 is 2MB so it must be aligned on a boundary that's a multiple of 2MB. Mark, Argh that is a carry over from a bad experiment in consolidating memory space. I don't use the SRAM for anything so it will not break the code so I will provide a patch on top of the platform patch to fix this if that works for you. Brian, I stand corrected. Dale Farnsworth pointed out to me that its 2Mb (as in bit) not byte. I was reading the manual wrong. Sorry 'bout that. Mark
[patch] mpc8560ads mtd map
Greg Weeks wrote: Add an MTD map for the flash on the mpc8560ads board. Signed-off-by: Greg Weeks greg.weeks at timesys.com snip Most of the code in this patch can be eliminated if you set up the table in your platform file and use the proper CONFIG_MTD_xxx options. Mark
[PATCH 2.6.12] ppc32: Patch for changed dev-bus_id format
ppc32: Patch for changed dev-bus_id format + some misc fixups - Recent changes to drivers/base/platform.c:platform_device_register() changed the format of dev-bus_id (there is now a '.' between the name instance (e.g., the old mpsc0 is now mpsc.0)). This field is used by some platform's platform_notify() routine to identify the dev entry. This patch updates the bus_id value compared to include the dot. - Fix an bad macro name change by a previous patch. - Some coding style fixups, etc. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: bus_id_fixups.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/737687d0/attachment.txt
[PATCH 2.6.11] ppc32: update Radstone ppc7d platform
ppc32: Radstone PPC7D platform update - Recent mv643xx #define name changes broke the PPC7D platform compile. Fixed by this patch. - Change default platform config to add mv643xx_eth and mv64xxx-i2c config options. - Add i2c platform data and update to cope with recent platform device name change. Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc7d-2.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/7f7ab745/attachment.txt
[PATCH 2.6.12] ppc32: Clean up mv64x60 bootwrapper support
ppc32: Clean up mv64x60 bootwrapper support This patch removes the call to mv64x60_init() in arch/ppc/boot/simple/head.S and now uses the 'load_kernel()' hook to call to have mv64x60-specific code called. This means that the mv64x60 code will be called after the bootwrapper has relocated itself. The platforms affected by this change are updated by this patch as well. Depends on patch: http://ozlabs.org/pipermail/linuxppc-embedded/2005-March/017269.html Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc32_bootwrapper.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/251bdcc1/attachment.txt
[PATCH 2.6.12] PPC32: Update chestnut platform files
Update Chestnut platform files. - Set up mtd partition from arch-specific platform file and remove obsoleted mtd map. - Update default config file (now enables embedded ethernet driver). - Make some minor fixups. - General code cleanup. Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: chestnut.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050311/1755d42e/attachment.txt
[PATCH 2.6.12] PPC32: Update chestnut platform files
Josh Boyer wrote: On Fri, 2005-03-11 at 15:05 -0700, Mark A. Greer wrote: Update Chestnut platform files. - Set up mtd partition from arch-specific platform file and remove obsoleted mtd map. Could you forward this portion of the patch to the MTD maintainer? That way it has less of a chance getting re-added to -mm when Andrew grabs the latest MTD bitkeeper tree. Certainly. Thanks. Mark Update Chestnut platform files. - Update default config file (now enables embedded ethernet driver). - Make some minor fixups. - General code cleanup. Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: chestnut.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050311/e6272553/attachment.txt
[PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
Remove Chestnut mtd map file. The chestnut now sets up its MTD map from its platform-specific file so the map file drivers/mtd/maps/chestnut.c is no longer needed. This patch removes the file the Kconfig/Makefile hooks. Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: chestnut_mtd.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050311/ee4f1658/attachment.txt
[PATCH 2.6.12] PPC32: Add rtc hooks to katana + fw bug workaround
Add rtc hooks to katana and workaround firmware bug. - Now that the mv64xxx i2c and m41t00 i2c rtc drivers are in the source base, add hooks to the katana file to use that rtc. - A recent version of the katana firmware incorrectly changes the mv64x60's pci vendor device id so this patch puts back the proper values. - Misc. cleanup and update of the default config file. Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: katana_rtc.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050310/6104c71e/attachment.txt
[PATCH 2.6.12] PPC32: Add rtc hooks to katana + fw bug workaround
Add rtc hooks to katana and workaround firmware bug. - Now that the mv64xxx i2c and m41t00 i2c rtc drivers are in the source base, add hooks to the katana file to use that rtc. - A recent version of the katana firmware incorrectly changes the mv64x60's pci vendor device id so this patch puts back the proper values. - Misc. cleanup and update of the default config file. Please apply. Signed-off-by: Mark A. Greer mgreer at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: katana_rtc.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050310/c583b221/attachment.txt
[PATCH 2.6.12] PPC32: Add rtc hooks to katana + fw bug workaround
Sorry again for the spam. Mark
mv64x60 updates
Sven Luther wrote: I have appended a (slightly revised) version of the patch, which is against a saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet, which is what Mark and Dale are working on. Viewed like that the patch is against to really manageable size, altough it may need some fine-tuning. The rest of your comments probably apply to Dale's and Mark's work in the above tree though. Hi guys. I got in late today so I'm just reading this thread now. I basically want to reiterate and expand on what Brian linwoes at gmail.com stated. The arch/ppc/syslib/mv64x60* code is really for embedded systems only. More accurately, its for systems whose firmwares don't do a good job of configuring the bridge or if you want to significantly change that configuration. This ends up including many embedded systems but basically no desktop-like systems (e.g., ones with openfirmware) so that's why this thread should stay on linuxppc-embedded only. Sven, et. al., your system has openfirmware and apparenly does a very good job of configuring the bridge so just ignore the mv64x60 stuff. You can use the platform_data code from there as an example of what needs to be passed into the enet driver (and mpsc i2c wdt, if you use them (and find all the patches :)). If I missed something or you have any more questions, I'l be happy to help. Mark
MV64360 MPSC - console problem
Hi Ashok. Hegde Ashok-aah024 wrote: Hi All, I am trying to bring up linux-2.6.10 on ppc based system with MV64360(marvell controller). I am unable to use mpsc as the console, serial text debug messages are coming fine i.e. ppc_md.progress able to print properly on the serial port. I observed that when console_init() is being called from init/main.c none of our mpsc init functions are called. Also I see that there is no call to console_initcall in mpsc driver. According to my understanding this call is required in serial drivers used as consoles. I took this mpsc driver from bk://source.mvista.com/linux-2.5-marvell as mentioned in ppc mailinglist. Hardware has been tested with linux-2.4.20 flavour and it is absolutely fine. Appreciate any help. It almost sounds like you don't have the mpsc config option selected. Make sure that Marvell MPSC serial port support and Support for consol on Marvell MPSC serial port under Device Drivers/Character devices/Serial drivers are selected. If they don't appear then you don't have CONFIG_PPC and/or CONFIG_MV64X60 defined. Those two should be defined in arch/ppc/Kconfig under the appropriate board selection. You also have to have the platform_data that is passed into the MPSC driver set up correctly for it to work correctly. Mark
MV64360 MPSC - console problem
Hegde Ashok-aah024 wrote: I took this mpsc driver from bk://source.mvista.com/linux-2.5-marvell as mentioned in ppc mailinglist. Also, this tree has long since been dead. In fact, its been deleted. You should be using the official kernel.org source base. Mark
PATCH 2.6.11-rc5] ppc32: add Radstone PPC7D platform support
ppc32: add Radstone PPC7D platform support Radstone PPC7D are ppc7447A VME boards with Marvell Discovery-II, dual GigE, dual PMC, 6 serial ports, keyboard/mouse, USB and optional SCSI/VGA. This patch adds support for the PPC7D platform. Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc7d.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050304/eaaffcb6/attachment.txt
PATCH 2.6.11-rc5] ppc32: add Radstone PPC7D platform support
ppc32: add Radstone PPC7D platform support Radstone PPC7D are ppc7447A VME boards with Marvell Discovery-II, dual GigE, dual PMC, 6 serial ports, keyboard/mouse, USB and optional SCSI/VGA. This patch adds support for the PPC7D platform. Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ppc7d.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050304/d95420a8/attachment.txt
PATCH 2.6.11-rc5] ppc32: add Radstone PPC7D platform support
Sorry for the spam. I horked Andrew's email addr. Mark
[PATCH 2.6.11-rc4] ppc: add support for Radstone ppc7d boards
James Chapman wrote: Revised patch for Radstone PPC7D board support. Signed-off-by: James Chapman jchapman at katalix.com - use mv64x60_set_bus() to setup for PCI scans rather than writing to chip P2P_CONFIG registers directly. Looks good, James, except for a couple minor things. If/when you address the comments, please resubmit the entire patch with a proper description so I can forward it on -- http://linux.yyz.us/patch-format.html Thanks, Mark -- diff -Nru a/arch/ppc/platforms/radstone_ppc7d.c b/arch/ppc/platforms/radstone_ppc7d.c +#if defined(CONFIG_SERIAL_MPSC_CONSOLE) + mv64x60_mpsc_init(port, uart); Don't you mean mv64x60_progress_init( base ); ? diff -Nru a/arch/ppc/platforms/radstone_ppc7d.h b/arch/ppc/platforms/radstone_ppc7d.h +#define PPC7D_MV64360_REG_BASE 0xfef0 You don't really need this b/c CONFIG_MV64X60_NEW_BASE should have the correct value.
[PATCH] PPC32: mv64360_pic non-zero irq base
Add support for non-zero irq base to mv64360_pic code. - Fix mv64360 pic code to handle non-zero mv64x60_irq_base - Cleanup mv64360 entries in /proc/interrupts Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: mv64360_pic.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050228/838f3457/attachment.txt
[PATCH] PPC32: Add GPIO/IRQ definitions for mv64x60 parts
Add mv64x60 GPP IO pin/IRQ register definitions Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: mv64x60_gpp_defs.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050228/36a41486/attachment.txt
PATCH: mv64x60: add watchdog support
James Chapman wrote: Wim, Please review this patch that adds mv64x60 watchdog support. Signed-off-by: James Chapman jchapman at katalix.com I'm cc'ing linuxppc-embedded to get critical review from developers who are more likely to know this chip. The Marvell mv64x60 chips are found on ppc and mips boards. /james FWIW, this looks fine to me. Mark
[PATCH] PPC32: Add GPIO/IRQ definitions for mv64x60 parts
Add mv64x60 GPP IO pin/IRQ register definitions Signed-off-by: James Chapman jchapman at katalix.com Signed-off-by: Mark A. Greer mgreer at mvista.com -- next part -- An embedded and charset-unspecified text was scrubbed... Name: mv64x60_gpp_defs.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050228/c478ead6/attachment.txt
[PATCH 2.6.11-rc4] ppc: add support for Radstone ppc7d boards
Hi James, All-in-all, this seems good but I have a few comments/questions. Mark -- James Chapman wrote: Add support for Radstone PPC7D PPC boards. Signed-off-by: James Chapman jchapman at katalix.com The Radstone PPC7D is a rugged ppc7447A VME card with Marvell Discovery-II dual GigE, dual PCI/PCI-X PMC sites, 4 UARTs, 2 high speed serial ports, USB and optional SCSI / VGA. diff -Nru a/arch/ppc/platforms/radstone_ppc7d.c b/arch/ppc/platforms/radstone_ppc7d.c +void __init ppc7d_setup_peripherals(void) + val32 = mv64x60_read(bh, MV64x60_PCI1_PCI_DECODE_CNTL); + val32 = ~(1 3); + mv64x60_write(bh, MV64x60_PCI1_PCI_DECODE_CNTL, val32); Bit 3 is already cleared by the core code. + /* Setup P2P for PCI#0 */ + val32 = mv64x60_read(bh, MV64x60_PCI0_P2P_CONFIG); + val32 = ~(0x00ff); + val32 |= ((bh.hose_a-first_busno 0xff) 16); etc. Do you really use the P2P bridge? Unless I missed something, I think it remains disabled. You shouldn't need it unless you have PCI devices on one hose directly accessing PCI devices on the other hose. The P2P stuff seems complicated unnecessary.
[PATCH 2.6.11-rc4] ppc: add support for Radstone ppc7d boards
James Chapman wrote: Mark A. Greer wrote: + /* Setup P2P for PCI#0 */ + val32 = mv64x60_read(bh, MV64x60_PCI0_P2P_CONFIG); + val32 = ~(0x00ff); + val32 |= ((bh.hose_a-first_busno 0xff) 16); etc. Do you really use the P2P bridge? Unless I missed something, I think it remains disabled. You shouldn't need it unless you have PCI devices on one hose directly accessing PCI devices on the other hose. The P2P stuff seems complicated unnecessary. Thinking about this more, what is really being configured here is the primary bus number before the scan is performed. If the bus number doesn't match the hose's primary bus number, the mv64x60 will issue Type 2 PCI config cycles instead of Type 1 and the scan will fail. This board has an on-board PCI-X bridge and potentially other PCI bridges on PMC cards. I found that I had to init the P2P_CONFIG primary bus value before scan in order for the PCI scan of bus 2 to work (hose_a has PCI busses 0 and 1). I think the writes to the P2P config registers are necessary. mv64x60_set_bus() is supposed to do that. Try doing your bus numbering setup/bus scanning like what's in ev64260.c. If there is still a deficiency, then we should fix up that routine. Mark
linuxppc tree with mv64xxx included?
Ron Bianco wrote: I'm trying to locate the correct bitkeeper or other URL to get access to a linux 2.5 or 2.6 tree that includes the support for the marvell mv64xxx series chips. I've examined the emails in this list regarding related patches for clues, but am still confused. Tried bk://ppc.bkbits.net/linuxppc-2.5, but there is no marvell code. Its in there along with a couple boards that use it. Note that the core code is in arch/ppc/syslib in 2.6. The name of the main core file is mv64x60.c. There are also several patches sitting in the mm tree waiting to go in. One of those patches adds an i2c driver. Mark
[PATCH][PPC32] mv64x60 updates
Sven Luther wrote: On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote: Hi Andrew. This patch briges the mv64x60 related code up to the latest that I have. Mark, ... I am a bit bewildered by what you are doing here. How does this mv64x60 code relate to the mv643xx_eth driver from the mips folk ? Friendly, Sven Luther Hi Sven. The mv64x60 is a Marvell host bridge with some I/O ctlrs including 3 enet cltrs. There are virtually identical versions for MIPS (called mv64x4x) and PPC (called mv64x6x). The mv643xx_eth driver was originally written by the MIPS folks, as you note, but Dale Farnsworth has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's patch(es) have been accepted and are queued to go into the mainline tree at some point. Did I answer your question? Mark
[PATCH][PPC32] mv64x60 updates
Sven Luther wrote: On Thu, Feb 24, 2005 at 08:28:56AM -0700, Mark A. Greer wrote: Sven Luther wrote: On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote: has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's Ok, so the code in question is in addition to the existing driver from the mips guys and works with it ? If the code in question == the enet related code in mv64x60.c then yes. However, the only enet related code in mv64x60 is platform_data setup and setup of the bridge's windows between the enet ctlr and system memory. I had the impression that it was a separate driver development or something. Nope. patch(es) have been accepted and are queued to go into the mainline tree at some point. Ok. Do you know if Dale's patches are available separatedly while they are not yet in mainline, so Nicolas Det can work on them and make sure they also work on the Pegasos board, which is not an embedded board but from the chrp lineage. Nicolas already did some mv643xx ethernet driver work last summer, but apparently had trouble integrating this in the mainline kernel, and it seems his work has now been redone by Dale or something. Do you know who the right person to communicate with about this would be ? The MIPS folk didn't reply to any of our mails about this subject. Nicolas has emailed me off-line and he Dale are now in contact. FYI, this is part of the email from Dale to Nicolas: Please see bk://dfarnsworth at bkbits.net/linux-2.5-mv643xx-enet. Most of this is in netdev and mm, and on track to go into linux-2.5. Did I answer your question? I think so. I was just surprised to see this 64x6x work go to arch/ppc instead to drivers/net. There is no driver functionality in arch/ppc. There is only platform_data setup which is used by the driver and the ensuring the bridge's windows between the enet ctlr and system memory are set up correctly. Mark
[PATCH][PPC32] Incorrect #define in include/asm-ppc/cpm2.h
This patch fixes the incorrect definition of a macro that sets the transmit parity to even on a cpm uart device. Please apply (once 2.6.12 is open). Thanks. Signed-off-by: Mark A. Greer mgreer at mista.com -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: cpm2_1.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050223/651f8376/attachment.txt
linux-2.5-marvell tree deletion
Mark A. Greer wrote: Dale Farnsworth has moved the mv64[34]60 enet driver to bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet and all of the code that I've worked on is either in linux-2.5 or on a queue to go in so this tree should evaporate. If you have an issue with this please let me know before the morning of Wednesday, Feb 23, 2005; otherwise, I will delete it on Wednesday. This tree is now gone. Mark
kernel with marvell 64360 support
Mark A. Greer wrote: Suresh Chandra Mannava wrote: Hi, We designed a power-pc 7410 board with galileo mv64360 bridge. We are interested in porting linux on to that board. Where can I download the linux kernel with 64360 (serial, ethernet, PCI etc) drivers. please provide the pointers for the same. You can get the latest code minus 3 patches and the enet driver from the latest linux-2.5 tree on bkbits.net/kernel.org. The 3 patches are in the linuxppc-embedded mail archive. AFAIK, the enet driver is queued to go into the mainline tree but I don't know when that'll happen. If you need it now, you can contact Dale Farnsworth dfarnsworth at mvista.com. I failed to mention that there is an i2c driver queued to go in at: http://archives.andrew.net.au/lm-sensors/msg29471.html Mark
mv64x60 patches for Radstone PPC7D - for review
Hi James. James Chapman wrote: Attached is a series of patches adding support for Radstone PPC7D boards and Marvell Discovery watchdog. PPC7D are rugged Marvell Discovery boards with PPC7447A CPUs, dual GigE, dual PMC and optional SCSI, VGA. Signed-off-by: James Chapman jchapman at katalix.com The patches are split into separate pieces to aid review. Most patches are generic for mv64x60 boards and could be applied separately. Patch p9, however, requires all other patches. From now on, please make a separate email per patch. That way the email threads/patch discussions are easier to track. Patch p2 just makes fields in /proc/interrupts line up so it is optional. p1 - fix mv64360_pic_irq_offset bugs when non-zero While you're in there, would you make a #define for the IRQ 28 in include/asm-ppc/mv64x60_defs.h. Otherwise, it looks good. p2 - cleanup formatting of mv64360 entries in /proc/interrupts [optional] Looks fine but you may as well combine w/ patch p1. p3 - add pciauto_ignore_device() hook to allow platforms to ignore specific devices in pciauto_bus_scan(). Should this hook be in ppc_md instead? Is there a reason ppc_md.pci_exclude_device doesn't work? p4 - add GPP IO pin/IRQ register definitions Looks fine. p5 - add extern i8259_pic_irq_offset p6 - add 7447A and 7457 CPU definitions Looks okay to me but these should probably be posted to linuxppc-dev. p7 - add mv64x60 watchdog support I think it would be better to use platform_data to pass in the duration/timeout value and not a config option. Other than that, it looks okay to me but I didn't go over it in detail. When you separate this patch into its own email, you should send it to whoever looks after the watchdog drivers, cc the appropriate mailing list, and lmkl and/or linuxppc-embedded. p8 - add mv64x60_setclr_bits() which can be used to set and clear bits of a mv64x60 register with a single chip register write. Is this really necessary? I have learned that many in the community really hate little routines like this. I have a todo item to get rid of the _set/clr_bits routines and replace them explicit code. p9 - add Radstone PPC7D board support I didn't go through this in great detail but I do have a few comments: +++ linux-2.6/arch/ppc/boot/simple/misc-radstone_ppc7d.c +void __attribute__ ((weak)) mv64x60_board_init(void) Don't make this weak, there is one alread defined as weak that you're replacing. + /* Map 0xe000-0x early because we need access to SRAM +* and the ISA memory space (for serial port) here. You mean for accessing the serial port while in the bootwrapper, right? The firmware doesn't put anything out the serial port? If so, there is likely a mapping alread setup for you to use, no? +++ linux-2.6/arch/ppc/Kconfig Why bother with RADSTONE_DEBUG? Plus I'm told that pr_debug() is the preferred method for this. Why a separate CONFIG_RADSTONE and CONFIG_RADSTONE_PPC7C? You never use CONFIG_RADSTONE. +++ linux-2.6/arch/ppc/platforms/radstone_ppc7d.c It looks like you only really use the 8250 uart. Is that correct? If so, get rid of the MPSC stuff since its only clutter. static void __init ppc7d_early_serial_map(void) I don't think you need this as long as you have your STD_SERIAL_PORT_DFNS setup correctly. TODC_ALLOC(); It doesn't look like you need this since you don't actually use a time-of-day/realtime clock. DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1533, ppc7d_fixup_ali1535); You have a lot of pci fixups. Are they all necessary? I noticed a quirk already implemented for the 1533... General note: you have a lot of lines that wrap in an 80 column window. I guess its a personal preference but I find it hard to read. Would you mind breaking them into separate lines? Mark
mv64x60 patches for Radstone PPC7D - for review
Mark A. Greer wrote: Hi James. James Chapman wrote: p5 - add extern i8259_pic_irq_offset Oops, hit send to soon. This looks okay but in your platform file, you never set it anyway so you don't need to access it in there. Mark
[PATCH} include/asm-ppc/cpu2.h typo
Hi, This bug/typo was pointed out to me. I looked at the 8260 8272 manuals and it should be 0x0002 in both cases. I don't work with the 82[67]x processors but it looks like this would have quickly bit anyone trying even parity on their serial line. Nobody uses even parity on those platforms? Is there something I don't know (and the manual isn't telling me)? Mark -- next part -- An embedded and charset-unspecified text was scrubbed... Name: cpm2_1.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050222/c3d0119c/attachment.txt
