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
Root device root=/dev/sda1 should be used temporarily way to test boot. Use root=LABEL=rootfs so that it will boot successfully when you boot with multiple drives (SATA, USB,....) attached to the box (only one partition among them should be a rootfs)by bodhi - Debian
ahuovinen, > Yes but if you look my printenv output: > > rootfs=/dev/sdb7 . > > have to type > > setenv rootfs <enter> > > to remove it. after that booting from usb works. Ah I see. Cool! > really have to get u-boot flashed to standard > version so i can install > Linux of hdd. You can flash it in netconsole or in Debian too.by bodhi - Debian
Hi jaykumar, > @bodhi, can you please add this patch the kernel > releases > > https://lore.kernel.org/netdev/ZU9OEwz7GoHbBE1m@lore-desk/T/ > > I was troubleshooting constant kernel stack trace > and found this patch fixed the issue for me. Sure it was accepted in the kernel so I will pick it up. But can you point me to the post here where you have this mvneta pby bodhi - Debian
spiderdijon , I'm reading and thinking about this problem. Will let you know.by bodhi - Debian
> > warri@debian:~$ cat /proc/cmdline > console=ttyS0,115200 root=LABEL=rootfs > rootdelay=10 earlyprintk=serial > > Yes. That's why it works.by bodhi - Debian
Quoterootfs=/dev/sdb7 setting that to nothing it then works. Check your bootargs in Debian cat /proc/cmdline ====== OK so it does look like the problem is with serial console. Just in case, at netconsole prompt, see if serial and net console are listed: coninfoby bodhi - Debian
> Tried also with other serial cable, pl2303hxa > based chip and the output is garbage again. > The serial output was set to net console https://forum.doozan.com/read.php?2,137024,137082#msg-137082 But I don't know this u-boot so I cannot be sure why it was not set to serial at the begining. Normally, u-boot sets stdin/stdout/stderr to serial initially, and then when itby bodhi - Debian
spiderdijon, > The auto booting debian from USB works well which > is great, Cool! > but the sata controller issue persists. > The unit only has 4 drive bays. It also has two > e-sata ports on the rear which connect directly to > the SoC (not via PCI-E). Yes, together that's 6 slots. 4 by PCIe. > However as you say to dts/dtb looks fine and I > caby bodhi - Debian
tillewolle, > https://wiki.debian.org/InstallingDebianOn/Synology > problem is: The tutorials are written for Marvell > Armada 385 CPUs. My RS814+ uses an Intel Atom > D2700. > Correct, that tutorial can not be used for this RS814+. We don't have tutorial for Intel boxes. There is one working thread that might be of interest to you: https://forum.doozan.com/reaby bodhi - Debian