<pinky_>
after I apply a patch should files in build_dir be updated? such as ./build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.4.137/drivers/gpio/gpio-mt7621.c
<pinky_>
oh wait now i see there are seperate instructions for the kernel :(
<pinky_>
why does quilt edit open something that can't be saved because the directory doesn't exist?
<slh>
quilt merely opens your preferred editor (and later diff's the results), everything else if down to the capabilities of your editor
<pinky_>
so i'm in ~/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.4.137 and i "quilt edit platform/0013-gpio-mt7621-Assign-base-field-in-gpio_chip.patch" is this wrong?
<slh>
yes
<slh>
you don't edit a quilt managed patch, you quilt push to the patch you want to modify, then quilt edit the file -of the linux kernel- (not the patch) in the way you want it to be, quilt refresh and continue rebasing the patches behind the one you've just updated
<slh>
but the very basic quilt push/ pop/ edit/ refresh logic is still important underneath it all
<mangix>
on no this nostradamus guy is hitting the packages feed
<mangix>
hopefully he behaves
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
gladiac has quit [Ping timeout: 480 seconds]
<pinky_>
slh: but some of the patches in ~/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.4.137/patches/platform are the mailbox style patch that I was trying to apply
<pinky_>
i'm just trying to add a new one of those
<pinky_>
or, does quilt make those with a quilt edit?
<pinky_>
if so, what if i already have one that i just want to apply?
<slh>
once you enter ~/openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.4.137/, you're now working directly with quilt - *until* you use the buioldsystem again to write it all back, via make target/linux/update package/index V=s
<pinky_>
oh sorry thats what i already had
<slh>
that means "patches/" is more or less off limits
<slh>
at that pint you have updated the top most patch of the stack, the one you've pushed to earlier (as in patches/platform/0013-gpio-mt7621-Assign-base-field-in-gpio_chip.patch)
<slh>
refresh the patches above that point and update the whole environment (buildsystem)
<rsalvaterra>
Not exactly unlimited, but a custom regdb helps. O:)
<mangix>
I remember DD-WRT having a paid upgrade for Atheros hardware to unlock totally illegal frequencies.
<rsalvaterra>
However, more power means a noisier signal, it's a trade-off. I limit it manually.
<rsalvaterra>
I just don't like being told what to do, especially by software. :)
Guest5555 is now known as EqUaTe
EqUaTe is now known as Guest5887
Tapper has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<russell-->
Grommish: rtl838x from the vendor firmware
Guest5887 is now known as equate
equate is now known as EqUaTe
<Tapper>
Hi people can any one tell me how to set the paths in ubuntu under wsl to build OpenWrt again pleas. I did fix it be for but I cant remember how I did it.
<Tapper>
russell-- workind now mate thanks a bunch
<Tapper>
working*
<russell-->
fwiw, in about a week, openwrt will be receiving wifi packets from 40km straight up. wifi is flying on a high altitude balloon, i'm using openwrt on a ubiquiti powerbeam and rocket m2 to sniff in monitor mode with steerable parabolic dishes
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Tapper1 has quit [Read error: Connection reset by peer]
<rsalvaterra>
russell--: So, it's Skynet, instead of Starlink? :)
goliath has joined #openwrt-devel
AdrianFL has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
<russell-->
in january we might be flying something in orbit, but (so far) openwrt is staying on the ground
<mrkiko>
russell--: and what device are you using in the baloon?
<russell-->
a usb ar9271 with a power amplifier
<russell-->
weirdly, my wdr3600 16mb flash hack seems to be broken, image from june boots, current master+myhacks can't mount jffs2
<russell-->
will look more tomorrow
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
minimal has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
f5- has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
nitroshift has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
<neggles>
hmmm... going back over an issue i ran into two years ago where the D-Link DIR-510L can't boot from extroot, worked out why, the GPIO switches rc.d script is what turns on the USB ports and that doesn't happen 'till after the extroot pivot
<neggles>
I can just leave them turned on all the time with a gpio-hog in DTS, but I wonder if that will make an appreciable difference to battery life
<neggles>
probably not, but it would be nice to be able to control them from userspace still
<neggles>
though come to think of it, it's probably a bad idea to be able to turn off power to my extroot USB drive
<mrkiko>
neggles: maybe you can take inspiration from mt7620n_dlink_dwr-921-c1.dts
<mrkiko>
see how the lte modem power is handled
<neggles>
mrkiko: I _knew_ someone would tell me to use gpio-export
<neggles>
:P
<mrkiko>
neggles: :D but... ?
<neggles>
well, I got 2/3 of the way through setting up regulator-fixed entries before I realized the mt7620n kernel config doesn't have CONFIG_REGULATOR / CONFIG_REGULATOR_FIXED
<neggles>
since it seems like The Correct Thing (so to speak) is to add usb-connector entries with vbus-supply set
<neggles>
more effort than it's worth, though. gpio-export it is, then
<mrkiko>
neggles: well, i'm into usb enough to tell; there was a debate in ML about this thing.
<neggles>
mrkiko: yeah, i've read some of it
<neggles>
but I stopped digging when I realized I've probably spent more time going "hmmmm" than I will spend actually using the dang device
<mrkiko>
neggles: out of curiosity, how do you use the system? I wanted to try extroot but never found a convincing enough use casefor me. So I was curious how others use it
<neggles>
mrkiko: on this thing, it's so I can install tcpdump/nmap/the whole plethora of USB-Serial device drivers and use it for a combination of network probe and a battery-powered SSH-to-console-port adapter
<neggles>
it autoconnects a wireshark tunnel over tcp/443 to a VM in our ~private cloud~ (hyper-v cluster), works as a convenient little instant-backdoor device, and has a web based console emulator so I can plug a USB-to-Cisco-RJ45-Serial cable into it & poke console ports on stuff from my phone/whatever
<neggles>
it's convenient to have multiple GB of local storage for packet dumps and not have to worry about running out of flash
<mrkiko>
neggles: nice! :)
<neggles>
it's also set up with a different config on the internal flash, so if you pull the drive it just becomes a dumb wifi AP with a known IP address and password
<neggles>
it's not even remotely _necessary_ but, eh, it's neat
<neggles>
there's an MSP430 handling battery charging and power control, but if the UART is enabled then TX being held high reverse-powers the MSP through its ESD diodes, and now you can't turn the router off.
<neggles>
thanks, d-link
Rentong has quit [Remote host closed the connection]
<mrkiko>
neggles: mhm, but in the official firmware you can turn it off anyway?
<neggles>
official firmware appears to set termios to force BREAK unless it's doing a firmware update
<mrkiko>
neggles: and this stops the issue from happening
<neggles>
mrkiko: yes'm, forcing BREAK pulls the SoC's UART TX line low instead of high
<mrkiko>
neggles: and what was the issue in implementing it in openwrt
<neggles>
mrkiko: the problem is that it has to remain in BREAK when the system has shut down
<neggles>
or shutdown would have to reconfigure the pinmux to change those pins back to GPIOs
<mrkiko>
neggles: ok, but if a process does this thing, and then you slideswitch the device, it shouldn't release the BREAK. Or am I missing something?
<neggles>
mrkiko: closing the TTY will typically reset force-break, and it gets closed during shutdown
<neggles>
not sure if there's a way around that
<mrkiko>
neggles: but at least you have mt7610E working now :D
<neggles>
mrkiko: yep! works much better than it did at the time :P and all I really lose here is battery percentage & charge status monitoring, which would be nice to have, but aren't strictly necessary
<neggles>
it's only 600 baud, guess I could always gpio-bitbang a UART
<mrkiko>
neggles: can you use the device without battery, just out of power?
<neggles>
mrkiko: no, if you unplug the battery the MSP430 will pull the low battery shutdown pin on the SoC
<neggles>
but if it's got external power even if the battery is dead flat it'll run
Tapper1 has quit [Ping timeout: 480 seconds]
<neggles>
it's just inconvenient to not have a clue what the battery level is until the battery LED turns orange at 25%
valku has joined #openwrt-devel
<neggles>
one of these days I'll get sick of dealing with annoying issues like this and just make my own little box with an RJ-45 console port, battery, ethernet, wifi, and passive PoE-in
decke has quit [Quit: Leaving.]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
aleksander has quit [Quit: Leaving]
<mrkiko>
neggles: :D how do you plan to build it? Based on what?
<neggles>
mrkiko: not sure just yet, maybe an amlogic chip like the S905Y (maybe just use a radxa zero, save the trouble and cost of doing BGA routing) or an older allwinner, even an STM32MP157 but something a bit faster would be nice
<Slimey>
oh hi
<neggles>
hello
<Slimey>
how is everyones morning/night :P
<mrkiko>
afternoon here I guess, fine thanks
<mrkiko>
Is there a PR in progress for porting mt7621 / mt7628 and friens to 5.10, if porting is planned at all?
stintel has quit [Ping timeout: 480 seconds]
SherlockDomes has joined #openwrt-devel
owrt-snap-builds has quit [Ping timeout: 480 seconds]
owrt-snap-builds has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
hexa- has quit [Quit: WeeChat 3.1]
Acinonyx has joined #openwrt-devel
hexa- has joined #openwrt-devel
<rsalvaterra>
mrkiko: ramips already supports 5.10 as testing kernel version.
Acinonyx_ has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #openwrt-devel
<mrkiko>
rsalvaterra: oh - I missed it. Thanks!
Rentong has joined #openwrt-devel
<rsalvaterra>
After 21.02 is out, the testing version will selectively be promoted to stable. The next testing version will likely be 5.16, if it's the last release of this year (the next LTS).
<hauke>
rsalvaterra: here is a nice crystal ball, which predicts when which kernel version will be released: http://phb-crystal-ball.org/
<stintel>
but does it predict the next LTS :)
<hauke>
stintel: someone should add an extension to this script
<hauke>
my managers would love it
PaulFertser has quit [Ping timeout: 480 seconds]
<stintel>
:)
jbowen has quit [Quit: leaving]
PaulFertser has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 481 seconds]
<russell-->
weirdness continues with my flash-hacked tplink wdr3600, comparing the device tree, they are afaict identical with the exception of partitions, and yet stock wdr3600 works, my 16MB flash version doesn't, maybe u-boot? i notice the cpu frequency is slightly different
<russell-->
"sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669584382ns" (stock) vs "sched_clock: 32 bits at 275MHz, resolution 3ns, wraps every 7809031678ns" (hacked)
<russell-->
tftpboot'ing an initramfs firmware fails, with:
<russell-->
Stopping network... OK!
<russell-->
## Error: LZMA error '1'!
<russell-->
Uncompressing Kernel... ERROR
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<russell-->
hmm. u-boot related. stock u-boot can tftpboot the initramfs image, but the pepe2k u-boot doesn't like it
Rentong has quit [Ping timeout: 480 seconds]
<slh>
kernel too large (for the bootloader)?
<russell-->
whatever the problem is, tftpboot'ing has been broken for a while on pepe2k's u-boot (or at least my slightly hacked version)
goliath has quit [Quit: SIGSEGV]
<russell-->
even tftpbooting the openwrt-19.07.1-ath79-generic-tplink_tl-wdr3600-v1-initramfs-kernel.bin release gives the same error