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
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/
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/
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/
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/
