OMAP2: add USB platform data and initialization for Nokia N800 and N810

Add platform data and initialization for USB on Nokia N800 and N810 devices via the TUSB6010 chipset.

Tested on Nokia N810 in Linux-OMAP tree. Mainline is not bootable yet.

---
 arch/arm/mach-omap2/Kconfig          |    5 +
 arch/arm/mach-omap2/Makefile         |    1 +
 arch/arm/mach-omap2/board-n8x0-usb.c |  173 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/board-n8x0.c     |    8 ++
 4 files changed, 187 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-n8x0-usb.c

index 10eafa7..e3c913c 100644
@@ -117,6 +117,11 @@ config MACH_NOKIA_N8X0
 	select MACH_NOKIA_N810
 	select MACH_NOKIA_N810_WIMAX
 
+config MACH_NOKIA_N8X0_USB
+	bool
+	depends on MACH_NOKIA_N8X0 && MACH_OMAP2_TUSB6010
+	default y
+
 config MACH_NOKIA_RX51
 	bool "Nokia RX-51 board"
 	depends on ARCH_OMAP3 && ARCH_OMAP34XX

index b32678b..e890b2b 100644
@@ -86,6 +86,7 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)	+= board-omap3pandora.o \
 obj-$(CONFIG_MACH_OMAP_3430SDP)		+= board-3430sdp.o \
 					   mmc-twl4030.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)		+= board-n8x0.o
+obj-$(CONFIG_MACH_NOKIA_N8X0_USB)	+= board-n8x0-usb.o
 obj-$(CONFIG_MACH_NOKIA_RX51)		+= board-rx51.o \
 					   board-rx51-sdram.o \
 					   board-rx51-peripherals.o \

index 764ab1e..c9395e1 100644
@@ -109,8 +109,16 @@ static void __init n8x0_init_irq(void)
 	omap_gpio_init();
 }
 
+#ifdef CONFIG_MACH_NOKIA_N8X0_LCD
+extern void n8x0_usb_init(void);
+#else
+static inline void n8x0_usb_init (void) {}
+#endif
+
 static void __init n8x0_init_machine(void)
 {
+	n8x0_usb_init();
+
 	/* FIXME: add n810 spi devices */
 	spi_register_board_info(n800_spi_board_info,
 				ARRAY_SIZE(n800_spi_board_info));

1.6.4.4

Excellent, thank you for doing this.

What's the problem in mainline? I haven't tested n8x0 for months :(

Kalle Valo

Lack of platform support, as far as I know.
Until we have cbus, there's no way to get the LCD powered...

Seemed simpler to manage in a separate file, though not as necessary as the LCD stuff (which I also have a patch against mainline for, but it needs tahvo...)

Heh, looks like my isolate-and-merge-to-mainline got messed up there. Of course it should be CONFIG_MACH_NOKIA_N8X0_USB :)

Also, scripts/checkpatch.pl gave me a warning about the extern in a .c file, but I couldn't figure out where else it could reasonably go. Any ideas? :/

Luke

Oh that. I have only used serial console with mainline. Luckily Felipe did some cbus patches, I haven't checked them yet though.

Having lots of small files is difficult IMHO.

Nice.

Yeah, maybe eating too much ham caused it ;)

Yes, just put everything into one file :) No need for externs then.

Kalle Valo

Hi,

nothing for mainline yet though, cbus needs lots of work.

anyone with free time, please help :-p

balbi

The last-working N8x0 support (Linux-OMAP 2.6.30-rc8) required 1706 lines of platform data and initialization, split up into 6 files:

	590	N800 + i2c + FM + keyboard + light sensor + LED + LCD + temp + SPI + WiFi
		 + touchscreen + OneNAND
	47	N810
	175	USB
	362	MMC
	156	DSP
	376	camera

The largest OMAP2 single-board file is merely 689 lines (3430sdp). N900/RX-51, totalling 863 lines itself, is split over 2 files.

I think 4 or 5 files with ~350 lines is more manageable than a single 1700- line board file, especially when considering that parts depend on multiple configuration options (LCD, which turns out to be a 128-line file, depends on 3 config options: N8x0, Blizzard, and MIPID).

Thoughts?

Luke

Upon trying to debug my non-working keyboard, I learned that the status of mainlining is actually worse off than I thought, and my "last 2.6.30-rc8 working" revision was actually already missing platform data.

It seems logical from looking at the code needed to divide the board into at least 5 files (line number estimates based on old code):

	460	board-n8x0-common.c
	175	board-n800.c			(FM radio, touchscreen)
	260	board-n810.c			(keyboard, light sensor, LEDs, touchscreen)
	600	board-n8x0-multimedia.c	(camera, audio, DSP)
	725	board-n8x0-storage.c	(flash, MMC)
	120	board-n8x0-lcd.c

On that topic, is there a reason the newer code is under a unified "N8x0" config option instead of the split N800/N810 that was used for the old code, or is that simply a symptom of the currently-supported features all being common?

Luke

IIRC, I just used one common n8x0 file because the n810 board file was very small and I didn't see any benefit from having it separately.

Kalle Valo

Yeah, that's because someone put all the N810 code in the N800 file ;)

Will probably at least split out the differences, if there's no other reason, then. Since I'm doing this stuff only for my own personal interest, I'll probably not bother to do much with N800 support unless someone feels like sending me one when I finish N810 (definitely not touching N800 before then).

Luke

Hi,

I think it's not worth the effort. Those boards share a lot of code. You'll end up with several small board files

balbi

(dropping lkml)

I tend to disagree. Scattering code to small files doesn't benefit that much, just makes it harder to find code. IMHO a 2k line file is perfectly acceptable and usable.

But if you really want smaller files, I'm not going to object. You're the one doing the all work here :)

Kalle Valo

Hi,

<snip>

<snip>

From: Tony Lindgren <[email protected]>
Date: Tue, 29 Dec 2009 11:04:58 -0800
Subject: [PATCH] tusb6010: Use clkdev to initialize the clock

Note that in this case the clock is fck, not ick
like for musb.

index 2254ebd..e67eabf 100644
@@ -25,7 +25,6 @@
 #define GPIO_TUSB_ENABLE	0
 
 static int tusb_set_power(int state);
-static int tusb_set_clock(struct clk *osc_ck, int state);
 
 #if	defined(CONFIG_USB_MUSB_OTG)
 #	define BOARD_MODE	MUSB_OTG

@@ -82,10 +81,8 @@ static struct musb_hdrc_config musb_config = {
 static struct musb_hdrc_platform_data tusb_data = {
 	.mode		= BOARD_MODE,
 	.set_power	= tusb_set_power,
-	.set_clock	= tusb_set_clock,
 	.min_power	= 25,	/* x2 = 50 mA drawn from VBUS as peripheral */
 	.power		= 100,	/* Max 100 mA VBUS for host mode */
-	.clock		= "osc_ck",
 	.config		= &musb_config,
 };
 

@@ -121,27 +118,6 @@ static int tusb_set_power(int state)
 	return retval;
 }
 
-static int		osc_ck_on;
-
-static int tusb_set_clock(struct clk *osc_ck, int state)
-{
-	if (state) {
-		if (osc_ck_on > 0)
-			return -ENODEV;
-
-		clk_enable(osc_ck);
-		osc_ck_on = 1;
-	} else {
-		if (osc_ck_on == 0)
-			return -ENODEV;
-
-		clk_disable(osc_ck);
-		osc_ck_on = 0;
-	}
-
-	return 0;
-}
-
 void __init n8x0_usb_init(void)
 {
 	int ret = 0;

@@ -156,6 +132,12 @@ void __init n8x0_usb_init(void)
 	}
 	gpio_direction_output(GPIO_TUSB_ENABLE, 0);
 
+	/*
+	 * REVISIT: This line can be removed once all the platforms using
+	 * musb_core.c have been converted to use use clkdev.
+	 */
+	tusb_data.clock = "fck";
+
 	tusb_set_power(0);
 
 	ret = tusb6010_setup_interface(&tusb_data, TUSB6010_REFCLK_19, 2,

index 97dc7cf..e9c8f09 100644
@@ -2222,6 +2222,7 @@ static struct omap_clk omap24xx_clks[] = {
 	CLK(NULL,	"aes_ick",	&aes_ick,	CK_243X | CK_242X),
 	CLK(NULL,	"pka_ick",	&pka_ick,	CK_243X | CK_242X),
 	CLK(NULL,	"usb_fck",	&usb_fck,	CK_243X | CK_242X),
+	CLK("musb_hdrc",	"fck",	&osc_ck,	CK_242X),
 	CLK("musb_hdrc",	"ick",	&usbhs_ick,	CK_243X),
 	CLK("mmci-omap-hs.0", "ick",	&mmchs1_ick,	CK_243X),
 	CLK("mmci-omap-hs.0", "fck",	&mmchs1_fck,	CK_243X),

Hi,

Yes, let's do like Tony suggested. I'm removing the old set_clock stuff completely, patches are available at my git tree, here are the links:

http://gitorious.org/usb/usb/commit/ca415cf06a4843e93041fe73f7f1867e066b48a3
http://gitorious.org/usb/usb/commit/013f8457a1ba0dd3f36811f647b0fe904128292e
http://gitorious.org/usb/usb/commit/e2ecae4c5b01415dbbf714c7217178c31a9a5dd1
http://gitorious.org/usb/usb/commit/874afb373ea75ff0a3a360802a53357affa27df0
http://gitorious.org/usb/usb/commit/6d47fc9858c17faea8a454e147839c878737a0f1
http://gitorious.org/usb/usb/commit/62b8d94df7739cb60bae0369b8265e588f518841
http://gitorious.org/usb/usb/commit/e06629acd44936fe87d34d188c8dfb54abd7915c

Tony, if you want I can send you a pull request will all the patches I have prepared on top of your tree. There's only one dependence which I can ship in the same pull request.

Sames goes to Kevin regarding davinci tree. I just have to subscribe in order to be able to send the patches there.

balbi

That would be great!

FYI, I think Kevin is on vacation right now.

Regards,

Tony

Hi,

Ok good. So I'll mark all my pending patches as Superseeded or something better on patchwork then by tomorrow I'll resend all of them, plus the pull request.

good to know. The patch going to Greg right now only marks the fields as __deprecated so it shouldn't be a big problem to wait a bit.

balbi

Sounds good. Please keep two separate queues: Fixes for the -rc cycle, and new code for next merge window.

OK

Tony

Hi,

will do.

balbi

Quick followup... I haven't had the chance to make those clock changes or move it into the main board file yet, but just discovered my recent boot problems were "fixed" by disabling USB support, so apparently there's something else broken with my patch. :(

Unfortunately, without a trackback, I'm totally lost:

Unable to handle kernel NULL pointer dereference at virtual address 00000031
pgd = c0004000
[00000031] *pgd=000000000
Internal error: Oops: 17 [#1] PREEMPT

can you post the entire trace ?

I need the function call trace that BUG() prints

balbi

Hi Luke,

I'm with some problems to boot-up latest l-o(commit abb74381235a05f15a3b07e9e3831034942c67fb) with n810. The error message can be found below and full boot output in the end of email.

dsme: No correct bootreason found, entering the malfunction state

I'm not sure if it's related with kernel or rootfs. I tried different distros(Maemo,Angstrom,Mamona and Mer) and I got the same problem using this kernel.

What rootfs do you use? Did you change initfs?

Any idea/help?

Thanks in advance,
Alecrim.

PS: 2.6.30-rc8 is the last kernel version that I got working
(http://www.natisbad.org/N810/index.html)

Uncompressing Linux.............................................................................. done, booting the kernel.

[    0.000000] Linux version 2.6.33-rc2-06901-gabb7438 (alecrim@alecrim)
(gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #53 Tue Jan 5
18:35:16 AMT 2010
[    0.000000] CPU: ARMv6-compatible processor [4107b362] revision 2
(ARMv6TEJ), cr=00c5387f
[    0.000000] CPU: VIPT aliasing data cache, VIPT aliasing instruction
cache
[    0.000000] Machine: Nokia N810
[    0.000000] Ignoring unrecognised tag 0x414f4d50
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] OMAP2420
[    0.000000]
[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 32512
[    0.000000] Kernel command line: root=1f03 rootfstype=jffs2
console=ttyS2,115200
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 64MB 64MB = 128MB total
[    0.000000] Memory: 127316KB available (2088K code, 184K data, 96K
init, 0K highmem)
[    0.000000] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0,
CPUs=1, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:368
[    0.000000] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz
[    0.000000] GPMC revision 2.0
[    0.000000] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96
interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] OMAP GPIO hardware version 1.8
[    0.000000] OMAP clockevent source: GPTIMER1 at 32000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Calibrating delay loop... 320.37 BogoMIPS (lpj=1253376)
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] NET: Registered protocol family 16
[  307.198364] OMAP DMA hardware revision 2.0
[  307.216583] bio: create slab <bio-0> at 0
[  307.221252] usbcore: registered new interface driver usbfs
[  307.222290] usbcore: registered new interface driver hub
[  307.222869] usbcore: registered new device driver usb
[  307.225250] Switching to clocksource 32k_counter
[  307.229980] musb_hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0
[  307.230895] NET: Registered protocol family 2
[  307.231140] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[  307.231597] TCP established hash table entries: 4096 (order: 3, 32768
bytes)
[  307.231872] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[  307.232116] TCP: Hash tables configured (established 4096 bind 4096)
[  307.232147] TCP reno registered
[  307.232177] UDP hash table entries: 256 (order: 0, 4096 bytes)
[  307.232238] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[  307.232513] NET: Registered protocol family 1
[  307.234924] NetWinder Floating Point Emulator V0.97 (double precision)
[  307.267059] JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat,
Inc.
[  307.269897] msgmni has been set to 248
[  307.270019] io scheduler noop registered
[  307.271697] io scheduler cfq registered (default)
[  307.310852] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[  307.334625] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a
ST16654
[  307.355895] serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a
ST16654
[  307.376953] serial8250.2: ttyS2 at MMIO 0x4806e000 (irq = 74) is a
ST16654
[  307.685607] console [ttyS2] enabled
[  307.712738] brd: module loaded
[  307.716278] OneNAND driver initializing
[  307.720794] omap2-onenand omap2-onenand: initializing on CS0, phys
base 0x04000000, virtual base c8880000
[  307.730560] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[  307.735382] OneNAND version = 0x0022
[  307.740570] Scanning device for bad blocks
[  307.754882] onenand_bbt_wait: ecc error = 0x2222, controller error 0x2440
[  307.761840] Bad eraseblock 183 at 0x016e0000
[  307.836791] onenand_bbt_wait: ecc error = 0x2222, controller error 0x2440
[  307.843658] Bad eraseblock 1461 at 0x0b6a0000
[  307.880462] Creating 5 MTD partitions on "omap2-onenand":
[  307.885925] 0x000000000000-0x000000020000 : "bootloader"
[  307.891998] 0x000000020000-0x000000080000 : "config"
[  307.897674] 0x000000080000-0x000000280000 : "kernel"
[  307.903442] 0x000000280000-0x000000680000 : "initfs"
[  307.909149] 0x000000680000-0x000010000000 : "rootfs"
[  307.917602] mice: PS/2 mouse device common for all mice
[  307.923004] TCP cubic registered
[  307.927215] VFP support v0.3: implementor 41 architecture 1 part 20
variant b rev 2
[  308.001525] VFS: Mounted root (jffs2 filesystem) on device 31:3.
[  308.007781] Freeing init memory: 96K

BusyBox v1.00 (2008.10.21-06:19+0000) multi-call binary

Usage: mknod [OPTIONS] NAME TYPE MAJOR MINOR

Create a special file (block, character, or pipe).

Options:
-m create the special file using the specified mode
(default a=rw)

TYPEs include:
b: Make a block (buffered) device.
c or u: Make a character (un-buffered) device.
p: Make a named pipe. MAJOR and MINOR are ignored for named
pipes.

BusyBox v1.00 (2008.10.21-06:19+0000) multi-call binary

Usage: mknod [OPTIONS] NAME TYPE MAJOR MINOR

Create a special file (block, character, or pipe).

Options:
-m create the special file using the specified mode
(default a=rw)

TYPEs include:
b: Make a block (buffered) device.
c or u: Make a character (un-buffered) device.
p: Make a named pipe. MAJOR and MINOR are ignored for named
pipes.

Enabling core dumps to /media/mmc1/core-dumps/...done.
Starting DSME... done.
dsme: reading bootreason from /proc/bootreason
dsme: No correct bootreason found, entering the malfunction state
dsme: bootreason read **
dsme: bootreason was other than mbus, let's wait for the battery type Wait for DSME socket to appear
grep: /proc/component_version: No such file or directory
fopen: Bad file descriptor
cal_read_block(r&d_mode): size zero, block not found?
Kicker: error reading R&D mode flags, both watchdogs enabledreceived state:8
Kicker: Error initialising OMAP watchdogKicker: failed to init WDs, exiting...DSME: process '/usr/sbin/kicker' with pid 330 exited with return value: 1
DSME: process '/usr/sbin/kicker' exited
and restarted with pid 340
cal_read_block(r&d_mode): size zero, block not found?
Kicker: error reading R&D mode flags, both watchdogs enabledKicker:
Error initialising OMAP watchdogKicker: failed to init WDs, exiting...DSME: process '/usr/sbin/kicker' with pid 340 exited with return value: 1
DSME: process '/usr/sbin/kicker' exited
and restarted with pid 352
Entering state 'MALF'.
cal_read_block(r&d_mode): size zero, block not found?
Kicker: error reading R&D mode flags, both watchdogs enabledHouston, we have a problem, powering off...
Kicker: Error initialising OMAP watchdogKicker: failed to init WDs, exiting...DSME: process '/usr/sbin/kicker' with pid 352 exited with return value: 1
DSME: process '/usr/sbin/kicker' exited
and restarted with pid 364

The system is going down NOW !!
Sending SIGTERM to all processes.
Sending SIGKILL to all processes.

[  311.089965] System halted.
grep: /proc/component_version: No such file or directory
Loading WLAN module...
[  311.293212] umac: version magic '2.6.21-omap1 mod_unload ARMv6 '
should be '2.6.33-rc2-06901-gabb7438 mod_unload ARMv6 '
insmod: cannot insert `/lib/modules/current/umac.ko': Invalid module
format (-1): Exec format error
[  311.337249] cx3110x: version magic '2.6.21-omap1 mod_unload ARMv6 '

should be '2.6.33-rc2-06901-gabb7438 mod_unload ARMv6 '
insmod: cannot insert `/lib/modules/current/cx3110x.ko': Invalid module format (-1): Exec format error
Pushing the WLAN tuned values
cal_init: dsmesock_connect failedPushing default country...cal_init failed [FAILED]
cal_init: dsmesock_connect failedPushing MAC address...cal_init failed bad CAL (0,28), Using default Nokia MAC Couldn't open /sys/devices/platform/wlan-omap/cal_mac_address
[FAILED]
cal_init: dsmesock_connect failedPushing IQ tuned values...cal_init failed Got 0 bytes while expecting 108
[FAILED]
cal_init: dsmesock_connect failedPushing TX tuned values...cal_init failed (default values)Couldn't open /sys/devices/platform/wlan-omap/cal_pa_curve_data
[FAILED]
Pushing TX limits...Couldn't open /sys/devices/platform/wlan-omap/cal_output_limits
[FAILED]
Pushing RX tuned values...Using default values Couldn't open /sys/devices/platform/wlan-omap/cal_rssi
[FAILED]

real    0m 0.64s
user    0m 0.00s
sys     0m 0.63s

dsmesock_connect: Connection refused
dsmesock_connect
Entering state 'MALF'.
Houston, we have a problem, powering off...
--
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.html

That's DSME, part of Maemo userland. You can possibly write a LD_PRELOAD workaround if you want to run it anyway...

Gentoo. I modified my initfs to chainload its init if a new kernel is running.

Unfortunately, I have come to the realisation that moving forward with the Linux port to N8x0 would take me more time than simply spending the same time doing paid work and buying a N900* or Pandora instead. So short some other reimbursement for porting Linux to N8x0 (like maybe a promise of BME sources or a N900 after the rest is done to finish the job), I'm probably not going to spend any more time on it. :(

Luke

* N900 is supposedly mostly mainlined already, and supposedly Nokia will actually finish the job with unlike N8x0; it also has nicer hardware, even if you just ignore the cellular capabilities

Hi Luke,

I tried but it doesn't work. I included a line to print the /proc/bootreason value and there is no bootreason. :P

cat: /proc/bootreason: No such file or directory

I guess that's the problem.

I don't know how to do it. Could you send me yours?

Maybe, you're right. Or they can produce something using a SoC cheaper than OMAP3.

Thank you! :)
Alecrim

Yeah, that "file" isn't supposed to exist. It was a Nokia-specific hack.

special=false
if echo -n >/writetest; then

        exec >/$(uname -r).log
        exec 2>&1
        /dmesg.static
        ls -lh /dev

# ifconfig usb0 192.168.1.2
# mount -t proc proc proc
# ifconfig -a
# umount proc
# sync

if true; then

echo A
mount -t proc proc proc
mount /dev/mmcblk0p1 /mnt/new_root || exec /bin/sh echo B
cd /mnt/new_root
mkdir -p mnt/initfs
echo C
pivot_root . mnt/initfs
echo D
cd /
mount
sync
echo E
exec /usr/bin/chroot / /sbin/init

fi

special=true
fi

Thanks! Now it goes to rootfs and continue the boot, but device power-off after 10-20 seconds. There is no error message to help. :(

I did some small changes:

mount -t jffs2 /dev/mtdblock4 /mnt/new_root || exec /bin/sh

exec /usr/sbin/chroot / /sbin/init

Thanks,
Alecrim

Hi,

watchdog ?

how about disabling watchdog with flasher ??

balbi

Hi/Olá Balbi, :)

I'm using the flags (no-omap-wd,no-retu-wd,no-lifeguard-reset) recommended by Kalle[1]. This's not the problem. :(

Thanks anyway,
Alecrim

[1] - http://gitorious.org/stlc45xx/mainline/blobs/HEAD/README

--
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.html

AFAIK, no-retu-wd disables *pinging* the retu WD (which itself cannot be disabled). I'd try removing that one.

Also, note my rootfs is Gentoo, not Maemo. Maemo will depend on DSME which is not being started with my modded linuxrc.

Hi Luke,

I tried with/without no-retu-wd, no-omap-wd .

I'm using Mamona. Anyway,I did some tests before rootfs execution and I got the same problem. My current init contain only "exec /bin/sh". Device just turn power-off without error message. :(

Thanks anyway,
Alecrim.

Well, give me a place to push my git tree and try that :)

If you have some custom changes to linux-omap kernel work correctly with N8x0+Gentoo, you can share it using http://gitorious.org/ . It's gonne be nice!

Hmm, for some reason I thought Gitorious had a storage limit... guess not! :) Pushing to http://gitorious.org/~Luke-Jr/n8x0
It's taking a while :/

Luke-Jr wrote at 2010-01-07 09:40 -0600:

I would like to run Debian on my N810; have you gotten PM, gps, and internal mmc to work while running Gentoo?

Don't expect GPS to ever work. The proprietary driver depends on a bug fixed in 2.6.23 or so, and even ignoring that, is full of bugs. It's a soft-GPS (like winmodems are for modems), so I suppose someone who understands GPS technical stuff might be able to rewrite it.

If you know anyone who has push with TI, the chipset is the TI GPS5300.

Luke-Jr wrote at 2010-01-08 20:56 -0600:

Okay, thanks for the information.

I don't but if I did...

If I read these recommendations correctly, they tell to *clear* these R&D flags. So probably it's better not to have them enabled.

Moreover, based on the following post, watchdog is hardwired and just can't be disabled by any software methods:
http://lists.maemo.org/pipermail/maemo-developers/2007-June/010650.html

Your powerdown problem is exactly caused by a watchdog. Earlier a solution was to have a script which would kick watchdog periodically. But right now it is kicked automatically in the kernel if CONFIG_CBUS_RETU_WDT option is enabled. You also need to enable CONFIG_WATCHDOG, CONFIG_CBUS and probably some other stuff.

This all also means that CBUS is critical for correct N8x0 operation and these devices simply can't work without it at all.

Hope this information helps.

Best regards,
Siarhei Siamashka

Thanks for this explanation. I works fine with the flags you indicate. :)

Well, if it's critical to n8x0 operation then it should be in n8x0_defconfig.

Thanks,
Alecrim.

Luke-Jr wrote at 2010-01-05 17:46 -0600:

You say "supposedly"; where do you get this information? Is there a mailing list or something...? I would like to find out what works before making a purchase. I made careless assumptions about Linux support when purchasing the N810.

IRC: #Maemo on FreeNode.

Probably best to do a through study of the code, then. While things are supposedly better with the N900, things were supposedly good with the N810 too, which was more or less advertised as being open source and running Linux even though neither will probably ever be true at this rate. Nokia has taught me not to trust such claims even when they have a large fan backing. :/

Luke

Luke-Jr wrote at 2010-01-09 11:43 -0600:

Okay; thanks.

The FOSS community wants to support Linux/etc. through their purchases, but it seems that Nokia has taken advantage of that. I will be more cautious in the future, especially regarding Nokia.

Nishanth Menon wrote at 2010-01-09 09:12 -0600:

I have been using the keyword 'mainline' in an attempt to filter out simple "it runs Linux" pages but that page makes no mention of 'mainline' Linux.

Thanks, I have read arno's N810 page on that site but had not yet found the N900 pages. They are very informative.