subject:"Re\: Current state of AM33xx patches"

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

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

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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


Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

This is known thing and clearly mentioned/highlighted above.

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



 Here's a section from my boot log:-
 
 [1.526156] omap_hsmmc mmc.18: Failed to get debounce clk
 [1.577266] omap_hsmmc mmc.19: Failed to get debounce clk
 [1.583961] mmc0: mmc_rescan_try_freq: trying to init card at 40 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 40 Hz
 [1.694232] mmc2: mmc_rescan_try_freq: trying to init card at 40 Hz
 
 AFAIKT there's no direct support for the AM335x EVM or BeagleBone, and we're 
 just running off
 existing non-specific code.
 

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

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

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

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

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

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

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


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

Not really true.

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


Thanks,
Vaibahv

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current state of AM33xx patches

2012-06-29 Thread Daniel Mack

On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
 On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
 On 27.06.2012 14:13, Hiremath, Vaibhav wrote:

 Just to clarify from AM335x perspective,

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

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

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

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

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

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

As an example, am33xx.dtsi yields

uart1: serial@44E09000 {
compatible = ti,omap3-uart;
ti,hwmods = uart1;
clock-frequency = 4800;
};

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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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

+ Benoit

Let me describe based on my understanding,

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

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

Benoit, correct me if I am wrong anywhere.

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current state of AM33xx patches

2012-06-29 Thread Paul Walmsley

On Fri, 29 Jun 2012, Daniel Mack wrote:

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

 The question is: is that the way things should be kept for OMAP/AM33xx? 
 Or should work be done to move all that hwmod stuff to proper 
 clk/irq/res definitions that can be used from DT generically?

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

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

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

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

The hwmod data is unrelated to the board files.

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

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

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

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


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current state of AM33xx patches

2012-06-28 Thread Daniel Mack

On 27.06.2012 14:13, Hiremath, Vaibhav wrote:

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

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

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

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


Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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

Coming back to your question,

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

Build Steps:

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

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

U-Boot commands to boot:

setenv bootcmd 'mmc rescan 0; fatload mmc 0 8100 uImage; fatload mmc 0 
8200 ramdisk-pm.gz; bootm 8100'
setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw 
initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial'
boot


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

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

On Tue, Jun 26, 2012 at 17:12:03, Nori, Sekhar wrote:
Hi Daniel,

On 6/25/2012 11:47 PM, Daniel Mack wrote:
On 21.06.2012 15:50, Daniel Mack wrote:
On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
From: Daniel Mack zon...@gmail.com
Hey,

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

There is a wiki page [1] that is intended to provide a summary, but I'm
confident it is not up-to-date.

Page updated now...

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

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

ping?

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

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

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

Hope that helps.

Just to clarify from AM335x perspective,

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

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

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

Hi Vaibhav

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

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

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



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
 Hi Vaibhav
 
 On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
 
  Build Steps:
  
   - make ARCH=arm CROSS_COMPILE=toolchain distclean
   - make ARCH=arm CROSS_COMPILE=toolchain omap2plus_defconfig
   - Enable option CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT
   - make ARCH=arm CROSS_COMPILE=toolchain uImage-dtb.am335x-evm
 (Since I am not using DT aware u-boot)
  
  Use the ramdisk image to boot kernel, since we do not have support for any 
  storage devices in the mainline.
  
  U-Boot commands to boot:
  
  setenv bootcmd 'mmc rescan 0; fatload mmc 0 8100 uImage; fatload mmc 0 
  8200 ramdisk-pm.gz; bootm 8100'
  setenv bootargs 'console=ttyO0,115200n8 mem=128M root=/dev/ram rw 
  initrd=0x8200,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=0x8200,16MB ramdisk_size=65536 
 earlyprintk=serial ignore_loglevel debug
 uenvcmd=mmc rescan 0; fatload mmc 0 8100 uImage; fatload mmc 0 8200 
 ramdisk-pm.gz; bootm 8100
 
 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 8100 ...
Image Name:   Linux-3.5.0-rc1-11828-ge2b3dd1

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

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

arm/dts: Add support for AM335x BeagleBone





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

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



U-Boot SPL 2011.09-9-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-9-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=0x8200,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 8100 uImage-dtb.am335x-evm
reading uImage-dtb.am335x-evm

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

2022580 bytes read
U-Boot# bootm 8100
## Booting kernel from Legacy Image at 8100 ...
   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.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.5.0-rc1-11827-g67e68668 (a0393758@psplinux064) 
(gcc version 4.5.3 20110311 (prerelease) (GCC) ) #2 SMP Thu Jun 28 00:20:09 IST 
2012
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00]

RE: Current state of AM33xx patches

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

 On Thu, Jun 28, 2012 at 00:01:06, Paul Walmsley wrote:
  On Wed, 27 Jun 2012, Hiremath, Vaibhav wrote:
  
  The branch used was your am335x-upstream-staging branch, plus a minor 
  patch to allow the kernel to build on an am335x-only config (although for 
  the purposes of this test, omap2plus_defconfig was used).

 Something seems to be wrong here???
 The HEAD is,
 
 commit 67e686682dc286d90a0ed47b7dc68fb54944d3d9
 Author: AnilKumar Ch anilku...@ti.com
 Date:   Thu Jun 21 12:33:58 2012 +0530
 
 arm/dts: Add support for AM335x BeagleBone

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


- Paul

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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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

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

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


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

Hi Vaibhav,

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


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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


Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches

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

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

Just tried the kernel from this; no luck.

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

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

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


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Current state of AM33xx patches