• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  General Category / Success stories / Re: OpenRD SATA mostly working with SIL3726 port multiplier on: February 05, 2011, 05:51:58 PM
For future refrence, I posted patches to get the 5th drive working a while back.

They can be found here: http://groups.google.com/group/openrd/browse_thread/thread/27745b2d1f483326/9bb088afbf94b0be?lnk=gst&q=jlinton#9bb088afbf94b0be

2  Hardware and U-Boot firmware / U-Boot stuff / Re: Trouble writing U-Boot to OpenRD on: February 05, 2011, 05:49:22 PM
As a FYI, I think the "issue" reported here http://code.google.com/p/openrd/issues/detail?id=7 may be related to the problem some people were having reflashing uboot on some of the boards.
3  General Category / General Discussion / guruplug quick setup for USB serial console win7(64-bit) on: May 15, 2010, 11:32:18 PM
Ok, as it took me a couple hours to work this all out here is the sequence to get the guruplug usb/jtag/serial port working on a win7 machine.

  • If your running win7 64-bit reboot the machine. Right before the windows splash screen comes up start pressing F8
  • When the menu shows up, select "disable driver signature checking" (you might be able to try bcedit test signing after everything else is working)
  • Connect the 4 wire cable between the port labeled UART on the jtag board to the guruplug.
  • Make sure the jtag board switch is set to UART
  • Now connect the JTAG cable
  • Download the 2.06.00 driver package from http://www.ftdichip.com/Drivers/VCP.htm (2.06.02 might work too, I wanted the signature to avoid all the win64 crap, but the vid/pid doesn't match the cat signature)
  • uncompress it to a folder
  • Plug in the guruplug
  • Plug in the jtag USB cable betwen the jtag board and the computer
[
  • Start the windows device manager, you should see two sheevaplug FTDI devices in error state
  • Right click one of them and say "Update driver software"
  • Select "Browse computer.." then "Let me pick.." then "have disk"
  • Then select "ftdibus" from the folder you uncompressed the driver package to
  • Then select "USB Serial Converter" from the list, it should be near the top
  • Accept all the warnings about it being the wrong driver, etc...
  • This should change the device to a "USB Serial Converter"
  • Repeat the process for the other FTDI device
  • One of these two driver updates should have created a new USB COM device in error state
  • Right click that device and go through the process except select the ftdiport from the uncompressed image
  • Then select the last device type of "USB Serial Port" from the list
  • This should enable the device in device manager as COM(x)
  • Start PUTTY (google for it if you don't have it). Select "Serial", type something like "COM3" (per the previous step)
  • Change "speed" to "115200" and click "open"
  • Then press enter a couple times, you should see the login prompt for the guruplug
  • The root password is the usual "nosoup4u"
4  Hardware and U-Boot firmware / U-Boot stuff / Re: Trouble writing U-Boot to OpenRD on: May 15, 2010, 10:39:49 PM
Dope, looks like someone found the problem that keeps the nand from being detected. Look at http://code.google.com/p/openrd/issues/detail?id=7

5  General Category / General Discussion / Re: GuruPlug - Received Yours Yet? on: May 15, 2010, 10:33:42 PM
I recieved mine last fri, after calling them because I ordered mine in feb. I just now plugged it in and spent an hour scratching my head/screwing with drivers about how to get the jtag/serial working with win7 64. Eventually I went back to the VM of suse that I used for my openrd last year. At that point It came right up.

I think globalscale could help us all out, with a reasonable quick start card, and a couple pointers to the correct locations to download the docs/kernels etc. I guess I was spoiled because the openrd came with a CD full of information (some of which was wrong). It forms a starting point, there is a quick blurb on the plug computing wiki about connecting to the guruplug over wifi, that probably should be in the box instead of the stupid registration card.
6  Hardware and U-Boot firmware / U-Boot stuff / Re: Trouble writing U-Boot to OpenRD on: February 22, 2010, 02:39:12 PM
You can see my previous post at http://plugcomputer.org/plugforum/index.php?PHPSESSID=ee324a737c9ea3286bc01fef84fd9090&topic=1126.msg6854#msg6854

You might try 0xF2000000, which if I remember correctly is the address linux claims the NAND_CS is at. That might be a virtual rather than a physical....



7  Hardware and U-Boot firmware / U-Boot stuff / Re: Trouble writing U-Boot to OpenRD on: February 20, 2010, 02:36:20 PM
I had similar problems with the openRD-client board. If you start an interactive session (using one of the versions that gets as far as claiming the NAND manufacturer is 0x0) that RAM locations actually update when you write/read them. The NAND flash section is playing a standard NAND sequence, and it should wake up the NAND and start responding with something other than 0's. I gave up with OCD after messing with it for a few hours but, I suspect that the NAND address in the default config file is wrong.
8  Linux Stuff / Kernel / Where do 2.6.22.18 Feroceon patches go? on: January 04, 2010, 04:32:25 PM
I have a patch to the 2.6.22.18 kernel? Is there a recommended location to post it?

Is anyone rolling new versions of that kernel, or is the focus strictly on the orion kernel?

9  General Category / General Discussion / Arggg.. The state of openOCD on openRD on: December 20, 2009, 10:02:36 PM
I finally recovered my openRD's uboot after 15+ hours of hell with openOCD. In the end I managed to fix it without openOCD....

So, this leads me to my first question. Have other people managed to flash an openrd's uboot using openOCD?

The short list of problems I had were:

    * The "official" version on the CD/download is statically bound with libUSB keeping it from being able to detect the ftdi device on many (most) recent version of linux. (This is caused by libUSB not understanding how to probe USB devices)
    * The openrd.cnf file only works with a fairly narrow range of openOCD versions, and the version it works with is ancient.
    * Finally, the worst problem is that the addresses in openrd.cfg (openrd_init and nand device) appear to be totally wrong.



So, after compiling every version of openOCD from the CD, to the latest GIT, porting the openrd.cfg file, etc. I started poking around by hand on the openOCD command prompt. What I discovered was this..

OpenOCD appeared to be working just fine after I built it using a recent version of libUSB. I could manipulate memory, read processor registers, Set assorted states, etc.

What wasn't working was the whole openrd_init process of writing to registers at 0xD0001xxx. That whole memory region appeared to be invalid. Same for the nand device at 0xd8000000. Running a `nand probe 0` with the given information simply returned 0's and caused an error because openOCD couldn't detect the device type.

The openrd.cnf file has a nice comment "this assumes the hardware default peripherals location before u-boot moves it". Along with the comment in the manual about running the script immediately after a power cycle, makes me think that might have been exactly what was happening. Only, I never successfully managed to detect the nand no matter how fast I power cycled and tried to halt the device.

This leads to my only real question. Assuming the addresses are incorrect, what are the correct addresses post uboot? Can they be dynamically detected from whatever register is being used to move the nand device? Does such a register exist? (I didn't find anything in the open documentation, I guess I might have to try and get the restricted version). Why, if uboot moves the nand, isn't there a comment indicating likely locations after the move?

Finally, I guess it could be some form of flash write protection bit, that keeps the device from responding to the wakeup sequence, but why was the device protected?

Bah, what I learned is not to screw around with uboot on a $250 openRD client, get a cheaper device (cause it will likely become a paper weight), or get openOCD's flash functions working stability before experimenting with uboot.
10  General Category / General Discussion / Re: SATA hard drive spin down on: December 15, 2009, 09:14:25 AM
MarkF: Yes, the drives spin back up. This is simply an ATA STANDBY IMMEDIATE. This spins them down, but leaves the controller active. The controller will automatically spin them back up for the next read/write.

Jon3s, In my case hdparm simply doesn't work, it fails because the marvell driver isn't integrated well with the kernel libata interfaces. This is what happens when I send hdparm -y.

/sbin/hdparm -y /dev/sda

/dev/sda:
 issuing standby command
SG_IO: bad/missing ATA_16 sense data::  72 05 20 00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing ATA_16 sense data::  72 05 20 00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 HDIO_DRIVE_CMD(standby) failed: Input/output error


I'm going to upgrade to a newer kernel, and if it still fails probably patch the driver. I suspect that hdparm and sg_start should be working in more recent kernels.

11  General Category / General Discussion / SATA hard drive spin down on: December 14, 2009, 11:36:43 PM
For spindown control, sg_start and hdparm don't appear to work with the default 2.6.22 kernel. To work around this, I've written some code using the old SCSI_IOCTL_SEND_COMMAND ioctl. This is the same ioctl smartctl uses with the -D marvell option. A quick look at the mvSata drive shows that it supports some other commands as "vendor specific". Including the ability to spin down a SATA drive.



Code:
/*
 * spindown.cpp
 *
 * spins down hard drives attached to the marvell sata controller on a kirkwood
 *
 * Copyright (c) 2009 Jeremy Linton
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 */

#include <stddef.h>
#include <scsi/scsi_ioctl.h>
#include <scsi/sg.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

int marvell_command_interface(int device)
{
typedef struct
{
int  inlen;
int  outlen;
char cmd[540];
} mvsata_scsi_cmd;

mvsata_scsi_cmd  stop_command;
unsigned char *buff = (unsigned char *)&stop_command.cmd[6];

memset(&stop_command, 0, sizeof(stop_command));
stop_command.inlen = 540;
stop_command.outlen = 540;
stop_command.cmd[0] = 0xC;  //Vendor-specific code
stop_command.cmd[4] = 6;    //command length

buff[0]=0xE0; //ATA_COMMAND_STANDBY_IMMEDIATE;

if (ioctl(device, SCSI_IOCTL_SEND_COMMAND, (void *)&stop_command))
{
printf("failed to send ioctl\n");
        return -1;
}
return 0;
}

int main(int argc,char *argv[])
{
if (argc!=2)
    {
printf("Use like %s /dev/sd[x]\n",argv[0]);
}
else
    {
int fd=open(argv[1],O_RDWR);
        if (fd!=-1)
        {
if (marvell_command_interface(fd)==0)
            {
printf("Successfully spun down %s\n",argv[1]);
}
            close(fd);
}
else
{
printf("Failed to open %s\n",argv[1]);
}
}
    return 0;
}

So given this utility you can spin down a drive like ./spindown /dev/sda
12  General Category / Success stories / OpenRD SATA mostly working with SIL3726 port multiplier on: December 12, 2009, 10:19:08 PM
I looked around a couple weeks back to see if anyone has gotten the openRD to work with a SIL3726 port expander and I didn't find anything conclusive. So I'm here to say it "works" with the default 2.6.22 kernel that came on the device. By that, I mean it sees hard drives on the first 4 ports. The 5th port is somewhat of a mystery as the device seems ok and comes online but the mvSata driver never discovers it. For future reference I'm using the Sans Digital TR5M-B. I plan on upgrading the kernel and turning the mvSata debug logging on to see if I can discover why it doesn't work with the 5th port, as nothing obvious in the code seems to limit it to 4 devices.

So, now my big disappointment is the fact that the sans digital consumes 12 watts(!) totally idle without any drives plugged in. That power seems to be broken down as ~1 watt for the large cooling fan, 6 watts for the multiplier board, of which the primary thing on the board seems to be the SIL (which is getting fairly warm). The power supply with a little 1 watt cooling fan consumes the remaining 5 watts plugged and running with everything disconnected. Its a 250W power supply and I'm running the Seagate LP drives which seem to consume about 5 watts "idle" and ~15 watts at spin up. I might try switching out a low power supply in the near future. Nothing in the open Sil documentation would seem to indicate that its power usage is that bad.

Also, as hdparm doesn't seem to work, I hacked up a little utility to force a hard drive to spin down when using the marvell driver. This drops the power usage from ~5watts per drive to ~1 watt. I will put the code to do that in another posting.
Pages: [1]