Show all posts by user
Discuss all things Debian on your device
Re: Debian on Dell Kace M300 - 6 months ago
I think it's ok to distribute the dll (https://www.cygwin.com/faq.html): "4.22. Can I bundle Cygwin with my product for free? Starting with Cygwin version 2.5.2, which is LGPL licensed, yes, albeit it's not recommended for interoperability reasons." I'm not real sure what "bundle Cygwin" means or what that entails (just add the dll to the zip?).by renojim - Debian
Re: Debian on Dell Kace M300 - 6 months ago
bodhi Wrote: ------------------------------------------------------- > JT, > > > Yeah. It would be nice to find out. It is quite > useful for Windows users who are not yet ready to > run a Linux VM. So you have built one under > cygwin? what is the size of that package? The big part of the package is cygwin1.dll which is 3.4MB. The kwboot.exe is only 67k. My ziby renojim - Debian
Re: Debian on Dell Kace M300 - 6 months ago
bodhi Wrote: ------------------------------------------------------- > And there is no kwboot for windows. You can build kwboot from source under cygwin. I don't know about the legality of packaging the cygwin dll with an application or I'd just post a link to an already built version.by renojim - Debian
Re: Zyxel NSA325 no IP - 1 year ago
That fsck error looks awfully familiar. I was getting it not too long ago and I can't remember exactly what the problem turned out to be, but I think it was because over the years I never updated the fstab entry for the root drive. After an update the old entry (which was "/dev/root / ..." and not "LABEL=rootfs / ...") stopped working whereas it was fine before the updaby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I'm pretty sure I tried that with 5.7.1. I have so many builds and versions of things that it's hard to keep them straight, but I have a dtb file with the suffix "nouart-noleds-noworks". I was using 5.7.1 for all my tests since that's the first version where this problem showed up. I've now switched to using 5.17.4 since that's ultimately the version I'mby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I guess TxD/RxD being in the DTS isn't enough? I'm reading "Device Tree for Dummies". :-) I'm sure I'll have some questions.by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
This is the entire procedure: int gpiochip_generic_request(struct gpio_chip *chip, unsigned offset) { #ifdef CONFIG_PINCTRL if (list_empty(&chip->gpiodev->pin_ranges)) return 0; #endif return pinctrl_gpio_request(chip->gpiodev->base + offset); } The old procedure was only the return statement. CONFIG_PINCTRL is absolutely necessary, so you can't just not setby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I found the offending line of new code! Once I figured out how to configure the pin controller from my LKM I was able to locate the call in gpiolib.c and sure enough a change was made right before the call to cause the pin configuration to never happen (and not return any kind of error either). I'm not sure how I'm going to proceed from here. I feel like I've wasted too much timby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
Yeah, you'd think it would be easy, but there's a lot of changes and many, many functions to try to figure out what's really involved in simply trying to set a pin high or low. It doesn't help that they changed variable names in statements that are otherwise identical producing hundreds of meaningless diffs. I can't be the only person in the world that's using GPIOby renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
sudos, that's amazing! I'm not clear on what the "mess up" was that caused this in the first place. Do you believe that when it was received it did not have hardware protection enabled, but something during the process enabled it?by renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
sudos, I just checked on my M300 with U-Boot 2022.04-tld-1 (Mar 20 2022 - 18:15:15 -0700), Kernel 5.16.5, and Bullseye (11.2) and I can set environment variables and they stick after a power cycle.by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
So after a solid week of building kernels and digging through documentation here's what I've discovered: Something changed from 5.6 to 5.7. Kernels before 5.7.1 work and all of those I tried after do not. The linux kernel changelog is less than helpful. The problem in a nutshell is that the configuration of the MPPs doesn't get changed. Using MPP10 as an example, after booby renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
bodhi Wrote: ------------------------------------------------------- > OK. So I guess nobody knows the stock OS login > credential :) Then the installation is still > needed to be a 2-step process. Or with kwboot (but > this introduces another hurdle for newbees). As I recall nobody ever found it. I know I looked and came up empty, so I quickly gave up and mounted the SSD onby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
That's cool. I think the problem is that the build process needs fixdep, modpost, and maybe other binaries when it builds the modules, so they have to be able to run on the host machine. I haven't figured out how to get it to cross compile them. I also haven't been able to figure out how to build just them on the target architecture. I thought "make scripts/" would doby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
Thanks guys! Yeah, I figured out the set up and even how to cross compile to speed it up, but it still takes hours on my Ubuntu virtual machine. Making a change and waiting hours or overnight to see if it makes a difference is painful. It seems like make always pretty much starts over from scratch or otherwise doesn't like something I'm doing. I ran into the wrong binaries in theby renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I've narrowed down the problem to some regression that occurred between kernel version 5.6.3 and 5.7.1. I'm trying to build the kernel myself so I can experiment. Any help in that regard would be appreciated. Is there a particular make target that would speed up the process? Just running make seems to build a lot of unnecessary stuff.by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
It looks like I can control GPIOs in the second bank using 5.17.4, but not the first bank. I tried 10, 11, 14, and 15 and they all give the same result - gpioset doesn't give any error, but the level of the pin never changes. However, I was able to control 49 (17 in the second bank). I haven't tried a different 5.x kernel yet.by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I already tried that. They're pretty much the same anyway. I'm going to try another gpio in that bank and some in the other bank. I don't have to use TxD/RxD if I can find others that work, but it is mysterious why it doesn't work anymore. I may also try an older 5.x kernel to see what happens.by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
Thanks for the suggestion, but unfortunately (or maybe it's a good thing?) I get the same results. With the 4.8.3 kernel I can use gpioset/get, but with 5.17.4, while they appear to work, nothing happens. I removed all references to the LEDs from the dtb and I am able to control them via gpioset and /sys/class in both kernels, but not TxD/RxD. Maybe it has something to do with GPIO10/11by renojim - Debian
Re: Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
Yes, they worked in 4.8.3. I updated a working system from 4.8.3 to 5.17.4 and suddenly I can't control the pins. I first suspected that it was something with my LKM, but when I couldn't control them through /sys/class I suspected there's something more going on. TxD/RxD are the easiest GPIO pins to access on the Dockstar, so that's why I used them. Everything in /sys/clasby renojim - Debian
Can't control GPIO pins after update to kernel 5.17.4 - 1 year ago
I hope I'm missing something simple. I've been working for the last week to update my Dockstar from kernel 4.8.3 to 5.17.4 and once I got past not being able to build LKMs I now find that I can't control GPIO10 (TxD) with the LKM or via /sys/class/gpio/gpio10. I don't get any errors from my LKM or when I export GPIO10 and use direction/value, etc., but nothing happens. I sby renojim - Debian
Re: Executables in linux-headers deb pkg are x86-64 - 1 year ago
Looks good! I was able to build my "Hello, world!" kernel module without any problem. I'm still having issues with the interrupt handler, but I'm sure that's more about trying to figure out what changed between kernel versions. Thanks!by renojim - Debian
Re: Executables in linux-headers deb pkg are x86-64 - 1 year ago
bodhi, thanks for looking into it. The only ones I know that I need are fixdep and modpost and that's because that's where the make fails. I've haven't tried to understand the complexities of what happens when I run make on what on the surface looks like a simple Makfile for LKMs, but clearly there's a lot more going on than what's on the surface. I copied the bby renojim - Debian
Executables in linux-headers deb pkg are x86-64 - 1 year ago
I'm finally getting around to updating the kernel on my Dockstar and I have to rebuild the LKMs I created. Make fails because the executables in /usr/src/linux-headers-5.17.4-kirkwood-tld-1/scripts/ are x86-64. I thought I could just "make" what I needed (it worked for fixdep, not modpost), but that is proving to be troublesome. Looking at the last kernel I had (4.8.3) the execuby renojim - Debian
Re: Migration to Debian from Arch - Armv5 Kirkwood boards - 1 year ago
Sorry, I missed that. I should have known there was a reason. :-)by renojim - Debian
Re: Migration to Debian from Arch - Armv5 Kirkwood boards - 1 year ago
bodhi Wrote: ------------------------------------------------------- > I've updated the u-boot installation post to > include Dropbox links for everything. Looks like I > will have to stop using bitly from now on. I need > to find a better shortening service. I gotta be honest, I've never understood the need for a shortening service. These aren't tweets or tby renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
sudos, I probably can't help much with Java. I ran into the same problem as you and I wasted way too much time trying to get past it with no solution. What I finally ended up doing (if I recall correctly) was installing openjdk-8-jre from https://packages.debian.org/sid/armel/java/openjdk-8-jre . It's good enough for my purposes as I'd never use Java if I didn't have toby renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
bodhi Wrote: ------------------------------------------------------- > So I've upgraded my rootfs to Debian bullseye. It > was a massive change from buster. Tell me about it! It took me a week to get everything working. One thing notable about the internal SATA connector is that it doesn't supply 12V, so an external supply was necessary for me.by renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
As another data point, I've been running 5.16.5 (and Bullseye) for a while now and I'm pushing my M300 pretty hard with a media server, a FTP server for my motion activated cameras, Windows shares, and a pretty big Java (yuck!) process that runs everyday and I haven't seen any problems. The one difference that may be notable is that I'm booting off a USB flash drive and usingby renojim - Debian
Re: Debian on Dell Kace M300 - 1 year ago
I also blindly flashed the new u-boot since I'm trying to clean things up and put this thing into production with a USB boot drive and my "eSATA" data drive (I ran a SATA cable out the slot between the top and the base of the M300). Everything looks good! (As usual. :-) I haven't played with the netconsole stuff yet. Is it still too early?by renojim - Debian