AM3505/3517 support

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Raphaël Assénat
Sent: Tuesday, July 05, 2011 12:59 AM
To: [email protected]
Subject: AM3505/3517 support

Hello,

We have a custom designed based on the AM3505 and we wish to run a modern kernel
on it. Unfortunately, it seems a lot of efforts have been made to support other
OMAP chips and that some work is still required to support the AM3505/3517
completely. (does not boot as-is)

Is there anyone working on this right now? Not knowing, I have already started
working on it.

The am3505 is apparently so similar to the 3430 that it was treated as such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
few differences that need to be addressed. I have therefore created a new
CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable
to mount its root filesystem.

I will send my patches in a moment for comments and hopefully, after a
few iterations, they will be acceptable. I know a lot of cleanup is happening right now and as a result my patches may not apply or conflict.
Please let me know and I will be happy to rebase them as needed.

Looking forward to your comments and help.

One of the next things I'll look at is how to properly support the ZCN package.
Right now, the CBB package is used (board-am3517evm.c for instance) but there
are differences that prevent some GPIOs from being configured properly. It would
be nice to know if someone is working on this before I start...

Best regards,
Raphaël Assénat
8D Technologies inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--

Quoted 41 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Raphaël Assénat
Sent: Tuesday, July 05, 2011 12:59 AM
To: [email protected]
Subject: AM3505/3517 support

Hello,

We have a custom designed based on the AM3505 and we wish to run a modern kernel
on it. Unfortunately, it seems a lot of efforts have been made to support other
OMAP chips and that some work is still required to support the AM3505/3517
completely. (does not boot as-is)

Is there anyone working on this right now? Not knowing, I have already started
working on it.

The am3505 is apparently so similar to the 3430 that it was treated as such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
few differences that need to be addressed. I have therefore created a new
CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable
to mount its root filesystem.

I will send my patches in a moment for comments and hopefully, after a
few iterations, they will be acceptable. I know a lot of cleanup is happening right now and as a result my patches may not apply or conflict.
Please let me know and I will be happy to rebase them as needed.

Looking forward to your comments and help.

Quoted 7 lines

One of the next things I'll look at is how to properly support the ZCN package.
Right now, the CBB package is used (board-am3517evm.c for instance) but there
are differences that prevent some GPIOs from being configured properly. It would
be nice to know if someone is working on this before I start...

Raphael,

The AM35x support has been trailing on the linux-omap. Usually, due to delays in dependency resolution:

If you are not specifically looking for the latest kernel, revision you can get the sources from:
http://arago-project.org/git/projects/?p=linux-omap3.git

Use the tag: v2.6.37_OMAPPSP_04.02.00.07

This tree is supported by TI. The patches contained here, are being reworked for upstream submission...

-----Original Message-----
From: Raphaël Assénat [mailto:[email protected]]
Sent: Wednesday, July 06, 2011 7:29 PM
To: Premi, Sanjeev
Cc: [email protected]
Subject: Re: AM3505/3517 support

Quoted 3 lines · Sanjeev

Quoted 3 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of

Raphaël Assénat

Quoted 18 lines

Quoted 18 lines

Sent: Tuesday, July 05, 2011 12:59 AM
To: [email protected]
Subject: AM3505/3517 support

Hello,

We have a custom designed based on the AM3505 and we wish to run a modern kernel
on it. Unfortunately, it seems a lot of efforts have been made to support other
OMAP chips and that some work is still required to support the AM3505/3517
completely. (does not boot as-is)

Is there anyone working on this right now? Not knowing, I have already started
working on it.

Quoted 7 lines

Quoted 7 lines

The am3505 is apparently so similar to the 3430 that it was treated as such
(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a
few differences that need to be addressed. I have therefore created a new
CHIP_IS and patched clocks, hwmod and power management

related files

Quoted 7 lines

Quoted 7 lines

consequently. My system now boots until it complains that it is unable
to mount its root filesystem.

I will send my patches in a moment for comments and hopefully, after a
few iterations, they will be acceptable. I know a lot of

cleanup is

Quoted 25 lines

Quoted 6 lines

happening right now and as a result my patches may not apply or conflict.
Please let me know and I will be happy to rebase them as needed.

Looking forward to your comments and help.

Quoted 7 lines

One of the next things I'll look at is how to properly support the ZCN package.
Right now, the CBB package is used (board-am3517evm.c for instance) but there
are differences that prevent some GPIOs from being configured properly. It would
be nice to know if someone is working on this before I start...

Raphael,

The AM35x support has been trailing on the linux-omap. Usually, due to delays in dependency resolution:

If you are not specifically looking for the latest kernel, revision you can get the sources from:
http://arago-project.org/git/projects/?p=linux-omap3.git

Use the tag: v2.6.37_OMAPPSP_04.02.00.07

Quoted 2 lines

This tree is supported by TI. The patches contained here, are being reworked for upstream submission...

When possible, I prefer working on the latest version. But at least I'll have a look to make sure I'm not duplicating anyone's work.

By the way, is there a specific mailing list for discussing this git tree?

Best regards,
Raphaël Assénat
--

The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem.

One of the next things I'll look at is how to properly support the ZCN package. Right now, the CBB package is used (board-am3517evm.c for instance) but there are differences that prevent some GPIOs from being configured properly. It would be nice to know if someone is working on this before I start...

Quoted 7 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem.

Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too?

I'd rather see us improve the code so we can support am3505 properly without a need to patch all over the place..

Quoted 11 lines · Tony Lindgren

Quoted 7 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem.

Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too?

Actually it's only needed for the 3505/3517 specific UART 4 which should not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)

But there are also cases where OMAP3430 hwmods must not be registered on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's.

Quoted 2 lines

I'd rather see us improve the code so we can support am3505 properly without a need to patch all over the place..

Maybe instead of having one big array of hwmods registered for all CPUs in omap_hwmod_3xxx_data we could have a separate one for am35xx (and maybe, eventually others) such as:

static __initdata struct omap_hwmod *omap3xxx_hwmods[] static __initdata struct omap_hwmod *am35xx_hwmods[]

...and maybe also a 'common' array.

The init function would then register the appropriate hwmod array(s). The only thing I don't like is that for this to work we would have to keep setting CHIP_IS_OMAP3430 even on AM35xx CPUs. But maybe we could change the behaviour of omap_hwmod_register to trust the caller and accept the hwmods without looking at the omap_chip member. By doing this I think we could drop all the .omap_chip = OMAP_CHIP_INIT(...) instances.

Otherwise I think the current approach, despite the size of the initial patch, has at least the benefit of being explicit and less confusing than (ab)using the CHIP_IS from a different CPU.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, July 06, 2011 12:26 PM
To: Raphaël Assénat; Paul Walmsley
Cc: [email protected]
Subject: Re: AM3505/3517 support

Quoted 4 lines · Raphaël Assénat

Quoted 3 lines · Tony Lindgren

Quoted 2 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it

was treated as such

Quoted 1 line

Quoted 1 line

Quoted 1 line

(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1).

There are however a

Quoted 1 line

Quoted 1 line

Quoted 1 line

few differences that need to be addressed. I have

therefore created a new

Quoted 1 line

Quoted 1 line

Quoted 1 line

CHIP_IS and patched clocks, hwmod and power management

related files

Quoted 1 line

Quoted 1 line

Quoted 1 line

consequently. My system now boots until it complains

that it is unable

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

to mount its root filesystem.

Can you please describe where you need CHIP_IS for

am3505? It seems that

Quoted 1 line

Quoted 1 line

your patches just enable the same CHIP_IS_OMAP3430

features for am3505 too?

Quoted 2 lines

Actually it's only needed for the 3505/3517 specific UART 4

which should

Quoted 4 lines

not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)

But there are also cases where OMAP3430 hwmods must not be

registered

Quoted 2 lines

on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's.

Sounds like we should be able to handle both uart and gptimer12 the same way
as we'll be handling the hwmod reset for special cases like gptimer12 for
secure mode. So addding Paul to Cc.

Basically we can have a am35xx specific arch_initcall that sets the special
flags for these devices like noreset, disabled or unavailable.

In this case we would just set some devices as unavailable on am35xx.

Quoted 2 lines

Quoted 2 lines

I'd rather see us improve the code so we can support

am3505 properly without

Quoted 9 lines

Quoted 1 line

a need to patch all over the place..

Maybe instead of having one big array of hwmods registered for all CPUs in omap_hwmod_3xxx_data we could have a separate one for am35xx (and maybe, eventually others) such as:

static __initdata struct omap_hwmod *omap3xxx_hwmods[] static __initdata struct omap_hwmod *am35xx_hwmods[]

...and maybe also a 'common' array.

Quoted 2 lines

The init function would then register the appropriate hwmod

array(s). The only

Quoted 1 line

thing I don't like is that for this to work we would have

to keep setting

Quoted 1 line

CHIP_IS_OMAP3430 even on AM35xx CPUs. But maybe we could

change the behaviour of

Quoted 1 line

omap_hwmod_register to trust the caller and accept the

hwmods without looking

Quoted 1 line

at the omap_chip member. By doing this I think we could

drop all the

Quoted 3 lines

.omap_chip = OMAP_CHIP_INIT(...) instances.

Otherwise I think the current approach, despite the size of

the initial patch,

Quoted 1 line

has at least the benefit of being explicit and less

confusing than (ab)using the

Quoted 1 line

CHIP_IS from a different CPU.

Well let's see how far we can get with passing the special case flags with
omap2_init_devices(). Initially we can call that from the board-*.c file
that should get your board booting. Then we can add the am35xx specific
arch_initcall.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--

Quoted 45 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, July 06, 2011 12:26 PM
To: Raphaël Assénat; Paul Walmsley
Cc: [email protected]
Subject: Re: AM3505/3517 support

Quoted 4 lines · Raphaël Assénat

Quoted 3 lines · Tony Lindgren

Quoted 2 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it

was treated as such

Quoted 1 line

Quoted 1 line

Quoted 1 line

(omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1).

There are however a

Quoted 1 line

Quoted 1 line

Quoted 1 line

few differences that need to be addressed. I have

therefore created a new

Quoted 1 line

Quoted 1 line

Quoted 1 line

CHIP_IS and patched clocks, hwmod and power management

related files

Quoted 1 line

Quoted 1 line

Quoted 1 line

consequently. My system now boots until it complains

that it is unable

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

to mount its root filesystem.

Can you please describe where you need CHIP_IS for

am3505? It seems that

Quoted 1 line

Quoted 1 line

your patches just enable the same CHIP_IS_OMAP3430

features for am3505 too?

Quoted 2 lines

Actually it's only needed for the 3505/3517 specific UART 4

which should

Quoted 4 lines

not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)

But there are also cases where OMAP3430 hwmods must not be

registered

Quoted 2 lines

on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's.

Sounds like we should be able to handle both uart and gptimer12 the same way
as we'll be handling the hwmod reset for special cases like gptimer12 for
secure mode. So addding Paul to Cc.

Quoted 5 lines

Basically we can have a am35xx specific arch_initcall that sets the special
flags for these devices like noreset, disabled or unavailable.

In this case we would just set some devices as unavailable on am35xx.

[sp] AM35x is already supported in the kernel. Specifically for the
changes being discussed, see this commit:

commit 3cc4a2fc2ed7727828f410ab092111cb56cefd61
Author: Ranjith Lohithakshan <[email protected]>
Date: Wed Feb 24 12:05:55 2010 -0700

AM35xx: Add clock support for new modules on AM35xx

I believe this patch already contains most AM35xx specific changes related to clocks.

Quoted 17 lines · Raphaël Assénat

Quoted 11 lines · Tony Lindgren

Quoted 7 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem.

Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too?

Actually it's only needed for the 3505/3517 specific UART 4 which should not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)

Quoted 3 lines

But there are also cases where OMAP3430 hwmods must not be registered on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's.

Sounds like we should be able to handle both uart and gptimer12 the same way as we'll be handling the hwmod reset for special cases like gptimer12 for secure mode. So addding Paul to Cc.

Basically we can have a am35xx specific arch_initcall that sets the special flags for these devices like noreset, disabled or unavailable.

In this case we would just set some devices as unavailable on am35xx.

Quoted 17 lines

Quoted 2 lines

I'd rather see us improve the code so we can support am3505 properly without a need to patch all over the place..

Maybe instead of having one big array of hwmods registered for all CPUs in omap_hwmod_3xxx_data we could have a separate one for am35xx (and maybe, eventually others) such as:

static __initdata struct omap_hwmod *omap3xxx_hwmods[] static __initdata struct omap_hwmod *am35xx_hwmods[]

...and maybe also a 'common' array.

The init function would then register the appropriate hwmod array(s). The only thing I don't like is that for this to work we would have to keep setting CHIP_IS_OMAP3430 even on AM35xx CPUs. But maybe we could change the behaviour of omap_hwmod_register to trust the caller and accept the hwmods without looking at the omap_chip member. By doing this I think we could drop all the .omap_chip = OMAP_CHIP_INIT(...) instances.

Quoted 3 lines

Otherwise I think the current approach, despite the size of the initial patch, has at least the benefit of being explicit and less confusing than (ab)using the CHIP_IS from a different CPU.

Well let's see how far we can get with passing the special case flags with omap2_init_devices(). Initially we can call that from the board-*.c file that should get your board booting. Then we can add the am35xx specific arch_initcall.

Quoted 18 lines · Tony Lindgren

Quoted 17 lines · Raphaël Assénat

Quoted 11 lines · Tony Lindgren

Quoted 7 lines · Raphaël Assénat

The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem.

Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too?

Actually it's only needed for the 3505/3517 specific UART 4 which should not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c)

Quoted 7 lines

Quoted 3 lines

But there are also cases where OMAP3430 hwmods must not be registered on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's.

Sounds like we should be able to handle both uart and gptimer12 the same way as we'll be handling the hwmod reset for special cases like gptimer12 for secure mode. So addding Paul to Cc.

So the idea would be to mark those devices as unavailable from the board file?

It sounds possible, but AM35xx also has some devices that are not present on 34xx chips, like the VPFE, EMAC, and HECC. And there are probably some other devices that are present on 34xx that are not present on AM35xx, like SSI, MSPRO, D2D, etc.

I'd suggest adding a separate CHIP_IS_* for those AM35xx chips, as it sounds like Raphaël has done, since they are different silicon, unlike the 34xx HS and GP chips, which just have some eFuse differences.

...

This is a bit of a side issue, but right now, the CHIP_IS_* macros are kind of messed up for OMAP3. That CHIP_IS_OMAP3430 macro is the main problem. The different CHIP_IS_OMAP* bits were intended to be mutually exclusive, so only one bit would be set at runtime for a given SoC. Then superset definitions would be defined as combinations of those bits, for use with data structures that are common to multiple OMAP3 SoCs. We do this the right way with OMAP2 and OMAP4, just not with OMAP3.

I have a patch for this, but part of it involves renaming some CHIP_IS_OMAP3430 to CHIP_IS_OMAP3XXX, so I've been hesitant to post it -- sounds like that would be grounds for flaming? Or maybe it can be posted as a 'cleanup' patch for the 3.2 time frame?