> It seems like no one else is interested in the subject, so i will talk > directly to you. > > If you say that the cpu also seg faults, it means that the problem is > in the code of the linux kernel... :)
Sorry, I was only joking. The hardware does _not_ segfault. There is no equivalent to segfault in real hardware. > I'm not sure you are completely familiar with this particular piece of > code I'm talking about, so just to make sure... On powerpc, in the > beggining, it jumps to the early initialization, where it checks cpu > type and then does the cpu features fixup, which means that it > overwrites with nop's code that is not intended for this particular > cpu. This happens on every powerpc cpu (32 bits at least), so if the > problem was here, somebody would have reported it at least. So it is > supposed to work this way. But in my emulator at least, I can't get > the code to write over code and not get a segmentation fault. The > emulator (psim, the one that comes with gdb) keeps it from writing to > sections that were loaded as readonly. You're saying it happens the > same on real hw ? I'm familiar with the code you are talking about... and it works correctly on real hardware (the code is replaced with NOPs) The section notes are just a hints to the loader. In the case of the Linux kernel, it's ignored or can't be enforced by the PPC architecture. Mikey > > On Mon, Aug 18, 2008 at 11:51 PM, Michael Neuling <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]> yo u 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! > > > >> I'm not sure how this is dealt with on real hardware. > > > > The CPU seg faults... :-P > > > >> 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. > > > > Mikey > > > >> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <[EMAIL PROTECTED]> wrot e: > >> > 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