OMAP baseline test results for v3.7-rc3

OMAP baseline test results for v3.7-rc3

[Paul Walmsley]

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-omap&m=135082257727502&w=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-kernel&m=135127961519817&w=2

* 3530es3beagle: hangs during off-mode dynamic idle test
  - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c:
    - http://marc.info/?l=linux-omap&m=135075364705188&w=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-omap&m=134833869730129&w=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-kernel&m=135071372426971&w=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      bss    total  kernel
  +1141      +88      -64    +1165  am33xx_only
  +1037      +32      -48    +1021  n800_multi_omap2xxx
  +1053      +32      -48    +1037  n800_only_a
  +1317      +40        0    +1357  omap1_defconfig
  +1285       +8        0    +1293  omap1_defconfig_1510innovator_only
  +1333      +40        0    +1373  omap1_defconfig_5912osk_only
  +1433      +80      -64    +1449  omap2plus_defconfig
  +1089        0      -32    +1057  omap2plus_defconfig_2430sdp_only
  +1429      +56      -64    +1421  omap2plus_defconfig_cpupm
  +1377      +88        0    +1465  omap2plus_defconfig_no_pm
  +1273      -24        0    +1249  omap2plus_defconfig_omap2_4_only
  +1509        0        0    +1509  omap2plus_defconfig_omap3_4_only
 +17468        0        0   +17468  rmk_omap3430_ldp_oldconfig
  +1033      +56        0    +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          kconfig
    -8k     8k      .      .  5912osk        omap2plus_defconfig
    -8k     8k      .      .  am335xbone     omap2plus_defconfig


--------------------------------------------------------------

Branch: test_v3.7-rc3
Test-Serial: 20121028162003
Commit-ID: 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64
Test-Target-Board-Count: 11


- Paul

OMAP baseline test results for v3.7-rc3

[Vaibhav Hiremath]

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-omap&m=135082257727502&w=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 80000000 am335x-bone.dtb
reading am335x-bone.dtb

4391 bytes read
U-Boot# fatload mmc 0 81000000 uImage
reading uImage

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

2022580 bytes read
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw
initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
   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 80000000
   Booting using the fdt blob at 0x80000000
   Loading Kernel Image ... OK
OK
   Loading Device Tree to 8fe65000, end 8fe69126 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.7.0-rc3 (a0393758 at psplinux064) (gcc
version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Oct 30 09:46:04
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 BeagleBone
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192
d15744 u36864
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 64768
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M
root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536
earlyprintk=serial
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 229112k/229112k available, 33032k 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 : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc06c4b68   (6899 kB)
[    0.000000]       .init : 0xc06c5000 - 0xc0715280   ( 321 kB)
[    0.000000]       .data : 0xc0716000 - 0xc07a13a0   ( 557 kB)
[    0.000000]        .bss : 0xc07a13c4 - 0xc0cfbd6c   (5483 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    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.001132] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[    0.107570] pid_max: default: 32768 minimum: 301
[    0.108239] Security Framework initialized
[    0.108448] Mount-cache hash table entries: 512
[    0.118568] CPU: Testing write buffer coherency: ok
[    0.119689] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.119779] Setting up static identity map for 0x804d5ee0 - 0x804d5f50
[    0.122980] Brought up 1 CPUs
[    0.123011] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[    0.147810] pinctrl core: initialized pinctrl subsystem
[    0.156141] regulator-dummy: no parameters
[    0.158749] NET: Registered protocol family 16
[    0.159728] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[    0.161208] omap-gpmc omap-gpmc: GPMC revision 6.0
[    0.161436] omap-gpmc omap-gpmc: failed to reserve memory
[    0.161536] omap-gpmc: probe of omap-gpmc failed with error -16
[    0.190579] OMAP GPIO hardware version 0.1
[    0.206252] No ATAGs?
[    0.206283] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.293742] bio: create slab <bio-0> at 0
[    0.400896] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[    0.408799] SCSI subsystem initialized
[    0.411752] usbcore: registered new interface driver usbfs
[    0.413025] usbcore: registered new interface driver hub
[    0.414113] usbcore: registered new device driver usb
[    0.431103] omap_i2c 44e0b000.i2c: bus 0 rev2.4.0 at 400 kHz
[    0.442630] Switching to clocksource gp_timer
[    0.597669] NET: Registered protocol family 2
[    0.600545] TCP established hash table entries: 8192 (order: 4, 65536
bytes)
[    0.601064] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    0.605997] TCP: Hash tables configured (established 8192 bind 8192)
[    0.606290] TCP: reno registered
[    0.606333] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.606678] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.607821] NET: Registered protocol family 1
[    0.609499] RPC: Registered named UNIX socket transport module.
[    0.609529] RPC: Registered udp transport module.
[    0.609545] RPC: Registered tcp transport module.
[    0.609561] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.610891] Trying to unpack rootfs image as initramfs...
[    0.613489] rootfs image is not initramfs (no cpio magic); looks like
an initrd
[    0.755899] Freeing initrd memory: 16384K
[    0.756108] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.756747] CPU PMU: probing PMU on CPU 0
[    0.756984] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5
counters available
[    0.963611] VFS: Disk quotas dquot_6.5.2
[    0.963913] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.967591] NFS: Registering the id_resolver key type
[    0.968222] Key type id_resolver registered
[    0.968255] Key type id_legacy registered
[    0.968449] jffs2: version 2.2. (NAND) (SUMMARY)  ? 2001-2006 Red
Hat, Inc.
[    0.969172] msgmni has been set to 479
[    0.973697] io scheduler noop registered
[    0.973729] io scheduler deadline registered
[    0.973866] io scheduler cfq registered (default)
[    0.977713] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.985692] omap_uart 44e09000.serial: did not get pins for uart0
error: -19
[    0.986374] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a
OMAP UART0
[    1.590551] console [ttyO0] enabled
[    1.634342] brd: module loaded
[    1.663009] loop: module loaded
[    1.673903] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.682057] OneNAND driver initializing
[    1.693805] usbcore: registered new interface driver asix
[    1.700157] usbcore: registered new interface driver cdc_ether
[    1.707228] usbcore: registered new interface driver smsc95xx
[    1.714312] usbcore: registered new interface driver net1080
[    1.721103] usbcore: registered new interface driver cdc_subset
[    1.728096] usbcore: registered new interface driver zaurus
[    1.734875] usbcore: registered new interface driver cdc_ncm
[    1.743641] usbcore: registered new interface driver cdc_wdm
[    1.749802] Initializing USB Mass Storage driver...
[    1.755830] usbcore: registered new interface driver usb-storage
[    1.762172] USB Mass Storage support registered.
[    1.767796] usbcore: registered new interface driver usbtest
[    1.776135] mousedev: PS/2 mouse device common for all mice
[    1.787377] i2c /dev entries driver
[    1.793669] Driver for 1-wire Dallas network protocol.
[    1.803608] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout
60 sec
[    1.816899] usbcore: registered new interface driver usbhid
[    1.823040] usbhid: USB HID core driver
[    1.828816] oprofile: using arm/armv7
[    1.833658] TCP: cubic registered
[    1.837422] Initializing XFRM netlink socket
[    1.842165] NET: Registered protocol family 17
[    1.846984] NET: Registered protocol family 15
[    1.852261] Key type dns_resolver registered
[    1.856941] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[    1.865272] ThumbEE CPU extension supported.
[    1.882344] clock: disabling unused clocks to save power
[    1.895621] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    1.907005] RAMDISK: gzip image found at block 0
[    2.380009] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.387220] Freeing init memory: 320K
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.


Thanks,
Vaibhav

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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-omap&m=135082257727502&w=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

OMAP baseline test results for v3.7-rc3

[Paul Walmsley]

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

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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

OMAP baseline test results for v3.7-rc3

[Paul Walmsley]

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-omap&m=135082257727502&w=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

OMAP baseline test results for v3.7-rc3

[Vaibhav Hiremath]

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-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

OMAP baseline test results for v3.7-rc3

[Tony Lindgren]

* Vaibhav Hiremath <hvaibhav@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

OMAP baseline test results for v3.7-rc3

[Felipe Balbi]

Hi,

On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> * Vaibhav Hiremath <hvaibhav@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/7f91c9c3/attachment-0001.sig>

OMAP baseline test results for v3.7-rc3

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [121030 10:34]:
> Hi,
> 
> On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > * Vaibhav Hiremath <hvaibhav@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

OMAP baseline test results for v3.7-rc3

[Felipe Balbi]

Hi,

On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121030 10:34]:
> > Hi,
> > 
> > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > * Vaibhav Hiremath <hvaibhav@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/222e00ed/attachment.sig>

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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.

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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

OMAP baseline test results for v3.7-rc3

[Paul Walmsley]

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

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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.

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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 80200000 ...
>    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 80000000 am335x-bone.dtb
fatload mmc 0 81000000 uImage
setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial
sendln 'bootm 81000000 - 80000000'



To build DTB files, use "make dtbs" command on your kernel home directory.

Thanks,
Vaibhav

> Starting kernel ...
> Mark J.
> 

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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 <balbi@ti.com> [121030 10:34]:
> > > Hi,
> > > 
> > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > * Vaibhav Hiremath <hvaibhav@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
> 

OMAP baseline test results for v3.7-rc3

[Felipe Balbi]

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 <balbi@ti.com> [121030 10:34]:
> > > > Hi,
> > > > 
> > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > * Vaibhav Hiremath <hvaibhav@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/6107e7d4/attachment.sig>

OMAP baseline test results for v3.7-rc3

[Felipe Balbi]

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 <balbi@ti.com> [121030 10:34]:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > > * Vaibhav Hiremath <hvaibhav@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/0d4d00f7/attachment.sig>

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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 <balbi@ti.com> [121030 10:34]:
> > > > > Hi,
> > > > > 
> > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > * Vaibhav Hiremath <hvaibhav@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
> 

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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 80000000 am335x-bone.dtb
> fatload mmc 0 81000000 uImage
> setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial
> sendln 'bootm 81000000 - 80000000'
> 
> 
> 
> 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.

OMAP baseline test results for v3.7-rc3

[Hiremath, Vaibhav]

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-00009-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 80000000 am335x-bone.dtb
reading am335x-bone.dtb
4391 bytes read
U-Boot# fatload mmc 0 81000000 uImage
reading uImage
3842256 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz
2022580 bytes read
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
   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 80000000
   Booting using the fdt blob at 0x80000000
   Loading Kernel Image ... OK
OK
   Loading Device Tree to 8fe65000, end 8fe69126 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.7.0-rc4 (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 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 BeagleBone
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 229112k/229112k available, 33032k 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 : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc06c4b94   (6899 kB)
[    0.000000]       .init : 0xc06c5000 - 0xc0715280   ( 321 kB)
[    0.000000]       .data : 0xc0716000 - 0xc07a13a0   ( 557 kB)
[    0.000000]        .bss : 0xc07a13c4 - 0xc0cfbd6c   (5483 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    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.001135] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[    0.107571] pid_max: default: 32768 minimum: 301
[    0.108255] Security Framework initialized
[    0.108464] Mount-cache hash table entries: 512
[    0.118582] CPU: Testing write buffer coherency: ok
[    0.119703] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.119790] Setting up static identity map for 0x804d61e0 - 0x804d6250
[    0.122980] Brought up 1 CPUs
[    0.123012] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[    0.147821] pinctrl core: initialized pinctrl subsystem
[    0.156108] regulator-dummy: no parameters
[    0.158717] NET: Registered protocol family 16
[    0.159696] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.161182] omap-gpmc omap-gpmc: GPMC revision 6.0
[    0.161403] omap-gpmc omap-gpmc: failed to reserve memory
[    0.161501] omap-gpmc: probe of omap-gpmc failed with error -16
[    0.190475] OMAP GPIO hardware version 0.1
[    0.206060] No ATAGs?
[    0.206089] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.293133] bio: create slab <bio-0> at 0
[    0.400112] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[    0.407996] SCSI subsystem initialized
[    0.410955] usbcore: registered new interface driver usbfs
[    0.411594] usbcore: registered new interface driver hub
[    0.413229] usbcore: registered new device driver usb
[    0.418391] omap_i2c 44e0b000.i2c: bus 0 rev2.4.0 at 400 kHz
[    0.430593] Switching to clocksource gp_timer
[    0.586714] NET: Registered protocol family 2
[    0.589620] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    0.590148] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    0.595587] TCP: Hash tables configured (established 8192 bind 8192)
[    0.595897] TCP: reno registered
[    0.595941] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.596311] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.597375] NET: Registered protocol family 1
[    0.599070] RPC: Registered named UNIX socket transport module.
[    0.599101] RPC: Registered udp transport module.
[    0.599117] RPC: Registered tcp transport module.
[    0.599133] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.600475] Trying to unpack rootfs image as initramfs...
[    0.603605] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.746420] Freeing initrd memory: 16384K
[    0.746624] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.747263] CPU PMU: probing PMU on CPU 0
[    0.747496] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    0.953802] VFS: Disk quotas dquot_6.5.2
[    0.954099] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.957740] NFS: Registering the id_resolver key type
[    0.958396] Key type id_resolver registered
[    0.958425] Key type id_legacy registered
[    0.958612] jffs2: version 2.2. (NAND) (SUMMARY)  (c) 2001-2006 Red Hat, Inc.
[    0.959333] msgmni has been set to 479
[    0.964156] io scheduler noop registered
[    0.964191] io scheduler deadline registered
[    0.964331] io scheduler cfq registered (default)
[    0.967982] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.975911] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[    0.976583] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    1.579209] console [ttyO0] enabled
[    1.622741] brd: module loaded
[    1.651866] loop: module loaded
[    1.661935] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.670613] OneNAND driver initializing
[    1.682234] usbcore: registered new interface driver asix
[    1.688544] usbcore: registered new interface driver cdc_ether
[    1.695670] usbcore: registered new interface driver smsc95xx
[    1.702759] usbcore: registered new interface driver net1080
[    1.709533] usbcore: registered new interface driver cdc_subset
[    1.716526] usbcore: registered new interface driver zaurus
[    1.723296] usbcore: registered new interface driver cdc_ncm
[    1.732034] usbcore: registered new interface driver cdc_wdm
[    1.738182] Initializing USB Mass Storage driver...
[    1.744230] usbcore: registered new interface driver usb-storage
[    1.750559] USB Mass Storage support registered.
[    1.756198] usbcore: registered new interface driver usbtest
[    1.764520] mousedev: PS/2 mouse device common for all mice
[    1.775792] i2c /dev entries driver
[    1.782078] Driver for 1-wire Dallas network protocol.
[    1.792090] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    1.805350] usbcore: registered new interface driver usbhid
[    1.811484] usbhid: USB HID core driver
[    1.817257] oprofile: using arm/armv7
[    1.822333] TCP: cubic registered
[    1.825843] Initializing XFRM netlink socket
[    1.830589] NET: Registered protocol family 17
[    1.835398] NET: Registered protocol family 15
[    1.840638] Key type dns_resolver registered
[    1.845380] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.853623] ThumbEE CPU extension supported.
[    1.870806] clock: disabling unused clocks to save power
[    1.884043] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    1.895403] RAMDISK: gzip image found at block 0
[    2.375558] VFS: Mounted root (ext2 filesystem) on device 1:0.
[    2.382761] Freeing init memory: 320K
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.

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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 80000000 am335x-bone.dtb
>> fatload mmc 0 81000000 uImage
>> setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial
>> sendln 'bootm 81000000 - 80000000'
>>
>>
>>
>> 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.

OMAP baseline test results for v3.7-rc3

[Paul Walmsley]

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

OMAP baseline test results for v3.7-rc3

[Mark Jackson]

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.