Hi Paul,
Thanks again for all of the help.
> It's described in the 34xx TRM sections 4.11.2 "Device Off-Mode
> Configuration" and 4.11.3 "CORE Power Domain Off-Mode Sequences". All the
> references to off-mode just confuse things, since AFAIK, this wakeup
> mechanism also applies to the device
it is set to 1 via
omap3_enable_io_chain()
8. The PRCM.PM_WKEN_WKUP[8] EN_IO bit is set to 1 via omap3_enable_io_chain()
9. CONTROL_PADCONF_UART3_RTS_SD[14] WAKEUPENABLE0 is set to 1
10. CONTROL_PADCONF_UART3_RTS_SD INPUTENABLE is set to 1
Thanks again,
Rick
> Hello Rick,
>
> On Wed, 1 Dec 2
Hi,
I'm having trouble getting the UART wakeup from sleep via activity
on the RX pin working.
Assumptions (using UART3)
1. Using Arago Linux 2.6.32
2. OMAP3730 is in sleep mode via
echo 1 > /mnt/dbg/pm_debug/sleep_while_idle
3. The UA
Hi,
I've found the problem and below is the fix. It appears your
SMSC9200 is faster than mine ;-) Once in a while mine gets through the
smsc911x_soft_reset() in 100 us but most of the time it takes a full
250 ms.
Rick
--- linux/drivers/net/smsc911x.c.~1~2010-11-08 19:53:03.0 -0
Hi Sanjeev,
Thanks much for the help.
> I tried building the latest on l-o master and was able to boot consistently
> in 4 times I tried. Didn't notice the gpio clock related error I noticed in
> your boot log.
>
>
> U-Boot 2010.09 (Nov 08 2010 - 17:11:45)
>
> OMAP3630/3730-GP ES2.0, CPU-OPP
sanjeev,
Thanks much for the help.
> [sp] On first looks I would suspect the u-boot. 2009.11 seems to be quite old.
> Can you try using version 2010.09?
I had tried 2010.09 on this board originally but found that it
wasn't stable, it was almost like the SDRAM wasn't set up correctly.
I'
_
| |
/ /__
.--._/ (___)
| Rick Bronsonrick at efn dot orgTel 541-485-7264 | (___)
| Amazonia Computing http://www.efn.org/~rick __ o|_ (___)
| 5050
Thanks very much for the help.
> so Rick, you need to load a gadget driver for musb to work, g_ether or
> g_zero are the simplest ones.
But don't I already have the g_zero enabled via:
CONFIG_USB_GADGET_MUSB_HDRC=y
But lets assume that, for the time being, I'm only interested in USB
Host
B_OTG_UTILS=y
Any help greatly app
Tomi,
I agree with both of you. My patch is a bandaid at best. I spend a
fair amount of time trying to find out what's causing the sync lost
interrupts in the first place, mostly be doing peripheral memory space
comparisons of good/bad boots. This let to nothing, all of the
registers off the
Hiroshi,
It works!
I used strace on ping.out and found out you need to be root to run
it. You might add that to your HOWTO. See new HOWTO below.
My device got made but it's 252 instead of 251. Not sure what
that's about.
> ls -al /dev/DspBridge
Hi Hiroshi,
Thanks very much for the help.
I'm getting farther. It would help to have the right path ;-)
Now I"m doing:
sudo modprobe bridgedriver
base_img=/home/rick/dspbridge_binaries/ddspbase_tiomap3430.dof64P
GT_str="**=01234567"
But I still get the same results as far as interr
Hi Hiroshi,
Thanks very much for the help.
Here is the output from
sudo modprobe bridgedriver base_img=ddspbase_tiomap3430.dof64P
GT_str="**=01234567"
http://www.efn.org/~rick/pub/dsp.txt
The first failure seems to be:
RG - 0: G CurrentConfig FAILED
Hi Hiroshi,
I just tried this on my beagleboard and I'm not sure if it worked.
First, did you forget to add that you need "mem=122m" in the
bootargs? Also do you need to add in the addresses like:
sudo modprobe bridgedriver phys_mempool_base=0x87a0
phys_mempool_size=0x60
base_img=/ho
Folks,
Please take a look at this change to drivers/video/omap/dispc.c. It
addresses a problem seen on some boots of OMAP's. On about 1 in 30
boots one gets an endless stream of interrupts from the
DISPC_IRQ_SYNC_LOST bit in the DISPC_IRQSTATUS register. The
following messages are printed.
erial port
problem. But I didn't see any after about 20 reboots.
I assume you mean the patch below but why do you want this one if
your 8250.c patch works?
Rick
Signed-off-by: Rick Bronson <[EMAIL PROTECTED]>
--- linux-omap-2.6/arch/arm/mach-omap2/io.c.~1~ 2008-10-28 10:10:25.
> Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO...
> I didn't try this, since I'm currently not hooking up that serial port,
> but dmesg does show(*):
>
> Serial: 8250/16550 driver3 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST
See previous post with subject:
Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?
Rick
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.
Ignore the last patch I posted.
I'm not sure this is the right fix for this problem but it seems to
work ;-) Here is what's happening
In drivers/serial/8250.c size_fifo() miscalculates the fifo size of
the 3rd UART. The first 2 UART's calculations are okay. The 3rd's
miscalculation caus
It looks like a race condition. Somehow the 8250 ends up with the
LSB of the baud rate register set to 0xff when it's supposed to be
0x1a. I'm still trying to figure it out :( The patch below gets it
working a little but there's still a problem after init runs. Note
that you will need to unde
Tony,
The last patch I posted didn't work quite right. It seems we do
actually come into this macro with none of the pending bits set.
Presumably, because the interrupt hasn't been ack'd yet. Anyway, I've
tested this patch and I think it's golden. It ack's spurious
interrupts and lets the use
Tony,
How does this look?
If we set irq to NR_IRQS then arch/arm/kernel/irq.c will use
bad_irq_desc when it processes the interrupt. NOTE: I haven't tested
this yet.
Rick
--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git
2008-10-22 20:01:33.0 -0700
+++ lin
Tony,
> Well we should let the generic irq handler to do the logging.. But I
> guess nothing will happen if adm_do_IRQ() does not get called.
>
> We could have a dummy handler for some invented higher number that would
> capture the spurious interrupts I guess.
>
> BTW, ideally we would do the l
Tony,
I checked out some other ARM spurious interrupt handling and it
seems that they ack the interrupt but left the macro with the Z bit
set which means that asm_do_IRQ() does not get called. Seems to me we
should do the same, see the patch below. Although, ideally, we should
be logging these
Tony,
I checked out some other ARM spurious interrupt handling and it
seems that they ack the interrupt but left the macro with the Z bit
set which means that asm_do_IRQ() does not get called. Seems to me we
should do the same, see the patch below. Although, ideally, we should
be logging these
> I got a message from someone on the beagleboard mailinglist that
> asound.conf was the culprit, no idea what the exact fix was.
I wonder if you could dig up this guy's contact info. I tried lots
of different asound.conf's but none of them did anything.
Here is what I get without a asound.c
Tony,
Here is the patch against the latest git. I'm a little concerned
about masking the interrupt number so that the spurious bit are
ignored. Do you really want to turn a spurious interrupt into a
normal (good) interrupt?
> Also, AFAIK we don't have infinitely repeating irqs any longer, it'
Sorry if I'm late in the game for changes to entry-macro.S but I
worked on this code a bit ago and have been testing it. What I have,
I think, is a little more straight forward. Note that it doesn't have
the added mask for the spurious bits, but it does check for
spurious interrupts and handle
Dave,
Thanks for the info. This patch did get sound output working. But
input doesn't seem to work. I checked that I really have audio at the
audio-in connector and that the mixer is set right:
> amixer
Simple mixer cont
ion 0.13.2
ALSA device list:
No soundcards found.
Please give me a clue on where to start.
Thanks much.
Rick Bronson
--
To u
Hi,
I got the lastest code on Oct 16 via:
git clone git://source.mvista.com/git/linux-omap-2.6.git
cd linux-omap-2.6
make omap3_beagle_defconfig
make uImage CROSS_COMPILE="arm-angstrom-linux-gnueabi-" CC="ccache
arm-angstrom-linux-gnueabi-gcc-4.2.1+csl-arm-2007q3-53"
LD="arm-angstrom-linux-gn
Hi,
This patch fixes this warning which, as Tomi Valkeinen pointed out, is
really an error.
CC arch/arm/mach-omap2/clock34xx.o
arch/arm/mach-omap2/clock34xx.c: In function 'omap3_noncore_dpll_enable':
arch/arm/mach-omap2/clock34xx.c:290: warning: 'rate' is used uninitialized in
this fun
Rick
_
| |
/ /__
.--._/ (___)
| Rick Bronsonrick at efn dot orgTel 541-485
33 matches
Mail list logo
