[2.5] Hang on 8xx in head_8xx.S

[2.5] Hang on 8xx in head_8xx.S

[Pantelis Antoniou]

Hello

I'm trying to make 2.5 work for 8xx processors.

After some tweaking it compiles, but now it hangs
in arch/ppc/kernel/head_8xx.S  at the marked point
below.

I know this is not enough to make it work, since
it appears that the calling convention and registers
used for exception are changed between 2.4 <-> 2.5.

I could use some help in trying to understand what's going on.

Regards

Pantelis


/*
 * Go back to running unmapped so we can load up new values
 * and change to using our exception vectors.
 * On the 8xx, all we have to do is invalidate the TLB to clear
 * the old 8M byte TLB mappings and load the page table base register.
 */
        /* The right way to do this would be to track it down through
         * init's THREAD like the context switch code does, but this is
         * easier......until someone changes init's static structures.
         */
        lis     r6, swapper_pg_dir@h
        ori     r6, r6, swapper_pg_dir@l
        tophys(r6,r6)
#ifdef CONFIG_8xx_CPU6
        lis     r4, cpu6_errata_word@h
        ori     r4, r4, cpu6_errata_word@l
        li      r3, 0x3980
        stw     r3, 12(r4)
        lwz     r3, 12(r4)
#endif
        mtspr   M_TWB, r6
        lis     r4,2f@h
        ori     r4,r4,2f@l
        tophys(r4,r4)
        li      r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
        mtspr   SRR0,r4
        mtspr   SRR1,r3

---> Gets here <---

        rfi
2:

---> Never gets here <---

        SYNC                    /* Force all PTE updates to finish */
        tlbia                   /* Clear all TLB entries */
        sync                    /* wait for tlbia/tlbie to finish */
        TLBSYNC                 /* ... on all CPUs */


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Dan Malek]

Pantelis Antoniou wrote:

> I'm trying to make 2.5 work for 8xx processors.

I'm working on it right now and should have it running shortly.


	-- Dan


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Pantelis Antoniou]

Dan Malek wrote:

> Pantelis Antoniou wrote:
>
>> I'm trying to make 2.5 work for 8xx processors.
>
>
> I'm working on it right now and should have it running shortly.
>
>
>     -- Dan
>
>
>
Cool. How can I help?

Could you take the time to  highlight the changes needed?
How about a discussion about some improvements?

Regards

Pantelis


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Dan Malek]

Pantelis Antoniou wrote:

> Cool. How can I help?

Once I get it basically booting there are lots of little things in
drivers that need updating.

> Could you take the time to  highlight the changes needed?

I'm not sure what all of them are just yet :-)

> How about a discussion about some improvements?

discuss away........

Thanks.


	-- Dan


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Pantelis Antoniou]

Dan Malek wrote:

> Pantelis Antoniou wrote:
>
>> Cool. How can I help?
>
>
> Once I get it basically booting there are lots of little things in
> drivers that need updating.
>
>> Could you take the time to  highlight the changes needed?
>
>
> I'm not sure what all of them are just yet :-)
>
>> How about a discussion about some improvements?
>
>
> discuss away........
>
> Thanks.
>
>
>     -- Dan
>
>
>
>
Ok then ;)

1. I think it is time to look into the
artificial (IMO) division between 8xx_io/8260_io.

The CPM is basically the same, but there are two kind
of drivers for every peripheral that is common.

i.e. arch/ppc/8xx_io/enet.c arch/ppc/8260_io/enet.c

I believe we should have one common driver for both.

2. The profusion of platform specific #defines in the
drivers. Typically something like the configuration of
the port I/O for the ethernet/uart whatever.

How about having a platform specific source file
that will export functions for the platform specific
part of the configuration?

i.e. instead of

#if defined(CONFIG_XXX)
    .. blah ..
#elif defined(CONFIG_YYY)
    .. blah blah ..
....

something like this

    m8xx_platform_ethernet_port_config(int scc);

3. Ability to have the drivers built as modules.
I believe I have made my case in a previous mail
so I'll spare you this time.

How about taking a look at the patches I have sent
you earlier about the dpalloc/hostalloc problem?

Thanks for taking the time to  respond, and
when you get it booting I'm willing to work
at any of these areas.

Regards

Pantelis


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Dan Malek]

Pantelis Antoniou wrote:

> 1. I think it is time to look into the
> artificial (IMO) division between 8xx_io/8260_io.
>
> The CPM is basically the same, but there are two kind
> of drivers for every peripheral that is common.

The CPM isn't the same, especially when you look at some
of the details.  There are reserved areas for special
functions that are very different between the two, along
with CPM memory configuration options (cache coherency
options and local memory) on the 8260.

If we can't make all of the drivers common, I'd prefer
not to make any of them common.  From a far away distance,
yes, everything looks similar, but I believe the details
are going to make for confusing #defines/#ifdefs that you
want to remove in some of the other drivers.

Another issue I have is that when I'm working on an 8260
driver, I don't want to worry about the impact on 8xx processors.
If someone is working on a common driver, I also want them to
ensure they have tested it on the other platform, and I don't
think there are very many people able (because they don't
have the hardware) or willing to do that.  Unfortunately,
I have both, and I don't want to be responsible for that
additional work prior to checking in the changes.


> 2. The profusion of platform specific #defines in the
> drivers. Typically something like the configuration of
> the port I/O for the ethernet/uart whatever.

That's always a trade off.  Some people like all of the
configuration stuff together so they can easily see
differences or be aware of configurations they can leverage
when doing new ports/designs.  I'm not a big fan of changing
something for the sake of personal preference.  If there is
some development or feature advantage, that's great, but
just because you like it one way and someone else likes it
another without any functional improvement isn't a reason
for change.  Since one of the goals of 2.5 is to have spilt
out these details, it's reasonable to try that.  I find it
interesting that other architectures are currently trying
to go the other way, more use of common code and fewer
platform specific directories........

> How about having a platform specific source file
> that will export functions for the platform specific
> part of the configuration?

That's a reasonable thing to do, unless you end up with
less than 10 lines of code in a file.  Please, don't put
such code in an include file, though.

> How about taking a look at the patches I have sent
> you earlier about the dpalloc/hostalloc problem?

I got 'em.  There may be other things that are issues
that may appear.

Thanks.


	-- Dan


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Pantelis Antoniou]

On Friday 14 February 2003 22:31, Dan Malek wrote:
> Pantelis Antoniou wrote:
> > 1. I think it is time to look into the
> > artificial (IMO) division between 8xx_io/8260_io.
> >
> > The CPM is basically the same, but there are two kind
> > of drivers for every peripheral that is common.
>
> The CPM isn't the same, especially when you look at some
> of the details.  There are reserved areas for special
> functions that are very different between the two, along
> with CPM memory configuration options (cache coherency
> options and local memory) on the 8260.
>
> If we can't make all of the drivers common, I'd prefer
> not to make any of them common.  From a far away distance,
> yes, everything looks similar, but I believe the details
> are going to make for confusing #defines/#ifdefs that you
> want to remove in some of the other drivers.
>
> Another issue I have is that when I'm working on an 8260
> driver, I don't want to worry about the impact on 8xx processors.
> If someone is working on a common driver, I also want them to
> ensure they have tested it on the other platform, and I don't
> think there are very many people able (because they don't
> have the hardware) or willing to do that.  Unfortunately,
> I have both, and I don't want to be responsible for that
> additional work prior to checking in the changes.
>

Fair enough. IMHO it is doable.
I'm currently hacking away at a 850 board, but I will shortly
have access to a 8270 based board.

As you see I'm acting out of pure self interest :-).


> > 2. The profusion of platform specific #defines in the
> > drivers. Typically something like the configuration of
> > the port I/O for the ethernet/uart whatever.
>
> That's always a trade off.  Some people like all of the
> configuration stuff together so they can easily see
> differences or be aware of configurations they can leverage
> when doing new ports/designs.  I'm not a big fan of changing
> something for the sake of personal preference.  If there is
> some development or feature advantage, that's great, but
> just because you like it one way and someone else likes it
> another without any functional improvement isn't a reason
> for change.  Since one of the goals of 2.5 is to have spilt
> out these details, it's reasonable to try that.  I find it
> interesting that other architectures are currently trying
> to go the other way, more use of common code and fewer
> platform specific directories........
>

I agree, you should not mess with something that works.
However we should strive for clarity when it is within reach.

> > How about having a platform specific source file
> > that will export functions for the platform specific
> > part of the configuration?
>
> That's a reasonable thing to do, unless you end up with
> less than 10 lines of code in a file.  Please, don't put
> such code in an include file, though.
>

Agreed.

> > How about taking a look at the patches I have sent
> > you earlier about the dpalloc/hostalloc problem?
>
> I got 'em.  There may be other things that are issues
> that may appear.
>
> Thanks.
>
>
> 	-- Dan
>

Thanks.

I forgot to mention one more thing.

The drivers are assuming that you use only one
peripheral of each kind. That is yoy have a
UART in SCC1, ethernet in SCC3 and so on.

There are some configurations that require
more than one of each kind, for example two
ethernets.

How do you think we can tackle this issue?

Regards

Pantelis

P.S. This is sent from my home account; that explains the
different email adress.


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

Re: [2.5] Hang on 8xx in head_8xx.S

[Dan Malek]

Pantelis Antoniou wrote:

> The drivers are assuming that you use only one
> peripheral of each kind. That is yoy have a
> UART in SCC1, ethernet in SCC3 and so on.

I don't quite understand.  The uart driver will support a
variety of SMC/SCC combinations.

We have discussed before that we are not doing "scc" or "smc"
drivers, but rather "uart", "ethernet", "usb", whatever function
driver.  It doesn't make sense to have an 'scc' driver because
there are so many configuration combinations and you logically
connect to the kernel with a function (i.e. network interface)
not a device type.

> There are some configurations that require
> more than one of each kind, for example two
> ethernets.

Well, in the case of multiple SCC ethernets, I have provided my old
patch to probably a half a dozen people, all who promised to
bring it up to date and apply some suggested improvements.  None
of them have provided anything up to date in return, so I guess
I'll have to take time to do that, too :-)  The 8260 FCC driver
supports any combination of FCC Ethernet devices.


Thanks.


	-- Dan


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

RE: [2.5] Hang on 8xx in head_8xx.S

[Allen Curtis]

> Well, in the case of multiple SCC ethernets, I have provided my old
> patch to probably a half a dozen people, all who promised to
> bring it up to date and apply some suggested improvements.  None
> of them have provided anything up to date in return, so I guess
> I'll have to take time to do that, too :-)  The 8260 FCC driver
> supports any combination of FCC Ethernet devices.

Could you make your patch available to the mail list?

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