SCC1 as serial console
experiment
SCC1 as serial console
exp
SCC1 as serial console
HOW TO REPLY ON POSTS ?? !!! -P?vodn? spr?va- Od: Ladislav Klenovi? [mailto:lk99336 at pobox.sk] Odoslan?: 22. m?ja 2006 13:33 Komu: linuxppc-embedded at ozlabs.org Predmet: SCC1 as serial console Hi, can anybody help me to setup the SCC1 port as serial console on MPC860 with kernel 2.6.15.4? I would like to use it as system console during the booting proccess. I can not get any output on serial console during booting proccess, I use uboot. thnx, regards ladislav ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
SCC1 as serial console
experiment __ http://auto.sme.sk - V?etko o aut?ch (novinky, testy, autosal?n, auto?kola, porovnaj si auto)
Viable PPC platform?
In message 1148334674.10288.30.camel at shinybook.infradead.org you wrote: Out of interest, how old is that JFFS2 test? If it's with the ancient code in the 2.4 kernel, you'll get a _lot_ of improvement by using the 2.6 kernel. This was on a MPC860 system running a 2.4.25 kernel tree with a MTD snapshot of Spring 2005. It looks like it took about 13 seconds to mount the onboard 8MiB flash. I can mount 512MiB of flash in 7.9 seconds with the current kernel, with a 400MHz AMD Geode. The file system size was actually only 4 MiB. But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably not only in terms of CPU performance but also in terms of memory bandwidth. There's more work going on right now to reduce the memory usage too. Fine, thanks! Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Make it right before you make it faster.
Viable PPC platform?
On Tue, 2006-05-23 at 00:15 +0200, Wolfgang Denk wrote: But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably not only in terms of CPU performance but also in terms of memory bandwidth. It's actually NAND flash, and the bandwidth sucks (the flash controller on the Geode companion chip is quite slow). We're getting about 3 MiB/s from it, although we _ought_ to be able to get 3?. I'm playing with JFFS2 some more before I go back to tweaking the NAND drivers though. -- dwmw2
Preferred way to configure MTD physical mapping and partitioning
On Mon, 2006-05-22 at 12:32 +0200, Laurent Pinchart wrote: - adding a board specific driver in drivers/mtd/maps and handle all mapping manually - adding board specific MTD configuration in arch/ppc/platforms with calls to physmap_set_partitions() and physmap_configure() - adding board specific MTD configuration in arch/ppc/platforms with a call to physmap_set_partitions(), and using the CONFIG_MTD_PHYSMAP option with physical mapping values provided in the kernel configuration. Could anyone comment on the preferred approach ? None of the above. The physmap driver in the MTD git tree already works with a platform_device, instead of needing a call to physmap_configure() or manual configuration at build time. Either register a platform_device, or preferably extend it to use an of_device too. -- dwmw2
HOW TO REPLY ON POST?
Hi, sorry for the stupid question, but how to reply on post (continue in thread)?
HOW TO REPLY ON POST?
Simply click on reply to all button if you are on GUI. Otherwise, you might have to read up on your mail viewer commands, which does similar. Normally reply or reply to all will maintain the original subject of the email you are replying to. (Normally they prepend RE:) And then its up to the mailing list daemon to sort it in out by thread. Magic happens at the mailing list daemon if all goes well. Cheers, On 5/23/06, Ladislav Klenovi? lk99336 at pobox.sk wrote: Hi, sorry for the stupid question, but how to reply on post (continue in thread)? ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Daniel
Tri-mode or gigebit ethernet support problem in ML403
Hi Grant, I want to ask you a problem about the 1000M ethernet support. Now I am trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with tri-mode ethernet support. And I have downloaded many versions of linux, including linuxppc_2_4_devel, MontaVista linux 3.1 Preview Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't find any option in the menuconfig item Network Device Support-ethernet (1000Mbit) for me to enable the 1000M ethernet in all three versions. So I have the following questions to ask. 1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of Linux shall I use? I think I should choose a version with Xilinx On-chip Ethernet supported in the 1000M ethernet item in menuconfig. 2. Assume that you can provide me a proper version. Shall I use Xilinx EDK to generate the BSP for my platform and copy the source code to overwrite the drivers in the original version. Then configure the kernel and enable 1000M ethernet (choose Xilinx on-chip ethernet). Then compile the kernel.. Are these steps correct? Thanks for your help. I am really confused about this problem. Also others who can help me are welcome. :) Best Regards Ming _ ??? MSN Hotmail? http://www.hotmail.com
question about linux with Xilinx ML-403
Hi Rick, Yes, we have a driver for the PLB TEMAC (different than the GSRD LL TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK 8.1.1, and MontaVista is on the verge of publishing a driver for PLB TEMAC for Linux 2.6. (I believe it came across this mailing list a few weeks ago) I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore Temac and PLB Temac included). I noticed that there is a directory called Xilinx_gige in the directory of /drivers/net. Is this the driver for MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in the linux kernel directory (in the kernel directory, there is only a directory called Xilinx_enet, no Xilinx_gige. So I just copied Xilinx_gige.). However, my problem is in the menuconfig item of Network Device Support-1000Mbit ethernet, there is not any option to choose and enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux 3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode Temac in my platform? Thanks for your answer. BR Ming _ MSN Explorer: http://explorer.msn.com/lccn/
question about linux with Xilinx ML-403
Hi Rick, Yes, we have a driver for the PLB TEMAC (different than the GSRD LL TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK 8.1.1, and MontaVista is on the verge of publishing a driver for PLB TEMAC for Linux 2.6. (I believe it came across this mailing list a few weeks ago) I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore Temac and PLB Temac included). I noticed that there is a directory called Xilinx_gige in the directory of /drivers/net. Is this the driver for MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in the linux kernel directory (in the kernel directory, there is only a directory called Xilinx_enet, no Xilinx_gige. So I just copied Xilinx_gige.). However, my problem is in the menuconfig item of Network Device Support-1000Mbit ethernet, there is not any option to choose and enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux 3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode Temac in my platform? Thanks for your answer. BR Ming _ ??? MSN Hotmail? http://www.hotmail.com
Setting ID cache enable in the same mtspr instruction
Attached. Thanks. -Original Message- From: Mark A. Greer [mailto:[EMAIL PROTECTED] Sent: Monday, May 15, 2006 10:00 PM To: Assaf Hoffman Cc: linuxppc-embedded at ozlabs.org; Rita Shtern; Ronen Shitrit Subject: Re: 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 -- next part -- A non-text attachment was scrubbed... Name: cpu_setup_6xx.S Type: application/octet-stream Size: 10964 bytes Desc: cpu_setup_6xx.S Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060523/f995b3b6/attachment.obj
CRAMFS: Error -3 while decompressing!
What's /dev/rw ??? Is a mistake, the correct argument is root=/dev/ram. We would want to use a Compact Flash card with VFAT file system to boot our system, so we need to store a linux kernel image and an initrd image on it. /boot/initrd.img /boot/vmlinux.img /custom/ (custom applications) The contents of this initrd is basically busybox,libraris and device files: /bin/busybox (and simbolik links to busybox) /etc/* /lib/lib*.so /dev/* /proc /mnt/(here goes mounted Compact Flash card ) U-Boot can load linux kernel image and initrd from Compact Flash to RAM. Then, when linux boots, we can mount the Compact flash card and execute our custom applications. We haven't choose already the initrd file system type, but CRAMFS is an option. However, as I mentioned in the previos message, a CRAMFS initrd doesn?t boot in our board. Thanks in advance. -Mensaje original- De: wd at denx.de [mailto:wd at denx.de] Enviado el: lunes, 22 de mayo de 2006 22:59 Para: IGOR LURI CC: linuxppc-embedded at ozlabs.org Asunto: Re: CRAMFS: Error -3 while decompressing! In message 44718702.1070809 at fagorautomation.es you wrote: We have a mpc5200liteB evaluation board with u-boot 1.1.4 and linux 2.4.25 from Denx. We have grabed a cramfs root fs on a mtd partition and we are able to boot linux without problems: ... However, we are not able to boot linux with the same rootfs image (with the u-boot header) loaded from RAM. setenv bootargs root=/dev/rw rw console=ttyS0 console=ttyS0 init=/sbin/init ip=on What's /dev/rw ??? and CRAMFS image is built with correct endianess: Ummm.. Why would you want to use a cramfs file system in a ramdisk image? This iseems to be a truely pessimal combination of features to me. Please see http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding for some hints... Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Life sucks, but it's better than the alternative. - Peter da Silva
CRAMFS: Error -3 while decompressing!
In message 918EB199DDDFFA42BEA2EB3A1C6021F3D49640 at correo.fagorautomation.net you wrote: We would want to use a Compact Flash card with VFAT file system to boot our system, so we need to store a linux kernel image and an initrd image on it. Did you read http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile ??? U-Boot can load linux kernel image and initrd from Compact Flash to RAM. No need to waste memory on a (big) ramdisk. We haven't choose already the initrd file system type, but CRAMFS is an option. However, as I mentioned in the previos message, a CRAMFS initrd doesn?t boot in our board. cramfs makes no sense on a ramdisk image. Use ext2. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de In theory, there is no difference between theory and practice. In practice, however, there is.
UART DRIVER on 2.6.15
Hi,
just a simple question, is uart driver for kernel 2.6.15 complete.
There are some parts like:
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
pinfo-brg = 1;
}
that seems to incomplete. Am I able to do something with SCC1 with the current
cpm_uart code?
Maybe stupid question, is there any way (is it possible) to import old uart
driver from kernel 2.4.x to kernel 2.6.x
Regards,
Ladislav Klenovic
Problem mapping GPIO regs on ppc440gx
Greetings:
We've been using a 2.4.30 kernel (with numerous patches) on a AMCC 440gx
custom built board for quite some time now.
We're building some new hardware that forces us to go to a 2.6 kernel.
So, I've downloaded 2.6.16.16 from kernel.org and am porting everything
forward from our 2.4.30 kernel.
The problem lies in mapping the GPIO regs of the 440 to user space using
/dev/mem:
gpio_fd = open(/dev/mem, O_RDWR | O_SYNC);
if (0 gpio_fd) {
perror(mbGpioGet(): Unable to open gpio);
return(-1);
}
addr = (ppc440_gpio_regs_t *)mmap(0, getpagesize() * 2,
PROT_READ | PROT_WRITE,
MAP_SHARED, gpio_fd,
(off_t)(0x4000));
if (MAP_FAILED == addr) {
perror(mbGpioGet(): map error);
close(gpio_fd);
return(-1);
}
pGpioRegs = (ppc440_gpio_regs_t *)((uint32_t)addr + 0x700);
data = pGpioRegs-in (MB_GPIO_PRI_N_K | MB_GPIO_SEC_PRES_K);
munmap(0, sizeof(ppc440_gpio_regs_t));
close(gpio_fd);
The data I get back is 0. Always. /SEC_PRES_K should be 1 in this case.
(gdb) print /x addr
$7 = 0x30015000
(gdb) print /x pGpioRegs
$8 = 0x30015700
Checking /proc/PID/map shows the mapping:
30015000-30019000 rw-p 30015000 00:00 0
On a board running the 2.4.30 kernel, I show the SAME entry in
/proc/PID/map
but I do get data back.
Any idea what I'm doing wrong here?
TIA,
Travis Sawyer
Tri-mode or gigebit ethernet support problem in ML403
On 5/23/06, Ming Liu eemingliu at hotmail.com wrote: Hi Grant, I want to ask you a problem about the 1000M ethernet support. Now I am trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with tri-mode ethernet support. And I have downloaded many versions of linux, including linuxppc_2_4_devel, MontaVista linux 3.1 Preview Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't find any option in the menuconfig item Network Device Support-ethernet (1000Mbit) for me to enable the 1000M ethernet in all three versions. I hate to be the bearer of bad news, but AFAIK non of the public trees have a driver for the TEMAC. Xilinx EDK 8.1 does include drivers for the TEMAC and it *should* generate a working BSP for MontaVista Linux 3.1 (patched 2.4 kernel). It should also work with the linuxppc-2.4 tree. If you want it on a 2.6, you'll need to port the driver. Regardless, the Xilinx driver code is NOT GPL'd, so beware. So I have the following questions to ask. 1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of Linux shall I use? I think I should choose a version with Xilinx On-chip Ethernet supported in the 1000M ethernet item in menuconfig. Both Linux 2.4 and 2.6 are usable. You've got some work to do to port the driver in either case. 2. Assume that you can provide me a proper version. Shall I use Xilinx EDK to generate the BSP for my platform and copy the source code to overwrite the drivers in the original version. Then configure the kernel and enable 1000M ethernet (choose Xilinx on-chip ethernet). Then compile the kernel.. Are these steps correct? The TEMAC and EMAC are totally different devices, and I haven't looked to see if TEMAC driver uses the same API, but it is probably a good starting point. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Tri-mode or gigebit ethernet support problem in ML403
Dear Grant, First, thanks for your help on my problem. So you mean, because there is no specific driver for TEMAC included in all versions of linux, I must port the driver from the BSP generated by EDK into the linux kernel by myself, right? I am sorry that I am a novice in linux field and I cannot understand you very well. Could you please give me more guidance on what shall I do to port the driver, in detail? Do you have some reference documents for me to do this? I really appreciate a lot for your kindly help on my work. Thank you so much. Regards Ming From: Grant Likely grant.likely at secretlab.ca To: Ming Liu eemingliu at hotmail.com CC: linuxppc-embedded at ozlabs.org Subject: Re: Tri-mode or gigebit ethernet support problem in ML403 Date: Tue, 23 May 2006 06:53:34 -0600 On 5/23/06, Ming Liu eemingliu at hotmail.com wrote: Hi Grant, I want to ask you a problem about the 1000M ethernet support. Now I am trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with tri-mode ethernet support. And I have downloaded many versions of linux, including linuxppc_2_4_devel, MontaVista linux 3.1 Preview Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't find any option in the menuconfig item Network Device Support-ethernet (1000Mbit) for me to enable the 1000M ethernet in all three versions. I hate to be the bearer of bad news, but AFAIK non of the public trees have a driver for the TEMAC. Xilinx EDK 8.1 does include drivers for the TEMAC and it *should* generate a working BSP for MontaVista Linux 3.1 (patched 2.4 kernel). It should also work with the linuxppc-2.4 tree. If you want it on a 2.6, you'll need to port the driver. Regardless, the Xilinx driver code is NOT GPL'd, so beware. So I have the following questions to ask. 1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of Linux shall I use? I think I should choose a version with Xilinx On-chip Ethernet supported in the 1000M ethernet item in menuconfig. Both Linux 2.4 and 2.6 are usable. You've got some work to do to port the driver in either case. 2. Assume that you can provide me a proper version. Shall I use Xilinx EDK to generate the BSP for my platform and copy the source code to overwrite the drivers in the original version. Then configure the kernel and enable 1000M ethernet (choose Xilinx on-chip ethernet). Then compile the kernel.. Are these steps correct? The TEMAC and EMAC are totally different devices, and I haven't looked to see if TEMAC driver uses the same API, but it is probably a good starting point. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195 _ ??? MSN Hotmail? http://www.hotmail.com
Tri-mode or gigebit ethernet support problem in ML403
On 5/23/06, Ming Liu eemingliu at hotmail.com wrote: Dear Grant, Hey Ming, I just saw your repy to Rick from Xilinx. His advice is better than mine. Listen to him. :) First, thanks for your help on my problem. So you mean, because there is no specific driver for TEMAC included in all versions of linux, I must port the driver from the BSP generated by EDK into the linux kernel by myself, right? I am sorry that I am a novice in linux field and I cannot understand you very well. Could you please give me more guidance on what shall I do to port the driver, in detail? Do you have some reference documents for me to do this? You need some background on writing Linux device drivers: http://lwn.net/Kernel/LDD3/ Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Problem mapping GPIO regs on ppc440gx
Answering my own question here...
Travis B. Sawyer wrote:
Greetings:
We've been using a 2.4.30 kernel (with numerous patches) on a AMCC 440gx
custom built board for quite some time now.
We're building some new hardware that forces us to go to a 2.6 kernel.
So, I've downloaded 2.6.16.16 from kernel.org and am porting everything
forward from our 2.4.30 kernel.
The problem lies in mapping the GPIO regs of the 440 to user space using
/dev/mem:
gpio_fd = open(/dev/mem, O_RDWR | O_SYNC);
if (0 gpio_fd) {
perror(mbGpioGet(): Unable to open gpio);
return(-1);
}
addr = (ppc440_gpio_regs_t *)mmap(0, getpagesize() * 2,
PROT_READ | PROT_WRITE,
MAP_SHARED, gpio_fd,
(off_t)(0x4000));
The above mmap call worked for 2.4.30, but for 2.6.16 I needed to change
the offset
to be a multiple of page size, so:
(off_t)(0x4000/getpagesize());
-travis
UART DRIVER on 2.6.15
On Tue, 23 May 2006 14:02:49 +0200
Ladislav Klenovi? lk99336 at pobox.sk wrote:
Hi,
just a simple question, is uart driver for kernel 2.6.15 complete.
There are some parts like:
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
pinfo-brg = 1;
}
that seems to incomplete. Am I able to do something with SCC1 with the
current cpm_uart code?
Maybe stupid question, is there any way (is it possible) to import old uart
driver from kernel 2.4.x to kernel 2.6.x
It is clear, that per-board tune-up is too specific to be kept within drivers/
and now it is accomplished in the board setup code.
Just have a look at arch/ppc/platforms/mps866ads_setup.c The thing you'll have
to do is implement the pin tune-up for your board in a function, and set the
callback pointer to it - it will be executed at the time UART initializes its
resources.
--
Sincerely,
Vitaly
MPC8xx Debugging: function call vs. no function call
Hello, I am not yet pretty familiar with 8xx system programming, so maybe you could give me some debugging hint. My C code which programs the the CPM (USB) has to execute the following commands: eieio(); usbregs-usb_uscom = 0x80 | 0; mb(); If i put those instructions in an new function, the CPM behaves as wished, elsewise it depends on the remaining code. E.g. the number of NOP machine code instructions before make a difference: 1.) ... remaining C function code __asm__(nop\n\t); eieio(); usbregs-usb_uscom = 0x80 | 0; mb(); ... other code 2.) ... remaining C function code __asm__(nop\n\t); __asm__(nop\n\t); eieio(); usbregs-usb_uscom = 0x80 | 0; mb(); ... other code Every hint howto find my mistake is appreciated! Thanks Josef
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
question about linux with Xilinx ML-403
Ming, -Original Message- From: Ming Liu [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 3:42 AM To: rick.moleres Cc: linuxppc-embedded at ozlabs.org Subject: question about linux with Xilinx ML-403 Hi Rick, Yes, we have a driver for the PLB TEMAC (different than the GSRD LL TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK 8.1.1, and MontaVista is on the verge of publishing a driver for PLB TEMAC for Linux 2.6. (I believe it came across this mailing list a few weeks ago) I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore Temac and PLB Temac included). I noticed that there is a directory called Xilinx_gige in the directory of /drivers/net. Is this the driver for MontaVista Linux2.4.20? Yes, this is the PLB TEMAC driver for Linux 2.4.20. In EDK 8.1.x, the temac driver and Makefile are copied to drivers/net/xilinx_gige. This xilinx_gige directory is not available in the MVL 3.1 Preview Kit, only in the full Professional kit. We put the temac driver here mostly to take advantage of the JUMBO_FRAME_SUPPORT in kernel configuration. I copied the BSP and overwrote the original one in the linux kernel directory (in the kernel directory, there is only a directory called Xilinx_enet, no Xilinx_gige. So I just copied Xilinx_gige.). However, my problem is in the menuconfig item of Network Device Support-1000Mbit ethernet, there is not any option to choose and enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux 3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode Temac in my platform? Thanks for your answer. Our best recommendation is to use the drivers/net/xilinx_enet directory for the temac driver and just enable the Xilinx 10/100 Ethernet in menuconfig. If you want jumbo frame support, modify adapter.c in the driver to define the CONFIG_XILINX_GIGE_JUMBO constant. Note that Linux 2.6 support for the temac should be available from MontaVista soon and a driver was pushed to this mailing list in March. There will be support for MV Linux 2.6 in EDK 8.2.1 (around August). Thanks, Rick -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060523/09c6d315/attachment.htm
