Reply
Thread Tools
Posts: 255 | Thanked: 61 times | Joined on Feb 2010
#11
Originally Posted by b-man View Post
Yup - that's what i'm doing right now
On n800 or n900

I would like to try getting this working on my n900 also
 
b-man's Avatar
Posts: 549 | Thanked: 502 times | Joined on Feb 2008 @ Bowling Green Ohio (united states)
#12
Originally Posted by ear0wax View Post
On n800 or n900

I would like to try getting this working on my n900 also
Both, although i don't have my N800 anymore due to an incident last summer and my N900 does boot into Ubuntu, but as soon as i get into a login prompt, it shuts down because of the watchdog issue.
__________________
I'm an advanced user and a bit of a modder.
----------------------------------------------
I am involved with Mer, Deblet, and NITdroid.
My ports/creations/hacks: GNOME (for Deblet), Cdeb2», Ubuntu, playable flash games in the "Get Started" app, DBS, ect...


enhanced fedora port has been canceled in favor of NITDebian (TBA)
 

The Following User Says Thank You to b-man For This Useful Post:
Posts: 79 | Thanked: 11 times | Joined on Oct 2009 @ Norway
#13
This would be nice to get working on the N900.
__________________
Is it not strange that we fear most that which never happens? That we destroy our initiative by the fear of defeat; when in reality, defeat is a moust useful tonic and should be accapted as sutch.
 
Posts: 255 | Thanked: 61 times | Joined on Feb 2010
#14
Originally Posted by b-man View Post
Btw, here is my highly modified /etc/init.d/n900_wd script that is supposed to launch the watchdog daemon; do any of you that are good at init scripts/runlevels see a fault in this?
idk. But maybe check it against the (N900 port of) Mer init file?
 
Siggen's Avatar
Posts: 204 | Thanked: 75 times | Joined on Jan 2010 @ Norway
#15
Originally Posted by b-man View Post
Btw, here is my highly modified /etc/init.d/n900_wd script that is supposed to launch the watchdog daemon; do any of you that are good at init scripts/runlevels see a fault in this?

Code:
#!/bin/sh
#/etc/init.d/n900_wd: start rx51 hw watchdog service.

### BEGIN INIT INFO
# Provides:          n900_wd
# Short-Description: Start rx51 hw watchdog service.
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# X-Start-Before:    $all
# Default-Start:     2 3 4 5
# Default-Stop:      
### END INIT INFO

[ -x /usr/sbin/wd_keepalive ] || exit 0

RETVAL=0
PROG=wd_keepalive
PIDFILE=/var/run/wd_keepalive.pid
LOCKFILE=/var/lock/subsys/n900_wd

return_failure(){
  echo -n "Starting ${0} failed"
}

return_sucsess(){
  echo -n "Starting ${0} sucseeded"
}

start(){
  echo -n "Starting ${PROG}..."
  /usr/sbin/${PROG} -c /etc/watchdog-omap.conf
  RETVAL=$?
  [ ${RETVAL} -ne 0 ] && (return_failure; echo; exit ${RETVAL})
  /usr/sbin/${PROG} -c /etc/watchdog-twl4030.conf
  RETVAL=$?
  [ ${RETVAL} -eq 0 ] && touch ${LOCKFILE}
  [ ${RETVAL} -eq 0 ] && return_sucsess
  [ ${RETVAL} -ne 0 ] && return_failure
  echo
  exit ${RETVAL}
}

stop(){
  rm -rf ${LOCKFILE} ${PIDFILE}
}

restart(){
  stop
  start
}

case ${1} in
start)
  start
;;
stop)
  stop
;;
restart)
  restart
;;
*)
  echo "Usage: ${0} {start|stop|restart}"
  exit 1
;;
esac
heres my runlevle setup:

Code:
update-rc.d n900_wd start 09 2 3 4 5 .
/etc/watchdog-twl4030.conf:

Code:
watchdog-device		= /dev/twl4030_wdt
interval		= 10
realtime		= yes
priority		= 1
/etc/watchdog-omap.conf:

Code:
watchdog-device		= /dev/watchdog
interval		= 10
realtime		= yes
priority		= 1
I'll be honest, I read the script and I'm just guessing its the script that reports that everything succeeds or fails when you start linux without a fancy picture above this info, and did not fully understand the syntax used, but some of it i understand. What might help is some questions I have that I'm wondering about.

*Is this is the same script that worked booting fedora, or is it modified? If not have you tried that script?
*How does MER tackle this?
*What is the outcome of running this current script thats faulty? and under what circumstances should that happend? (skip that last question if you can write a book on it)

Thanks for making progress on this field I'll ask around some friends that might or might not understand whats wrong
 

The Following User Says Thank You to Siggen For This Useful Post:
Posts: 4 | Thanked: 2 times | Joined on Oct 2009
#16
How goes the work with the watchdog? Can't you just disable the watchdog timer wih the flasher tool?

Anyway, i'm going to take a different tack on this and have a go at getting lucid to work in a chroot. Just need to figure out how to configure Xephyr like qole does with debian. Hopefully this will enable me to run OpenOffice a bit quicker without having to reboot.
 
b-man's Avatar
Posts: 549 | Thanked: 502 times | Joined on Feb 2008 @ Bowling Green Ohio (united states)
#17
Originally Posted by mickeyjaw View Post
How goes the work with the watchdog?
Things haven't been so hot - I spent most of last weekend trying two approaches to the watchdog issue; implementing Stskeep's n900-support package which uses DSME to ping the watchdogs, and I've tried Jebba's approach which uses the watchdog package to directly ping the watchdogs - both did not work

Originally Posted by mickeyjaw View Post
Can't you just disable the watchdog timer wih the flasher tool?
Yes and no; Yes, in that would prevent the hw watchdog from rebooting the device, and No because Ubuntu seems to also be shutting it's self down later on in the boot process due an unknown issue that i need to look into.

Also, in my opinion putting the device in R&D mode just to boot another OS seems like bad practice, is unnecessary, and can be quite unsafe - especially for an inexperienced user who just wants to try out another os. When playing with R&D mode your playing with _very_low_level_ components of the device, and messing up these sensitive components could turn your device into a permanent brick. (i permanently bricked my N800 while experimenting with these components - accidentally wiped both the x-loader and nolo (1st and 2nd bootloader) turning it into a paperweight) Some people have also occasionally reported strange bugs while booted with R&D mode. Enabling R&D mode on the device really isn't recommended unless absolutely necessary.

One of my goals with the projects that i do is to make things as non-invasive, safe, and as simple to setup as i can so everyone can try it out.
__________________
I'm an advanced user and a bit of a modder.
----------------------------------------------
I am involved with Mer, Deblet, and NITdroid.
My ports/creations/hacks: GNOME (for Deblet), Cdeb2», Ubuntu, playable flash games in the "Get Started" app, DBS, ect...


enhanced fedora port has been canceled in favor of NITDebian (TBA)
 

The Following User Says Thank You to b-man For This Useful Post:
Posts: 71 | Thanked: 19 times | Joined on Dec 2009
#18
Originally Posted by b-man View Post
i permanently bricked my N800 while experimenting with these components - accidentally wiped both the x-loader and nolo (1st and 2nd bootloader) turning it into a paperweight
Now my N810 is in same situation.
/dev/mtdblock0, /dev/mtdblock1, /dev/mtdblock2 and /dev/mtdblock3 all were overwritten.

I wonder if cold flashing can let it work again?

btw. I searched and found it seems no successful case of cold flashing.

my try always show "Suitable USB device not found, waiting."
lsusb cannot show anything about N810 connection on usb port.
 
Posts: 71 | Thanked: 19 times | Joined on Dec 2009
#19
according to info about BeagleBoard


Depending on user button OMAP3 on BeagleBoard uses different boot order. Normal order if user button isn't pressed at power up is boot from

NAND -> USB -> UART -> MMC

press user button at power up to switch boot order to

USB -> UART -> MMC -> NAND
ROM code set from which boot can start. if not disable boot from MMC, "bricked device" shouldn't be dead.
 
Posts: 255 | Thanked: 61 times | Joined on Feb 2010
#20
did this whole idea just die off?*
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 11:27.