Hi,

I just thought I would see if v.27 uboot fixed my troubles. 

Unfortunately it gives a new  (to me)  error:-

This is using a 8GB Kingston SDHC card, 

uboot v.23  also fails but in a different way,  it does not return  ANYTHING after a ext2load, except for the next Marvell>>> prompt but performing a ext2ls command returns the / structure and also the uImage file.  (command >>>  ext2ls mmc 0:1 /boot  returns uImage)

just my 2c's worth

I am going to fdisk and mk2fs the card again, put a deb rfs on it and a uImage and try again.


EDIT

Re tried above with same card no change same error on 3.4.27

Found an old copy of 3.4.19 uboot, installed using bubt.

Did same test again, using same card and same rfs and uImage  ..... uImage now loads OK and runs OK !

regards

Patrick

Hi

As Sheeva plug computer sales rise and rise, it is becoming patently obvious that the number of purchasers / developers suffering  software, mainly firmware problems is also growing.

It is not clear to me, who, (if anyone),  has the responsibility for maintaining  Sheeva plug and Marvell specific software or patches.

It is obvious that the Sheevaplug U-boot firmware is  suffering from several major and persistent faults.

Take a couple of minutes and Google around, you will find many complaints about very similar problems.

Every time someone posts a topic  or this forum with a U-boot problem,  a number of other SheevaPlug users or Marvell staff kindly jump in and offer advice.

Next day, another new topic is  started with the same problem!  Just read through the U-boot forum!

THIS IS NOT THE WAY to control this situation, shortly it will overwhelm the good natured helpers.   Also people bought this dev kit to develop their applications, not to have to use their resources  to debug and repair the internal firmware.

What is needed is:-

1.  A Sheevaplug bugzilla reporting system, that should be used to log and report all firmware and software problems

2.  A proper response by Marvell and Globalscale to provide timely resource to analyse, (severity level),  clear (fix) problems and keep the bug list CURRENT.

A public bugzilla will save a huge amount of repeated effort on the part of the dedicated volunteers on this forum.

If this is not done, then the extra sales generated by the PR effort recently may be in fact counterproductive for Marvell, as the number of dissatisfied  users rise.  Make no mistake, there are people out there who not happy bunnies at this time.

YMMV 

regards

Patrick

@ccp

Yes MY Kingston 4GB card works fine as well!

Does YOUR Kingston 8 GB SDHC(6) card work ok?

cheers

Patrick

Hi,

I am getting so frustrated.

I have been running my esata modified plug very successfully on a 8GB Transcend class 6 SDHC card although several times I have had to  reformat and rebuild the RFS due to errors induced in the card due to mechanical disconnects and power offs, and even finger trouble on my part.

I run the plug  from a kernel and RFS on the SDHC card, using the Esata drive as a data store only.

I bought two Kingston 8GB class 6 HDSC cards  so I could do a rotating 3 card backup. I prepared the two new cards EXACTLY as the Transcend card.  I thought that this would then save time if I  corrupted my working card, I could just swap to a new card and re-clone the failing card at a more convenient time.

Was I ever wrong!... I have spent (wasted) days trying to get the Kingston cards working!

My working boot commands would not load uImage  from /boot/uImage on the  new  SDHC cards.  (the reported error was could not find /boot/uImage, followed by the infamous bad magic number, but the prime fault is that uboot could not load the uImage).

Even trying this manually, with lots of mmcinits  before the ext2load  command did not work, nor did  power off/on uboot reset and all the other advice given here.

HOWEVER   using:-     ext2ls   mmc 0:1 / boot    returns  "uImage"  !!!

Why has uboot an aversion to doing a ext2load on the Kingston cards, (my Transcend works fine!)

Several years ago I  did some work with an Atmel NGW100   ref design, a small module with two NICS, USB and an SD card.  There was lots of problems at the time with SD card support on the Atmel Uboot, it was very very picky over which manufactures' cards it would work with and the size of card, (sub 1gb only).  I had hoped by now that things had improved, and Uboot and SD cards was more robust.

Unfortunately looking at the Plug forum  and Googling "bad magic number" for example it seems that on many embedded systems, using uboot and SD cards, things are still very flakey.

I am a little suspicious of  the output of the mkimage utility.   ASAIK  mkimage applies a "header" including a CRC, to the compiled kernel binary thus:-

I did a mkimage -l on my modified uImage on my x8s box I cross compiled on and it returned


The parameters for mkimage are buried somewhere in the cross compiler, so I haven't changed them.  Note that the uImage load and entry address is set to 0x08000 I am using 0x80000. It did not appear to make any difference using the Transcend, so why should it make any odds to the Kingston.

Accordin to the Kingston PR blurb, it is supposed to be using wear levelling. Not all SDHC cards do this. I can find no mention of wear levelling in the Transcend literature.   Is there a timing problem ?

If the Kingston does employ wear levelling, then I suppose that there may have to be an additional level of lookup tables in the  Kingston control chip, although it might only be slower on a write to sdhc memory, the cell address would then be in the lookup table for the read.  It is a pity that the SDHC manufacturers guard this info so closely, it would be nice to find out what is really going on!

Please can anyone suggest why the Transcend works on ext2load and the Kingston doesn't?  and why does ext2ls work OK on the Kingston, showing that uboot CAN find the file if it wants to?

regards

Patrick


 

@jlpoole

Hi,

Please re-read my last reply.  I had already  installed xpl-perl and got 2/3 of the chain working:-


If you really want to add value,  can you advise me  how to find a particular Perl Plug-in,  Catalyst::Plugin::DefaultEnd. It is not called out in the Makefile.PL.   (It must be referenced somewhere else, but I am b******d  if I can find it). I need to find out how it was used and how the new module Catalyst::Action::RenderView 0.11 works in its place.

FYI Here are snips from the Deb  Perl change log:-


I have crashed my SD card, before backing it up, so I have lost the verbatum error message from the compile. I am presently attempting to rebuild the system, xpl-perl and Zenah on another card, and will try to record the error if it occurs again.

cheers

Patrick

hi fun.

I have d/l'd it. I will try it on my Plug when I can, busy now with xPL-perl, Rfxcom, Oregon sensors and the Sheevaplug

BTW What kernel are you using?  Does it support sata drive?

regards

Patrick

Hi

Thanks for the pointer, I have already been using that site as one of my references.

It is very slow going, I have been, and still am in Debian dependency hell! I was hoping someone had already sorted them out.

I want to use xpl perl  to collect, log and display data from  rf Oregon weather sensors, using a USB output Rxfcom receiver and the Sheevaplug. I know I could buy  Meteohub, but that comes as a complete sys and app image, which I do not like and it is expensive in UK with our pound/Euro rate.  I also want to run other server apps concurrently, and the Meteohub is too restrictive.
 
There is also an XPL perl interface for my Currentcost power monitor.

So far I have managed the first two, i.e. collect and log data using the Currrent cost as a data source.  I can check the data against another logger running on my desktop Linux box, easier than sitting here tipping the rain gauge bucket to create data!

I am struggling with the display part, using an XPL web app called ZENAH.  This uses a lot of perl modules, one in particular used in Catalyst (sp)  has been depreciated and removed from the perl package.  I am trying to contact the Zenah developers, to find a solution, but the bug reporting process and dev list is currently locked due to a spam attack!

I will post any progress later.

cheers

P

@cbxbiker61

Hi, 

Attached is a file openrd_base-setup.c, from the  Marvell Orion git

I found all the references  to sata, and modified the sheevaplug-setup.c to be similar, cross compiled using the modified sheevaplug setup, installed the kernel  and my plug uses the sata drive now absolutely fine!

The "data buffer" maybe that was a bad expression,  I was referring to is here, ( from openrd_base-setup):-


cheers

Patrick

Hi cxbiker61

You did say " This kernel should theoretically support the OpenRD.  Anyone care to give it a try?"

Did you compile it with sata support?

I tried it in my modified sheevaplug (with sata enabled), booted and ran fine, but could not find the sata drive.   

The openrd base and client both have a sata drive mount on the board and an Esata connection for external drives, so really to support the OpenRd  the kernel needs sata driver and data buffer compiled in.

cheers

Patrick

Hi,

What I did was to use the Marvell Orion Git repository  and cross compile a kernel.

I opened  orion/arch/arm/mach-kirkwood and compared openrd_base-setup.c with the standard Marvell sheevaplug-setup.c.   There are a few 3 or 4, cannot remember exactly,  extra lines to add

I then edited sheevaplug-setup.c to include the necessary additions for the Sata

I have attached my modified sheevaplug-setup. c to this reply  as *.modified. DO NOT get it confused with the official sheevaplug setup file!!!!!!
 
I then followed the instructions here:-

http://plugcomputer.org/plugwiki/index.php/Compiling_Linux_Kernel_for_the_Plug_Computer

use the cross compiling section.

cheers

Patrick

Hi

The title says it all.  Has anyone installed / used xPL Perl on their Sheevaplug?

thanks

Patrick

@ Guai888

Great stuff, I am glad you got it working ok!

@Ralf

Question 1 Parts cost  Very little!   However I over-ordered all the components, from Mouser in the us, i.e. needed 2 ordered 10 etc,
402's  C's
0.1u 16v  £0.034   10 off
0.01u 16v £0.069   10 off
1u 10V      £0.346   5 off
603 ferrite  £0.076  10 off
Connector   £0.809    2 off

You definitely NEED the proper tools. It is not impossible to solder these little components with the right tools, especially a magnifier, but it is hard.

The MAJOR problem is cleaning the lumps of solder off the vacant pads, without removing the pads by accident. On the 4 caps in the pi filter, one end of the caps is the 0v ground plane. This sucks all the heat out of your dewicking braid and soldering iron. I have a 90w rework iron with a 0.2mm radius tip, it struggles to get the heat into the braid.

Here is the URL of a video showing soldering of 0402 components:- www.youtube.com/watch?v=66GV4OuShzI

When you look at the video, remember the pads in this video are CLEAN with no great lumps of solder!  When GlobalScale manufactured the Plug boards they used a "common" mask, so all the unused pads were covered with solder paste, so when the board went through the oven, the paste fused into lumps on the unused pads. It is hard to balance a component on two solder mountains!

The connector is  easy to solder.

I have no idea who or how much they would charge to solder  8 0402 caps, one 0603 ferrite and  one connector.

So you see not a lot, What was expensive was the Fedex charge from the states, (I could not find the connector in the UK) I think the carriage was £12.00

Question 2 Port multiplier   Don't know, haven't tried one, I don't see why not, its a standard sata port, SATA 2 with bags of bandwidth, if you have one lend it me and I will try it  !

Question 3   Have you looked at www.openrd.org?  You can get the specifications there.  There seems to be a preference for OpenRd-client units,   NEW IT is selling them in the uk at the moment.   

A really think that it will not be long now before we can buy a version of the Sheevaplug with E-Sata as standard. 

see the post:- http://plugcomputer.org/plugforum/index.php?topic=1046.0

Good luck

Patrick

Hi,

Very interesting.

Some time ago there was a big project:- www.nas-central.org to put an open version of software on BUFFALO NAS boxes, (they used a Marvell SOC!). About the same time Kuro produced an open version of the Buffalo NAS, for the Japanese DIY market, it was known as the KURO-BOX.  They were extremely difficult to obtain outside of Japan, there was a US vendor:- www.revogear.com, but they never seemed to have stock.

Unless Kuro have changed their operation, it may be as difficult to obtain the Kuro-Sheeva plug.  HOWEVER!

There are now two vendors of E-Sata equipped  Sheevaplugs.  (Ctera being the other).  Neither of these vendors are buying standard units and fitting the extra components and plug as I have done, the cost would be prohibitive.

I am sure GlobalScale have a E-Sata equipped version in production for OEM's, orderable on request in volume!

I am sure if NewIT or another retailer were to approach GlobalScale with a bundle of cash, then we could see an E-Sata version on the market very soon!

BTW  Completely OT, I see NewIT are stocking OpenRD-client units cased at this time for £189 (inc vat).  This has 2.5in on board Sata connector and mounting location and a second E-Sata connector. Unfortunately that is getting a bit rich for an elcheapo low consumption system,  esp. a system with no FPU. The Pcie video card and the drive bump the power up a lot as well.

Obviously it all depends on your applications.

cheers

P


Edit for clarity

Hi Paul,

It looks like you have all the components OK.  You are so nearly there!

Question is:- are the components connected properly (soldered in OK) ?   I got that error when I started, I found I had not soldered one end of one of the series decoupling capacitors properly. It was waving in the air. Resoldering it fixed the problem. 

Read my previous reply again!

How and what drive have you got connected?

If it is in an external enclosure, how are you powering the sata drive?  Try switching the power to the sata drive  off and on.

Have you checked the esata cable is properly plugged into your enclosure?

Try the drive bare with an  external supply  THAT IS THE BEST WAY TO  TEST THE  SHEEVAPLUG SATA CONNECTION

Good luck

Patrick

@Guai888

Hi,

You are 50%  complete now.

The Marvell SOC sata section is alive and well!

It looks like the communication between the drive and the Soc is not OK

There appears to be a problem either

1. Between the Marvell Soc and the esata connector  ( i.e.  the 4 serial decouple caps, or the esata connector soldering)

2. Esata cable and sockets.  I found the Esata / esata cables I had purchased had very thick plastic grips on the connectors which would not allow the pins of the connector to enter the sockets fully,  I had to trim back the plastic surrounding the esata sockets on both my drive enclosures' end plates, to allow the esata plug to make contact properly.

3 The sata device you are connecting to the esata connector    What have you got connected?    I found that one of my cheap external enclosures would NOT work with the Esata connection at all, the other only connected after removing / replacing the 5v power connector several times, or unplugging / replugging the esata cable.

I found the PREFERRED way of testing the sata channels was to connect a sata drive, bare, directly from the sata connection on the drive to the esata connector on the sheevaplug, using a Sata to ESata cable I had in my spares box, ( it was a 1 metre cable but worked fine).  I powered the drive from a small 5V 12V power brick and a sata drive power connector.
This eliminates the possibility of your esta enclosure not being "compatible" with the Sheevaplug

I am convinced a lot of the  cheap enclosures  although fitted with USB and Esata ports do not function with Esata properly. I think there may be issues between Sata 1 and Sata 2  standards and speeds.  I went as far as purchasing a Antec enclosure, nearly £30 retail, this connects to the Plug first time every time, with no need to pulse the power or esata
cables

YMMV

good luck

Patrick