General NAS-Central Forums

Welcome to the NAS community
It is currently Mon Nov 24, 2014 6:33 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu May 08, 2008 12:32 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
<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:
aaribaud wrote:
You must use the connector J11 I think -- that's the only other 8x1 connector on the board. Pinout is:

pin 1: 3.3V
pin 2: Gnd
pin 3: TMS
pin 4: CLK
pin 5: TDO
pin 6: TDI
pin 7: SRST
pin 8: RESET


To make things clear: J2 has the console and the Xilinx JTAG, and J11 has the Marvell SoC JTAG.

I have not investigated the J2 Xilinx JTAG, and know of no way to access the Flash through it.

I have investigated the J11 SoC JTAG, and while it does not provide direct access to the Flash, it provides access to the SoC debug port, which allows accessing the Flash using OpenOCD in two ways:

1. Direct OpenOCD reads and writes to the Flash address area (caveat: right after reset, the Flash CS settings put it at 0xF8000000, not at 0xFFF80000. You must read or reprogram the BOOT CS registers if you want to be sure where the Flash is located). You can even program the flash that way, following the write sequences in the Macronix datasheet, but it takes ages.

2. Indirect flash programming: build a RAM-based U-boot for edminiv2 (for RAM-based, you need to skip critical inits, by #define'ing CONFIG_SKIP_LOWLEVEL_INIT in include/configs/edminiv2.h) and use OpenOCD to load and execute U-Boot. From U-boot prompt, you will be able to read and reprogram the Flash at will.

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


Last edited by rosbif on Wed Dec 15, 2010 5:58 am, edited 8 times in total.

Top
 Profile  
 
PostPosted: Fri May 09, 2008 8:39 am 
Offline

Joined: Thu Mar 06, 2008 12:23 pm
Posts: 58
Location: Vienna
do we already have a picture of the Edmini v2 PCB? i would like to see one.


Top
 Profile  
 
PostPosted: Fri May 09, 2008 2:24 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
There are PCB pictures (and an interesting article) here:-
http://www.smallnetbuilder.com/content/view/29790/75/

Chris


Top
 Profile  
 
PostPosted: Sat May 10, 2008 9:49 am 
Offline

Joined: Thu Mar 06, 2008 12:23 pm
Posts: 58
Location: Vienna
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.


Top
 Profile  
 
PostPosted: Sat May 10, 2008 2:55 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
mindbender wrote:
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.


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 :(

mindbender wrote:
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.


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>>

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


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?

mindbender wrote:
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..


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.

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


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


Top
 Profile  
 
PostPosted: Sat May 10, 2008 3:57 pm 
Offline

Joined: Thu Mar 06, 2008 12:23 pm
Posts: 58
Location: Vienna
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.


Top
 Profile  
 
PostPosted: Mon May 12, 2008 10:19 am 
Offline

Joined: Thu Mar 06, 2008 12:23 pm
Posts: 58
Location: Vienna
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.


Top
 Profile  
 
PostPosted: Wed Aug 27, 2008 9:05 pm 
Offline

Joined: Sat May 17, 2008 2:57 pm
Posts: 32
rosbif wrote:
Here is the pinout of the Nokia connector:-
http://pinouts.ru/CellularPhones-Nokia/ ... nout.shtml


rosbif wrote:
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.



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?


Top
 Profile  
 
PostPosted: Thu Aug 28, 2008 8:30 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
kosmaty wrote:
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:
rosbif wrote:
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 :(

The Wikipedia article http://en.wikipedia.org/wiki/RS-232 says:-
Quote:
Transmitted Data (TxD)
    Data sent from DTE to DCE.
Received Data (RxD)
    Data sent from DCE to DTE.

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 :(


Top
 Profile  
 
PostPosted: Sat Sep 06, 2008 1:21 pm 
Offline

Joined: Sat May 17, 2008 2:57 pm
Posts: 32
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 :P


Top
 Profile  
 
PostPosted: Sat Sep 06, 2008 6:00 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
kosmaty wrote:
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.

As I wrote in my original post:-
rosbif wrote:
Pin 1 is furthest from the power connector.

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 ;-)

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

Good luck with your exam ;-)

Cheers,
Chris


Top
 Profile  
 
PostPosted: Fri Sep 26, 2008 11:36 pm 
Offline

Joined: Sat May 17, 2008 2:57 pm
Posts: 32
I back to the game :).

rosbif wrote:
Good luck with your exam


It was very helpful. I have passed :D ...

rosbif wrote:
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.


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?


Top
 Profile  
 
PostPosted: Sat Sep 27, 2008 7:10 am 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
kosmaty wrote:
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.


Top
 Profile  
 
PostPosted: Sat Sep 27, 2008 5:15 pm 
Offline

Joined: Sat May 17, 2008 2:57 pm
Posts: 32
rosbif wrote:
Yes, this is correct.

Great!

rosbif wrote:
I hope that this is OK with you.

I hope that this help other people :) .

rosbif wrote:
When it is static TxD (the output from the cable) will be at about +3.2 V with respect to GND.

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

rosbif wrote:
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.


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 :) .


Top
 Profile  
 
PostPosted: Sat Sep 27, 2008 5:41 pm 
Offline

Joined: Thu May 08, 2008 11:23 am
Posts: 112
Location: near Toulouse, France
kosmaty wrote:
rosbif wrote:
When it is static TxD (the output from the cable) will be at about +3.2 V with respect to GND.

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

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.

kosmaty wrote:
rosbif wrote:
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

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

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group