From bergner at vnet.ibm.com Wed Jun 12 05:26:15 2002 From: bergner at vnet.ibm.com (Peter Bergner) Date: Tue, 11 Jun 2002 14:26:15 -0500 Subject: [Linuxppc-dev] ptrace References: <20020610214831.GA18245@krispykreme> Message-ID: <3D064ED7.40400@vnet.ibm.com> Note: redirecting this to the external linuxppc64-dev mailing list, as this is where this discussion belongs... Anton Blanchard wrote: >> The idea/history behind GETREGS,GETFPREGS,etc is to allow GDB (or other >>debugger) a way to retrieve all registers with a single syscall. Similar >>calls appear to exist for arm,i386,ia64,sparc,sparc64. >> > > But not ppc32. Is there a reason for creating this difference in > the 32 and 64 bit interface other than everyone else does it? > > Im keen to keep the 32 and 64 bit environment consistent where possible. Well, it shouldn't be too hard to add the GETREGS,etc to ppc32! ;) I'm guessing you're advocating PEEKUSR/GETREGS/... always return the same amount (for 32-bit apps) regardless of whether we're running on a ppc32 or ppc64 kernel. I can accept this. This means then that we need PEEKUSR64 and/or GETREGS64/... versions in the ppc64 kernel that 32-bit apps can use so we don't need to make multiple syscalls just to read a register value. Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at vnet.ibm.com Wed Jun 12 06:04:12 2002 From: bergner at vnet.ibm.com (Peter Bergner) Date: Tue, 11 Jun 2002 15:04:12 -0500 Subject: [Linuxppc-dev] boot code rework References: <20020611084454.GA2822@krispykreme> Message-ID: <3D0657BC.5050102@vnet.ibm.com> Anton Blanchard wrote: > Ive been seeing a lot of kernels fail to boot on large S85 and p690 > machines lately, so Paul and I sat down today to look at the potential > problems with early boot. There are a few things: > > 1. Must not touch OF at 12MB until we are done with it. > 2. Must not touch the RTAS region at any time Yup. > There were a number of problem scenarios: > > 1. The RTAS region can get quite large, on a p690 it was over 5MB > Since we were allocating the RTAS region directly above the kernel it > was possible to overlap the OF region. If firmware zeroes this > region then its very likely we will die right there. (We should > really be using claim here, it would have picked this bug up) Yes, this does seem to be a problem if indeed, RTAS can get that large! > 2. With a very large RTAS region any memory allocated with the klimit > hack above the RTAS region could end up inside the RTAS region once > we relocate! This should _not_ happen... or at least it's not supposed to happen! :) The kernel memory used to hold RTAS is reserved with a klimit allocation just like the other early boot time allocations. However it is instantiated at the physical address of where it is supposed to end up after the kernel is relocated. I took great pains to make sure we didn't copy over the RTAS region while relocating the kernel and you'll see we skip relocating the RTAS region since it's already located where it's supposed to live. > For 2.4 I suggest we allocate the RTAS region above OF, this will > hopefully fix the boot problems Ive been seeing. > > I experimented today with a larger change in 2.5: > > 1. link the kernel at 0xC....4000 > 2. store the exception vectors in an __init section > 3. load the zImage wrapper somewhere high (8MB at this stage) > 4. load the kernel at 0x4000 physical > 5. when finished with OF, copy the linux exception vectors in Reworking this code would definitely be a good thing!!! Death to RELOC!!!! Only problem I see is that the zImage can be quite large if we have an attached ramdisk/initrd. We might want to think about linking it above OF too. > Since we jump out of all the exception vectors via an rfid, we dont > have to do anything at all to make this work. The really nice thing > is that we can take advantage of the fact that real mode ignores the > top two bits. > > This means RELOC is no more! Hooray! > In fact Ive just gone through and shortened the pSeries boot sequence by a > significant amount. There is no need to do any of the copy_down or relocate > toc/naca etc two or more times. We should be able to simplify the iSeries > boot too since there will be no need to do the final paca/naca/r2 etc > relocation in the common code. Its booting on my 270, I'll clean it up > a bit more before posting the patch. Once this gets tested well, we're going to want to backport this to 2.4.X as the distro's will no doubt want/need this for installs on _large_ systems. > Im interested to know how we can handle yaboot. Will it load the zImage > correctly? Can we get it to load the vmlinux at physical 0x4000? I can make yaboot do whatever we need it to do! :) Yaboot just loads the zImage LOAD segments where the zImage program header tells it to. If you want it to load somewhere else, we just need to update arch/ppc64/boot/ files to put it somewhere else. No changes to Yaboot should be required. Since the zImage wrapper is tightly connected to the kernel, we can make any changes we want to it and not have to worry about backward compatability. The plan is to also move to requiring booting a zImage rather than a vmlinux, but we haven't done this yet... I'm not sure whether you forward ported our latest 2.4.X zImage changes, but that would be good to have in 2.5.X. I'm including the entire vmlinux in it's own elf section so it can now be extracted with objcopy. Before, we stripped the elf header so you couldn't objdump the extracted vmlinux. Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at au1.ibm.com Wed Jun 12 22:14:50 2002 From: anton at au1.ibm.com (Anton Blanchard) Date: Wed, 12 Jun 2002 22:14:50 +1000 Subject: [Linuxppc-dev] boot code rework In-Reply-To: <3D0657BC.5050102@vnet.ibm.com> References: <20020611084454.GA2822@krispykreme> <3D0657BC.5050102@vnet.ibm.com> Message-ID: <20020612121450.GD9417@krispykreme> > Only problem I see is that the zImage can be quite large if > we have an attached ramdisk/initrd. We might want to think > about linking it above OF too. Agreed. I had a rethink about it today and my current tree does: 1. yaboot and the zImage wrapper operate as normal, ie they load somewhere below OF and load the kernel above OF (say 20MB or higher). 2. The first thing the kernel does is relocate down to 0x4000 and then jumps into it. This allows the current yaboot to work. Unfortunately I had to make one change, I was linking the vmlinux at 0xc....4000 so that in theory a loader could load it at its final physical address. However this confuses yaboot (possibly because the ELF rules say you should have things on a 64kB alignment). In the end I had to link at 0xc...0000 to keep yaboot happy. This means there is 16k of zeroes where the exception vectors should be and if we were loaded into our final position we'd overwrite the OF vectors :( Now the final thing is to find a place for RTAS. At this stage we've claimed all over the place (above and below OF) and havent freed the memory, so I made the arbitrary decision to use our original load address (ie 20MB or so) as the RTAS area :) Ive tested this on a p690 that was having problems and it seems OK (it uses yaboot). I need to build a massive kernel (say 9MB big) and see if it still works. > I can make yaboot do whatever we need it to do! :) Yaboot just loads the > zImage LOAD segments where the zImage program header tells it to. If you > want it to load somewhere else, we just need to update arch/ppc64/boot/ > files to put it somewhere else. No changes to Yaboot should be required. > Since the zImage wrapper is tightly connected to the kernel, we can make > any changes we want to it and not have to worry about backward > compatability. OK, if we are going to go the zImage direction in yaboot we can probably clean it up some more. Any suggestions for the best place to lay all this out? We have OF, RTAS, birecs, initrd, kernel image (anything else??) to look out for. I was thinking it would be nice to claim and free memory in OF as we go but they may turn out to be too much work. I guess all we really need to know is where OF starts and finishes since everything else is ours for the taking (I hope). > The plan is to also move to requiring booting a zImage rather than a > vmlinux, > but we haven't done this yet... I'm not sure whether you forward ported > our latest 2.4.X zImage changes, but that would be good to have in 2.5.X. > I'm including the entire vmlinux in it's own elf section so it can now be > extracted with objcopy. Before, we stripped the elf header so you couldn't > objdump the extracted vmlinux. I havent yet but it was on my list of things to do. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Thu Jun 13 03:44:00 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Wed, 12 Jun 2002 12:44:00 -0500 Subject: [Linuxppc-dev] boot code rework In-Reply-To: <20020612121450.GD9417@krispykreme> References: <20020611084454.GA2822@krispykreme> <3D0657BC.5050102@vnet.ibm.com> <20020612121450.GD9417@krispykreme> Message-ID: <20020612124400.A666546@brule.borg.umn.edu> Anton Blanchard wrote: :> Only problem I see is that the zImage can be quite large if :> we have an attached ramdisk/initrd. We might want to think :> about linking it above OF too. : : Agreed. I had a rethink about it today and my current tree does: : : 1. yaboot and the zImage wrapper operate as normal, ie they load : somewhere below OF and load the kernel above OF (say 20MB or higher). As I mentioned before, a zImage.initrd can get quite large so if we try loading it below OF, we just might overlay OF with our ramdisk. We probably only want to load yaboot below OF. Everything else should probably be loaded above OF. : 2. The first thing the kernel does is relocate down to 0x4000 and : then jumps into it. : : This allows the current yaboot to work. Unfortunately I had to make : one change, I was linking the vmlinux at 0xc....4000 so that in theory : a loader could load it at its final physical address. However this : confuses yaboot (possibly because the ELF rules say you should have : things on a 64kB alignment). : : In the end I had to link at 0xc...0000 to keep yaboot happy. This : means there is 16k of zeroes where the exception vectors should be and : if we were loaded into our final position we'd overwrite the OF : vectors :( Yaboot has some special magic addresses it knows about when it attempts to load a binary like vmlinux or zImage. It looks at the e_entry field in the binary's ELF header and if it's the special value KERNEL_LINK_ADDR_PPC64 (which is 0xC000000000000000ULL for us currently), then it ignores this value and loads the binary at KERNELADDR (0x01400000). Otherwise, it attempts to load it at it's e_entry value. So, if you change the link addr to 0xC00....4000, you'll need to update the value of KERNEL_LINK_ADDR_PPC64 in Yaboot, otherwise that's where we'll try and load it! Or it may just be easier to change the test from: if (e->e_entry == KERNEL_LINK_ADDR_PPC64) { to: if ((e->e_entry & ~((Elf64_Addr)0xffffff) == KERNEL_LINK_ADDR_PPC64) { This should allow both 0xC000000000000000 and 0xC000000000004000 to work with Yaboot. : Now the final thing is to find a place for RTAS. At this stage we've : claimed all over the place (above and below OF) and havent freed : the memory, so I made the arbitrary decision to use our original load : address (ie 20MB or so) as the RTAS area :) : : Ive tested this on a p690 that was having problems and it seems OK : (it uses yaboot). I need to build a massive kernel (say 9MB big) and : see if it still works. I don't think hard coding the addr is a good thing. Particularly since we've seen some machines (Condor?) where the 20M area was already claimed and not available. We had to add hacks in Yaboot to work around this when loading a vmlinux... : I guess all we really need to know is where OF starts and finishes : since everything else is ours for the taking (I hope). I think we need to know a little more than that. We need to know what memory has been claimed. This includes OF, but on some of the Condor boxes, we've seen other areas at or around 20M that were also being claimed. I'm not sure exactly what they were/are used for, but I'm guessing OF was using it for something. We don't' want to stomp on that either. : OK, if we are going to go the zImage direction in yaboot we can probably : clean it up some more. Any suggestions for the best place to lay all : this out? We have OF, RTAS, birecs, initrd, kernel image (anything : else??) to look out for. I was thinking it would be nice to claim : and free memory in OF as we go but they may turn out to be too much : work. I hesitate to rely on OF's claim/free code. I seem to recall that there is a limit to how much information it can remember. I'd feel better if we determine what is claimed when we first start up and then handle all our own allocations/frees ourselves. My thoughts on how this should work is: 1) Boot into zImage from either yaboot or OF. 2) 32-bit zImage code should be compiled fully relocatable similar to paulus' prom.c changes to ppc32 kernel. 3) Allow yaboot to load the zImage wrapper anywhere it can find space, rather than using it's e_entry value in case that space it already claimed. Prefer addrs above OF. 4) zImage code will make _all_ OF calls, so will need to pass information like device tree, claimed memory, RTAS addr/size and others to the kernel via birecs. 5) Have the zImage code relocate the kernel to phys addr 0... rather than having the kernel do it. 6) Early kernel code still runs relocate off, but since realmode ignores the upper addr bits, no RELOC needed. 7) rm arch/ppc64/kernel/prom.c :) Did I forget anything??? Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollis-lists at austin.rr.com Thu Jun 13 10:28:35 2002 From: hollis-lists at austin.rr.com (Hollis Blanchard) Date: Wed, 12 Jun 2002 19:28:35 -0500 Subject: [Linuxppc-dev] OF locations In-Reply-To: <20020612124400.A666546@brule.borg.umn.edu> Message-ID: on 12/6/02 12:44 PM, Peter Bergner at bergner at brule.borg.umn.edu wrote: > > : I guess all we really need to know is where OF starts and finishes > : since everything else is ours for the taking (I hope). > > I think we need to know a little more than that. We need to know > what memory has been claimed. This includes OF, but on some of the > Condor boxes, we've seen other areas at or around 20M that were also > being claimed. I'm not sure exactly what they were/are used for, but > I'm guessing OF was using it for something. We don't' want to stomp > on that either. All pSeries OF starts at 12MB. The older stuff is only 8MB large (so ends at 20MB), but newer/bigger OF can be 16MB large (ending at 28MB). In one spot the kernel tries to claim at 20MB and then increments upwards 1MB at a time... it should really increment by 8MB and save some effort. :) Also, on Condor NVRAM (or some copy of it) is stored at 32MB, but I think it's only 1MB large (at least currently). So a 5MB claim will fail even at 28MB. -Hollis ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Thu Jun 13 11:30:27 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Wed, 12 Jun 2002 20:30:27 -0500 Subject: [Linuxppc-dev] OF locations In-Reply-To: References: <20020612124400.A666546@brule.borg.umn.edu> Message-ID: <20020612203027.A668757@brule.borg.umn.edu> Hollis wrote: : Also, on Condor NVRAM (or some copy of it) is stored at 32MB, but I think : it's only 1MB large (at least currently). So a 5MB claim will fail even at : 28MB. That must have been what Dave and I were seeing... Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From migor at lrn.ru Fri Jun 21 01:55:53 2002 From: migor at lrn.ru (Igor Muratov) Date: Thu, 20 Jun 2002 19:55:53 +0400 Subject: kernel cross-compile Message-ID: <3D11FB09.4050207@lrn.ru> Hi All. I'm build kernel for 7044-170 (uniproc.). I'm go step by step corresponding by penguinppc64.org. Now i have binutils-2.12.90.0.9 and gcc-3.1 successfully compiled with --target=powerpc64-linux Next. I try to build kernel 2.4.18 with patch-2.4.19-pre8.gz and linuxppc64-2.4.19-pre8-ibm-1.patch.gz Also, I had to make my own small patch ------------->8---------- --- arch/ppc64/kernel/process.c. Thu Jun 20 17:58:26 2002 +++ arch/ppc64/kernel/process.c Thu Jun 20 17:58:51 2002 @@ -41,6 +41,7 @@ #include #include #include +#include #include int dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpregs); --- arch/ppc64/kernel/traps.c. Thu Jun 20 17:58:06 2002 +++ arch/ppc64/kernel/traps.c Thu Jun 20 17:52:58 2002 @@ -40,6 +40,7 @@ #include #include #include +#include extern int fix_alignment(struct pt_regs *); extern void bad_page_fault(struct pt_regs *, unsigned long); --- arch/ppc64/lib/dec_and_lock.c. Thu Jun 20 18:54:03 2002 +++ arch/ppc64/lib/dec_and_lock.c Thu Jun 20 18:48:03 2002 @@ -8,6 +8,7 @@ */ #include +#ifndef ATOMIC_DEC_AND_LOCK #include #include @@ -36,3 +37,4 @@ spin_unlock(lock); return 0; } +#endif ------------->8---------- Now, my trouble in last step of kernel building: /opt/ppc64/bin/powerpc64-linux-ld -T arch/ppc64/vmlinux.lds -Bstatic -e 0xc000000000000000 -Ttext 0xc000000000000000 arch/ppc64/kernel/head.o init/main.o init/version.o init/do_mounts.o \ --start-group \ arch/ppc64/kernel/kernel.o arch/ppc64/mm/mm.o arch/ppc64/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/ppc64/xmon/x.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o drivers/input/inputdrv.o \ net/network.o \ /opt/cross/linux/lib/lib.a \ --end-group \ -o vmlinux arch/ppc64/kernel/head.o: In function `.start_secondary_prolog': arch/ppc64/kernel/head.o(.text+0x9db4): undefined reference to `.start_secondary' arch/ppc64/kernel/kernel.o: In function `.openpic_init_processor': arch/ppc64/kernel/kernel.o(.text+0x28b04): undefined reference to `.get_hard_smp_processor_id' arch/ppc64/kernel/kernel.o: In function `.openpic_set_affinity': arch/ppc64/kernel/kernel.o(.text+0x28f14): undefined reference to `.get_hard_smp_processor_id' arch/ppc64/kernel/kernel.o: In function `.xics_set_affinity': arch/ppc64/kernel/kernel.o(.text+0x29988): undefined reference to `.get_hard_smp_processor_id' arch/ppc64/kernel/kernel.o: In function `.pSeriesLP_qirr_info': arch/ppc64/kernel/kernel.o(.text+0x36380): undefined reference to `.get_hard_smp_processor_id' arch/ppc64/kernel/kernel.o: In function `.openpic_init': arch/ppc64/kernel/kernel.o(.text.init+0xa60): undefined reference to `.get_hard_smp_processor_id' arch/ppc64/kernel/kernel.o(.text.init+0xba0): more undefined references to `.get_hard_smp_processor_id' follow kernel/kernel.o: In function `.printk': kernel/kernel.o(.text+0x4ca4): undefined reference to `.__restore_flags' kernel/kernel.o(.text+0x4cec): undefined reference to `.__restore_flags' kernel/kernel.o: In function `.release_console_sem': kernel/kernel.o(.text+0x4e50): undefined reference to `.__restore_flags' kernel/kernel.o(.text+0x4e98): undefined reference to `.__restore_flags' kernel/kernel.o: In function `.register_console': kernel/kernel.o(.text+0x51c4): undefined reference to `.__restore_flags' kernel/kernel.o(.text+0x12718): more undefined references to `.__restore_flags' follow drivers/video/video.o: In function `.tdfxfb_probe': drivers/video/video.o(.text.init+0x190c): undefined reference to `.eeh_memset' make: *** [vmlinux] Error 1 Where is my fault? -- With best regards System administrator Igor Muratov mailto:migor at lrn.ru ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ken at tossell.net Fri Jun 21 01:57:50 2002 From: ken at tossell.net (Ken Tossell) Date: Thu, 20 Jun 2002 11:57:50 -0400 Subject: kernel cross-compile In-Reply-To: <3D11FB09.4050207@lrn.ru> References: <3D11FB09.4050207@lrn.ru> Message-ID: <1024588670.3d11fb7e407cb@mail.tossell.net> Quoting Igor Muratov : > > Hi All. > > I'm build kernel for 7044-170 (uniproc.). > I'm go step by step corresponding by penguinppc64.org. Now i have > binutils-2.12.90.0.9 and gcc-3.1 successfully compiled with > --target=powerpc64-linux > > Next. I try to build kernel 2.4.18 with patch-2.4.19-pre8.gz and > linuxppc64-2.4.19-pre8-ibm-1.patch.gz > Also, I had to make my own small patch > ------------->8---------- > --- arch/ppc64/kernel/process.c. Thu Jun 20 17:58:26 > 2002 > +++ arch/ppc64/kernel/process.c Thu Jun 20 17:58:51 > 2002 > @@ -41,6 +41,7 > @@ > > #include > > > #include > > > #include > > > +#include > > > #include > > > > > int dump_fpu(struct pt_regs *regs, elf_fpregset_t > *fpregs); > --- arch/ppc64/kernel/traps.c. Thu Jun 20 17:58:06 > 2002 > +++ arch/ppc64/kernel/traps.c Thu Jun 20 17:52:58 > 2002 > @@ -40,6 +40,7 > @@ > > #include > > > #include > > > #include > > > +#include > > > > > extern int fix_alignment(struct pt_regs > *); > extern void bad_page_fault(struct pt_regs *, unsigned > long); > --- arch/ppc64/lib/dec_and_lock.c. Thu Jun 20 18:54:03 > 2002 > +++ arch/ppc64/lib/dec_and_lock.c Thu Jun 20 18:48:03 > 2002 > @@ -8,6 +8,7 > @@ > > > */ > > > > #include > > > +#ifndef > ATOMIC_DEC_AND_LOCK > > #include > > > #include > > > > > @@ -36,3 +37,4 > @@ > > > spin_unlock(lock); > > return > 0; > > } > > +#endif > > ------------->8---------- > > Now, my trouble in last step of kernel building: > > /opt/ppc64/bin/powerpc64-linux-ld -T arch/ppc64/vmlinux.lds -Bstatic -e > 0xc000000000000000 -Ttext 0xc000000000000000 arch/ppc64/kernel/head.o > init/main.o init/version.o init/do_mounts.o \ > --start-group \ > arch/ppc64/kernel/kernel.o arch/ppc64/mm/mm.o > arch/ppc64/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o > arch/ppc64/xmon/x.o \ > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o > drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o > drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o > drivers/input/inputdrv.o \ > net/network.o \ > /opt/cross/linux/lib/lib.a \ > --end-group \ > -o vmlinux > arch/ppc64/kernel/head.o: In function `.start_secondary_prolog': > arch/ppc64/kernel/head.o(.text+0x9db4): undefined reference to > `.start_secondary' > arch/ppc64/kernel/kernel.o: In function `.openpic_init_processor': > arch/ppc64/kernel/kernel.o(.text+0x28b04): undefined reference to > `.get_hard_smp_processor_id' > arch/ppc64/kernel/kernel.o: In function `.openpic_set_affinity': > arch/ppc64/kernel/kernel.o(.text+0x28f14): undefined reference to > `.get_hard_smp_processor_id' > arch/ppc64/kernel/kernel.o: In function `.xics_set_affinity': > arch/ppc64/kernel/kernel.o(.text+0x29988): undefined reference to > `.get_hard_smp_processor_id' > arch/ppc64/kernel/kernel.o: In function `.pSeriesLP_qirr_info': > arch/ppc64/kernel/kernel.o(.text+0x36380): undefined reference to > `.get_hard_smp_processor_id' > arch/ppc64/kernel/kernel.o: In function `.openpic_init': > arch/ppc64/kernel/kernel.o(.text.init+0xa60): undefined reference to > `.get_hard_smp_processor_id' > arch/ppc64/kernel/kernel.o(.text.init+0xba0): more undefined references > to `.get_hard_smp_processor_id' follow > kernel/kernel.o: In function `.printk': > kernel/kernel.o(.text+0x4ca4): undefined reference to `.__restore_flags' > kernel/kernel.o(.text+0x4cec): undefined reference to `.__restore_flags' > kernel/kernel.o: In function `.release_console_sem': > kernel/kernel.o(.text+0x4e50): undefined reference to `.__restore_flags' > kernel/kernel.o(.text+0x4e98): undefined reference to `.__restore_flags' > kernel/kernel.o: In function `.register_console': > kernel/kernel.o(.text+0x51c4): undefined reference to `.__restore_flags' > kernel/kernel.o(.text+0x12718): more undefined references to > `.__restore_flags' follow > drivers/video/video.o: In function `.tdfxfb_probe': > drivers/video/video.o(.text.init+0x190c): undefined reference to > `.eeh_memset' > make: *** [vmlinux] Error 1 > > Where is my fault? > > -- > With best regards System administrator > Igor Muratov mailto:migor at lrn.ru > > > The problem may be that the kernel won't build well as uniprocessor. Sometimes it will build, but then it will be buggy. Make sure that you are building a SMP kernel. I run ppc64 Linux on a p44 170 UP and smp works fine. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From migor at lrn.ru Fri Jun 21 02:55:21 2002 From: migor at lrn.ru (Igor Muratov) Date: Thu, 20 Jun 2002 20:55:21 +0400 Subject: kernel cross-compile References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> Message-ID: <3D1208F9.9030900@lrn.ru> Ken Tossell ?????: >Quoting Igor Muratov : > > > >>Hi All. >> >>I'm build kernel for 7044-170 (uniproc.). >>I'm go step by step corresponding by penguinppc64.org. Now i have >>binutils-2.12.90.0.9 and gcc-3.1 successfully compiled with >>--target=powerpc64-linux >> [ Skip ] >> >>`.eeh_memset' >>make: *** [vmlinux] Error 1 >> >>Where is my fault? >> >>-- >>With best regards System administrator >>Igor Muratov mailto:migor at lrn.ru >> >> >> >> >> > >The problem may be that the kernel won't build well as uniprocessor. Sometimes >it will build, but then it will be buggy. Make sure that you are building a SMP >kernel. I run ppc64 Linux on a p44 170 UP and smp works fine. > > Thanks Ken. For SMP kernel i have /opt/ppc64/bin/powerpc64-linux-ld -T arch/ppc64/vmlinux.lds -Bstatic -e 0xc000000000000000 -Ttext 0xc000000000000000 arch/ppc64/kernel/head.o init/main.o init/version.o init/do_mounts.o \ --start-group \ arch/ppc64/kernel/kernel.o arch/ppc64/mm/mm.o arch/ppc64/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/ppc64/xmon/x.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o drivers/input/inputdrv.o \ net/network.o \ /opt/cross/linux/lib/lib.a \ --end-group \ -o vmlinux drivers/net/net.o(.data.init+0x78): undefined reference to `de4x5_probe' drivers/net/net.o(.toc1+0x3d8): undefined reference to `tr_header' drivers/net/net.o(.toc1+0x3e0): undefined reference to `tr_rebuild_header' drivers/video/video.o: In function `.tdfxfb_probe': drivers/video/video.o(.text.init+0x1954): undefined reference to `.eeh_memset' net/network.o(__ksymtab+0xdf0): undefined reference to `tr_type_trans' net/network.o(.data+0x11e0): undefined reference to `sysctl_tr_rif_timeout' make: *** [vmlinux] Error 1 I use config from http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc/config.power3 with some small changes. Maybe i need to disable something? -- With best regards System administrator Igor Muratov mailto:migor at lrn.ru ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Fri Jun 21 04:04:11 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Thu, 20 Jun 2002 13:04:11 -0500 Subject: kernel cross-compile In-Reply-To: <3D1208F9.9030900@lrn.ru> References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> Message-ID: <20020620130411.A702588@brule.borg.umn.edu> Igor Muratov wrote: : I use config from : http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc/config.power3 : with some small changes. Maybe i need to disable something? For your 170, just do a "make oldconfig && make dep && make vmlinux". You shouldn't need anything more than that. Remember to clean out the old build cruft with "make mrproper" first. Peter -- Peter Bergner Linux PPC64 & GLIBC Kernel Development IBM Rochester, MN bergner at vnet.ibm.com ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From migor at lrn.ru Sat Jun 22 01:12:10 2002 From: migor at lrn.ru (Igor Muratov) Date: Fri, 21 Jun 2002 19:12:10 +0400 Subject: kernel cross-compile References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> <20020620130411.A702588@brule.borg.umn.edu> Message-ID: <3D13424A.2030700@lrn.ru> Peter Bergner ?????: >Igor Muratov wrote: >: I use config from >: http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc/config.power3 >: with some small changes. Maybe i need to disable something? > >For your 170, just do a "make oldconfig && make dep && make vmlinux". >You shouldn't need anything more than that. Remember to clean out >the old build cruft with "make mrproper" first. > Sorry, Peter, But this is not enought. After "make mrproper && make oldconfig && make dep && make zImage" I have: /opt/ppc64/bin/powerpc64-linux-nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map make[1]: Entering directory `/opt/cross/linux/arch/ppc64/boot' gcc -D__ASSEMBLY__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -I/opt/cross/linux/include -traditional -c -o crt0.o crt0.S /home/migor/tmp/ccFavuGr.s: Assembler messages: /home/migor/tmp/ccFavuGr.s:134: Error: no such instruction: `lis 9,_start at h' /home/migor/tmp/ccFavuGr.s:135: Error: no such instruction: `lis 8,_etext at ha' /home/migor/tmp/ccFavuGr.s:136: Error: no such instruction: `addi 8,8,_etext at l' /home/migor/tmp/ccFavuGr.s:137: Error: no such instruction: `dcbf 0,9' /home/migor/tmp/ccFavuGr.s:138: Error: no such instruction: `icbi 0,9' /home/migor/tmp/ccFavuGr.s:139: Error: no such instruction: `addi 9,9,0x20' /home/migor/tmp/ccFavuGr.s:140: Error: no such instruction: `cmplwi 0,9,8' /home/migor/tmp/ccFavuGr.s:141: Error: no such instruction: `blt 1b' /home/migor/tmp/ccFavuGr.s:142: Error: no such instruction: `sync' /home/migor/tmp/ccFavuGr.s:143: Error: no such instruction: `isync' /home/migor/tmp/ccFavuGr.s:147: Error: no such instruction: `lis 7,_end at ha' /home/migor/tmp/ccFavuGr.s:148: Error: no such instruction: `addi 7,7,_end at l' /home/migor/tmp/ccFavuGr.s:149: Error: no such instruction: `lis 8,__bss_start at ha' /home/migor/tmp/ccFavuGr.s:150: Error: no such instruction: `addi 8,8,__bss_start at l' /home/migor/tmp/ccFavuGr.s:154: Error: no such instruction: `subf 7,8,7' /home/migor/tmp/ccFavuGr.s:155: Error: no such instruction: `addi 7,7,3' /home/migor/tmp/ccFavuGr.s:156: Error: invalid character '.' in mnemonic /home/migor/tmp/ccFavuGr.s:157: Error: no such instruction: `beq 3f' /home/migor/tmp/ccFavuGr.s:158: Error: no such instruction: `addi 8,8,-4' /home/migor/tmp/ccFavuGr.s:159: Error: no such instruction: `mtctr 7' /home/migor/tmp/ccFavuGr.s:160: Error: no such instruction: `li 0,0' /home/migor/tmp/ccFavuGr.s:161: Error: no such instruction: `stwu 0,4(8)' /home/migor/tmp/ccFavuGr.s:162: Error: no such instruction: `bdnz 2b' /home/migor/tmp/ccFavuGr.s:164: Error: no such instruction: `b start' make[1]: *** [crt0.o] Error 1 make[1]: Leaving directory `/opt/cross/linux/arch/ppc64/boot' make: *** [zImage] Error 2 It is too difficult for me :-( > > >Peter > >-- >Peter Bergner >Linux PPC64 & GLIBC Kernel Development >IBM Rochester, MN >bergner at vnet.ibm.com > > -- With best regards System administrator Igor Muratov mailto:migor at lrn.ru ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Sat Jun 22 02:14:30 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Fri, 21 Jun 2002 11:14:30 -0500 Subject: kernel cross-compile In-Reply-To: <3D13424A.2030700@lrn.ru> References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> <20020620130411.A702588@brule.borg.umn.edu> <3D13424A.2030700@lrn.ru> Message-ID: <20020621111430.A710594@brule.borg.umn.edu> Igor Muratov wrote: : Sorry, Peter, But this is not enought. : After "make mrproper && make oldconfig && make dep && make zImage" I have: Ahh, you didn't tell me you wer building zImage! For building zImage for PPC64 on a non PPC32/PPC64 machine, you need not only a set of cross tools for powerpc64-linux, but one for powerpc-linux as well, since the PPC64 zImage is actually a powerpc-linux (ie, ELF32) binary. If you're building on a PPC32 or PPC64, amek sure the "gcc" you're using to compile the arch/ppc64/boot/* files is the powerpc-linux one. Yeah Hollis, I know you told me to add this to the toolchain.shtml directions. I'll get to it soon! :) Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From migor at lrn.ru Sat Jun 22 02:49:26 2002 From: migor at lrn.ru (Igor Muratov) Date: Fri, 21 Jun 2002 20:49:26 +0400 Subject: kernel cross-compile References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> <20020620130411.A702588@brule.borg.umn.edu> <3D13424A.2030700@lrn.ru> <20020621111430.A710594@brule.borg.umn.edu> Message-ID: <3D135916.80007@lrn.ru> Thans You for Your help. Peter Bergner ?????: >Igor Muratov wrote: >: Sorry, Peter, But this is not enought. >: After "make mrproper && make oldconfig && make dep && make zImage" I have: > >Ahh, you didn't tell me you wer building zImage! For building zImage >for PPC64 on a non PPC32/PPC64 machine, you need not only a set of >cross tools for powerpc64-linux, but one for powerpc-linux as well, >since the PPC64 zImage is actually a powerpc-linux (ie, ELF32) binary. > Yes, I build it on i686 :-( Ok If I build cross tools for powerpc-linux, How can I use it? I must place this tools together? Another way. I can "make vmlinux" but this image is wrong IMHO. I try to load it via tftp and have this message on my console RS/6000 Firmware Version SPH01184 (c) Copyright IBM Corp. 2000 All rights reserved. ------------------------------------------------------------------------------- BOOTP S = 1 FILE: vmlinux BOOTP: read-first-block failed: 0 FILE: vmlinux BOOTP: read-first-block failed: 1 FILE: vmlinux BOOTP: read-first-block failed: 2 FILE: vmlinux BOOTP: read-first-block failed: 3 FILE: vmlinux BOOTP: read-first-block failed: 4 BOOTP ERROR: TFTP of first block failed, ABORT !20A80005 ! TFTP works fine. I test it a few times. Sorry, I know, my questions is too stuped... But I really need it. > >If you're building on a PPC32 or PPC64, amek sure the "gcc" you're >using to compile the arch/ppc64/boot/* files is the powerpc-linux one. > >Yeah Hollis, I know you told me to add this to the toolchain.shtml >directions. I'll get to it soon! :) > Yes, I tell too ;-)) > >Peter > > > -- With best regards System administrator Igor Muratov mailto:migor at lrn.ru ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Sat Jun 22 05:12:29 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Fri, 21 Jun 2002 14:12:29 -0500 Subject: kernel cross-compile In-Reply-To: <3D135916.80007@lrn.ru> References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> <20020620130411.A702588@brule.borg.umn.edu> <3D13424A.2030700@lrn.ru> <20020621111430.A710594@brule.borg.umn.edu> <3D135916.80007@lrn.ru> Message-ID: <20020621141229.A710665@brule.borg.umn.edu> Igor Muratov wrote: : Yes, I build it on i686 :-( : Ok If I build cross tools for powerpc-linux, How can I use it? : I must place this tools together? Having never done a cross-build from x86, I can't really answer this. Anyone??? If you installed SuSE's x86->ppc64 cross tools, then I'd just grab their x86->ppc cross tools too. : Another way. I can "make vmlinux" but this image is wrong IMHO. : I try to load it via tftp and have this message on my console I'm not a tftp expert nor do I use it, but it should work. If you use the Yaboot bootloader (similar to lilo), then I can answer questions for you... Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ken at tossell.net Sat Jun 22 06:06:15 2002 From: ken at tossell.net (Ken Tossell) Date: Fri, 21 Jun 2002 16:06:15 -0400 Subject: kernel cross-compile In-Reply-To: <3D12B7F6.8060906@lrn.ru> References: <3D11FB09.4050207@lrn.ru> <1024588670.3d11fb7e407cb@mail.tossell.net> <3D1208F9.9030900@lrn.ru> <1024597536.3d121e201f2cc@mail.tossell.net> <3D12B7F6.8060906@lrn.ru> Message-ID: <1024689975.3d1387376f14c@mail.tossell.net> Quoting Igor Muratov : > > > Ken Tossell wrote: > > > > >I also had trouble starting with "de4x5", which is an ethernet driver, but > I'm > >not sure where anymore. I used the config base from 'arch/ppc64/defconfig' > and > >copied that file to my .config in the root of the linux source tree. > > > >Some trouble that you might run into: > > > >1) Sometimes, there are errors making the zImage. In this case, if you get > an > >error with vmlinux, the best way to fix it is usually to go into > arch/ppc64/boot > >and run 'make clean'. > > > >2) *If you are using the IBM integrated ethernet card, you WILL have this > >problem*: This ethernet card uses the 'pcnet32' driver and it is broken in > >2.4.19-pre8. There is a problem in the source, for which I can send you a > patch > >if you'd like. > > > >Good luck, > >Ken Tossell > > > Thanks Ken > Unfortunately, I have integrated ethernet card pcnet32. :( > I'm glad to get this magic patch. > > -- > Igor Muratov > > The patch file is below. Save the text between the markers to a file called patch in the linux source tree root. Then run 'patch drivers/net/pcnet32.c patch' and the source should be good. **Start Patch (Remove This Line)** 660c660 < for (i = 0; i < 6; i++) { --- > for (i = 0; i < 6; i++) 675c675 < } --- > **End Patch (Remove this, too)** ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From engebret at vnet.ibm.com Sat Jun 22 06:09:40 2002 From: engebret at vnet.ibm.com (Dave Engebretsen) Date: Fri, 21 Jun 2002 15:09:40 -0500 Subject: [Fwd: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2] Message-ID: <3D138804.FE96871@vnet.ibm.com> Anton, I was working on an explaination for this but you beat me to the punch with the question ... Fundamentally, the problem is that the OS does not have any control over the ERAT and it may be invalidated at any point in time. What we found is that when castouts from the SLB start to occur and we get into this code path with some frequency, we end up in a state where the SLB is full, and there are additional translations in the ERAT for kernel address which are not in the SLB. This set up a situation where we were preparing to rfi (do_signal_ret) and were in the crital section where SRRO/1 were loaded when the ERAT entry for the stack gets invalidated from under us (presumably via a tlbie from another processor). We then take an SLB fault, where the handler proceeds to clobber SRR0/1, and things fall apart. Given that this should be a generally low use path (SLB castout), I don't expect there would be any performance impact. Dave. -------------- next part -------------- An embedded message was scrubbed... From: Anton Blanchard Subject: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2 Date: Fri, 21 Jun 2002 14:35:44 -0500 Size: 1009 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20020621/6a669536/attachment.mht From anton at au1.ibm.com Sat Jun 22 07:15:23 2002 From: anton at au1.ibm.com (Anton Blanchard) Date: Fri, 21 Jun 2002 16:15:23 -0500 Subject: [Fwd: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2] In-Reply-To: <3D138804.FE96871@vnet.ibm.com> References: <3D138804.FE96871@vnet.ibm.com> Message-ID: <20020621211523.GA15846@krispykreme> Hi Dave, > Fundamentally, the problem is that the OS does not have any control over > the ERAT and it may be invalidated at any point in time. What we found > is that when castouts from the SLB start to occur and we get into this > code path with some frequency, we end up in a state where the SLB is > full, and there are additional translations in the ERAT for kernel > address which are not in the SLB. This set up a situation where we were > preparing to rfi (do_signal_ret) and were in the crital section where > SRRO/1 were loaded when the ERAT entry for the stack gets invalidated > from under us (presumably via a tlbie from another processor). We then > take an SLB fault, where the handler proceeds to clobber SRR0/1, and > things fall apart. Thanks for the explanation. I actually have a comment in my tree warning about SLB castouts during the exception exit path but hadnt got around to fixing it :) I think there are more problems than just this one, what if the exception took an SLB miss and chose to cast out the kernel segment mapping the stack? My understanding is that we should be clearing the MSR RI bit during exception exit and then replaying the final parts of the exception exit code if necessary. I cannot take credit for this idea, Paul has implemented it in the 32 bit port :) > Given that this should be a generally low use path (SLB castout), I > don't expect there would be any performance impact. I think the SLB castout path can be quite important on large random access workloads. We were seeing it trip on 32 bit JVM benchmarks, imagine how bad it would be with 200GB of pagecache or process memory. An unnecessary slbie could have a noticeable effect. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From hollis-lists at austin.rr.com Mon Jun 24 13:00:32 2002 From: hollis-lists at austin.rr.com (Hollis Blanchard) Date: Sun, 23 Jun 2002 22:00:32 -0500 Subject: kernel cross-compile In-Reply-To: <20020621141229.A710665@brule.borg.umn.edu> Message-ID: on 21/6/02 2:12 PM, Peter Bergner at bergner at brule.borg.umn.edu wrote: > > Igor Muratov wrote: > : Yes, I build it on i686 :-( There is nothing wrong with that; I do it all the time. > : Ok If I build cross tools for powerpc-linux, How can I use it? > : I must place this tools together? > > Having never done a cross-build from x86, I can't really answer this. > Anyone??? If you installed SuSE's x86->ppc64 cross tools, then I'd > just grab their x86->ppc cross tools too. You must edit another Makefile to specify your cross-compiler, arch/ppc/boot/Makefile I think. > : Another way. I can "make vmlinux" but this image is wrong IMHO. > : I try to load it via tftp and have this message on my console Those messages (unfortunately omitted here, but I think I remember them...) looked simply like a failed tftp attempt, which is not vmlinux's fault. Of course a vmlinux is much larger than a zImage, which greatly increases the chance of an ARP timeout on the host (and ARP requests greatly confuse RS/6000 firmware when they occur mid-tftp). -Hollis ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at brule.borg.umn.edu Tue Jun 25 01:56:24 2002 From: bergner at brule.borg.umn.edu (Peter Bergner) Date: Mon, 24 Jun 2002 10:56:24 -0500 Subject: kernel cross-compile In-Reply-To: References: <20020621141229.A710665@brule.borg.umn.edu> Message-ID: <20020624105624.B715129@brule.borg.umn.edu> :> Having never done a cross-build from x86, I can't really answer this. :> Anyone??? If you installed SuSE's x86->ppc64 cross tools, then I'd :> just grab their x86->ppc cross tools too. : : You must edit another Makefile to specify your cross-compiler, : arch/ppc/boot/Makefile I think. I think you mean arch/ppc64/boot/Makefile here. ^^ Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From engebret at vnet.ibm.com Fri Jun 28 06:56:45 2002 From: engebret at vnet.ibm.com (David Engebretsen) Date: Thu, 27 Jun 2002 15:56:45 -0500 Subject: [Fwd: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2] References: <3D138804.FE96871@vnet.ibm.com> <20020621211523.GA15846@krispykreme> Message-ID: <3D1B7C0D.88310356@vnet.ibm.com> Anton Blanchard wrote: > > Hi Dave, > > Thanks for the explanation. I actually have a comment in my tree warning > about SLB castouts during the exception exit path but hadnt got around > to fixing it :) > > I think there are more problems than just this one, what if the > exception took an SLB miss and chose to cast out the kernel segment > mapping the stack? My understanding is that we should be clearing the MSR > RI bit during exception exit and then replaying the final parts of the > exception exit code if necessary. > I'm not sure that we have other exposures like this one. Certainly in the case we have identified, we should be ok. The text is bolted in the SLB so the only exception should be on the stack address segment. As long as the kernel stack is aligned to its size, we will only take the one exception & then the stack should be ok. At this point, we are hard disabled and all addresses are bolted in the HPT. Dave. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/