bodhi Wrote:
-------------------------------------------------------
> Hi xssa,
>
> The SATA 2nd port LED trigger is already supported
> in the kernel with my patch for the SATA driver.
> But the T5325 has only one exposed SATA. Now that
> you and CV have the 2nd SATA :) However, it seems
> that the T5325 SATA LED is hardwired (I did not
> need to do anything in the DTS for it to blink).
>
> It is good that you've verified that hardwired
> only to the SATA port 0! I don't know yet if it is
> good or bad news, but I'll do some investigation
> to see if there is anyway to activate it.

I gave this a shot, but could not find the gpio that can turn on/off the SATA LED. Even for the STATA port 0! actually, no LED, except the Power LED, can be manipulated.

It is apparently hardwired. If you can, examine the board SoC pinouts with magnifier, I think it would confirm this.

xssa Wrote:
-------------------------------------------------------
> @bodhi
> I have one with stock and ssh running well. There
> was some trick to enable it. I'll look for...
>
> To enable sshd you have to remove file
> /etc/ssh/sshd_not_to_be_run
>
> There is a code fragment from /etc/init.d/ssh who
> deal with it
>

Nice! but that's not gonna do it for me right now. To see that /etc/ssh/sshd_not_to_be_run file I will have to be inside stock OS.

Currently, I can boot stock OS, but have no console for input (lost serial console input after stock OS booted). It's a catch-22. Something in stock OS always disable the ttyS0 console after booted. So I thought if I can ssh in, then I can see where that ttyS0 console was disable and restore it.

I guess I'll have to connect a monitor and a keyboard to actually fix this. Something I'm not looking forward to (I donated all my old VGA monitors and PCs long ago). I'm traveling light :).

syong Wrote:
-------------------------------------------------------
> @bodhi,
>
> From xssa's overlayfs idea, we do not need ssh to
> enable serial console on the stock os.
>
> Just do this as root:
>
>

I have owned and hacked my t5325 for a couple years now and had it running fine under Squeeze.

I have it running with an internal 16GB SSD from it's internal 2nd SATA port - actually a SATA to mSATA/PCI-E adapter with a half slim 16GB SSD inserted.
As discussed earlier, I had to add the 4 missing capacitors and add in a SATA lead/connector, which IIRC came from a Toshiba Tecra M5.

I recently tried to install Debian Jessie and hit a wall (as normal).
Anyways, with Google's help and this forum post I have managed to glue a vanilla Jessie into the 16GB SSD.

So, this post is to encourage others, to give back some of what I have got from others and remind me of what I have done (I'm getting old and forget stuff !!) .

With a serial connection to the t5325, stop uboot (you have to be very quick to catch it the first time) and enter the following (make the IP addressing suit your environment) as I use tftp to load the 2 files. It's also possible with a USB stick with FAT format and the 2 files copied to it, but needs a few different setenv commands, but anyway...

You can see some of the other hacked settings I've used and to remove them, issue a setenv <command>
with an ‘empty’ variable and it will remove the line.

Also, resetenv – resets all of the u-boot variables back to factory default – use with caution as some settings are lost e.g. your MAC address! Although this can be added back with setenv ......

I leave the serial lead permanently connect and hook in an FTDI serial adapter when needed.
I also added a foot from an old Shuttle mini PC.
Not bad for an all up price of a Raspberry Pi (not counting endless hours doing battle with it!).

With my t5325 I can make it run from the original 512Mb drive (sda) by running the 'thinpro' boot command.

I also have an HP T5745 with a 120Gb SATA SSD attached internally (Intel Atom), a 10zig (Intel Atom) with 16Gb internal SSD plus a couple other hacked devices, including a Wyse H12v (Kirkwood 1.2GHz) but it's a SOB with Chrome 9 graphics and will not run in a Debian desktop, so it's resigned to a portable command line only machine.

devonian Wrote:
-------------------------------------------------------
> Yes, I 'power read' the thread and cherry picked
> the bits I needed and thought I'd contribute a
> little as a way of giving back something and not
> just taking.
>
> I've fought this little box 'bout enough as it is
> ;-)

Ethernet LED..
Yes, I have serial console. (ower BT module, and TTL serial cable also)
Netconsole not work on the first one, because stock uboot..
..(on the second one, because no net) ..

I tried Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 + linux-4.9.0-kirkwood-tld-1-bodhi.tar.bz2 / linux-4.10.0-kirkwood-tld-1-bodhi.tar.bz2 / linux-4.5.0-kirkwood-tld-1-bodhi.tar.bz2 with no success.
Uboot env "machid ffffffff" is set, and all as I see is " Uncompressing Linux... done, booting the kernel. "

bodhi Wrote:
-------------------------------------------------------
> > http://195.28.90.62/dohc/ostatne/hpt5325/t5325_b
> oo
> > t_zImage_dts_inside_kernel.txt
>
> It is not easy to read this log. It got cut off an
> d missing text in many places. Can you copy and pa
> ste the log to your post and put it in code tags?

Thanks for answer bodhi.
Don't care about uboot env, it is modified many many times, for testing use..
and i try too much kernel and init versions, today I have booted your FS and Kernel successfully..
..but, LAN don't work ...

The common problem is there ..

[ 0.160973] [Firmware Info]: /ocp@f1000000/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set
[ 0.166712] No ATAGs?

..I think ..
My router have no APR record from marvell LAN also ..

I will try to copy MX Flash from "working one" into this "bad one"
(cause working one have stock uboot, and "stock" uboot env & HP env)
I try to work with this... for a last time ..

JRD McLAREN Wrote:
-------------------------------------------------------
> OK,
>
> I try to back serial flash image, uboot and envs
> and then try to boot with working LAN.
> If they don't wok, then it will be a hardware prob
> lem ..
> ( ..and I trash this device .. )

Don't trash the box! This is a common problem with rootfs. You can solve it. It is very unlikely a hardware probkem.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.