does that device have a an sdcard reader or similar? I seem to remember I solved a lot of conflicts by removind the mvsdio entry on devices where it isn't actually needed. I also found one that didn't use i2c and was re-using those pins and solved some issues. The buffalo devices all use spi1 instead of spi0 pins for what it's worth.by 1000001101000 - Debian
I’d think it would be a0000 rather than a8000by 1000001101000 - Debian
I discovered while working on some other devices that my strange workaround for to make the initrd images work isn't actually needed if the initramfs size is less than 8MB or so. I've reworked the installer images to be small enough to fit this limitation and included logic to configure initramfs-tools to generate small enough images (MODULES=dep). This means working kernels for theby 1000001101000 - Debian
It's usually pretty difficult to get the serial console working on these devices. I'd also be interested in knowing how to do so on this particular device, a brief search didn't turn up anything for me either. That said, you can usually recover these device without console output as long as you didn't try flashing the bootloader (or lose power when the firmware updater wasby 1000001101000 - uBoot
I noticed something interesting recently. It looks like FreeBSD has some degree of support for the MV78100, including device-tree support. https://github.com/freebsd/freebsd/blob/master/sys/dts/arm/db78100.dtsby 1000001101000 - Debian
right on . I'm not sure how I'd feel about it if I was flashing mtdblock devices but it makes kernel updates pretty painless when booting from a disk.by 1000001101000 - Debian
Are you planning to configure flash-kernel to automate updating the uImage for this device?by 1000001101000 - Debian
Did you install haveged on that system?by 1000001101000 - Debian
They are all 78100. The boards are all nearly identical as well.by 1000001101000 - Debian
I don't remember the exact order of things but I noticed that only one PCI channel seemed to be initialized during boot and that it happened to be the incorrect one for the SATA chip. I eventually noticed that the code in question is meant to assign each channel to a separate CPU, but this is the single-cpu variant of the soc. I eventually noticed one of the boards was set up this way andby 1000001101000 - Debian
Yeah, the package creates a service that runs early enough to sidestep the problem.by 1000001101000 - Debian
My understanding is most cpu's have a built-in entropy source but these were determined to be potentially insecure around the same time as all the meltdown/spectre stuff was being discovered. Sometime around 4.17 they started disabling them by default. This has given me a few headaches since rather than use/provide a rootfs tar like Bohdi I provide a modified Debian Installer image for soby 1000001101000 - Debian
Try installing haveged. That’s what i’ve ended up doing on my armada370 systemsby 1000001101000 - Debian
Neat. I’ll have to give it a try in 5.2by 1000001101000 - Debian
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
I went ahead and threw the alias in the DTB and rebooted. That didn't change anything for that particular device.by 1000001101000 - Debian
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
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
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
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