onewithforce, Your u-boot envs were already populated with some much older version. So kwboot the latest u-boot 2023.04-tld-1 will not boot into Debian due to envs mismatched. Try kwboot using uboot.2017.07-tld-1.nsa325.mtd0.kwb. This version would boot into Debian with your current envs. kwboot is meant to be tested so that you know there is a rescue path. But not to boot all the way iby bodhi - Debian
Quoteis it possible that some of the problemĀ“s are from an not working RTC or problemĀ“s with the DNS ? Not RTC or DNS. Quoteis it possible to assign the copy led to an specific drive/usb port and disable the usb led for an specifig usb port ? Not possible in userspace.by bodhi - uBoot
"The shared folder for the 6TB-A is visible on my CentOS when doing the mount, but it shows empty." Most likely it's permission.by bodhi - Debian
optim, > I tried going direct from Jessie to the newest > Bookworm release on a GoFlex Home, that boots off > the hard drive. That's too big a jump. Debian does not support skipping release. And you're skipping 2 releases! > Whats my best option for fixing this? I prefer to > remove the HD and repair it on another computer > (not sure if that possible).by bodhi - Debian
Tedious_1, > root@debian:/mnt/drives/6TB-A# iperf -c > 192.168.1.2 -F bigfile I think the big file here might not be a good test for iperf. This was a good test because you are not using file system: QuoteI have also set up a iperf server on the CentOS (gigabit Netgear XR500 router in the middle) and ran the following: root@debian:/mnt/drives/6TB-A# iperf -c 192.168.1.2 -n 10by bodhi - Debian
Another way to test PCI ASPM. While in Debian, disable it by: echo performance > /sys/module/pcie_aspm/parameters/policyby bodhi - Debian
spiderdijon, [ 69.099838][ T1] pci 0000:00:02.0: ASPM: current common clock configuration is inconsistent, reconfiguring [ 69.188522][ T1] pci 0000:00:05.0: ASPM: current common clock configuration is inconsistent, reconfiguring Try this PCI test: Toggle the PCI ASPM state to off/on. We don't know what's the default value is. So Interrupt serial console and changeby bodhi - Debian
> > There are several > Wiki > thread entries: > > QuotePerfornance Tuning & Benchmarks > > Network performance - SAMBA - NFS (various > protocols) > > Samba Tuning > Mount NTFS with big_writes > > "Samba Tuning" post is old, but perhaps it will > help. Have you tried to use the smb.conf attached to the "Sambaby bodhi - Debian
I've updated 1st post to include the patch. QuoteNOTE: After uploading, I relalized that I forgot to include the patch for this kernel. Here is linux-6.7.5-mvebu-370xp-tld-3.patch if you want to build your own kernel.by bodhi - Debian
Hi Tedious_1, > > Is the CentOS box also using SAMBA when you get > > 60-80MB/s? or using NFS to copy to/from the > > GFNet? > > Yes, the CentOS is set up to share the drive on > the network using samba. I was hoping to use the > GoFlex Net to replace this machine due to > power/heat. For SAMBA, 60-80MB/s is quite decent. Hard to get more than that rby bodhi - Debian
Also, keep in mind that due to the new architecture change in recent years, many mainline u-boot for old hardwares need to be regression tested. That did not happen for a few Kirkwood boxes (perhaps such as the Lacie NAS?), because there is no active maintainer. I'm actively maintaining the mainline u-boot for the Kirkwood boxes that I've been supported here.by bodhi - uBoot
Quote- dphys-swapfile installed with the swapfactor set to 5 (thinking of using HDD for swap later) Also, the swap file should be on HDD while running the test. This box 's RAM is limited.by bodhi - Debian
QuoteCurrent Windows transfer rates (copying from 6TB Goflex to anything on the network) are showing between 14MB/s and 20MB/s. Most 4K movies require higher speeds than this. QuoteCopying to/from the CentOS hosted 4TB drive usually runs at 60-80MB/s. Is the CentOS box also using SAMBA when you get 60-80MB/s? or using NFS to copy to/from the GFNet? ==== There are several Wiki thread entby bodhi - Debian
> There are at least 2 different versions of the > Networkspace 2. > https://web.archive.org/web/20180720230834/http://lacie.nas-central.org/wiki/Category:Network_Space_2 > > I suppose that means that there should be 2 > different u-boot's either. Indeed. But looks like this box is the Netspace V2 "classic" version (with 256MB). Quotehttps://forumby bodhi - uBoot
spiderdijon, > Sure I can look at doing that. If you could, please follow the format that I have for Mirabox and RN102/104 installation in the release thread. QuoteI. Mirabox Intsallation Updated 06 Sept 2020 II. Netgear RN102 Intsallation Updated 06 Sept 2020 Updated 19 Dec 2022 (added Section C) > On the driver side > I would be interested in taking a look. Isby bodhi - Debian
@sudos, > do you have non-free-firmware added to your > apt sources and firmware-realtek > installed? The packges above are only relevant in Debian/kernel, which has no problem. We are currently at issue with the RealTek driver in U-Boot. It could be that nobody has regression test this driver since U-Boot changed SW architecture to driver model. Or could be due to my lack ofby bodhi - Debian
Kernel linux-6.7.5-mvebu-370xp-tld-3 package has been uploaded. See 1st post for download link. Note that this is the same as the working kernel I've uploaded before in this thread.by bodhi - Debian
spiderdijon, I did some digging and reading, and I don't think I can do any thing more regarding the 1st PCIe SATA controller. This driver is way too complicated, and I'm not familiar with PCI. I think we can call it a success in bringing up this box (with the PCI caveat). And we should write an installation post for RN2120, woud you like to do that? In this thread, I wrote indiviby bodhi - Debian
Random MAC issue mentioned in the release thread QuoteUpdated 16 Dec 2023: Rootfs Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded. Basic Debian bookworm armhf rootfs for most MVEBU Armada NAS: .... Note 6. Persistent MAC address (Optional): To enable the network dynamic IP to stay consistent after each reboot, and also for faster boot. In this rootfs, a scripby bodhi - Debian
ahuovinen, > U-Boot 2024.04-rc4 (Mar 13 2024 - 15:56:28 +0200) > NS v2 You should have flashed a known working u-boot first: the stock u-boot.by bodhi - uBoot
SuperPoney, > Continuing my setup, I was able to bring network. > For an unknown reason in my box the network card > under "initramfs-6.6.2-mvebu-tld-1" (Debain 12) is > named "end1" and not "end0" : That was because your u-boot envs set it up to use egiga1. Net: , egiga1 Power On! FDT loaded successfully Hit any key to stop autoboot:by bodhi - Debian
> I didn't post anything regarding the mvneta > problem earlier as I thought this was somehow only > affecting my installation :) Ah, OK :) If the next stable kernel 6.8.x does not pick this up, I will.by bodhi - Debian
Quotebodhi Of course there is also a chance that the envs location was moved by the modified u-boot. Quotea location is different for the envs.. that you mentioned was all empty. its much before. It can also be that the modified u-boot doesn't store the envs on flash at all. They instead specified them internally in the code. Use hexedit to load the mtd0 dump and search for "stby bodhi - Debian
> do i need a reboot between the editing and > fw_printenv? No need to. Check dmesg dmesg | grep -i2 spi [ 7.139740] spi-nor spi0.0: mx25l4005a (512 Kbytes) [ 7.145448] 1 cmdlinepart partitions found on MTD device spi0.0 [ 7.152119] Creating 1 MTD partitions on "spi0.0": [ 7.157662] 0x000000000000-0x000000080000 : "uboot" Check mtd cat /by bodhi - Debian
After dumping u-boot as described above, use hexedit to find the localtion in the image file mtd0.ns2, see if it is really 0x70000.by bodhi - Debian
> root@debian:/home/warri# cat /etc/fw_env.config > # MTD device name Device offset Env. size > Flash sector size Number of sectors > #/dev/mtd0 0xc0000 0x20000 0x20000 > /dev/mtd0 0x70000 0x1000 0x1000 I missed one zero, 6KB = 0x10000 cat /etc/fw_env.config /dev/mtd0 0x70000 0x10000 0x1000 But this u-boot seems to use only 4K envs Environmentby bodhi - Debian
After you see mtd0 detected and listed in Linux. Modify /etc/fw_env.config # MTD device name Device offset Env. size Flash sector size Number of sectors /dev/mtd0 0x70000 0x1000 0x1000 And then list the envs fw_printenvby bodhi - Debian
> Darn, maybe i have to desolder the flash chips to > program them ;) might be easier with a jtag. There > might be a way to do this with arduino > or raspberry pi IIRC . though dont have a pi and > all my arduinos are 5v 16mhz. No need to do that drastic step yet. The next step is to get the mtds definition correct and so Linux can see the MTD partitions (u-boot and envby bodhi - Debian
> If i compile mainline u-boot for networkspace 2, > how to test if it works without serial or > flashing? I don't think there is any other way to test. The only remaining way to test without flashing is to chain load u-boot image from u-boot prompt. However, the mainline u-boot has a very different architecture from the old stock u-boot. So chainload will not work in that dby bodhi - Debian
> Yes, was just experimenting. Too bad i cannot set > bootargs as i would like to in environment > variables because they are hard coded on the > u-boot differently. You already did set bootargs correctly. That's why you can boot and the kernel can mount the root device using the partition label. warri@debian:~$ cat /proc/cmdline console=ttyS0,115200 root=LABEL=rootfs rby bodhi - Debian