<neggles>
Grommish: sorry i got distracted by desoldering eMMCs from femtocells
<neggles>
hey, Qualcomm? Why do these all run android?
<Grommish>
neggles: Ok, so.. question, can I filter out arm targets for hardfloat but the FEATURES fpu
<neggles>
yes, with the exception of 4 subtargets that are missing it
<neggles>
easy enough to fix
<neggles>
and it's not like anything breaks if `fpu` is missing from FEATURES
<Grommish>
neggles: I started with armv7-openwrt-linux-muslgnueabi.. there is also a muslgnueabihf target.. if I see a FEATURES fpu, I can safely set hf?
<neggles>
yes
<Grommish>
the regular defaults to +soft-float
<neggles>
also isn't it just muslabihf
<Grommish>
Not according to the build system
<Grommish>
*shrug*
<Grommish>
I use what it gives me because it's esay to just call the file whatever than think to hard on it
<Grommish>
I don't know the ABI conventions, so.
<Grommish>
Is there an armv7 target that is soft-float?
sanjay has joined #openwrt-devel
<neggles>
Grommish: yes, many of them
<neggles>
armv7 covers all cortex-*
<neggles>
well
<neggles>
a7 a9 a8 a15
<Grommish>
neggles: So i just picked a HF target sigh
<neggles>
the 32-bit cortex-As, and not all of those have FPU
<Grommish>
If I key to FEATURE:=fpu as a way to send those to HF and the rest to SF, then that'll solve most of the issues
<Grommish>
Or CONFIG_HAS_FPU?
<Grommish>
Anyone know if that is consistent?
<neggles>
should be, I imagine it's looking for 'fpu' in FEATURES :P
<neggles>
also, uh,
<neggles>
RUST_COMMOM_ARGS <-- i suspect this should be RUST_COMMON_ARGS
<neggles>
they're not necessary to run rust binaries on the target
bobsy has joined #openwrt-devel
<bobsy>
ahoy-hoy
<Grommish>
Maybe, but they have InstallDev calls that need to be done
<bobsy>
\x: ru any good at creating packages?
<Grommish>
They are there because they error without it
<Grommish>
I had nothing to base this Makefile on
<\x>
bobsy: way above my paygrade man, im mostly a hardware guy sorry.
<Grommish>
but, it was early and I'm always willing to pull it out and test
<neggles>
you should not need to be depending on any _target_ packages to build and install this toolchain
<\x>
you have to wait for robimarko here for ipq60xx chit-chat
<bobsy>
if i use git as pkg_source where do i derive the the version hash and the mirror_hash from?
<Grommish>
neggles: true. Let me get this workign and then we can break it?
<bobsy>
\x: yeah cool
<\x>
bobsy: actually back then i even asked here on how to enable nvme support as i didnt know that make kernel_menuconfig thing hehe
<neggles>
they need to be installed on whatever's building the image, sure
<Grommish>
neggles: It takes so long to compile I'll break them after I'm sure they work :D
<bobsy>
i'd love a hand creating this package if anyone can hlep
<Grommish>
So, do me a solid and comment that on the PR?
<\x>
bobsy: have you gotten the board to boot?
<\x>
with your own compiled fw
<bobsy>
\x: no but i have it ready to flash
<\x>
yeah better wait as if something happens youll have to do some recovery work, and its kinda hard to recover and write on nand
<\x>
if its spi nor then you can just backup with a cheap flasher
<bobsy>
yeah i'd rather spend my time working on this package so that depending on what route we/i go with the firmware there is the packages ready for the task at hand
<bobsy>
any assistance would be greatly appreciated
<neggles>
heh
<bobsy>
i've done plenty of bsd ports in the past, but over a decade ago
<neggles>
you're gonna have some trouble with that, since you can't hook anything that's not been approved by google/helium inc. up as an actual proof-of-coverage miner as of yet
<neggles>
but
<bobsy>
so i get the gist of it but its been so long
<neggles>
suggest you get the device working before you try to add this :P
<neggles>
what *is* the device
<\x>
you can probably try another target first, like the nearest target
<bobsy>
neggles: well i have compiled an image to flash
<\x>
ipq60xx is aarch64 so you build for that, statically.
<bobsy>
its a wallys_dr6018_v4
<\x>
thats what i did when i built dropbear for my ont
<bobsy>
well, i'll just resort to another valium for now and go watch WW3 start on TV
<neggles>
you can still set up a gateway with DIY hardware
<bobsy>
right
<bobsy>
ok
<bobsy>
and?
<neggles>
and it will work, and if anyone uses it for data they'll pay you
<bobsy>
right
<neggles>
you just don't get paid for having it in the first place / covering an uncovered area
<bobsy>
uh
<bobsy>
i see
<bobsy>
hmm
<neggles>
(which is the overwhelming majority of the payout)
<bobsy>
bah humbug
<bobsy>
why did you mention google?
<bobsy>
what association does google have with helium?
<neggles>
because google run helium
<bobsy>
oh well then
<neggles>
they *created* it
<bobsy>
i'm going to go punch someone in the face then
<neggles>
it's not governed by them, but they're the ones throwing all the money into making it be A Thing
<bobsy>
yeh ok
<neggles>
also, ipq6000 is way too new to be supported until we bump openwrt to the next kernel revision
<bobsy>
okj
<neggles>
you can probably get it to *work*
<neggles>
but you won't get wifi
<bobsy>
so what are the chances of this board ever being a miner?
<bobsy>
not with ath11k?
<neggles>
a PoC miner? never. a regular old gateway node? should be easy, just compile the miner for the firmware I assume the OEM provided
<neggles>
which is no doubt based on QSDK's Not-OpenWrt
<bobsy>
hrmm
<slh64>
Grommish: by convention and agreement between ARM and distributions, ARMv7 is hardfloat (only) - that didn't prevent at least one vendor to omit an fpu... (no idea if OpenWrt supports any of those)
<\x>
bobsy: even the chinese when using ipq60xx they still dont use wifi
<bobsy>
neggles: i gtg punch something, i'll be back later to talk rationally about it
<\x>
it has some memory issues iirc
<neggles>
ath11k is a dumpster fire
<\x>
but they say its real good for wired routing and encryption/tunneling
<bobsy>
oh right
<neggles>
you can make it work just fine if you essentially transplant the QSDK kernel and drivers over
<Grommish>
slh64: Interesting.. There is a native armv7_unknown_linux_musleabi for +soft-float which is why i was asking
<bobsy>
i have the board running with the firmware that came with it
<\x>
ipq60xx is a hit on china as its a cheap way to tunnel 500Mbps++ for them
<\x>
this is a 20$ device that allows them to tunnel 800Mbps++
<\x>
even acwifi owner moved to ipq60xx for his tunneling needs
<neggles>
yeah so this is the same problem we run into with ath11k on absolutely everything
<Grommish>
slh64: But, as long as CONFIG_HAS_FPU is set to y,it'll select HF for a target
<neggles>
256MiB of RAM is just not enough to run ath11k + full-feature NSS
<\x>
neggles: yup, they say you need 512MB minimum and its like its still tight in there
<bobsy>
yeah i rerally cant have this discussion right now loaded up on all sorts of meds
<bobsy>
and majorly triggered
<bobsy>
ill bbl
<neggles>
cya
<bobsy>
(;
<neggles>
\x: there is a profile for running ath11k in a mode that only eats 64? 32?MiB for itself - half what the current minimum is - but it only just barely made it into 5.15 and iirc it's kinda broken
<neggles>
classic qca.
<slh64>
Grommish: the general purpose distros stick to the convention and treat ARMv7 as hardfloat (and ARMv6 or earlier as softfloat) - meaning the softfloat ARMv7 devices remain generally unsupported
Guest273 has quit [Ping timeout: 480 seconds]
<Grommish>
slh64: Gotcha.. Well, it'll support it should it ever have a target that rquires it.. the code is the same with or without.. it's a single extra check. Someone was asking about armv5 support, so I might as well include it
AtomiclyCursed2 has joined #openwrt-devel
<Grommish>
and I guess there are armv6 targets?
<\x>
neggles: yup, memory profiles theyre called iirc
<slh64>
Grommish: the 1st gen RPi and 1st gen RPi-0 are ARMv6+hardfloat
atomiclycursed has quit [Quit: Page closed]
ac has joined #openwrt-devel
srslypascal_ has joined #openwrt-devel
srslypascal is now known as Guest275
srslypascal_ is now known as srslypascal
Guest275 has quit [Ping timeout: 480 seconds]
<neggles>
ARM1176JZF-S
<neggles>
the F means FPU :P vfpv3 specifically
srslypascal is now known as Guest277
srslypascal has joined #openwrt-devel
Guest277 has quit [Ping timeout: 480 seconds]
pmelange has joined #openwrt-devel
swegener has quit [Quit: leaving]
<PaulFertser>
svanheule: hey. Do you probably have any hints regarding flashing with external programmer without desoldering the chip? I tried "barely" powering it via the programmer, and tried powering all the board the normal way while keeping SoC's reset line low but all failed.
<PaulFertser>
svanheule: I suspect I might have miswired something or missed some detail but I have no idea if rtl838x when kept in reset allows to talk to the flash freely or not. Would be nice to have some confirmation.
noltari has quit [Ping timeout: 480 seconds]
pmelange has left #openwrt-devel [#openwrt-devel]
danitool has joined #openwrt-devel
<neggles>
PaulFertser: it depends on whether the SoC tri-states its SPI pins or not when held in reset; sounds like it's not
<neggles>
(ofc svanheule will know whether that is the case :P)
<PaulFertser>
neggles: indeed, that's my current guess. But probably I'm doing something else wrong.
<f00b4r0>
you mean, besides trying to flash in-circuit? :->
goliath has joined #openwrt-devel
* f00b4r0
hides
<PaulFertser>
f00b4r0: flashing in-circuit is fine if there's a known way to tristate the SoC pins. Sometimes it's enough to desolder just flash Vcc.
<neggles>
PaulFertser: the other day I thought of something and suggested it to someone; if you can lift the VCC pin of the chip off the board, and slip a piece of kapton tape (or paper) under it to isolate it from the pad on the board, then attach spi clip, that may work
<f00b4r0>
PaulFertser: it's not "fine". It *can* work, but it's never "fine". You're exposing the SOC's pins to voltage while the SoC isn't powered. That is not fine.
<neggles>
that's what ESD protection diodes are for, it's fiiiiiiiiiiiiine
<f00b4r0>
heh :D
<neggles>
there's not enough supply current from an spi programmer to make a difference anyways
<PaulFertser>
f00b4r0: yes, that's why I prefer to power the target board normally and make SoC tristate its pins.
<f00b4r0>
*nod*
<neggles>
personally I just pull the chip off and chuck it in a ZIF socket
<PaulFertser>
neggles: yes, that worked for me. This SO16 flash has Vcc not exactly at the edge, so it's not as easy to lift without damaging anything.
<neggles>
ah, 16-pin, ew
<neggles>
if you lift the CS pin and keep it high at power-on, the SoC should fail to boot and *might* just sit there spinning forever... more likely to keep resetting and trying to access the chip
<PaulFertser>
neggles: even though I do not remember blowing anything off boards I still hesitate a bit. Guess I'll just go for it if svanheule doesn't encourage me to recheck something else.
<f00b4r0>
neggles: I was wondering if letting the SoC boot to bootloader and stop there would be enough. The bootloader idling shouldn't touch the SPI bus, should it?
<f00b4r0>
oh
<f00b4r0>
silly me
<neggles>
PaulFertser: you don't need hot air, not really - and the secret to not blowing things off the board is to reduce your flow rate :P i got *so much better* at hot air use once i turned it down from "8" to ~3.5-4
<neggles>
but, wick off as much of the existing solder as you can, then re-apply some leaded solder (tiny bit), apply more flux than seems reasonable, away you go
<f00b4r0>
^
<PaulFertser>
neggles: yeah, I never blow at full speed when desoldering (only when preheating polyurethane glue or some other unrelated activities)
<neggles>
lead-free solder is the bane of any hobbyist's existence
<PaulFertser>
neggles: last time I was desoldering (that was a micro-USB socket from a tablet) I just applied the flux, didn't bother adding leaded solder to the pins, worked fine.
<neggles>
it depends on what specific kind of solder they've used, some of it melts at stupidly high temperatures
<f00b4r0>
neggles: it's the bane of modern electronics :(
<Grommish>
neggles: I think I may have the armv7 arch settled, but I'm sure there will be outliers. I'm gong to check in the monring if it finsihes.. armv7 takes a lot longer than mips hehe.. 5 hours vs 3.5-5 for mips64. If it works, I'll ping you?
<neggles>
e.g. the airspan airunity 587 i dismantled earlier? that stuff doesn't melt till it hits almost 325C
<neggles>
it's insane
<f00b4r0>
ouch
<neggles>
getting the eMMCs off that board was *unpleasant*
<Grommish>
neggles: sharp chisel and a whiskey and you'll be alright
<neggles>
PaulFertser: i just wick off / reflow leaded because it lets me use a much lower air temp, so less risk of board damage and more time to get it 'right'
<aiyion>
is "crypt" an openwrt tool? if so, which pokg does it belong to?
<neggles>
one of those $60 hot air guns everyone uses, set to 325C, flow rate 4/10, doesn't take but a minute to loosen up an 8-pin, 16 takes a bit longer
<neggles>
aiyion: i believe it is part of coreutils/busybox
<aiyion>
thanks
<f00b4r0>
neggles: then again, what the temp accuracy of these things? I eventually invested in a proper Weller rework station, that changed my life. That and a good scope.
<neggles>
the hot air gun? calibrated against my FLIR E8, it's within 5-10 degrees
<f00b4r0>
not bad
<neggles>
considering you can make a bigger difference by moving it <1cm, it's close enough
<f00b4r0>
*nod*
<neggles>
Grommish: you jest, but i did end up using a paint scraper to clean the passives off the underside where the eMMC is so I could put my tiny hotplate under it to pre-heat...
<neggles>
I worked out the insanity of this solder when the hotplate hit 300C and held it for over a minute without anything on the top coming loose.. had to heat from both sides, with the pencil set to 420
<neggles>
u n p l e a s a n t.
<neggles>
but the chip survived and i got a clean dump so mission accomplished
<f00b4r0>
risky, too.
<Grommish>
neggles: Jest? Tsk.. You just need a sharp chishel and a dead-blow hammer and a cliean strike.. you can do eet!
<neggles>
*that* is how you tear all the pads off the bottom of the eMMC :P
<neggles>
the connection from ball to PCB is stronger than ball to chip
<neggles>
f00b4r0: yeah, this one was already trash - they glued one of the m.2 cards into the thing and i accidentally tore several pads off while trying to loosen it... - so i don't care what happens to the board
<neggles>
also they cost about US$30 at the moment
<f00b4r0>
heh :)
<neggles>
and i have two more
<neggles>
and five of the t-mobile/alcatel femtos. getting the eMMC off one of those is going to be "fun"... they underfilled it
<Grommish>
My hands aren't steady enough for that kinda stuff, unfortuneately. :/
<neggles>
*de*soldering BGAs is easy, don't need steady hands for that
<neggles>
it's reballing and resoldering that's hard
<f00b4r0>
i have a "retired" alcatel 3G femto here, i should probably take a look at what can be salvaged in there
<neggles>
nothing.
<f00b4r0>
ok :)
<neggles>
well, there will be an 8-16MB SPI NOR, buried in plastic
<neggles>
plasticky-siliconey polyurethane potting compound which just, does not come off nicely
<f00b4r0>
yeah I know exactly what you're talking about :(
<neggles>
and depending on whether it's the gen1 or gen2 model, a TSOP-56 or BGA-something parallel CFI NAND of 128 or 256MiB
<ynezz>
aparcar: pls don't forget to change status of the applied patches in patchwork, thanks
<neggles>
gen1 contains one of my fav little chips, the picochip pc302, but unlike AT&T, alcatel-lucent actually enabled secure boot
<neggles>
jerks.
<neggles>
fused off the JTAG, too. (AT&T did not)
<neggles>
been meaning to get around to building a custom distro for the DPH-153, and/or digging through the software to find some way into the thing *without* JTAG
<neggles>
but UMTS/HSDPA are lame, GSM and LTE/NR are where all the fun is
<f00b4r0>
sounds non-trivial
<Grommish>
HPSA+ still around and active?
<neggles>
that'd be "3G"
<neggles>
or "4G" if you're AT&T
<Grommish>
HPSA+ is only for GSM.. CDMA for Sprint/TMo prior though.. But I thought they ended all 3G/Non-VoIP devices at least in the US
<neggles>
not yet
<neggles>
soon(tm)
<PaulFertser>
f00b4r0: I'm happy enough with TS100 soldering iron and some cheap hotair in lukey station seems to work fine for the purpose.
<neggles>
f00b4r0: ehhhh. the DPH-153 is an ip.access Nano3G with a weirdo ramips chip glued to the side of it (that doesn't do much). the actual hNodeB part of it is literally the nano3G firmware with a bunch of Cisco garbage attached to handle TR-069/autoprovisioning
<Grommish>
*nod*
<enick_479>
ynezz: uhm, which one did I forget?
<neggles>
it was not super difficult to bamboozle u-boot into turning on the console, then delete some symlinks + add some entries to a script in the config partition (which the system runs on boot) to kill the cisco management stuff
<neggles>
works quite well with osmocom
<neggles>
but all in all it's quite a chore and what you end up with at the end is... meh
<neggles>
these LTE femtos are much more interesting, even if they're *literally all goddamn QCA and literally running android*
<neggles>
Grommish: happy to test whatever btw :P
ac has quit [Remote host closed the connection]
<Grommish>
neggles: Appreciate it! I think I'll need to drop a separate .mk file as jow suggested for the environmental stuff, but not that big a deal
<PaulFertser>
neggles: or I'm pretty bad properly connecting everything to my TUMPA...
<neggles>
PaulFertser: possibly, are you using a soic clip? or just solder-tagging wires directly to the pins?
<PaulFertser>
neggles: clip
<neggles>
double-checked your orientation & that the clip is actually contacting?
<PaulFertser>
neggles: kinda. Should probably do it again. You know it's not the first time I connect an SPI NOR chip...
<neggles>
PaulFertser: look, I figured, but if your clips are anything like mine, they don't care how many times you've used them :P
<PaulFertser>
:D
<PaulFertser>
neggles: don't get me wrong, your feedback is appreciated and actually helpful.
robje has quit [Quit: "I'll be back"]
robje has joined #openwrt-devel
<neggles>
PaulFertser: I getcha :) i only mention b/c the number of times i've been caught out by something stupid like a misaligned clip after 30+min of troubleshooting...
<PaulFertser>
neggles: yep
<neggles>
PaulFertser: I keep trying to find better things to use for flash dumping, but I always end up back at CH341A + clip or https://www.aliexpress.com/item/32793054513.html one of these + flashrom
rua has quit [Quit: Leaving.]
<neggles>
if just attaching the clip doesn't work, chip's coming off
<neggles>
i've been known to bridge all the pins on a 16-pin with leaded solder & melt the whole puddle with my big angry JBC iron, lift one side at a time
<neggles>
but i would not recommend
<neggles>
it's weird that the SoC would be pulling down pins sufficiently to interfere, even when powered off, but I guess it's just down to how the ESD diodes etc. are configured
<neggles>
f00b4r0's earlier comment, that once it's sitting in the bootloader console it shouldn't be accessing the flash at all, is a valid point - maybe reattach the chip's VCC, disconnect the VCC pin on your clip, boot to u-boot console, plug in your reader's USB, and try reading it out?
rua has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<PaulFertser>
neggles: if only I had u-boot console... Somehow UART got damaged, neither outputs nor inputs anything but device boots normally.
<PaulFertser>
neggles: also, I think it's all pinmuxed to SPI at the very beginning, so the SoC will interfere in u-boot console.
shibboleth has quit []
shibboleth has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
Habbie has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<PaulFertser>
neggles: hot-aired it, still can't connect. Guess I need a break :)
<enick_479>
robimarko: yes matrix gives me a hard time
<neggles>
PaulFertser: well. that's, not great
<neggles>
it's gonna be something really dumb, it always is :P
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<PaulFertser>
neggles: got it connected now, guess I confused myself by first trying to use JTAG interface and then switching to SPI header that's in parallel to the buffer but without properly disabling the buffer.
<neggles>
PaulFertser: ah, yep, that'd do it - glad it's working now! (see! it _was_ something silly!)
clandmeter has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
clandmeter has joined #openwrt-devel
Habbie has joined #openwrt-devel
rua has quit [Quit: Leaving.]
SherlockDomes has joined #openwrt-devel
rua has joined #openwrt-devel
<svanheule>
PaulFertser: I've always taken off the flash chips and reinstalled them in a socket, if I wanted to flash them manually (as far as I remember)
<svanheule>
neggles: I've never touched the SPI hardware on these realtek SoCs, and I don't even know if the GPIO pins can be tri-stated. But I appreciate that you thought I would have such a thorough understanding of these completely undocumented chips :P
<svanheule>
(on second thought, configuring a GPIO as input would put it in a high impedance state...)
<PaulFertser>
svanheule: thanks, I ended up desoldering and now I soldered it back, all fine so far.
goliath has quit [Quit: SIGSEGV]
<neggles>
svanheule: haha, I assumed PaulFertser was asking you for a reason and you might have checked what the state is in reset :P
<neggles>
typically you tristate a pin by configuring it as an input and an output at the same time, with no pull-up or pull-down - tho on most SoCs and modern MCUs there’s an explicit “output driver disable”
<PaulFertser>
neggles: yes, I basically assumed that someone has already tried flashing rtl838x-based boards without desoldering and their experience might be useful for my case.
<svanheule>
neggles: that feature is something I've only seen on the RTL8231. The SoC itself appears to have some drive strength/slew rate control bits, but that's about it (not that I've hooked up a scope to see what these do)
<PaulFertser>
neggles: no, tri-stating is usually "input" and "no pulls".
<svanheule>
PaulFertser: I think Birger uses a clip to dump/flash his devices. Can't remember doing that myself though
<PaulFertser>
svanheule: thank you. BTW, did you see in backlog that I have a SoC here with damaged UART? Apparently I mixed up the wiring being tired on Friday evening a week ago, and as the result device's Tx is stuck at ~2.5 V and Rx doesn't seem to be getting any data, I couldn't stop it by pressing Escape. That's the reason I was reflashing the memory directly.
shibboleth has quit [Quit: shibboleth]
goliath has joined #openwrt-devel
<svanheule>
PaulFertser: ah no, missed that while I skimmed through the backog :( What device did you break?
<PaulFertser>
svanheule: dgs-1210-10 (non-PoE) R1
<svanheule>
PaulFertser: if that's the same board as the F1, I wouldn't be surprised if it didn't have any input protection. Surely I've mixed up RX/TXT pins in the past, but (luckily) all my consoles still work
<PaulFertser>
svanheule: yeah, it's the first time I see UART break, probably this Realtek is really sensitive.
<PaulFertser>
svanheule: another possibility is of course ESD.
<PaulFertser>
btw, I was surprised to see non-PoE version to have seriously different layout but seemingly identical software-wise.
<Grommish>
Anyone running a armv7-hf device that wants to test to see if this draws a pretty fractal or just SIGILLs?
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
lol I just reduced my M300 image build time by > 4 minutes
<Grommish>
stintel: That happens to me, but usually it's because I forgot to turn something back on :)
<stintel>
Grommish: patch should be on the ML by now :)
<Grommish>
stintel: I can't do the MLs.. I get so much now my OCD doesn't allow me to leave them unread
<Grommish>
stintel: Is that going to override a manual -jx on the make?
<stintel>
it's going to let mksquashfs use its default instead of hardcoding it to use only 1 core, the behavior of ignoring make -jX was already there
<Grommish>
stintel: I ask because I purposely do a -j5 instead (of the 8 threads available) so I can continue to actually use the machine. If mksquashfs calls a -j$(nproc) during my build, WSL2 and Win10 are just going to crumble :D
<Grommish>
Right, but I'm worry about the other way and overloading the system by hammering ALL the cores/threads
<Grommish>
During the compile
<stintel>
I guess this can be a config option
<Grommish>
You could just do $(nproc-1)
<stintel>
as this might be needed to avoid it breaking reproducible builds
<Grommish>
That will use all but 1, should be fine
<Grommish>
\It at least leaves me overhead for my YT videos while I wait for the build to finish :D
<Grommish>
Also, for anyone reading the backlog.. I have an exported/inoprted WSL2 instance so I could move the drive, and it breaks the use of .wslconfig :x
SherlockDomes has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
Tapper has joined #openwrt-devel
<bobsy>
neggles: ok i'm willing to put that helium stuff aside for a while and contemplate pkt.cash instead
<bobsy>
im also looking at forking helium, but i'll save that for later.
pmelange has joined #openwrt-devel
<bobsy>
fwiw, i only just woke up and my eyes only just focused enough so i'm not getting around like a pirate with one eye
<bobsy>
damn fatty liver.
<bobsy>
but i'm going to read up on pkt.cash
shibboleth has joined #openwrt-devel
<Slimey>
hi everybody
Misanthr- has joined #openwrt-devel
<stintel>
o/
Misanthropos has quit [Ping timeout: 480 seconds]
<Slimey>
:p
<Slimey>
ever just try putting random valid email addresses of people you have had with contact before into ms teams and its a valid contact to chat with
guerby__ has joined #openwrt-devel
guerby_ has quit [Read error: Connection reset by peer]
<shibboleth>
what's the state of .ax support? i've been holding off, waiting for 6e-capable devices
<shibboleth>
ath11, intel?
pmelange1 has joined #openwrt-devel
pmelange2 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
eduardo010174 has joined #openwrt-devel
pmelange1 has quit [Ping timeout: 480 seconds]
<aiyion>
Where do I need to put an executable sh-file in an openwrt backup in order to make sure it was run on boot?
fda has joined #openwrt-devel
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
eduardo010174 has quit [Quit: Leaving]
<aiyion>
anybody? -.-'
pmelange2 has left #openwrt-devel [#openwrt-devel]
<PaulFertser>
aiyion: probably /etc/rc.local ?
<aiyion>
I tried that; putting lines to execute before the `exit 0`
<jow>
yeah, all init scripts are processed, but tat does not mean that bridges are created, ip addresses assigned, wan dhcp lease acquired/pppoe session negotiated
<jow>
so init done != network up
<aiyion>
eh.
<Lynx->
it works fine when you run 'bash CAKE-autorate.sh' and then just CTRL-C from terminal. But my issue is with simply getting the same in init.d file. I have problems with the kill command working properly.
<aiyion>
thanks, that's a big misunderstanding on my end.
<jow>
aiyion: better create a hotplug script in /etc/hotplug.d/iface/
<jow>
react on $ACTION = ifup and $INTERFACE = wan
<aiyion>
Will try, thanks
<aiyion>
While were at it; how do I make e.g. an echos output come up in the bootlog that I can see via serial?
<jow>
either just "logger -t foo"
<jow>
logger -t foo "My message"
<jow>
or echo "My message" > /dev/kmsg
<jow>
Lynx-: and how is your init script looking?
<Lynx->
ok don't kill me when I link it
shibboleth has joined #openwrt-devel
<aiyion>
so if i put `/usr/bin/logger -t foo" in the rc.local (which is executed by `init.d/done`) it's supposed to land on the serial?
<Slimey>
ah i do love my weekends, unsolicited calls wanting to sell me something but i drag the call out into a long conversation as if im interested.
<jow>
Lynx-: then you need to use kill -INT $pid
<jow>
Lynx-: Ctrl-C = SIGINT
<jow>
by default kill sends SIGTERM iirc
<PaulFertser>
Slimey: in russia you'd have a chance to have long conversations with prison inhabitants who would be trying to social engineer you into sending them money.
<svanheule>
PaulFertser: of course, too bad those patches never moved in :(
<Slimey>
lol
<svanheule>
PaulFertser: I'm looking to clean up some of the mess left over after that hurried PR merge...
<PaulFertser>
svanheule: about two weeks ago Knight wrote me that it's possible my patches would be tested soon...
<svanheule>
PaulFertser: fingers crossed then!
<PaulFertser>
svanheule: not sure, probably my reply wasn't properly polite or something, I never heard back.
<Lynx->
jow so I tried just running from terminal 'bash CAKE-autorate.sh', and then echo $! to get PID, then kill -INT $PID. That works perfectly. But the same commands don't work from within the init.d script. Any idea?
<Lynx->
It seems this line works from terminal but not within init.d: --> bash /root/CAKE-autorate/CAKE-autorate.sh&; echo "PID="$! > /tmp/CAKE-autorate-PID
<svanheule>
PaulFertser: seems polite enough to me :)
Borromini has joined #openwrt-devel
<Lynx->
so I am guessing that: echo "PID="$! gives a different result inside init.d script than when run from terminal for some reason
<Lynx->
is $! not always the last PID that was run
<jow>
aiyion: "logger" requires a running syslog infrastructure, if you want to log stuff very early on boot that service might not be started yet
<dwfreed>
Lynx-: you seem to be assuming the shell is bash
<dwfreed>
this would be a quite bad assumption :)
<dwfreed>
openwrt's /bin/sh is busybox ash
<Lynx->
I don't understand why it runs fine with shell / terminal
<Lynx->
but not from within init.d script
<Lynx->
specifically if I run 'bash script.sh' and echo $!, then kill -INT that PID, it works
<Lynx->
the same commands inside init.d script don't work
<jow>
Lynx-: I suggest starting /root/CAKE-autorate/CAKE-autorate.sh as proper foreground command
<jow>
using a procd init script
<jow>
get rid of "&" and that PID fiddling
<Lynx->
you mean just like ./root/CAKE-autorate/CAKE-autorate.sh?
<Lynx->
if I just start /root/CAKE-autorate/CAKE-autorate.sh itself from within terminal, it fails when sourcing 'defaults.sh' because that has a bash style array. I don't really understand why, but I imagine it's to do with what dwfreed stated that this is run from shell not bash. Even though there is the bash shebang at the top of the script.
<bobsy>
mmm cake
<Lynx->
I have the autorate working nicely
<Lynx->
and it's just starting and stopping this that gives hours of time lost :(
<Borromini>
is there something I need to rerun/clean?
Tapper has quit [Ping timeout: 480 seconds]
shibboleth has quit [Quit: shibboleth]
<Borromini>
sorry, should have been more clearer: if i revert the changes to Config.in, the errors go away.
<Borromini>
i am not sure about the internals but reverting that makes sure i can reassemble my .config file again, using split out configuration files
<Borromini>
slh: ping - can you check if 009293c52e637612cd118717a1bea4e142889e09 works for you? you're using split configs as well aren't you
<slh>
as far as the buildsystem is concerned, not really split config - I just have a generic config part and a target specific one, which I concatenate to .config and run make defconfig oldconfig on
goliath has joined #openwrt-devel
<Borromini>
ok, that's what i meant.
<Borromini>
i am concatenating multiple files into > config
<Borromini>
make defconfig breaks with that commit for me
<Borromini>
make menuconfig does work.
<Borromini>
./scripts/diffconfig.sh will act as if my complete config is different with that commit
<Borromini>
ok... maybe I should try the oldconfig at the end as well then
<slh>
for another target, I just replace amd64.init with ath79-tiny.init, ath79.init, bcm47xx-generic.init, bcm47xx-legacy.init, easybox904xdsl.init, ipq40xx.init, ipq806x.init, ipq807x.init, lantiq.init, or realtek.config
<Borromini>
:)
<Borromini>
i went bonkers and i got split out stuff for mbedTLS / OpenSSL / Unbound / LuCI / ... =)
<Borromini>
looks like i need to rebase my patches for realtek as well
<slh>
defconfig without oldconfig tends not to sort the config, making diffconfig and friends harder