Transfer of kernel via u-boot fails

[redbeard]

Hello, I want to start by thanking you all for your efforts to provide a free alternative firmware for LaCie devices (and others).

I am following the instructions for fvdw-sl-console 6-0 + 17-0 firmware (on Windows 10) to install the fvdw-sl firmware on my Cloudbox. Unfortunately I am running into a rather odd issue that I have not seen mentioned anywhere else on the forum.

I am using a new storage drive (Samsung 850 PRO 512GB SSD) and have done the following:

Disabled anti-virus
Disabled firewall
Disabled all extra network adapters (including Wi-Fi)
Double-checked DHCP lease range (192.168.1.6 - 192.168.1.254)

When I run fvdw-sl-console and select either Install fvdw-sl firmware or Standalone kernel, load and start under the Action menu drop-down the window that pops up with the remark that it waits for u-boot (step #3 listed on the help file) closes after a couple of seconds and I never see the kernel transferred.

Consequently the telnet fails to connect. I've managed to grab a screenshot of the U-Boot window prior to it closing (which happens quite quickly). From what I understand the U-Boot window is not supposed to close until the transfer of the kernel to the NAS is complete.

I've tried the entire process many different times with slightly different delays between selecting the firmware image and powering up the NAS. I am beginning to think that there may be a problem with u-boot on my device.

Any thoughts?

[fvdw]

Hi, sorry to hear this
do you use a wireless connection between pc and lan ?

If you use wife change to wired connection, wifi transfer can be disturbed.

There is no problem with your u-boot, the window you posted shows that boot is interupted, that means there is communication between your pc and the cloudbox uboot.

There seems to be an issue with tftp transfer

[fvdw]

if you use a wired connection then something seems to block tftp communication, so is tftp32 program started (you should see a seperate window showing what is doing). It should look like this

consolel.JPG

If that's is the case (tftp32 up and running and no firewall block or block in router) then tftp transfer can fail if you moved the tftp folder of the fvdw-sl console to a different location then the default

[redbeard]

Hello fvdw, thank you for the quick response.

I am connected via Ethernet cable and I do see the tftpd32 server window pop-up whenever I select one of the Action items.

The Cloudbox and PC are connected to the same switch. Firewall and AV disabled. Very odd indeed.

I am curious, how does the NAS/telnet server set its IP, is it static? DHCP?

[redbeard]

I've screen captured the process in hopes that it gives you a better idea of what's going on. Please take a look at the video here: https://we.tl/t-PgtjBYPQcq

The u-boot window disappears almost immediately. Is that normal?

[fvdw]

I've screen captured the process in hopes that it gives you a better idea of what's going on. Please take a look at the video here: https://we.tl/t-PgtjBYPQcq

The u-boot window disappears almost immediately. Is that normal?

No the window should not disappear immediately it should show loading the kernel
What is strange is that is also that the waiting for u-boot is very short. Normally it stays there and then you switch on the cloudbox, some seconds after you switch on the cloudbox the the lines shwoing uboot infoot should appear it indicates that uboot is interupted and waiting for commands.

Did you switch on your cloudbox after the command window waiting for uboot popped up ? If not then that is what do wrong

If you switch it on after that window waiting for u-boot appears something else is going on.
To investigate that you could select as action "u-boot console".
First start the tftp server in the fvdw-sl console then choose action u-boot console (of course switch off cloudbox first and wait with switching on until the command window ask you to click on it.
The u-boot console should interrupt boot and ask you to click on it.,
now you get a Marvell>> prompt in the u-boot console window and we are talking to u-boot running on the cloudbox.
Set boot parameters by entering these commands
(do not replace ip addr and serverip and so on by actual ip's, type the command exactly as given)

Code: Select all

Marvell>> setenv ipaddr ${ipaddr}; setenv serverip ${serverip}
Marvell>> setenv bootargs console=ttyS0,115200 netconsole=6666@${ipaddr}/,6666@${serverip}/ root=/dev/sda7

(you can paste it in the window, right click on title bar of the window and choose edit)

Then upload the kernel

Code: Select all

Marvell>> ide reset
Marvell>> tftpboot 0x800000 UIMAGE-3142-KIRKWOOD-158-standalone

this will give output that it uploads the kernel and mention when it is done

next boot the kernel

Code: Select all

Marvell>> bootm

and see what happens. If it loads and produce output we can see what can be done to solve the problem
If the kernel loads ok and runs then you should be able to connect with the telnet terminal of the fvdw-sl console

[redbeard]

Hello,

I switch the Cloudbox on after the u-boot window appears (as per the instructions). I put the original HDD back in the device to see if anything changes.

When I run the u-boot console it seems to get stuck and nothing happens (screenshot attached). The Cloudbox ends up booting into the original firmware. It seems u-boot is not interrupting the boot process.

Perhaps there is something wrong with my PC. I will try using another and see if it helps at all.

Thank you kindly for your time.

[fvdw]

Oke, funny behavior especially that it boot into the original firmware. The behavior should be like this
Before starting the nas you should see this

$matches[2]

After the line appears mentioning "starting u-boot net console click on window and press enter" you should get this

uboot-after.JPG

The fact that the the line appears "starting u-boot net console.."means that the fvdw-sl console detected the start of uboot and tried to interrupt it. Because we see the Marvell>> prompt when using the action load standalone kernel it succeeded in doing that however your cloudbox seems to leave netconsole mode after a short period which is not the expected behavior and indicates a modified u-boot or more likely it performs a reset because of a hardware issue or other reason, mmm what next... :scratch

How is the setup of your lan ? Do you use a router ?
Did something specific issue happened before you attempted to install fvdw-sl ?
Does it boot into the normal firmware and then operates normal ?

You could also try to repeat but without a harddisk installed
A reset could be initiated by a bad power supply especially when powering up the disk the power supply may have a problem to supply sufficient power and drop voltage and cause a reset.
Also a test with an other power supply may help to check out this option

[redbeard]

How is the setup of your lan ? Do you use a router ?

The LAN setup is pretty basic. The PC and NAS are connected to the same switch. There is a router that handles WAN traffic (internet) and DHCP also connected to the same switch.

Did something specific issue happened before you attempted to install fvdw-sl ?

I updated the original firmware to the latest version and searched the internet to see if I could get root access to the NAS. During my search I discovered fvdw-sl and thought it would be a great alternative firmware. There was no particular issue that I had.

Does it boot into the normal firmware and then operates normal ?

Yes it boots into the normal firmware and operates like normal.

You could also try to repeat but without a harddisk installed

I have tried without a HDD attached and the same behavior happens.

A reset could be initiated by a bad power supply...

That is a good point. I am not using the original power supply. The power supply I am using is rated for 12V 4A (original is 12V 2A) which I thought should be OK. I will try and see if I can find another.

This is funny behavior for sure. :scratch I am looking to find another PC to try as well.

[fvdw]

The power supply I am using is rated for 12V 4A (original is 12V 2A) which I thought should be OK. I will try and see if I can find another.

yep 12V 4 A should be enough maybe it is not working properly and drops voltage when power is pulled.
However the fact that it can boot the original firmware would suggest power supply is ok.

If thats the case then remains something is interfering with communucation between console and nas. For that you test with another pc would be ok.

As last resort you could try to connect to the serial interface of the cloudbox, for that you will nee a ttl 232 (3,3V) usb/rs232 cable and using a program like putty to talk to the serial interface via com port)
The serial interface will display output of uboot when booting and may reveal the reason why it acts different