Closed Omagic76 closed 3 years ago
Log without stopping to add commands logBuffalo.txt
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
After booting, the network turned on and off several times, then it remained off. logBuffalo1.txt
Tell me how to update the kernel)
Nice!
Download/copy the .deb to the device
run dpkg -i
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
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
Ok. Pumped again) It seems that the process has started)
Sorry for my tactlessness. I did not greet you today). Hello)
Something seems wrong again ( kernel_update.txt
sorry, I forgot about that.
remove Kernel-Flavors: armmp
from your devices entry in:
/usr/share/flash-kernel/db/buffalo_devices.db
Deleted 2 lines with these entries. Nothing changed. Now I will try to reboot the device
... 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.
Noticed that in buffalo_devices.db another model is registered: LS210D
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
OK. Do you need to change the model to the LS420D?
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
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.
now run:
dmesg | grep -i phytest
to see the output I added about the memory address/values changed by the patch.
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
Outputs nothing ( root@nasBuffalo:/home/rik# dmesg | grep -i phytest root@nasBuffalo:/home/rik#
that seems odd, try just looking through the output of dmesg
After reloading network is down.
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 run
flash-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.
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
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.
The network does not work, I will try to download it to a USB flash drive
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.
you could also just try ifup eth0
after it boots. That output you posted earlier makes it look like that might work.
Ifup tried writing some kind of error
Rewritten the file, rebooted nothing has changed
Excuse me. I need to go away. We will continue a little later
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.
I'm here ). If something needs to be done, I'm ready
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.
@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).
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.
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.
@metrorik could probably try a ping command or something from the uboot prompt which might be easier.
I have already copied initrd.buffalo and uImage.buffalo from the Buster branch. I can flash the device via TFTP
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.
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
We understood each other)
initrd.buffalo и uImage.buffalo Besides these files nothing else to put to TFTP?
Will it be with the old kernel, then will it be necessary to update the kernel again?
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.
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.
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
Here is the complete system installation log: installing.txt
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.