• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 2 [3] 4 5 ... 9
Author Topic: Sheevaplug installer - alpha-6 release - Testers needed  (Read 42097 times)
ianjb
Jr. Member
**

Karma: 0
Posts: 65


View Profile
« Reply #30 on: June 16, 2009, 06:48:10 AM »

The idea of the installer is to be able to recover a bricked plug. A bricked plug is one that is no longer able to boot or communicate over the serial port.

The runme.sh script running on your linux box calls an application openOCD also on your linux box. OpenOCD uses the jtag interface available through the miniusb port to control the bricked plug. The jtag interface is able to read and write directly to the nand and access the hardware e.g. an attached usb memory stick.

The runme.sh uses openOCD to erase the nand flash on the plug, then read the images from the usb stick attached to the plug and write those images into the nand, restoring the plug to it's original state.

Hope that description helps.
Logged

edmc
Newbie
*

Karma: 1
Posts: 21


View Profile
« Reply #31 on: June 16, 2009, 09:06:30 AM »

Why won't the Sheeva environment execute the script?

Think of it this way... the Installer is being asked to re-write all (or some) of the flash that the Sheeva OS is currently using to present an execution environment.  The JTAG interface used by the Installer allows an external device (via this USB/Serial-to-JTAG connection) to write to the Flash without any help from software running on the SheevaPlug itself.  This would be mandatory if, say, the OS on the SheevaPlug got so corrupted it wouldn't boot.
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #32 on: June 16, 2009, 11:53:12 AM »

As others have said, the JTAG is just some hardware that allows direct access to the NAND memory (and perhaps some other functionality).  It's mainly used here to install a new Uboot program.  Think of it as a sophisticated equivalent to toggling in a boot program on the front console of one of your old mainframes.

The installer is like the CD you put in your optical drive to reload Windows on a PC.  Once you have a viable Uboot, you can tell it to boot off of an attached USB thumb drive, and what is there is an environment that installs a pristine Unix on either the NAND or on an SDcard.  You don't really need the JTAG for that function.  Once the installer is done, you can remove the thumb drive and the Plug then boots into whatever Unix you have installed.

Actually, I believe the JTAG board (which includes the SDcard interface IIRC), is part of the development kit for the Plug.  The intent of Marvell/Globalscale was to sell the development kits to allow people to develop their own products, and then sell them thousands of Plugs w/o the development kit (at about 1/2 the $99 price) for them to load with their apps and resell as blackbox plug and play systems.  I wonder how their strategy has worked in practice:  It seems most of us here are experimenters and hobbyists who intend to make use of the actual development kit, including at least the SDcard hardware, to put together one-zie and two-zie systems for ourselves.  Are we their main clientèle, or just one small facet of it?
Logged

ianjb
Jr. Member
**

Karma: 0
Posts: 65


View Profile
« Reply #33 on: June 16, 2009, 12:18:07 PM »

The Marvell website shows a page with:
Marvell Plug Computing Partners
    * Axentra       
    * Cloud Engines, Inc.       
    * CTERA       
    * Eyecon Technologies       
    * GlobalScale Technologies, Inc.       
    * Ionics EMS       
    * Prosyst       
    * Tonido       
    * WebTView

Only GlobalScale and Cloud Engines has a "Buy" button so far. Right now I'm guessing we, the experimenters, are their main clientele. Product availability still seems to be a problem even in ones and twos.
Logged

mcginnist
Newbie
*

Karma: 0
Posts: 8


View Profile
« Reply #34 on: June 16, 2009, 02:14:54 PM »

Didn't work for me, and I cannot figure out the problem.  I've tried from my Jaunty laptop, and also from a Jaunty live CD (two different machines).

I've unplugged the power and restarted, unplugged the USB console cable and restarted, but it's beating me.

Code:
**** Preparing environment variables file ...
 **** Burning uboot and environment variables ... This will take few minutes ...
Open On-Chip Debugger 0.2.0-in-development (2009-05-17-10:32) svn:1800M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
2000 kHz
dcc downloads are enabled
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2)
Info : JTAG Tap/device matched
Error: unknown EmbeddedICE version (comms ctrl: 0xfffffffe)
Error: unexpected Feroceon EICE version signature
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
Error: unexpected Feroceon EICE version signature
Error: timed out while waiting for target halted
Runtime error, file "../scripts-linux/openocd/config/board/sheevaplug.cfg", line 24:
   
 **** openocd FAILED
 **** Is the mini USB cable connected?
 **** Try powering down, then replugging the Sheevaplug
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #35 on: June 16, 2009, 03:04:31 PM »

I'm not ready to reflash my Plug yet, but I'd be interested in testing whether it is likely to work (i.e., whether openocd is able to talk to the Plug reliably) when I am indeed ready to do so.  I also know nothing about the openocd command, and am somewhat leery of fiddling with this somewhat dangerous appearing command without knowing what I'm doing.  If I go to the sheevaplug-installer-alpha-6 directory and execute something like:

Code:
../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit

is it likely to tell me if openocd is talking to the JTAG correctly... or will it brick my Plug?  Is there some way I can verify that everything is good to go, without actually committing to reflash my Uboot?
Logged

Rabeeh Khoury
Administrator
Full Member
*****

Karma: 5
Posts: 218


View Profile
« Reply #36 on: June 19, 2009, 01:28:28 AM »

It won't brick your plug.
Note that if you don't do the 'exit' command then you can connect to openocd via telnet port or on gdb port.
Logged

mcginnist
Newbie
*

Karma: 0
Posts: 8


View Profile
« Reply #37 on: June 19, 2009, 06:24:59 AM »

Rabeeh,  have you any ideas why I cannot use the installer?  It seems that openocd will not halt my plug.  When I do runme.sh, it appears to reset the plug instead of halting it.  In the thread for the alpha-5 release, I saw a suggestion to lower the 2000khz speed in the sheevaplug.cfg file.  I lowered it to 500 with no change in behaviour.

I was able to bubt the new uboot image, then load your kernel and initrd to create the ubifs (love the boot speed from flash now!), but I am nervous that I will eventually get myself in a position where I will have to use openocd to load uboot.
Logged

passive
Newbie
*

Karma: 0
Posts: 15


View Profile
« Reply #38 on: June 20, 2009, 07:13:24 PM »

Didn't work for me, and I cannot figure out the problem.  I've tried from my Jaunty laptop, and also from a Jaunty live CD (two different machines).

I've unplugged the power and restarted, unplugged the USB console cable and restarted, but it's beating me.

Code:
**** Preparing environment variables file ...
 **** Burning uboot and environment variables ... This will take few minutes ...
Open On-Chip Debugger 0.2.0-in-development (2009-05-17-10:32) svn:1800M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
2000 kHz
dcc downloads are enabled
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2)
Info : JTAG Tap/device matched
Error: unknown EmbeddedICE version (comms ctrl: 0xfffffffe)
Error: unexpected Feroceon EICE version signature
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
Error: unexpected Feroceon EICE version signature
Error: timed out while waiting for target halted
Runtime error, file "../scripts-linux/openocd/config/board/sheevaplug.cfg", line 24:
   
 **** openocd FAILED
 **** Is the mini USB cable connected?
 **** Try powering down, then replugging the Sheevaplug

I'm having the same problem.
Logged

jdonth
Jr. Member
**

Karma: 0
Posts: 75

Azle, Texas


View Profile
« Reply #39 on: June 21, 2009, 07:46:05 AM »

Can I use the installer to ONLY install the rootfs?

If so, what is the procedure?

Thanks,
~Joe
Logged

...I've always depended on the kindness of strangers

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #40 on: June 23, 2009, 07:30:09 PM »


Well, I've finally gotten around to trying to explore the use of openocd in preparation for perhaps attempting to upgrade my Plug using Rabeeh's alpha-6 installer.  Unfortunately, my pre-test seems to fail much like bpsbr_ernie experienced and documented earlier.  I tried the following command from the alpha-6's uboot subdirectory (as it would be executed had it been invoked from runme.sh, but w/o the actual commands to reflash the uboot):
Code:
../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit
And here are the results:
Code:
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot# ../scripts-linux/openocd/openocd -f ../scripts-linux/openocd/config/board/sheevaplug.cfg -s ../scripts-linux/openocd/config/ -c init -c exit
Open On-Chip Debugger 0.2.0-in-development (2009-05-17-10:32) svn:1800M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
2000 kHz
dcc downloads are enabled
Error: JTAG communication failure, check connection, JTAG interface, target power etc.
Error: trying to validate configured JTAG chain anyway...
Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x00. tap=feroceon.cpu pos=0 expected 0x1 got 0
Warn : Could not validate JTAG chain, continuing anyway...
Warn : value captured during scan didn't pass the requested check:
Warn : captured: 0x00 check_value: 0x01 check_mask: 0x0F
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot# echo $?
0
root@kevey:/home/res/SheevaPlug/sheevaplug-installer-alpha-6/uboot#
BTW, after executing this, the /dev/ttyUSB0 device is no longer present, and I have to unplug/replug the mini-USB to get it back.

This doesn't look like it is working correctly to me.  Any ideas?
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #41 on: June 23, 2009, 08:49:56 PM »

Well, oops, perhaps I spoke too soon.  When I removed the final "-c exit" above, openocd remained up and "open".  I was then able to telnet to port 4444 and inject commands (I tried halt, sheevaplug_init, cpu, reset, version, reg) and aside from a running trail of error messages, most of the commands seemed to have the intended effect, although I'm not sure about that the commands like cpu or reg returned anything useful -- most of the registers seemed to be zero or 0xFFFFFFFF.

I'm still a bit reluctant to try reflashing the uboot, though, not knowing whether the observed errors are in fact significant, and as a result, whether I might be left with a bricked plug with no way to unbrick it.

Another oddity:  Even though the /dev/ttyUSB0 device disappeared when openocd was executed, it didn't seem to impede by ability to access the Plug with openocd.  I could even break out of the command and then reinvoke it.  (Is there a graceful way to tell openocd to exit?

Next question: If I do run the alpha-6 installer, I know it reflashes the Uboot and its environment.  After that succeeds, the Uboot's environment is set up to automagically load the new installer off a USB drive, which I suppose installs a release candidate kernel and associated Ubuntu system.  By default, I presume this installation is on the internal NAND, wiping out the load that was there before.  Since the new Uboot allegedly has the capability of booting a kernel directly off an SDcard, is it possible to instruct the installer to do the install to the SDcard as well?  If so, how do I go about this?

Finally, how can I find out what modules are included in this kernel, and what packages are included in the system, before installing them?  In particular, I'd like to know whether the new kernel supports loopback devices, and whether it is capable of mounting writable NTFS file systems.  It would also be nice to know if it has better USB recognition capabilities.  I have a USB-serial cable that my Ubuntu desktop seamlessly supports, but which the default SheevaPlug kernel doesn't seem to know how to handle.

Again, any comments or suggestions? (And, thanks in advance.)
Logged

bpsbr_ernie
Newbie
*

Karma: 0
Posts: 5


View Profile
« Reply #42 on: June 24, 2009, 06:42:58 PM »

I'm glad (sorta) that I'm not alone.  Thankfully, it seems like it failed and doesn't change the plug (at least for me).  I'm not sure what to do next or to report to help debug it.
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #43 on: June 24, 2009, 07:19:42 PM »

I'm wondering whether there are perhaps some config files, beyond those which were disseminated, that openocd needs in order to interact with our jtag.

Of those of you who were successful at running the installer, I'm curious: Did you have a version of openocd previously loaded on your Intel box?
Logged

Rabeeh Khoury
Administrator
Full Member
*****

Karma: 5
Posts: 218


View Profile
« Reply #44 on: June 25, 2009, 02:26:26 AM »

I'm glad (sorta) that I'm not alone.  Thankfully, it seems like it failed and doesn't change the plug (at least for me).  I'm not sure what to do next or to report to help debug it.

restamp has his openocd working, he can access the processor without issues (look of last two posts from him before your post).
I suggest you cut and paste an output of what you see so people can debug and learn from the issue.
Logged

Pages: 1 2 [3] 4 5 ... 9
Print
Jump to: