Hi, all
I met a boot problem for changing a different flash on dm355 evm. I have three
EVM editions:
1. I use MT29F16G08FAA nand flash on TMX320DM355 evm and it boots ok;
2. I use K9F4G08U0A nand flash on TMX320DM355 evm and it boots ok;
3. I use K9F4G08U0A nand flash on TMS320DM355 evm and
I did have to add this after the request irq in the dm9000.c driver. If
/proc/interrupts shows no interrupts for irq 45 then this is most likely the
problem.
#ifdef CONFIG_ARCH_DAVINCI
/* set irq type to rising edge */
davinci_writel(1 1, DAVINCI_GPIO_BASE + 0x24);
#endif
Tom Wheeler twhee...@control4.com writes:
I did have to add this after the request irq in the dm9000.c driver. If
/proc/
interrupts shows no interrupts for irq 45 then this is most likely the
problem.
#ifdef CONFIG_ARCH_DAVINCI
/* set irq type to rising edge */
davinci_writel(1
Kevin,
I had removed the set_irq_type from the board file and was trying it in
the dm9000 driver.
Here is a little history on using the direct IRQ for the dm9000.
When working with the 2.6.10 kernel and the DM6443 I configured the
GPIOs directly and found that the bank interrupt always had to
Tom Wheeler twhee...@control4.com writes:
Kevin,
I had removed the set_irq_type from the board file and was trying it in
the dm9000 driver.
Here is a little history on using the direct IRQ for the dm9000.
Thanks so much for all your detective work here. It's made it much
easier for me to
Kevin,
Here is an interesting bit of info.
I masked the bank0 interrupt in EINT1 and the dm9000 is still running.
This should eliminate the bank0 interrupt from being generated to the
core.
Tom W.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent:
On Friday 01 May 2009, Kevin Hilman wrote:
In debugging this, I've noticed that only using the banked IRQ along
with some strategically placed printk's also gets things working
without the direct IRQ. This suggests there's a timing problem or
race someplace that needs flushing out.
Right,
On Thu, Apr 30, 2009 at 11:04:07AM -0700, Kevin Hilman wrote:
Hi Mark,
Sorry for the review lag and the lack of attention to the da830 stuff.
I've been focusing on getting DaVinci core code reworked and submitted
upstream for the next merge window.
No problem.
These areas have (or will
Laurent,
Thanks once again for your support. Please see below my response with
[MK] prefix. If some more outstanding issues are to be discussed, will it be
possible to talk to you over phone?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone :
Has anyone else been observing issues with the stack walking code
in recent kernels? It's kept me from using lockdep, since when I
enable it I get stuff like shown below. Infrequently, I'm able
to log in and issue a few commands first.
For some reason the top of the stack in these messes always
David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Package on-chip SRAM. It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.
In some cases (dm6467) the physical addresses used
On Fri, May 1, 2009 at 3:52 PM, David Brownell davi...@pacbell.net wrote:
Has anyone else been observing issues with the stack walking code
in recent kernels? It's kept me from using lockdep, since when I
enable it I get stuff like shown below. Infrequently, I'm able
to log in and issue a
12 matches
Mail list logo
