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
Turns out the PCI issue for non-DTB devices was less complicated than I thought…. Or at least working around it is fairly simple. The PCI setup attaches a map_irq function to a function pointer so that the proper irq can be assigned when a device is detected. If the driver making the call is in a kernel module that call crosses a namespace boundary and results in a kernel panic. This issue canby 1000001101000 - Debian
I have a similar quick and dirty solution I use in my installer: https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Tools/ifup-mac.sh I know someone created an out-of-tree kernel patch that mimicked the method buffalo/marvell use to pass the MAC though that repo appears to have disappeared. I never used it personally since I have this weird fixation with compatibility with Debian&by 1000001101000 - Debian
Sorry, I've been away and didn't see this. I've got a device tree for that device here: https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/device_trees make sure to use the wxl device tree (I believe there is mainline one too), your comment about 64 vs 128mb has me worried you may have the wrong one in mind.by 1000001101000 - uBoot
Neat! On a brighter note, I was able to Upgrade my LS-GL to Bullseye (with Debian's 5.10 kernel) without issue. Looks like some Orion5x devices should work just fine.by 1000001101000 - Debian
Quotebodhi Ah, I see that the 2MB kernel size is artificial (limited by the stock MTD partition). That sounds worth a shot, though it might not be the only limitation. I know from experience on some of those Orion5x devices uboot crashes if you try to load a kernel file larger than 2mb. It's also pretty common for NAS devices that boot from mtd devices to not have drivers for their onboarby 1000001101000 - Debian
I believe the specific issue is that the uboot on these older devices can't handle kernel images larger than 2MB and it's become virtually impossible to compile a kernel that small these days. I have some ideas to work around that limit but haven't spent much time looking at it yet. I'm guessing the TS-409 would have separate issues since it is an Orion5x devices that usesby 1000001101000 - Debian