I recently acquired some odd thin client devices with 4xHDMI ports and some other odd features. The company is long gone so I don't think I'll be getting GPL source or a clean copy of the firmware from anywhere. Fortunately, it has an easily accessible serial header. I didn't see any obvious way to read the emmc rootfs since it's EXT4 (strangely) and that version of ubootby 1000001101000 - uBoot
I saw some similar-ish issues between either 4.19 and 5.10 or 5.10 and 6.1 which I was able to track back to trim/discard being enabled by default for EXT4. Some SATA port expanders, IDE->SATA converters and USB->SATA converters (and probably just older IDE/SATA controllers) will throw a fit if they receive an a TRIM command. I assume this is because their internal firmware predates thatby 1000001101000 - Debian
FWIW I've started putting together Buildroot configurations and tools for Buffalo devices as an alternative to Debian. Originally I focused on the newer devices using SoCs without sufficient mainline support (RealTek RTD1619, RealTek RTD1195N and Alpine AL-314) and have now started adding profiles for mainline devices as well. For the non-mainline devices it's an exercise in makingby 1000001101000 - Debian
mainline 32-bit ARM kernels like the armel and armhf (even the LPAE version) used with Debian have a 16TiB limit for block devices which includes drives and logical devices like mdadm arrays. You get a lot of weird results if you try using using such a device since some programs/calls will report the correct size/etc but you end up with IO errors trying to access past the 16TiB limit. I thougby 1000001101000 - uBoot
2TB limit for MBRs though that can usually be worked around unless you're using a truly ancient kernel. 2TB limit for some ancient sata chips, old usb->sata converters in particular. 16TiB for 32-bit ARM and other 32-bit architectures that tie block size to page size and force 4K pages (2^32 * 4K = 16TiB) The last restriction effects mdadm devices too. There are some out-of-tree patby 1000001101000 - uBoot
Most likely 16TiB limit for block devices generally with 32-bit ARM Linux Kernel. Starting to wish I had a 18TB drive to do some tests with, I'd bet anything some older SATA controllers will have issues with drives above a certain size too but don't know of any so far.by 1000001101000 - uBoot
I spent some time looking at the clock speed of some armada-370 devices a while back. It appeared in the datasheet that the relevant values had to be set right when the CPU came up either by pull up/down resistors on certain pins or via the bootrom. I got the impression this all happened before uboot even started.by 1000001101000 - Debian
I’d say start by confirming you can read some registers with phytool before going for a full test, somethings may need tweakingby 1000001101000 - Debian
actually, I think it was a few years ago: https://github.com/torvalds/linux/blob/master/drivers/power/reset/linkstation-poweroff.c I had mostly forgotten about that, I should really see if I can submit a patch to make it work for some of the kirkwood devices that use the same restart mechanism. I've been doing the equivalent from userspace by setting the desired default values in theby 1000001101000 - Debian
I also wouldn’t mess with the uboot, though I rarelly do. I looked at your stock dmesg at the beginning of the thread, I didnt see a reference to an rtc. You could always poke around with i2c-detect. They are usually pretty easy to spot on the board since they’re usually well labeled and connected to a crystal oscillator. If you’re using a rootfs from my process you might need to modpby 1000001101000 - uBoot
For the ethernet you probably need to adjust the device-tree. Most of these Marvell SoCs have 2 ethernet ports, it’s possible Buffalo used port1 and iomega used port2 or vice versa. for the mtd partitions, you’re defining them in a uboot variable but you aren’t adding that to the cmdline passed to the device. usually at this point I copy whatever device-tree I use as a base to a new oby 1000001101000 - uBoot
I was able to generate an ls-gl image running it myself if that helps. here are the variables I had set: #!/bin/bash ##set some vars. target="/mnt/target" target_hostname="lsgl" #machine="Buffalo Terastation TS-XEL" #machine="Buffalo Terastation TS3400D" machine="Buffalo Linkstation Pro/Live" arch="armel" #arch="armby 1000001101000 - uBoot
The relevant code is below, you can remove some of the “>/dev/null” stuff to see what’s going on if [ "$arch" == "armel" ]; then cp "../bootshim/armel_shim" "$target/boot/bootshim" chroot "$target" /bin/bash -c "wget -O /etc/apt/custom_repo.gpg https://raw.githubusercontent.com/1000001101000/Debian_on_Buffalo/master/Pby 1000001101000 - uBoot
just in case this part is still confusing, my "shim" is appended to beginning of the kernel image: This is a simplified version of what happens in my code to generate the installer kernel images like the one you used. cat armel_shim vmlinuz orion5x-linkstation-lsgl.dtb > tmpkern mkimage -A arm -O linux -T Kernel -C none -a 0x00008000 -e 0x00008000 -n debian_installer -d tmpkeby 1000001101000 - uBoot
Nice! looks like you're 90% of the way there. The cmdline thing is my fault, or rather because you are using one of my kernel images directly rather than making your own from the vmlinuz+DTB. My solution for dealing with the initrd issue was to write some assembly that relocates the initrd and then re-writes the ATAGS with the new location, it also overrides the cmdline to prevent the iniby 1000001101000 - uBoot
hmm. At first glance that all looks pretty reasonable, I have a few thoughts but nothing definitive. That's an odd spot for it to stop, it reminds me of some issues I've run into for newer devices that shouldn't apply for this type of device. Like Bohdi said, the output stops where the memory initialization should be happening. Looking at your dmesg output from the stock I don&by 1000001101000 - uBoot
Building a kernel is more or less following the steps in the page you linked. The relevant commands I use are: make olddefconfig ARCH=arm make -j$(nproc) ARCH=arm KBUILD_DEBARCH=armel CROSS_COMPILE="arm-linux-gnueabi-" bindeb-pkg make olddefconfig ARCH=arm make -j$(nproc) ARCH=arm KBUILD_DEBARCH=armhf CROSS_COMPILE="arm-linux-gnueabihf-" bindeb-pkg etcby 1000001101000 - Debian
Quote I think you're referring to this commit: https://github.com/torvalds/linux/commit/e3e13c9135da969cfe1666a9f24e76b589d5652b That's the one! It look me an embarrassingly log time to narrow that down for various reasons. Quote This problem could be solved in u-boot. IIRC, to populate that to correct value before booting the kernel, we might be able to poke the location with a mby 1000001101000 - Debian
I seem to be missing some of the details in my notes but they were re-writing the PCI id from 11ab:7846 which matches the functional spec to something like 0001:7823 presumably either but accident or to help them separate the mv78230 and mv7840 which set that value the same. It went unnoticed for a long time since the kernel never used to do anything with that value for the mvebu pci driver untilby 1000001101000 - Debian
alf45tar, Great work! I may need to dust off my ix4-200d and see if I can adapt some of it to work with that device. Could you post the dmesg output from this device on the 6.1 kernel? I'm curious to compare how the PCIe initialization looks compared to one of my devices. I ran into a rather nasty issue affecting the PCIe SATA on the Buffalo TS3400D which I believe uses the sameby 1000001101000 - Debian
I spent a little time looking at some similar devices running a RTD1195 and RTD1619 (Buffalo Linkstation LS500 and LS700). I ran into the reference to that two stage u-boot needed for the device-tree's in the mainline kernel but hadn't gotten around to finding it yet. I don't have much to add at this point but I'm glad to see someone taking a look!by 1000001101000 - Debian
Quotehttps://github.com/benoitm974/ix4-300d/wiki UART on connector CN9 (four pins, outer side of board) provides Vcc at pin 1 (marked). Connect Pin 2 to the RX pin of your serial adapter, Pin 3 is GND and Pin 4 is TX. Connection parameters are 115200/8N1. Vcc can be controlled by the adjacent JP1 (pin 1 marked); bridging 1/2 provides 3V3, bridging 2/3 provides 5V - but beware that this does NOT cby 1000001101000 - Debian
How you should proceed depends on what you are trying to accomplish and what your constraints are along several axis. odds are anything you need can be found via http://archive.debian.org or https://snapshot.debian.org/. To start: Installing a new libc version into an ancient Debian install risks messing a lot of things up. Hopefully you've got a backup image of this system you can goby 1000001101000 - Debian
I think you're probably right, I've not looked that closely at the protective MBR in such cases. Any chance you could post the output of gdisk -l /dev/sdx for one of your disks?by 1000001101000 - uBoot
It's probably worth mentioning that gdisk supports Hybrid GPT-MBR partitions and will do the hard bits for you. It will also tell you useful things like the state of the secondary GPT table. In my experience a lot confusing uboot issues come from disks with invalid secondary GPT tables either because they aren't in the proper place after cloning a disk or just left over from being reby 1000001101000 - uBoot
Here is some sample code to read those values and print them on the LCD. I don't know quite where the temp sensor is, I assume it's Celsius. I printed the two fan values I'm aware of. The first is the speed setting (0-3) the second might be the PWM value but I don't really know. #!/usr/bin/python3 import libmicon import socket import time test = libmicon.micon_apiby 1000001101000 - Debian
Good to hear from you! What version of Debian/kernel are you running? (It's not important to my answer, I'm just curious). Sadly, I've only really implemented the minimum required to successfully use the device (disable the onboard watchdog timer, set a welcome message, fan daemon so rackmount devices aren't so loud). Beyond that I've only provided examples of how cby 1000001101000 - Debian
Go you have a link to the GPL source in question?by 1000001101000 - uBoot
Nice!by 1000001101000 - Debian
I spent some time working with an ix4-200d a couple years ago. I found that benoitm974's kernel module for the LCD worked if adjusted the GPIOs but also found that approach to be a pain to work with. I ended up writing some Python to set the display, it should work with the ix4-300d if you change the GPIOs to the proper ones for that device. https://github.com/1000001101000/ix4-200d-rby 1000001101000 - Debian