Re: [linuxsh-dev] mmu problems?

[Greg B. <gb...@po...>]

Bryan Rittmeyer wrote:
> 
> Hello linuxsh-dev,
> 
> I have been working with the latest CVS kernel sources, putting in
> printk statements as reach points trying to figure out why the only
> thing I am getting in GDB is the kernel banner. It looks like the
> problem lies in setup_arch, called right after printk(linux_banner).
> That routine executes fine, until  it calls paging_init (at the last
> line of setup_arch). As soon as the MMU is brought up, printk stops
> working:
> 
> [from arch/sh/mm/init.c:paging_init]
> 
>         printk("paging here 1\n");
> 
>         /* Enable MMU */
>         ctrl_outl(MMU_CONTROL_INIT, MMUCR);
> 
>         /* The manual suggests doing some nops after turning on the MMU
> */
>         asm volatile("nop;nop;nop;nop;nop;nop;");
> 
>         printk("paging here 2\n");
> 
> All I get with GDB is "paging here 1" and then nothing else. As I
> mentioned before if I exit GDB and go into a terminal program, the
> sh-ipl menu is back up as if GDB mode exited (suggesting the kernel
> died/returned). Of course I have no way of knowing how much of the
> kernel executed since printk stops working. I am not passing a console
> parameter to the kernel.
> 
> Is it normal for LinuxSH BIOS-based printk to break after bringing up
> the MMU? 

  No, this is a configuration bug.  Mitch & I struggled with exactly
this problem some weeks ago.  What is wrong is that the gdb stub's
exception handling table, to which the kernel delegates BIOS calls,
is located at an address which has the top nibble 0x0.  This works
fine until the kernel enables paging because the address is not
translated; after that there is no mapping for the address and an
attempt to call the BIOS will double-fault.

  You need to check two things.

1.  Your gdb stub is linked at the right address.  The easiest way is
    to use the `sh-linux-gnu-objdump --headers' command on the .exe
    produced when you built the stub.  You should see numbers like this:

gnb@felix 1031> sh-linux-gnu-objdump --headers sh-stub.exe 

sh-stub.exe:     file format elf32-shl

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00001c24  a0000000  a0000000  00001000  2**12
                            ^
                          a not 0

                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000001  ac000000  ac000000  00003000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          000008a4  ac000004  ac000004  00003004  2**2
                  ALLOC
  3 .stack        00000600  ac000a00  ac000a00  00003a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .stab         0000258c  ac000004  ac000004  00004000  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000072  ac002590  ac002590  0000658c  2**0
                  CONTENTS, READONLY
  6 .stabstr      00000c65  ac002602  ac002602  000065fe  2**0
                  CONTENTS, READONLY, DEBUGGING

2.  Your kernel configuration variable CONFIG_GDB_STUB_VBR has
    the top nibble set to `a', e.g. `a0000000'.

    BTW this variable will go away in the next few days when I
    get around to checking in my auto-vbr patch.

> If so, how do I fix it--I would like all console output to go
> into GDB. And if I am having MMU problems, could that be the result of
> incorrect sh-ipl init_bsc code?

  Probably not.  At least, these particular symptoms don't indicate it.


Greg.
-- 
These are my opinions not PPIs.