On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce <[EMAIL PROTECTED]> wrote: > > On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote: > >> In message <[EMAIL PROTECTED]> >> you wrote: >>> >>> The mmu is still disabled at this point. >>> >>> What is marked as readonly is the text section of the vmlinux file >>> generated when compiling the kernel. And since the code tries to write >>> to the text section, I assumed it was the reason for the segmentation >>> fault. >> >> Seriously, a seg fault in your emulator is a bug in the emulator! > > Mikey is likely right here. I've (unfortunately) done a lot of emulator > work, and every time I've hit a problem like this, the problem has been with > the emulator or the emulation environment. Have you isolated the faulting > instruction, verified that it's to a reasonable address, and tried examining > memory at the faulting address using your emulator's command interface? >
yes, it's a store instruction. the value to be stored is a nop instruction and the address is inside the text section (it is writing over existing code that is intended for other cpus). >> >> >>> I'm not sure how this is dealt with on real hardware. >> >> The CPU seg faults... :-P > > But only if the page is mapped non-writeable. Even with the MMU on, Linux > maps itself in as writeable. It's the OS, it can do whatever it wants. So > it just works on real hardware, and it should just work in your emulator. > I forgot to mention that I'm trying to run directly the vmlinux image in psim emulator. I'm not sure it's even supposed to work this way. >> >> >>> Can somebody please explain how is it supposed to work ? Is it ok to >>> write to text section that you load on real hardware as readonly ? >>> (again, no mmu involved, as it is still turned off, so i'm not sure >>> who's guarding this section against writing) >> >> I'm not sure how this works for 32 bit CPUs, so I can't speak to the >> details of it. >> >> For the 64bit MMU, if you're in real mode (MMU off), nothing can stop >> this from being written. The kernel ignores the elf sections >> permissions and does it's own mapping but this can only be enforced once >> the MMU is on. > > The same is true on 32-bit ppc - the basic MMU architecture is very similar > if you have a part that has "real mode" (i.e. non-booke). There is no way > to restrict stores in real mode. > > -Becky > >> >> >> Mikey >> >>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> In message <[EMAIL PROTECTED]> >>>> you >> >> wrote: >>>>> >>>>> Hello, >>>>> >>>>> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in >>>>> latest versions, >>>>> but i assume the code is still the same and just moved to powerpc. >>>>> >>>>> There is a piece of code in the early initialization of the 2.6 kernel >>>>> that identifies the cpu type and then tries to eliminate code that >>>>> does not apply to the current cpu. This is done by writing nop's over >>>>> sections of code that are not needed (do_cpu_ftr_fixups in >>>>> arch/ppc/kernel/misc.S) >>>>> >>>>> When I try to run the kernel in a ppc emulator, I get a segmentation >>>>> fault in do_cpu_ftr_fixups. From examining the section headers of the >>>>> vmlinux, the text section is marked as readonly. The piece of code >>>>> above mentioned is trying to write a nop to memory location inside the >>>>> text section which is readonly, so that explains the sigsegv error. >>>> >>>> Any segv in the emulator sounds like a bug in the emulator. >>>> >>>> If the page really is marked read only, then writing to it should cause >>>> a page fault. >>>> >>>>> Since the kernel does run on boards with ppc cpu's, can somebody >>>>> explain how come this is actually working ? Or if/where I am mistaking >>>>> with my assumptions ? >>>>> >>>>> Thank you >>>>> >>>>> P.S. please add me in cc in a reply to this message >>>>> _______________________________________________ >>>>> Linuxppc-dev mailing list >>>>> Linuxppc-dev@ozlabs.org >>>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev >>>>> >>>> >>> >> _______________________________________________ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
