Looking at the relevant dtsi's your offsets look correct. using the other buttons I've previously identified the addresses continue to be slightly off what I would expect. f1010111: 0x01 is mpp16 f1010151: 0x20 is mpp49 f1010152: 0x80 is mpp47by 1000001101000 - Debian
I just started playing with this. I dumped 0xF1010150 and then did again with a button pressed which corresponds to mpp47. I believe that toggled 0x80 at 0xF1010152: f1010100: 1000d080 efff0f7f 00000000 00000000 ................ f1010110: 3001d080 b401ff94 00000000 00000000 ...0............ f1010120: 00000000 00000000 00000000 00000000 ................ f1010130: 00000000 0000by 1000001101000 - Debian
That gives me something to play with. I verified that the sata controller shows up within uboot but also confirmed that the drives don't show up at all via scsi scan I also tried setting all the outputs of the on-board shift register high and low used for the leds but that didn't do anything either.by 1000001101000 - Debian
That would be great. I put 4 drives in and added 4x likely pins as regulators. I tried as both active high and active low but no drives showed up. I don't see the crash anymore. I'm not sure if that's because of disabling on-board sata, adding the regulatord, or just because it's a different kernel than before. the sata controller does show up in lspci: root@ix4:~by 1000001101000 - Debian
Interesting. I suppose enabling gpios after mv_sata already crashed probably isn’t a great test. I suppose I could set up the regulators in the dts on the assumption they exist. Fortunately, the lcd etc takes up so many gpios there are only a handful left I haven’t identified, it shouldn’t be hard to guess which ones control drives if any do.by 1000001101000 - Debian
hmm, your output looks almost identical to mine (see attached). I was starting to think mine was just broken since I hadn't seen other folks with the same issue. I've mostly skipped trying to get the stock firmware working and have been working on building on the existing hardware support in Debian. I've tried enabling all the GPIO pins but none them caused the drives to powerby 1000001101000 - Debian
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