Current state of AM33xx patches

Current state of AM33xx patches

[Daniel Mack]

Hey,

can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?

I'm getting involved in a project that is based on a AM3352 and would
like to provide help where necessary and wanted.


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

Hey,

can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?

I'm getting involved in a project that is based on a AM3352 and would
like to provide help where necessary and wanted.


Thanks,
Daniel

Re: Current state of AM33xx patches

[Jason Kridner]

From: Daniel Mack <zonque@gmail.com>
>Hey,
>
>can anybody give me a quick wrap-up about the current state of AM33xx
>based SoCs in mainline? What are the next steps to get things merged?

There is a wiki page [1] that is intended to provide a summary, but I'm
confident it is not up-to-date.  There is also some automated testing, but
I'm not aware if any of the test results are public and I believe the
coverage is fairly limited.  Hopefully Carlos can chime in with any
information about that.

[1] 
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x
_Status 


>
>I'm getting involved in a project that is based on a AM3352 and would
>like to provide help where necessary and wanted.

Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
or Chase can reply with info about any particular subsystems that need
either review or coding.  Conversion to Device Tree is an on-going complex
area where Vaibhav is contributing.

>
>
>Thanks,
>Daniel

Current state of AM33xx patches

[Jason Kridner]

From: Daniel Mack <zonque@gmail.com>
>Hey,
>
>can anybody give me a quick wrap-up about the current state of AM33xx
>based SoCs in mainline? What are the next steps to get things merged?

There is a wiki page [1] that is intended to provide a summary, but I'm
confident it is not up-to-date.  There is also some automated testing, but
I'm not aware if any of the test results are public and I believe the
coverage is fairly limited.  Hopefully Carlos can chime in with any
information about that.

[1] 
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x
_Status 


>
>I'm getting involved in a project that is based on a AM3352 and would
>like to provide help where necessary and wanted.

Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
or Chase can reply with info about any particular subsystems that need
either review or coding.  Conversion to Device Tree is an on-going complex
area where Vaibhav is contributing.

>
>
>Thanks,
>Daniel

Re: Current state of AM33xx patches

[Vaibhav Hiremath]

On 6/11/2012 2:58 PM, Daniel Mack wrote:
> Hey,
> 
> can anybody give me a quick wrap-up about the current state of AM33xx
> based SoCs in mainline? What are the next steps to get things merged?
> 

Daniel,

We are in the process of submitting all baseport patches to the
upstream, summary would be,

Accepted:
	- Machine and low-level init code
	- Basic DT required for boot.
	- Voltagedomain, Powerdomain, clockdomain implementation

Currently under work (already submitted multiple versions):
	- Clock Tree
	- HWMOD

I do maintain wiki page which you should refer for any updates:
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status

In order to get latest and greatest kernel to boot, you can use my repo:
https://github.com/hvaibhav/am335x-linux


Also, note that, currently there will be very minimal feature-set
supported in the kernel, so not sure how much can be leveraged for
production use-cases.


> I'm getting involved in a project that is based on a AM3352 and would
> like to provide help where necessary and wanted.
> 

That's great, help is always required and appreciated.

Thanks,
Vaibhav

> 
> Thanks,
> Daniel
> 

Current state of AM33xx patches

[Vaibhav Hiremath]

On 6/11/2012 2:58 PM, Daniel Mack wrote:
> Hey,
> 
> can anybody give me a quick wrap-up about the current state of AM33xx
> based SoCs in mainline? What are the next steps to get things merged?
> 

Daniel,

We are in the process of submitting all baseport patches to the
upstream, summary would be,

Accepted:
	- Machine and low-level init code
	- Basic DT required for boot.
	- Voltagedomain, Powerdomain, clockdomain implementation

Currently under work (already submitted multiple versions):
	- Clock Tree
	- HWMOD

I do maintain wiki page which you should refer for any updates:
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status

In order to get latest and greatest kernel to boot, you can use my repo:
https://github.com/hvaibhav/am335x-linux


Also, note that, currently there will be very minimal feature-set
supported in the kernel, so not sure how much can be leveraged for
production use-cases.


> I'm getting involved in a project that is based on a AM3352 and would
> like to provide help where necessary and wanted.
> 

That's great, help is always required and appreciated.

Thanks,
Vaibhav

> 
> Thanks,
> Daniel
> 

RE: Current state of AM33xx patches

[Hernandez, Carlos]

> -----Original Message-----
> From: Jason Kridner [mailto:jkridner@gmail.com]
> Sent: Monday, June 11, 2012 9:51 AM
> To: Daniel Mack; Tony Lindgren; Hilman, Kevin; Paul Walmsley; Hiremath,
> Vaibhav; Hernandez, Carlos; Maupin, Chase
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> From: Daniel Mack <zonque@gmail.com>
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
> 
> There is a wiki page [1] that is intended to provide a summary, but I'm
> confident it is not up-to-date.  There is also some automated testing, but
> I'm not aware if any of the test results are public and I believe the
> coverage is fairly limited.  Hopefully Carlos can chime in with any
> information about that.
> 

Linux Nightly Test results are available at http://arago-project.org/testresults/linux/
Builds are currently failing due to wpa-supplicant recipe. 

The current nightly test plan includes: USB Host tests, PWM, Alsa, SPI, MMC, NAND, EDMA, Ethernet, RTC, I2C, PWM, WDT, CPUFREQ,  Timers, Kernel IPC, Math library, LMBench and cyclictest. Let us know if you want other areas to be included in the nightly test plan.
For a sample test coverage, check build from last week at
http://arago-project.org/testresults/linux/ti-staging/2012-06-05_16-05-17/am335x-evm/test-log.html

Carlos

> [1]
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335
> x
> _Status
> 
> 
> >
> >I'm getting involved in a project that is based on a AM3352 and would
> >like to provide help where necessary and wanted.
> 
> Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
> or Chase can reply with info about any particular subsystems that need
> either review or coding.  Conversion to Device Tree is an on-going complex
> area where Vaibhav is contributing.
> 
> >
> >
> >Thanks,
> >Daniel
> 

Current state of AM33xx patches

[Hernandez, Carlos]

> -----Original Message-----
> From: Jason Kridner [mailto:jkridner at gmail.com]
> Sent: Monday, June 11, 2012 9:51 AM
> To: Daniel Mack; Tony Lindgren; Hilman, Kevin; Paul Walmsley; Hiremath,
> Vaibhav; Hernandez, Carlos; Maupin, Chase
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> From: Daniel Mack <zonque@gmail.com>
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
> 
> There is a wiki page [1] that is intended to provide a summary, but I'm
> confident it is not up-to-date.  There is also some automated testing, but
> I'm not aware if any of the test results are public and I believe the
> coverage is fairly limited.  Hopefully Carlos can chime in with any
> information about that.
> 

Linux Nightly Test results are available at http://arago-project.org/testresults/linux/
Builds are currently failing due to wpa-supplicant recipe. 

The current nightly test plan includes: USB Host tests, PWM, Alsa, SPI, MMC, NAND, EDMA, Ethernet, RTC, I2C, PWM, WDT, CPUFREQ,  Timers, Kernel IPC, Math library, LMBench and cyclictest. Let us know if you want other areas to be included in the nightly test plan.
For a sample test coverage, check build from last week at
http://arago-project.org/testresults/linux/ti-staging/2012-06-05_16-05-17/am335x-evm/test-log.html

Carlos

> [1]
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335
> x
> _Status
> 
> 
> >
> >I'm getting involved in a project that is based on a AM3352 and would
> >like to provide help where necessary and wanted.
> 
> Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
> or Chase can reply with info about any particular subsystems that need
> either review or coding.  Conversion to Device Tree is an on-going complex
> area where Vaibhav is contributing.
> 
> >
> >
> >Thanks,
> >Daniel
> 

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
> From: Daniel Mack <zonque@gmail.com>
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
> 
> There is a wiki page [1] that is intended to provide a summary, but I'm
> confident it is not up-to-date.  

Page updated now...

http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status


Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
> From: Daniel Mack <zonque@gmail.com>
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
> 
> There is a wiki page [1] that is intended to provide a summary, but I'm
> confident it is not up-to-date.  

Page updated now...

http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status


Thanks,
Vaibhav

Re: Current state of AM33xx patches

[Daniel Mack]

On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>> From: Daniel Mack <zonque@gmail.com>
>>> Hey,
>>>
>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>> based SoCs in mainline? What are the next steps to get things merged?
>>
>> There is a wiki page [1] that is intended to provide a summary, but I'm
>> confident it is not up-to-date.  
> 
> Page updated now...
> 
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status

Great, thanks. So if things get upstreamed, which is the repo/branch
they appear in? In other words: where is the code people should write
patches against? I couldn't find an answer to that yet.


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>> From: Daniel Mack <zonque@gmail.com>
>>> Hey,
>>>
>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>> based SoCs in mainline? What are the next steps to get things merged?
>>
>> There is a wiki page [1] that is intended to provide a summary, but I'm
>> confident it is not up-to-date.  
> 
> Page updated now...
> 
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status

Great, thanks. So if things get upstreamed, which is the repo/branch
they appear in? In other words: where is the code people should write
patches against? I couldn't find an answer to that yet.


Thanks,
Daniel

Re: Current state of AM33xx patches

[Domenico Andreoli]

Hello,

On Mon, Jun 11, 2012 at 4:15 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote:
>
> I do maintain wiki page which you should refer for any updates:
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status
>
> In order to get latest and greatest kernel to boot, you can use my repo:
> https://github.com/hvaibhav/am335x-linux

do you have any usable defconfig? I've some trouble with the build of
this branch and I'm not sure about the configuration.

> Also, note that, currently there will be very minimal feature-set
> supported in the kernel, so not sure how much can be leveraged for
> production use-cases.

I need something that boots to userspace, nothing more (but I'm happy
to test) :)

thanks,
Domenico

Current state of AM33xx patches

[Domenico Andreoli]

Hello,

On Mon, Jun 11, 2012 at 4:15 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote:
>
> I do maintain wiki page which you should refer for any updates:
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status
>
> In order to get latest and greatest kernel to boot, you can use my repo:
> https://github.com/hvaibhav/am335x-linux

do you have any usable defconfig? I've some trouble with the build of
this branch and I'm not sure about the configuration.

> Also, note that, currently there will be very minimal feature-set
> supported in the kernel, so not sure how much can be leveraged for
> production use-cases.

I need something that boots to userspace, nothing more (but I'm happy
to test) :)

thanks,
Domenico

Re: Current state of AM33xx patches

[Daniel Mack]

On 21.06.2012 15:50, Daniel Mack wrote:
> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>>> From: Daniel Mack <zonque@gmail.com>
>>>> Hey,
>>>>
>>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>>> based SoCs in mainline? What are the next steps to get things merged?
>>>
>>> There is a wiki page [1] that is intended to provide a summary, but I'm
>>> confident it is not up-to-date.  
>>
>> Page updated now...
>>
>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
> 
> Great, thanks. So if things get upstreamed, which is the repo/branch
> they appear in? In other words: where is the code people should write
> patches against? I couldn't find an answer to that yet.

ping?

Current state of AM33xx patches

[Daniel Mack]

On 21.06.2012 15:50, Daniel Mack wrote:
> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>>> From: Daniel Mack <zonque@gmail.com>
>>>> Hey,
>>>>
>>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>>> based SoCs in mainline? What are the next steps to get things merged?
>>>
>>> There is a wiki page [1] that is intended to provide a summary, but I'm
>>> confident it is not up-to-date.  
>>
>> Page updated now...
>>
>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
> 
> Great, thanks. So if things get upstreamed, which is the repo/branch
> they appear in? In other words: where is the code people should write
> patches against? I couldn't find an answer to that yet.

ping?

Re: Current state of AM33xx patches

[Sekhar Nori]

Hi Daniel,

On 6/25/2012 11:47 PM, Daniel Mack wrote:
> On 21.06.2012 15:50, Daniel Mack wrote:
>> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
>>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>>>> From: Daniel Mack <zonque@gmail.com>
>>>>> Hey,
>>>>>
>>>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>>>> based SoCs in mainline? What are the next steps to get things merged?
>>>>
>>>> There is a wiki page [1] that is intended to provide a summary, but I'm
>>>> confident it is not up-to-date.  
>>>
>>> Page updated now...
>>>
>>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
>>
>> Great, thanks. So if things get upstreamed, which is the repo/branch
>> they appear in? In other words: where is the code people should write
>> patches against? I couldn't find an answer to that yet.
> 
> ping?

Bug fixes are always accepted against Linus's tree[1].

For features, typically there is a -next branch that each subsystem
maintainer has against which feature development happens. In case of
OMAP, feature development happens against master branch of linux-omap
tree[2]. One way to get to know the -next branches of all subsystem is
to look at Next/Trees file of linux-next tree[3].

Note that in case of ARM, sub-arch maintainers send the code to arm-soc
maintainers who in turn have a branch which gets merged to linux-next.

Hope that helps.

Thanks,
Sekhar

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git
[2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git
[3] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

Current state of AM33xx patches

[Sekhar Nori]

Hi Daniel,

On 6/25/2012 11:47 PM, Daniel Mack wrote:
> On 21.06.2012 15:50, Daniel Mack wrote:
>> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
>>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
>>>> From: Daniel Mack <zonque@gmail.com>
>>>>> Hey,
>>>>>
>>>>> can anybody give me a quick wrap-up about the current state of AM33xx
>>>>> based SoCs in mainline? What are the next steps to get things merged?
>>>>
>>>> There is a wiki page [1] that is intended to provide a summary, but I'm
>>>> confident it is not up-to-date.  
>>>
>>> Page updated now...
>>>
>>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
>>
>> Great, thanks. So if things get upstreamed, which is the repo/branch
>> they appear in? In other words: where is the code people should write
>> patches against? I couldn't find an answer to that yet.
> 
> ping?

Bug fixes are always accepted against Linus's tree[1].

For features, typically there is a -next branch that each subsystem
maintainer has against which feature development happens. In case of
OMAP, feature development happens against master branch of linux-omap
tree[2]. One way to get to know the -next branches of all subsystem is
to look at Next/Trees file of linux-next tree[3].

Note that in case of ARM, sub-arch maintainers send the code to arm-soc
maintainers who in turn have a branch which gets merged to linux-next.

Hope that helps.

Thanks,
Sekhar

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git
[2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git
[3] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Sat, Jun 23, 2012 at 18:33:13, Domenico Andreoli wrote:
> Hello,
> 
> On Mon, Jun 11, 2012 at 4:15 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote:
> >
> > I do maintain wiki page which you should refer for any updates:
> > http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status
> >
> > In order to get latest and greatest kernel to boot, you can use my repo:
> > https://github.com/hvaibhav/am335x-linux
> 
> do you have any usable defconfig? I've some trouble with the build of
> this branch and I'm not sure about the configuration.
> 
> > Also, note that, currently there will be very minimal feature-set
> > supported in the kernel, so not sure how much can be leveraged for
> > production use-cases.
> 
> I need something that boots to userspace, nothing more (but I'm happy
> to test) :)
> 

Sorry for delayed response, I went out of station, supposed to come back on 
Monday itself but due to some known reason couldn't make it. I have just 
resumed my work today. Sorry for inconvenience...

Coming back to your question,

Omap2plus_defconfig should work for you, you should get linux prompt with 
ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 

Build Steps:
============
 - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
 - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
 - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
 - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
   (Since I am not using DT aware u-boot)

Use the ramdisk image to boot kernel, since we do not have support for any 
storage devices in the mainline.

U-Boot commands to boot:
========================
setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
boot


Hope this will help you to boot the kernel on BeagleBone.

Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Sat, Jun 23, 2012 at 18:33:13, Domenico Andreoli wrote:
> Hello,
> 
> On Mon, Jun 11, 2012 at 4:15 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote:
> >
> > I do maintain wiki page which you should refer for any updates:
> > http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status
> >
> > In order to get latest and greatest kernel to boot, you can use my repo:
> > https://github.com/hvaibhav/am335x-linux
> 
> do you have any usable defconfig? I've some trouble with the build of
> this branch and I'm not sure about the configuration.
> 
> > Also, note that, currently there will be very minimal feature-set
> > supported in the kernel, so not sure how much can be leveraged for
> > production use-cases.
> 
> I need something that boots to userspace, nothing more (but I'm happy
> to test) :)
> 

Sorry for delayed response, I went out of station, supposed to come back on 
Monday itself but due to some known reason couldn't make it. I have just 
resumed my work today. Sorry for inconvenience...

Coming back to your question,

Omap2plus_defconfig should work for you, you should get linux prompt with 
ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 

Build Steps:
============
 - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
 - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
 - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
 - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
   (Since I am not using DT aware u-boot)

Use the ramdisk image to boot kernel, since we do not have support for any 
storage devices in the mainline.

U-Boot commands to boot:
========================
setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
boot


Hope this will help you to boot the kernel on BeagleBone.

Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Tue, Jun 26, 2012 at 17:12:03, Nori, Sekhar wrote:
> Hi Daniel,
> 
> On 6/25/2012 11:47 PM, Daniel Mack wrote:
> > On 21.06.2012 15:50, Daniel Mack wrote:
> >> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
> >>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
> >>>> From: Daniel Mack <zonque@gmail.com>
> >>>>> Hey,
> >>>>>
> >>>>> can anybody give me a quick wrap-up about the current state of AM33xx
> >>>>> based SoCs in mainline? What are the next steps to get things merged?
> >>>>
> >>>> There is a wiki page [1] that is intended to provide a summary, but I'm
> >>>> confident it is not up-to-date.  
> >>>
> >>> Page updated now...
> >>>
> >>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
> >>
> >> Great, thanks. So if things get upstreamed, which is the repo/branch
> >> they appear in? In other words: where is the code people should write
> >> patches against? I couldn't find an answer to that yet.
> > 
> > ping?
> 
> Bug fixes are always accepted against Linus's tree[1].
> 
> For features, typically there is a -next branch that each subsystem
> maintainer has against which feature development happens. In case of
> OMAP, feature development happens against master branch of linux-omap
> tree[2]. One way to get to know the -next branches of all subsystem is
> to look at Next/Trees file of linux-next tree[3].
> 
> Note that in case of ARM, sub-arch maintainers send the code to arm-soc
> maintainers who in turn have a branch which gets merged to linux-next.
> 
> Hope that helps.
> 

Just to clarify from AM335x perspective,

In case of AM335x, since the patches and complete BasePort support is still
not present in the Mainline (neither in Linus's tree not in linux-omap), you 
need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
omap/master) in order to test something on BeagleBone platform.

Once we have all bits-n-pieces accepted/merged in the mainline, then all the 
above process must be followed for patch submission.


Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Tue, Jun 26, 2012 at 17:12:03, Nori, Sekhar wrote:
> Hi Daniel,
> 
> On 6/25/2012 11:47 PM, Daniel Mack wrote:
> > On 21.06.2012 15:50, Daniel Mack wrote:
> >> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
> >>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
> >>>> From: Daniel Mack <zonque@gmail.com>
> >>>>> Hey,
> >>>>>
> >>>>> can anybody give me a quick wrap-up about the current state of AM33xx
> >>>>> based SoCs in mainline? What are the next steps to get things merged?
> >>>>
> >>>> There is a wiki page [1] that is intended to provide a summary, but I'm
> >>>> confident it is not up-to-date.  
> >>>
> >>> Page updated now...
> >>>
> >>> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status
> >>
> >> Great, thanks. So if things get upstreamed, which is the repo/branch
> >> they appear in? In other words: where is the code people should write
> >> patches against? I couldn't find an answer to that yet.
> > 
> > ping?
> 
> Bug fixes are always accepted against Linus's tree[1].
> 
> For features, typically there is a -next branch that each subsystem
> maintainer has against which feature development happens. In case of
> OMAP, feature development happens against master branch of linux-omap
> tree[2]. One way to get to know the -next branches of all subsystem is
> to look at Next/Trees file of linux-next tree[3].
> 
> Note that in case of ARM, sub-arch maintainers send the code to arm-soc
> maintainers who in turn have a branch which gets merged to linux-next.
> 
> Hope that helps.
> 

Just to clarify from AM335x perspective,

In case of AM335x, since the patches and complete BasePort support is still
not present in the Mainline (neither in Linus's tree not in linux-omap), you 
need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
omap/master) in order to test something on BeagleBone platform.

Once we have all bits-n-pieces accepted/merged in the mainline, then all the 
above process must be followed for patch submission.


Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Paul Walmsley]

Hi Vaibhav

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> Build Steps:
> ============
>  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
>  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
>  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
>  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
>    (Since I am not using DT aware u-boot)
> 
> Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline.
> 
> U-Boot commands to boot:
> ========================
> setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> boot
> 
> 
> Hope this will help you to boot the kernel on BeagleBone.

Was anyone else able to get this to work?

I tried these steps here but with one difference: I put the U-boot 
commands into the uEnv.txt file:

optargs=mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial ignore_loglevel debug
uenvcmd=mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000

Unfortunately the kernel did not boot.  The log is at the bottom of this 
file.  I did verify in U-boot that the commands were being executed 
correctly by walking through them by hand.

The branch used was your am335x-upstream-staging branch, plus a minor 
patch to allow the kernel to build on an am335x-only config (although for 
the purposes of this test, omap2plus_defconfig was used).

This is on a BeagleBone A3, using gcc version 4.5.1 (Sourcery G++ Lite 
2010.09-50).

Enabling CONFIG_EARLY_PRINTK doesn't make any difference, which isn't too 
surprising since there's no output from the kernel at all.  
Unfortunately, I don't have the time to do in-depth troubleshooting here 
with JTAG.

Any thoughts? 


- Paul


No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: second ID read did not match 10,10 against 00,00
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0 
SD/MMC found on device 0
reading uEnv.txt

224 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading uImage

3819902 bytes read
reading ramdisk-pm.gz

2013059 bytes read
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11828-ge2b3dd1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3819838 Bytes = 3.6 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Current state of AM33xx patches

[Paul Walmsley]

Hi Vaibhav

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> Build Steps:
> ============
>  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
>  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
>  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
>  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
>    (Since I am not using DT aware u-boot)
> 
> Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline.
> 
> U-Boot commands to boot:
> ========================
> setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> boot
> 
> 
> Hope this will help you to boot the kernel on BeagleBone.

Was anyone else able to get this to work?

I tried these steps here but with one difference: I put the U-boot 
commands into the uEnv.txt file:

optargs=mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial ignore_loglevel debug
uenvcmd=mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000

Unfortunately the kernel did not boot.  The log is at the bottom of this 
file.  I did verify in U-boot that the commands were being executed 
correctly by walking through them by hand.

The branch used was your am335x-upstream-staging branch, plus a minor 
patch to allow the kernel to build on an am335x-only config (although for 
the purposes of this test, omap2plus_defconfig was used).

This is on a BeagleBone A3, using gcc version 4.5.1 (Sourcery G++ Lite 
2010.09-50).

Enabling CONFIG_EARLY_PRINTK doesn't make any difference, which isn't too 
surprising since there's no output from the kernel at all.  
Unfortunately, I don't have the time to do in-depth troubleshooting here 
with JTAG.

Any thoughts? 


- Paul


No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: second ID read did not match 10,10 against 00,00
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0 
SD/MMC found on device 0
reading uEnv.txt

224 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading uImage

3819902 bytes read
reading ramdisk-pm.gz

2013059 bytes read
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11828-ge2b3dd1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3819838 Bytes = 3.6 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> Hi Vaibhav
> 
> On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > Build Steps:
> > ============
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
> >  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
> >    (Since I am not using DT aware u-boot)
> > 
> > Use the ramdisk image to boot kernel, since we do not have support for any 
> > storage devices in the mainline.
> > 
> > U-Boot commands to boot:
> > ========================
> > setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> > setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> > boot
> > 
> > 
> > Hope this will help you to boot the kernel on BeagleBone.
> 
> Was anyone else able to get this to work?
> 
> I tried these steps here but with one difference: I put the U-boot 
> commands into the uEnv.txt file:
> 
> optargs=mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial ignore_loglevel debug
> uenvcmd=mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000
> 
> Unfortunately the kernel did not boot.  The log is at the bottom of this 
> file.  I did verify in U-boot that the commands were being executed 
> correctly by walking through them by hand.
> 
> The branch used was your am335x-upstream-staging branch, plus a minor 
> patch to allow the kernel to build on an am335x-only config (although for 
> the purposes of this test, omap2plus_defconfig was used).
> 
> This is on a BeagleBone A3, using gcc version 4.5.1 (Sourcery G++ Lite 
> 2010.09-50).
> 
> Enabling CONFIG_EARLY_PRINTK doesn't make any difference, which isn't too 
> surprising since there's no output from the kernel at all.  
> Unfortunately, I don't have the time to do in-depth troubleshooting here 
> with JTAG.
> 
> Any thoughts? 
> 
> 
> - Paul
> 
> 
> No daughter card present
> NAND:  HW ECC Hamming Code selected
> nand_get_flash_type: second ID read did not match 10,10 against 00,00
> No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - readenv() failed, using default environment
> 
> Net:   cpsw
> Hit any key to stop autoboot:  0 
> SD/MMC found on device 0
> reading uEnv.txt
> 
> 224 bytes read
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> Running uenvcmd ...
> reading uImage
> 
> 3819902 bytes read
> reading ramdisk-pm.gz
> 
> 2013059 bytes read
> ## Booting kernel from Legacy Image at 81000000 ...
>    Image Name:   Linux-3.5.0-rc1-11828-ge2b3dd1

Something seems to be wrong here???
The HEAD is,

commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Thu Jun 21 12:33:58 2012 +0530

    arm/dts: Add support for AM335x BeagleBone





>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    3819838 Bytes = 3.6 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 

I just checked out  am335x-upstream-staging branch and tested it on my 
BeagleBone (A2: Available at my home :)) and below is exact log -



U-Boot SPL 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
Texas Instruments Revision detection unimplemented
No AC power, disabling frequency switch
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
No daughter card present
NAND:  HW ECC Hamming Code selected
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 81000000 uImage-dtb.am335x-evm
reading uImage-dtb.am335x-evm

3539030 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz

2022580 bytes read
U-Boot# bootm 81000000
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11827-g67e68668
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3538966 Bytes = 3.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.5.0-rc1-11827-g67e68668 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #2 SMP Thu Jun 28 00:20:09 IST 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM
[    0.000000] cma: CMA: reserved 16 MiB at 86800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0d74000 s11520 r8192 d13056 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32256
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 127MB = 127MB total
[    0.000000] Memory: 83336k/83336k available, 47736k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0626de4   (6268 kB)
[    0.000000]       .init : 0xc0627000 - 0xc0675d00   ( 316 kB)
[    0.000000]       .data : 0xc0676000 - 0xc0713570   ( 630 kB)
[    0.000000]        .bss : 0xc0713594 - 0xc0c6be08   (5475 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.084516] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504)
[    0.084576] pid_max: default: 32768 minimum: 301
[    0.085432] Security Framework initialized
[    0.085748] Mount-cache hash table entries: 512
[    0.095464] CPU: Testing write buffer coherency: ok
[    0.096364] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.096449] Setting up static identity map for 0x80462f40 - 0x80462fb0
[    0.098490] Brought up 1 CPUs
[    0.098516] SMP: Total of 1 processors activated (497.82 BogoMIPS).
[    0.117332] initlevel:0=early, 4 registered initcalls
[    0.117665] initlevel:1=core, 24 registered initcalls
[    0.130683] dummy:
[    0.134998] NET: Registered protocol family 16
[    0.135304] initlevel:2=postcore, 19 registered initcalls
[    0.142535] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.142688] GPMC revision 6.0
[    0.143016] gpmc: irq-20 could not claim: err -22
[    0.153262] initlevel:3=arch, 16 registered initcalls
[    0.172916] OMAP GPIO hardware version 0.1
[    0.195147] No ATAGs?
[    0.195151] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.205297] initlevel:4=subsys, 43 registered initcalls
[    0.287496] bio: create slab <bio-0> at 0
[    0.300794] SCSI subsystem initialized
[    0.304330] usbcore: registered new interface driver usbfs
[    0.305038] usbcore: registered new interface driver hub
[    0.306050] usbcore: registered new device driver usb
[    0.319859] omap_i2c i2c.13: bus -1 rev2.4.0 at 100 kHz
[    0.334853] omap_i2c i2c.14: bus -1 rev2.4.0 at 100 kHz
[    0.350436] omap_i2c i2c.15: bus -1 rev2.4.0 at 100 kHz
[    0.360856] initlevel:5=fs, 20 registered initcalls
[    0.361166] Switching to clocksource gp_timer
[    0.504744] NET: Registered protocol family 2
[    0.505845] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.508384] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.508770] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.511973] TCP: Hash tables configured (established 4096 bind 4096)
[    0.512104] TCP: reno registered
[    0.512147] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.512524] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.513677] NET: Registered protocol family 1
[    0.515562] RPC: Registered named UNIX socket transport module.
[    0.515591] RPC: Registered udp transport module.
[    0.515607] RPC: Registered tcp transport module.
[    0.515622] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.516772] Trying to unpack rootfs image as initramfs...
[    0.519750] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.662323] Freeing initrd memory: 16384K
[    0.662364] initlevel:6=device, 185 registered initcalls
[    0.662555] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.871407] VFS: Disk quotas dquot_6.5.2
[    0.871803] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.873851] NFS: Registering the id_resolver key type
[    0.874506] Key type id_resolver registered
[    0.876183] jffs2: version 2.2. (NAND) (SUMMARY)  (c) 2001-2006 Red Hat, Inc.
[    0.877974] msgmni has been set to 226
[    0.882385] io scheduler noop registered
[    0.882412] io scheduler deadline registered
[    0.882717] io scheduler cfq registered (default)
[    0.886088] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.895186] serial.7: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[    1.505204] console [ttyO0] enabled
[    1.511448] serial.8: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
[    1.520916] serial.9: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
[    1.530074] serial.10: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
[    1.539284] omap_uart serial.11: [UART-1]: failure [serial_omap_probe]: -22
[    1.546851] omap_uart: probe of serial.11 failed with error -22
[    1.553620] omap_uart serial.12: [UART-1]: failure [serial_omap_probe]: -22
[    1.561142] omap_uart: probe of serial.12 failed with error -22
[    1.608820] brd: module loaded
[    1.637652] loop: module loaded
[    1.648624] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.656752] OneNAND driver initializing
[    1.674491] usbcore: registered new interface driver asix
[    1.680906] usbcore: registered new interface driver cdc_ether
[    1.688183] usbcore: registered new interface driver smsc95xx
[    1.695038] usbcore: registered new interface driver net1080
[    1.701812] usbcore: registered new interface driver cdc_subset
[    1.708799] usbcore: registered new interface driver zaurus
[    1.715502] usbcore: registered new interface driver cdc_ncm
[    1.723580] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.732223] usbcore: registered new interface driver cdc_wdm
[    1.738381] Initializing USB Mass Storage driver...
[    1.744253] usbcore: registered new interface driver usb-storage
[    1.750756] USB Mass Storage support registered.
[    1.757147] usbcore: registered new interface driver libusual
[    1.764115] usbcore: registered new interface driver usbtest
[    1.772211] mousedev: PS/2 mouse device common for all mice
[    1.783856] i2c /dev entries driver
[    1.792566] Driver for 1-wire Dallas network protocol.
[    1.802176] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.814226] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.862284] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.876636] mmc0: host doesn't support card's voltages
[    1.882177] mmc0: error -22 whilst initialising SD card
[    1.917083] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.977688] usbcore: registered new interface driver usbhid
[    1.983724] usbhid: USB HID core driver
[    1.988349] oprofile: hardware counters not available
[    1.993683] oprofile: using timer interrupt.
[    1.999300] TCP: cubic registered
[    2.003296] Initializing XFRM netlink socket
[    2.007966] NET: Registered protocol family 17
[    2.012873] NET: Registered protocol family 15
[    2.018181] Key type dns_resolver registered
[    2.022711] initlevel:7=late, 26 registered initcalls
[    2.028304] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.036550] ThumbEE CPU extension supported.
[    2.054622] clock: disabling unused clocks to save power
[    2.068584] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.079800] RAMDISK: gzip image found at block 0
[    2.599286] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.606462] Freeing init memory: 312K
mount: mounting none on /var/shm failed: No such file or directory
  ::
  :: Enabling hot-plug  : [SUCCESS]
  ::
  ::
   : Populating /dev    : [SUCCESS]
[SUCCESS]
  ::
  ::
  :: Setting PATH
  ::
   : syslogd            : [SUCCESS]
   : telnetd            : [SUCCESS]

Please press Enter to activate this console.
  ::
  :: Setting shell environment ...
  ::
   : Path
   : Aliases
   : Touch Screen
  ::
  :: Done
  ::
[root@arago /]#

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> Hi Vaibhav
> 
> On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > Build Steps:
> > ============
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
> >  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
> >    (Since I am not using DT aware u-boot)
> > 
> > Use the ramdisk image to boot kernel, since we do not have support for any 
> > storage devices in the mainline.
> > 
> > U-Boot commands to boot:
> > ========================
> > setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> > setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> > boot
> > 
> > 
> > Hope this will help you to boot the kernel on BeagleBone.
> 
> Was anyone else able to get this to work?
> 
> I tried these steps here but with one difference: I put the U-boot 
> commands into the uEnv.txt file:
> 
> optargs=mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial ignore_loglevel debug
> uenvcmd=mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000
> 
> Unfortunately the kernel did not boot.  The log is at the bottom of this 
> file.  I did verify in U-boot that the commands were being executed 
> correctly by walking through them by hand.
> 
> The branch used was your am335x-upstream-staging branch, plus a minor 
> patch to allow the kernel to build on an am335x-only config (although for 
> the purposes of this test, omap2plus_defconfig was used).
> 
> This is on a BeagleBone A3, using gcc version 4.5.1 (Sourcery G++ Lite 
> 2010.09-50).
> 
> Enabling CONFIG_EARLY_PRINTK doesn't make any difference, which isn't too 
> surprising since there's no output from the kernel at all.  
> Unfortunately, I don't have the time to do in-depth troubleshooting here 
> with JTAG.
> 
> Any thoughts? 
> 
> 
> - Paul
> 
> 
> No daughter card present
> NAND:  HW ECC Hamming Code selected
> nand_get_flash_type: second ID read did not match 10,10 against 00,00
> No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - readenv() failed, using default environment
> 
> Net:   cpsw
> Hit any key to stop autoboot:  0 
> SD/MMC found on device 0
> reading uEnv.txt
> 
> 224 bytes read
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> Running uenvcmd ...
> reading uImage
> 
> 3819902 bytes read
> reading ramdisk-pm.gz
> 
> 2013059 bytes read
> ## Booting kernel from Legacy Image at 81000000 ...
>    Image Name:   Linux-3.5.0-rc1-11828-ge2b3dd1

Something seems to be wrong here???
The HEAD is,

commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
Author: AnilKumar Ch <anilkumar@ti.com>
Date:   Thu Jun 21 12:33:58 2012 +0530

    arm/dts: Add support for AM335x BeagleBone





>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    3819838 Bytes = 3.6 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 

I just checked out  am335x-upstream-staging branch and tested it on my 
BeagleBone (A2: Available at my home :)) and below is exact log -



U-Boot SPL 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
Texas Instruments Revision detection unimplemented
No AC power, disabling frequency switch
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
No daughter card present
NAND:  HW ECC Hamming Code selected
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 81000000 uImage-dtb.am335x-evm
reading uImage-dtb.am335x-evm

3539030 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz

2022580 bytes read
U-Boot# bootm 81000000
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11827-g67e68668
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3538966 Bytes = 3.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.5.0-rc1-11827-g67e68668 (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #2 SMP Thu Jun 28 00:20:09 IST 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM
[    0.000000] cma: CMA: reserved 16 MiB at 86800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0d74000 s11520 r8192 d13056 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32256
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 127MB = 127MB total
[    0.000000] Memory: 83336k/83336k available, 47736k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0626de4   (6268 kB)
[    0.000000]       .init : 0xc0627000 - 0xc0675d00   ( 316 kB)
[    0.000000]       .data : 0xc0676000 - 0xc0713570   ( 630 kB)
[    0.000000]        .bss : 0xc0713594 - 0xc0c6be08   (5475 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.084516] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504)
[    0.084576] pid_max: default: 32768 minimum: 301
[    0.085432] Security Framework initialized
[    0.085748] Mount-cache hash table entries: 512
[    0.095464] CPU: Testing write buffer coherency: ok
[    0.096364] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.096449] Setting up static identity map for 0x80462f40 - 0x80462fb0
[    0.098490] Brought up 1 CPUs
[    0.098516] SMP: Total of 1 processors activated (497.82 BogoMIPS).
[    0.117332] initlevel:0=early, 4 registered initcalls
[    0.117665] initlevel:1=core, 24 registered initcalls
[    0.130683] dummy:
[    0.134998] NET: Registered protocol family 16
[    0.135304] initlevel:2=postcore, 19 registered initcalls
[    0.142535] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.142688] GPMC revision 6.0
[    0.143016] gpmc: irq-20 could not claim: err -22
[    0.153262] initlevel:3=arch, 16 registered initcalls
[    0.172916] OMAP GPIO hardware version 0.1
[    0.195147] No ATAGs?
[    0.195151] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.205297] initlevel:4=subsys, 43 registered initcalls
[    0.287496] bio: create slab <bio-0> at 0
[    0.300794] SCSI subsystem initialized
[    0.304330] usbcore: registered new interface driver usbfs
[    0.305038] usbcore: registered new interface driver hub
[    0.306050] usbcore: registered new device driver usb
[    0.319859] omap_i2c i2c.13: bus -1 rev2.4.0 at 100 kHz
[    0.334853] omap_i2c i2c.14: bus -1 rev2.4.0 at 100 kHz
[    0.350436] omap_i2c i2c.15: bus -1 rev2.4.0 at 100 kHz
[    0.360856] initlevel:5=fs, 20 registered initcalls
[    0.361166] Switching to clocksource gp_timer
[    0.504744] NET: Registered protocol family 2
[    0.505845] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.508384] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.508770] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.511973] TCP: Hash tables configured (established 4096 bind 4096)
[    0.512104] TCP: reno registered
[    0.512147] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.512524] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.513677] NET: Registered protocol family 1
[    0.515562] RPC: Registered named UNIX socket transport module.
[    0.515591] RPC: Registered udp transport module.
[    0.515607] RPC: Registered tcp transport module.
[    0.515622] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.516772] Trying to unpack rootfs image as initramfs...
[    0.519750] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.662323] Freeing initrd memory: 16384K
[    0.662364] initlevel:6=device, 185 registered initcalls
[    0.662555] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.871407] VFS: Disk quotas dquot_6.5.2
[    0.871803] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.873851] NFS: Registering the id_resolver key type
[    0.874506] Key type id_resolver registered
[    0.876183] jffs2: version 2.2. (NAND) (SUMMARY)  (c) 2001-2006 Red Hat, Inc.
[    0.877974] msgmni has been set to 226
[    0.882385] io scheduler noop registered
[    0.882412] io scheduler deadline registered
[    0.882717] io scheduler cfq registered (default)
[    0.886088] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.895186] serial.7: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[    1.505204] console [ttyO0] enabled
[    1.511448] serial.8: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
[    1.520916] serial.9: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
[    1.530074] serial.10: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
[    1.539284] omap_uart serial.11: [UART-1]: failure [serial_omap_probe]: -22
[    1.546851] omap_uart: probe of serial.11 failed with error -22
[    1.553620] omap_uart serial.12: [UART-1]: failure [serial_omap_probe]: -22
[    1.561142] omap_uart: probe of serial.12 failed with error -22
[    1.608820] brd: module loaded
[    1.637652] loop: module loaded
[    1.648624] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.656752] OneNAND driver initializing
[    1.674491] usbcore: registered new interface driver asix
[    1.680906] usbcore: registered new interface driver cdc_ether
[    1.688183] usbcore: registered new interface driver smsc95xx
[    1.695038] usbcore: registered new interface driver net1080
[    1.701812] usbcore: registered new interface driver cdc_subset
[    1.708799] usbcore: registered new interface driver zaurus
[    1.715502] usbcore: registered new interface driver cdc_ncm
[    1.723580] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.732223] usbcore: registered new interface driver cdc_wdm
[    1.738381] Initializing USB Mass Storage driver...
[    1.744253] usbcore: registered new interface driver usb-storage
[    1.750756] USB Mass Storage support registered.
[    1.757147] usbcore: registered new interface driver libusual
[    1.764115] usbcore: registered new interface driver usbtest
[    1.772211] mousedev: PS/2 mouse device common for all mice
[    1.783856] i2c /dev entries driver
[    1.792566] Driver for 1-wire Dallas network protocol.
[    1.802176] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.814226] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.862284] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.876636] mmc0: host doesn't support card's voltages
[    1.882177] mmc0: error -22 whilst initialising SD card
[    1.917083] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.977688] usbcore: registered new interface driver usbhid
[    1.983724] usbhid: USB HID core driver
[    1.988349] oprofile: hardware counters not available
[    1.993683] oprofile: using timer interrupt.
[    1.999300] TCP: cubic registered
[    2.003296] Initializing XFRM netlink socket
[    2.007966] NET: Registered protocol family 17
[    2.012873] NET: Registered protocol family 15
[    2.018181] Key type dns_resolver registered
[    2.022711] initlevel:7=late, 26 registered initcalls
[    2.028304] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.036550] ThumbEE CPU extension supported.
[    2.054622] clock: disabling unused clocks to save power
[    2.068584] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.079800] RAMDISK: gzip image found at block 0
[    2.599286] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.606462] Freeing init memory: 312K
mount: mounting none on /var/shm failed: No such file or directory
  ::
  :: Enabling hot-plug  : [SUCCESS]
  ::
  ::
   : Populating /dev    : [SUCCESS]
[SUCCESS]
  ::
  ::
  :: Setting PATH
  ::
   : syslogd            : [SUCCESS]
   : telnetd            : [SUCCESS]

Please press Enter to activate this console.
  ::
  :: Setting shell environment ...
  ::
   : Path
   : Aliases
   : Touch Screen
  ::
  :: Done
  ::
[root at arago /]#

RE: Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> > On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> > 
> > The branch used was your am335x-upstream-staging branch, plus a minor 
> > patch to allow the kernel to build on an am335x-only config (although for 
> > the purposes of this test, omap2plus_defconfig was used).
>
> Something seems to be wrong here???
> The HEAD is,
> 
> commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
> Author: AnilKumar Ch <anilkumar@ti.com>
> Date:   Thu Jun 21 12:33:58 2012 +0530
> 
>     arm/dts: Add support for AM335x BeagleBone

As I wrote earlier, there's an extra patch on there to get a kernel built 
with an AM33xx-only config to link, used here for build testing.  It 
shouldn't affect the kernel's ability to start at all.  It's included 
below.


- Paul

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d09ccc1..e6f4117 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -385,8 +385,12 @@ void __init omap2430_init_late(void)
 /*
  * Currently only board-omap3beagle.c should call this because of the
  * same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
+ *
+ * XXX Due to the fact that the 33xx machine_init section is incorrectly
+ * incorporated as part of an AM35xx board file, we had to expand the
+ * following test to include CONFIG_SOC_AM33XX :-(
  */
-#ifdef CONFIG_SOC_OMAP3430
+#if defined(CONFIG_SOC_OMAP3430) || defined(CONFIG_SOC_AM33XX)
 void __init omap3_init_early(void)
 {
        omap2_set_globals_3xxx();

Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> > On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> > 
> > The branch used was your am335x-upstream-staging branch, plus a minor 
> > patch to allow the kernel to build on an am335x-only config (although for 
> > the purposes of this test, omap2plus_defconfig was used).
>
> Something seems to be wrong here???
> The HEAD is,
> 
> commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
> Author: AnilKumar Ch <anilkumar@ti.com>
> Date:   Thu Jun 21 12:33:58 2012 +0530
> 
>     arm/dts: Add support for AM335x BeagleBone

As I wrote earlier, there's an extra patch on there to get a kernel built 
with an AM33xx-only config to link, used here for build testing.  It 
shouldn't affect the kernel's ability to start at all.  It's included 
below.


- Paul

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d09ccc1..e6f4117 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -385,8 +385,12 @@ void __init omap2430_init_late(void)
 /*
  * Currently only board-omap3beagle.c should call this because of the
  * same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
+ *
+ * XXX Due to the fact that the 33xx machine_init section is incorrectly
+ * incorporated as part of an AM35xx board file, we had to expand the
+ * following test to include CONFIG_SOC_AM33XX :-(
  */
-#ifdef CONFIG_SOC_OMAP3430
+#if defined(CONFIG_SOC_OMAP3430) || defined(CONFIG_SOC_AM33XX)
 void __init omap3_init_early(void)
 {
        omap2_set_globals_3xxx();

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 00:42:16, Paul Walmsley wrote:
> On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> > > On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> > > 
> > > The branch used was your am335x-upstream-staging branch, plus a minor 
> > > patch to allow the kernel to build on an am335x-only config (although for 
> > > the purposes of this test, omap2plus_defconfig was used).
> >
> > Something seems to be wrong here???
> > The HEAD is,
> > 
> > commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
> > Author: AnilKumar Ch <anilkumar@ti.com>
> > Date:   Thu Jun 21 12:33:58 2012 +0530
> > 
> >     arm/dts: Add support for AM335x BeagleBone
> 
> As I wrote earlier, there's an extra patch on there to get a kernel built 
> with an AM33xx-only config to link, used here for build testing.  It 
> shouldn't affect the kernel's ability to start at all.  It's included 
> below.
> 
> 
> - Paul
> 
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index d09ccc1..e6f4117 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -385,8 +385,12 @@ void __init omap2430_init_late(void)
>  /*
>   * Currently only board-omap3beagle.c should call this because of the
>   * same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
> + *
> + * XXX Due to the fact that the 33xx machine_init section is incorrectly
> + * incorporated as part of an AM35xx board file, we had to expand the
> + * following test to include CONFIG_SOC_AM33XX :-(
>   */
> -#ifdef CONFIG_SOC_OMAP3430
> +#if defined(CONFIG_SOC_OMAP3430) || defined(CONFIG_SOC_AM33XX)
>  void __init omap3_init_early(void)
>  {
>         omap2_set_globals_3xxx();
> 
> 

Shouldn't impact, but  still will apply now...will update you on this.
Can you also share me the .config file of yours??

Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 00:42:16, Paul Walmsley wrote:
> On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
> > > On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
> > > 
> > > The branch used was your am335x-upstream-staging branch, plus a minor 
> > > patch to allow the kernel to build on an am335x-only config (although for 
> > > the purposes of this test, omap2plus_defconfig was used).
> >
> > Something seems to be wrong here???
> > The HEAD is,
> > 
> > commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
> > Author: AnilKumar Ch <anilkumar@ti.com>
> > Date:   Thu Jun 21 12:33:58 2012 +0530
> > 
> >     arm/dts: Add support for AM335x BeagleBone
> 
> As I wrote earlier, there's an extra patch on there to get a kernel built 
> with an AM33xx-only config to link, used here for build testing.  It 
> shouldn't affect the kernel's ability to start at all.  It's included 
> below.
> 
> 
> - Paul
> 
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index d09ccc1..e6f4117 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -385,8 +385,12 @@ void __init omap2430_init_late(void)
>  /*
>   * Currently only board-omap3beagle.c should call this because of the
>   * same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
> + *
> + * XXX Due to the fact that the 33xx machine_init section is incorrectly
> + * incorporated as part of an AM35xx board file, we had to expand the
> + * following test to include CONFIG_SOC_AM33XX :-(
>   */
> -#ifdef CONFIG_SOC_OMAP3430
> +#if defined(CONFIG_SOC_OMAP3430) || defined(CONFIG_SOC_AM33XX)
>  void __init omap3_init_early(void)
>  {
>         omap2_set_globals_3xxx();
> 
> 

Shouldn't impact, but  still will apply now...will update you on this.
Can you also share me the .config file of yours??

Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> Shouldn't impact, but  still will apply now...will update you on this.
> Can you also share me the .config file of yours??

Just sent it to you via private E-mail.  It's just omap2plus_defconfig 
plus the two DT-related config options that you mentioned.

One other minor comment, the kernel build system wouldn't build a kernel 
following the exact sequence of steps that you mentioned earlier.  Rather 
than building uImage-dtb.am335x-evm as a direct target, first I had to 
build the uImage.


- Paul

Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> Shouldn't impact, but  still will apply now...will update you on this.
> Can you also share me the .config file of yours??

Just sent it to you via private E-mail.  It's just omap2plus_defconfig 
plus the two DT-related config options that you mentioned.

One other minor comment, the kernel build system wouldn't build a kernel 
following the exact sequence of steps that you mentioned earlier.  Rather 
than building uImage-dtb.am335x-evm as a direct target, first I had to 
build the uImage.


- Paul

RE: Current state of AM33xx patches

[Paul Walmsley]

Hi Vaibhav,

By the way, maybe you could post a kernel image somewhere that we could 
test-boot?


- Paul

Current state of AM33xx patches

[Paul Walmsley]

Hi Vaibhav,

By the way, maybe you could post a kernel image somewhere that we could 
test-boot?


- Paul

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 01:30:30, Paul Walmsley wrote:
> Hi Vaibhav,
> 
> By the way, maybe you could post a kernel image somewhere that we could 
> test-boot?
> 

Is it accessible - http://uploadingit.com/folder/z1uttvfpr6fgjvzl/Home%20Folder


Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 01:30:30, Paul Walmsley wrote:
> Hi Vaibhav,
> 
> By the way, maybe you could post a kernel image somewhere that we could 
> test-boot?
> 

Is it accessible - http://uploadingit.com/folder/z1uttvfpr6fgjvzl/Home%20Folder


Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> On Thu, Jun 28, 2012 at 01:30:30, Paul Walmsley wrote:
> > Hi Vaibhav,
> > 
> > By the way, maybe you could post a kernel image somewhere that we could 
> > test-boot?
> > 
> 
> Is it accessible - http://uploadingit.com/folder/z1uttvfpr6fgjvzl/Home%20Folder

Just tried the kernel from this; no luck.

Will try with the other files from this site to see if they make a 
difference.

In the meantime I've reposted those files from that uploadingit.com site 
here:

http://www.pwsan.com/omap/am33xx/from-vaibhav-hiremath/boottest/


- Paul

Current state of AM33xx patches

[Paul Walmsley]

On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:

> On Thu, Jun 28, 2012 at 01:30:30, Paul Walmsley wrote:
> > Hi Vaibhav,
> > 
> > By the way, maybe you could post a kernel image somewhere that we could 
> > test-boot?
> > 
> 
> Is it accessible - http://uploadingit.com/folder/z1uttvfpr6fgjvzl/Home%20Folder

Just tried the kernel from this; no luck.

Will try with the other files from this site to see if they make a 
difference.

In the meantime I've reposted those files from that uploadingit.com site 
here:

http://www.pwsan.com/omap/am33xx/from-vaibhav-hiremath/boottest/


- Paul

RE: Current state of AM33xx patches

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11727 bytes --]


Good news; am able to get it booting with the images you sent and by 
following the U-boot commands line by line from your earlier post. If I 
use the uEnv.txt to set the optargs and uenvcmd to the same values, it 
hangs as before.  So looks like I need to do a little further debugging 
there to see why that's not working.

Thanks for your help.


- Paul

U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: second ID read did not match 10,10 against 00,10
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0 
U-Boot# 
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=128M root=/dev/ram rw 
initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=seril
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 81000000 uImage-dtb.am335x-evm
reading uImage-dtb.am335x-evm

** Unable to read "uImage-dtb.am335x-evm" from mmc 0:1 **
U-Boot# fatload mmc 0 81000000 uImage
reading uImage

3539030 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz

2022580 bytes read
U-Boot# bootm 81000000
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11827-g67e68668
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3538966 Bytes = 3.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.5.0-rc1-11827-g67e68668 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #2 SMP Thu Jun 28 00:20:09 IST 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM
[    0.000000] cma: CMA: reserved 16 MiB at 86800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0d74000 s11520 r8192 d13056 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32256
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 127MB = 127MB total
[    0.000000] Memory: 83336k/83336k available, 47736k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0626de4   (6268 kB)
[    0.000000]       .init : 0xc0627000 - 0xc0675d00   ( 316 kB)
[    0.000000]       .data : 0xc0676000 - 0xc0713570   ( 630 kB)
[    0.000000]        .bss : 0xc0713594 - 0xc0c6be08   (5475 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.084512] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504)
[    0.084575] pid_max: default: 32768 minimum: 301
[    0.085427] Security Framework initialized
[    0.085746] Mount-cache hash table entries: 512
[    0.095474] CPU: Testing write buffer coherency: ok
[    0.096368] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.096455] Setting up static identity map for 0x80462f40 - 0x80462fb0
[    0.098510] Brought up 1 CPUs
[    0.098538] SMP: Total of 1 processors activated (497.82 BogoMIPS).
[    0.117359] initlevel:0=early, 4 registered initcalls
[    0.117688] initlevel:1=core, 24 registered initcalls
[    0.130732] dummy: 
[    0.135033] NET: Registered protocol family 16
[    0.135342] initlevel:2=postcore, 19 registered initcalls
[    0.142542] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.142697] GPMC revision 6.0
[    0.143031] gpmc: irq-20 could not claim: err -22
[    0.153324] initlevel:3=arch, 16 registered initcalls
[    0.172994] OMAP GPIO hardware version 0.1
[    0.195325] No ATAGs?
[    0.195327] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.205396] initlevel:4=subsys, 43 registered initcalls
[    0.288151] bio: create slab <bio-0> at 0
[    0.301232] SCSI subsystem initialized
[    0.304817] usbcore: registered new interface driver usbfs
[    0.305531] usbcore: registered new interface driver hub
[    0.306545] usbcore: registered new device driver usb
[    0.319884] omap_i2c i2c.13: bus -1 rev2.4.0 at 100 kHz
[    0.334856] omap_i2c i2c.14: bus -1 rev2.4.0 at 100 kHz
[    0.350437] omap_i2c i2c.15: bus -1 rev2.4.0 at 100 kHz
[    0.360796] initlevel:5=fs, 20 registered initcalls
[    0.361110] Switching to clocksource gp_timer
[    0.504856] NET: Registered protocol family 2
[    0.505958] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.508505] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.508889] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.512097] TCP: Hash tables configured (established 4096 bind 4096)
[    0.512236] TCP: reno registered
[    0.512278] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.512654] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.513831] NET: Registered protocol family 1
[    0.515748] RPC: Registered named UNIX socket transport module.
[    0.515776] RPC: Registered udp transport module.
[    0.515792] RPC: Registered tcp transport module.
[    0.515807] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.516947] Trying to unpack rootfs image as initramfs...
[    0.519935] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.662490] Freeing initrd memory: 16384K
[    0.662531] initlevel:6=device, 185 registered initcalls
[    0.662721] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.871566] VFS: Disk quotas dquot_6.5.2
[    0.871964] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.874030] NFS: Registering the id_resolver key type
[    0.874693] Key type id_resolver registered
[    0.876405] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    0.878207] msgmni has been set to 226
[    0.882644] io scheduler noop registered
[    0.882671] io scheduler deadline registered
[    0.882977] io scheduler cfq registered (default)
[    0.886331] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.895435] serial.7: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[    1.505306] console [ttyO0] enabled
[    1.511548] serial.8: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
[    1.521021] serial.9: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
[    1.530178] serial.10: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
[    1.539399] omap_uart serial.11: [UART-1]: failure [serial_omap_probe]: -22
[    1.546983] omap_uart: probe of serial.11 failed with error -22
[    1.553752] omap_uart serial.12: [UART-1]: failure [serial_omap_probe]: -22
[    1.561280] omap_uart: probe of serial.12 failed with error -22
[    1.608812] brd: module loaded
[    1.637737] loop: module loaded
[    1.648775] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.656905] OneNAND driver initializing
[    1.674797] usbcore: registered new interface driver asix
[    1.681200] usbcore: registered new interface driver cdc_ether
[    1.688454] usbcore: registered new interface driver smsc95xx
[    1.695334] usbcore: registered new interface driver net1080
[    1.702097] usbcore: registered new interface driver cdc_subset
[    1.709078] usbcore: registered new interface driver zaurus
[    1.715775] usbcore: registered new interface driver cdc_ncm
[    1.723841] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.732439] usbcore: registered new interface driver cdc_wdm
[    1.738595] Initializing USB Mass Storage driver...
[    1.744634] usbcore: registered new interface driver usb-storage
[    1.750971] USB Mass Storage support registered.
[    1.757383] usbcore: registered new interface driver libusual
[    1.764317] usbcore: registered new interface driver usbtest
[    1.772412] mousedev: PS/2 mouse device common for all mice
[    1.784078] i2c /dev entries driver
[    1.792814] Driver for 1-wire Dallas network protocol.
[    1.802435] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.814452] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.862238] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.876561] mmc0: host doesn't support card's voltages
[    1.882111] mmc0: error -22 whilst initialising SD card
[    1.917023] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.977620] usbcore: registered new interface driver usbhid
[    1.983656] usbhid: USB HID core driver
[    1.988273] oprofile: hardware counters not available
[    1.993605] oprofile: using timer interrupt.
[    1.999234] TCP: cubic registered
[    2.003055] Initializing XFRM netlink socket
[    2.007730] NET: Registered protocol family 17
[    2.012848] NET: Registered protocol family 15
[    2.018313] Key type dns_resolver registered
[    2.022832] initlevel:7=late, 26 registered initcalls
[    2.028421] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.036674] ThumbEE CPU extension supported.
[    2.054739] clock: disabling unused clocks to save power
[    2.068694] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.079880] RAMDISK: gzip image found at block 0
[    2.599184] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.606361] Freeing init memory: 312K
mount: mounting none on /var/shm failed: No such file or directory
  ::
  :: Enabling hot-plug  : [SUCCESS]
  ::
  ::
   : Populating /dev    : [SUCCESS]
[SUCCESS]
  ::
  ::
  :: Setting PATH
  ::
   : syslogd            : [SUCCESS]
   : telnetd            : [SUCCESS]

Please press Enter to activate this console. 

Current state of AM33xx patches

[Paul Walmsley]

Good news; am able to get it booting with the images you sent and by 
following the U-boot commands line by line from your earlier post. If I 
use the uEnv.txt to set the optargs and uenvcmd to the same values, it 
hangs as before.  So looks like I need to do a little further debugging 
there to see why that's not working.

Thanks for your help.


- Paul

U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: second ID read did not match 10,10 against 00,10
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0 
U-Boot# 
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=128M root=/dev/ram rw 
initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=seril
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 81000000 uImage-dtb.am335x-evm
reading uImage-dtb.am335x-evm

** Unable to read "uImage-dtb.am335x-evm" from mmc 0:1 **
U-Boot# fatload mmc 0 81000000 uImage
reading uImage

3539030 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz

2022580 bytes read
U-Boot# bootm 81000000
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-3.5.0-rc1-11827-g67e68668
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3538966 Bytes = 3.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.5.0-rc1-11827-g67e68668 (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #2 SMP Thu Jun 28 00:20:09 IST 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM
[    0.000000] cma: CMA: reserved 16 MiB at 86800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0d74000 s11520 r8192 d13056 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32256
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 127MB = 127MB total
[    0.000000] Memory: 83336k/83336k available, 47736k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0626de4   (6268 kB)
[    0.000000]       .init : 0xc0627000 - 0xc0675d00   ( 316 kB)
[    0.000000]       .data : 0xc0676000 - 0xc0713570   ( 630 kB)
[    0.000000]        .bss : 0xc0713594 - 0xc0c6be08   (5475 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.084512] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504)
[    0.084575] pid_max: default: 32768 minimum: 301
[    0.085427] Security Framework initialized
[    0.085746] Mount-cache hash table entries: 512
[    0.095474] CPU: Testing write buffer coherency: ok
[    0.096368] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.096455] Setting up static identity map for 0x80462f40 - 0x80462fb0
[    0.098510] Brought up 1 CPUs
[    0.098538] SMP: Total of 1 processors activated (497.82 BogoMIPS).
[    0.117359] initlevel:0=early, 4 registered initcalls
[    0.117688] initlevel:1=core, 24 registered initcalls
[    0.130732] dummy: 
[    0.135033] NET: Registered protocol family 16
[    0.135342] initlevel:2=postcore, 19 registered initcalls
[    0.142542] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.142697] GPMC revision 6.0
[    0.143031] gpmc: irq-20 could not claim: err -22
[    0.153324] initlevel:3=arch, 16 registered initcalls
[    0.172994] OMAP GPIO hardware version 0.1
[    0.195325] No ATAGs?
[    0.195327] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.205396] initlevel:4=subsys, 43 registered initcalls
[    0.288151] bio: create slab <bio-0> at 0
[    0.301232] SCSI subsystem initialized
[    0.304817] usbcore: registered new interface driver usbfs
[    0.305531] usbcore: registered new interface driver hub
[    0.306545] usbcore: registered new device driver usb
[    0.319884] omap_i2c i2c.13: bus -1 rev2.4.0 at 100 kHz
[    0.334856] omap_i2c i2c.14: bus -1 rev2.4.0 at 100 kHz
[    0.350437] omap_i2c i2c.15: bus -1 rev2.4.0 at 100 kHz
[    0.360796] initlevel:5=fs, 20 registered initcalls
[    0.361110] Switching to clocksource gp_timer
[    0.504856] NET: Registered protocol family 2
[    0.505958] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.508505] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.508889] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.512097] TCP: Hash tables configured (established 4096 bind 4096)
[    0.512236] TCP: reno registered
[    0.512278] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.512654] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.513831] NET: Registered protocol family 1
[    0.515748] RPC: Registered named UNIX socket transport module.
[    0.515776] RPC: Registered udp transport module.
[    0.515792] RPC: Registered tcp transport module.
[    0.515807] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.516947] Trying to unpack rootfs image as initramfs...
[    0.519935] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.662490] Freeing initrd memory: 16384K
[    0.662531] initlevel:6=device, 185 registered initcalls
[    0.662721] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.871566] VFS: Disk quotas dquot_6.5.2
[    0.871964] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.874030] NFS: Registering the id_resolver key type
[    0.874693] Key type id_resolver registered
[    0.876405] jffs2: version 2.2. (NAND) (SUMMARY)  ? 2001-2006 Red Hat, Inc.
[    0.878207] msgmni has been set to 226
[    0.882644] io scheduler noop registered
[    0.882671] io scheduler deadline registered
[    0.882977] io scheduler cfq registered (default)
[    0.886331] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.895435] serial.7: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[    1.505306] console [ttyO0] enabled
[    1.511548] serial.8: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
[    1.521021] serial.9: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
[    1.530178] serial.10: ttyO3 at MMIO 0x481a6000 (irq = 44) is a OMAP UART3
[    1.539399] omap_uart serial.11: [UART-1]: failure [serial_omap_probe]: -22
[    1.546983] omap_uart: probe of serial.11 failed with error -22
[    1.553752] omap_uart serial.12: [UART-1]: failure [serial_omap_probe]: -22
[    1.561280] omap_uart: probe of serial.12 failed with error -22
[    1.608812] brd: module loaded
[    1.637737] loop: module loaded
[    1.648775] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.656905] OneNAND driver initializing
[    1.674797] usbcore: registered new interface driver asix
[    1.681200] usbcore: registered new interface driver cdc_ether
[    1.688454] usbcore: registered new interface driver smsc95xx
[    1.695334] usbcore: registered new interface driver net1080
[    1.702097] usbcore: registered new interface driver cdc_subset
[    1.709078] usbcore: registered new interface driver zaurus
[    1.715775] usbcore: registered new interface driver cdc_ncm
[    1.723841] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.732439] usbcore: registered new interface driver cdc_wdm
[    1.738595] Initializing USB Mass Storage driver...
[    1.744634] usbcore: registered new interface driver usb-storage
[    1.750971] USB Mass Storage support registered.
[    1.757383] usbcore: registered new interface driver libusual
[    1.764317] usbcore: registered new interface driver usbtest
[    1.772412] mousedev: PS/2 mouse device common for all mice
[    1.784078] i2c /dev entries driver
[    1.792814] Driver for 1-wire Dallas network protocol.
[    1.802435] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.814452] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.862238] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.876561] mmc0: host doesn't support card's voltages
[    1.882111] mmc0: error -22 whilst initialising SD card
[    1.917023] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.977620] usbcore: registered new interface driver usbhid
[    1.983656] usbhid: USB HID core driver
[    1.988273] oprofile: hardware counters not available
[    1.993605] oprofile: using timer interrupt.
[    1.999234] TCP: cubic registered
[    2.003055] Initializing XFRM netlink socket
[    2.007730] NET: Registered protocol family 17
[    2.012848] NET: Registered protocol family 15
[    2.018313] Key type dns_resolver registered
[    2.022832] initlevel:7=late, 26 registered initcalls
[    2.028421] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.036674] ThumbEE CPU extension supported.
[    2.054739] clock: disabling unused clocks to save power
[    2.068694] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.079880] RAMDISK: gzip image found at block 0
[    2.599184] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.606361] Freeing init memory: 312K
mount: mounting none on /var/shm failed: No such file or directory
  ::
  :: Enabling hot-plug  : [SUCCESS]
  ::
  ::
   : Populating /dev    : [SUCCESS]
[SUCCESS]
  ::
  ::
  :: Setting PATH
  ::
   : syslogd            : [SUCCESS]
   : telnetd            : [SUCCESS]

Please press Enter to activate this console. 

Re: Current state of AM33xx patches

[Daniel Mack]

On 27.06.2012 14:13, Hiremath, Vaibhav wrote:

> Just to clarify from AM335x perspective,
> 
> In case of AM335x, since the patches and complete BasePort support is still
> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> omap/master) in order to test something on BeagleBone platform.

Great, that is the information I've been looking for.

Your am335x-upstream-staging branch works for me on a custom AM335x
based board using a custom DT config.

I'll dig through the sources and come back once I know which parts are
missing.


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 27.06.2012 14:13, Hiremath, Vaibhav wrote:

> Just to clarify from AM335x perspective,
> 
> In case of AM335x, since the patches and complete BasePort support is still
> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> omap/master) in order to test something on BeagleBone platform.

Great, that is the information I've been looking for.

Your am335x-upstream-staging branch works for me on a custom AM335x
based board using a custom DT config.

I'll dig through the sources and come back once I know which parts are
missing.


Thanks,
Daniel

Re: Current state of AM33xx patches

[Yegor Yefremov]

Am 28.06.2012 17:09, schrieb Daniel Mack:
> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> 
>> Just to clarify from AM335x perspective,
>>
>> In case of AM335x, since the patches and complete BasePort support is still
>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>> omap/master) in order to test something on BeagleBone platform.
> 
> Great, that is the information I've been looking for.
> 
> Your am335x-upstream-staging branch works for me on a custom AM335x
> based board using a custom DT config.
> 
> I'll dig through the sources and come back once I know which parts are
> missing.

Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:

(EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()

and before this error there was FB_BLANK_NORMAL option missing in drivers/video/da8xx-fb.c. That's why I think that the current driver is not really production ready.

Best regards,
Yegor

Current state of AM33xx patches

[Yegor Yefremov]

Am 28.06.2012 17:09, schrieb Daniel Mack:
> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> 
>> Just to clarify from AM335x perspective,
>>
>> In case of AM335x, since the patches and complete BasePort support is still
>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>> omap/master) in order to test something on BeagleBone platform.
> 
> Great, that is the information I've been looking for.
> 
> Your am335x-upstream-staging branch works for me on a custom AM335x
> based board using a custom DT config.
> 
> I'll dig through the sources and come back once I know which parts are
> missing.

Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:

(EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()

and before this error there was FB_BLANK_NORMAL option missing in drivers/video/da8xx-fb.c. That's why I think that the current driver is not really production ready.

Best regards,
Yegor

Re: Current state of AM33xx patches

[Mark Jackson]

On 27/06/12 13:07, Hiremath, Vaibhav wrote:
> 
> Omap2plus_defconfig should work for you, you should get linux prompt with 
> ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 
> 
> Build Steps:
> ============
>  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
>  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
>  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
>  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
>    (Since I am not using DT aware u-boot)
> 
> Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline.
> 
> U-Boot commands to boot:
> ========================
> setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> boot
> 
> 
> Hope this will help you to boot the kernel on BeagleBone.

This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.

Here's a section from my boot log:-

[    1.526156] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.577266] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.583961] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    1.600184] mmc0: host doesn't support card's voltages
[    1.605606] mmc0: error -22 whilst initialising SD card
[    1.639743] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.646051] mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    1.694232] mmc2: mmc_rescan_try_freq: trying to init card at 400000 Hz

AFAIKT there's no direct support for the AM335x EVM or BeagleBone, and we're just running off
existing non-specific code.

Buildroot currently references koenkooi repo[1], which has a large number of code changes to add
proper support, and we have a nice working system running on a BeagleBone.

But, going back to some other previous emails in this thread, the Wiki[2] states many of the support
required will only be put into the mainline kernel at 3.7.

Is this still the case ?  Or is it possible that the koenkooi code will be pushed up earlier ?

All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
non-trivial changes going in ?

Cheers
Mark Jackson

[1] https://github.com/koenkooi/linux
[2] http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status

Current state of AM33xx patches

[Mark Jackson]

On 27/06/12 13:07, Hiremath, Vaibhav wrote:
> 
> Omap2plus_defconfig should work for you, you should get linux prompt with 
> ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 
> 
> Build Steps:
> ============
>  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
>  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
>  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
>  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
>    (Since I am not using DT aware u-boot)
> 
> Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline.
> 
> U-Boot commands to boot:
> ========================
> setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> boot
> 
> 
> Hope this will help you to boot the kernel on BeagleBone.

This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.

Here's a section from my boot log:-

[    1.526156] omap_hsmmc mmc.18: Failed to get debounce clk
[    1.577266] omap_hsmmc mmc.19: Failed to get debounce clk
[    1.583961] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    1.600184] mmc0: host doesn't support card's voltages
[    1.605606] mmc0: error -22 whilst initialising SD card
[    1.639743] omap_hsmmc mmc.20: Failed to get debounce clk
[    1.646051] mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
[    1.694232] mmc2: mmc_rescan_try_freq: trying to init card at 400000 Hz

AFAIKT there's no direct support for the AM335x EVM or BeagleBone, and we're just running off
existing non-specific code.

Buildroot currently references koenkooi repo[1], which has a large number of code changes to add
proper support, and we have a nice working system running on a BeagleBone.

But, going back to some other previous emails in this thread, the Wiki[2] states many of the support
required will only be put into the mainline kernel at 3.7.

Is this still the case ?  Or is it possible that the koenkooi code will be pushed up earlier ?

All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
non-trivial changes going in ?

Cheers
Mark Jackson

[1] https://github.com/koenkooi/linux
[2] http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> 
> > Just to clarify from AM335x perspective,
> > 
> > In case of AM335x, since the patches and complete BasePort support is still
> > not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> > need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> > omap/master) in order to test something on BeagleBone platform.
> 
> Great, that is the information I've been looking for.
> 
> Your am335x-upstream-staging branch works for me on a custom AM335x
> based board using a custom DT config.
> 
> I'll dig through the sources and come back once I know which parts are
> missing.
> 

Great to hear that you could able to get this working on your board.
Please let me know if you need any help.

Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> 
> > Just to clarify from AM335x perspective,
> > 
> > In case of AM335x, since the patches and complete BasePort support is still
> > not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> > need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> > omap/master) in order to test something on BeagleBone platform.
> 
> Great, that is the information I've been looking for.
> 
> Your am335x-upstream-staging branch works for me on a custom AM335x
> based board using a custom DT config.
> 
> I'll dig through the sources and come back once I know which parts are
> missing.
> 

Great to hear that you could able to get this working on your board.
Please let me know if you need any help.

Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote:
> Am 28.06.2012 17:09, schrieb Daniel Mack:
> > On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> > 
> >> Just to clarify from AM335x perspective,
> >>
> >> In case of AM335x, since the patches and complete BasePort support is still
> >> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> >> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> >> omap/master) in order to test something on BeagleBone platform.
> > 
> > Great, that is the information I've been looking for.
> > 
> > Your am335x-upstream-staging branch works for me on a custom AM335x
> > based board using a custom DT config.
> > 
> > I'll dig through the sources and come back once I know which parts are
> > missing.
> 
> Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:
> 
> (EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()
> 

Did you get a chance to dig on this? Do you have further level of details 
from driver perspective? Which IOCTL is failing here? What is return value?


Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote:
> Am 28.06.2012 17:09, schrieb Daniel Mack:
> > On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> > 
> >> Just to clarify from AM335x perspective,
> >>
> >> In case of AM335x, since the patches and complete BasePort support is still
> >> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> >> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> >> omap/master) in order to test something on BeagleBone platform.
> > 
> > Great, that is the information I've been looking for.
> > 
> > Your am335x-upstream-staging branch works for me on a custom AM335x
> > based board using a custom DT config.
> > 
> > I'll dig through the sources and come back once I know which parts are
> > missing.
> 
> Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:
> 
> (EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()
> 

Did you get a chance to dig on this? Do you have further level of details 
from driver perspective? Which IOCTL is failing here? What is return value?


Thanks,
Vaibhav

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote:
> On 27/06/12 13:07, Hiremath, Vaibhav wrote:
> > 
> > Omap2plus_defconfig should work for you, you should get linux prompt with 
> > ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 
> > 
> > Build Steps:
> > ============
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
> >  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
> >    (Since I am not using DT aware u-boot)
> > 
> > Use the ramdisk image to boot kernel, since we do not have support for any 
> > storage devices in the mainline.
> > 
> > U-Boot commands to boot:
> > ========================
> > setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> > setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> > boot
> > 
> > 
> > Hope this will help you to boot the kernel on BeagleBone.
> 
> This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.
> 

This is known thing and clearly mentioned/highlighted above.

"Use the ramdisk image to boot kernel, since we do not have support for any 
storage devices in the mainline."



> Here's a section from my boot log:-
> 
> [    1.526156] omap_hsmmc mmc.18: Failed to get debounce clk
> [    1.577266] omap_hsmmc mmc.19: Failed to get debounce clk
> [    1.583961] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> [    1.600184] mmc0: host doesn't support card's voltages
> [    1.605606] mmc0: error -22 whilst initialising SD card
> [    1.639743] omap_hsmmc mmc.20: Failed to get debounce clk
> [    1.646051] mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
> [    1.694232] mmc2: mmc_rescan_try_freq: trying to init card at 400000 Hz
> 
> AFAIKT there's no direct support for the AM335x EVM or BeagleBone, and we're just running off
> existing non-specific code.
> 

What do you mean by non-specific code? 
Mainline support may or may not happens in one-shot, where you have compete 
board support in one kernel version.

> Buildroot currently references koenkooi repo[1], which has a large number of code changes to add
> proper support, and we have a nice working system running on a BeagleBone.
> 

If I understand correctly, it is based ontop of PSP release; and as I said 
before we are working on upstreaming every feature from PSP release.

> But, going back to some other previous emails in this thread, the Wiki[2] states many of the support
> required will only be put into the mainline kernel at 3.7.
> 

Yes, that's correct and that's where we are heading.

> Is this still the case ?  Or is it possible that the koenkooi code will be pushed up earlier ?

I do not track this repo/tree, so may not be right person to comment 
anything on this.


> 
> All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
> non-trivial changes going in ?
> 

Not really true.

The answer is simple, if you are looking for production quality code then 
certainly you should use something based on PSP release (SDK) and if you 
want to stay close to Mainline and would like to contribute towards it, you 
have to understand the process, dependencies, development and discussions 
happening on the list.


Thanks,
Vaibahv

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote:
> On 27/06/12 13:07, Hiremath, Vaibhav wrote:
> > 
> > Omap2plus_defconfig should work for you, you should get linux prompt with 
> > ramdisk image (which I use). Just to be more clear, and for your reference I am pasting steps which I use for testing, 
> > 
> > Build Steps:
> > ============
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> distclean
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> omap2plus_defconfig
> >  - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
> >  - make ARCH=arm CROSS_COMPILE=<toolchain> uImage-dtb.am335x-evm
> >    (Since I am not using DT aware u-boot)
> > 
> > Use the ramdisk image to boot kernel, since we do not have support for any 
> > storage devices in the mainline.
> > 
> > U-Boot commands to boot:
> > ========================
> > setenv bootcmd 'mmc rescan 0; fatload mmc 0 81000000 uImage; fatload mmc 0 82000000 ramdisk-pm.gz; bootm 81000000'
> > setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial'
> > boot
> > 
> > 
> > Hope this will help you to boot the kernel on BeagleBone.
> 
> This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.
> 

This is known thing and clearly mentioned/highlighted above.

"Use the ramdisk image to boot kernel, since we do not have support for any 
storage devices in the mainline."



> Here's a section from my boot log:-
> 
> [    1.526156] omap_hsmmc mmc.18: Failed to get debounce clk
> [    1.577266] omap_hsmmc mmc.19: Failed to get debounce clk
> [    1.583961] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> [    1.600184] mmc0: host doesn't support card's voltages
> [    1.605606] mmc0: error -22 whilst initialising SD card
> [    1.639743] omap_hsmmc mmc.20: Failed to get debounce clk
> [    1.646051] mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz
> [    1.694232] mmc2: mmc_rescan_try_freq: trying to init card at 400000 Hz
> 
> AFAIKT there's no direct support for the AM335x EVM or BeagleBone, and we're just running off
> existing non-specific code.
> 

What do you mean by non-specific code? 
Mainline support may or may not happens in one-shot, where you have compete 
board support in one kernel version.

> Buildroot currently references koenkooi repo[1], which has a large number of code changes to add
> proper support, and we have a nice working system running on a BeagleBone.
> 

If I understand correctly, it is based ontop of PSP release; and as I said 
before we are working on upstreaming every feature from PSP release.

> But, going back to some other previous emails in this thread, the Wiki[2] states many of the support
> required will only be put into the mainline kernel at 3.7.
> 

Yes, that's correct and that's where we are heading.

> Is this still the case ?  Or is it possible that the koenkooi code will be pushed up earlier ?

I do not track this repo/tree, so may not be right person to comment 
anything on this.


> 
> All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
> non-trivial changes going in ?
> 

Not really true.

The answer is simple, if you are looking for production quality code then 
certainly you should use something based on PSP release (SDK) and if you 
want to stay close to Mainline and would like to contribute towards it, you 
have to understand the process, dependencies, development and discussions 
happening on the list.


Thanks,
Vaibahv

Re: Current state of AM33xx patches

[Daniel Mack]

On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
> On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
>> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
>>
>>> Just to clarify from AM335x perspective,
>>>
>>> In case of AM335x, since the patches and complete BasePort support is still
>>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>>> omap/master) in order to test something on BeagleBone platform.
>>
>> Great, that is the information I've been looking for.
>>
>> Your am335x-upstream-staging branch works for me on a custom AM335x
>> based board using a custom DT config.
>>
>> I'll dig through the sources and come back once I know which parts are
>> missing.
>>
> 
> Great to hear that you could able to get this working on your board.
> Please let me know if you need any help.

I wonder about the way forward with regard to hwmod and DT. From what I
can currently see, resources are defined as hard-coded values, even
though that doesn't seem necessary as they're stored in the device tree
data already.

As an example, am33xx.dtsi yields

		uart1: serial@44E09000 {
			compatible = "ti,omap3-uart";
			ti,hwmods = "uart1";
			clock-frequency = <48000000>;
		};

But the address of that hardware module is in fact ignored. Instead, the
reference to the "uart1" hwmod defines the address space and interrupt
sources the driver requires:

static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
        {
                .pa_start       = 0x44E09000,
                .pa_end         = 0x44E09000 + SZ_8K - 1,
                .flags          = ADDR_TYPE_RT,
        },
        { }
};

And that's the same for all the hardware modules.

Correct me if I'm mistaken, but this isn't really what DT was designed
for. In this context, it is used as a simple list of devices to probe,
not as a abstracted description of the hardware resources and their
interconnects.

The question is: is that the way things should be kept for OMAP/AM33xx?
Or should work be done to move all that hwmod stuff to proper
clk/irq/res definitions that can be used from DT generically? As there's
actually no need to care for legacy users at all (as no board support
for AM33xx is mainline), shouldn't things be done right in the first place?


Best regards,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
> On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
>> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
>>
>>> Just to clarify from AM335x perspective,
>>>
>>> In case of AM335x, since the patches and complete BasePort support is still
>>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>>> omap/master) in order to test something on BeagleBone platform.
>>
>> Great, that is the information I've been looking for.
>>
>> Your am335x-upstream-staging branch works for me on a custom AM335x
>> based board using a custom DT config.
>>
>> I'll dig through the sources and come back once I know which parts are
>> missing.
>>
> 
> Great to hear that you could able to get this working on your board.
> Please let me know if you need any help.

I wonder about the way forward with regard to hwmod and DT. From what I
can currently see, resources are defined as hard-coded values, even
though that doesn't seem necessary as they're stored in the device tree
data already.

As an example, am33xx.dtsi yields

		uart1: serial at 44E09000 {
			compatible = "ti,omap3-uart";
			ti,hwmods = "uart1";
			clock-frequency = <48000000>;
		};

But the address of that hardware module is in fact ignored. Instead, the
reference to the "uart1" hwmod defines the address space and interrupt
sources the driver requires:

static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
        {
                .pa_start       = 0x44E09000,
                .pa_end         = 0x44E09000 + SZ_8K - 1,
                .flags          = ADDR_TYPE_RT,
        },
        { }
};

And that's the same for all the hardware modules.

Correct me if I'm mistaken, but this isn't really what DT was designed
for. In this context, it is used as a simple list of devices to probe,
not as a abstracted description of the hardware resources and their
interconnects.

The question is: is that the way things should be kept for OMAP/AM33xx?
Or should work be done to move all that hwmod stuff to proper
clk/irq/res definitions that can be used from DT generically? As there's
actually no need to care for legacy users at all (as no board support
for AM33xx is mainline), shouldn't things be done right in the first place?


Best regards,
Daniel

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Sat, Jun 30, 2012 at 00:04:53, Daniel Mack wrote:
> On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
> > On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
> >> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> >>
> >>> Just to clarify from AM335x perspective,
> >>>
> >>> In case of AM335x, since the patches and complete BasePort support is still
> >>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> >>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> >>> omap/master) in order to test something on BeagleBone platform.
> >>
> >> Great, that is the information I've been looking for.
> >>
> >> Your am335x-upstream-staging branch works for me on a custom AM335x
> >> based board using a custom DT config.
> >>
> >> I'll dig through the sources and come back once I know which parts are
> >> missing.
> >>
> > 
> > Great to hear that you could able to get this working on your board.
> > Please let me know if you need any help.
> 
> I wonder about the way forward with regard to hwmod and DT. From what I
> can currently see, resources are defined as hard-coded values, even
> though that doesn't seem necessary as they're stored in the device tree
> data already.
> 
> As an example, am33xx.dtsi yields
> 
> 		uart1: serial@44E09000 {
> 			compatible = "ti,omap3-uart";
> 			ti,hwmods = "uart1";
> 			clock-frequency = <48000000>;
> 		};
> 
> But the address of that hardware module is in fact ignored. Instead, the
> reference to the "uart1" hwmod defines the address space and interrupt
> sources the driver requires:
> 
> static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
>         {
>                 .pa_start       = 0x44E09000,
>                 .pa_end         = 0x44E09000 + SZ_8K - 1,
>                 .flags          = ADDR_TYPE_RT,
>         },
>         { }
> };
> 
> And that's the same for all the hardware modules.
> 
> Correct me if I'm mistaken, but this isn't really what DT was designed
> for. In this context, it is used as a simple list of devices to probe,
> not as a abstracted description of the hardware resources and their
> interconnects.
>
> The question is: is that the way things should be kept for OMAP/AM33xx?
> Or should work be done to move all that hwmod stuff to proper
> clk/irq/res definitions that can be used from DT generically? As there's
> actually no need to care for legacy users at all (as no board support
> for AM33xx is mainline), shouldn't things be done right in the first place?
> 
> 

+ Benoit

Let me describe based on my understanding,

OMAP infrastructure is build around HWMOD and omap-device and OMAP devices 
are still relying on the omap_device/omap_hwmod mechanism to populate the 
IRQ, DMA and address space.

The goal would be to get it to the stage where all these information should 
come from DT alone.

Benoit, correct me if I am wrong anywhere.

Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Sat, Jun 30, 2012 at 00:04:53, Daniel Mack wrote:
> On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
> > On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
> >> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
> >>
> >>> Just to clarify from AM335x perspective,
> >>>
> >>> In case of AM335x, since the patches and complete BasePort support is still
> >>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
> >>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
> >>> omap/master) in order to test something on BeagleBone platform.
> >>
> >> Great, that is the information I've been looking for.
> >>
> >> Your am335x-upstream-staging branch works for me on a custom AM335x
> >> based board using a custom DT config.
> >>
> >> I'll dig through the sources and come back once I know which parts are
> >> missing.
> >>
> > 
> > Great to hear that you could able to get this working on your board.
> > Please let me know if you need any help.
> 
> I wonder about the way forward with regard to hwmod and DT. From what I
> can currently see, resources are defined as hard-coded values, even
> though that doesn't seem necessary as they're stored in the device tree
> data already.
> 
> As an example, am33xx.dtsi yields
> 
> 		uart1: serial at 44E09000 {
> 			compatible = "ti,omap3-uart";
> 			ti,hwmods = "uart1";
> 			clock-frequency = <48000000>;
> 		};
> 
> But the address of that hardware module is in fact ignored. Instead, the
> reference to the "uart1" hwmod defines the address space and interrupt
> sources the driver requires:
> 
> static struct omap_hwmod_addr_space am33xx_uart1_addr_space[] = {
>         {
>                 .pa_start       = 0x44E09000,
>                 .pa_end         = 0x44E09000 + SZ_8K - 1,
>                 .flags          = ADDR_TYPE_RT,
>         },
>         { }
> };
> 
> And that's the same for all the hardware modules.
> 
> Correct me if I'm mistaken, but this isn't really what DT was designed
> for. In this context, it is used as a simple list of devices to probe,
> not as a abstracted description of the hardware resources and their
> interconnects.
>
> The question is: is that the way things should be kept for OMAP/AM33xx?
> Or should work be done to move all that hwmod stuff to proper
> clk/irq/res definitions that can be used from DT generically? As there's
> actually no need to care for legacy users at all (as no board support
> for AM33xx is mainline), shouldn't things be done right in the first place?
> 
> 

+ Benoit

Let me describe based on my understanding,

OMAP infrastructure is build around HWMOD and omap-device and OMAP devices 
are still relying on the omap_device/omap_hwmod mechanism to populate the 
IRQ, DMA and address space.

The goal would be to get it to the stage where all these information should 
come from DT alone.

Benoit, correct me if I am wrong anywhere.

Thanks,
Vaibhav

Re: Current state of AM33xx patches

[Paul Walmsley]

On Fri, 29 Jun 2012, Daniel Mack wrote:

> Correct me if I'm mistaken, but this isn't really what DT was designed
> for. In this context, it is used as a simple list of devices to probe,
> not as a abstracted description of the hardware resources and their
> interconnects.
>
> The question is: is that the way things should be kept for OMAP/AM33xx? 
> Or should work be done to move all that hwmod stuff to proper 
> clk/irq/res definitions that can be used from DT generically?

Eventually the MPU address space, MPU interrupt controller IRQ line data, 
system DMA controller data, and some of the other common resource 
information are probably going to migrate from the hwmod data into the DT 
blob.

And probably some of the power management-related data will migrate to the 
IP block driver code used for a particular SoC.

Probably the best time for this to happen is after the PRM/CM/SCM drivers 
are written, and an omap_bus layer is created from the existing hwmod 
code.  The planning that we've done in conjunction with the ARM DT people 
involves getting DT board file handling done first, which is really what 
DT makes the most sense for.  Then looking at the on-chip SoC stuff 
afterwards.

> As there's actually no need to care for legacy users at all (as no board 
> support for AM33xx is mainline),

The hwmod data is unrelated to the board files.

The "legacy" user here is the hwmod code.  It uses the data to create 
devices for the IP blocks on the SoC, to reset those IP blocks at kernel 
init, and to implement IP block power management via the runtime PM layer.

> shouldn't things be done right in the first place?

Well, all this is distinct from what the 'right' thing is or was.

It should be noted that from the power management and multiple bus 
initiator perspectives, the process of migrating from hwmod data to DT 
will be lossy.  For example, DT uses a single-root perspective of the 
device hierarchy, and does not explicitly encode the interconnections 
between IP blocks.


- Paul

Current state of AM33xx patches

[Paul Walmsley]

On Fri, 29 Jun 2012, Daniel Mack wrote:

> Correct me if I'm mistaken, but this isn't really what DT was designed
> for. In this context, it is used as a simple list of devices to probe,
> not as a abstracted description of the hardware resources and their
> interconnects.
>
> The question is: is that the way things should be kept for OMAP/AM33xx? 
> Or should work be done to move all that hwmod stuff to proper 
> clk/irq/res definitions that can be used from DT generically?

Eventually the MPU address space, MPU interrupt controller IRQ line data, 
system DMA controller data, and some of the other common resource 
information are probably going to migrate from the hwmod data into the DT 
blob.

And probably some of the power management-related data will migrate to the 
IP block driver code used for a particular SoC.

Probably the best time for this to happen is after the PRM/CM/SCM drivers 
are written, and an omap_bus layer is created from the existing hwmod 
code.  The planning that we've done in conjunction with the ARM DT people 
involves getting DT board file handling done first, which is really what 
DT makes the most sense for.  Then looking at the on-chip SoC stuff 
afterwards.

> As there's actually no need to care for legacy users at all (as no board 
> support for AM33xx is mainline),

The hwmod data is unrelated to the board files.

The "legacy" user here is the hwmod code.  It uses the data to create 
devices for the IP blocks on the SoC, to reset those IP blocks at kernel 
init, and to implement IP block power management via the runtime PM layer.

> shouldn't things be done right in the first place?

Well, all this is distinct from what the 'right' thing is or was.

It should be noted that from the power management and multiple bus 
initiator perspectives, the process of migrating from hwmod data to DT 
will be lossy.  For example, DT uses a single-root perspective of the 
device hierarchy, and does not explicitly encode the interconnections 
between IP blocks.


- Paul

Re: Current state of AM33xx patches

[Daniel Mack]

Hi Paul,

On 30.06.2012 04:11, Paul Walmsley wrote:
> On Fri, 29 Jun 2012, Daniel Mack wrote:
> 
>> Correct me if I'm mistaken, but this isn't really what DT was designed
>> for. In this context, it is used as a simple list of devices to probe,
>> not as a abstracted description of the hardware resources and their
>> interconnects.
>>
>> The question is: is that the way things should be kept for OMAP/AM33xx? 
>> Or should work be done to move all that hwmod stuff to proper 
>> clk/irq/res definitions that can be used from DT generically?
> 
> Eventually the MPU address space, MPU interrupt controller IRQ line data, 
> system DMA controller data, and some of the other common resource 
> information are probably going to migrate from the hwmod data into the DT 
> blob.
> 
> And probably some of the power management-related data will migrate to the 
> IP block driver code used for a particular SoC.
> 
> Probably the best time for this to happen is after the PRM/CM/SCM drivers 
> are written, and an omap_bus layer is created from the existing hwmod 
> code.  The planning that we've done in conjunction with the ARM DT people 
> involves getting DT board file handling done first, which is really what 
> DT makes the most sense for.  Then looking at the on-chip SoC stuff 
> afterwards.
> 
>> As there's actually no need to care for legacy users at all (as no board 
>> support for AM33xx is mainline),
> 
> The hwmod data is unrelated to the board files.
> 
> The "legacy" user here is the hwmod code.  It uses the data to create 
> devices for the IP blocks on the SoC, to reset those IP blocks at kernel 
> init, and to implement IP block power management via the runtime PM layer.

Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
the components I need.

Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?


Daniel

Current state of AM33xx patches

[Daniel Mack]

Hi Paul,

On 30.06.2012 04:11, Paul Walmsley wrote:
> On Fri, 29 Jun 2012, Daniel Mack wrote:
> 
>> Correct me if I'm mistaken, but this isn't really what DT was designed
>> for. In this context, it is used as a simple list of devices to probe,
>> not as a abstracted description of the hardware resources and their
>> interconnects.
>>
>> The question is: is that the way things should be kept for OMAP/AM33xx? 
>> Or should work be done to move all that hwmod stuff to proper 
>> clk/irq/res definitions that can be used from DT generically?
> 
> Eventually the MPU address space, MPU interrupt controller IRQ line data, 
> system DMA controller data, and some of the other common resource 
> information are probably going to migrate from the hwmod data into the DT 
> blob.
> 
> And probably some of the power management-related data will migrate to the 
> IP block driver code used for a particular SoC.
> 
> Probably the best time for this to happen is after the PRM/CM/SCM drivers 
> are written, and an omap_bus layer is created from the existing hwmod 
> code.  The planning that we've done in conjunction with the ARM DT people 
> involves getting DT board file handling done first, which is really what 
> DT makes the most sense for.  Then looking at the on-chip SoC stuff 
> afterwards.
> 
>> As there's actually no need to care for legacy users at all (as no board 
>> support for AM33xx is mainline),
> 
> The hwmod data is unrelated to the board files.
> 
> The "legacy" user here is the hwmod code.  It uses the data to create 
> devices for the IP blocks on the SoC, to reset those IP blocks at kernel 
> init, and to implement IP block power management via the runtime PM layer.

Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
the components I need.

Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?


Daniel

Re: Current state of AM33xx patches

[Mark Jackson]

On 29/06/12 18:56, Hiremath, Vaibhav wrote:
> On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote:
>>
>> This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.
>>
> 
> This is known thing and clearly mentioned/highlighted above.
> 
> "Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline."

Oops ... missed that, sorry !!

<snip>

>> All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
>> non-trivial changes going in ?
>>
> 
> Not really true.
> 
> The answer is simple, if you are looking for production quality code then 
> certainly you should use something based on PSP release (SDK) and if you 
> want to stay close to Mainline and would like to contribute towards it, you 
> have to understand the process, dependencies, development and discussions 
> happening on the list.

Okay.  Thanks for explaining.

Mark

Current state of AM33xx patches

[Mark Jackson]

On 29/06/12 18:56, Hiremath, Vaibhav wrote:
> On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote:
>>
>> This does appear to work using the ramdisk, but there seems to be no support for booting off MMC.
>>
> 
> This is known thing and clearly mentioned/highlighted above.
> 
> "Use the ramdisk image to boot kernel, since we do not have support for any 
> storage devices in the mainline."

Oops ... missed that, sorry !!

<snip>

>> All in all, the AM335x code does seem to be very fragmented.  Is that just because these are
>> non-trivial changes going in ?
>>
> 
> Not really true.
> 
> The answer is simple, if you are looking for production quality code then 
> certainly you should use something based on PSP release (SDK) and if you 
> want to stay close to Mainline and would like to contribute towards it, you 
> have to understand the process, dependencies, development and discussions 
> happening on the list.

Okay.  Thanks for explaining.

Mark

Re: Current state of AM33xx patches

[Yegor Yefremov]

Am 29.06.2012 19:43, schrieb Hiremath, Vaibhav:
> On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote:
>> Am 28.06.2012 17:09, schrieb Daniel Mack:
>>> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
>>>
>>>> Just to clarify from AM335x perspective,
>>>>
>>>> In case of AM335x, since the patches and complete BasePort support is still
>>>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>>>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>>>> omap/master) in order to test something on BeagleBone platform.
>>> Great, that is the information I've been looking for.
>>>
>>> Your am335x-upstream-staging branch works for me on a custom AM335x
>>> based board using a custom DT config.
>>>
>>> I'll dig through the sources and come back once I know which parts are
>>> missing.
>> Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:
>>
>> (EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()
>>
> Did you get a chance to dig on this? Do you have further level of details 
> from driver perspective? Which IOCTL is failing here? What is return value?

Sorry for the noise. The driver is working now. It was a software issue introduced by the latest Buildroot version. But the FB_BLANK patch is still valid, it removes nasty warnings.

Best regards,
Yegor

Current state of AM33xx patches

[Yegor Yefremov]

Am 29.06.2012 19:43, schrieb Hiremath, Vaibhav:
> On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote:
>> Am 28.06.2012 17:09, schrieb Daniel Mack:
>>> On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
>>>
>>>> Just to clarify from AM335x perspective,
>>>>
>>>> In case of AM335x, since the patches and complete BasePort support is still
>>>> not present in the Mainline (neither in Linus's tree not in linux-omap), you 
>>>> need to use my Repo (https://github.com/hvaibhav: Closely follows linux-
>>>> omap/master) in order to test something on BeagleBone platform.
>>> Great, that is the information I've been looking for.
>>>
>>> Your am335x-upstream-staging branch works for me on a custom AM335x
>>> based board using a custom DT config.
>>>
>>> I'll dig through the sources and come back once I know which parts are
>>> missing.
>> Do you have LCD screen attached? I need a functioning framebuffer driver. So far if I start x-server I get various errors:
>>
>> (EE) FBDEV(0): internal error: miCreateDefColormap failed in FBDevScreenInit()
>>
> Did you get a chance to dig on this? Do you have further level of details 
> from driver perspective? Which IOCTL is failing here? What is return value?

Sorry for the noise. The driver is working now. It was a software issue introduced by the latest Buildroot version. But the FB_BLANK patch is still valid, it removes nasty warnings.

Best regards,
Yegor

Re: Current state of AM33xx patches

[Paul Walmsley]

On Sat, 30 Jun 2012, Daniel Mack wrote:

> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> the components I need.

Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
for the AM33xx.  There might be some missing integration code to build the 
devices for the newer IP blocks, though.

> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?

Mainline has:

drivers/net/ethernet/ti/davinci_emac.c
drivers/net/ethernet/ti/davinci_mdio.c

Those might work for you.


- Paul

Current state of AM33xx patches

[Paul Walmsley]

On Sat, 30 Jun 2012, Daniel Mack wrote:

> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> the components I need.

Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
for the AM33xx.  There might be some missing integration code to build the 
devices for the newer IP blocks, though.

> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?

Mainline has:

drivers/net/ethernet/ti/davinci_emac.c
drivers/net/ethernet/ti/davinci_mdio.c

Those might work for you.


- Paul

RE: Current state of AM33xx patches

[Hiremath, Vaibhav]

On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> On Sat, 30 Jun 2012, Daniel Mack wrote:
> 
> > Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> > the components I need.
> 
> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
> for the AM33xx.  There might be some missing integration code to build the 
> devices for the newer IP blocks, though.
> 

I would also be interested to know more here.


> > Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> 
> Mainline has:
> 
> drivers/net/ethernet/ti/davinci_emac.c

Not required for AM335X.

> drivers/net/ethernet/ti/davinci_mdio.c
> 
> Those might work for you.
> 

Few more files,

drivers/net/ethernet/ti/cpsw.c
drivers/net/ethernet/ti/davinci_cpdma.c


Wanted to highlight one point,
You still have to add platform device code to get it working.

Thanks,
Vaibhav

Current state of AM33xx patches

[Hiremath, Vaibhav]

On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> On Sat, 30 Jun 2012, Daniel Mack wrote:
> 
> > Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> > the components I need.
> 
> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
> for the AM33xx.  There might be some missing integration code to build the 
> devices for the newer IP blocks, though.
> 

I would also be interested to know more here.


> > Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> 
> Mainline has:
> 
> drivers/net/ethernet/ti/davinci_emac.c

Not required for AM335X.

> drivers/net/ethernet/ti/davinci_mdio.c
> 
> Those might work for you.
> 

Few more files,

drivers/net/ethernet/ti/cpsw.c
drivers/net/ethernet/ti/davinci_cpdma.c


Wanted to highlight one point,
You still have to add platform device code to get it working.

Thanks,
Vaibhav

Re: Current state of AM33xx patches

[Daniel Mack]

On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
>> On Sat, 30 Jun 2012, Daniel Mack wrote:
>>
>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
>>> the components I need.
>>
>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
>> for the AM33xx.  There might be some missing integration code to build the 
>> devices for the newer IP blocks, though.
>>
> 
> I would also be interested to know more here.
> 
> 
>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
>>
>> Mainline has:
>>
>> drivers/net/ethernet/ti/davinci_emac.c
> 
> Not required for AM335X.
> 
>> drivers/net/ethernet/ti/davinci_mdio.c
>>
>> Those might work for you.
>>
> 
> Few more files,
> 
> drivers/net/ethernet/ti/cpsw.c
> drivers/net/ethernet/ti/davinci_cpdma.c
> 
> 
> Wanted to highlight one point,
> You still have to add platform device code to get it working.

Exactly. And a hwmod binding for DT. Do you have patches for that?


Daniel

Current state of AM33xx patches

[Daniel Mack]

On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
>> On Sat, 30 Jun 2012, Daniel Mack wrote:
>>
>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
>>> the components I need.
>>
>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod data 
>> for the AM33xx.  There might be some missing integration code to build the 
>> devices for the newer IP blocks, though.
>>
> 
> I would also be interested to know more here.
> 
> 
>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
>>
>> Mainline has:
>>
>> drivers/net/ethernet/ti/davinci_emac.c
> 
> Not required for AM335X.
> 
>> drivers/net/ethernet/ti/davinci_mdio.c
>>
>> Those might work for you.
>>
> 
> Few more files,
> 
> drivers/net/ethernet/ti/cpsw.c
> drivers/net/ethernet/ti/davinci_cpdma.c
> 
> 
> Wanted to highlight one point,
> You still have to add platform device code to get it working.

Exactly. And a hwmod binding for DT. Do you have patches for that?


Daniel

RE: Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque@gmail.com]
> Sent: Wednesday, July 04, 2012 4:52 PM
> To: Hiremath, Vaibhav
> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; Kridner, Jason; N, Mugunthan V
> Subject: Re: Current state of AM33xx patches
> 
> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> > On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> >> On Sat, 30 Jun 2012, Daniel Mack wrote:
> >>
> >>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> >>> the components I need.
> >>
> >> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
> data
> >> for the AM33xx.  There might be some missing integration code to build
> the
> >> devices for the newer IP blocks, though.
> >>
> >
> > I would also be interested to know more here.
> >
> >
> >>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> >>
> >> Mainline has:
> >>
> >> drivers/net/ethernet/ti/davinci_emac.c
> >
> > Not required for AM335X.
> >
> >> drivers/net/ethernet/ti/davinci_mdio.c
> >>
> >> Those might work for you.
> >>
> >
> > Few more files,
> >
> > drivers/net/ethernet/ti/cpsw.c
> > drivers/net/ethernet/ti/davinci_cpdma.c
> >
> >
> > Wanted to highlight one point,
> > You still have to add platform device code to get it working.
> 
> Exactly. And a hwmod binding for DT. Do you have patches for that?
> 
> 
> Daniel

I am working on DT support for cpsw and will be submitting the patch by 
July 20, 2012

With regards
Mugunthan V N

Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque at gmail.com]
> Sent: Wednesday, July 04, 2012 4:52 PM
> To: Hiremath, Vaibhav
> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; Kridner, Jason; N, Mugunthan V
> Subject: Re: Current state of AM33xx patches
> 
> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> > On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> >> On Sat, 30 Jun 2012, Daniel Mack wrote:
> >>
> >>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
> >>> the components I need.
> >>
> >> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
> data
> >> for the AM33xx.  There might be some missing integration code to build
> the
> >> devices for the newer IP blocks, though.
> >>
> >
> > I would also be interested to know more here.
> >
> >
> >>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> >>
> >> Mainline has:
> >>
> >> drivers/net/ethernet/ti/davinci_emac.c
> >
> > Not required for AM335X.
> >
> >> drivers/net/ethernet/ti/davinci_mdio.c
> >>
> >> Those might work for you.
> >>
> >
> > Few more files,
> >
> > drivers/net/ethernet/ti/cpsw.c
> > drivers/net/ethernet/ti/davinci_cpdma.c
> >
> >
> > Wanted to highlight one point,
> > You still have to add platform device code to get it working.
> 
> Exactly. And a hwmod binding for DT. Do you have patches for that?
> 
> 
> Daniel

I am working on DT support for cpsw and will be submitting the patch by 
July 20, 2012

With regards
Mugunthan V N

Re: Current state of AM33xx patches

[Daniel Mack]

On 05.07.2012 19:45, N, Mugunthan V wrote:
>> -----Original Message-----
>> From: Daniel Mack [mailto:zonque@gmail.com]
>> Sent: Wednesday, July 04, 2012 4:52 PM
>> To: Hiremath, Vaibhav
>> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
>> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap@vger.kernel.org;
>> linux-arm-kernel@lists.infradead.org; Kridner, Jason; N, Mugunthan V
>> Subject: Re: Current state of AM33xx patches
>>
>> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
>>> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
>>>> On Sat, 30 Jun 2012, Daniel Mack wrote:
>>>>
>>>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
>>>>> the components I need.
>>>>
>>>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
>> data
>>>> for the AM33xx.  There might be some missing integration code to build
>> the
>>>> devices for the newer IP blocks, though.
>>>>
>>>
>>> I would also be interested to know more here.
>>>
>>>
>>>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
>>>>
>>>> Mainline has:
>>>>
>>>> drivers/net/ethernet/ti/davinci_emac.c
>>>
>>> Not required for AM335X.
>>>
>>>> drivers/net/ethernet/ti/davinci_mdio.c
>>>>
>>>> Those might work for you.
>>>>
>>>
>>> Few more files,
>>>
>>> drivers/net/ethernet/ti/cpsw.c
>>> drivers/net/ethernet/ti/davinci_cpdma.c
>>>
>>>
>>> Wanted to highlight one point,
>>> You still have to add platform device code to get it working.
>>
>> Exactly. And a hwmod binding for DT. Do you have patches for that?
>>
>>
>> Daniel
> 
> I am working on DT support for cpsw and will be submitting the patch by 
> July 20, 2012

Just curious - have you made any progress on that yet?


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 05.07.2012 19:45, N, Mugunthan V wrote:
>> -----Original Message-----
>> From: Daniel Mack [mailto:zonque at gmail.com]
>> Sent: Wednesday, July 04, 2012 4:52 PM
>> To: Hiremath, Vaibhav
>> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
>> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org; Kridner, Jason; N, Mugunthan V
>> Subject: Re: Current state of AM33xx patches
>>
>> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
>>> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
>>>> On Sat, 30 Jun 2012, Daniel Mack wrote:
>>>>
>>>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
>>>>> the components I need.
>>>>
>>>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
>> data
>>>> for the AM33xx.  There might be some missing integration code to build
>> the
>>>> devices for the newer IP blocks, though.
>>>>
>>>
>>> I would also be interested to know more here.
>>>
>>>
>>>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
>>>>
>>>> Mainline has:
>>>>
>>>> drivers/net/ethernet/ti/davinci_emac.c
>>>
>>> Not required for AM335X.
>>>
>>>> drivers/net/ethernet/ti/davinci_mdio.c
>>>>
>>>> Those might work for you.
>>>>
>>>
>>> Few more files,
>>>
>>> drivers/net/ethernet/ti/cpsw.c
>>> drivers/net/ethernet/ti/davinci_cpdma.c
>>>
>>>
>>> Wanted to highlight one point,
>>> You still have to add platform device code to get it working.
>>
>> Exactly. And a hwmod binding for DT. Do you have patches for that?
>>
>>
>> Daniel
> 
> I am working on DT support for cpsw and will be submitting the patch by 
> July 20, 2012

Just curious - have you made any progress on that yet?


Thanks,
Daniel

RE: Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque@gmail.com]
> Sent: Monday, July 23, 2012 12:01 PM
> To: N, Mugunthan V
> Cc: Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony
> Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin, Chase; linux-
> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> On 05.07.2012 19:45, N, Mugunthan V wrote:
> >> -----Original Message-----
> >> From: Daniel Mack [mailto:zonque@gmail.com]
> >> Sent: Wednesday, July 04, 2012 4:52 PM
> >> To: Hiremath, Vaibhav
> >> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
> >> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap@vger.kernel.org;
> >> linux-arm-kernel@lists.infradead.org; Kridner, Jason; N, Mugunthan V
> >> Subject: Re: Current state of AM33xx patches
> >>
> >> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> >>> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> >>>> On Sat, 30 Jun 2012, Daniel Mack wrote:
> >>>>
> >>>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs
> for
> >>>>> the components I need.
> >>>>
> >>>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
> >> data
> >>>> for the AM33xx.  There might be some missing integration code to
> build
> >> the
> >>>> devices for the newer IP blocks, though.
> >>>>
> >>>
> >>> I would also be interested to know more here.
> >>>
> >>>
> >>>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> >>>>
> >>>> Mainline has:
> >>>>
> >>>> drivers/net/ethernet/ti/davinci_emac.c
> >>>
> >>> Not required for AM335X.
> >>>
> >>>> drivers/net/ethernet/ti/davinci_mdio.c
> >>>>
> >>>> Those might work for you.
> >>>>
> >>>
> >>> Few more files,
> >>>
> >>> drivers/net/ethernet/ti/cpsw.c
> >>> drivers/net/ethernet/ti/davinci_cpdma.c
> >>>
> >>>
> >>> Wanted to highlight one point,
> >>> You still have to add platform device code to get it working.
> >>
> >> Exactly. And a hwmod binding for DT. Do you have patches for that?
> >>
> >>
> >> Daniel
> >
> > I am working on DT support for cpsw and will be submitting the patch by
> > July 20, 2012
> 
> Just curious - have you made any progress on that yet?
>
 
I have got the runtime PM support accepted to net-next, will be working on 
and submitting DT support by this week.

Regards
Mugunthan V N

Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque at gmail.com]
> Sent: Monday, July 23, 2012 12:01 PM
> To: N, Mugunthan V
> Cc: Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony
> Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin, Chase; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> On 05.07.2012 19:45, N, Mugunthan V wrote:
> >> -----Original Message-----
> >> From: Daniel Mack [mailto:zonque at gmail.com]
> >> Sent: Wednesday, July 04, 2012 4:52 PM
> >> To: Hiremath, Vaibhav
> >> Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
> >> Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap at vger.kernel.org;
> >> linux-arm-kernel at lists.infradead.org; Kridner, Jason; N, Mugunthan V
> >> Subject: Re: Current state of AM33xx patches
> >>
> >> On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
> >>> On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
> >>>> On Sat, 30 Jun 2012, Daniel Mack wrote:
> >>>>
> >>>>> Ok, thanks for the explaining this. For now, I'll add hwmod stubs
> for
> >>>>> the components I need.
> >>>>
> >>>> Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
> >> data
> >>>> for the AM33xx.  There might be some missing integration code to
> build
> >> the
> >>>> devices for the newer IP blocks, though.
> >>>>
> >>>
> >>> I would also be interested to know more here.
> >>>
> >>>
> >>>>> Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
> >>>>
> >>>> Mainline has:
> >>>>
> >>>> drivers/net/ethernet/ti/davinci_emac.c
> >>>
> >>> Not required for AM335X.
> >>>
> >>>> drivers/net/ethernet/ti/davinci_mdio.c
> >>>>
> >>>> Those might work for you.
> >>>>
> >>>
> >>> Few more files,
> >>>
> >>> drivers/net/ethernet/ti/cpsw.c
> >>> drivers/net/ethernet/ti/davinci_cpdma.c
> >>>
> >>>
> >>> Wanted to highlight one point,
> >>> You still have to add platform device code to get it working.
> >>
> >> Exactly. And a hwmod binding for DT. Do you have patches for that?
> >>
> >>
> >> Daniel
> >
> > I am working on DT support for cpsw and will be submitting the patch by
> > July 20, 2012
> 
> Just curious - have you made any progress on that yet?
>
 
I have got the runtime PM support accepted to net-next, will be working on 
and submitting DT support by this week.

Regards
Mugunthan V N

Re: Current state of AM33xx patches

[Daniel Mack]

On 23.07.2012 18:36, N, Mugunthan V wrote:
>> On 05.07.2012 19:45, N, Mugunthan V wrote:

>>> I am working on DT support for cpsw and will be submitting the patch by
>>> July 20, 2012
>>
>> Just curious - have you made any progress on that yet?
>>
>  
> I have got the runtime PM support accepted to net-next, will be working on 
> and submitting DT support by this week.

I got these updates now via mainline, thanks for your work. Could you
give me some board code sniplet that makes that driver work for you? I'm
asking because I fail to see the "fck" clock that the driver requires.

I'm based on Linus' tree in the middle of the merge window, plus the
am335x-upstream-staging branch of
git://github.com/hvaibhav/am335x-linux.git - anything else I need to have?

Once I have network up and running, I can finally boot into a shell :)


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 23.07.2012 18:36, N, Mugunthan V wrote:
>> On 05.07.2012 19:45, N, Mugunthan V wrote:

>>> I am working on DT support for cpsw and will be submitting the patch by
>>> July 20, 2012
>>
>> Just curious - have you made any progress on that yet?
>>
>  
> I have got the runtime PM support accepted to net-next, will be working on 
> and submitting DT support by this week.

I got these updates now via mainline, thanks for your work. Could you
give me some board code sniplet that makes that driver work for you? I'm
asking because I fail to see the "fck" clock that the driver requires.

I'm based on Linus' tree in the middle of the merge window, plus the
am335x-upstream-staging branch of
git://github.com/hvaibhav/am335x-linux.git - anything else I need to have?

Once I have network up and running, I can finally boot into a shell :)


Thanks,
Daniel

Re: Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 16:52 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 23.07.2012 18:36, N, Mugunthan V wrote:
>>> On 05.07.2012 19:45, N, Mugunthan V wrote:
> 
>>>> I am working on DT support for cpsw and will be submitting the patch by
>>>> July 20, 2012
>>> 
>>> Just curious - have you made any progress on that yet?
>>> 
>> 
>> I have got the runtime PM support accepted to net-next, will be working on 
>> and submitting DT support by this week.
> 
> I got these updates now via mainline, thanks for your work. Could you
> give me some board code sniplet that makes that driver work for you? I'm
> asking because I fail to see the "fck" clock that the driver requires.
> 
> I'm based on Linus' tree in the middle of the merge window, plus the
> am335x-upstream-staging branch of
> git://github.com/hvaibhav/am335x-linux.git - anything else I need to have?
> 
> Once I have network up and running, I can finally boot into a shell :)

With Ajay's usb patches you can easily boot from a usb stick, you'll only need the bootloads to be on mmc or tftp. That's what I have been doing on my beaglebone :)

I'm going to update https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use linus' tree when I get a chance to test a build.

regards,

Koen

Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 16:52 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 23.07.2012 18:36, N, Mugunthan V wrote:
>>> On 05.07.2012 19:45, N, Mugunthan V wrote:
> 
>>>> I am working on DT support for cpsw and will be submitting the patch by
>>>> July 20, 2012
>>> 
>>> Just curious - have you made any progress on that yet?
>>> 
>> 
>> I have got the runtime PM support accepted to net-next, will be working on 
>> and submitting DT support by this week.
> 
> I got these updates now via mainline, thanks for your work. Could you
> give me some board code sniplet that makes that driver work for you? I'm
> asking because I fail to see the "fck" clock that the driver requires.
> 
> I'm based on Linus' tree in the middle of the merge window, plus the
> am335x-upstream-staging branch of
> git://github.com/hvaibhav/am335x-linux.git - anything else I need to have?
> 
> Once I have network up and running, I can finally boot into a shell :)

With Ajay's usb patches you can easily boot from a usb stick, you'll only need the bootloads to be on mmc or tftp. That's what I have been doing on my beaglebone :)

I'm going to update https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use linus' tree when I get a chance to test a build.

regards,

Koen

Re: Current state of AM33xx patches

[Daniel Mack]

On 26.07.2012 17:00, Koen Kooi wrote:

> With Ajay's usb patches you can easily boot from a usb stick, you'll
> only need the bootloads to be on mmc or tftp. That's what I have been
> doing on my beaglebone :)
> 
> I'm going to update
> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use
> linus' tree when I get a chance to test a build.

Hmm, how are the patches in this repository generated? Is there a tree
that has them as real commits?


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 26.07.2012 17:00, Koen Kooi wrote:

> With Ajay's usb patches you can easily boot from a usb stick, you'll
> only need the bootloads to be on mmc or tftp. That's what I have been
> doing on my beaglebone :)
> 
> I'm going to update
> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use
> linus' tree when I get a chance to test a build.

Hmm, how are the patches in this repository generated? Is there a tree
that has them as real commits?


Thanks,
Daniel

Re: Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 26.07.2012 17:00, Koen Kooi wrote:
> 
>> With Ajay's usb patches you can easily boot from a usb stick, you'll
>> only need the bootloads to be on mmc or tftp. That's what I have been
>> doing on my beaglebone :)
>> 
>> I'm going to update
>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use
>> linus' tree when I get a chance to test a build.
> 
> Hmm, how are the patches in this repository generated? Is there a tree
> that has them as real commits?

If only! I'm manually pulling them from the mailinglist archives and patchwork. I keep hoping for TI to put up a git tree with all their WIP stuff, but I guess that goes into the world peace and pony category of wanting things.

Even with this small patchset I'm already having a ton of merge conflicts in the .dtsi files which is keeping me from posting my patches (e.g. the leds-gpio one) to the proper mailinglists.

Anyway, enough ranting, mainline + those patches now works on my beaglebone so for now I'm a happy camper :)

regards,

Koen

Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 26.07.2012 17:00, Koen Kooi wrote:
> 
>> With Ajay's usb patches you can easily boot from a usb stick, you'll
>> only need the bootloads to be on mmc or tftp. That's what I have been
>> doing on my beaglebone :)
>> 
>> I'm going to update
>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use
>> linus' tree when I get a chance to test a build.
> 
> Hmm, how are the patches in this repository generated? Is there a tree
> that has them as real commits?

If only! I'm manually pulling them from the mailinglist archives and patchwork. I keep hoping for TI to put up a git tree with all their WIP stuff, but I guess that goes into the world peace and pony category of wanting things.

Even with this small patchset I'm already having a ton of merge conflicts in the .dtsi files which is keeping me from posting my patches (e.g. the leds-gpio one) to the proper mailinglists.

Anyway, enough ranting, mainline + those patches now works on my beaglebone so for now I'm a happy camper :)

regards,

Koen

Re: Current state of AM33xx patches

[Daniel Mack]

On 26.07.2012 18:09, Koen Kooi wrote:
> 
> Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het
> volgende geschreven:
> 
>> On 26.07.2012 17:00, Koen Kooi wrote:
>> 
>>> With Ajay's usb patches you can easily boot from a usb stick,
>>> you'll only need the bootloads to be on mmc or tftp. That's what
>>> I have been doing on my beaglebone :)
>>> 
>>> I'm going to update 
>>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use 
>>> linus' tree when I get a chance to test a build.
>> 
>> Hmm, how are the patches in this repository generated? Is there a
>> tree that has them as real commits?
> 
> If only! I'm manually pulling them from the mailinglist archives and
> patchwork. I keep hoping for TI to put up a git tree with all their
> WIP stuff, but I guess that goes into the world peace and pony
> category of wanting things.
> 
> Even with this small patchset I'm already having a ton of merge
> conflicts in the .dtsi files which is keeping me from posting my
> patches (e.g. the leds-gpio one) to the proper mailinglists.
> 
> Anyway, enough ranting, mainline + those patches now works on my
> beaglebone so for now I'm a happy camper :)

I'm not on beaglebone here, so things are different. I'd be happy to get
some sniplet that make the cpsw stuff work ...


Daniel

Current state of AM33xx patches

[Daniel Mack]

On 26.07.2012 18:09, Koen Kooi wrote:
> 
> Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het
> volgende geschreven:
> 
>> On 26.07.2012 17:00, Koen Kooi wrote:
>> 
>>> With Ajay's usb patches you can easily boot from a usb stick,
>>> you'll only need the bootloads to be on mmc or tftp. That's what
>>> I have been doing on my beaglebone :)
>>> 
>>> I'm going to update 
>>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use 
>>> linus' tree when I get a chance to test a build.
>> 
>> Hmm, how are the patches in this repository generated? Is there a
>> tree that has them as real commits?
> 
> If only! I'm manually pulling them from the mailinglist archives and
> patchwork. I keep hoping for TI to put up a git tree with all their
> WIP stuff, but I guess that goes into the world peace and pony
> category of wanting things.
> 
> Even with this small patchset I'm already having a ton of merge
> conflicts in the .dtsi files which is keeping me from posting my
> patches (e.g. the leds-gpio one) to the proper mailinglists.
> 
> Anyway, enough ranting, mainline + those patches now works on my
> beaglebone so for now I'm a happy camper :)

I'm not on beaglebone here, so things are different. I'd be happy to get
some sniplet that make the cpsw stuff work ...


Daniel

Re: Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 19:46 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 26.07.2012 18:09, Koen Kooi wrote:
>> 
>> Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het
>> volgende geschreven:
>> 
>>> On 26.07.2012 17:00, Koen Kooi wrote:
>>> 
>>>> With Ajay's usb patches you can easily boot from a usb stick,
>>>> you'll only need the bootloads to be on mmc or tftp. That's what
>>>> I have been doing on my beaglebone :)
>>>> 
>>>> I'm going to update 
>>>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use 
>>>> linus' tree when I get a chance to test a build.
>>> 
>>> Hmm, how are the patches in this repository generated? Is there a
>>> tree that has them as real commits?
>> 
>> If only! I'm manually pulling them from the mailinglist archives and
>> patchwork. I keep hoping for TI to put up a git tree with all their
>> WIP stuff, but I guess that goes into the world peace and pony
>> category of wanting things.
>> 
>> Even with this small patchset I'm already having a ton of merge
>> conflicts in the .dtsi files which is keeping me from posting my
>> patches (e.g. the leds-gpio one) to the proper mailinglists.
>> 
>> Anyway, enough ranting, mainline + those patches now works on my
>> beaglebone so for now I'm a happy camper :)
> 
> I'm not on beaglebone here, so things are different. I'd be happy to get
> some sniplet that make the cpsw stuff work ...

2/3 of the way there:

http://patchwork.ozlabs.org/patch/174085/
http://patchwork.ozlabs.org/patch/174086/

I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(

regards,

Koen

Current state of AM33xx patches

[Koen Kooi]

Op 26 jul. 2012, om 19:46 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 26.07.2012 18:09, Koen Kooi wrote:
>> 
>> Op 26 jul. 2012, om 17:58 heeft Daniel Mack <zonque@gmail.com> het
>> volgende geschreven:
>> 
>>> On 26.07.2012 17:00, Koen Kooi wrote:
>>> 
>>>> With Ajay's usb patches you can easily boot from a usb stick,
>>>> you'll only need the bootloads to be on mmc or tftp. That's what
>>>> I have been doing on my beaglebone :)
>>>> 
>>>> I'm going to update 
>>>> https://github.com/beagleboard/kernel/tree/beaglebone-3.6 to use 
>>>> linus' tree when I get a chance to test a build.
>>> 
>>> Hmm, how are the patches in this repository generated? Is there a
>>> tree that has them as real commits?
>> 
>> If only! I'm manually pulling them from the mailinglist archives and
>> patchwork. I keep hoping for TI to put up a git tree with all their
>> WIP stuff, but I guess that goes into the world peace and pony
>> category of wanting things.
>> 
>> Even with this small patchset I'm already having a ton of merge
>> conflicts in the .dtsi files which is keeping me from posting my
>> patches (e.g. the leds-gpio one) to the proper mailinglists.
>> 
>> Anyway, enough ranting, mainline + those patches now works on my
>> beaglebone so for now I'm a happy camper :)
> 
> I'm not on beaglebone here, so things are different. I'd be happy to get
> some sniplet that make the cpsw stuff work ...

2/3 of the way there:

http://patchwork.ozlabs.org/patch/174085/
http://patchwork.ozlabs.org/patch/174086/

I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(

regards,

Koen

Re: Current state of AM33xx patches

[Daniel Mack]

On 31.07.2012 21:29, Koen Kooi wrote:

> 2/3 of the way there:
> 
> http://patchwork.ozlabs.org/patch/174085/
> http://patchwork.ozlabs.org/patch/174086/
> 
> I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(

Yes, that's because there are couple of sytax errors in the example
bindings. Mugunthan, could you repost these patches and at least copy
devicetree-discuss@lists.ozlabs.org and the ARM kernel mailing list? I
can't comment on the patches you sent to netdev@vger.kernel.org because
I'm not currently subscribed to that list.


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 31.07.2012 21:29, Koen Kooi wrote:

> 2/3 of the way there:
> 
> http://patchwork.ozlabs.org/patch/174085/
> http://patchwork.ozlabs.org/patch/174086/
> 
> I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(

Yes, that's because there are couple of sytax errors in the example
bindings. Mugunthan, could you repost these patches and at least copy
devicetree-discuss at lists.ozlabs.org and the ARM kernel mailing list? I
can't comment on the patches you sent to netdev at vger.kernel.org because
I'm not currently subscribed to that list.


Thanks,
Daniel

Re: Current state of AM33xx patches

[Koen Kooi]

Op 2 aug. 2012, om 17:30 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 31.07.2012 21:29, Koen Kooi wrote:
> 
>> 2/3 of the way there:
>> 
>> http://patchwork.ozlabs.org/patch/174085/
>> http://patchwork.ozlabs.org/patch/174086/
>> 
>> I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(
> 
> Yes, that's because there are couple of sytax errors in the example
> bindings.

Not only that, it's actually missing params and other params are wrong. See my non-constructive rant in the commit message: http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch

But I still can't get it working:

root@beaglebone:~# dmesg | grep -i cpsw
[   13.504425] net eth0: initializing cpsw version 1.12 (0)

root@beaglebone:~# dmesg | grep -i phy 
[    0.000000] Booting Linux on physical CPU 0
[    0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already exists
[   13.512056] libphy: PHY davinci_mdio-0:00 not found
[   13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0
[   13.523516] libphy: PHY davinci_mdio-0:01 not found
[   13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1

root@beaglebone:~# ifconfig -a | grep eth
eth0      Link encap:Ethernet  HWaddr 00:04:9F:01:1B:B8  

> Mugunthan, could you repost these patches and at least copy
> devicetree-discuss@lists.ozlabs.org and the ARM kernel mailing list? I
> can't comment on the patches you sent to netdev@vger.kernel.org because
> I'm not currently subscribed to that list.


Same here, I'm only on l-o, but I guess I'll need to subscribe dt-discuss in the near future :)

regards,

Koen

Current state of AM33xx patches

[Koen Kooi]

Op 2 aug. 2012, om 17:30 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 31.07.2012 21:29, Koen Kooi wrote:
> 
>> 2/3 of the way there:
>> 
>> http://patchwork.ozlabs.org/patch/174085/
>> http://patchwork.ozlabs.org/patch/174086/
>> 
>> I keep failing to create a .dts that doesn't upset the dtc, so I don't have it working yet :(
> 
> Yes, that's because there are couple of sytax errors in the example
> bindings.

Not only that, it's actually missing params and other params are wrong. See my non-constructive rant in the commit message: http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch

But I still can't get it working:

root at beaglebone:~# dmesg | grep -i cpsw
[   13.504425] net eth0: initializing cpsw version 1.12 (0)

root at beaglebone:~# dmesg | grep -i phy 
[    0.000000] Booting Linux on physical CPU 0
[    0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already exists
[   13.512056] libphy: PHY davinci_mdio-0:00 not found
[   13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0
[   13.523516] libphy: PHY davinci_mdio-0:01 not found
[   13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1

root at beaglebone:~# ifconfig -a | grep eth
eth0      Link encap:Ethernet  HWaddr 00:04:9F:01:1B:B8  

> Mugunthan, could you repost these patches and at least copy
> devicetree-discuss at lists.ozlabs.org and the ARM kernel mailing list? I
> can't comment on the patches you sent to netdev at vger.kernel.org because
> I'm not currently subscribed to that list.


Same here, I'm only on l-o, but I guess I'll need to subscribe dt-discuss in the near future :)

regards,

Koen

Re: Current state of AM33xx patches

[Daniel Mack]

On 02.08.2012 17:37, Koen Kooi wrote:
> Not only that, it's actually missing params and other params are
> wrong. See my non-constructive rant in the commit message:
> http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch
>
>  But I still can't get it working:
> 
> root@beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
> initializing cpsw version 1.12 (0)
> 
> root@beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
> type USB2 PHY already exists [   13.512056] libphy: PHY
> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
> davinci_mdio-0:01 not found on slave 1

That is because the davinci_mdio driver is not yet probed from DT. I
hooked up bindings to that driver and also had to augment the clock
definitions, but that's giving me an "external abort on non-linefetch"
at boot time. Most probably because there's something missing in the
clock setup. Not sure whether I should debug that any further or if
anyone has patches for that.

Mugunthan, how did you test your DT bindings? Could you push your entire
tree somewhere maybe for others to have a look at it? I have no problem
helping you in any way, I just want to know where we currently are.


Thanks for you work,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 02.08.2012 17:37, Koen Kooi wrote:
> Not only that, it's actually missing params and other params are
> wrong. See my non-constructive rant in the commit message:
> http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch
>
>  But I still can't get it working:
> 
> root at beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
> initializing cpsw version 1.12 (0)
> 
> root at beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
> type USB2 PHY already exists [   13.512056] libphy: PHY
> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
> davinci_mdio-0:01 not found on slave 1

That is because the davinci_mdio driver is not yet probed from DT. I
hooked up bindings to that driver and also had to augment the clock
definitions, but that's giving me an "external abort on non-linefetch"
at boot time. Most probably because there's something missing in the
clock setup. Not sure whether I should debug that any further or if
anyone has patches for that.

Mugunthan, how did you test your DT bindings? Could you push your entire
tree somewhere maybe for others to have a look at it? I have no problem
helping you in any way, I just want to know where we currently are.


Thanks for you work,
Daniel

Re: Current state of AM33xx patches

[Daniel Mack]

On 02.08.2012 17:37, Koen Kooi wrote:
>  But I still can't get it working:
> 
> root@beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
> initializing cpsw version 1.12 (0)
> 
> root@beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
> type USB2 PHY already exists [   13.512056] libphy: PHY
> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
> davinci_mdio-0:01 not found on slave 1
> 
> root@beaglebone:~# ifconfig -a | grep eth eth0      Link
> encap:Ethernet  HWaddr 00:04:9F:01:1B:B8

Ok, I got it up and and running now on my board using the two
davinci_mdio drivers and the hwmod addition I just posted.

With those applied on top of Mugunthan work, I can link my cpsw slave
with the phy id "davinci_mdio.18-:04", but the 18 is just the global
device counter which will change again once I add more devices. That
still needs some cleanup.

Anyway, at least I can boot into my NFS root now :) Koen, can you try
this on your board and see if that works for you as well?


Thanks,
Daniel

Current state of AM33xx patches

[Daniel Mack]

On 02.08.2012 17:37, Koen Kooi wrote:
>  But I still can't get it working:
> 
> root at beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
> initializing cpsw version 1.12 (0)
> 
> root at beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
> type USB2 PHY already exists [   13.512056] libphy: PHY
> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
> davinci_mdio-0:01 not found on slave 1
> 
> root at beaglebone:~# ifconfig -a | grep eth eth0      Link
> encap:Ethernet  HWaddr 00:04:9F:01:1B:B8

Ok, I got it up and and running now on my board using the two
davinci_mdio drivers and the hwmod addition I just posted.

With those applied on top of Mugunthan work, I can link my cpsw slave
with the phy id "davinci_mdio.18-:04", but the 18 is just the global
device counter which will change again once I add more devices. That
still needs some cleanup.

Anyway, at least I can boot into my NFS root now :) Koen, can you try
this on your board and see if that works for you as well?


Thanks,
Daniel

Re: Current state of AM33xx patches

[Koen Kooi]

Op 2 aug. 2012, om 21:56 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 02.08.2012 17:37, Koen Kooi wrote:
>> But I still can't get it working:
>> 
>> root@beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
>> initializing cpsw version 1.12 (0)
>> 
>> root@beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
>> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
>> type USB2 PHY already exists [   13.512056] libphy: PHY
>> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
>> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
>> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
>> davinci_mdio-0:01 not found on slave 1
>> 
>> root@beaglebone:~# ifconfig -a | grep eth eth0      Link
>> encap:Ethernet  HWaddr 00:04:9F:01:1B:B8
> 
> Ok, I got it up and and running now on my board using the two
> davinci_mdio drivers and the hwmod addition I just posted.
> 
> With those applied on top of Mugunthan work, I can link my cpsw slave
> with the phy id "davinci_mdio.18-:04", but the 18 is just the global
> device counter which will change again once I add more devices. That
> still needs some cleanup.
> 
> Anyway, at least I can boot into my NFS root now :) Koen, can you try
> this on your board and see if that works for you as well?

[koen@Angstrom-F16-vm-rpm kernel]$ git diff
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index ac7fab5..c33a05d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -33,6 +33,11 @@
                };
        };
 
+       mdio: davinci_mdio@4a101000 {
+               compatible = "ti,davinci-mdio";
+               ti,hwmods = "davinci_mdio";
+       };
+
        mac: ethernet@4A100000 {
                compatible = "ti,cpsw";
                ti,hwmods = "cpgmac0";
@@ -49,19 +54,13 @@
                no_bd_ram = <0>;
                rx_descs = <64>;
                mac_control = <0x20>;
-               slaves = <2>;
+               slaves = <1>;
                slave@0 {
                        slave_reg_ofs = <0x208>;
                        sliver_reg_ofs = <0xd80>;
-                       phy_id = "davinci_mdio-0:00";
+                       phy_id = "davinci_mdio.21-:00";
                        mac-address = [00 04 9F 01 1B B8];
                };
-               slave@1 {
-                       slave_reg_ofs = <0x308>;
-                       sliver_reg_ofs = <0xdc0>;
-                       phy_id = "davinci_mdio-0:01";
-                       mac-address = [00 04 9F 01 1B B9];
-               };
        };
 };


leads to:

[   14.127177] net eth0: initializing cpsw version 1.12 (0)
[   14.135038] net eth0: phy found : id is : 0x7c0f1
[   17.871215] libphy: davinci_mdio.21-:00 - Link is Up - 100/Full

So you can add my Tested-by: to the patches if you want :)

regards,

Koen

Current state of AM33xx patches

[Koen Kooi]

Op 2 aug. 2012, om 21:56 heeft Daniel Mack <zonque@gmail.com> het volgende geschreven:

> On 02.08.2012 17:37, Koen Kooi wrote:
>> But I still can't get it working:
>> 
>> root at beaglebone:~# dmesg | grep -i cpsw [   13.504425] net eth0:
>> initializing cpsw version 1.12 (0)
>> 
>> root at beaglebone:~# dmesg | grep -i phy [    0.000000] Booting Linux
>> on physical CPU 0 [    0.228496] nop_usb_xceiv phy.17: transceiver
>> type USB2 PHY already exists [   13.512056] libphy: PHY
>> davinci_mdio-0:00 not found [   13.517168] net eth0: phy
>> davinci_mdio-0:00 not found on slave 0 [   13.523516] libphy: PHY
>> davinci_mdio-0:01 not found [   13.528675] net eth0: phy
>> davinci_mdio-0:01 not found on slave 1
>> 
>> root at beaglebone:~# ifconfig -a | grep eth eth0      Link
>> encap:Ethernet  HWaddr 00:04:9F:01:1B:B8
> 
> Ok, I got it up and and running now on my board using the two
> davinci_mdio drivers and the hwmod addition I just posted.
> 
> With those applied on top of Mugunthan work, I can link my cpsw slave
> with the phy id "davinci_mdio.18-:04", but the 18 is just the global
> device counter which will change again once I add more devices. That
> still needs some cleanup.
> 
> Anyway, at least I can boot into my NFS root now :) Koen, can you try
> this on your board and see if that works for you as well?

[koen at Angstrom-F16-vm-rpm kernel]$ git diff
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index ac7fab5..c33a05d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -33,6 +33,11 @@
                };
        };
 
+       mdio: davinci_mdio at 4a101000 {
+               compatible = "ti,davinci-mdio";
+               ti,hwmods = "davinci_mdio";
+       };
+
        mac: ethernet at 4A100000 {
                compatible = "ti,cpsw";
                ti,hwmods = "cpgmac0";
@@ -49,19 +54,13 @@
                no_bd_ram = <0>;
                rx_descs = <64>;
                mac_control = <0x20>;
-               slaves = <2>;
+               slaves = <1>;
                slave at 0 {
                        slave_reg_ofs = <0x208>;
                        sliver_reg_ofs = <0xd80>;
-                       phy_id = "davinci_mdio-0:00";
+                       phy_id = "davinci_mdio.21-:00";
                        mac-address = [00 04 9F 01 1B B8];
                };
-               slave at 1 {
-                       slave_reg_ofs = <0x308>;
-                       sliver_reg_ofs = <0xdc0>;
-                       phy_id = "davinci_mdio-0:01";
-                       mac-address = [00 04 9F 01 1B B9];
-               };
        };
 };


leads to:

[   14.127177] net eth0: initializing cpsw version 1.12 (0)
[   14.135038] net eth0: phy found : id is : 0x7c0f1
[   17.871215] libphy: davinci_mdio.21-:00 - Link is Up - 100/Full

So you can add my Tested-by: to the patches if you want :)

regards,

Koen

RE: Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque@gmail.com]
> Sent: Thursday, August 02, 2012 9:01 PM
> To: Koen Kooi
> Cc: N, Mugunthan V; Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar;
> Jason Kridner; Tony Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin,
> Chase; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> On 31.07.2012 21:29, Koen Kooi wrote:
> 
> > 2/3 of the way there:
> >
> > http://patchwork.ozlabs.org/patch/174085/
> > http://patchwork.ozlabs.org/patch/174086/
> >
> > I keep failing to create a .dts that doesn't upset the dtc, so I
> don't have it working yet :(
> 
> Yes, that's because there are couple of sytax errors in the example
> bindings. Mugunthan, could you repost these patches and at least copy
> devicetree-discuss@lists.ozlabs.org and the ARM kernel mailing list? I
> can't comment on the patches you sent to netdev@vger.kernel.org because
> I'm not currently subscribed to that list.
> 
> 
> Thanks,
> Daniel

I will repost the patch set including the device tree and arm kernel mailing list today.

Regards
Mugunthan V N

Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Daniel Mack [mailto:zonque at gmail.com]
> Sent: Thursday, August 02, 2012 9:01 PM
> To: Koen Kooi
> Cc: N, Mugunthan V; Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar;
> Jason Kridner; Tony Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin,
> Chase; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> On 31.07.2012 21:29, Koen Kooi wrote:
> 
> > 2/3 of the way there:
> >
> > http://patchwork.ozlabs.org/patch/174085/
> > http://patchwork.ozlabs.org/patch/174086/
> >
> > I keep failing to create a .dts that doesn't upset the dtc, so I
> don't have it working yet :(
> 
> Yes, that's because there are couple of sytax errors in the example
> bindings. Mugunthan, could you repost these patches and at least copy
> devicetree-discuss at lists.ozlabs.org and the ARM kernel mailing list? I
> can't comment on the patches you sent to netdev at vger.kernel.org because
> I'm not currently subscribed to that list.
> 
> 
> Thanks,
> Daniel

I will repost the patch set including the device tree and arm kernel mailing list today.

Regards
Mugunthan V N

RE: Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Koen Kooi [mailto:koen@dominion.thruhere.net]
> Sent: Thursday, August 02, 2012 9:08 PM
> To: Daniel Mack
> Cc: N, Mugunthan V; Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar;
> Jason Kridner; Tony Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin,
> Chase; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> 
> Op 2 aug. 2012, om 17:30 heeft Daniel Mack <zonque@gmail.com> het
> volgende geschreven:
> 
> > On 31.07.2012 21:29, Koen Kooi wrote:
> >
> >> 2/3 of the way there:
> >>
> >> http://patchwork.ozlabs.org/patch/174085/
> >> http://patchwork.ozlabs.org/patch/174086/
> >>
> >> I keep failing to create a .dts that doesn't upset the dtc, so I
> don't have it working yet :(
> >
> > Yes, that's because there are couple of sytax errors in the example
> > bindings.
> 
> Not only that, it's actually missing params and other params are wrong.
> See my non-constructive rant in the commit message:
> http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-
> add-broken-cpsw-DT.patch
> 
> But I still can't get it working:
> 
> root@beaglebone:~# dmesg | grep -i cpsw
> [   13.504425] net eth0: initializing cpsw version 1.12 (0)
> 
> root@beaglebone:~# dmesg | grep -i phy
> [    0.000000] Booting Linux on physical CPU 0
> [    0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already
> exists
> [   13.512056] libphy: PHY davinci_mdio-0:00 not found
> [   13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0
> [   13.523516] libphy: PHY davinci_mdio-0:01 not found
> [   13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1
> 
> root@beaglebone:~# ifconfig -a | grep eth
> eth0      Link encap:Ethernet  HWaddr 00:04:9F:01:1B:B8
> 
> > Mugunthan, could you repost these patches and at least copy
> > devicetree-discuss@lists.ozlabs.org and the ARM kernel mailing list?
> I
> > can't comment on the patches you sent to netdev@vger.kernel.org
> because
> > I'm not currently subscribed to that list.
> 
> 
> Same here, I'm only on l-o, but I guess I'll need to subscribe dt-
> discuss in the near future :)
> 
> regards,
> 
> Koen

I am not aware that the examples should simple be copy pastable and so had
a non compatible example. Will fix this in the next version and will be posting soon.

Regards
Mugunthan V N

Current state of AM33xx patches

[N, Mugunthan V]

> -----Original Message-----
> From: Koen Kooi [mailto:koen at dominion.thruhere.net]
> Sent: Thursday, August 02, 2012 9:08 PM
> To: Daniel Mack
> Cc: N, Mugunthan V; Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar;
> Jason Kridner; Tony Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin,
> Chase; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> 
> Op 2 aug. 2012, om 17:30 heeft Daniel Mack <zonque@gmail.com> het
> volgende geschreven:
> 
> > On 31.07.2012 21:29, Koen Kooi wrote:
> >
> >> 2/3 of the way there:
> >>
> >> http://patchwork.ozlabs.org/patch/174085/
> >> http://patchwork.ozlabs.org/patch/174086/
> >>
> >> I keep failing to create a .dts that doesn't upset the dtc, so I
> don't have it working yet :(
> >
> > Yes, that's because there are couple of sytax errors in the example
> > bindings.
> 
> Not only that, it's actually missing params and other params are wrong.
> See my non-constructive rant in the commit message:
> http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-
> add-broken-cpsw-DT.patch
> 
> But I still can't get it working:
> 
> root at beaglebone:~# dmesg | grep -i cpsw
> [   13.504425] net eth0: initializing cpsw version 1.12 (0)
> 
> root at beaglebone:~# dmesg | grep -i phy
> [    0.000000] Booting Linux on physical CPU 0
> [    0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already
> exists
> [   13.512056] libphy: PHY davinci_mdio-0:00 not found
> [   13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0
> [   13.523516] libphy: PHY davinci_mdio-0:01 not found
> [   13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1
> 
> root at beaglebone:~# ifconfig -a | grep eth
> eth0      Link encap:Ethernet  HWaddr 00:04:9F:01:1B:B8
> 
> > Mugunthan, could you repost these patches and at least copy
> > devicetree-discuss at lists.ozlabs.org and the ARM kernel mailing list?
> I
> > can't comment on the patches you sent to netdev at vger.kernel.org
> because
> > I'm not currently subscribed to that list.
> 
> 
> Same here, I'm only on l-o, but I guess I'll need to subscribe dt-
> discuss in the near future :)
> 
> regards,
> 
> Koen

I am not aware that the examples should simple be copy pastable and so had
a non compatible example. Will fix this in the next version and will be posting soon.

Regards
Mugunthan V N