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
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
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
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
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
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
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
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
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
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
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
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
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
@kiddouk have you ever successfully loaded an initrd on these devices?by 1000001101000 - Debian
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
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
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
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
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
I would be very interested in that.by 1000001101000 - Debian
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
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
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
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
Looks like the mainline dtb marks it as read-only. https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-goflexnet.dts partition@0 { label = "u-boot"; reg = <0x0000000 0x100000>; read-only; }; Looks like it has for a long time, but if you changed to the dtb distributed by debian recently it might explain it.by 1000001101000 - uBoot
@oxygen8 I'm working on creating a script to automatically adjust the fan speed on devices that use the microcontroller to control the fan, I think you said you were putting something similar together for the other devices. If so, what logic are you using to map drive temperature to fan speeds?by 1000001101000 - Debian
Can you be more specific about what you want to accomplish? Most distros use "hybrid" images for there installation media these days which can be directly written to a usb drive via dd.I use grub-mkrescue to generate usb-bootable disk images for a custom Debian Installer I maintain. There are many other ways to create bootable media but it depends greatly on what you are trying tby 1000001101000 - Off-Topic
Was finally able to confirm that trying to scan this i2c bus locks something up if you try to scan it and it stays that way across resets until you physically disconnect power. It works fine if you just use the rtc without trying to scan via i2cdetect or sensors-detect. I confirmed this happens with the i2c-mv64xxxx driver and using the i2c-gpio “bitbang” driver. I’m still narrowing dby 1000001101000 - Debian
I’m 99% sure that I got to detect the chip once a few days ago when I was troubleshooting a UART issue. I didn’t pay much attention since I thought fixing the UART pins resolved some kind of conflict. I wonder if stumbled across some sort of power/chip select pin without realizing it... or imagined it. I think i’ll work it from that angle for a while. I didn’t find any meaningful diffeby 1000001101000 - Debian
Howdy, I'm trying to get the rtc working on an armada-370 device but am having trouble getting the i2c bus to work. I can tell from the dmesg output from the stock firmware that the rrtc works and is connected via i2c. In fact I've had no trouble with some very similar devices (with the same stock dmesg output) but haven't had luck with this one but am encountering this on mulby 1000001101000 - Debian