• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 2 3 [4]
46  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 09, 2011, 07:16:09 PM
By the way, did you set the U-Boot variables:

setenv mainlineLinux yes
setenv arcNumber 2659
saveenv

2659 is for the Guruplug
2097 for the SheevaPlug
2678 for SheevaPlug eSATA

When you upgrade the kernel, the stopping after kernel decompress is often caused by these being missing.
47  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 09, 2011, 07:02:55 PM
Palcom,

Could you please start a new discussion thread so we can get this issue out of the 2.6.35.10 thread.  Thanks
48  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 09, 2011, 12:02:18 PM
palcom,

The thought occurred, to update the kernel, it may be simpler to just try one of the README scripts from http://sheeva.with-linux.com/sheeva:

log into your system as root (can do this from /root)

wget http://sheeva.with-linux.com/sheeva/README-2.6.35.9

bash ./README* --nandkernel

The script should not only install the kernel, but also update the modules.

Ok, IŽll try it, but before running the script I supose I have to set the setenv variables with the values I have in my guruplug, isnŽt it?


These scripts are run from the Linux environment.  Just log in as root.  Should be in the directory /root (do pwd to check).  It will download a bunch of stuff into that directory, then should flash the kernel.

If you are already booting from a kernel in the correct flash location -- mdtpart   0x400000@0x100000(uImage) -- then there should be no need to make any changed to the U-Boot variables.

If you have troubles, give a shout.   Good Luck
49  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 08, 2011, 11:03:20 PM
palcom,

The thought occurred, to update the kernel, it may be simpler to just try one of the README scripts from http://sheeva.with-linux.com/sheeva:

log into your system as root (can do this from /root)

wget http://sheeva.with-linux.com/sheeva/README-2.6.35.9

bash ./README* --nandkernel

The script should not only install the kernel, but also update the modules.
50  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 08, 2011, 07:04:26 PM
Should have mentioned, in the ESIA method, you can take the Debian Squeeze directory that the project supplies, and replace the contents with whatever kernel image (and other related files) that you'd like.  Just make sure to also upgrade the Manifest file.
51  Linux Stuff / Kernel / Re: 2.6.35.10 new kernel available on: January 08, 2011, 07:00:38 PM
pacolm,

There's about three or four well-explained guides to doing a kernel upgrade.  The only question is -- Which one, if any, will work for you? . . . and do you have the patience to deal with the situation if one of the brinks your plug?

It sort of depends on the hardware of both your Plug and your host system.

If you have a 32-bit host, I'd recommend first trying the ESIA method  http://shankserver.org/2010/09/unbrick-sheevaplug/

After that, the "correct the Installer issues" method  http://plugcomputer.org/plugforum/index.php?topic=3680.0


If you have a 64-bit host, you're probably going to have to do a lot of the work manually -- getting the kernel onto a USB stick, SD card or TFTP server to copy it into the RAM, then move it into Flash.  Then, there will remain the issue of the module dependencies (see the last step of the previous link).

Wish there was a simpler answer.  (And, maybe, there will be, for you. ;^)
52  Hardware and U-Boot firmware / Hardware / Re: Dead Plug? on: January 08, 2011, 06:44:22 PM
Yes, it should be 5V.
53  General Category / General Discussion / Re: Is the window closing on Plug Computing? on: January 08, 2011, 02:05:25 PM
A summary of what has been written by others in various places.  This is not intended to be a rant; just cold, logical observation.

It certainly seems as if the window either is closing, or it will be closing in the not-distant future.

Marvell is a company that makes profits from selling many chips.  Any product needs a huge customer base, or it will not be worth the time to develop and product it.  Neither Marvell, nor it's partner manufacturers are likely to keep producing Plugs for just a few hundred, or thousand hobbyists.

We might take a lesson by reviewing the product arc of the NSLU2.  It was one of the somewhat earlier NAS devices, was sold in retail stores for a decent price.  The fact that it was a retail product means it provided a revenue stream that would sustain it's availability for a while.  Being a retail product also meant that the platform was relatively stable.

Both the availability and the stability gave hobbyists the chance to create software that would reliably install the Linux overlays.

Seems to me, some people at Marvell were hoping the same thing would happen with the Plug.  Not so much because the company was thrilled to support this niche, but because they hoped that the hobbyists, and the hype, would lead to some new product or use which would sell a million units.

But, there were problems on the way to paradise.

We can put aside, the power supply issues.

The main issue is the new kernel installation and un-bricking.  It is not so difficult, really.  But there are two things that make it difficult for the newcomer.  First, the differences in Plug configuration [is an old one, a new one, a new-old one?].  Second, the differences in the installing host (operating system, 32-bit vs 64-bit).
As a result of these two issues, there are many instructions and "helper" scripts about how to install or unbrick a Plug. . . But, it seems, most of them will only work for some persons, while others work for other people.
So, the bottom line is, the guy who may know some Linux, but doesn't know about bootloaders or kernel installation is facing a steep slope and no clear map.  (The plug is for the "hard-core" hobbyist.)

Those challenges mean mean that the hobbyist community which Marvell, et.al., might have hoped for has not taken off with the speed and force similar to the Slug (NSLU2).  (Not to slight those who have helped -- Thank you, cbxbikerr61, rooster, those who've contributed to the wiki, and all the others who have built and helped others.)

Furthermore, the evidence suggests that Marvell is already minimizing their involvement/investment.  The official documentation set has errors that will cause a re-flash to fail; that has not been corrected.  The wiki sees much more spam than actual content activity.  In fact, it seems there's been no administration of the wiki since November.  There is no reply to email requesting that the wiki be secured.  It doesn't seem as if it would take much effort (investment) to fix some of these problems, so the inaction only contributes to the impression that the situation is being allowed to come to a conclusion without further corporate effort.

I started working on the wiki, and there's a lot more that might be done.  But, then I saw the spam, and the user creation logs, and realized that hardly anyone is looking at it.  Made me wonder if my efforts would be supporting a community, or just talking to myself.  That was what led me to these observations and conclusions.  I suspect others have arrived at the same conclusions.

Thus, we arrive at the question posed in this discussion -- just how long is this going to continue?  Will the plugwiki and the plugforum simply disappear one day?  (The domain is, after all, registered to Marvell.)  Is there enough of a community that it would make sense to move the wiki and forum to a non-corporate domain?

Contrary to what it may seem, I'm pretty  happy with my Sheeva; it will be a better Asterisk host than the Slug.  I'd like to be able to buy another one in a few years if/when this one breaks.

But, I suspect that won't be possible.  I expect that, say three years from now, the choice will be to work on whatever new little device has come along (hoping it has a serial/JTAG port), . . . or, buy a Plug replacement/spare now and pull it out of storage when the service unit bites the dust.

Hobbyists work on the fringes of the marketplace.
54  Linux Stuff / Kernel / Re: 2.6.37 new kernel available on: January 05, 2011, 02:33:48 PM
Thanks for the work.  While doing working on the wiki, I'll enter the preferred download location to replace your site, and mention your's as a back-up.
55  Hardware and U-Boot firmware / U-Boot stuff / Re: Puzzled about addresses on: December 31, 2010, 10:53:22 PM
The reason for the RAM starting (0x800000) is because the first 8 MB are reserved for U-Boot.

Watch the console during startup or restart, stop it before the autoboot.

The U-Boot log will say something like:

Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done.

http://www.plugcomputer.org/plugwiki/index.php/BootNarrative

So, there is definitely a reason for the 0x800000.
56  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: December 31, 2010, 12:18:02 AM
First, thank you for continuing to post the results of your research.  It's tough when there is no answer.

In your introductory post it was not exactly clear how you encountered the problem.  Probably you had done nothing new or special, but it can be helpful to be clear that the system had been stable for a period of time, and without any change, simply began "misbehaving."

That said, this situation is very unusual.  I have no answers, only observations.

I doubt it was a system compromise, normally crackers want to use the system, not damage it.  And, if one is motivated to damage it, there are far better ways to do so than make procps temporarily unusable.

It could, hypothetically, be a problem with your SD card, except the fact that it only effected the file permissions of one entire package.  The conditions seem so unlikely that it is hardly worth considering.

Seems that the best answer is that this was a packaging problem.

If I were in the same situation, my next questions would be along the lines of:

-- What is status of the permissions for the other files in /usr/bin ?

-- Had you recently done any installation that might have been related to the problem?

-- When was the last time you used any of the commands from that package?

Doubt that this is much help, but again, thanks for sharing.
57  Hardware and U-Boot firmware / U-Boot stuff / Re: Puzzled about addresses on: December 29, 2010, 10:05:51 PM
bootcmd=nand read.e 0x800000 0x100000 0x400000 ; bootm 0x800000

I assume the kernel is being loaded into RAM at 8MB and then the bootm command starts it executing from there.  WHY 8MB?  The Debian instructions (http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html) loads it into 4MB and puts an Initrd Image at 8MB.  Why the difference.  Are these numbers plucked out of thin air, or is there a reason they are like they are?

Yes these commands copy the kernel (4 MB length) from Flash into RAM, starting at the 8 MB address; and then start execution.

0x800000 is the RAM target address
0x100000 is the starting (Flash) address from which to load (standard kernel Flash storage address)
0x400000 is the length of memory to copy

The reasons for the Flash addresses are easy -- cramming everything in as closely as possible.  I don't know why the RAM address of 8 MB was used.  The page you reference no longer seems to have a 4 MB starting address.  Perhaps it has something to do with alignment ( Undecided ).

Might keep in mind that use of initrd is often only temporary -- for new installations (mounting in a RAM file system so that a new rootfs can be uncompressed and written).
Pages: 1 2 3 [4]