New QT based installer: Easy Plug Computer Installer (ESIA)

[dubitoergosum]

Looks like the URL has changed to https://sourceforge.net/projects/epia/.

[BP]

rooster,

Good news !   Before going to bed, i thought i would give one more try to the "boot from sd" option in ESIA, and let it run all nigth.  As explained in previous post it freezed twice on previous attempt when selecting that option...  Now with same DOK, same files (untouched since last install), same pc, same usb port on pc, etc...  go wonder, it worked !!  And I think that option made the difference, because now uname -a return 2.6.34.1 !!! yeah !! ;-)

Not sure what the problem was, if any... , but my take away will be "always try 3 times" ;-)

the bad news is I wont be able to retry autofs install before 3 days from now... but i am positive

Thanks again !

[rbgray]

Looks like the URL has changed to https://sourceforge.net/projects/epia/.

Might I suggest the first post on this thread be edited to correct the links...

[rooster]

Hi guys,

Yes the SF project name has been changed (esia->epia), sorry for inconvenience
I updated the seed of this thread and the header too, though the binaries and the documents still refer to esia.

[ppmt]

Does the change of name means it will soon support guruplug as well? or will it still be specific to sheevaplug?

the program looks good but I don't have a sheevaplug

[rooster]

the rename came from marketing, I have no plans currently for additional dev

[lyzby]

I have used the ESIA/EPIA installer to try to install two of the distributions in the distro folder to nand (squeeze and ubuntu), and the program reports successful completion, but for both when I try to boot, I get a NAND read "Bad block at 0x2a0000" error message, which causes a bad checksum and failure to boot.  This is on an original Sheevaplug.

Here is the message: 
---------------------------------
...
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x100000, size 0x400000

Bad block at 0x2a0000 in erase block from 0x2a0000 will be skipped
Reading data from 0x51f800 -- 100% complete.
4194304 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.33
   Created:      2010-03-02  21:27:23 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2840500 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>>
-----------------

The command, "nand bad" reports 0x2a0000 as a bad block.  Is it possible that the installer is writing to it anyway, and not using the write.e command which skips bad blocks?

Is there a work-around?

[birdman]

http://www.linuxfordevices.com/c/a/News/Marvell-Easy-Plug-Computer-Installer/

[lyzby]

@birdman--This was the installer I used, first installing squeeze to nand and then ubuntu904.  In both cases the program reported successful installation, but on booting, got the error at 0x2a0000, which is reported as a known bad block by "nand bad".  So is the installer not avoiding bad blocks by using "nand write.e" or the equivalent?  How would I flash so that the device would boot?

[rooster]

the only way to fix it would be to replace the initrd used by the ESIA with code that performs nand write with APIs that skip bad blocks, not with cp/dd.

[lyzby]

Ok, I figured out how to get around this problem of a bad block in the uImage nand partition area.  Not too hard, except when you don't know anything.  The solution is given in the thread I originally started: http://plugcomputer.org/plugforum/index.php?topic=2056.0

[rooster]

That is the right way to do it.
This could be set in uboot env to be done on every esia install.

[lyzby]

rooster--can you outline the general procedure by which ESIA/EPIA performs its functions in writing to nand?

For instance, the provided Debian_squeeze directory has a uImage file, a modules.tar.gz, and a root.tar.gz.  The uImage gets flashed to the area, 0x100000.  How do the two .gz files get processed to produce an initrd and the contents which are flashed to 0x500000?

As set by bootargs_root, the rootfs is a ubifs--how does that get created?

[lyzby]

Wanting to further explore installations to nand, I decided to try the latest sheeva-with-linux kernal, and so created a new directory on my ESIA usb drive, "26342".  From the Debian_squeeze directory, I copied to it root.tar.gz as my basic root filesystem and MANIFEST.cfg as a sample.  I then got files from sheeva-with-linux.

Code:

wget http://sheeva.with-linux.com/sheeva/2.6.34.2/sheeva-2.6.34.2-uImage
wget http://sheeva.with-linux.com/sheeva/2.6.34.2/sheeva-2.6.34.2-uImage.md5
wget http://sheeva.with-linux.com/sheeva/2.6.34.2/sheeva-2.6.34.2-Modules.tar.gz
wget http://sheeva.with-linux.com/sheeva/2.6.34.2/sheeva-2.6.34.2-Modules.tar.gz.md5

I modified MANIFEST.cfg to reflect the proper filenames and md5 numbers.

Code:

Application=26342
Summary =  sheeva-with-linux + Squeeze root ARM5 SheevaPlug Distribution
Description = This application consists of a Sheeva-with-linux kernel 2.6.34.2, & modules Debian Squeeze root file system (password: nosoup4u) and kernel modules from: http://sheeva.with-linux.com/sheeva/

rootfs.tar.gz = root.tar.gz
rootfs.tar.gz_checksum = 1C1A54095C8DF36627651D75A3FB0A04
uImage = uImage
uImage_checksum = cd49b2df58568e2104da0407a6a81017
modules.tar.gz = sheeva-2.6.34.2-Modules.tar.gz
modules.tar.gz_checksum = de10ee990b5698a2346fa15e42e95a5d

I then ran the ESIA/EPIA installer.  Unfortunately, it died at 85% done, but I was hopeful that this was far enough along so that I could just add the uImage, so I did the following (I would have needed to do it anyway since I have a bad block in the uImage area which ESIA would have tried to overwrite):

Code:

usb start
fatls usb 0 /26342
fatload usb 0 0x800000 /26342/sheeva-2.6.34.2-uImage
nand erase clean 0x00100000 0x00400000
nand write.e 0x800000 0x100000 0x300000
boot

This booted into a 2.6.34.2 debian system.  I haven't played with it enough to confirm that it is stable and that nothing was omitted, but this appears to be a way to get the sheeva-with-linux kernels loaded and a ubifs file system.  I updated password, timezone, /etc/hosts, and /etc/network/interfaces, and rebooted, and all appears to work.

[marlar]

I had to give up on this installer because it requires a USB stick less than 2 GB. None of the shops around here has so small sticks, they are totally obsolete. Can't the installer be updated to use more modern USB sticks?