Show all posts by user
Bootloader tips and tricks
Re: resurrecting iomega storcenter ix2 u-boot and debian - Yesterday
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
Re: resurrecting iomega storcenter ix2 u-boot and debian - Yesterday
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
Re: resurrecting iomega storcenter ix2 u-boot and debian - 2 days ago
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
Re: resurrecting iomega storcenter ix2 u-boot and debian - 3 days ago
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
Re: Howto create Kirkwood and Mvebu packages? - 2 months ago
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
Re: Mainline Debian on Iomega ix4-300d - 2 months ago
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
Re: Mainline Debian on Iomega ix4-300d - 3 months ago
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
Re: Mainline Debian on Iomega ix4-300d - 3 months ago
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
Re: Debian on ds218play (rtl1296 cpu) - work in progress - 3 months ago
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
Re: Looking desperately for ttl pinout and terminal settings for lenovo arm ix4-300d - 10 months ago
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
Re: Running rtl_sdr on Debian 7, GLIBC - 1 year ago
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
Re: Schizophrenic GPT implementation in first generation Armada 370 u-boot - 1 year ago
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
Re: Schizophrenic GPT implementation in first generation Armada 370 u-boot - 1 year ago
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
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 1 year ago
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
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 1 year ago
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
Re: Porting u-boot to Western Digital My Cloud mirror (Armada 370) possible - 1 year ago
Go you have a link to the GPL source in question?by 1000001101000 - uBoot
Re: WD My Cloud Ex2: Kernel v5.10 with Debian Bullseye and OMV - 1 year ago
Nice!by 1000001101000 - Debian
Re: Mainline Debian on Iomega ix4-300d - 1 year ago
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
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 1 year ago
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
Re: Armada: Setting persistent MAC address. - 1 year ago
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
Re: U-Boot for Buffalo Linkstations - 1 year ago
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
Re: Debian on QNAP Turbo Station (TS-xxx) - 2 years ago
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
Re: Debian on QNAP Turbo Station (TS-xxx) - 2 years ago
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
Re: Debian on QNAP Turbo Station (TS-xxx) - 2 years ago
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
Re: Debian on QNAP Turbo Station (TS-xxx) - 2 years ago
@bhodi Thanks or starting this thread. I'm working on Bullseye support for a bunch of similar Buffalo devices and am curious to hear about any experiences with these older QNAP devices. I'm particularly curious if anyone has TS-409 and what was the latest kernel it worked with.by 1000001101000 - Debian
Re: Debian on iomega storcenter ix4-200d: succes! - 2 years ago
Quotebodhi Thanks, I defer to your experience about this :) I recall some binding for LCD in some Armada boxes. But I don't really know if this LCD needs some driver that is not in mainline yet. I believe the binding is for the shift-register that is used to multiplex the LEDs (I had fun writing a script to find those pins). As far as I could tell when I was looking into it there was noby 1000001101000 - Debian
Re: Debian on iomega storcenter ix4-200d: succes! - 2 years ago
I don't think there is a driver/binding for this type of display (please correct me if I'm wrong about that). Last year I wrote a python script which displays a bitmap on the screen (it can also be used to read the screen). Checkout lcd_test.py here: https://github.com/1000001101000/ix4-200d-research I was originally planning to do a bunch of other things for this device but ranby 1000001101000 - Debian
Re: How to run a python script at reboot? - 2 years ago
I'm assuming you're not using systemd, if you were you can set your script to run after the network is up via a "wants=" field. you should be able to set your script to run have dhcp-client to ensure the network will be up. it's been a while....but don't you put it in rc.6 with a suitable filename (since they get executed alphabetically)?by 1000001101000 - Debian
Re: Question about i2c troubleshooting - 2 years ago
lol, maybe Buffalo forgot a resistor on their board design.by 1000001101000 - Debian
Re: armada 370 L2 cache - 3 years ago
Exactly! Quote Aurora cache disabled: 42 MB/s Aurora cache enabled: 82 MB/s Aurora cache enabled and CPU coherency enabled: 99 MB/s If the 82MB/s->99MB/s checks out I could see going through the trouble of moving to a custom kernel based around this patch and a few others I'm aware of (phy voltage fix, patch to read MAC from atag etc). I suppose I'd need at leastby 1000001101000 - Debian