Re: yaboot: text mode or graphics mode?
sumedh tirodkar wrote: I just found out that openfirmware boots into graphics mode(non-text mode). Now i wish to switch back to text mode. how do i do this? Unfortunately unless you are running some kind of yaboot-accessible or firmware-accessible x86 BIOS emulation, this isn't possible. -- Matt ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SRAM
Is it memory mapped somewhere? If it is you can emulate an MTD using the "slram" driver. Then you can just use whatever you like on top - JFFS2 or something that thinks it's going to be on flash or something, ext2 if you're nuts. But, seriously, with slram you *can* go nuts. On Sun, Nov 23, 2008 at 12:37 PM, Thomas Johnson <[EMAIL PROTECTED]>wrote: > We have a new PPC based board which includes some SRAM (actually Everspin > MRAM). > > I can't work out the best way to mount this device or what filing system to > run on it, any advice ? > > Thanks > > TJ > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC512x SPI very high cpu load
Matteo Fortini wrote: Hi, we're using the latest denx tree on an mpc512x, and we have a touchscreen on the spi which is talking at 100kHz. The polling frequency is 5ms and we transmit around 20 bytes per poll. If we keep the touchscreen pressed, cpu utilization goes to 70% for the spi task. This is quite strange, since I thought the mpc512x would be using DMA to feed the PSC FIFOs. If the SPI driver isn't using DMA then, it's not using DMA. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using Bestcomm API (DMA) on MPC5200b with Linux?
You know, Sylvain posted his patch the week after 2.6.23 was released so I guess it's a big fat no. However the original patchset or it (http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044301.html) should patch very easily. The last thing you'd want is to code a driver using BestComm right now, and then move to a new kernel later on in development and have to rewrite it from scratch. The Freescale API really is dead as a dodo. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Jon Smirl wrote: Was the new BestComm support in the 2.6.23.1 kernel he is using? On Thu, Oct 23, 2008 at 6:28 PM, Matt Sealey <[EMAIL PROTECTED]> wrote: You need to write a task that does the DMA operation you want; GenBD is actually pretty generic and lets you just copy from one place to another. The API is pretty simple; make sure genbd is compiled in, get the task structure using bcom_gen_bd_[tr]x_init, and then.. uhh.. this is where I always forget. There is a way to submit a buffer descriptor and have the engine basically perform that transfer. I think it's bcom_prepare_next_buffer and then bcom_submit_next_buffer. Actually I can't even FIND those functions in the Linux tree right now, but they have to be in there because the FEC driver uses them.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Dave Best wrote: I am trying to connect a FPGA/FIFO with my MPC5200b on a phytec PCM 030 board while running a 2.6.23.1 Linux. The Linux Kernel source contains an implementation for the Bestcomm API in the form of a driver for ethernet (fec) and ATA.(situated in the arch-powerpc/sysdev/bestcomm path) I tried to make use of it but i've run into some problems. So i tried to include the API in a module to utilize its functionality but no luck till now. Freescale supports the Bestcomm DMA API not on an OS level. So the problem is adopting this API into a Linux environment, which distinguishes between kernel space and user space while writing to the appropriate registers. Further information is very hard to find for such a common task as starting a DMA transfer. Dave ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using Bestcomm API (DMA) on MPC5200b with Linux?
You need to write a task that does the DMA operation you want; GenBD is actually pretty generic and lets you just copy from one place to another. The API is pretty simple; make sure genbd is compiled in, get the task structure using bcom_gen_bd_[tr]x_init, and then.. uhh.. this is where I always forget. There is a way to submit a buffer descriptor and have the engine basically perform that transfer. I think it's bcom_prepare_next_buffer and then bcom_submit_next_buffer. Actually I can't even FIND those functions in the Linux tree right now, but they have to be in there because the FEC driver uses them.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Dave Best wrote: I am trying to connect a FPGA/FIFO with my MPC5200b on a phytec PCM 030 board while running a 2.6.23.1 Linux. The Linux Kernel source contains an implementation for the Bestcomm API in the form of a driver for ethernet (fec) and ATA.(situated in the arch-powerpc/sysdev/bestcomm path) I tried to make use of it but i've run into some problems. So i tried to include the API in a module to utilize its functionality but no luck till now. Freescale supports the Bestcomm DMA API not on an OS level. So the problem is adopting this API into a Linux environment, which distinguishes between kernel space and user space while writing to the appropriate registers. Further information is very hard to find for such a common task as starting a DMA transfer. Dave ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Scott Wood wrote: BTW, it's actually simpler than I originally described (I had implemented this years ago in the TimeSys kernel for x86 and some other arches that already use FP or similar resources for memcpy, but the memory was a little fuzzy); the FP restore code doesn't need to test anything, it always restores from the regular spot. The kernel code wishing to use FP saves the user context in an alternate save area (it could even be on the stack, allowing atomic context to use it as well, if it's not too large), and restores it when it's done. Sure, it's simple, the problem is that VRSAVE isn't maintained in the kernel, which means for AltiVec context switches you need to save and restore 32 128-bit registers every time. And that takes a LONG time.. Just imagine if you did a ~512 byte memcpy, you could guarantee that it would take twice as long as it should! There are ways around it, like assembly and fixed registers, and saving the ones you use (this is the sort of thing gcc does for you usually, but you can do it by hand just as well) and restoring the ones you trashed afterwards, but that makes code messier and less readable. Not insurmountable problems, but it makes using AltiVec harder. You would have to really justify a speed increase. I think you could get that on cryptography functions easily. For page zero/copying, I think you would also get the increase to outweigh the prologue/epilogue required and also the loss of preemption. TCP/IP copy with checksum? Probably absolutely definitely.. Straight memcpy? I am not so sure. Like I said I am far more worried about how you'd get a reasonable benchmark out of it. Profiling kernels is a messy business.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Scott Wood wrote: Benjamin Herrenschmidt wrote: Yuck. Hmm? It's simple and achieves the desired result (avoiding non-preemptible regions without unduly restricting the ability to extract performance from the hardware). Would it be nicer to avoid FP/Altivec in the kernel altogether? Sure. If the benchmarking says that we're better off with it, though, then so be it. There should definitely be a nice API for an in-kernel AltiVec context save/restore. When preemption happens doesn't it do some equivalent of the userspace context switch? Why can't the preemption system take care of it? At worst case you make the worst case latency bigger, but at best case you gain performance across the board. One thing which is worrying me is that now that Ben has thrown down the gauntlet (note, I'm not going to be coding a line, but I know a man who can :) how on earth do we benchmark the differences here? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Benjamin Herrenschmidt wrote: On Thu, 2008-10-09 at 10:37 -0500, Matt Sealey wrote: Ahem, but nobody here wants AltiVec in the kernel do they? It depends. We do use altivec in the kernel for example for RAID accelerations. The reason where we require a -real-good- reason to do it is simply because of the drawbacks. The cost of enabling altivec in the kernel can be high (especially if the user is using it) and it's not context switched for kernel code (just like the FPU) for obvious performance reasons. Thus any use of altivec in the kernel must be done within non-preemptible sections, which can cause higher latencies in preemptible kernels. Would the examples (page copy, page clear) be an okay place to do it? These sections can't be preempted anyway (right?), and it's noted that doing it with AltiVec is a tad faster than using MMU tricks or standard copies? In Scott's case, while "optimizing memcpy for 48byte blocks" was a joke, this is 3 load/stores in AltiVec, which as long as every SKB is 16 byte aligned (is there any reason why it would not be? :) skb_clone might not be something you want to dump AltiVec into and would make a mess if an skb got extended somehow, but the principle is outlined in a very good document from a very long time ago; http://www.motorola.com.cn/semiconductors/sndf/conference/PDF/AH1109.pdf I think a lot of it still holds true as long as you really don't care about preemption under these circumstances (where network throughput is more important, and where AltiVec actually *reduces* CPU time, the overhead of disabling preemption is lower anyway). You could say the same about the RAID functions - I bet LatencyTOP has a field day when you're using RAID5 AltiVec. But if you're more concerned about fast disk access, would you really care (especially since the algorithm is automatically selected on boot, you've not much chance of having any choice in the matter anyway)? Granted it also doesn't help Scott one bit. Sorry :D -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Paul Mackerras wrote: Dominik Bozek writes: Actually I made couple of other tests on that mpc8313. Most of them are to ugly to publish them, but... My problem is that I have to boost the gigabit interface on the mpc8313. I made simple substitution and __copy_tofrom_user was used instead of memcpy. I know, it's wrong, but I speedup that way the network interface for about 10%. Very interesting. Can you work out where memcpy is being called on the network data? I wouldn't have expected that. It probably is somewhere.. through some weird and wonderful code path that needs some serious digging to find. At least in 2.4 memcpy was used and optimizing it (see Freescale's libmotovec benchmarks) did produce a sizable performance improvement. That, and offloading TCP checksumming to AltiVec helped a lot. No help at all on an 8313 but, relevant anyway. Since then zero copy networking and other fancy things like the DMA engine API (for intel ioat at least but also there is fsl dma support) there's less to actually optimize now so you're less likely to see the same benefits. All these got into mainline because it's essential to have this kind of architecture to get reasonable speeds out of >gigabit network links. There is actually no strong reason not to use __copy_tofrom_user as memcpy, in fact, as long as we are sure that source and destination are both cacheable. I do think there is probably a good benefit in doing things like zeroing pages in AltiVec and copying entire pages with AltiVec (for instance when copy-on-write happens in an application) - NetBSD and QNX implement at least this because it's faster than using the cache management and works fine on uncacheable pages too (also since you're always aligned to a page, zeroing 4kb aligned to a 4kb boundary - or whatever your page size happens to be, the number of errors that can occur are absolutely tiny and performance can go through the roof). Ahem, but nobody here wants AltiVec in the kernel do they? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Quick question about dts
Marco Stornelli wrote: M. Warner Losh ha scritto: I have a .dts file that works with 2.6.18 (MV Pro 5.0). I encode it directly into the kernel image. However, when I try to use it with my 2.6.23, 2.6.24 or 2.6.25 kernel trees, it doesn't work at all. In the MV Pro 5.0 kernel, I hacked the startup sequence to store a pointer to this blob in r3 so that it is moved in. I've done something similar in -current (for reasons that are too complicated to really explain well, we can't do this via the normal boot loader mechanisms). The dtc complains that the interrupt-controller property is obsolete on the chosen device. Does any documentation exist for how dts has evolved? I'd like to forward port what I have without examining the .dts files from both versions and guessing... Check out the kernel documentation booting-without-of.txt of your version. Better yet, go get the ePAPR specification from Power.org? It's easier to read :) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C and CAN bus on MPC5200B device tree
Hi guys, I know the I2C stuff is up in the air (I cannot pinpoint the documentation for it) and have not found any CAN bus documentation for device trees. I want to update the firmware tree to add these but, am basically looking for those docs, or someone to go over a few points.. is there some kind of tree standard I should be looking at, or some patch I missed which has a driver which implements something that looks at a compatible tree? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: use of fsl, in lite5200b.dts in git current
Jon Loeliger wrote: > Matt Sealey wrote: > >> this is a ridiculous >> amount of specificity in a device tree, > > Except that some of that information _is_ specified elsewhere in other > properties. Speed, for example. Which is fine.. >> and it also does not match the >> datasheet (MPC7448 is the name of the chip). > > Because the data sheets are _s_ reliable. :-) Be careful or I'll start looking for the datasheets with your name on it :) >> Indeed, so.. at some point we should all sit down and hammer out the >> major issues in describing something like the MPC5121E because right >> now Genesi has a vested interest in that. > > You understand that _that_ is being worked on as we, er, speak? Yeah I've seen it, recognise your name from the top of the device tree definition, and I must say, it's not the most ideal... >> If we could all agree on how it should be mapped out, with an example >> tree which shows *every damn thing available* so platform developers >> can pick and choose and OF developers can use it as a reference, it >> would make a much happier process. > > Right. It's being nailed down, but it is a slow, community process... Why? Freescale's chip, open standards, just design it right, and tell the community they should be conforming with it. The slow community process would have had the Efika come out this month instead of this time last year if we had waited to fix the device tree to "the right way to do it". The device tree, hardware description in general, is down to the silicon vendor and ODM, and should provide description of the hardware which allows any driver (not just the ones in the BSP) to get enough information from the tree where necessary. I don't see that in the MPC5200 tree and I still don't see it in the examples of the MPC5121E tree. I also note the few users of the MPC5121E that there are outside of Freescale, aren't involved (ahem) in this process unless they join these mailing lists. You can't discuss anything on here with that chip, it's locked down by NDA, release date tenuous, feature state tenuous.. documentation is in draft/preliminary and nobody else has it. >> By the way while I was poking around the tree today I noticed that >> there is a PCI errata fixup handled by a Kconfig in there. Why? > > Happens occasionally. And other places as well. > >> Surely >> this is something you check the PVR/SVR for and switch on that for >> a runtime solution, > > That's not always fine-grained enough to base a decision on it. It is in this case isn't it? The errata states that it only appears on that particular revision. >> and not trick users with the possibility of >> forgetting to enable some obscure "PCI errata fix" configuration >> item? (CONFIG_PPC_MPC5200_BUGFIX) > > It should be in the defconfig. :-) It shouldn't be a configuration option at all in my opinion :) You either fix the bug or you don't, if you have to fix it in a generic, multi-chip (5200/5200B) API like the PCI stuff, it should be handled on a if/else basis. There's practically no benefit to having it as a configuration option and being able to compile it out, in fact.. it rather makes the whole presence of the fix more complicated (to support 5200 and 5200B you need to compile in the fix, and that means 5200B chips are implementing it when they don't need to - and you need to recompile to fix it). -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: use of fsl, in lite5200b.dts in git current
Jon Smirl wrote: > On 11/8/07, Scott Wood <[EMAIL PROTECTED]> wrote: > >> I think you may be placing too much faith in the vendors. >> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-) > > There has to be more to the part number for the Freescale powerpc chip > than just 7400. 7400 is a shorthand name, it is not an orderable part number. The orderable part numbers add 3 or 4 characters to the front and about 8 after. There is a difference between MPC7400 and PPC7400, and the low voltage versions, and the different clock speeds. Orderable part number for a recent G4 might be PPC7448B1333NL - this is a ridiculous amount of specificity in a device tree, and it also does not match the datasheet (MPC7448 is the name of the chip). What people usually do is use what's in the datasheet. >> If you want to argue that the "MPC" part differentiates them, that's >> just a less readable and more obsolete vendor prefix. > > The MPC is what is printed on the chip. fsl is not printed there. MPC > is part of the orderable part number. Not all of them *ahem* :) Like I said, trust the datasheet, not the number on the chip. >> Vendor prefixes on properties are useful in that it might not mean >> exactly the same thing as a similar property that gets standardized >> later on. >> >>> That's life in the Linux world, no backwards binary compatibility. >> There's a huge difference between compatibility of kernel interfaces and >> compatibility of interfaces between the kernel and something else -- >> whether it be userspace or firmware. Indeed, so.. at some point we should all sit down and hammer out the major issues in describing something like the MPC5121E because right now Genesi has a vested interest in that. Thanks Grant for your discussion on it, I agree of course :) One thing we don't want to go through again is the complaints we got because we named the chip node "/builtin" rather than "/soc". My fixup script is still handling that mess because you guys refused to accept it (and some drivers were coded to map from the MBAR contained in device_type soc's reg property rather than find a real device). If we could all agree on how it should be mapped out, with an example tree which shows *every damn thing available* so platform developers can pick and choose and OF developers can use it as a reference, it would make a much happier process. And then we can fix up the Efika to fit some definition of the new MPC5200 tree too. By the way while I was poking around the tree today I noticed that there is a PCI errata fixup handled by a Kconfig in there. Why? Surely this is something you check the PVR/SVR for and switch on that for a runtime solution, and not trick users with the possibility of forgetting to enable some obscure "PCI errata fix" configuration item? (CONFIG_PPC_MPC5200_BUGFIX) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: use of fsl, in lite5200b.dts in git current
Jon Smirl wrote: > I'm not in favor of all these fsl prefixes. These chip families do get > sold. What would we have done with intel,pxa320 all over the place > when they sold it to marvell? mass changes to marvell,pxa320? That's the idea, and there'd be a compatible entry for intel,pxa320. Actually the spec says you should use the stock ticker (IBM, FSL, INTC, JAVA, MRVL) if they have one and if not, the company name in lower case. Freescale are a funny one because they used to have a stock ticker as MOT and then FSL but now they're privately owned, so it's gonna have to be lower case :] It's just to seperate out the fact that sometimes you get chips with very similar or identical names, or to mark out vendor-specific functionality. fsl,has-wdt differs from has-wdt ideally because Freescale watchdog timers aren't the same as other watchdog timers - the term is pretty pliable, Freescale's GPT on the MPC52xx isn't always a watchdog (it can be a normal, non-watchdog timer too..) > The mpc/pxa parts numbers don't get changes when chip families get sold. There is a case that between selling chips, some of them get updated or bugfixed, and you can tell which one you have by the name. There has to be some standardisation on the first implementation of the device tree for the chip, otherwise the chopping and changing gets rather tedious. I'm sure you can see why we don't release firmware updates every time some Linux guy changes some lousy, hacky tree definition for yet another 6 times a year, until it finally stabilises and the product is usually discontinued anyway :D However in the current situation it just means you need to flash new FDT blobs to your U-Boots which are more clean, and keep your kernel in sync, because Linux only handles what it currently thinks is the standard. The real loser is the real Open Firmware implementation, but nobody seems to think about that, the device trees on OF devices get more cluttered.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: use of fsl, in lite5200b.dts in git current
Jon Smirl wrote: > Sometimes the fsl prefix is being used and sometimes it isn't. Look at > the two compatible strings. Which way is it going to be? Is > fsl,has-wdt right? fsl,has-wdt is right, at least since someone changed it. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: pata_mpc52xx - no interrupts when using bestcomm/dma?
Hi guys,
I'm not sure if this is a particularly PowerPC problem - more ATA -
but I am curious if we just got rid of the MWDMA and UDMA stuff from
this patch, would it still work in a sort of PIO mode with the
BestComm task being invoked at the right times?
All BestComm needs to do is marshall the data back and forth, since
the ATA portion is covered by errata and 'hidden' bugs you can't rely
on FIFO errors or the automatic handling anyway..
On that note, seeing as it seems to be easily possible to invoke
a BestComm task on something other than a FIFO (just needs two
physical address pointers), does anyone feel motivated to try and
make some kind of memory copy handler/task which can be invoked
in the case of some memory activity required? Or, perhaps, work
out the PCI DMA TX/RX stuff and what it could be used for (I
personally don't understand how PCI DMA isn't handled by the
PCI arbiter anyway.. doesn't this mean no PCI DMA is ever done on
MPC5200 platforms right now??)
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Domen Puncer wrote:
> Hi!
>
> I'm taking a stab at adding DMA support to pata_mpc52xx driver.
>
> It's based on patches from Freescale's ltib (old ide driver).
>
>
> The problem is that I can't seem to get any interrupts
> (not ata, not bestcomm task), when setting up MWDMA/UDMA mode.
>
> Ideas?
>
>
> My current patch:
>
> ---
> drivers/ata/pata_mpc52xx.c | 491
> +++--
> include/linux/libata.h |2
> 2 files changed, 477 insertions(+), 16 deletions(-)
>
> Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
> ===
> --- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
> +++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
> @@ -4,6 +4,7 @@
> * libata driver for the Freescale MPC52xx on-chip IDE interface
> *
> * Copyright (C) 2006 Sylvain Munaut <[EMAIL PROTECTED]>
> + * Copyright (C) 2005,2006 Freescale - Bernard Kuhn, John Rigby
> * Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
> *
> * This file is licensed under the terms of the GNU General Public License
> @@ -22,6 +23,8 @@
> #include
> #include
>
> +#include
> +#include
>
> #define DRV_NAME "mpc52xx_ata"
> #define DRV_VERSION "0.1.0ac2"
> @@ -31,6 +34,14 @@
> struct mpc52xx_ata_timings {
> u32 pio1;
> u32 pio2;
> + u32 mdma1;
> + u32 mdma2;
> + u32 udma1;
> + u32 udma2;
> + u32 udma3;
> + u32 udma4;
> + u32 udma5;
> + int using_udma;
> };
>
> struct mpc52xx_ata_priv {
> @@ -39,6 +50,12 @@ struct mpc52xx_ata_priv {
> int ata_irq;
> struct mpc52xx_ata_timings timings[2];
> int csel;
> +
> + /* dma stuff follows */
> + struct bcom_task * dmatsk;
> + const struct udmaspec * udmaspec;
> + const struct mdmaspec * mdmaspec;
> + int mpc52xx_ata_dma_last_write;
> };
>
>
> @@ -53,6 +70,102 @@ static const int ataspec_ta[5]= { 35
>
> #define CALC_CLKCYC(c,v) v)+(c)-1)/(c)))
>
> +/* ATAPI-4 MDMA specs (in clocks) */
> +struct mdmaspec {
> + u32 t0M[3];
> + u32 td[3];
> + u32 th[3];
> + u32 tj[3];
> + u32 tkw[3];
> + u32 tm[3];
> + u32 tn[3];
> +};
> +
> +//
> ---
> +
> +static const struct mdmaspec mdmaspec66 = {
> + {32, 10, 8},
> + {15, 6, 5},
> + {2, 1, 1},
> + {2, 1, 1},
> + {15, 4, 2},
> + {4, 2, 2},
> + {1, 1, 1}
> +};
> +
> +static const struct mdmaspec mdmaspec132 = {
> + {64, 20, 16},
> + {29, 11, 10},
> + {3, 2, 2},
> + {3, 1, 1},
> + {29, 7, 4},
> + {7, 4, 4},
> + {2, 1, 1}
> +};
> +
> +
> +/* ATAPI-4 UDMA specs (in clocks) */
> +struct udmaspec {
> + u32 tcyc[6];
> + u32 t2cyc[6];
> + u32 tds[6];
> + u32 tdh[6];
> + u32 tdvs[6];
> + u32 tdvh[6];
> + u32 tfs_min[6];
> + u32 tli_max[6];
> + u32 tmli[6];
> + u32 taz[6];
> + u32 tzah[6];
> + u32 tenv_min[6];
> + u32 tsr[6];
> + u32 trfs[6];
> + u32 trp[6];
> + u32 tack[6];
> + u32 tss[6];
> +};
> +
> +static const struct udmaspec udmaspec66 = {
> + { 8, 5, 4, 3, 2, 2},
> + {16,
Re: Efika, initrd and current kernel
How did you attach the initrd to the kernel? Compiled in using the initramfs feature, or did you use mkvmlinuz (debian/ubuntu) or mkzImage (suse) or have genkernel build it (--genzimage) on Gentoo? It looks like you're trying to boot Gentoo from the boot line.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Jon Smirl wrote: > On 9/30/07, Sven Luther <[EMAIL PROTECTED]> wrote: >> On Sun, Sep 30, 2007 at 10:09:47AM -0400, Jon Smirl wrote: >>> On 9/30/07, Matt Sealey <[EMAIL PROTECTED]> wrote: >>>> How did you build the kernel? >>> I attached the .config >>> Am I supposed to have both chrp and efika selected? >> I think so, yes. > > I have then both selected. > > I'm sure it is something simple about how I have my kernel configured > wrong but I can't figure out what it is. I have BLK_INITRD turned on. > I can trace in the initrd code and see that it is exiting because > strat_initrd is not set. start_initrd is set in the platform specfic > code which I haven't figured out yet. > > >> Friendly, >> >> Sven Luther >> > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Efika, initrd and current kernel
How did you build the kernel? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Jon Smirl wrote: > I'm trying to boot a current kernel on the Efika like this: > boot hd:0 efika init=/linuxrc root=/dev/ram0 looptype=squashfs > loop=/squashfs.img cdroot > > It is not finding the initrd. > I added some printks and start_initrd is not getting set. > > The 2.6.19 gentoo kernel described here boots and finds the same initrd > http://gentoo-wiki.com/Efika > > Something is missing in the hand off from the OF to the kernel code. > I'm poking around in powerpc/kernel/prom_init.c > looking for answers. > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
> On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
>> David Gibson wrote:
>>> Uh... no... this is in the bootwrapper, long before ppc_md even
>>> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
>>> immediately before main().
>> Oh *THAT* platform init.
>>
>> So I could just drop a
>>
>> } else {
>> dt_find_initrd();
>> }
>>
>> .. at the end and nobody would be too disgusted or have any problems?
>
> Err.. at the end of what? Each platform has it's own version of
> platform_init().
arch/powerpc/boot/of.c since it's not really relevant to me for non-OF
platforms?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote:
> Uh... no... this is in the bootwrapper, long before ppc_md even
> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
David Gibson wrote: > On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote: >> Damn, I should use patchwork more efficiently; >> >> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 >> >> Does anyone have any suggestion on the best way to integrate this so that >> it "just works" on OF platforms? It seems only to be usable way too late >> in boot to work, this code would have to be called in boot/main.c which seems >> relatively.. impossible to achieve.. or called in some specialised platform >> init code.. > > It would have to be called from platform_init(). If called in main() > it would clobber any other platform-specific initialization of the > initrd parameters in loader_info. So just to get this straight.. platform_init would be the function called from md.init or would be better at md.setup_arch? My goal right now is get something for CHRP (Pegasos) and Efika and try not to cause problems for anything else, but also really try not to clutter the thing with config checks, platform checks etc. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OF /chosen/initrd,* variables - patch, official?
Damn, I should use patchwork more efficiently; http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168 Does anyone have any suggestion on the best way to integrate this so that it "just works" on OF platforms? It seems only to be usable way too late in boot to work, this code would have to be called in boot/main.c which seems relatively.. impossible to achieve.. or called in some specialised platform init code.. I hacked up a patch initially before I saw Milton's work and did it all in main.c (and did the same to mkvmlinuz..) and it seemed to work okay there. I'm really curious as to the status and usefulness of this here.. :( -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Matt Sealey wrote: > Hi guys, > > Just a query here, there was a patch for /chosen/initrd,start and initrd,end > variables gained from firmware or so, which allowed booting without getting > those values into r3/r4, does anyone know the maintainer/author of that > patch? > > Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine > it's fairly useful (at least it is to me).. > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OF /chosen/initrd,* variables - patch, official?
Hi guys, Just a query here, there was a patch for /chosen/initrd,start and initrd,end variables gained from firmware or so, which allowed booting without getting those values into r3/r4, does anyone know the maintainer/author of that patch? Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine it's fairly useful (at least it is to me).. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC PATCH v0.1] net driver: mpc52xx fec
Are you sure this is correct for the Efika? The MPC5200B manual makes a decent distinction between MII operation and straight MDIO? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Domen Puncer wrote: > On 20/08/07 10:31 +0200, Domen Puncer wrote: >> On 19/08/07 16:39 +0100, Matt Sealey wrote: >>> Domen, >>> >>> Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter >>> Linux with more fixups. The Efika PHY isn't going to change to something >>> else and it's a bog standard no-frills MII PHY anyway. >> Fine with me, but I'm worried people won't update nvramrc. >> > ... >> But I have a problem with it, possibly due to my not-knowledge of Forth. >> Compatible keep getting set to: >> compatible"/builtin/etherne" > > I missed the encode-string. > > Matt, can you please add attached Forth script to Efika updates. > > > Domen ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC PATCH v0.1] net driver: mpc52xx fec
Domen,
Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
Linux with more fixups. The Efika PHY isn't going to change to something
else and it's a bog standard no-frills MII PHY anyway.
I think it is a distinction that the OF docs forgot to make, that the
client interface is *all those Forth words* and not just the 6 or 7
distinct, special callable functions like claim (they exist because of
the simple fact that claiming memory shouldn't involve claiming memory
and such other paradoxes) and call-method. Call-method is a perfectly
valid way of doing things.
But, I'd really recommend you please think of a different way.. if you
want to spec out a device tree entry for it I'll update my script which
I am probably going to stick as an 'official' Genesi support file in
the next week.
If you insist on using prom_init and fixups, yaboot has the best
examples of call-method and interpret, both readable and fairly
easily available.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Domen Puncer wrote:
> Hi!
>
> On 10/08/07 11:51 +0200, Domen Puncer wrote:
>> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> ===
>> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
>> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> +[EMAIL PROTECTED] {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +device_type = "mdio";
>> +compatible = "mpc5200b-fec-phy";
>> +reg = <3000 400>; // fec range, since we need to
>> setup fec interrupts
>> +interrupts = <2 5 0>; // these are for "mii command
>> finished", not link changes & co.
>> +interrupt-parent = <&mpc5200_pic>;
>> +
>> +phy0:[EMAIL PROTECTED] {
>> +device_type = "ethernet-phy";
>> +reg = <0>;
>> +};
>> };
>
> I am struggling with this part on Efika.
> I would like to add this to the device tree from
> fixup_device_tree_efika() (arch/powerpc/kernel/prom_init.c).
>
> AFAICS client-services doesn't offer anything like new-device,
> so I guess "interpret" or "call-method" will have to be used.
>
> I have read some docs, but I'm still wandering in the dark.
> Can I please get an example?
> Pretty please with a cherry on top?
>
>
> Domen
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 and Bestcomm
The current (2.6.22) patchset for the Efika is being held here for the moment; http://dev.gentoo.org/~nixnut/efika/ That's everything you 'really need' and it's probably the same as this patch list. However practically none of it is mainline-worthy at the moment, Sylvain has detailed too many things he thinks is wrong with it. I'm having a go with the new ethernet driver patch right now (a customer asked me for a prebuilt kernel..) so I can get on with testing that. The most important ones for rewrites besides that are the AC97 driver (which is a little.. sparse) and actually using the ATA task. I'll put in a decent request here for any work on this subject to please at least attempt to retrieve the tasks from the Efika firmware rather than replacing them in Linux gratuituously. I understand this doesn't help the Lite5200 guys.. but.. pretty please with a cherry on top? :] -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Jon Smirl wrote: > Another series is being posted to the Efika boards. > > 0001-powerpc-exports-rheap-symbol-to-modules.patch > 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch > 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch > 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch > 0005-powerpc-BestcComm-ATA-task-support.patch > 0006-powerpc-BestcComm-FEC-task-support.patch > 0007-powerpc-BestcComm-GenBD-task-support.patch > 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch > 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch > 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch > 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch > 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch > 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch > 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch > 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch > 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch > 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch > 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch > 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch > 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch > 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch > 0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch > 0082-powerpc-pata_mpc52xx-suspend.patch > ___ 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
Isn't the ethernet the same on the 64260, 64360, 64460? There's definitely a driver for 6436x and above.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ThomasB wrote: > Hi all, > I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board. > My Linux runs completely except for Ethernet. I don't find any Ethernet > driver for my bridge. Do you know if there is an Ethernet driver for the > Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 > ethernet driver in the kernel 2.4.34 for MIPS processor, will it be > possible to port it in a 2.6 kernel? > Thanks for you help. > > > -- > ThomasB > http://psyphi.zeblog.com/ <http://psyphi.zeblog.com/> > > > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mem-2-Mem DMA - Generalized API
Clifford Wolf wrote: > Hi, > > However, i don't think that implementing stuff like memset() in a dma > controller is any good because that would just flood the memory bus which > would then block in 99% of all cases the cpu until the dma is finished. > > It would however cost less power than doing that in the CPU. ;-) At least while the DMA transfer is happening, you could preempt to some other task. Would it flood the memory bus? When a DMA transfer happens would it really do it in such a way that it would stall the CPU on a memory access far more than it would usually? I think it would have to be extremely badly designed to be even ABLE to do that, or at least, you'd be doing some incredibly unwise things to be able to flood it like that. >> Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise >> it (it should be possible) or simply add to it, or if making a powerpc >> specific dma engine abstraction would be an easier idea. > > I don't think that this would actually be powerpc specific in any way. But > since such general purpose dma controllers are more common in embedded > hardware this still seams to be the right place to discuss the issue. I meant powerpc platform (as in ARCH=powerpc) specific. Rather than dropping it in the global drivers, just keep it as a library for powerpc. Everyone else can get it later with a move into the full tree. As long as the headers have common, easy to get to names that do not conflict with anything preexisting, it would not affect anything. Taking IOAT as an example and fixing it's weirdness would be a better start than making a whole new API, but I think doing development *WITH* IOAT and potentially trashing all.. umm.. 4 users, and the weird Linux kernel tripling of development cost when heavily updating an actively maintained subsystem that everyone else wants to touch, that would be detrimental. We don't want to break Intel and we don't want to be tracking Intel's patches or having extra weirdness break in (or for the number of users of that DMA system to explode underneath New DMA Development) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mem-2-Mem DMA - Generalized API
Clemens Koller wrote: > Hello, Matt! > >> There is so much you can do with most SoC DMA controllers, and it's not >> even limited to PowerPC (most ARM/XScale SoCs have very capable devices >> inside too). I can only imagine that nobody got excited over IOAT because >> the entire programming interface stinks of "offloading gigabit ethernet" >> and not much else. > > The main question remains: Is it possible to have a flexible cross platform > DMA API which handles even complex requests and does scheduling, > prioritizing, queuing, locking, (re-)building/caching of SG lists... > automagically. I would think so. I think there is a fairly generic example in many parts of the Linux kernel. Dare I say the Via Unichrome AGP subsystem? And a bunch of the ARM/OMAP platforms..? A lot of the code is even identical, I wonder why it isn't some library rather than platform drivers. > Filling memory with zero is also a simple task for a DMA engine. > (Thinking about malloc() and memset()) Also xor and logical operations, byte swapping huge chunks of data, that kind of thing. Most DMA engines in SoCs have cute features like that. I think BestComm can even calculate CRCs for IP packets. > The problem is IMHO similar to video acceleration. Within the > Xorg's XAA/EXA/whatever framework, the drivers accelerate certain > calls if the hardware has the capability to do so. Other calls fall back > to some default non accelerated memcpy() & friends. > > Sounds like a lot of fun... replacing kernel's and libc's memcpy() with > memcpy_with_dma_if_possible(). :-) Indeed. I wonder if we could pull apart the IOAT/DMA stuff and genericise it (it should be possible) or simply add to it, or if making a powerpc specific dma engine abstraction would be an easier idea. Probably the latter to be merged with the former at a later date would be easier to manage. Take inspiration but don't be bound by Intel's weird "new" (i.e. 15 year old) concept? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mem-2-Mem DMA - Generalized API
IOAT and Intel's DMA engine driver is very IOAT specific in places.. I had a peek at it as I have a little interest in the concept; at least the two platforms Genesi has been supporting (Pegasos and Efika) have quite competant DMA engines which are woefully underused (i.e. not at all). There exists a Marvell DMA driver somewhere (I have a copy, someone on this list posted it about a year ago) and while the MPC5200B doesn't have explicit support for DMA from memory to memory (although memory to SRAM might work in chunks, or memory to a FIFO wired as a loopback like in the docs..??) There is so much you can do with most SoC DMA controllers, and it's not even limited to PowerPC (most ARM/XScale SoCs have very capable devices inside too). I can only imagine that nobody got excited over IOAT because the entire programming interface stinks of "offloading gigabit ethernet" and not much else. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Arnd Bergmann wrote: > On Sunday 24 June 2007, Clifford Wolf wrote: >> I'm working on an MPC8349E based project and as some of you might know this >> chip has a four channel (bus-) memory-to-memory DMA controller. >> >> Unfortunately the linux kernel is atm lacking a generic interface for such >> DMA controllers. > > So what's wrong with the include/linux/dmaengine.h API? I thought it was > designed to cover this sort of DMA controller? > > Arnd <>< > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
