**** BEGIN LOGGING AT Wed Dec 05 03:00:01 2018
Dec 05 04:34:56 <owrt-snap-builds> build #327 of ipq40xx/generic is complete: Failure [failed pkgbuild]  Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/327  blamelist: Stijn Tintel <stijn@linux-ipv6.be>, Mathias Kresin <dev@kresin.me>
Dec 05 06:02:20 <jow> stintel: something like  KCONFIG:= CONFIG_VIDEO_BCM2835=y@le4.9  should work
Dec 05 07:01:22 <russell--> blogic: i'm trying to using digital mode on a bunch of mt7688 pins that are shared between ephy (ports 1-4) and various other functions, just setting the pinmux'ing seems insufficient. in the datasheet, i'm seeing the mt7688 registore 0x10000060 bit 15 describe as ESD_MODE. also I'm seeing register 0x1000003C and bits 20:17 as "digital pad selection", poking a 1 in there seems to reboot my
Dec 05 07:01:28 <russell--> device. any clues what i need to do?
Dec 05 07:07:58 <blogic> russell--: i was given the padconf register description pdf yesterday by MTK
Dec 05 07:08:07 <blogic> i'll have a look inside later on today
Dec 05 07:09:24 <blogic> russell--: which gpio specifically ?
Dec 05 07:10:01 <blogic> russell--: register 10001360 bit 14->29 map to gpio 14->29
Dec 05 07:10:24 <blogic> that is ports 1->4 each with 4 pins
Dec 05 07:10:48 <russell--> a bunch, mostly the in sd group, e.g. 22-29
Dec 05 07:11:04 <blogic> see what the bits are set to and flib them
Dec 05 07:11:17 * russell-- looks
Dec 05 07:11:55 <blogic> looks like 0 is atpg mode whatever that is and then 1 is gpio 8mA mode
Dec 05 07:12:08 <blogic> and then there is a register to configure atpg mode aswell
Dec 05 07:12:41 <blogic> russell--: wait
Dec 05 07:13:06 <blogic> 10001350 is the E4 register and 10001360 E8
Dec 05 07:14:25 <blogic> the config is 2ma[0 0] 4mA[0 1] 6mA[1 0] 8mA[1 1] with the msb in E4 and lsb E8
Dec 05 07:14:36 <blogic> bits 14->29 on both
Dec 05 07:15:38 <blogic> and then 10001300 sets the pin mode, so 14->29 will be 0 in that register and you need to switch them to 1 to go from atpg->pu mode
Dec 05 07:16:03 <blogic> i think :-) hard to tell from a file generated from a bsdl
Dec 05 07:16:31 <russell--> # io -r -4 0x10001360
Dec 05 07:16:32 <russell--> 10001360:  00000000
Dec 05 07:16:49 <blogic> check 1300 and 1350 aswell
Dec 05 07:17:01 <russell--> # io -r -4 0x10001350
Dec 05 07:17:02 <russell--> 10001350:  00000000
Dec 05 07:17:18 <russell--> # io -r -4 0x10001300
Dec 05 07:17:19 <russell--> 10001300:  00000400
Dec 05 07:17:50 <blogic> that bit 10 is the spi cs0
Dec 05 07:18:04 <blogic> try setting bits inside 1300
Dec 05 07:18:07 <blogic> see if that helps
Dec 05 07:19:38 <russell--> what does atpg mean?
Dec 05 07:20:22 <blogic> dr google says automatic test pattern generation
Dec 05 07:20:33 <blogic> no idea if that is the case
Dec 05 07:20:37 <russell--> lol
Dec 05 07:20:38 <russell--> okay
Dec 05 07:20:51 <blogic> these are signal names from the verilog design files i guess
Dec 05 07:21:03 <russell--> gotcha
Dec 05 07:21:07 <blogic> this is a bare pdf autogenerated by some tool from the bsdl files of the chip
Dec 05 07:21:45 <russell--> we basically aren't using any of the configurable ethernet ports, so i'm going to flip all the bits to 1
Dec 05 07:22:00 <blogic> see if it works otherwise let me know
Dec 05 07:33:59 <russell--> that didn't seem to work, but the AGPIO_CFG register at 0x1000003C seems to be working for me now, i think i figured the register writes need to be 4-bytes
Dec 05 09:03:59 <stintel> jow: I'll try it again, thanks
Dec 05 09:51:01 <ldir> jow: love this commit https://github.com/openwrt/luci/commit/be2d0536f4f6083cc0ba77d4e70915164889ca3e  great stuff - fw display on the archer is *much* more stable
Dec 05 10:21:09 <russell--> blogic: i couldn't find a device tree interface for that register
Dec 05 10:21:47 <russell--> (AGPIO_CFG at 0x1000003c)
Dec 05 11:22:18 <Neighbor11111111> good morning all
Dec 05 11:28:37 <stintel> dedeckeh: ping
Dec 05 11:40:41 <Monkeh> blogic: Can you share that? :)
Dec 05 12:09:06 <dedeckeh> stintel:pong
Dec 05 15:19:54 <mkresin> mangix: would you please have a look at https://github.com/lede-project/source/commit/c7144ec688192c83ec91c4a4ff4f5db06c11e469#commitcomment-31568576
Dec 05 15:21:41 <rotanid> Signature check failed.
Dec 05 15:21:42 <rotanid> Remove wrong Signature file.
Dec 05 15:21:50 <rotanid> when downloading releases/packages-17.01/x86_64/base/Packages.sig
Dec 05 15:21:56 <rotanid> is it only me?
Dec 05 15:22:52 <rotanid> (yes, update to 18.06 is in the works, just to answer this in advance)
Dec 05 16:14:12 <rotanid> looks like someone/something broke the package signatures :/
Dec 05 17:32:24 <owrt-snap-builds> build #328 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/328
Dec 05 18:46:42 <ultito> gninrom
Dec 05 19:10:54 <russell--> mkresin: i'm looking at your commit 287b7aa5835 from back in september. the 3c register also needs to be touched in cases other than mmc, e.g. when any otherwise-EPHY pad is pinmuxed to a digital mode.
Dec 05 19:18:28 <russell--> the pinmux groups involved are: spis, pwm0, pwm1, uart2, and sd
Dec 05 19:33:52 <mkresin> russell--: sure. but my commit neither made it better nor worse
Dec 05 19:34:04 <mkresin> russell--: FIXME: this should be done by pinconf and not by the sd driver
Dec 05 19:34:20 <mkresin> russell--: no pinconf support yet
Dec 05 19:42:20 <russell--> mkresin: i need it, so i'm thinking about the tasteful way of doing it.
Dec 05 20:06:09 <Neighbor11111111> nbd: I'm studying scripts/kconfig.pl mostly out of curiosity. I'm starting to understand it. However I'm interested in the prefix expression language. Is that language derived from another language or create purely for this script? Secondly I can see that setting mod_plus stops CONFIG duplicates overwriting previous values. However the variable mod_plus doesn't seem to apply here. If you have time could you explain
Dec 05 20:06:10 <Neighbor11111111>  what is the meaning behind this variable? I can follow the logic but the naming leads me to believe I'm missing some bigger picture. Thanks in advance
Dec 05 20:09:54 <jow> Neighbor11111111: what exactly do you mean with "prefix expression language" ?
Dec 05 20:10:16 <Neighbor11111111> studying the code it suggests that the input is an expression language that uses prefix form
Dec 05 20:10:29 <Neighbor11111111> for example could run ./scripts/kconfig.pl + configA configB
Dec 05 20:10:44 <Neighbor11111111> it's a prefix language because the operator goes on the left instead of the usual infix that humans are used to
Dec 05 20:11:00 <jow> ah, no this is just poor mans argument processing
Dec 05 20:11:08 <Neighbor11111111> heh
Dec 05 20:12:04 <Neighbor11111111> are you sure? parse_expr definitely looks like a prefix parser
Dec 05 20:13:01 <jow> yeah, seems like a simple rpn notation interpreter using the argv vector as stack
Dec 05 20:13:15 <Neighbor11111111> yeah reverse polish notation is prefix. Very cool I thought
Dec 05 20:14:31 <Neighbor11111111> The operators are "&", "+", "m+", ">", ">+" and "-". They kinda look like shell script operators. Is this what the language is trying to imitate?
Dec 05 20:15:02 <Neighbor11111111> Or is there some other expression language this was derived from?
Dec 05 20:15:44 <jow> looks like a mix of fopen modes and bit operators
Dec 05 20:17:00 <jow> I don't think it tries to imitate shell script, looks more like an ad-hoc dsl to specify multiple config transformation steps in one go
Dec 05 20:17:59 <Neighbor11111111> Ok cool thought so. Just a couple of things. The variable name mod_plus is a bit confusing. It appears to mean disallow override. Would you agree?
Dec 05 20:18:34 <Neighbor11111111> And one last thing I noticed in kernel-defaults.mk you run an expression like so:  m+ + .config.target /dev/null .config.override
Dec 05 20:18:39 <Neighbor11111111> what is the point in /dev/null?
Dec 05 20:18:52 <Neighbor11111111> Surely just do m+ .config.target .config.override
Dec 05 20:21:34 <Neighbor11111111> I guess my first question is what is the motiviation for the m+ operator?
Dec 05 20:22:43 <jow> it looks as if m+ is designed to only set new symbols if they aren't already set or if the new symbol is =y
Dec 05 20:23:13 <jow> so it only allows "upgrading" symbols but an existing CONFIG_FOO=y cannot be overridden with a CONFIG_FOO=m
Dec 05 20:23:26 <jow> while vice versa would be okay
Dec 05 20:23:49 <ultito> jow: As a short feedback, I have 18.06.01 on most of my routers. All works fine, OpenWrt has a point :-)
Dec 05 20:23:53 <jow> CONFIG_FOO=y may replace CONFIG_FOO=m or "# CONFIG_FOO is not set"
Dec 05 20:24:33 <Neighbor11111111> Yeah that makes sense. Upgrading is the word. Thanks jow!
Dec 05 20:25:15 <Neighbor11111111> Do you think the /dev/null in the aforemention kernel-defaults.mk command is unncessary? It appears to be a NOP
Dec 05 20:32:07 <jow> it looks like a nop indeed
Dec 05 20:34:11 <Neighbor11111111> ok great thanks
Dec 05 20:35:31 <jow> the nop got introduced with ea41d3a2881e925e4a8cd74b214fb3f836b1e386 in 2009
Dec 05 20:36:37 <jow> it seems to be an unrelated change, possibly because the original patch author didn't understand the cmdline semantics and simply adapted the expression to the one used in the first change
Dec 05 20:36:59 <jow> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ea41d3a2881e925e4a8cd74b214fb3f836b1e386
Dec 05 20:37:48 <Neighbor11111111> Right but the commit is from Felix? He is the one who wrote kconfig.pl
Dec 05 20:38:12 <jow> the commit message contains a "(thanks sn9)"
Dec 05 20:38:19 <Neighbor11111111> oh right ok cool
Dec 05 20:38:31 <jow> and commits from this era were made with svn, not git, so no proper attributaion, signed off etc.
Dec 05 20:38:49 <Neighbor11111111> very cool
Dec 05 20:39:01 <Neighbor11111111> Were you working on OpenWRT in 2009 jow?
Dec 05 20:40:07 <jow> my first commit was Sun Nov 16 18:03:38 2008 +0000
Dec 05 20:41:23 <jow> gotta run, bbl!
Dec 05 20:42:15 <Neighbor11111111> cool, bye
Dec 05 22:56:05 <Strykar> doesn't musl implement sched_setscheduler? 'root@apu:~# heatppm -t /sys/class/hwmon/hwmon1/temp1_input' gives me 'sched_setscheduler: Function not implemented'
Dec 06 00:09:24 <stintel> Strykar: it does: /usr/include/sched.h:int    sched_setscheduler(pid_t, int, const struct sched_param *);
Dec 06 00:21:11 <owrt-snap-builds> build #668 of layerscape/armv8_64b is complete: Failure [failed images]  Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/668  blamelist: Michael Heimpold <mhei@heimpold.de>, Daniel Halmschlager <dh@dev.halms.at>
Dec 06 00:34:23 <Strykar> stintel, apparently not - https://github.com/MusicPlayerDaemon/MPD/issues/218
Dec 06 00:41:32 <stintel> Strykar: ehr, you're drawing a very weird conclusion. musl implements it, following POSIX. that's it's not compatible with however glibc implements it is a different story
Dec 06 00:45:03 <stintel> hmm, or not. it's implemented as a noop if I follow https://github.com/MusicPlayerDaemon/MPD/commit/817656504dea224dbf849e5e988e277d798ae08e
Dec 06 00:45:38 <stintel> either way you could patch heatppm the same way
**** ENDING LOGGING AT Thu Dec 06 03:00:01 2018