General NAS-Central Forums

<EDIT>
You can get some serial console functionality via Ethernet using a netconsole.
CLUNC is a netconsole which is adapted for use on LaCie NAS products.
You can get it here.
You don't even need to open your EDmini v2 to use CLUNC .
</EDIT>

The EDmini v2 uses J2 for JTAG and serial console.
LaCie have thoughtfully pre-equipped J2 on my board with header pins
I believe that the Ethernet Big Disk uses the same board (but with the second set of SATA connectors equipped).

The J2 pinout is:
1 VCC (+5V)
2 GND
3 JTAG TMS : input to board
4 JTAG TCK : input to board
5 JTAG TDO : output from board
6 JTAG TDI : input to board
7 Serial RxD : input to board
8 Serial TxD : output from board

Pin 1 is furthest from the power connector.
UPDATE: kosmaty has kindly indicated pins 1 and 8 here: http://img524.imageshack.us/my.php?image=800pxlacieebdboardcompogk5.jpg

Note that:
I believe this information to be correct but please do not blame me if you blow up your board
In particular I guessed the JTAG from the connections to the xc9536 but I have not yet tested it

EDIT: Albert Aribaud (aaribaud) has told me that this JTAG chain seems to only include the Xilinx
So it would seem that the FLASH cannot be reprogrammed via these JTAG connections

EDIT 15/12/2010: Concerning JTAG FLASH access, Albert has subsequently told me via the lacie-nas mailing list:

Serial I/O is at 3.3V logic levels and not RS232C levels.
I am not certain that the inputs are 5V tolerant.
(I suspect that they should be as otherwise it would be stupid to put 5V on pin 1 of the connector.)
My usage of TxD and RxD is that the edmini sends on TxD and receives on RxD but this may not be standard as I have not taken into account DCE/DTE
For the serial console I used a modified DKU-5 mobile phone USB cable which works perfectly (115200, 8, N, 1 with XON/XOFF if you like but you must disable the hardware handshake (RTS/CTS IIRC or maybe DSR/DTR)).
LaCie have also thoughtfully put the security lock hole in exactly the right position to bring out the cable

EDIT: Albert Aribaud has told me that opening minicom freezes his PC when using a DKU-5 and 2.6.24.4 and 2.6.25.1 Linux kernels.
I have read a discussion about the Prolific PL2303 USB to serial chip used in the DKU-5 cables not being USB compliant.
Maybe they have removed some workaround for the quirks of the Prolific chip from the kernel.
So it looks like a combination of the Prolific chip and recent kernels should be avoided.
See Albert's website: http://tweaky.aribaud.net for details on this and other interesting articles on the EDmini V2.
EDIT 15/12/2010: The Prolific chip works for me with Ubuntu 10.10 which uses a 2.6.35 kernel IIRC.

I used a three wire connection (GND, TxD and RxD) for my DKU-5.

Here is the pinout of the Nokia connector:-
http://pinouts.ru/CellularPhones-Nokia/ ... nout.shtml

I cut off the connector at the Nokia side leaving just enough wire to determine with a ohmmeter which colours were connected to which pins.

The colours seem to vary but you may have the same colours as me if you have this model:-
http://eshop.no-ip.biz/eshop/#DATA_CABLE
(He sells on eBay too which is in fact where I bought mine.)

Taken from my (unreliable) notes the surprising colours on my cable were:-

Yellow: GND to J2 pin 2
Blue: TxD (output from the cable) to RxD J2 pin 7
Green: RxD (input to the cable) to TxD J2 pin 8

There was a fourth red wire which, from my notes, looks like it ought to be another GND.
However for me it is inconceivable to connect red to GND
So I think I just taped back the red wire.

However PLEASE check your colours.

Don't connect the EDmini at first; it is better to blow up a $4 cable than your EDmini

You should be able to identify GND with an ohmmeter to GND on the USB side.

Then with the cable connected to the USB of your PC:-
When it is static TxD (the output from the cable) will be at about +3.2 V with respect to GND.

Then with minicom (Linux) or HyperTerminal (Windows):-
You can check RxD by connecting it back to TxD on the cable and testing whether the characters you type are echoed.

When you are sure that you have GND, TxD and RxD right you can then try them out on the EDmini.
Enjoy

Other notes:
I should be interested in hearing from anybody hacking this board or the Ethernet Big Disk or the 2Big Network.

I bought mine with a dead disk and I should be interested if someone could give me a backup of the system partitions.
EDIT: I have them now thanks to aaribaud.

I have managed to install and boot the software for another NAS with fairly similar hardware (Maxtor Shared Storage II).
Serial access to uBoot is required to boot it and some functions do not work because the hardware has minor differences.

The kernel for the LaCie 2Big Network seems to support the EDmini v2 as well.
Some other Feroceon boards are supported as standard in the 2.6.25 kernels.
Is anybody working on adding EDmini v2 support to the latest kernels?
EDIT: I am now - I have created a machine type and I have posted information in another topic:-
http://forums.nas-central.org/viewtopic ... &t=76#p351

Cheers,
Chris

do we already have a picture of the Edmini v2 PCB? i would like to see one.

There are PCB pictures (and an interesting article) here:-
http://www.smallnetbuilder.com/content/view/29790/75/

Chris

added both pics to http://lacie.nas-central.org/index.php/ ... :EDmini_v2

....rosbif....i have something to test for you as soon as you have serial access.

all marvell orion based boards use the uboot bootloader...and the uboot bootloader is able to load kernels/initrds via tftp.

just hit enter to get to the uboot console and enter "help"...and post the commands here.

if "tftpboot" is there you can try to boot
http://downloads.foonas.org/foonas-em/0 ... e_2.6.25.1

this is a kernel with initramfs....nothing on your hdd/flash is touched....its just trying to boot a kernel with built in rootfs (foonas-em)

if it works it would not be that hard to add support for this machine in the vanilla kernel + foonas/foonas-em .....and debian would work as soon as the kernel.org supports the box.

EDIT: please post a dmesg from the stock kernel as well so we can post it on the wikipage.

I (knowingly) bought my EDmini V2 off eBay with no disk.
Serial access was the first thing I had to get going.
Otherwise I couldn't have guessed that by default it tries to boot a raw uImage (no filesystem) from /dev/sda6



Marvell>> help
? - alias for 'help'
FSdel - del a file from the Flash MV FS
FSdir - ls the Flash MV FS
FSformat- format the Flash MV FS
FSlef - Load an exe file to the Flash MV FS
FSlf - Load a file to the Flash MV FS
FSrun - Load an exe file from the Flash MV FS and run it
FStftp - tftp a file to the Flash MV FS
FStftpe - tftp an exe file to the Flash MV FS
FStype - cat file from the Flash MV FS
base - print or set address offset
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootext2 dev:boot_part1,boot_part2 addr boot_image linux_dev_name
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
bubt - Burn an image on the Boot Flash.
chpart - change active partition
cmp - memory compare
cmpm - Compare Memory
cp - memory copy
cpumap - Display CPU memory mapping settings.
crc32 - checksum calculation
date - get/set/reset date & time
dclk - Display the MV device CLKs.
ddimm - Display SPD Dimm Info
dhcp - invoke DHCP client to obtain IP/boot params
diskboot- boot from IDE device
dma - Perform DMA
echo - echo args to console
eeprom - EEPROM sub-system
erase - erase FLASH memory
exit - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls- list files in a directory (default /)
fi - Find value in the memory.
flinfo - print FLASH memory information
fsinfo - print information about filesystems
fsload - load binary file from a filesystem image
g - start application at cached address 'addr'(default addr 0x40000)
go - start application at address 'addr'
help - print online help
icrc32 - checksum calculation
ide - IDE sub-system
iloop - infinite loop on address range
imd - i2c memory display
imm - i2c memory modify (auto-incrementing)
imw - memory write (fill)
inm - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
ir - reading and changing MV internal register values.
ln - Load S-Record executable file through the network interface.
loop - infinite loop on address range
ls - list files in a directory (default /)
lump - Wait for a LUMP
map - Diasplay address decode windows
md - memory display
me - PCI master enable
mm - memory modify (auto-incrementing)
mp - map PCI BAR
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
pci - list and access PCI Configuraton Space
phyRead - Read Phy register
phyWrite - Write Phy register
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
resetenv - Return all environment variable to default.
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
se - PCI Slave enable
setenv - set environment variables
sg - scanning the PHYs status
sleep - delay execution for some time
snapboot -boot image from snapshot partition
sp - Scan PCI bus.
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version
wol - Enter Wake On LAN mode
Marvell>>



Tftpboot is there but I didn't try it as I have never been able to get it to work
Additionally I am having some DNS problems at the moment.
However I wrote the image to the disk ...
... and it booted
I used the bootargs "console=ttyS0,115200 root=/dev/sda8 rw mem=64m enaWrAlloc=no".
I don't know yet whether the last two are necessary
It gave me a login screen instead of a root shell so I had to Google for the login
The web interface worked too but it confirmed that I have DNS problems

Kudos to you for the great work.

EDIT : DNS is now working but I hadn't seen a bigger problem : SATA doesn't work
And yet AFAIK SATA is generic Feroceon so shouldn't depend on the board.

Would you like me to send you the boot log?

Some comments :

There was a very long wait after the "Freeing init memory" line and I thought it had crashed.
However the next line was something about JFS and I have already had problems with the lousy uBoot and flash implementation by LaCie (or Marvell ?).

I have managed to compile and boot a 2.6.25.2 kernel but I haven't managed to get the Ricoh RTC working. I don't know whether it's an I2C or an RTC problem.
Would you mind sending me your .config please?



Most things do indeed work.
It needs support for the LaCie specifics : mainly the switch, the LED, the fan and maybe a temperature sensor and the flash.
I was thinking of trying to add this myself to a current kernel.



The flash is rather small (512 KB) and just contains uBoot.
I have no original disk and therefore no stock kernel
The LaCie updates seem to be encrypted and I have been unable to compile their GPL source tree.
(Rather than wasting my time on this I have been compiling a 2.6.25.2 kernel.)
However there is a boot log for the Ethernet Big Disk here:-
http://legacy.not404.com/node/8
IMHO it is the same but with two drives : it even says it is an EDmini V2

Thank you very much for all your help.

Cheers,
Chris

kudos go to timtimred/bbradley/davy_gravy and the team payed by marvell which is porting the vanilla kernel to the marvell orion devices.

maybe read a little about foonas/foonas-em and openembedded at foonas.org. everythings available via the svn viewer or if you checkout the svn repository directly.

the defconfig + patches can be seen here (scroll down until you see "linux orion"):
http://svn.foonas.org/listing.php?repna ... nux-orion_

defconfig:
http://svn.foonas.org/filedetails.php?r ... g-2.6.25.3

what is the console log with the current kernel?

take a look at http://nas-central.org/index.php/Orion_ ... tion_guide

PS: i have just disabled any post restrictions regarding length of postings.

Discussion regarding getting a mainline kernel to work on the EDmini v2 continued at
viewtopic.php?f=146&t=76

Continue using this topic for JTAG/serial related discussions.

Strange thing. When I connect USB cable to PC, voltage between GND and TxD is very low. Voltage between GND and RxD is about +3.9V. But I have identified TxD as TxD by checking resistance between cut connector at the Nokia side and the wires. So I was able to conclude which wire is which pin(in Nokia connector) and using this http://pinouts.ru/CellularPhones-Nokia/ ... nout.shtml pinouts, I was able to identify which wire is TxD, RxD.

But using this method, voltage between RxD (6th pin of Nokia connector) and GND is about +3.9V, so it behaves like being TxD ;]. Do you have any idea where does this discrepancy come from?

The problem is deciding on from whose point of view one is considering transmit and receive
Each side receives on the wire on which the other side transmits.
I said in my original post:

The Wikipedia article http://en.wikipedia.org/wiki/RS-232 says:-

In my post I apparently considered both sides to be DTE and I assumed that both sides transmit on TxD and receive on RxD.
This means I have to cross TxD and RxD (as is done in a "null modem").

However it is probably more logical to consider the DKU-5 to be DCE (as apparently Nokia do) and therefore use a straight cable (without crossing TxD and RxD).
Then, in agreement with the Wikipedia article:-

The EDmini v2 (DTE) transmits on TxD and receives on RxD.
So paradoxically the DKU-5 (DCE) must transmit on RxD and receive on TxD.

This seems to be the case. Does it work?

Sorry for this very unclear explanation which probably only confused you further

Thank you for your answer, which is very clear for me .

One more thing: could you paint on this picture http://lacie.nas-central.org/images/thu ... _front.JPG , which pin is 1 and which pin is the last pin.

I will write here about the results in a week or two, because I have to retake some exam

As I wrote in my original post:-

At least this is what I considered to be pin 1.
IIRC all the pins have a round solder pad except this one which has a square pad.
AIUI this square solder pad indicates pin 1.

I am not sure that I have write access to the picture so I'll let someone else update it


Good luck with your exam

Cheers,
Chris

I back to the game .



It was very helpful. I have passed ...



Again, great explanation! Thank you so much for that!

But to be sure I mark these pins. Could you look at here: http://img524.imageshack.us/my.php?image=800pxlacieebdboardcompogk5.jpg . Is it correct?

Yes, this is correct.
Thanks for updating the drawing.
I shall add an update pointing to your drawing to my original post (with a credit to you of course).
I hope that this is OK with you.

Great!


I hope that this help other people .


I have +3.9V. Is it OK? My voltmeter is very cheap. So mayby this is the reason...



Is this proper echoing: http://www.youtube.com/watch?v=Y_sSb8oHD3U ?

Sorry for all these silly questions - I have no experience in electronics, but I am open minded .

This should be OK.
Someone else told me that he measured more than +3.2V.
So maybe it is my voltmeter that is wrong.
This would seem to mean that the cable uses 5V TTL levels (rather than 3.3V as I thought).
However it works fine for me and nobody has complained of any damage yet.
Plus I guess that the EDmini v2 inputs will be 5V tolerant as there is definitely +5V and not +3.3V on pin 1 of the J2 connector.


Yes, it looks correct to me.
Now you just have to hook it up to your EDmini v2, cross your fingers and (hopefully) enjoy

Cheers,
Chris