<f00b4r0>
ynezz: https://buildbot.staging.openwrt.org/images/#/builders/62/builds/28 - workaround is working all right. I'll revisit later, see if can come up with something a little less blunt than "rm -rf" which I'm afraid may delete more than we might want. Thanks!
Tapper has joined #openwrt-devel
<f00b4r0>
i also noticed the order of -delete and -print is wrong. Minor details :)
<nwf>
If anyone has a minute, could they look at https://github.com/openwrt/fstools/issues/2 and tell me if I'm completely barking mad? If not, I'll propose a patch as suggested, but I'd like to know I'm not missing anything, first. :)
<raenye>
nwf: superficially looking, you're right (but I only spent a minute looking)
tom- has quit [Quit: WeeChat 3.8]
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<PaulFertser>
Znevna: that's about what it really does: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/upgrade/nand.sh;h=fa29d575a81dafce4b271586cadf01dc643f5bf2;hb=HEAD#l79
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<raenye>
PaulFertser: hey, long time no see. If the mt76 DBDC PR isn't going to be accepted upstream anytime soon, does it make sense to commit it to openwrt as a patch?
<PaulFertser>
raenye: the patch is trivial and anyway mt76 maintainer is nbd, so if he thinks it's not suitable for upstream, it won't be any good for OpenWrt in his eyes either.
robimarko has quit [Quit: Leaving]
<raenye>
I just don't know how acceptable is to nag people about PR, especially trivial ones
<raenye>
PaulFertser: btw, are you familiar with ath79?
<raenye>
I'm working on D-Link DAP-1720 too
<raenye>
took me a while to get initramfs booting, it was just too big at the end
<raenye>
and probably lack of ram is the reason ath9k and ath10k won't load
<PaulFertser>
raenye: a bit
<raenye>
there are all sort of dts tidbits that seem like voodoo to me
<raenye>
I guess that as long as I'm sure bootloader and other important mtd parts are not clobbered, and I have backup of the rest, and I can do bootloader tftp via eth, it's possible to recover from a bad flash
<raenye>
I just couldn't read the whole nor-flash with a CH341A without desoldering
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<PaulFertser>
raenye: yep, but make backups of bootloader and calibration data just in case too, and probably you can recover even if you damage the bootloader with a SOIC clip to connect directly to the flash (if your target has SPI NOR flash for the bootloader).
<raenye>
i got it all
<raenye>
I wasn't able to read it with a SOIC clip
<Habbie>
PaulFertser, what do you put on the other end of the clip? a pi? some CH chip?
<raenye>
most likely 3v3 is too weak
<raenye>
Habbie: most use CH341A
<Habbie>
thanks
<raenye>
but there are a lot of 5v versions
<raenye>
and we usually need 3.3v
<PaulFertser>
Habbie: I prefer an FT2232H board, but yes, rpi or ch34x could work too. The trick is to somehow keep the target SoC in reset while doing it. One sure way would be to just lift the flash Vcc leg off the board. Another method that sometimes works is to feed it limited current so that the voltage is too low for the SoC to attempt starting but enough for the flash to work. If the SoC reset pin is
<PaulFertser>
available worth trying to pull it low while reading, in that case probably no tricks are required.
<Habbie>
right! i did read about the leg trick in here before
<raenye>
PaulFertser: one thing I tried to do and miserably fail is to set lan mac via dts. I know this can be done in preinit, but why can't I read it from uboot-env or devdata like wifi macs?
tlj has quit [Remote host closed the connection]
<raenye>
tried nvmem-cell-cells ethaddr, tried mac-address and mac-address-ascii, but nothing stuck with the ar8033
<mrkiko>
ynezz: yeah, was referring to that memlkea, but I can see it fixed now
schwicht has joined #openwrt-devel
<PaulFertser>
raenye: you should be able to, by defining the right nvmem cell and probably transformations, and assuming the ethernet driver supports it. Can't tell you the current state, sorry, need to sleep now, but will be happy to discuss another day.
<raenye>
PaulFertser: sweet dreams
tlj has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
schwicht has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<dangole>
raenye: nbd told me he prefers patches for mt76 to be sent via linux-wireless mailing list instead of PR on github. that will also give it more review from linux-wireless maintainers and community
<raenye>
dangole: thanks. PaulFertser created the PR (after he kindly solved my issue on the spot) so I guess he'll have the honour of sending the patch to the list.
<raenye>
(but should a beginner developer like me know about this in the first place?)
<raenye>
dangole: and is this true also for LuCI PRs?
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
<dangole>
raenye: no, thought you are talking about mt76 wifi driver. luci is on github only