SheevaPlug Installer with updated kernel, uboot, distro ?

[superpat]

@pingtoo


Hi,

I just tried out your suggestion to add /bin/sh to the bootargs.

What happens now is that the system  "stops" and hangs instead of rebooting back to uboot

regards

P

[pingtoo]

@pingtoo


Hi,

I just tried out your suggestion to add /bin/sh to the bootargs.

What happens now is that the system  "stops" and hangs instead of rebooting back to uboot

regards

P

OK, after review all your putty.log I am convinced it is not a random error of bad code or configuration issue. I think it is in the initrd.

I can not think of reason why we are not seeing any output two more suggestion, one use a known working kernel to test with the sheeva-installer-1.01. Second try append the word debug at end of setenv bootargs ....

If a known kernel work then we know it is the new kernel is the issue. And with the debug kernel parameter we should see something unless the console was not setup correctly.

[johndoe]

Hi guys, new here but after reviewing many posts on the forum, I want to comment something especially in this thread.
I see many users, debugging methods of installing new stuff to the plug and giving information to all the others, but the administrators of the forum (distributors employees) many times are just watching, without giving any actual help to the guys who are willing to destroy their sheeva plug, just to test new things and help others.
Many distributors (companies) of the sheeva plug, have updated their sites with all the new kernel or distro, but noone gave an updated procedure online to the community.
Ok I saw that they give scattered  information and help here and there, but sometimes they let the people do all the work with out any comment.
It's very sad...       

[mgillespie]

It's pretty hard to totally brick a plug.  Those that are tinkering because they know how to get things back.

There are documented and well tested methods of updating your uboot, kernel, rootfs, but this is not one of them (yet..)

Off skiing next week (French Alps), so unlikely to have tinker time until I get back..

[superpat]

@johndoe

Hi, 

Welcome ro the madhouse.

Firstly.  I agree with the previous poster. It is extremely hard to permanently brick the Sheevplug.  I would go further and say with a little bit of caution it is difficult to break the hardware either.  I have been modding my Sheena for weeks now, running it out of it's case, adding  the esata port etc.  So long as you are careful and think before you power on, observe the basic static precautions then you will get away with it.

Secondly, I agree with you wholeheartedly regarding this forum and wiki and their layout and presentation of information.  There are a lot of broken links, a lot of incorrect information, and the information is not very well organized.

My particular peeve, is that there is no bug zilla, a place where users can report errors and where the "support" people, (if they existed) could assign severity level and fix time scales.
It would save a huge amount of time if users could go to ONE place to look up problems.

The people running this forum are MARVELL engineers,  but the Plug is a  devolved design exercise,  by Globalscale,  (they have their name on the rev 1 and 1.3 schematics)!

There are a lot of very good poeple on this forum, giving  a lot of their own time to try to provide answers to all the problems that people are finding.

I don't think anyone on the design or manufacture side have ever really given a great deal of thought to the basic support of the product. The implication I get is that "you have bought a dev kit then you buy the warts and all". 

Realistically how much support can a manufacturer  afford to give on a $99 piece of kit?

cheers

P

[marcus]

I've been fighting the same problems as have been reported here (on an eSATA plug, FWIW), but using the old installer package.

What I have learnt:

If the /etc/init.d/rcS script reads 3 mtd partitions, this command:

Code:

mount -t ubifs ubi0:rootfs /mnt/target

mounts the uImage partition when we want it to mount the rootfs partition. It then gives messages like:

Code:

Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"

...

**** Erasing all flash
ubiformat: mtd1 (nand), size 4194304 bytes (4.0 MiB), 32 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes

...

**** Copying root filesystem. This will take few minutes
tar: write error: No space left on device.................................]

Solution:
Retain orion_nand in the mtdpartitions environment variable, despite the note "If using kernel >= 2.6.30 then replace orion_nand with orion_mtd". This solution has been mentioned here several times.

I am also seeing exactly the same crash as Patrick, starting with Unable to handle kernel NULL pointer dereference at virtual address 00000018. However, I am using a kernel that I (cross) compiled. And yet the error seems to be identical.

My first thoughts were that the kernel I created was faulty. I am relieved to finds myself at the same end point, but via a different route.

I have downloaded the installer v1.01 from the publicly posted link, and found it to be unreadable (although tar -xvzf sheevaplug-installer-v1.01.tar.gz extracts partially, as Patrick reported).

@mgillespie - I am willing to try out your as-yet-unpublished installer. Will PM you imminently.

Edited to add:

Having run the same old installer that I have been using for the past couple of months, I then manually applied the kernel that I had compiled, and everything looks good and proper.

So the conclusion is that there is something in the installer process that is tripping up the (various, different) kernels that we have been working with?

[Mat]

This could be bug in the sheeva-installer-1.0 code.

@mgillespie,
Please confirm your version of initrd is same as sheeva-install-1.0.

If the initrd is same, then this could be because the 1.0 initrd's rootfs installation script /etc/init.d/rcS is not doing the right thing

The /etc/init.d/rcS call busybox's applet mdev with argument "-s" multiple times. This argument instruct the code to scan for new device and check kernel events. the problem is in order to do this the sysfs must be mounted in /sys this is not done in the script. I suspect the previous versions of kernel is more forgiving so it does not crash kernel. However this version of kernel is not very happy about the code access system inode without correct setup.

This is just my guess by looking at the code. I have no prove.

I have encountered the same problem, too.

I found that busybox's bug tracker has some report related to this problem,

    https://bugs.busybox.net/show_bug.cgi?id=639

Hope these information helps.

sincerely, Mat.

[rooster]

If you are having problems you might want to try the new QT based installer, I used it with 2.6.33 and never encountered this problem.

The only issue I can see is that when using a memory card the initrd rcS formats it, in some cases the formatting works but linux can not copy data to new partition, a reset is needed and you will need to perform the installation procedure again, it should succeed the second time.

In any case try out the new installer: http://plugcomputer.org/plugforum/index.php?topic=1400.0

[Mat]

Thank you for your information! ESIA looks great! I will try it :-)


BTW, I solved the sheevaplug-installer in previous days.


The installation problem is caused by mdev. We can change it to create dev nodes manually.

unpack the initrd from the installer and change the following lines.

Code:

--- etc/init.d/rcS.orig 2010-04-11 12:08:36.000000000 +0800
+++ etc/init.d/rcS      2010-03-25 01:01:01.000000000 +0800
@@ -51,10 +51,10 @@
                ubiformat -y /dev/mtd1
                ubiattach /dev/ubi_ctrl -m 1
                # Following will redetect devices, including /dev/ubi0 which we care about
-               mdev -s
+               mknod /dev/ubi0 c 252 0 #mdev -s
                ubimkvol -m -N rootfs /dev/ubi0
                # Rescan. This will get us /dev/ubi0_0
-               mdev -s
+               mknod /dev/ubi0_0 c 252 1 #mdev -s
                # Wipe out the volume
                ubiupdatevol /dev/ubi0_0 -t
        else

This patch works for 2.6.33.x -- 2.6.34-rc2 kernels.
Hope this helps~

sincerely, Mat.