Re: Inspiration needed to track down early kernel startup crash
On Monday 24 May 2010 09:50:19 am Jon Povey wrote: > Trying to get the git kernel running on our in-house board and have an > unpleasant crash somewhere between kernel start and console output, with > code jumping off to 0x000c. > > This is using u-boot v2010.03 and kernel based on davinci master at > 5954dd1d2cab4b378e22256edbfe132bf4f82f22 > > Sympoms are; this is the last output I get on the console: > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > Maybe you can use earlyprintk for getting more info from the kernel. i.e. earlyprintk=serial,ttyS0,115200 ... Regards, Caglar > If I now halt the CPU over JTAG it tells me: > > target halted in ARM state due to debug-request, current mode: Abort > cpsr: 0x20d7 pc: 0x000c > MMU: enabled, D-Cache: enabled, I-Cache: enabled > > I tried both the vanilla EVM versions of bootloader and kernel, and > in-house modified (for different pinmuxing, board file etc). Both > combinations boot OK on the DM355EVM, both crash in the same way on our > in-house board. This in-house board and many like it were previously > running a MontaVista (DM355 Beta SDK) based setup, so is capable of > running linux and the board design should be sound. > > There is no UBL on the board at present: I am doing initial setup and > loading u-boot over JTAG with OpenOCD. > > I stepped through the code enough to determine that the uncompress, > relocate and jump to kernel (and several instructions after) seems OK. > > I am looking into the ARM ETM/ETB + OpenOCD hoping that could give me a > trace of how I end up at 0x000c but not having any joy with that so > far. > > Inspiration for approaches to debugging this problem would be much > appreciated, running low on ideas. > > Thanks, > > -- > Jon Povey > jon.po...@racelogic.co.uk > > Racelogic is a limited company registered in England. Registered number > 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, > Buckingham, Bucks, MK18 1TB . > > The information contained in this electronic mail transmission is intended > by Racelogic Ltd for the use of the named individual or entity to which it > is directed and may contain information that is confidential or > privileged. If you have received this electronic mail transmission in > error, please delete it from your system without copying or forwarding it, > and notify the sender of the error by reply email so that the sender's > address records can be corrected. The views expressed by the sender of > this communication do not necessarily represent those of Racelogic Ltd. > Please note that Racelogic reserves the right to monitor e-mail > communications passing through its network > > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
sdio on 2.6.18?
Hi, someone has ever successfully used SDIO on 2.6.18 for DM355 ? Thanks, bye. -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
uart interrupt
hi,all: there are three uart in dm6446,i want to read and write by uart-1 the irq number is 41,but i can not rececive data,i think if i have register the uart-1 to the linux kernel,the irq number can be found in /proc/interrupts but there is only 40 which is uart-0's irq number,if the uart driver register the uart-1 failed but in the /dev, the device file is exiseted. why there is no data can be recieved thank you ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/6] davinci: edma: clear events in edma_start()
This patch causes that the sound can not work normally on OMAP_L138.
Stanley.
Kevin Hilman wrote:
From: Brian Niebuhr
This patch fixes an issue where a DMA channel can erroneously process an
event generated by a previous transfer. A failure case is where DMA is
being used for SPI transmit and receive channels on OMAP L138. In this
case there is a single bit that controls all event generation from the
SPI peripheral. Therefore it is possible that between when edma_stop()
has been called for the transmit channel on a previous transfer and
edma_start() is called for the transmit channel on a subsequent transfer,
that a transmit event has been generated.
The fix is to clear events in edma_start(). This prevents false events
from being processed when events are enabled for that channel.
Signed-off-by: Brian Niebuhr
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/dma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 15dd886..260485c 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -1266,7 +1266,8 @@ int edma_start(unsigned channel)
/* EDMA channel with event association */
pr_debug("EDMA: ER%d %08x\n", j,
edma_shadow0_read_array(ctlr, SH_ER, j));
- /* Clear any pending error */
+ /* Clear any pending event or error */
+ edma_write_array(ctlr, EDMA_ECR, j, mask);
edma_write_array(ctlr, EDMA_EMCR, j, mask);
/* Clear any SER */
edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] MUSB: make non-OMAP platforms build with CONFIG_PM=y
Attempt to build MUSB driver with CONFIG_PM=y (e.g. in the OTG mode) on DaVinci
results in these link errors:
drivers/built-in.o: In function `musb_restore_context':
led-triggers.c:(.text+0x714d8): undefined reference to
`musb_platform_restore_context'
drivers/built-in.o: In function `musb_save_context':
led-triggers.c:(.text+0x71788): undefined reference to
`musb_platform_save_context'
This turned out to be caused by commit 9957dd97ec5e98dd334f87ade1d9a0b24d1f86eb
(usb: musb: Fix compile error for omaps for musb_hdrc). Revert it, taking into
account the rename of CONFIG_ARCH_OMAP34XX into CONFIG_ARCH_OMAP3 (which that
commit fixed in a completely inappropriate way) and the recent addition of
OMAP4 support.
Signed-off-by: Sergei Shtylyov
---
This version of patch should be applied to 2.6.35, while the previous one
should be applied to 2.6.34.y...
drivers/usb/musb/musb_core.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/usb/musb/musb_core.h
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -470,7 +470,8 @@ struct musb_csr_regs {
struct musb_context_registers {
-#ifdef CONFIG_PM
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
u32 otg_sysconfig, otg_forcestandby;
#endif
u8 power;
@@ -484,7 +485,8 @@ struct musb_context_registers {
struct musb_csr_regs index_regs[MUSB_C_NUM_EPS];
};
-#ifdef CONFIG_PM
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4)
extern void musb_platform_save_context(struct musb *musb,
struct musb_context_registers *musb_context);
extern void musb_platform_restore_context(struct musb *musb,
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing uboot from Uboot
Hi Guys, Thanks - and yes I'm prepared to use CCS if necesarry - but UBoot upgrades will be much easier from a running system :) I'm on the DM365, but I can't determine the load address... My nand mappings are : [2.25] Creating 4 MTD partitions on "nand_davinci.0": [2.26] 0x-0x0066 : "bootloader" [2.27] 0x0066-0x0068 : "params" [2.27] 0x0068-0x00a8 : "kernel" [2.28] 0x00a8-0x2000 : "filesystem" And I've tried poking around the nand to look at where I might find the UBoot source - but can't "find" it manually. setenv a 0x8 nand read.i 0x8070 $(a) 0x1000; md 0x8070 8070: a1aced00 0100 0007 0004 80700010: 0001 0020 ... 80700020: 80700030: 80700040: 80700050: Anyone got any clues as the correct address? Regards -- Kieran Liu, Yan wrote: I don't know which product you are using. But, there is a way to write uboot from uboot. Here is the sample command: tftp 0x8000 u-boot.bin nand erase 0x1C nandecc sw nand write.i 0x8000 0x1C The can be found in booting log. Typically, you will find the following part: 0x-0x0008 : "xloader-nand" 0x0008-0x0024 : "uboot-nand" 0x0024-0x0028 : "params-nand" 0x0028-0x0078 : "linux-nand" 0x0078-0x2000 : "jffs2-nand" In my case, I use 0x8 as . Hope this helps. Regards, Yan -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Kieran Bingham Sent: Friday, May 21, 2010 1:03 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Flashing uboot from Uboot Hi Guys, As I'm running linux, I can't easily switch to running Windows for CCS. I've been making changes to UBoot and testing them by setting the TEXT_BASE at a different address in RAM, loading via TFTP, and calling go $(loadaddr) Now I would like to write this uboot binary to flash, so I've recompiled it with the original TEXT_BASE, but I can't figure out where I need to flash it in the NAND. Is it possible to reflash uboot from within Uboot? -- Regards Kieran ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Flashing uboot from Uboot
On 05/24/2010 11:02 AM, Kieran Bingham wrote: Hi Guys, Thanks - and yes I'm prepared to use CCS if necesarry - but UBoot upgrades will be much easier from a running system :) I'm on the DM365, but I can't determine the load address... My nand mappings are : [2.25] Creating 4 MTD partitions on "nand_davinci.0": [2.26] 0x-0x0066 : "bootloader" [2.27] 0x0066-0x0068 : "params" [2.27] 0x0068-0x00a8 : "kernel" [2.28] 0x00a8-0x2000 : "filesystem" And I've tried poking around the nand to look at where I might find the UBoot source - but can't "find" it manually. setenv a 0x8 nand read.i 0x8070 $(a) 0x1000; md 0x8070 8070: a1aced00 0100 0007 0004 80700010: 0001 0020 ... 80700020: 80700030: 80700040: 80700050: Anyone got any clues as the correct address? Regards -- Kieran Liu, Yan wrote: I don't know which product you are using. But, there is a way to write uboot from uboot. Here is the sample command: tftp 0x8000 u-boot.bin nand erase 0x1C nandecc sw nand write.i 0x8000 0x1C The can be found in booting log. Typically, you will find the following part: 0x-0x0008 : "xloader-nand" 0x0008-0x0024 : "uboot-nand" 0x0024-0x0028 : "params-nand" 0x0028-0x0078 : "linux-nand" 0x0078-0x2000 : "jffs2-nand" In my case, I use 0x8 as . Hope this helps. Regards, Yan -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Kieran Bingham Sent: Friday, May 21, 2010 1:03 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Flashing uboot from Uboot Hi Guys, As I'm running linux, I can't easily switch to running Windows for CCS. I've been making changes to UBoot and testing them by setting the TEXT_BASE at a different address in RAM, loading via TFTP, and calling go $(loadaddr) Now I would like to write this uboot binary to flash, so I've recompiled it with the original TEXT_BASE, but I can't figure out where I need to flash it in the NAND. Is it possible to reflash uboot from within Uboot? -- Regards Kieran ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Kieran, In the UBL source, I have bootloader.h which defines APP_DESC_START_BLOCK_NUM to be 8. Block 8 of my NAND is supposed to have the start of U-boot. Check your UBL source and you should be able to find the starting block. Use U-boot's nand dump to view the nand without copying to RAM. According to UBL, the data stored should contain the APP_BOOT structure. You can examine it to make sure this is correct. To be honest, I haven't done this in a long time, I generally have setup SD card booting or USB booting for reflashing boards. My comment about CCS loading was only for emergency loading. It is not desirable but sometimes necessary. Steve -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC 1/4] Davinci: mdio - separate out mdio controller code
"Nori, Sekhar" writes: > Hi Cyril, > > On Wed, May 19, 2010 at 20:35:58, Chemparathy, Cyril wrote: >> Hi Sekhar, >> >> [...] >> >>> Also, can you keep this as a platform variable (with >> >>> a 2.2 MHz default)? The frequency depends on the board, >> >>> and although most boards work at 2.2 MHz, not having it >> >>> as a platform variable will make adding a board with a >> >>> different frequency requirement difficult. >> >> >> >> I am not quite convinced that you'll have too many boards deviate from >> >> the 2MHz ballpark. That seems to be a nice and safe frequency that >> >> works well across phys, socs, and boards. >> >> >> >> That said, if we see the need to override the bus frequency in future, I >> >> am all for a patch at that time. As it stands, I don't see the value in >> >> adding platform data definitions for a capability that is not going to >> >> be used at present. >> > >> > Okay, but why regress on existing functionality? >> >> I don't quite think that the prior existence of a "knob" is reason >> enough to keep it around, considering that the knob is essentially >> unused (below). > > AFAIR, some boards in mach-omap2 use this driver as well. Hope > you searched them as well before concluding that it is unused. Also, there are many, many boards out there that have not been submitted upstream (and whose maintainers do not read this list.) While that is a problem in and of itself, I do not want to break those boards on the assumption that some board-specific knob is unused. >> In short, we currently have a knob for frequency control, but we don't >> use board-specific numbers from characterization data (if available). >> That said, what good is the knob? All that it does at present, is muddy >> up the code with identical definitions on every board. > > You can decide to default to 2.2 MHz if there is no platform data > that way there wouldn't be any additional code in any of the board > files. Agreed. Feel free to drop the setting in the board files if it is just using the default. That will help avoid duplicating the redundant code when board files are copy-pasted to create new boards. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC 2/4] Davinci: mdio - add clock lookups for mdio
Cyril Chemparathy writes:
> The standalone davinci mdio drivers acquires its own (possible separate)
> clock. On existing architectures where MDIO is built into the EMAC subsystem,
> the same underlying clock is used by both mdio and emac.
>
> Signed-off-by: Cyril Chemparathy
The preferred method for this is to use clk_add_alias().
Kevin
> ---
> arch/arm/mach-davinci/da830.c |1 +
> arch/arm/mach-davinci/da850.c |1 +
> arch/arm/mach-davinci/dm365.c |1 +
> arch/arm/mach-davinci/dm644x.c |1 +
> arch/arm/mach-davinci/dm646x.c |1 +
> 5 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
> index 3a7a96f..8fe0292 100644
> --- a/arch/arm/mach-davinci/da830.c
> +++ b/arch/arm/mach-davinci/da830.c
> @@ -416,6 +416,7 @@ static struct clk_lookup da830_clks[] = {
> CLK(NULL, "aintc",&aintc_clk),
> CLK(NULL, "secu_mgr", &secu_mgr_clk),
> CLK("davinci_emac.1", NULL, &emac_clk),
> + CLK("davinci_mdio.0", NULL, &emac_clk),
> CLK(NULL, "gpio", &gpio_clk),
> CLK("i2c_davinci.2",NULL, &i2c1_clk),
> CLK(NULL, "usb11",&usb11_clk),
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 6b8331b..5cb8a92 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -373,6 +373,7 @@ static struct clk_lookup da850_clks[] = {
> CLK(NULL, "arm", &arm_clk),
> CLK(NULL, "rmii", &rmii_clk),
> CLK("davinci_emac.1", NULL, &emac_clk),
> + CLK("davinci_mdio.0", NULL, &emac_clk),
> CLK("davinci-mcasp.0", NULL, &mcasp_clk),
> CLK("da8xx_lcdc.0", NULL, &lcdc_clk),
> CLK("davinci_mmc.0",NULL, &mmcsd_clk),
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index e5e3dce..a2c832f 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -458,6 +458,7 @@ static struct clk_lookup dm365_clks[] = {
> CLK(NULL, "timer3", &timer3_clk),
> CLK(NULL, "usb", &usb_clk),
> CLK("davinci_emac.1", NULL, &emac_clk),
> + CLK("davinci_mdio.0", NULL, &emac_clk),
> CLK("davinci_voicecodec", NULL, &voicecodec_clk),
> CLK("davinci-asp.0", NULL, &asp0_clk),
> CLK(NULL, "rto", &rto_clk),
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 7ad1520..001b9a1 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -300,6 +300,7 @@ static struct clk_lookup dm644x_clks[] = {
> CLK(NULL, "uart1", &uart1_clk),
> CLK(NULL, "uart2", &uart2_clk),
> CLK("davinci_emac.1", NULL, &emac_clk),
> + CLK("davinci_mdio.0", NULL, &emac_clk),
> CLK("i2c_davinci.1", NULL, &i2c_clk),
> CLK("palm_bk3710", NULL, &ide_clk),
> CLK("davinci-asp", NULL, &asp_clk),
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 9404565..60b7a8a 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -343,6 +343,7 @@ static struct clk_lookup dm646x_clks[] = {
> CLK("davinci-mcasp.1", NULL, &mcasp1_clk),
> CLK(NULL, "aemif", &aemif_clk),
> CLK("davinci_emac.1", NULL, &emac_clk),
> + CLK("davinci_mdio.0", NULL, &emac_clk),
> CLK(NULL, "pwm0", &pwm0_clk),
> CLK(NULL, "pwm1", &pwm1_clk),
> CLK(NULL, "timer0", &timer0_clk),
> --
> 1.7.0.4
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 4/4] davinci: Fix transparency handling with dm365.
Cyril Chemparathy writes:
> Hi,
>
> [...]
>> -if (cpu_is_davinci_dm355()) {
>> +if (cpu_is_davinci_dm355() || cpu_is_davinci_dm365()) {
>
> Why does this driver have cpu_is_ macros all over the place?
Because this driver has not yet been submitted for review. ;) I
believe it is only in the Arago tree at the moment.
> Isn't there a way to pass in the device capabilities via pdata?
Hopefully there is when it is posted.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/4] Assorted davinci fixes.
"Nori, Sekhar" writes: > Hi Gilles, > > On Tue, May 18, 2010 at 18:24:56, Gilles Chanteperdrix wrote: >> >> Hi, >> >> while experimenting with a davinci DM368, I had a few issues which the >> following patches serie try and fix. >> >> Thanks in advance for your review. > > It seems these patches apply to the arago-project.org hosted davinci-staging > tree and not to upstream v4l2 tree or Kevin's davinci tree. > > In such cases, please note this fact in the patch 0/N and/or below the --- > in patch description so that folks interested in upstream development only > can ignore these patches. > > DaVinci display is still not upstream yet. We are working on cleaning up the > code and preparing the code for upstream submissions. Fixes like these will > surely help the process. Thanks for the work! In addition to Sekhar's comments, please include a more descriptive changelog in your patches. The subject typically summarizes _what_ is being done, and the changelog should go into more detail to answer _what_, but also answer _why_. Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Inspiration needed to track down early kernel startup crash
Caglar Akyuz writes: > On Monday 24 May 2010 09:50:19 am Jon Povey wrote: >> Trying to get the git kernel running on our in-house board and have an >> unpleasant crash somewhere between kernel start and console output, with >> code jumping off to 0x000c. >> >> This is using u-boot v2010.03 and kernel based on davinci master at >> 5954dd1d2cab4b378e22256edbfe132bf4f82f22 >> >> Sympoms are; this is the last output I get on the console: >> >> Starting kernel ... >> >> Uncompressing Linux... done, booting the kernel. >> > > Maybe you can use earlyprintk for getting more info from the kernel. i.e. > earlyprintk=serial,ttyS0,115200 ... Don't forget to enable early printk support in Kconfig either. Another trick to get early printk output using JTAG: Look for the address of __log_buf in System.map, then use your debugger to dump that region in ASCII format. This is the printk buffer, so you can any printk output there, including the kernel crash dump. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/6] davinci: edma: clear events in edma_start()
[please don't top post, moved your reply below original...] "stanley.miao" writes: > Kevin Hilman wrote: >> From: Brian Niebuhr >> >> This patch fixes an issue where a DMA channel can erroneously process an >> event generated by a previous transfer. A failure case is where DMA is >> being used for SPI transmit and receive channels on OMAP L138. In this >> case there is a single bit that controls all event generation from the >> SPI peripheral. Therefore it is possible that between when edma_stop() >> has been called for the transmit channel on a previous transfer and >> edma_start() is called for the transmit channel on a subsequent transfer, >> that a transmit event has been generated. >> >> The fix is to clear events in edma_start(). This prevents false events >> from being processed when events are enabled for that channel. >> > > This patch causes that the sound can not work normally on OMAP_L138. > Can you describe "can not work normally"? Does that mean simply does not work, or works with pops & clicks etc.? Just to clarify... how did you isolate it to this patch. If you revert just this patch on current davinci git, do you have working sound as you expect again? Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 0/6] Davinci: initial tnetv107x patch series
Cyril Chemparathy writes: > This patch series adds support for TNETV107X - a Texas Instruments SOC that > shares a number of common features with the Davinci architecture. > > This version includes two minor fixes over the v6 series posted earlier. > > Cyril Chemparathy (6): > Davinci: generalized debug macros > Davinci: tnetv107x decompresser uart definitions > Davinci: tnetv107x soc support > Davinci: tnetv107x initial gpio support > Davinci: tnetv107x evm board initial support > Davinci: tnetv107x default configuration Thanks, applying (after dropping parens pointed out be Sergei.) Will queue for 2.6.36. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
toolchain for davinci kernel
hi, Where I can download the toolchain to compile the laster davinci linux kernel? Best Regards! 2010-05-25 e-eo ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: toolchain for davinci kernel
On 25 May 2010 05:54, e-eo wrote: > hi, > Where I can download the toolchain to compile the laster davinci linux > kernel? CodeSourcery has prebuilt ARM toolchains that you can use: http://www.codesourcery.com/sgpp/datasheet?target_arch=ARM&target_os=GNU%2FLinux Best regards, Bjørn Forsman ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM365 DavinciFB Colour Keying Transparency
Gilles Chanteperdrix a écrit : Kieran Bingham wrote: Hi Guys, Does anyone know the correct methods to set up the OSD0 to be transparent based on a BLACK colour key ? We are trying to move to the Arago 2.6.32 kernel, and the methods we used on the 2.6.18 kernel no longer work - and everything I've tried hasn't worked either. So rather than continue guessing in the dark - I thought I'd ask you guys :) See: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-May/019022.html You also need to disable OSD1. If OSD1 is enabled, it is used to set transparency. You can try above patch, and use the following kernel command line parameter : video=davincifb:vid0=off:vid1=off:osd1=0x0x8 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
