Show all posts by user
Discuss all things Debian on your device
Re: Debian buster 10.0 on Armada boxes -- udev problem with MAC address - 5 years ago
Neat. I’ll have to give it a try in 5.2by 1000001101000 - Debian
Re: Debian buster 10.0 on Armada boxes -- udev problem with MAC address - 5 years ago
This is what I get at boot: [ 7.037559] libphy: orion_mdio_bus: probed [ 7.143841] mvneta d0074000.ethernet eth0: Using random mac address 92:ba:10:da:c0:77by 1000001101000 - Debian
Re: Debian buster 10.0 on Armada boxes -- udev problem with MAC address - 5 years ago
I went ahead and threw the alias in the DTB and rebooted. That didn't change anything for that particular device.by 1000001101000 - Debian
Re: Debian buster 10.0 on Armada boxes -- udev problem with MAC address - 5 years ago
If memory serves the alias only works if the relevant kernel patch is applied. Admittedly i haven't looked at that part in a year or more, it might be a good time for me to revisit, I've learned a lot since then. I took a look at the dmesg on one of my armada boxes (Debian Buster using Vanilla 4.19.0-5) and confirmed I don't see that message, just the one from mvneta when it setby 1000001101000 - Debian
Re: Debian buster 10.0 on Armada boxes -- udev problem with MAC address - 5 years ago
On the Armada 370/XP devices I've worked with the mainline kernel isn't able to read the ATAG values containing the MAC address(es) though there is a patch available that adds that support. Is that still the case or has that feature made it into the mainline kernel? or is that something you've resolved with a newer u-boot? I'm currently using a script in if-pre-up.d to grabby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I confirmed that my Stretch (4.9) kernel/image works on the rack-mounted TS-RXL just like the TS-XL. I took a closer look at the changed between 4.9 and 4.19 and found that there were some large changes to how PCI is handled for the 4.13 kernel that likely broke MV78100 PCI support which would explain why my fix for the 4.9 kernel doesn't help for 4.19. I honestly don't know wherby 1000001101000 - Debian
Re: Debian On Netgear RN102 - 5 years ago
I run Debian's armmp kernel on my Armada 370 devices, when I make a custom kernel I usually use that config as my starting point: https://packages.debian.org/sid/linux-image-armmp You can extract it out of the deb with dpkg -x linux-image-5.2.0-2-armmp.deb . The file is boot/config-5.2.0-2-armmp They also provide a package with just the configs called linux-config-5.2. I imagby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I added some debugging options which made the stack trace a bit more readable: [ 18.445931] Internal error: Oops - undefined instruction: 0 [#1] ARM [ 18.452259] Modules linked in: marvell(+) sata_mv(+) usbcore(+) mvmdio(+) usb_common nls_base rtc_rs5c372(+) libata scsi_mod mv643xx_h [ 18.464499] CPU: 0 PID: 54 Comm: systemd-udevd Not tainted 4.19.67 #1 [ 18.470903] Hardware name:by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
looks like there is an addition fix in 5.2.9 that isn’t in 4.19.67 yet. I created a patch that adds it in which now allows 4.19.67 to work properly on the ts-wxl. i’m getting the same error in 4.19 and 5.2.9 preventing the pci sata from working on the ts-xl [ 17.363300] Internal error: Oops - undefined instruction: 0 [#1] ARM [ 17.369631] Modules linked in: sata_mv(+) mvmdio(+) usbby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I tried building the current Sid kernel (5.2.9) and it worked just fine on the ts-wxl. It seems like my pci patch must not work work with this version since the ts-xl failed to find the rootfs. I expect with some work I’ll be able get that working again.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I’ve tried out my patches and configure changes from the Stretch 4.9 kernel with the Buster 4.19 kernel. I’ve gotten it to boot successfully but am still getting errors trying to start the network. The error still matches the one reported in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712 They listed that bug as fixed in the next proposed kernel https://salsa.debian.org/kernel-by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I spent some time tracing the TS-XL PCI error in the kernel today. It turned out to be a pretty easy fix once I traced the error message back through the kernel source. I now have Debian Stretch running on my TS-XL with working sata. I've uploaded the patch along with new installer images etc to the github page: https://github.com/1000001101000/Terastation-III-research Adding folksby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I spent some time working out the requirements to make a working boot partition for this version/build of u-boot which makes setting up a disk without first installing the stock firmware on it much easier on modern distros. https://buffalonas.miraheze.org/wiki/Terastation_TS-XL#boot_partition_requirementsby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I've got the scripts for building the kernel and installer images posted now along with the installer and kernel packages. https://github.com/1000001101000/Terastation-III-research Let me know if you need anything else to get started.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
My installer image worked and my ts-wxl is running again. I went ahead and created a repository and will start committing my build scripts as I get things streamlined. The url is: https://github.com/1000001101000/Terastation-III-research I uploaded my current installer images as Stretch/installer_files.zip. You can use this to install Debian Stretch on the device along with my kernel, my mby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
Sounds good! I'm testing my latest installer image today, assuming it works as expected I'll try and get everything posted on github to provide a good starting point. Until then, here is the diff between Debian's config and the one I have working: $ diff config-4.9.0-9-marvell linux-4.9.168/.config 377c377,380 < # CONFIG_ARCH_MV78XX0 is not set --- > CONFIG_by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I dug into the issue with the 4.19 kernel, I'm fairly sure it's the same as this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712 It looks like a fix is already pending, I'll try it out in the coming days. In the meantime I've been working on a Debian Installer image for this device which sets up the kernel/startup scripts/initramfs hooks etc. I'm stiby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I was able to get an initrd to execute successfully without needing to modify uboot in anyway. The process is basically to pad the front of the initrd with zeros to get the the actual archive loaded to a suitable offset and then compiling that offset into the kernel cmdline. I'm still working to cleanup/script that process (as well as looking at some other less hacky options). Either wayby 1000001101000 - Debian
Re: fw_setenv not storing parameters - 5 years ago
Quotecholat c) Don't want to break the "never touch a working uboot"-rule, though 2017.07 features sound promising. But I'm a sissy. I'm glad I'm not the only one with this rule.by 1000001101000 - uBoot
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
@kiddouk have you ever successfully loaded an initrd on these devices?by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I ended up starting with the 4.9 kernel I was trying a few months ago with a stretch rootfs from my ls-qvl and the ts-wxl since that's the actually supported device. Although I still can't seem to load an initrd without throwing an error I was able to make the tweaks to the config necessary to get it to successfully boot. The device is running stably and seems to work as expected. Iby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I got my ts-wxl, ts-xl and ts-rxl out and am ready for testing. I compiled a buster (4.19) kernel and tried booting it and got to about the same place as I did back in april. I’ve also installed buster on an ls-qvl and plan to use that for my rootfs/etc. I’m working on setting up some scripts to streamline building kernel images and testing them once we get going.by 1000001101000 - Debian
Re: Zyxel NSA325 Newbie question for update uBoot - 5 years ago
You can find out for sure if you can see the kernel cmdline string either from /proc/cmdline on the running system or by looking at the parameters in the boot loader. You can also usually figure it out from trial and error as there are only a few commonly used settings. looking at another tread for this device I keep seeing: bootargs=console=ttyS0,115200 root=LABEL=rootfs So I would startby 1000001101000 - uBoot
Re: Zyxel NSA325 Newbie question for update uBoot - 5 years ago
random characters on the console usually indicates it's working, just that the settings need to be adjusted. Usually it's just the baud rate that must be changed but you should look at stop bits/parity/flow control too.by 1000001101000 - uBoot
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I’ll pull out my ts-wxl and ts-xl too. I think the dmesg output from my attempts a few months ago are earlier in this thread, it seemed like it was mostly working.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 5 years ago
I would be very interested in that.by 1000001101000 - Debian
Re: Can't write uboot env after upgrade to Debian Buster - 5 years ago
I took another look at that mainline device tree as well as the documentation for MTD partition bindings. Since that device tree hasn't been updated in many years it still uses the older style of binding for fixed partitions. According to the bindings documentation using the older type is not recommended though it doesn't way anything specific on how they would be handled differently.by 1000001101000 - uBoot
Re: Can't write uboot env after upgrade to Debian Buster - 5 years ago
Hmm, I was looking at the armmp kernel rather than the marvell kernel, that changes things a bit. @tsunulukai if it’s set to m you probably just have to load the module. Try adding cmdlinepart to /etc/modules and rebootby 1000001101000 - uBoot
Re: Can't write uboot env after upgrade to Debian Buster - 5 years ago
Those config options are all the same on the stretch kernel. I assume @tsunulukai was running a different kernel (maybe one of yours?) last time they were able to make changes. In any case, removing that read-only; attribute in the dts and making a new dtb should get it working again.by 1000001101000 - uBoot
Re: Can't write uboot env after upgrade to Debian Buster - 5 years ago
I think ignoring the cmdline partition info is normal for the vanilla Debian kernel: ~# cd /boot /boot# grep -i parts config-4.19.0-5-armmp # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_AFS_PARTS is not set CONFIG_MTD_OF_PARTS=m CONFIG_MTD_AR7_PARTS=m Wouldn’t that cause it to use the partitions defined in the dtb? The armada 370/xpby 1000001101000 - uBoot