early UART mapping in head_44x.S

early UART mapping in head_44x.S

[Ralph Siemsen]

I've been trying to boot a vanilla 2.6.7 kernel on a board similar to
Ocotea (the board boots 2.4.x okay).  I wasn't getting any serial
output, despite setting CONFIG_SERIAL_TEXT_DEBUG and doing early
registration of a console (as per David Woodhouse's posts on this list).

After much tracing and a lucky suggestion on IRC, I seem to have
stumbled on the cause, although I don't fully understand what is going
on.  In arch/ppc/kernel/head_44x.S (from 2.6.7 mainline) there is a
block of code that sets up the "early UART mapping".  It does three
tlbwe instructions, and then repeats the same a second time but in
"Translation state 1".  This second set seems to cause my problems.
When I comment out the 5 instructions before the isync, I magically
start getting printk outputs.

But as-written, the code causes an exception immediately upon the first
attempt to write to the mapped space.  Of course there are no exception
handlers in place at this point, so things grind to a halt very quickly.

Can anyone explain how this is meant to work?  Specifically, the
	ori	r3,r3,PPC44x_TLB_TS
would clear the other bits in this register, including the "valid" bit,
so how is this mapping supposed to work?

Thanks
-Ralph

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: early UART mapping in head_44x.S

[Ralph Siemsen]

Ralph Siemsen wrote:
> Can anyone explain how this is meant to work?  Specifically, the
>     ori    r3,r3,PPC44x_TLB_TS
> would clear the other bits in this register, including the "valid" bit,
> so how is this mapping supposed to work?
Clearly demonstrating that I have been staring that this line of code
too long... the ori instruction sets the TS bit and shouldn't affect the
others...

However, if I dump the TLB entry after the isync using the BDI
interface, it shows the EPN is zero'd out:

IDX TID      EPN  SIZE VTS          RPN   USER WIMGE USRSVC
  1 : 00 00000000   1KB -0 -> 1_40000000 U:0000 -I-G- -WR-WR

whereas without the second "tlbwe" instructions, I get the expected and
functioning mapping:

  1 : 00 e0000000 256MB V0 -> 1_40000000 U:0000 -I-G- ----WR

What's the secret?
-R

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: early UART mapping in head_44x.S

[James Perkins]

Ralph Siemsen wrote:

>
> I've been trying to boot a vanilla 2.6.7 kernel on a board similar to
> Ocotea (the board boots 2.4.x okay).  I wasn't getting any serial
> output, despite setting CONFIG_SERIAL_TEXT_DEBUG and doing early
> registration of a console (as per David Woodhouse's posts on this list).
>
> After much tracing and a lucky suggestion on IRC, I seem to have
> stumbled on the cause, although I don't fully understand what is going
> on.  In arch/ppc/kernel/head_44x.S (from 2.6.7 mainline) there is a
> block of code that sets up the "early UART mapping".  It does three
> tlbwe instructions, and then repeats the same a second time but in
> "Translation state 1".  This second set seems to cause my problems.
> When I comment out the 5 instructions before the isync, I magically
> start getting printk outputs.
>
> But as-written, the code causes an exception immediately upon the first
> attempt to write to the mapped space.  Of course there are no exception
> handlers in place at this point, so things grind to a halt very quickly.
>
> Can anyone explain how this is meant to work?  Specifically, the
>     ori    r3,r3,PPC44x_TLB_TS
> would clear the other bits in this register, including the "valid" bit,
> so how is this mapping supposed to work?

ori won't clear the invalid bits, it just "or"s in the TS bit itself.
What suprises me is that TLB 1 is being written twice. It may make more
sense to change the second case

         li      r0,1            /* TLB slot 1 */

to
        li      r0,2             /* TLB slot 2 */

So that there is both a TS=0 and a TS=1 mapping, in TLB entry index 1
and 2, respectively -- this will catch both the MSR[DS]=0 and MSR[DS]=1
cases.

Note I haven't explored further into the allocation the kernel uses for
TLB entries; I just looked through head_44x.S

Cheers,
James

--
James Perkins         james@loowit.net         http://loowit.net/~james
-=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=- -=*=-
    I have no fear of death.... It's how you live that really counts.
		    -- Katharine Hepburn, 1907-2003


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: early UART mapping in head_44x.S

[Ralph Siemsen]

James Perkins wrote:

> ori won't clear the invalid bits, it just "or"s in the TS bit itself.
> What suprises me is that TLB 1 is being written twice. It may make more
> sense to change the second case
>
>         li      r0,1            /* TLB slot 1 */
>
> to
>        li      r0,2             /* TLB slot 2 */
>
> So that there is both a TS=0 and a TS=1 mapping, in TLB entry index 1
> and 2, respectively -- this will catch both the MSR[DS]=0 and MSR[DS]=1
> cases.

Yes I see now.  Your suggestion also works, and it seems more logical -
though I doubt anything in the early startup would ever do an access in
TS=1 virtual space... shortly after this the real MMU init is done and
it will overwrite all of these temporary mappings...

-Ralph

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: early UART mapping in head_44x.S

[Matt Porter]

On Tue, Jul 13, 2004 at 05:23:34PM -0400, Ralph Siemsen wrote:
>
> I've been trying to boot a vanilla 2.6.7 kernel on a board similar to
> Ocotea (the board boots 2.4.x okay).  I wasn't getting any serial
> output, despite setting CONFIG_SERIAL_TEXT_DEBUG and doing early
> registration of a console (as per David Woodhouse's posts on this list).

That's a separate issue. I need to go through and early register
the console on 4xx when I get a moment.

> After much tracing and a lucky suggestion on IRC, I seem to have
> stumbled on the cause, although I don't fully understand what is going
> on.  In arch/ppc/kernel/head_44x.S (from 2.6.7 mainline) there is a
> block of code that sets up the "early UART mapping".  It does three
> tlbwe instructions, and then repeats the same a second time but in
> "Translation state 1".  This second set seems to cause my problems.
> When I comment out the 5 instructions before the isync, I magically
> start getting printk outputs.

Yeah, I fat-fingered the last patch to head_44x.S and left the
duplicate code fragment there. There's a patch submitted to fix
this in mainline.

-Matt

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

RE: early UART mapping in head_44x.S

[Daren Hayward]

Hi,

I have been having the same problems with the head_44x.S, what does the
patch do just remove the duplicate entries?

Where can I browse the PPC BK tree online?

Daren

> -----Original Message-----
> From: Matt Porter [mailto:mporter@kernel.crashing.org]
> Sent: 23 July 2004 00:56
> To: Ralph Siemsen
> Cc: Linux PPC Dev
> Subject: Re: early UART mapping in head_44x.S
>
>
> On Tue, Jul 13, 2004 at 05:23:34PM -0400, Ralph Siemsen wrote:
> >
> > I've been trying to boot a vanilla 2.6.7 kernel on a board similar to
> > Ocotea (the board boots 2.4.x okay).  I wasn't getting any serial
> > output, despite setting CONFIG_SERIAL_TEXT_DEBUG and doing early
> > registration of a console (as per David Woodhouse's posts on this list).
>
> That's a separate issue. I need to go through and early register
> the console on 4xx when I get a moment.
>
> > After much tracing and a lucky suggestion on IRC, I seem to have
> > stumbled on the cause, although I don't fully understand what is going
> > on.  In arch/ppc/kernel/head_44x.S (from 2.6.7 mainline) there is a
> > block of code that sets up the "early UART mapping".  It does three
> > tlbwe instructions, and then repeats the same a second time but in
> > "Translation state 1".  This second set seems to cause my problems.
> > When I comment out the 5 instructions before the isync, I magically
> > start getting printk outputs.
>
> Yeah, I fat-fingered the last patch to head_44x.S and left the
> duplicate code fragment there. There's a patch submitted to fix
> this in mainline.
>
> -Matt
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: early UART mapping in head_44x.S

[Matt Porter]

On Mon, Aug 02, 2004 at 01:30:10PM +0100, Daren Hayward wrote:
>
> Hi,
>
> I have been having the same problems with the head_44x.S, what does the
> patch do just remove the duplicate entries?

Yes, it removes the repeated code.

> Where can I browse the PPC BK tree online?

Most PPC subarches don't use the old linuxppc-2.5 tree any longer.
The latest 4xx bit are in mainline.

http://linux.bkbits.net:8080/linux-2.5

-Matt

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: early UART mapping in head_44x.S

[Ralph Siemsen]

Daren Hayward wrote:
 > Hi,
 >
 > I have been having the same problems with the head_44x.S, what does
 > the patch do just remove the duplicate entries?
 >
 > Where can I browse the PPC BK tree online?

Hi Daren

I'm using mainline sources (eg. tarball from kernel.org)... its a
one-line fix for the TLB setup.. the second one should use slot 2
not slot 1 (which is already setup).  Note this only affects you if you
build with CONFIG_EARLY_SERIAL_DEBUG.

I just found your post to the u-boot mailing list from 2004-07-02 where
you mention networking problems unless you use u-boot to touch the
network somehow before the kernel boots.

I am seeing very much similar behaviour, with 2.6.7 kernel and using
PIBS bootloader.

Looks very much like the kernel is missing some initialization that is
required.  Did you make any progress tracking down the cause?

-Ralph

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/