Active Topics

 


Reply
Thread Tools
Posts: 473 | Thanked: 141 times | Joined on Jan 2009 @ Virginia, USA
#21
Originally Posted by Copernicus View Post
The procedure looks correct to me, although the Updating the Firmware page notes that you should power down the N900 between flashing the EMMC and rootfs (by temporarily removing the battery).
I will try this and report back.

I hate to mention it, but this could just be a simple hardware failure. The cost of overclocking is reduced lifespan; the faster you run a chip, the shorter it lasts.
It's possible ("speed kills, Peaches"), but isn't it usually heat that kills it? And the processor doesn't seem to have the issue, it's the filesystem. I was able to log in to it before I flashed, and it was behaving normally. And even at 900MHz, I ran it at lower voltage, so it didn't burn through the battery, nor did it run hot.
 

The Following User Says Thank You to VulcanRidr For This Useful Post:
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#22
Originally Posted by VulcanRidr View Post
It's possible ("speed kills, Peaches"), but isn't it usually heat that kills it?
Basically (if I remember correctly), pretty much any conductor that isn't a superconductor will fail to transmit some percentage of the electricity that flows through it; this is known as "resistance". The electrons that do not pass through the substance instead "bump into" the material; this causes the atoms of the material to move or vibrate. And, of course, it is the vibration of atoms that we call "heat".

Eventually, this vibration will cause the material to deform or even evaporate. And, because the flow of electrons always causes resistance, your electronics are in fact always deforming / evaporating right before your very eyes, so long as they are on.

Certainly, if a chip is hot to the touch, you can be assured that it is dying more quickly than if it were cool to the touch. But you don't need to heat the entire chip to cause the problem; even running current through a single trace on the chip at 150% of its rated value is going to cause that part of the chip to die at a faster rate than normal.

In any case, I think Aristotle put it best: "All Macines are Mortal". Be nice to your N900, there are only so many left in the world...
 

The Following 6 Users Say Thank You to Copernicus For This Useful Post:
Posts: 473 | Thanked: 141 times | Joined on Jan 2009 @ Virginia, USA
#23
Originally Posted by Copernicus View Post
The procedure looks correct to me, although the Updating the Firmware page notes that you should power down the N900 between flashing the EMMC and rootfs (by temporarily removing the battery).
I wish I could thank you twice, Copernicus. This time the flash took. Apparently my device's filesystem was more b0rken than I thought.

First thing I'm installing is backupmenu, then I will dig through this thread and see what I need to do. Thanks to everyone who contributed.

I'm back in business.
 

The Following 5 Users Say Thank You to VulcanRidr For This Useful Post:
Posts: 242 | Thanked: 169 times | Joined on Nov 2011
#24
Is there some way to replace auto-disconnect functionality?
 

The Following User Says Thank You to enne30 For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#25
Originally Posted by Wikiwide View Post
And yet, I am cursing wifi-switcher and quick-launch for storing their .a and .la in the same directory with .so, when the built package should contain only .so - .a and .la are transitional files used by gcc when generating .so from .c and .h.
Disclaimer: I haven't used gcc, or packaged anything, for a long time. When I package something, I use no makefiles of any kind, preferring plain Debian packaging.
Best wishes.
You know. That "packaging" was the norm before some bright heads decided to split every package into "package" and "package-dev" (or -devel, or whatever).

It is highly un-Unix-ish to provide packages without the corresponding development stuff (.h, .la, .a).
 

The Following 2 Users Say Thank You to reinob For This Useful Post:
Posts: 1,994 | Thanked: 3,342 times | Joined on Jun 2010 @ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
#26
Originally Posted by reinob View Post
You know. That "packaging" was the norm before some bright heads decided to split every package into "package" and "package-dev" (or -devel, or whatever).

It is highly un-Unix-ish to provide packages without the corresponding development stuff (.h, .la, .a).
Well, I expect that there is a source-package with .h and .c files, and a binary-package with .so files. Not one package, just two files for one package. Installing .a and .la on user device when user doesn't need them... just consumes space and makes a mess. If there is need for debugging... then you can give to user the whole mess: .c, .h, .patch, .a, .la, .so, whatever. But the binary package for end-user should not contain additional files which are not useful at all. Right?
Yes, it is highly probable that I'm unaware of some special mission of .a and .la files. I'm not a professional debugger; for me, either program works or it doesn't. I write code in Notepad-Leafpad, compile it in command line by politely asking gcc to do it, and use the final .so or .bin file. Breakpoints don't exist for me. If debugging is necessary, I add print-or-log-or-whatever lines to my code and recompile it, to figure out later what was the problem. I dislike all these makefiles, solutions-projects, compiling environments, etcetera. And on the same level, for me .a and .la are just transient files generated by gcc for gcc. I can easily concede that separating gcc into compiler-assembler-linker-whatever is beneficial; gcc is a joyful program to use. But I have no understanding of .a and .la files - except that .so can work without them.
Best wishes.
 

The Following User Says Thank You to Wikiwide For This Useful Post:
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#27
Originally Posted by Wikiwide View Post
Well, I expect that there is a source-package with .h and .c files, and a binary-package with .so files. Not one package, just two files for one package. Installing .a and .la on user device when user doesn't need them... just consumes space and makes a mess. If there is need for debugging... then you can give to user the whole mess: .c, .h, .patch, .a, .la, .so, whatever. But the binary package for end-user should not contain additional files which are not useful at all. Right?
That's why those bright heads split the packages between "normal" and "development". It may be the right thing to do for most people. I myself tend to be very very conservative with "modern" technology

Yes, it is highly probable that I'm unaware of some special mission of .a and .la files.
The .a is the static counterpart of the .so, so you need the .a if you want to statically link a library (as opoosed to using the .so, for which you need the .la).

I'm not a professional debugger; for me, either program works or it doesn't. I write code in Notepad-Leafpad, compile it in command line by politely asking gcc to do it, and use the final .so or .bin file. Breakpoints don't exist for me. If debugging is necessary, I add print-or-log-or-whatever lines to my code and recompile it, to figure out later what was the problem. I dislike all these makefiles, solutions-projects, compiling environments, etcetera. And on the same level, for me .a and .la are just transient files generated by gcc for gcc. I can easily concede that separating gcc into compiler-assembler-linker-whatever is beneficial; gcc is a joyful program to use. But I have no understanding of .a and .la files - except that .so can work without them.
Best wishes.
The funny thing is that most programs are developed using the traditional way, i.e. a Makefile that builds the program. make install usually installs everything (yes, including .a and .la, etc.)

The .deb packagers (maintainers I think they're called) take that and generally make a mess of it by adding dependencies, using more-or-less common sense (unfortunately now always) and decide to strip one thing or the other or (in the case of Maemo) to "optify" the package after-the-fact (instead of compiling with the appropriate --prefix).

It's actually pretty incredible that things like Maemo, Debian and Ubuntu actually work OK-ish
 

The Following 2 Users Say Thank You to reinob For This Useful Post:
Posts: 1,994 | Thanked: 3,342 times | Joined on Jun 2010 @ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
#28
Originally Posted by reinob View Post
That's why those bright heads split the packages between "normal" and "development". It may be the right thing to do for most people. I myself tend to be very very conservative with "modern" technology
I tend to be conservative, but I have seen Debian packaging before I have seen a Makefile, so instead of trying to use both Debian packaging and Makefile at the same time, I aim to use only Debian packaging, plain, without .configure files or whatever.
Originally Posted by reinob View Post
The .a is the static counterpart of the .so, so you need the .a if you want to statically link a library (as opposed to using the .so, for which you need the .la).

The funny thing is that most programs are developed using the traditional way, i.e. a Makefile that builds the program. make install usually installs everything (yes, including .a and .la, etc.)
'Everything' sounds ominously complicated.
Originally Posted by reinob View Post
The .deb packagers (maintainers I think they're called) take that and generally make a mess of it by adding dependencies, using more-or-less common sense (unfortunately not always) and decide to strip one thing or the other or (in the case of Maemo) to "optify" the package after-the-fact (instead of compiling with the appropriate --prefix).

It's actually pretty incredible that things like Maemo, Debian and Ubuntu actually work OK-ish
Agree. I use gcc flag "-shared", and see neither tail nor whiskers of 'additional' .a or .la files - only the needed .so file.
Best wishes.
 

The Following User Says Thank You to Wikiwide For This Useful Post:
Posts: 473 | Thanked: 141 times | Joined on Jan 2009 @ Virginia, USA
#29
Just a quick update and sanity check. I have updated, gotten all of my core apps back on, and am running the following system-level stuff:
  • CSSU (Thumb2, I believe) [done]
  • 2.6.28.10-power50 [done]
  • Power settings [done]
  • swapolube [done]
  • flopswap [pending remapping the SD card]
  • backupmenu

Have I forgotten anything? One thing I noticed is that the backupmenu-1.1 looks and acts a lot like the old bootmenu I had on my N810. I didn't see any backup options. Did I miss a step?

Oh, one more question. Does anyone happen to have a copy of maemo_flyby_xvid_lame_r3.avi? The site http://castus.dnsalias.com:8080/share/ is off the internet apparently.
 
Posts: 473 | Thanked: 141 times | Joined on Jan 2009 @ Virginia, USA
#30
Okay...Something I have noticed since rebooting onto the power50 kernel is that my machine is not as snappy as it was on the nokia kernel. And I had apps drop off (like Panucci), and my display will momentarily blank. Anybody got any ideas?

Edit: Yeah, there's definitely a problem. I had the device reset twice within 10 minutes. I was in the app manager both times, once scrolling through packages, the other trying to install the cssu features package...Just bam, blank screen and blue LED, then it reset.

Last edited by VulcanRidr; 2013-06-21 at 02:54.
 
Reply

Tags
fremantle, nokia n900


 
Forum Jump


All times are GMT. The time now is 16:48.