Re: OMAP baseline test results for v3.7-rc3
On 06/11/12 09:47, Mark Jackson wrote: On 06/11/12 06:16, Hiremath, Vaibhav wrote: Where is your DTB? Is it appended to Kernel image? Can you try below sequence/commands from u-boot? mmc rescan 0 fatload mmc 0 8000 am335x-bone.dtb fatload mmc 0 8100 uImage setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial sendln 'bootm 8100 - 8000' To build DTB files, use make dtbs command on your kernel home directory. That works ... great !! But now I'm confused, since I thought the DTB was appended to the uImage file. I have the following in my .config:- ARM_ATAG_DTB_COMPAT=y ARM_APPENDED_DTB=y ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And then I create my uImage file using:- $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage Do you now have to load the DTB as a separate file ? Or should the appended DTB still work ? Any update on this ? Cheers Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On Tue, 13 Nov 2012, Mark Jackson wrote: On 06/11/12 09:47, Mark Jackson wrote: That works ... great !! But now I'm confused, since I thought the DTB was appended to the uImage file. The DTB is appended to the zImage file. You then need to convert the product of the concatenation to uImage format. So ... I have the following in my .config:- ARM_ATAG_DTB_COMPAT=y ARM_APPENDED_DTB=y ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And then I create my uImage file using:- $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb instead of this: $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage something like this is what you need to do instead: $ cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone Do you now have to load the DTB as a separate file ? Or should the appended DTB still work ? Appended DTBs work fine on the testbed here. - 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: OMAP baseline test results for v3.7-rc3
On 13/11/12 15:35, Paul Walmsley wrote: instead of this: $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage something like this is what you need to do instead: $ cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone Works like a charm ... thanks. Mark J. -- 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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which
he has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
--
balbi
signature.asc
Description: Digital signature
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt,
which he has
already submitted to the list recently. So MMC support will
come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
The thread started with need of MMC support without EDMA.
So when I say polling, I would like to try MMC without DMA support, not to
put dependency on EDMA-DMA engine migration patches.
Thanks,
Vaibhav
--
balbi
--
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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 09:07:47AM +0100, Hiremath, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt,
which he has
already submitted to the list recently. So MMC support will
come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets
see how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain
RX DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain
TX DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
The thread started with need of MMC support without EDMA. So when I
say polling, I would like to try MMC without DMA support, not to put
dependency on EDMA-DMA engine migration patches.
I see, so you meant interrupt/PIO mode. That's supposed to be working
and I'm sure Venkat and Balaji test that every now and then.
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
On 06/11/12 06:16, Hiremath, Vaibhav wrote: Where is your DTB? Is it appended to Kernel image? Can you try below sequence/commands from u-boot? mmc rescan 0 fatload mmc 0 8000 am335x-bone.dtb fatload mmc 0 8100 uImage setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial sendln 'bootm 8100 - 8000' To build DTB files, use make dtbs command on your kernel home directory. That works ... great !! But now I'm confused, since I thought the DTB was appended to the uImage file. I have the following in my .config:- ARM_ATAG_DTB_COMPAT=y ARM_APPENDED_DTB=y ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And then I create my uImage file using:- $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage Do you now have to load the DTB as a separate file ? Or should the appended DTB still work ? Cheers Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 11:39:18, Hiremath, Vaibhav wrote: On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: Pulling the tree, let me try now and update you shortly... Just tried -rc4, and it boots up fine for me. I tested it with Mainline u- boot and mainline Kernel, I have pasted log below for reference - U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) I do not suspect anything here, but still think we should use mainline u-boot version. Can you share the images with me, so that I can try them? Log=== U-Boot SPL 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3842256 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3842192 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc4 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 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] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b94 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH:
Re: OMAP baseline test results for v3.7-rc3
On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: On 30/10/12 14:48, Vaibhav Hiremath wrote: Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? Thanks, Vaibhav So I've now spent several days trying to fix this problem, but still no joy. Did my previous emails give any clue as to where I'm going wrong ? Thanks for any help you can provide. Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: Pulling the tree, let me try now and update you shortly... U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) Which U-boot are you using these days? I am using mainline denx u-boot. Thanks, Vaibhav - 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: OMAP baseline test results for v3.7-rc3
On Mon, Nov 05, 2012 at 22:24:28, Mark Jackson wrote: On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: On 30/10/12 14:48, Vaibhav Hiremath wrote: Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? Thanks, Vaibhav So I've now spent several days trying to fix this problem, but still no joy. Did my previous emails give any clue as to where I'm going wrong ? Thanks for any help you can provide. Sorry for delayed response, I was really got pulled into other things, now I am back. I looked at your boot-log, didn't understand how it was booting earlier for you - mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) I2C: ready DRAM: 256 MiB This is important, since u-boot relocated DTB file. WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 29 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... 4315695 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4308448 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Where is your DTB? Is it appended to Kernel image? Can you try below sequence/commands from u-boot? mmc rescan 0 fatload mmc 0 8000 am335x-bone.dtb fatload mmc 0 8100 uImage setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial sendln 'bootm 8100 - 8000' To build DTB files, use make dtbs command on your kernel home directory. Thanks, Vaibhav Starting kernel ... Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he
has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how
it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the past?
Thanks,
Vaibhav
--
balbi
--
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: OMAP baseline test results for v3.7-rc3
Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) Which U-boot are you using these days? - 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: OMAP baseline test results for v3.7-rc3
On 31/10/12 14:24, Mark Jackson wrote: On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 29 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... 4315695 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4308448 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Contents of uEnv.txt mmcrootfstype=ext2 rootwait Vaibhav Does this boot log shed any light on my non-boot problem ? Are we using the same U-Boot version (2012.10-00434-ged296d2) ? Can you post your linux-ohporter .config ? I was also thinking, if the previously mentioned patch [1] was concerning toolchains, what toolchain are you using ? I'm using the latest mainline Buildroot git, which compiles gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89). [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Cheers Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On 30/10/12 14:48, Vaibhav Hiremath wrote: On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote: Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 I just tested this branch (+ one fix which Matt provided [1]) on BeagleBone, and MMC is working without any issues. I have tested with rootFS on MMC card. [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? Cheers Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: On 30/10/12 14:48, Vaibhav Hiremath wrote: On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote: Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 I just tested this branch (+ one fix which Matt provided [1]) on BeagleBone, and MMC is working without any issues. I have tested with rootFS on MMC card. [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? Thanks, Vaibhav Cheers Mark J. -- 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: OMAP baseline test results for v3.7-rc3
On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 29 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... 4315695 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4308448 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Contents of uEnv.txt mmcrootfstype=ext2 rootwait -- 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: OMAP baseline test results for v3.7-rc3
On 30/10/12 02:36, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. Cheers Mark JACKSON -- 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: OMAP baseline test results for v3.7-rc3
cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. - 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: OMAP baseline test results for v3.7-rc3
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote: cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 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: OMAP baseline test results for v3.7-rc3
On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: On 10/30/2012 8:06 AM, Paul Walmsley wrote: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ Please don't worry about this one at the moment. This one isn't part of the automated test suite, so it requires further effort from me to re-test. I've marked it as such in the README. Will try to re-test by v3.7-rc4. - 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: OMAP baseline test results for v3.7-rc3
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote: On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote: cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 I just tested this branch (+ one fix which Matt provided [1]) on BeagleBone, and MMC is working without any issues. I have tested with rootFS on MMC card. [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Thanks, Vaibhav Thanks, Vaibhav ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-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: OMAP baseline test results for v3.7-rc3
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]: MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. This is a bogus dependency, the MMC driver needs to also work without DMA. Regards, Tony -- 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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along
with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along
with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
Regards,
Tony
--
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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he
has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
--
balbi
signature.asc
Description: Digital signature
OMAP baseline test results for v3.7-rc3
Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Caused by RT throttling - Fixed by http://www.spinics.net/lists/arm-kernel/msg202224.html - Patch in rmk's patch system as 7565/1 * 37xx EVM: CORE not entering dynamic off-idle - Dynamic retention-idle seems to work; system suspend to off works - Happens on both MMC root and NFS root - Can be detected by comparing the CORE off/ret counts from /debug/pm_debug/count before after serial autosuspend occurs - Fixed by http://marc.info/?l=linux-arm-kernelm=135127961519817w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c: - http://marc.info/?l=linux-omapm=135075364705188w=2 - Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3) - clock source is from an external I2C-controlled source - must skip reset until the switchover to hwmod late init - http://www.spinics.net/lists/arm-kernel/msg178138.html Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken * 3530ES3 Beagle: I2C timeouts during userspace init - Intermittent, appears on 5 out of 6 boots here - Aaro Koskinen observes this also on N900 - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc - http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 PM tests: * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown - Pending re-test Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent vmlinux object size (delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)): text data bsstotal kernel +1141 +88 -64+1165 am33xx_only +1037 +32 -48+1021 n800_multi_omap2xxx +1053 +32 -48+1037 n800_only_a +1317 +400+1357 omap1_defconfig +1285 +80+1293 omap1_defconfig_1510innovator_only +1333 +400+1373 omap1_defconfig_5912osk_only +1433 +80 -64+1449 omap2plus_defconfig +10890 -32+1057 omap2plus_defconfig_2430sdp_only +1429 +56 -64+1421 omap2plus_defconfig_cpupm +1377 +880+1465 omap2plus_defconfig_no_pm +1273 -240+1249 omap2plus_defconfig_omap2_4_only +150900+1509 omap2plus_defconfig_omap3_4_only +1746800 +17468 rmk_omap3430_ldp_oldconfig +1033 +560+1089 rmk_omap4430_sdp_oldconfig The 17k increase in the rmk_omap3430_ldp_oldconfig text appears to be due to the automatic selection of CONFIG_PINCTRL by 'make oldnoconfig', new in v3.7-rc3. Boot-time memory difference (delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)) avail rsrvd high freed board
Re: OMAP baseline test results for v3.7-rc3
On 10/30/2012 8:06 AM, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ ==Boot Log U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3841320 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3841256 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc3 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Oct 30 09:46:04 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] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b68 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE:
