**** BEGIN LOGGING AT Thu Dec 03 02:59:57 2020
Dec 03 04:44:00 <ByteEnable> Is there a way to disable the file hash checks via the CLI at make or statically via a file?
Dec 03 05:07:59 <mangix> i want to say fill the value with skip or SKIP
Dec 03 05:08:01 <mangix> I forgot
Dec 03 05:08:14 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.2% images and 97.5% packages reproducible in our current test framework.)
Dec 03 08:09:35 <nitroshift> nbd, ping
Dec 03 11:09:53 <rsalvaterra> Guys, quick/stupid question… Does anyone know if it's possible to do persuade u-boot to dump the flash through the serial port…? Not asking for a friend. :P
Dec 03 11:13:53 <rsalvaterra> *possible to persuade
Dec 03 11:18:32 <rsalvaterra> Of course, dumping 128 MiB at 115200 bps is going to be "fun"…
Dec 03 11:25:25 <stintel> :D
Dec 03 11:26:53 <PaulFertser> rsalvaterra: usually yes, there's "md" and some scripts like https://github.com/gmbnomis/uboot-mdb-dump
Dec 03 11:27:16 <rsalvaterra> Right, I was reading this already… https://cybergibbons.com/hardware-hacking/recovering-firmware-through-u-boot/
Dec 03 11:27:55 <rsalvaterra> The idea is to replace a dead NAND with a good one. Now, I have a good flash which I can dump…
Dec 03 11:28:48 <rsalvaterra> … but maybe I can get by just dumping a couple of partitions…? Like the bootloader and system-reserved stuff…?
Dec 03 11:30:31 <rsalvaterra> As long as the partition table (how is raw NAND even partitioned…?) is also copied, or defined elsewhere…
Dec 03 11:31:09 <rsalvaterra> … if the bootloader and system-reserved stuff is there, a normal TFTP recovery should do the trick.
Dec 03 11:43:43 <nitroshift> rsalvaterra, best bet is to get a hardware nand reader/writer
Dec 03 11:43:52 <nitroshift> it only costs ~3 USD
Dec 03 11:47:21 <rsalvaterra> nitroshift: I'd still have to desolder the chip, no? :/
Dec 03 11:47:34 <nitroshift> rsalvaterra, not necessarily
Dec 03 11:47:49 <nitroshift> mine came with various clamps
Dec 03 11:50:24 <nitroshift> rsalvaterra, you said you had a turris afaicr?
Dec 03 11:51:06 <PaulFertser> nitroshift: hm, what NAND IC package do you have in mind?
Dec 03 11:51:19 <PaulFertser> How do you clamp on it?
Dec 03 11:51:57 <nitroshift> PaulFertser, you might be onto something here... my device is a bios / spi flasher
Dec 03 11:52:05 <nitroshift> *not* nand
Dec 03 11:52:12 <rsalvaterra> nitroshift: I have lots of devices… This is a Redmi AC2100.
Dec 03 11:52:29 <rsalvaterra> Hi, dangole! :)
Dec 03 11:52:32 <nitroshift> PaulFertser, just got it out from the drawer
Dec 03 11:53:15 * nitroshift 's memory started going after rsalvaterra's nand chip
Dec 03 11:53:52 <PaulFertser> nitroshift: spi nor comes in SO8/SO16 so yes, much easier with them.
Dec 03 11:54:05 <nitroshift> PaulFertser, exactly
Dec 03 11:54:22 <rsalvaterra> I wish it were SPI-NOR… :P
Dec 03 11:56:04 <rsalvaterra> This is a TSOP48.
Dec 03 11:56:25 <dangole> rsalvaterra: morning :)
Dec 03 12:23:53 <karlp> nitroshift: got a link to a ~3USD version, that comes with clamps? that seems optimistic pricing wise, but if you've got one that cheap, sure, I'll get one too :)
Dec 03 12:25:37 <nitroshift> karlp, i got iy from a store in y country
Dec 03 12:25:40 <nitroshift> *y = in
Dec 03 12:25:45 <nitroshift> grr\
Dec 03 12:25:49 <nitroshift> *y = my
Dec 03 12:26:59 <nbd> nitroshift: pong
Dec 03 12:27:21 <nitroshift> nbd, thanks for your work on 5.10
Dec 03 12:27:30 <nbd> you're welcome
Dec 03 12:27:38 <nbd> i'm currently working on flow offload support
Dec 03 12:27:41 <nitroshift> i got it running on my wrt3200acm's
Dec 03 12:28:18 <nbd> i will push 5.10 to master once we have a release branch
Dec 03 12:29:28 <nitroshift> nbd, nice
Dec 03 12:29:59 <nitroshift> nbd, for mvebu target the patches are the same as the ones i sent you
Dec 03 12:30:08 <nitroshift> minus patch 411
Dec 03 12:30:27 <nitroshift> pci-e collision issue has been fixed upstream
Dec 03 12:34:39 <karlp> nitroshift:ok, which one do you have?
Dec 03 12:35:41 <nitroshift> karlp, it's a ch341a
Dec 03 12:35:43 <karlp> do you have something like this? https://www.amazon.com/Gikfun-Programmer-CH341A-Burner-EEPROM/dp/B01I1EU9LG/ref=sr_1_8?dchild=1&keywords=spi+programmer&qid=1606998895&sr=8-8
Dec 03 12:35:45 <karlp> right, yeah
Dec 03 12:36:02 <nitroshift> yep, that's the one
Dec 03 12:36:06 <karlp> wonn't do for nand anyway, and getting one of them, and a clip for ~$3 still sounds super creative pricing :)
Dec 03 12:39:50 <nitroshift> karlp, it *may* sound, that's what i payed
Dec 03 12:40:32 <nitroshift> store went out of business, clearance sale
Dec 03 12:41:46 <karlp> ok. great advice then.  "get this thing, it will solve your problem, only costs $3, just as long as you can find a firesale somewhere"
Dec 03 12:51:48 <PaulFertser> karlp: I got a SO8 clamp for like a buck, and I already had enough ftdi devices supported by flashrom. Jlink works too. And raspberrypi.
Dec 03 12:52:48 <PaulFertser> Those ch341a programmers are shitty: slow and work with Vcc = 3.3 V only. So any proper JTAG adapter should be better.
Dec 03 12:59:35 <Namidairo> some boards just have an unpopulated pad for spi flash and then you stick a resistor in as well to pull down the boot select pin
Dec 03 12:59:56 <Namidairo> not that board, but some do...
Dec 03 13:05:14 <Nick_Lowe> Guys, can i suggest consideration to move the x86 (32-bit) build to -march i686 and -mtune i686 and cease x86/legacy, x86/geode in to x86/generic (dropping two)
Dec 03 13:06:23 <Nick_Lowe> The Geode is an i686 processor (it just doesn't have NOPL - a bug in binutils/gas is decade long fixed where this instruction was incorrectly generated)
Dec 03 13:08:59 <Nick_Lowe> Most specifically, I cannot see it makes any sense to have a Geode target when -march i686 and -mtune i686 could be used on Generic instead
Dec 03 13:20:07 <Nick_Lowe> Also, for packages, I am not sure it makes sense to build both an i386_pentium4 and also an i386_pentium-mmx when this could I think be a single i386_i686
Dec 03 13:29:42 <dangole> Nick Lowe: there are some embedded x86 platforms which are not i686 (ie. not fully PentiumPro/Pentium II compatible). admittedly, those are mostly historic platforms (via EPIA and such). however, OpenWrt is by now kinda the only option for having a useful out-of-the-box OS on those at all...
Dec 03 13:31:50 <dangole> generally I believe supporting the lowest-end x86 devices the kernel can support is worth it because there are tons (ok, wrong unit given the weight of each of them...) of those machines still alive, many in places where you can't easily grab something better off the shelf
Dec 03 13:33:03 <Borromini> jow: was wondering if we can use https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=c67a97c7317d1f28b0ace76b821f79d9f7ff9f4e since it got reverted from master, but it's in your tree?
Dec 03 13:33:23 <Borromini> might need to tinker with vlans on my mt7621 devices.
Dec 03 13:53:49 <nbd> Borromini: there is no need for dsaconfig anymore. netifd has bridge vlan support
Dec 03 13:54:04 <Borromini> nbd: cool, so i'm fine with current master?
Dec 03 13:54:20 <nbd> yes
Dec 03 13:54:31 <Borromini> ok :)
Dec 03 13:54:45 <Borromini> i take it i don't need ip-bridge or ip-full either anymore? since dsaconfig relied on those.
Dec 03 13:59:02 <nbd> right. netifd uses netlink directly
Dec 03 13:59:16 <nbd> ip-bridge might be useful if you want to check the status
Dec 03 13:59:21 <nbd> but it's not needed for configuration
Dec 03 14:03:23 <Borromini> cool, thanks.
Dec 03 14:46:18 <Nick_Lowe> dangole Hmm, as far as compatibility impact of compiling for i686, which need to be understood and digested:
Dec 03 14:46:20 <Nick_Lowe> VIA Edens based on the 'Samuel 2' design do not support CMOV or NOPL. (These would break.)
Dec 03 14:46:20 <Nick_Lowe> All VIA Edens based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.)
Dec 03 14:46:29 <Nick_Lowe> Via C3s based on the 'Samuel 2'or 'Ezra'/'Ezra-T' design do not support CMOV or NOPL. (These would break.)
Dec 03 14:46:32 <Nick_Lowe> All C3s based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.)
Dec 03 14:46:48 <Nick_Lowe> National Semi's GXm, GXLV and GX1 do not support CMOV or NOPL. (These would break.)
Dec 03 14:46:48 <Nick_Lowe> All Geodes since and including National Semi's GX2 support CMOV but not NOPL. (Introduced in 2002. These would not break.)
Dec 03 14:46:49 <Nick_Lowe> The AMD branded Geodes (GX and LX) support CMOV but not NOPL. (These would not break.)
Dec 03 14:46:51 <Nick_Lowe> The Cyrix 6x86 processors do not support CMOV or NOPL. (These would break.)
Dec 03 14:46:51 <Nick_Lowe> The Cyrix 8x86MX / Cyrix MII do support CMOV but not NOPL. (These would not break.)
Dec 03 14:46:55 <Nick_Lowe> The AMD K6 and K6-2 do not support CMOV or NOPL. (These would break.)
Dec 03 14:50:54 <Nick_Lowe> So, based on this, I suggest dropping the Geode build as pointless and move to an i586 and i686 build
Dec 03 14:52:50 <DonkeyHotei> does presence of lack of NOPL affect anything?
Dec 03 14:54:12 <Nick_Lowe> No, there was a historic binutils/gas bug where it would generate NOPL for i686 but that was fixed a decade agio
Dec 03 14:54:21 <Nick_Lowe> *decade ago
Dec 03 14:55:36 <Nick_Lowe> That's the historic root cause for why people didn't previously build for i686 for these - but it is no longer relevant today
Dec 03 14:55:54 <Nick_Lowe> NOPL is not a valid i686 instruction
Dec 03 14:56:37 <DonkeyHotei> which variant supports it?
Dec 03 14:59:31 <Nick_Lowe> Historic binutils/gas fix for i686: https://sourceware.org/legacy-ml/binutils-cvs/2010-08/msg00057.html / https://gcc.gnu.org/legacy-ml/gcc/2010-08/msg00194.html
Dec 03 14:59:35 <Nick_Lowe> Let me check...
Dec 03 15:02:20 <Nick_Lowe> https://bugzilla.redhat.com/show_bug.cgi?id=579838#c15
Dec 03 15:02:25 <Nick_Lowe> There's some good background in that comment
Dec 03 15:04:41 <Nick_Lowe> It would not be possible to go higher than i686 certainly - My conclusion is that it appears this is historical legacy in OpenWRT that there is a Geode specific build when it's no longer needed and a move to an i586 and an i686 build would make more sense
Dec 03 15:07:38 <Nick_Lowe> NOPL is not standard i686, it was undocumented and has just been de facto supported since the Pentium Pro which is how the binutil/gas bug snuck in.
Dec 03 15:09:11 <DonkeyHotei> is there a variant for which binutils/gas still generate NOPL?
Dec 03 15:11:51 <Nick_Lowe> Not if you choose -march i686
Dec 03 15:12:52 <Nick_Lowe> If you pick for a a pentium something, then yes it can
Dec 03 15:13:44 <DonkeyHotei> right, but those builds have already been removed previously
Dec 03 15:14:58 <DonkeyHotei> out of the variants you mentioned as not supporting CMOV either, do any support bswap or cmpxchg/xadd?
Dec 03 15:17:46 <Nick_Lowe> Yes they all do
Dec 03 15:18:11 <DonkeyHotei> then relegating them all to i586 is not the best option
Dec 03 15:18:36 <Nick_Lowe> They're 486 instructions and 586 is a superset?
Dec 03 15:19:19 <Nick_Lowe> As such, targeting for i586 would be expected to generate these I would hope...
Dec 03 15:19:23 <DonkeyHotei> the bugzilla link you pasted says that binutils/gas generate them for i686
Dec 03 15:23:34 <Nick_Lowe> I think that was in the context of compiling for i386 otherwise
Dec 03 15:23:46 <DonkeyHotei> hmm
Dec 03 15:24:02 <Nick_Lowe> You need i486 to to get bswap and cmpxchg/xadd
Dec 03 15:30:57 * enyc recalls installing 486-in-386-socket upgrade chips into a certain Apricot 386 =)
Dec 03 15:39:38 <DonkeyHotei> dwmw2_gone: when you can answer, do you still plan to extend openconnect to integrate vpnc functionality?
Dec 03 16:04:44 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 97.2% packages reproducible in our current test framework.)
Dec 03 17:56:25 <Hauke> jow: do you still plan a fix for 19.07?
Dec 03 18:13:37 <stintel> hmmm looks like hwrng on rpi0 is broken
Dec 03 18:14:08 <stintel> takes near 90s to reach: random: crng init done
Dec 03 18:28:47 <stintel> ynezz: are you using an SPS30 on a Raspberry Pi ?
Dec 03 18:45:19 <stintel> ynezz: nvm, made a type (dtoverlay=i2c-sensors,sps30 - overlay is i2c-sensor)
Dec 03 18:45:39 <jow> Hauke: yeah, wil ltry to do it tomorrow
Dec 03 18:46:59 <Hauke> jow: ok thanks
Dec 03 19:16:49 <ynezz> stintel: yes, on zero, up 259 days :] seems rock solid
Dec 03 20:23:58 <stintel> ynezz: how are you reading it? and are you storing the result in a timeseries db ?
Dec 03 20:25:02 <stintel> and where did you get cables with the proper connector (JST-ZH 5-pin 1.5mm iirc)
Dec 03 23:37:49 <mangix> Am I wrong in seeing that 19.07 doesn't support WPA3?
Dec 03 23:39:04 <Hauke> mangix: WPA3 is supported, but you have to install a hostapd version with openssl or wolfssl support
Dec 04 00:44:29 <philipp64> got a question about init.d scripts and start_service() … if I need one command to start the daemon, and another to cause it to load it’s config file (oddly doesn’t happen by default), what would that look like?
Dec 04 01:59:49 <mangix> Hauke: do you mean wpad?
Dec 04 02:44:34 <pkgadd> mangix: wpad-openssl (or wpad-wolfssl, but I wouldn't recommend the later9
Dec 04 02:45:15 <pkgadd> the plain wpad can't do WPA3
Dec 04 02:52:42 <mangix> pkgadd: yeah. I see it now.
**** ENDING LOGGING AT Fri Dec 04 02:59:56 2020