What we do realistically see in the RX-51 - Page 4 - maemo.org

Active Topics

Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 3 days, 6 hrs ago
Handbook (2)
to Maemo 7 / Leste by teroyk - 4 days, 6 hrs ago
more...

Page 4 of 47

Thread Tools

	daperl	2008-12-09 , 21:40
	Posts: 2,427 \| Thanked: 2,986 times \| Joined on Dec 2007	#31

Inside the kernel patches I saw the following:

Code:

+++ kernel-2.6.27/drivers/net/irda/Kconfig
@@ -342,5 +342,15 @@
          To compile it as a module, choose M here: the module will be called
          mcs7780.

+config OMAP_IR
+       tristate "OMAP IrDA(SIR/MIR/FIR)"
+       depends on IRDA && ARCH_OMAP
+       select GPIOEXPANDER_OMAP if (MACH_OMAP_H3 || MACH_OMAP_H4)
+        help
+         Say Y here if you want to build support for the Texas Instruments
+         OMAP IrDA device driver, which supports SIR/MIR/FIR. This driver
+         relies on platform specific helper routines so available capabilities
+         may vary from one OMAP target to another.
+
 endmenu

--- kernel-2.6.27.orig/drivers/net/irda/omap-ir.c
+++ kernel-2.6.27/drivers/net/irda/omap-ir.c
@@ -0,0 +1,901 @@
+/*
+ * BRIEF MODULE DESCRIPTION
+ *
+ *     Infra-red driver for the OMAP1610-H2 and OMAP1710-H3 and H4 Platforms
+ *       (SIR/MIR/FIR modes)
+ *       (based on omap-sir.c)
+ *
+ * Copyright 2003 MontaVista Software Inc.
+ * Author: MontaVista Software, Inc.
+ *        source@mvista.com
+ *
+ * Copyright 2004 Texas Instruments.
+ *

...

+#define IS_FIR(omap_ir)                ((omap_ir)->speed >= 4000000)
+
+struct omap_irda {
+       unsigned char open;
+       int speed;              /* Current IrDA speed */
+       int newspeed;
+
+       struct net_device_stats stats;
+       struct irlap_cb *irlap;
+       struct qos_info qos;
+
+       int rx_dma_channel;
+       int tx_dma_channel;
+
+       dma_addr_t rx_buf_dma_phys;     /* Physical address of RX DMA buffer */
+       dma_addr_t tx_buf_dma_phys;     /* Physical address of TX DMA buffer */
+
+       void *rx_buf_dma_virt;          /* Virtual address of RX DMA buffer */
+       void *tx_buf_dma_virt;          /* Virtual address of TX DMA buffer */
+
+       struct device *dev;
+       struct omap_irda_config *pdata;
+};
+
+static void inline uart_reg_out(int idx, u8 val)
+{
+       omap_writeb(val, idx);
+}
+
+static u8 inline uart_reg_in(int idx)
+{
+       u8 b = omap_readb(idx);
+       return b;
+}
+
+/* forward declarations */
+extern void omap_stop_dma(int lch);
+static int omap_irda_set_speed(struct net_device *dev, int speed);

...

+
+static char __initdata banner[] = KERN_INFO "OMAP IrDA driver initializing\n";
+
+static int __init omap_irda_init(void)
+{
+       printk(banner);
+       return platform_driver_register(&omapir_driver);
+}
+
+static void __exit omap_irda_exit(void)
+{
+       platform_driver_unregister(&omapir_driver);
+}
+
+module_init(omap_irda_init);
+module_exit(omap_irda_exit);
+
+MODULE_AUTHOR("MontaVista");
+MODULE_DESCRIPTION("OMAP IrDA Driver");
+MODULE_LICENSE("GPL");
+
--- kernel-2.6.27.orig/drivers/net/irda/Makefile
+++ kernel-2.6.27/drivers/net/irda/Makefile
@@ -18,6 +18,7 @@
 obj-$(CONFIG_VIA_FIR)          += via-ircc.o
 obj-$(CONFIG_PXA_FICP)         += pxaficp_ir.o
 obj-$(CONFIG_MCS_FIR)          += mcs7780.o
+obj-$(CONFIG_OMAP_IR)          += omap-ir.o
 obj-$(CONFIG_AU1000_FIR)       += au1k_ir.o
 # SIR drivers
 obj-$(CONFIG_IRTTY_SIR)                += irtty-sir.o  sir-dev.o

Might there be an IR port? Or was that already mentioned?

__________________
N9: Go white or go home

Quote & Reply |

fanoush	2008-12-09 , 22:08
Posts: 2,152 \| Thanked: 1,490 times \| Joined on Jan 2006 @ Czech Republic	#32

Originally Posted by daperl

Might there be an IR port?

Not necessarily, both the patch and the changelog has many 'false positives' because they started at 2.6.25 and then merged generic 2.6.26, 2.6.27 patches with tons of other unrelated noise. Safer bet is examining rx-51 board files where specific hardware is listed and initialized, see rx-51 specific kernel config files and search for @nokia.com in source files.

__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Quote & Reply |

The Following User Says Thank You to fanoush For This Useful Post:
daperl

	kotzkind	2008-12-09 , 22:33
	Posts: 117 \| Thanked: 22 times \| Joined on Apr 2007	#33

Originally Posted by Mara

If so then RX-51 should work with either 128MB or 256MB or RAM without any change in motherboard, just a change in RAM chip. (Maybe this happened with the Pandora case too, when the 256MB chips became available they just announced the memory upgrade...)

This could get a problem:

Omaps are SoC. That means, that most part what in normal computers are on other cards or chips than the CPU, but in omap chips there is everything on the omap chip. Also the RAM. When first asked, the developers of the Pandora stated, that more than 128MB Ram is not possible, because there is no Omap 3 with more than 128MB. Now it seems they use an external RAM chip. And here comes the problem: In the n810 they only provided one minisd because of the gps chip and antenna. In the NITs free space is rare.

However: Pandora is only a small project. Nokia is a big company and a big customer of TI. So if Nokia wants an Omap3 with more RAM, it may get one...

Edit: I revoke that. Seems like there are no external RAM chips needed for 256MB:
http://gumstix.com/store/catalog/pro...roducts_id=211

Last edited by kotzkind; 2008-12-09 at 22:50.

Quote & Reply |

	allnameswereout	2008-12-09 , 22:45
	Posts: 3,397 \| Thanked: 1,212 times \| Joined on Jul 2008 @ Netherlands	#34

Originally Posted by Stskeeps

Do I need to point out that there's hints there's on, internal MMC, a 768mb swap partition, 2gb linux partition and rest fat32.. Where do you think that might lead?

Well, given swap is usually 2x the RAM this might indicate 384 MB RAM.

__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!

Quote & Reply |

	tso	2008-12-09 , 22:49
	Posts: 4,783 \| Thanked: 1,253 times \| Joined on Aug 2007 @ norway	#35

iirc, the pandora got the ram in there via chip on chip solution.

basically they put the ram and nand chip on top of the cpu.

Quote & Reply |

The Following User Says Thank You to tso For This Useful Post:
GeneralAntilles

	GeneralAntilles	2008-12-09 , 23:09
	Posts: 5,478 \| Thanked: 5,222 times \| Joined on Jan 2006 @ St. Petersburg, FL	#36

Originally Posted by kotzkind

Omaps are SoC. That means, that most part what in normal computers are on other cards or chips than the CPU, but in omap chips there is everything on the omap chip. Also the RAM. When first asked, the developers of the Pandora stated, that more than 128MB Ram is not possible, because there is no Omap 3 with more than 128MB. Now it seems they use an external RAM chip. And here comes the problem: In the n810 they only provided one minisd because of the gps chip and antenna. In the NITs free space is rare.

RAM and NAND aren't integrated with the SoC. At least with the Pandora and the Beagle Board, they're in what's called a PoP (Package-on-Package), which is a chip that rests on top of the OMAP3 and sandwiches it between itself and the board. The problem is that 6 months ago, there weren't any 256MB RAM PoPs available, now a few months ago 256MB RAM PoPs showed up, so the Beagle and Pandora are going to ship them (though the Beagle's will be slightly faster and contain no NAND).

Yes, it'd be perfectly reasonable for Nokia to swap out this chip with no impact on size.

Originally Posted by allnameswereout

Well, given swap is usually 2x the RAM this might indicate 384 MB RAM.

Where I come from, swap is usually 1.5x the RAM, which would lead to 512MB. Either way, there's no way they'd ship 384MB of RAM.

The other proposal is that it's enough to support a suspend to disk.

__________________
Ryan Abel

Quote & Reply |

The Following User Says Thank You to GeneralAntilles For This Useful Post:
Texrat

	daperl	2008-12-10 , 00:26
	Posts: 2,427 \| Thanked: 2,986 times \| Joined on Dec 2007	#37

Originally Posted by fanoush

Not necessarily, both the patch and the changelog has many 'false positives' because they started at 2.6.25 and then merged generic 2.6.26, 2.6.27 patches with tons of other unrelated noise. Safer bet is examining rx-51 board files where specific hardware is listed and initialized, see rx-51 specific kernel config files and search for @nokia.com in source files.

Ah, you're right. I ignored the configuration. It looks very unlikely that there will be IR anything. A sunset technology that should probably just ride off. Maybe go down to Florida and spend some time with his sister "the fax." Thanks.

__________________
N9: Go white or go home

Quote & Reply |

The Following User Says Thank You to daperl For This Useful Post:
Texrat

	Texrat	2008-12-10 , 00:32
	Posts: 11,700 \| Thanked: 10,045 times \| Joined on Jun 2006 @ North Texas, USA	#38

Originally Posted by sachin007

Anyway seeing the specs as it is.... i think many people will be disappointed.

I doubt it. Who expects 5 mpix on a Nokia internet tablet? Where is the precedent? I don't see the first implementation of a forward camera for internet tablets as disappointing with a "mere" 5 mpix. But maybe we need a poll...?

Anyway, I think you're worrying for nothing sachin. I think the specs look great, and personally, I would not sweat published memory details at this point.

__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net

Quote & Reply |

	GeneralAntilles	2008-12-10 , 00:47
	Posts: 5,478 \| Thanked: 5,222 times \| Joined on Jan 2006 @ St. Petersburg, FL	#39

Originally Posted by Texrat

I doubt it. Who expects 5 mpix on a Nokia internet tablet? Where is the precedent? I don't see the first implementation of a forward camera for internet tablets as disappointing with a "mere" 5 mpix. But maybe we need a poll...?

TA-t3 and qole both have it exactly right. Anyone who knows, knows that megapixels are ********. Especially with these shitty little cellphone sensors. More megapixels means neither higher quality nor a better sensor it means exactly this: more noise.

What you want to pay attention to is the quality of the optics, and the noise level of the sensor. So look at a sample picture before you make any snap decisions based on a meaningless metric.

__________________
Ryan Abel