Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 09:25:11AM -0800, Tony Lindgren wrote: > * Grant Likely [110107 09:18]: > > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote: > > > Grant, > > > > > > Care to queue or ack the following fix? > > > > If you bounce the patch to me, then I'll pick it up into the spi tree > > and send it on to Linus right away. (It didn't get sent to either me > > or the spi list, so I don't have the original). > > Thanks, bounced it to you. As noted in the original patch, someone who understands this driver should fix the other exit paths so buffers aren't left mapped when they shouldn't be. -- 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: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 03:49:20PM +, Russell King - ARM Linux wrote: > And, with one ARM errata disabled, the kernel finally boots. So the > "X-Loader hangs" message means that we did something that non-secure > mode prevented us from doing. Here's the dmesg with as many things as I could find enabled. Linux version 2.6.37+ (r...@rmk-pc) (gcc version 4.3.5 (GCC) ) #67 SMP PREEMPT Fri Jan 7 19:38:30 GMT 2011 CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: OMAP4430 4430SDP board vmalloc area is too big, limiting to 864MB Memory policy: ECC disabled, Data cache writealloc OMAP4430 ES1.0 SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 FIXME: omap44xx_sram_init not implemented On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c035f540, node_mem_map c0381000 Normal zone: 64 pages used for memmap Normal zone: 0 pages reserved Normal zone: 8128 pages, LIFO batch:0 HighMem zone: 960 pages used for memmap HighMem zone: 121920 pages, LIFO batch:31 PERCPU: Embedded 7 pages/cpu @c0786000 s4192 r8192 d16288 u32768 pcpu-alloc: s4192 r8192 d16288 u32768 alloc=8*4096 pcpu-alloc: [0] 0 [0] 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/mmcblk0p2 ip=dhcp rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2 PID hash table entries: 128 (order: -3, 512 bytes) Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 512MB = 512MB total Memory: 516492k/516492k available, 7796k reserved, 491520K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc280 - 0xf800 ( 856 MB) lowmem : 0xc000 - 0xc200 ( 32 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .init : 0xc0008000 - 0xc002f000 ( 156 kB) .text : 0xc002f000 - 0xc0334000 (3092 kB) .data : 0xc0334000 - 0xc035ff00 ( 176 kB) SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Preemptable hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:402 powerdomain: waited too long for powerdomain dss_pwrdm to complete transition [ cut here ] WARNING: at arch/arm/mach-omap2/clockdomain.c:868 omap2_clkdm_deny_idle+0x58/0xcc() clockdomain: OMAP4 wakeup/sleep dependency support is not yet implemented Modules linked in: Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r7:c0335f30 r6:c004a7f0 r5:c02f6189 r4:0364 [] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x58/0x70) [] (warn_slowpath_common+0x0/0x70) from [] (warn_slowpath_fmt+0x38/0x40) r8:c0347860 r7:c03464c4 r6:0060 r5:c0346f4c r4:c036032c [] (warn_slowpath_fmt+0x0/0x40) from [] (omap2_clkdm_deny_idle+0x58/0xcc) r3: r2:c02f61c7 [] (omap2_clkdm_deny_idle+0x0/0xcc) from [] (clkdm_init+0x144/0x17c) r5:c0347860 r4:c0346f4c [] (clkdm_init+0x0/0x17c) from [] (omap2_init_common_hw+0x20/0xa0) [] (omap2_init_common_hw+0x0/0xa0) from [] (omap_4430sdp_init_irq+0x34/0x54) [] (omap_4430sdp_init_irq+0x0/0x54) from [] (init_IRQ+0x1c/0x24) r4:c035ff00 [] (init_IRQ+0x0/0x24) from [] (start_kernel+0x18c/0x2fc) [] (start_kernel+0x0/0x2fc) from [<80008038>] (0x80008038) r7:c0345cb4 r6:c0029120 r5:c0342bf0 r4:10c53c7d ---[ end trace 1b75b31a2719ed1c ]--- omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. GPMC revision 6.0 OMAP GPIO hardware version 0.1 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 2013.49 BogoMIPS (lpj=7864320) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok L310 cache controller enabled l2x0: 16 ways, CACHE_ID 0x41c2, AUX_CTRL 0x0e05, Cache size: 524288 B CPU1: Booted secondary processor CPU1: Unknown IPI message 0x1 Brought up 2 CPUs SMP: Total of 2 processors activated (4026.98 BogoMIPS). regulator: core version 0.5 regulator: dummy: NET: Registered protocol family 16 OMAP DMA hardware revision 0.0 sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms bio: create slab at 0 i2c_omap i2c_omap.1: bus 1 rev4.0 at 400 kHz Skipping twl internal clock init and using bootloader value (unknown osc rate) twl6030: PIH (irq 39) chaining IRQs 368..387 regulator: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby regulator: VPP: 1800 <--> 2500 mV at 1900 mV normal standby regulator: VUSIM: 1200 <--> 2900 mV at 1800 mV normal standby regulator: VANA: 2100 mV normal standby regulator: VCXIO: 1800 mV normal standby regulator: VDAC: 1800 mV normal standby regulator: VUSB:
RE: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:50 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Saturday, January 08, 2011 12:23 AM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> > >
> > > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar
> wrote:
> > > > > And, with one ARM errata disabled, the kernel finally boots.
> So
> > > the
> > > > > "X-Loader hangs" message means that we did something that
> non-
> > > secure
> > > > > mode prevented us from doing.
> > > > >
> > > > Actually it's not. The error message is quite misleading.
> > > Basically in
> > > > x-loader exception handlers are setup and all these handlers
> > > report
> > > > same message ("X-Loader hangs"). This should be fixed so that
> it
> > > can
> > > > report more meaningful info like data abort, prefetch abort
> etc.
> > > >
> > > > Till the vector relocation in the kernel exceptions are not
> set up
> > > > so code jumps to already installed exceptions in the x-loader
> and
> > > > hence the messege.
> > >
> > > I disagree with your "actually it's not". It was errata 742230,
> > > which
> > > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > > register)
> > > which I bet provokes an undefined instruction trap from non-
> secure
> > > mode.
> > >
> > 742230 errata workaround is not implemented in the x-loader so I
> > can surely say it's not the secure violation.
>
> Precisely. So when we directly read, modify and write this
> diagnostic
> register in the non-secure world during kernel boot, we end up
> faulting.
> Comment those instructions out, we don't get a fault, and the kernel
> boots normally.
I understand now. Was confused last time.
So your custom build did have this errata
CONFIG_ARM_ERRATA_742230 where there is an access
to diagnostic register which is not accessible on OMAP4
from non-secure side.
Thanks for clarification.
Regards,
Santosh
--
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: 4430SDP boot failure - solved + SPI bug fix
On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Saturday, January 08, 2011 12:23 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> >
> > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > > And, with one ARM errata disabled, the kernel finally boots. So
> > the
> > > > "X-Loader hangs" message means that we did something that non-
> > secure
> > > > mode prevented us from doing.
> > > >
> > > Actually it's not. The error message is quite misleading.
> > Basically in
> > > x-loader exception handlers are setup and all these handlers
> > report
> > > same message ("X-Loader hangs"). This should be fixed so that it
> > can
> > > report more meaningful info like data abort, prefetch abort etc.
> > >
> > > Till the vector relocation in the kernel exceptions are not set up
> > > so code jumps to already installed exceptions in the x-loader and
> > > hence the messege.
> >
> > I disagree with your "actually it's not". It was errata 742230,
> > which
> > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > register)
> > which I bet provokes an undefined instruction trap from non-secure
> > mode.
> >
> 742230 errata workaround is not implemented in the x-loader so I
> can surely say it's not the secure violation.
Precisely. So when we directly read, modify and write this diagnostic
register in the non-secure world during kernel boot, we end up faulting.
Comment those instructions out, we don't get a fault, and the kernel
boots normally.
--
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: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:23 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > And, with one ARM errata disabled, the kernel finally boots. So
> the
> > > "X-Loader hangs" message means that we did something that non-
> secure
> > > mode prevented us from doing.
> > >
> > Actually it's not. The error message is quite misleading.
> Basically in
> > x-loader exception handlers are setup and all these handlers
> report
> > same message ("X-Loader hangs"). This should be fixed so that it
> can
> > report more meaningful info like data abort, prefetch abort etc.
> >
> > Till the vector relocation in the kernel exceptions are not set up
> > so code jumps to already installed exceptions in the x-loader and
> > hence the messege.
>
> I disagree with your "actually it's not". It was errata 742230,
> which
> requires access to the CP15, c15, c0, 1 register (a diagnostic
> register)
> which I bet provokes an undefined instruction trap from non-secure
> mode.
>
742230 errata workaround is not implemented in the x-loader so I
can surely say it's not the secure violation.
He is the x-loader source tree.
http://dev.omapzoom.org/?p=bootloader/x-loader.git;a=shortlog;h=refs/heads
/omap4_dev
Even simple things like if DDR is not configured correctly or not
Stable, code/data access takes abort which lands up in the "X-loader
hang messege"
> Hence, the reason it vectored to the X-loader was because we tried
> to
> do something in the non-secure mode which we're prevented from
> doing.
My suspect was clock configurations on the older boot loaders were
Incomplete that might have lead to issue since now more drivers are
getting enabled in newer kernels.
--
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: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > And, with one ARM errata disabled, the kernel finally boots. So the
> > "X-Loader hangs" message means that we did something that non-secure
> > mode prevented us from doing.
> >
> Actually it's not. The error message is quite misleading. Basically in
> x-loader exception handlers are setup and all these handlers report
> same message ("X-Loader hangs"). This should be fixed so that it can
> report more meaningful info like data abort, prefetch abort etc.
>
> Till the vector relocation in the kernel exceptions are not set up
> so code jumps to already installed exceptions in the x-loader and
> hence the messege.
I disagree with your "actually it's not". It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-secure mode.
Hence, the reason it vectored to the X-loader was because we tried to
do something in the non-secure mode which we're prevented from doing.
--
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: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, January 07, 2011 9:19 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely
> on
> > > the board - which should ease the debugging problem as it no
> longer
> > > requires anything but the reset button pressed to test a new
> kernel.
> >
> > Glad to hear that.
>
> And, with one ARM errata disabled, the kernel finally boots. So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
>
Actually it's not. The error message is quite misleading. Basically in
x-loader exception handlers are setup and all these handlers report
same message ("X-Loader hangs"). This should be fixed so that it can
report more meaningful info like data abort, prefetch abort etc.
Till the vector relocation in the kernel exceptions are not set up
so code jumps to already installed exceptions in the x-loader and
hence the messege.
> It would be a good idea if X-loader could tell dump out the
> exception,
> register dump, and for data/prefetch aborts, the relevent FSR and
> FAR
> registers - that would make debugging this kind of failure a lot
> easier.
>
Yes. At least it should report data/prefect aborts.
> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
>
> Running the latest kernel on the 4430SDP board with DMA API
> debugging
> enabled results in this:
>
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has
> not allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
> r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from []
> (warn_slowpath_fmt+0x38/0x40)
> r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from []
> (check_unmap+0x19c/0x6f0)
> r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from []
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from []
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from []
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from []
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from []
> (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from []
> (do_exit+0x0/0x5fc)
> r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
>
> I've no idea why this driver uses NULL for dma_unmap_single instead
> of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
>
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting
> and
> * dcache use. Note that if dma_unmap_single() ever
> starts
> * to do real work on ARM, we'd need to clean up
> mappings
> * for previous transfers on *ALL* exits of this
> loop...
> */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above. I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
>
> Signed-off-by: Russell King
Thanks for fixing it
> ---
> I'm surprised this driver got merged as it has such a comment, and
> is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/
Re: 4430SDP boot failure - solved + SPI bug fix
* Grant Likely [110107 09:18]: > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote: > > Grant, > > > > Care to queue or ack the following fix? > > If you bounce the patch to me, then I'll pick it up into the spi tree > and send it on to Linus right away. (It didn't get sent to either me > or the spi list, so I don't have the original). Thanks, bounced it to you. 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: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> Grant,
>
> Care to queue or ack the following fix?
If you bounce the patch to me, then I'll pick it up into the spi tree
and send it on to Linus right away. (It didn't get sent to either me
or the spi list, so I don't have the original).
Or if you want to pick it up:
Acked-by: Grant Likely
Nothing in my tree touches omap_mcspi.c for this merge window, so
there won't be a merge conflict (I'm assuming you want this fix to go
into 2.6.28).
g.
>
> * Russell King - ARM Linux [110107 07:48]:
> > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > > -Original Message-
> > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > > Sent: Friday, January 07, 2011 7:55 PM
> > > > To: Santosh Shilimkar
> > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > > Subject: Re: 4430SDP boot failure
> > > >
> > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > > >
> > > > > Low level debug as you reported seems to be broken though.
> > > >
> > > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > > > the board - which should ease the debugging problem as it no longer
> > > > requires anything but the reset button pressed to test a new kernel.
> > >
> > > Glad to hear that.
> >
> > And, with one ARM errata disabled, the kernel finally boots. So the
> > "X-Loader hangs" message means that we did something that non-secure
> > mode prevented us from doing.
> >
> > It would be a good idea if X-loader could tell dump out the exception,
> > register dump, and for data/prefetch aborts, the relevent FSR and FAR
> > registers - that would make debugging this kind of failure a lot
> > easier.
> >
> > =
> > Subject: Fix DMA API usage in OMAP MCSPI driver
> >
> > Running the latest kernel on the 4430SDP board with DMA API debugging
> > enabled results in this:
> >
> > WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> > NULL NULL: DMA-API: device driver tries to free DMA memory it has not
> > allocated
> > [device address=0x8129901a] [size=260 bytes]
> > Modules linked in:
> > Backtrace:
> > [] (dump_backtrace+0x0/0x10c) from []
> > (dump_stack+0x18/0x1c)
> > r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> > [] (dump_stack+0x0/0x1c) from []
> > (warn_slowpath_common+0x58/0x70)
> > [] (warn_slowpath_common+0x0/0x70) from []
> > (warn_slowpath_fmt+0x38/0x40)
> > r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> > [] (warn_slowpath_fmt+0x0/0x40) from []
> > (check_unmap+0x19c/0x6f0)
> > r3:c03110de r2:c0304e6b
> > [] (check_unmap+0x0/0x6f0) from []
> > (debug_dma_unmap_page+0x74/0x80)
> > [] (debug_dma_unmap_page+0x0/0x80) from []
> > (omap2_mcspi_work+0x514/0xbf0)
> > [] (omap2_mcspi_work+0x0/0xbf0) from []
> > (process_one_work+0x294/0x400)
> > [] (process_one_work+0x0/0x400) from []
> > (worker_thread+0x220/0x3f8)
> > [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
> > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
> > r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> > ---[ end trace 1b75b31a2719ed20 ]---
> >
> > I've no idea why this driver uses NULL for dma_unmap_single instead of
> > the &spi->dev that is laying around just waiting to be used in that
> > function - but it's an easy fix.
> >
> > Also replace this comment with a FIXME comment:
> > /* Do DMA mapping "early" for better error reporting and
> > * dcache use. Note that if dma_unmap_single() ever starts
> > * to do real work on ARM, we'd need to clean up mappings
> > * for previous transfers on *ALL* exits of this loop...
> > */
> > as the comment is not true - we do work in dma_unmap() functions,
> > particularly on ARMv6 and above. I've corrected the existing unmap
> > functions but if any others are required they must be added ASAP.
> >
> > Signed-off-by: Russell King
>
> Acked-by: Tony Lindgren
>
>
> > ---
> > I'm surprised this driver got merged as it has such a comment, and is
> > abusing the DMA API... well, at least with the DMA API debugging we
> > can now catch this stuff.
> >
> > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> > index 951a160..abb1ffb 100644
> > --- a/drivers/spi/omap2_mcspi.c
> > +++ b/drivers/spi/omap2_mcspi.c
> > @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> > spi_transfer *xfer)
> >
> > if (tx != NULL) {
> > wait_for_completion(&mcspi_dma->dma_tx_completion);
> > - dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
> > + dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
> >
> > /* for TX_ONLY mode, be sure all words have shifted out */
> > if
Re: 4430SDP boot failure - solved + SPI bug fix
Grant,
Care to queue or ack the following fix?
* Russell King - ARM Linux [110107 07:48]:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > > the board - which should ease the debugging problem as it no longer
> > > requires anything but the reset button pressed to test a new kernel.
> >
> > Glad to hear that.
>
> And, with one ARM errata disabled, the kernel finally boots. So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
>
> It would be a good idea if X-loader could tell dump out the exception,
> register dump, and for data/prefetch aborts, the relevent FSR and FAR
> registers - that would make debugging this kind of failure a lot
> easier.
>
> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
>
> Running the latest kernel on the 4430SDP board with DMA API debugging
> enabled results in this:
>
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has not
> allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
> r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from []
> (warn_slowpath_fmt+0x38/0x40)
> r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from []
> (check_unmap+0x19c/0x6f0)
> r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from []
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from []
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from []
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from []
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
> r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
>
> I've no idea why this driver uses NULL for dma_unmap_single instead of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
>
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting and
> * dcache use. Note that if dma_unmap_single() ever starts
> * to do real work on ARM, we'd need to clean up mappings
> * for previous transfers on *ALL* exits of this loop...
> */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above. I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
>
> Signed-off-by: Russell King
Acked-by: Tony Lindgren
> ---
> I'm surprised this driver got merged as it has such a comment, and is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
>
> if (tx != NULL) {
> wait_for_completion(&mcspi_dma->dma_tx_completion);
> - dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
>
> /* for TX_ONLY mode, be sure all words have shifted out */
> if (rx == NULL) {
> @@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
>
> if (rx != NULL) {
> wait_for_completion(&mcspi_dma->dma_rx_completion);
> - dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->rx_dma, count,
> DMA_FROM_DEVICE);
> omap2_mcspi_set_enable(spi, 0);
>
> if (l & OMAP2_MCSPI_CHCONF_TURBO) {
> @@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device
> *spi, struct spi_message *m)
> if (m->is_dma_mapped || len < DMA_MIN_BYTES)
>
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > >
> > > Low level debug as you reported seems to be broken though.
> >
> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > the board - which should ease the debugging problem as it no longer
> > requires anything but the reset button pressed to test a new kernel.
>
> Glad to hear that.
And, with one ARM errata disabled, the kernel finally boots. So the
"X-Loader hangs" message means that we did something that non-secure
mode prevented us from doing.
It would be a good idea if X-loader could tell dump out the exception,
register dump, and for data/prefetch aborts, the relevent FSR and FAR
registers - that would make debugging this kind of failure a lot
easier.
=
Subject: Fix DMA API usage in OMAP MCSPI driver
Running the latest kernel on the 4430SDP board with DMA API debugging
enabled results in this:
WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x8129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
[] (dump_stack+0x0/0x1c) from []
(warn_slowpath_common+0x58/0x70)
[] (warn_slowpath_common+0x0/0x70) from []
(warn_slowpath_fmt+0x38/0x40)
r8:c1839e40 r7: r6:0104 r5: r4:8129901a
[] (warn_slowpath_fmt+0x0/0x40) from []
(check_unmap+0x19c/0x6f0)
r3:c03110de r2:c0304e6b
[] (check_unmap+0x0/0x6f0) from []
(debug_dma_unmap_page+0x74/0x80)
[] (debug_dma_unmap_page+0x0/0x80) from []
(omap2_mcspi_work+0x514/0xbf0)
[] (omap2_mcspi_work+0x0/0xbf0) from []
(process_one_work+0x294/0x400)
[] (process_one_work+0x0/0x400) from []
(worker_thread+0x220/0x3f8)
[] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---
I've no idea why this driver uses NULL for dma_unmap_single instead of
the &spi->dev that is laying around just waiting to be used in that
function - but it's an easy fix.
Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop...
*/
as the comment is not true - we do work in dma_unmap() functions,
particularly on ARMv6 and above. I've corrected the existing unmap
functions but if any others are required they must be added ASAP.
Signed-off-by: Russell King
---
I'm surprised this driver got merged as it has such a comment, and is
abusing the DMA API... well, at least with the DMA API debugging we
can now catch this stuff.
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..abb1ffb 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(&mcspi_dma->dma_tx_completion);
- dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+ dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
/* for TX_ONLY mode, be sure all words have shifted out */
if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (rx != NULL) {
wait_for_completion(&mcspi_dma->dma_rx_completion);
- dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+ dma_unmap_single(&spi->dev, xfer->rx_dma, count,
DMA_FROM_DEVICE);
omap2_mcspi_set_enable(spi, 0);
if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi,
struct spi_message *m)
if (m->is_dma_mapped || len < DMA_MIN_BYTES)
continue;
- /* Do DMA mapping "early" for better error reporting and
-* dcache use. Note that if dma_unmap_single() ever starts
-* to do real work on ARM, we'd need to clean up mappings
-* for previous transfers on *ALL* exits of this loop...
-
