ioremap on powerpc question
On Mon, Jul 15, 2002 at 01:58:21PM -0500, Cameron, Steve wrote: > > Hello, > > I have a question about ioremap_nocache() on powerpc. > > I want to create a huge RAM buffer for i/o purposes, so I > boot the kernel with parameter "mem=64M" (actually, my > system, an IBM ebony 440, has 128M RAM) > This leave 64M sitting around unused by the linux kernel. > > Then, I can do > > unsigned char *buf; > buf = ioremap_nocache(64*1024*1024, 64*1024*1024); > > And get back some kind of virtual address, "buf" which I want > to use for example to recieve data coming in from an IP socket. > > Then, since I know the physical address of buf (because I set > it up myself with ioremap), I want to DMA from buf to a PCI > device. > > I have all this working fine on x86, so far so good. > > However, on powerpc, as soon as I try to do, for example: > > *buf = '\0'; // write one char to virt addr returned by ioremap > > It blows up with a machine check. You are hitting a 440GP specific feature. ioremap is trapping ranges of addresses and "fixing them up" with the proper ERPN. Unfortunately, I left the default on a no match as an ERPN=1 which will ioremap 1 0400 . That's why you get a bus error. Try this patch: = arch/ppc/mm/pgtable.c 1.19 vs edited = --- 1.19/arch/ppc/mm/pgtable.c Wed Jun 26 15:00:59 2002 +++ edited/arch/ppc/mm/pgtable.cMon Jul 15 16:12:32 2002 @@ -93,7 +93,7 @@ ioremap(unsigned long addr, unsigned long size) { unsigned long long addr64; - unsigned long long page_4gb = PPC440_IO_PAGE; + unsigned long long page_4gb = 0; /* * Trap the least significant 32-bit portions of an > (BTW, buf happens to be == 0xc505c000, so alignment shouldn't be a problem.) > > Now, I see threads on LKML via google that say, essentially, > "you _must_ use readb/writeb, etc to access addresses returned > by ioremap," I had presumed this is because ioremap is used most > typically to access memory, registers, etc which are actually on > PCI devices. In my case, I am simply remapping actual RAM, not > on the PCI bus at all. I thought this meant that I can get away > with accessing those virtual addresses directly. Am I wrong about > that? (well, it seems I am wrong somewhere, but why?) The "_must_" comes from a desire to make all drivers portable. Some platforms cannot directly access PCI address space, and so their methods are encapsulated in read*/write* (alpha). > Using readb/writeb would defeat my purpose. > My purpose is to avoid an extra copy of the data. I want to read/write > the data off an IP socket into/from a buffer which is then directly DMA-able > to/from a PCI device, and thus avoid having to copy the data into a special > DMA-able buffer from a more "ordinary" buffer that's used with the socket. Sounds reasonable, you're going for a level of performance in which portability goes out the window. That's Ok. > I'm using ioremap because kmalloc can't give me big enough buffers. > (nothing even close to 64M, and in the end it's likely I would want > even more than 64M.) You could use alloc_bootmem_pages() to get a large buffer more elegantly than lopping off memory and ioremapping. IMHO, it is a slightly more flexible approach to large allocations. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
pcmcia-cs-3.1.34 compile problems
I've been using linux-2.4.4-2001-07-23 with a patched pcmcia-cs-3.1.24...works great ( MPC850 platform ). For a new project, I thought I would try the linux-2.4 cvs tree from DENX. Applied all changes for our board...no problems...works as expected. Then I grabbed pcmcia-cs-3.1.34 from sourceforge and added the board specific stuff and can't get it to compile. Has anyone else tried/gotten the pcmcia-cs-3.1.34 source to compile for ppc linux-2.4.x or had similar probems? Below is the output from the build: ppc_8xx-gcc -fno-builtin -msoft-float -ffixed-r2 -MD -O2 -Wall -Wstrict-prototypes -pipe -I../include -I/home/paulr/projects/nautilus2/src/linux/include -D__KERNEL__ -DMODULE -c m8xx_pcmcia.c m8xx_pcmcia.c: In function `m8xx_shutdown': m8xx_pcmcia.c:546: warning: implicit declaration of function `free_irq_Rf20dabd8' m8xx_pcmcia.c: In function `m8xx_init': m8xx_pcmcia.c:561: warning: implicit declaration of function `printk_Rdd132261' m8xx_pcmcia.c:562: warning: implicit declaration of function `CardServices_Re4eef0a4' m8xx_pcmcia.c:573: warning: implicit declaration of function `request_8xxirq_R814af5f5' m8xx_pcmcia.c:627: warning: implicit declaration of function `register_ss_entry_Reda35fe3' m8xx_pcmcia.c: In function `m8xx_exit': m8xx_pcmcia.c:641: warning: implicit declaration of function `unregister_ss_entry_R7f678b5b' m8xx_pcmcia.c: In function `m8xx_get_speed': m8xx_pcmcia.c:782: `__res_Rd7dfb463' undeclared (first use in this function) m8xx_pcmcia.c:782: (Each undeclared identifier is reported only once m8xx_pcmcia.c:782: for each function it appears in.) m8xx_pcmcia.c:755: warning: `clocks' might be used uninitialized in this function m8xx_pcmcia.c: In function `m8xx_get_status': m8xx_pcmcia.c:918: warning: implicit declaration of function `socket_get' m8xx_pcmcia.c: In function `m8xx_set_socket': m8xx_pcmcia.c:1000: warning: implicit declaration of function `__save_flags_ptr_R98964d1e' m8xx_pcmcia.c:1001: warning: implicit declaration of function `__cli_Re45078fb' m8xx_pcmcia.c:1115: warning: implicit declaration of function `__restore_flags_R9a3562fe' make[1]: *** [m8xx_pcmcia.o] Error 1 make[1]: Leaving directory `/home/paulr/projects/nautilus2/src/pcmcia-cs-3.1.34/modules' make: *** [all] Error 2 -- Paul Ruhland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ioremap on powerpc question
I wrote: > I have a question about ioremap_nocache() on powerpc. [...] > Now, I see threads on LKML via google that say, essentially, > "you _must_ use readb/writeb, etc to access addresses returned > by ioremap," [...] > Using readb/writeb would defeat my purpose. One more data point. I tried it with writeb, just to see, and it blows up just the same anyway, with machine check (bus error). -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem with PPC 857 MMU
Hi, We are trying to port mvista linux on Power PC 857T based board. We are loading the zImage.initrd file into 0x12 address and our bootloader looks for an elf file at that address and then copies the kernel into 0x40 adrress. After that the boot-loader jumps to that location and the pro-kernel starts uncompressing the kernel into 0x00. After that it jumps to 0x0. From head_8xx.S, control is transffered to start_kernel by using a rfi instruction. Our kernel crashes at this location. We would like to hear about any such problem faced by any of you and how you solved the problem. We are downloading our boot-loader into the RAM (at 0x10) using BDM and we run the boot-loader from there as we are Not able to write the on-board flash. All the addresses mentioned above RAM physical address. Thanx a lot in advance for your help. --Rajib -- next part -- An embedded and charset-unspecified text was scrubbed... Name: Wipro_Disclaimer.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020715/b8add15e/attachment.txt
ioremap on powerpc question
Hello, I have a question about ioremap_nocache() on powerpc. I want to create a huge RAM buffer for i/o purposes, so I boot the kernel with parameter "mem=64M" (actually, my system, an IBM ebony 440, has 128M RAM) This leave 64M sitting around unused by the linux kernel. Then, I can do unsigned char *buf; buf = ioremap_nocache(64*1024*1024, 64*1024*1024); And get back some kind of virtual address, "buf" which I want to use for example to recieve data coming in from an IP socket. Then, since I know the physical address of buf (because I set it up myself with ioremap), I want to DMA from buf to a PCI device. I have all this working fine on x86, so far so good. However, on powerpc, as soon as I try to do, for example: *buf = '\0'; // write one char to virt addr returned by ioremap It blows up with a machine check. (BTW, buf happens to be == 0xc505c000, so alignment shouldn't be a problem.) Now, I see threads on LKML via google that say, essentially, "you _must_ use readb/writeb, etc to access addresses returned by ioremap," I had presumed this is because ioremap is used most typically to access memory, registers, etc which are actually on PCI devices. In my case, I am simply remapping actual RAM, not on the PCI bus at all. I thought this meant that I can get away with accessing those virtual addresses directly. Am I wrong about that? (well, it seems I am wrong somewhere, but why?) Using readb/writeb would defeat my purpose. My purpose is to avoid an extra copy of the data. I want to read/write the data off an IP socket into/from a buffer which is then directly DMA-able to/from a PCI device, and thus avoid having to copy the data into a special DMA-able buffer from a more "ordinary" buffer that's used with the socket. I'm using ioremap because kmalloc can't give me big enough buffers. (nothing even close to 64M, and in the end it's likely I would want even more than 64M.) Is what I'm trying to do possible? Where am I going wrong? Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem with PPC 857 MMU
Don't use zImage.initrd PPCBoot won't understand that format. Use mkimage to build either: i) pImage - the stand alone kernel ii) pRamdisk - a stand alone ramdisk iii) pMulti - combined ramdisk/kernel see SELF on ftp.denx.de/pub/LinuxPPC/usr/src/SELF for an example of how to build these rajib majila wrote: > Hi, > We are trying to port mvista linux on Power PC 857T based board. We are > loading the zImage.initrd file into 0x12 address and our bootloader looks > for an elf file at that address and then copies the kernel into 0x40 > adrress. > After that the boot-loader jumps to that location and the pro-kernel starts > uncompressing the kernel into 0x00. After that it jumps to 0x0. From > head_8xx.S, control is transffered to start_kernel by using a rfi > instruction. Our kernel crashes at this location. We would like to hear about > any such problem faced by any of you and how you solved the problem. > We are downloading our boot-loader into the RAM (at 0x10) using BDM and > we run the boot-loader from there as we are > Not able to write the on-board flash. > All the addresses mentioned above RAM physical address. > Thanx a lot in advance for your help. > --Rajib > > > > > **Disclaimer** > > Information contained in this E-MAIL being proprietary to Wipro Limited is > 'privileged' > and 'confidential' and intended for use only by the individual or entity to > which it is > addressed. You are notified that any use, copying or dissemination of the > information > contained in the E-MAIL in any manner whatsoever is strictly prohibited. > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/