Skip to contentSkip to conversation

Current state of AM33xx patches

DISCUSSION Daniel Mack 11 participants 51 messages Jun 11, 2012 – Aug 3, 2012

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

From: Daniel Mack <[email protected]>

Quoted 4 lines

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

Quoted 3 lines

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.

Quoted 4 lines

Thanks,
Daniel

#2 lore raw
Quoted 14 lines

-----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 <[email protected]>

Quoted 2 lines

Hey,

Quoted 9 lines
Quoted 2 lines

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

Quoted 20 lines

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

Quoted 3 lines

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.

Quoted 4 lines

Thanks,
Daniel

#3 lore raw
In reply to Jason Kridner
Quoted 8 lines · Jason Kridner

From: Daniel Mack <[email protected]>

Quoted 4 lines

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

#4 lore raw
Quoted 7 lines · Vaibhav
Quoted 6 lines · Jason Kridner

From: Daniel Mack <[email protected]>

Quoted 4 lines

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?

Quoted 6 lines
Quoted 2 lines

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

#5 lore raw
Quoted 11 lines · Daniel Mack
Quoted 10 lines · Vaibhav
Quoted 8 lines · Jason Kridner

From: Daniel Mack <[email protected]>

Quoted 4 lines

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.

Quoted 7 lines
Quoted 3 lines

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?

#6 lore raw

Hi Daniel,

Quoted 14 lines · Daniel Mack
Quoted 13 lines · Daniel Mack
Quoted 12 lines · Vaibhav
Quoted 8 lines · Jason Kridner

From: Daniel Mack <[email protected]>

Quoted 4 lines

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...

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

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

#7 lore raw
Quoted 33 lines · Sekhar

Hi Daniel,

Quoted 14 lines · Daniel Mack
Quoted 13 lines · Daniel Mack
Quoted 12 lines · Vaibhav
Quoted 8 lines · Jason Kridner

From: Daniel Mack <[email protected]>

Quoted 4 lines

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...

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

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].

Quoted 5 lines

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

#8 lore raw
Quoted 6 lines · Vaibhav

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

#9 lore raw

Am 28.06.2012 17:09, schrieb Daniel Mack:

Quoted 9 lines · Vaibhav
Quoted 7 lines

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.

Quoted 7 lines

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

#10 lore raw
Quoted 15 lines · Yegor Yefremov

Am 28.06.2012 17:09, schrieb Daniel Mack:

Quoted 14 lines · Vaibhav
Quoted 7 lines

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.

Quoted 7 lines
Quoted 2 lines

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

#11 lore raw

Am 29.06.2012 19:43, schrieb Hiremath, Vaibhav:

Quoted 15 lines · Yegor Yefremov
Quoted 14 lines

Am 28.06.2012 17:09, schrieb Daniel Mack:

Quoted 13 lines · Vaibhav
Quoted 7 lines

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.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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

#12 lore raw
In reply to Daniel Mack
Quoted 9 lines · Daniel Mack
Quoted 6 lines · Vaibhav

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.

Quoted 8 lines

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

#13 lore raw
Quoted 15 lines · Vaibhav
Quoted 14 lines · Daniel Mack
Quoted 6 lines · Vaibhav

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.

Quoted 6 lines
Quoted 3 lines

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

#14 lore raw
Quoted 56 lines · Daniel Mack
Quoted 15 lines · Vaibhav
Quoted 14 lines · Daniel Mack
Quoted 6 lines · Vaibhav

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 7 lines

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

#15 lore raw
In reply to Daniel Mack
Quoted 8 lines · Daniel Mack

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.

Quoted 2 lines

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.

Quoted 1 line

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

#16 lore raw

Hi Paul,

Quoted 26 lines · Paul Walmsley
Quoted 8 lines · Daniel Mack

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.

Quoted 8 lines
Quoted 2 lines

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

#17 lore raw
Quoted 2 lines · Daniel Mack

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.

Quoted 1 line

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

#18 lore raw
Quoted 9 lines · Paul Walmsley
Quoted 2 lines · Daniel Mack

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.

Quoted 5 lines
Quoted 1 line

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.

Quoted 4 lines

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

#19 lore raw
Quoted 27 lines · Vaibhav
Quoted 9 lines · Paul Walmsley
Quoted 2 lines · Daniel Mack

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.

Quoted 5 lines
Quoted 1 line

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.

Quoted 4 lines

drivers/net/ethernet/ti/davinci_mdio.c

Those might work for you.

Quoted 8 lines

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

#20 lore raw
Quoted 45 lines

-----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

Quoted 7 lines · Vaibhav
Quoted 6 lines · Paul Walmsley
Quoted 2 lines · Daniel Mack

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

Quoted 1 line
Quoted 1 line

for the AM33xx. There might be some missing integration code to build

the

Quoted 25 lines
Quoted 2 lines

devices for the newer IP blocks, though.

I would also be interested to know more here.

Quoted 5 lines
Quoted 1 line

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.

Quoted 4 lines

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

Quoted 7 lines
Quoted 2 lines

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

#21 lore raw
Quoted 48 lines · Mugunthan V
Quoted 48 lines

-----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

Quoted 7 lines · Vaibhav
Quoted 6 lines · Paul Walmsley
Quoted 2 lines · Daniel Mack

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

Quoted 1 line
Quoted 1 line

for the AM33xx. There might be some missing integration code to build

the

Quoted 27 lines
Quoted 2 lines

devices for the newer IP blocks, though.

I would also be interested to know more here.

Quoted 5 lines
Quoted 1 line

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.

Quoted 4 lines

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.

Quoted 7 lines
Quoted 4 lines

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

#22 lore raw
Quoted 63 lines

-----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

Quoted 9 lines · Mugunthan V
Quoted 9 lines

-----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

Quoted 5 lines
Quoted 5 lines · Vaibhav
Quoted 4 lines · Paul Walmsley
Quoted 3 lines · Daniel Mack
Quoted 2 lines

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

for

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

the components I need.

Hmm. Which drivers are you working on? Vaibhav Hiremath has hwmod

data

Quoted 1 line
Quoted 1 line

for the AM33xx. There might be some missing integration code to

build

Quoted 32 lines
Quoted 32 lines

the

Quoted 19 lines
Quoted 2 lines

devices for the newer IP blocks, though.

I would also be interested to know more here.

Quoted 5 lines
Quoted 1 line

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.

Quoted 4 lines

drivers/net/ethernet/ti/davinci_mdio.c

Those might work for you.

Quoted 8 lines

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?

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

#23 lore raw
Quoted 10 lines · Mugunthan V
Quoted 7 lines · Mugunthan V
Quoted 3 lines

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

#24 lore raw

Op 26 jul. 2012, om 16:52 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 16 lines · Mugunthan V
Quoted 10 lines
Quoted 7 lines · Mugunthan V
Quoted 3 lines

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.

Quoted 5 lines

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

#25 lore raw
Quoted 7 lines · Koen Kooi

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

#26 lore raw

Op 26 jul. 2012, om 17:58 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 6 lines · Koen Kooi
Quoted 5 lines

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 :)

Quoted 6 lines
Quoted 3 lines

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

#27 lore raw
Quoted 22 lines · Koen Kooi

Op 26 jul. 2012, om 17:58 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 6 lines · Koen Kooi
Quoted 5 lines

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 :)

Quoted 6 lines
Quoted 3 lines

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.

Quoted 6 lines

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

#28 lore raw

Op 26 jul. 2012, om 19:46 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 27 lines · Koen Kooi
Quoted 26 lines

Op 26 jul. 2012, om 17:58 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 6 lines · Koen Kooi
Quoted 5 lines

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 :)

Quoted 6 lines
Quoted 3 lines

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.

Quoted 5 lines
Quoted 2 lines

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

#29 lore raw
Quoted 6 lines · Koen Kooi

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

#30 lore raw

Op 2 aug. 2012, om 17:30 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 11 lines · Koen Kooi
Quoted 7 lines

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

Quoted 4 lines

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

#31 lore raw
Quoted 9 lines · Koen Kooi

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)

Quoted 7 lines

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

#32 lore raw
In reply to Koen Kooi
Quoted 13 lines · Koen Kooi

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

Quoted 2 lines

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

#33 lore raw

Op 2 aug. 2012, om 21:56 heeft Daniel Mack <[email protected]> het volgende geschreven:

Quoted 20 lines · Koen Kooi
Quoted 13 lines

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

Quoted 2 lines

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.

Quoted 7 lines

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

arch/arm/boot/dts/am335x-bone.dts +7 -8
index ac7fab5..c33a05d 100644
@@ -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

#34 lore raw
In reply to Koen Kooi
Quoted 57 lines

-----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 <[email protected]> het volgende geschreven:

Quoted 8 lines · Koen Kooi
Quoted 7 lines

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 :(

Quoted 3 lines

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

Quoted 2 lines

Mugunthan, could you repost these patches and at least copy devicetree-discuss at lists.ozlabs.org and the ARM kernel mailing list?

I

Quoted 1 line

can't comment on the patches you sent to netdev at vger.kernel.org

because

Quoted 1 line

I'm not currently subscribed to that list.

Quoted 6 lines

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

#35 lore raw
In reply to Daniel Mack
Quoted 27 lines

-----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

Quoted 6 lines · Koen Kooi

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.

Quoted 2 lines

Thanks,
Daniel

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

Regards
Mugunthan V N

#36 lore raw
In reply to Daniel Mack
Quoted 5 lines · 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?

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.

Quoted 3 lines

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

Quoted 4 lines

Thanks,
Daniel

#37 lore raw

Hello,

Quoted 6 lines · Vaibhav Hiremath

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.

Quoted 3 lines

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

#38 lore raw
Quoted 13 lines · Domenico Andreoli

Hello,

Quoted 6 lines · Vaibhav Hiremath

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.

Quoted 7 lines
Quoted 3 lines

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

#39 lore raw

Hi Vaibhav

Quoted 11 lines · Vaibhav

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.

Quoted 8 lines

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 ...

#40 lore raw
Quoted 73 lines · Paul Walmsley

Hi Vaibhav

Quoted 11 lines · Vaibhav

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.

Quoted 8 lines

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

Quoted 6 lines

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 <[email protected]>
Date:   Thu Jun 21 12:33:58 2012 +0530

arm/dts: Add support for AM335x BeagleBone

Quoted 11 lines

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 /]#

#41 lore raw
Quoted 7 lines · Vaibhav
Quoted 5 lines · Paul Walmsley

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).

Quoted 8 lines

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

commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9

Author: AnilKumar Ch <[email protected]>
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

arch/arm/mach-omap2/io.c +5 -1
index d09ccc1..e6f4117 100644
@@ -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();
#42 lore raw
Quoted 36 lines · Paul Walmsley
Quoted 7 lines · Vaibhav
Quoted 5 lines · Paul Walmsley

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).

Quoted 8 lines

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

commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9

Author: AnilKumar Ch <[email protected]>
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

arch/arm/mach-omap2/io.c +0 -0
index d09ccc1..e6f4117 100644
@@ -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.

arch/arm/mach-omap2/io.c void __init omap2430_init_late(void) · line 396

Quoted 10 lines
arch/arm/mach-omap2/io.c +5 -1
+ *
+ * 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

#43 lore raw
Quoted 2 lines · Vaibhav

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

#46 lore raw
Quoted 8 lines · Vaibhav
Quoted 5 lines · Paul Walmsley

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

#47 lore raw
In reply to Hiremath, Vaibhav

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.

#48 lore raw
In reply to Hiremath, Vaibhav
Quoted 15 lines · Vaibhav

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.

Quoted 8 lines

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

#49 lore raw
Quoted 23 lines · Mark Jackson
Quoted 22 lines · Vaibhav

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

Quoted 4 lines
Quoted 1 line

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."

Quoted 11 lines

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
Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 4 lines

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

#50 lore raw
Quoted 9 lines · Vaibhav
Quoted 3 lines · Mark Jackson

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>

Quoted 11 lines
Quoted 3 lines

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