search

1000001101000 / Debian_on_Buffalo

Tools for Installing/Running Debian on Buffalo ARM based Linkstation/Terastation/Kurobox/Cloudstor devices.
330 stars 41 forks source link

Cannot install on LS421de, network disconnects #47

Closed Omagic76 closed 3 years ago

Omagic76 commented 4 years ago

Hi 1000001101000,

First of all, thanks for your work on enabling the use of Debian on Buffalo NAS.

I have a LS421de for quite some time, and I want to upgrade its software. I follow your instructions to update to Debian Linux, but when I'm installing Debian, the network disconnects. I tried at least 10 times with the same result. And it happens in different screens of the installation process. I have the LS421de connected directly to the router (gigabit ethernet) with the network cable it came with. I tried changing the cable, changing the port it is connected in, and same result. I also tried to limit the ethernet speed to 100M before starting the installation, but still it disconnects from the network. I tried with the Stretch version, same result. And with the stock firmware it works fine. I checked the Issues in the repository, read every forum I could find but can't find the solution. So my last resort is to contact you. Any help you can provide will be greatly appreciated. Thanks.

metrorik commented 4 years ago

Log without stopping to add commands logBuffalo.txt

metrorik commented 4 years ago

I used to try to stop the boot process with a hardware button. Now I just tried to press the button in the console and the download stopped) Now I’ll throw off the log after entering commands to change the status of the registers

metrorik commented 4 years ago

After booting, the network turned on and off several times, then it remained off. logBuffalo1.txt

metrorik commented 4 years ago

Tell me how to update the kernel)

1000001101000 commented 4 years ago

Nice!

Download/copy the .deb to the device run dpkg -i .deb

metrorik commented 4 years ago

root@nasBuffalo:/home/rik/kernel# ls linux-image-5.6.14_5.6.14-2_armhf.deb
root@nasBuffalo:/home/rik/kernel# dpkg -i linux-image-5.6.14_5.6.14-2_armhf.deb dpkg-deb: error: «linux-image-5.6.14_5.6.14-2_armhf.deb» Is not an archive in the format debian dpkg: Error processing archive linux-image-5.6.14_5.6.14-2_armhf.deb (--install): process dpkg-deb --control Returned error code 2 Errors occurred while processing the following packages: linux-image-5.6.14_5.6.14-2_armhf.deb

1000001101000 commented 4 years ago

looks like you ended up with an invalid file. follow the download link on the page I sent or use this direct link: https://github.com/1000001101000/Debian_on_Buffalo/raw/master/Tools/kernel_tools/armhf/linux-image-5.6.14_5.6.14-2_armhf.deb

metrorik commented 4 years ago

Ok. Pumped again) It seems that the process has started)

metrorik commented 4 years ago

Sorry for my tactlessness. I did not greet you today). Hello)

metrorik commented 4 years ago

Something seems wrong again ( kernel_update.txt

1000001101000 commented 4 years ago

sorry, I forgot about that.

remove Kernel-Flavors: armmp from your devices entry in: /usr/share/flash-kernel/db/buffalo_devices.db

metrorik commented 4 years ago

Deleted 2 lines with these entries. Nothing changed. Now I will try to reboot the device

metrorik commented 4 years ago

... Taking backup of armada-370-linkstation-ls420d.dtb. Installing new armada-370-linkstation-ls420d.dtb. Kernel /boot/vmlinuz-5.6.14 does not match any of the expected flavors (armmp), therefore not writing it to flash.

metrorik commented 4 years ago

Noticed that in buffalo_devices.db another model is registered: LS210D

1000001101000 commented 4 years ago

I should have been more specific. try:

sed -i 's/^Kernel-Flavors*//g' /usr/share/flash-kernel/db/buffalo_devices.db
dpkg -i linux-image-5.6.14_5.6.14-2_armhf.deb
metrorik commented 4 years ago

OK. Do you need to change the model to the LS420D?

metrorik commented 4 years ago

The kernel has been updated: uname -a Linux nasBuffalo 5.6.14 #2 SMP Fri Jun 19 13:12:41 CDT 2020 armv7l GNU/Linux

1000001101000 commented 4 years ago

no, the DB file contains info for all the supported models but flash-kernel can detect which is needed automatically by looking at /proc/device-tree/model

The command I gave just wipes out the "flavor" lines from the whole file.

1000001101000 commented 4 years ago

now run: dmesg | grep -i phytest to see the output I added about the memory address/values changed by the patch.

1000001101000 commented 4 years ago

Here's what mine looks like:

[   17.729547] mvneta d0074000.ethernet eth0: PHY [d0072004.mdio-mii:00] driver [Marvell 88E1510] (irq=POLL)
[   17.768720] phytest: Port1 Address E09744E0 Value  AAA
[   17.773971] phytest: Port1 Address E09744E0 Value  A8A
[   17.779196] mvneta d0074000.ethernet eth0: VDDO voltage asserted: 1v8
[   17.900909] mvneta d0074000.ethernet eth0: configuring for phy/rgmii-id link mode
[   20.568652] random: crng init done
[   20.572090] random: 7 urandom warning(s) missed due to ratelimiting
[   22.049463] mvneta d0074000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   22.057601] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
metrorik commented 4 years ago

Outputs nothing ( root@nasBuffalo:/home/rik# dmesg | grep -i phytest root@nasBuffalo:/home/rik#

1000001101000 commented 4 years ago

that seems odd, try just looking through the output of dmesg

metrorik commented 4 years ago

After reloading network is down.

metrorik commented 4 years ago

dmesg.txt

1000001101000 commented 4 years ago

hmm, yours looks pretty different from mine for some reason.

You are using Stretch and I'm using Buster, but that shouldn't change the kernel initialization. It does mean you are using the older device tree though. that owuld explain the problem.

try copying this into your /etc/flash-kernel/dtbs/' then runflash-kernel` and reboot.: https://github.com/1000001101000/Debian_on_Buffalo/raw/master/Buster/device_trees/armada-370-linkstation-ls420d.dtb

You'll need to replace it with the old one before going back to the Stretch/4.9 kernel later.

metrorik commented 4 years ago

When turned off, the log stops briefly on these lines: mvneta d0074000.ethernet eth0: VDDO voltage asserted: 1v8 [ 921.645184] mvneta d0074000.ethernet eth0: configuring for phy/rgmii-id link mode

1000001101000 commented 4 years ago

weird. I'm guessing the DTB version mismatch caused that, but i don't know why.

For these devices to reboot they need to bring up the network interface and set the "wake on lan" register to signal reboot instead of shutdown. It seems like that worked even though it failed at boot. Very strange.

metrorik commented 4 years ago

The network does not work, I will try to download it to a USB flash drive

1000001101000 commented 4 years ago

good point. You could also restore uImage.buffalo.bak and initrd.buffalo.bak and boot the old kernel... althoughwe may have already overwritten those with other 5.6 attempts. USB is probably simplest if you have that available.

1000001101000 commented 4 years ago

you could also just try ifup eth0 after it boots. That output you posted earlier makes it look like that might work.

metrorik commented 4 years ago

Ifup tried writing some kind of error

metrorik commented 4 years ago

Rewritten the file, rebooted nothing has changed

metrorik commented 4 years ago

Excuse me. I need to go away. We will continue a little later

Omagic76 commented 4 years ago

Hi 1000001101000 and metrorik,

Thanks metrorik for your interest on solving this issue. I've been busy lately with work and hasn't been dedicating much time to this. I'll try the modified kernel and report back.

metrorik commented 4 years ago

I'm here ). If something needs to be done, I'm ready

Omagic76 commented 4 years ago

With the kernel linux-image-5.6.14_5.6.14-2_armhf.deb I have the same results, the network adapter disconnects. I attached the dmesg log. It looks like the voltage is changed, but still the network adapter disconnects after a couple of minutes.

Kernel_5.6.14_log.txt

1000001101000 commented 4 years ago

@metrorik focus on trying to get linux 5.6 working with the "Buster" device-tree via the flash kernel process discussed earlier. That should make your network work again (though perhaps not solve the stability problem).

1000001101000 commented 4 years ago

I'm curious if the patch works any better for @metrorik but imagine the result will be the same.

I'm wondering if building in the network driver rather than using a module would make any difference.

It might be worth tracking down the actual kernel from openwrt to figure out why that works and this doesn't.

I should probably try getting a serial console working on one of my "good" devices so I can compare my output to to @metrorik

Could either of you try booting from TFTP and see if that makes a difference? I'm wondering if that would cause u-boot to properly initialize the network hardware before linux loads and result in a stable system. If so, we could look at the serial output for clues on how that works and even look at a memory dump or phy register dump to compare.

1000001101000 commented 4 years ago

to do that you'd copy your initrd.buffalo and uImage.buffalo from a working install to a TFTP server at 192.168.11.1 and then I believe you hold the function button while it boots.

1000001101000 commented 4 years ago

@metrorik could probably try a ping command or something from the uboot prompt which might be easier.

metrorik commented 4 years ago

I have already copied initrd.buffalo and uImage.buffalo from the Buster branch. I can flash the device via TFTP

1000001101000 commented 4 years ago

you should be able to boot into Debian that way by using the files generated by flash-kernel. I'm wondering if that results in a stable network.

I've never actually done that so there could be some complications. You may need to boot without drives, then insert them, then trigger TFTP via the function button.

The goal is to somehow get uboot to enable the network and then boot into Debian normally and see if that improves things.

metrorik commented 4 years ago

During the initial boot, I disconnect the disks, then the device enters recovery mode via TFTP. Then I connect the disks and press the button

metrorik commented 4 years ago

We understood each other)

metrorik commented 4 years ago

initrd.buffalo и uImage.buffalo Besides these files nothing else to put to TFTP?

metrorik commented 4 years ago

Will it be with the old kernel, then will it be necessary to update the kernel again?

1000001101000 commented 4 years ago

It needs to be a kernel where you have working network already (either 4.9 kernel + 4.9 dtb or newer kernel + newer dtb).

For this test I don't think it even needs to have the patch.

1000001101000 commented 4 years ago

In case it hasn't been clear:

uImage.buffalo is a uboot image that contains the kernel + DTB, initrd.buffalo contains uboot imagecontaining the initrd. The ones on my github page contain the debian installer code in the initrd. On a running system flash-kernel handles creating new *.buffalo files whenever the kernel or initrd are updated.

metrorik commented 4 years ago

I understand that. Apparently a bad translation is obtained, my words are not correctly written ( Until the device is flashed. I can throw off the connection waiting log to the TFTP server. At this time, the LS420 has an address of 192,168,11,150 and ping perfectly here: log.txt

metrorik commented 4 years ago

Here is the complete system installation log: installing.txt