I implemented that to troubleshoot some bit order issues but now that I have it working it's super helpful to get a sense for how things are showing up on the screen without having to physically sit in front of it. Ascii art is a fun bonus.by 1000001101000 - Debian
I haven't read the entire thread, but have you set passwords for the users via smbpasswd?by 1000001101000 - uBoot
I took a look at that GPL code you found, it looks like it has some things in there specific to the ix4-200d but seems to be missing some things. Specifically, the driver for the lcd doesn't seem to be anywhere that I can find. There is a kernel image in there and I can see from it's strings that it was built with the lcd driver but I don't see the actual source in there anywhere.by 1000001101000 - Debian
The gpl source would be good to have access too if you have it. I did a little work with my device though not as much as I would have liked with sata not working. What I did do is: - add entries to the dts for each of the buttons - add entries to the dts for the leds - add entries to the dts for the stock nand partitions - create a python script that displays an example image (debianby 1000001101000 - Debian
I've started working with mine but can't seem to get sata to work at all (built-in or PCI). It's possible mine is a hardware problem but I haven't confirmed that yet. At one point I dug through those posts too but didn't find what the solution was. I'd be interested to know as well.by 1000001101000 - Debian
I imagine there are a lot of good tutorials out there for learning about permissions, I don’t have a particular one to recommend. It’s important to learn but also difficult to keep straight sometimes. Amusingly, the website for the class where I first learned about Unix permissions ~20 years ago is still online. It gives a pretty good overview of file permissions though not this specific iby 1000001101000 - Debian
Put it somewhere else, such as /usr/local/bin. Generally, to execute a script the user needs some access to the entire path from / to where the script is, since that user won't have any access to /root this won't work. Rather than modify /root I'd suggest moving the scripts.by 1000001101000 - Debian
When you say it wont boot usb anymore, what error/problem are you seeing? I just remembered I have one of these in my closet, I’m going to see if I can get mine up and running in the coming days/weeks.by 1000001101000 - Debian
It looks like you've got the SoC sata and the PCI sata enabled and two of the ports are connected to both. I ran into the same thing with the Buffalo Linkstation LS441DE though it never caused any instability that I noticed. You should be able to disable the SoC sata in the dtb and allow all 4 to use the PCI sata. Hopefully that would resolve the issue, or at least help narrow it down.by 1000001101000 - Debian
Quick update about kernel versions for these devices since I've been working on automating building kernels for them recently. TS-WXL: Working fine with all the kernels I've tested, most recently 5.4.6. version ~4.12 - 5.1 require a patch to deal with an mvmdio bug which was eventually fixed. TS-XL, TS-RXL (and the TS-HTGL (ts2pro) for that matter): working on versions up to 4.by 1000001101000 - Debian
Yes, for this device uboot is configured to load from the first partition of one of the drives. I think it goes with the first one it finds a valid image on but it does compare the timestamps on each and may default to the newest one if multiple are found. For the debian installer to work properly you must specify the first partition (or preferably a raid1 array made up of the first partitionsby 1000001101000 - Debian
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