**** BEGIN LOGGING AT Fri Jul 19 02:59:57 2019 Jul 19 05:09:42 morning Jul 19 07:00:46 jow: hey Jul 19 07:24:59 blogic: 'lo Jul 19 09:06:35 'stupid' question alert Jul 19 09:06:48 no Jul 19 09:06:52 (answer) Jul 19 09:07:00 awww Jul 19 09:07:35 This is 'make' related but more like shell/make interaction Jul 19 09:08:08 I have a command, let's call it 'foo' Jul 19 09:08:13 Red aleert! *Riker sound* Jul 19 09:08:41 invoked from shell: 'foo' Jul 19 09:08:54 if I pass parameters they are: Jul 19 09:09:49 'foo bar1 bar2 bar3' Jul 19 09:10:34 sometimes I see things invoked as 'foo BAR=foo BAR2=foo' Jul 19 09:10:47 and then sometimes I see this: Jul 19 09:11:15 BAR=foo BAR2=foo foo bar1 bar2 bar3 Jul 19 09:12:21 I *think* the difference is that the last case is setting environment variables BAR & BAR2 Jul 19 09:12:47 foo 1 2 3 is simply an argument vector (execl("/bin/foo", "foo", "1", "2", "3")) Jul 19 09:13:28 foo X=1 Y=2 Z=3 is like the previous form but some utilities (e.g. gnu autoconf ./configure) interpret arguments in the form key=val as environment variables Jul 19 09:13:44 that requires explicit application support though Jul 19 09:14:14 X=1 Y=2 Z=3 foo on the other hand is standard shell notation for setting environment variables for exactly one command invcation Jul 19 09:15:00 so for ./configure, FOO=bar ./configure and ./configure FOO=bar should be equivalent Jul 19 09:15:12 so 'X=1 foo ; foo2' means foo2 wouldn't have env X=1? Jul 19 09:15:18 correct Jul 19 09:15:35 * ldir goes and digests this info Jul 19 09:15:40 '(export X=1; foo; foo2)' would work in this case Jul 19 09:15:47 buuuurrrrrp Jul 19 09:15:52 spawns a subshell, exports $X for all child processes Jul 19 09:16:33 however since "make" spawns a new shell for every line, you likely do not need a subshell to isolate $X Jul 19 09:16:52 a mere 'export X=1; foo; foo2' would have the same effect in make Jul 19 09:17:23 is trying to digest https://pastebin.com/rumQVhp5 Jul 19 09:18:03 ah gnu make is another such program Jul 19 09:18:11 make foo=bar is equivalent to foo=bar make Jul 19 09:18:30 I believe this was done for portability reasons Jul 19 09:18:34 and how that relates to our package makefile entry +$(MAKE_FLAGS) $(MAKE) $(PKG_JOBS) \ Jul 19 09:18:42 especially since make allows variable names which would not be valid in a shell Jul 19 09:18:56 * ldir has to leave = picking car up from service - back later/soon Jul 19 09:20:03 https://pastebin.com/SEw228C4 Jul 19 09:20:34 thats why the KEY=VAL argument form is supported by make Jul 19 09:20:52 in order to be able to pass valid make variables to submakes Jul 19 09:52:00 * ldir is back Jul 19 09:56:46 not that I have tried this but looking at our package makefile does that mean $(MAKE_FLAGS) $(MAKE) $(PKG_JOBS) $(MAKE) $(MAKEFLAGS) $(PKG_JOBS) are/should be functionally equivalent ? Jul 19 10:10:30 it appears yes. Jul 19 10:12:28 yes Jul 19 10:12:52 but the former form might fail if MAKEFLAGS contains things not being valid shell variable assignment expressions Jul 19 10:16:19 also the former is a right pain in the backside to find the actual command after the env vars! Jul 19 10:17:35 it looks like our master make for perf gets invoked with a whole load of env vars - usr/bin/make --no-print-directory -C /Users/kevin/wrt/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.57/tools/perf Jul 19 10:18:37 this calls a submake that doesn't appear to have them make -C /Users/kevin/wrt/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.57/tools/build CFLAGS= LDFLAGS= /Users/kevin/wrt/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.57/tools/perf-target-x86_64_musl/fixdep Jul 19 10:22:41 the -no-print-directory flag makes the log hard to understand Jul 19 10:23:01 impossible to follow the process flow without reading the corresponding makefiles at the same time Jul 19 10:23:26 maybe its just another case of missing header include paths? Jul 19 10:23:51 paths are defined, just not set on otherOS Jul 19 10:24:06 then they should be set on otheros too Jul 19 10:26:24 well this is going to be a learning experience :-) Jul 19 10:29:28 boggles - uname -s - otherOS - ;-) Jul 19 10:51:08 talk about wall of text https://pastebin.com/1xhMxTiL Jul 19 11:04:17 it same as before, isn't it ? Jul 19 11:04:55 yes, or very similar - the error is the same :-) Jul 19 11:05:36 you're simply missing -I$(srctree)/tools/include which has linux/kernel.h Jul 19 11:06:12 this include is defined via https://elixir.bootlin.com/linux/latest/source/tools/perf/pmu-events/Build#L4 Jul 19 11:07:14 oh wait Jul 19 11:07:45 HOSTCFLAGS_json.o = -I$(srctree)/tools/include Jul 19 11:07:55 try to add this Jul 19 11:08:14 in that tools/perf/pmu-events/Build file Jul 19 11:08:21 ok Jul 19 11:14:10 https://pastebin.com/rjEBUbRm - falling at another fence. Jul 19 11:14:53 and asm/types.h doesn't exist under tools/include at all Jul 19 11:16:21 /usr/include/x86_64-linux-gnu/sys/types.h Jul 19 11:16:55 err /usr/include/x86_64-linux-gnu/asm/types.h Jul 19 11:18:44 libc6-dev:amd64: /usr/include/x86_64-linux-gnu/sys/types.h Jul 19 11:19:01 isn't that going to be more $STAGING_DIR/ usr/include/x86_64-linux-gnu/asm/types.h ? Jul 19 11:19:34 this is host Jul 19 11:20:39 have you tried to build 4.19 out of the openwrt tree? Jul 19 11:21:04 just download the tarball and run that `make -C tools/perf` manually? Jul 19 11:21:28 no, not yet Jul 19 11:21:55 I've tried that in the evening yesterday, it complains about missing glibc-dev package Jul 19 11:22:14 on otherOS I mean Jul 19 11:22:36 just couldn't find that package in brew, so I gave up Jul 19 11:53:37 jow: where could one download mirror-01.infra.openwrt.org::release-uploads/19.07-SNAPSHOT/targets/ar71xx/generic/ ? Jul 19 12:13:50 ynezz: -EPARSE Jul 19 12:14:35 ynezz: ah you mean via http, anonymously? Jul 19 12:14:36 https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ar71xx/generic/ Jul 19 12:14:41 its hidden by default Jul 19 12:18:02 jow: ramips/mt7620 is still being compiled I assume...? Jul 19 12:28:01 dangole: no its broken and fails to build Jul 19 12:28:36 dangole: http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7620/builds/2/steps/images/logs/stdio Jul 19 12:28:44 dangole: while you Jul 19 12:28:59 're here... you did the libudev-bsd change in the past? Jul 19 12:32:17 yes, because udev was unmaintained and mostly unusable, I found libudev-fbsd and added some stuff to it so it would work for libinput and to probe V4L devices Jul 19 12:32:53 dangole: it seems to have broken usbnet completely Jul 19 12:34:28 dangole: https://bugs.openwrt.org/index.php?do=details&task_id=2130 Jul 19 12:34:44 sorry, usbip - not usbnet Jul 19 12:35:15 https://forum.openwrt.org/t/usb-over-ip-problems/7589 Jul 19 12:36:22 ok, if it's somehow still manageable to run up-to-date libudev (without pulling-in half of systemd) and that would make it work, maybe that's the better solution then Jul 19 12:36:46 or just unstub the missing functions; not sure how much effort this is Jul 19 12:37:30 i've already added some USB functionality a while ago, generally it's not that much effort Jul 19 12:40:38 however, the whole reason to use libudev-fbsd in first place was because udevd itself didn't work with procd back then Jul 19 12:42:06 maybe I am very naive here but is it possible to simply copy-paste e.g. udev_device_get_sysattr_value() to *-fbsd ? Jul 19 12:44:23 and waht eudev ? Jul 19 12:44:30 *and what about eudev? Jul 19 12:46:35 Hi. Are there negative dependencies for DEPENDS? I want my package to automatically deselect/inhibit another package. Jul 19 12:46:45 no, this is not possible Jul 19 12:46:52 Thanks. Jul 19 12:48:45 udev_device_get_sysattr_value() seems to redirect to https://github.com/systemd/systemd/blob/76c887fdaaeaf2e4d94f61dba6a7094542ecdef3/src/libsystemd/sd-device/sd-device.c#L1732 in libudev Jul 19 12:49:01 which looks fairly manageable, complexity wise if leaving out all the systemd magic Jul 19 12:49:14 e.g. no caching etc. Jul 19 12:56:43 * dangole looking at sd-device.c Jul 19 12:59:28 jow: true, it's mostly just taking some things out of sysfs... Jul 19 13:00:32 Is there a preferred method for doing configuration management / vendor-specific stuff in OpenWRT? Using plain packages maybe? Jul 19 13:00:49 jow: yep, you parsed it correctly, thanks Jul 19 13:02:02 Eduard_Munteanu: for config management I had good success with ansible raw mode Jul 19 13:02:27 which then manipulated /etc/config/ via the uci cli Jul 19 13:02:55 uci commands + /sbin/reload_config get your halfway there Jul 19 13:02:56 jow, hm, not sure we're talking about the same thing. I just want to build pre-configured images, not reconfigure live systems. Jul 19 13:03:01 ah Jul 19 13:03:11 imagebuilder + files/ overlay I'd say Jul 19 13:03:17 or uci-defaults Jul 19 13:03:32 I see. Jul 19 13:03:33 right, or uci-defaults if you need incremental changes on top of the defaults Jul 19 13:03:55 e.g. make image PROFILE=whatever FILES=files/ Jul 19 13:04:09 with files/etc/uci-defaults/90-my-firstboot-provision-script.sh Jul 19 13:04:40 I guess I can also split part of my configuration into packages? I heard it's relatively common in other distros. Jul 19 13:04:49 or files/etc/config/network, files/etc/passwd, files/etc/shadow etc. to bake in hardcoded defaults Jul 19 13:05:01 I guess so, yes Jul 19 13:05:07 I see, thanks. Jul 19 13:10:53 what about urngd backport to 19.07, it could be considered a fix :) Jul 19 13:11:19 just testing the ar71xx 19.07 image and got welcomed with '[123.407894] random: crng init done' Jul 19 13:13:48 8dev-carambola2_ath79-generic_OpenWrt-SNAPSHOT-r10535+6-16ac5c4fbd18_info.txt:[ 15.744230] random: crng init done Jul 19 13:14:07 carambola2_ar71xx-generic_OpenWrt-18.06.4-r7808-ef686b7292_info.txt:[ 127.734042] random: crng init done Jul 19 13:14:30 carambola2_ar71xx-generic_OpenWrt-SNAPSHOT-r10250-016d1eb_info.txt:[ 37.623333] random: crng init done Jul 19 13:17:57 for 19.07 I agree Jul 19 13:18:05 for 18.06 not Jul 19 13:18:13 wrt. backporting Jul 19 13:19:30 so I can add your Acked-by: ? :) Jul 19 13:20:18 there is going to be 19.07-rc1 anyway, right? Jul 19 13:21:18 I mean 19.07.0-rc1 Jul 19 13:28:38 just emailed NXP about that layerscape related build breakage Jul 19 13:29:03 going to take a look at that ath25 problem Jul 19 14:23:54 fuck, I've commited my complete staging tree :( Jul 19 14:25:06 I intended to commit just the mkfwimage improvements, but somehow fucked it up Jul 19 14:26:43 well, it's not a big deal as I was testing Hauke's mac80211 bumps to 5.2-rc7 which he wanted to bump anyway, but still it wasn't intended Jul 19 14:27:29 well there is allways revert in git :) Jul 19 14:27:39 Quick, everybody pull Jul 19 14:27:59 yeah, just push a revert commit Jul 19 14:28:25 it's 5 commits actually Jul 19 14:29:52 I would say it's an accidental move forward Jul 19 14:30:25 Hauke: ping Jul 19 14:30:31 well then multiple reverts Jul 19 14:32:45 I guess the finaly commit for mac80211 was supposed to be based on Linux 5.2 rather than 5.2-rc7... however, there aren't any relevant commits v5.2-rc7..v5.2, so it in the end it doesn't matter Jul 19 14:33:28 that ath10k version bumping and reverting hick-up could have been avoided though... Jul 19 14:34:01 and more reverts are not going to make that look any better imho Jul 19 14:34:49 For what it is worth, I have been testing that mac80211 bump for a couple of weeks and have encountered no problems. Jul 19 14:35:44 mamarley: same here Jul 19 14:36:04 I was advised by mkresin to have 2 copies of the repo to help avoid such fun - one copy knows how to push to upstream, the other doesn't. My staging tree lives in the 'no upstream push' copy. Jul 19 14:40:01 I've something similar for stable, so going to do the same for master as well Jul 19 14:43:17 I could of course just have 2 remotes 'upstream' and 'upstreampush' - concentrate the mind that I have to use upstreampush to actually do it :-) Jul 19 14:43:44 I've openwrt-upstream remote for that, but still screwed it Jul 19 14:44:59 going to make an alias probably which is going to show me the commits and pause Jul 19 14:45:33 ha - make something idiot proof and they'll only build a better idiot :-) Jul 19 14:57:33 ldir: very true :) Jul 19 14:58:05 if you're very fast, there's always the possibility to silently reset HEAD :P Jul 19 14:59:27 I've found out about the fuckup from the commit emails, so it was late already Jul 19 15:01:50 jow: does image build with your "e.g. make image PROFILE=whatever FILES=files/" allow you to override anything from packages then? unlike having your private stuff in a package? Jul 19 15:02:01 yes Jul 19 15:02:41 hrm, it's been much easier to have things in packages as far as version control, and not having to copy a files folder around. Jul 19 15:02:57 will have to experiment a bit with that, Jul 19 15:03:19 I've still got these weird makefile overrides to allow replacing files from a package, it always feels gross Jul 19 15:09:18 hm, theoretically you could put files/ in version control too Jul 19 15:09:31 then refer to a subdir to avoid having a .git in your target rootfs Jul 19 15:10:01 e.g. make image PROFILE=whatever FILES=files.git/rootfs-overrides/ where files.git is a Git clone Jul 19 15:10:28 :+1: on symlink of .config to env/.config and files to env/files with env under its own git control (or wherever you want that repo) Jul 19 15:10:53 (Actually, I symlink to env/dot.config so I can "see" the file) Jul 19 15:19:03 will 19.07 support running nginx with luci? nginx+luci was broken on 18.06 Jul 19 15:19:28 Guest43: Yes, it should. Has been present on `master` for quite some time now Jul 19 15:20:01 cool, waiting for 19.07 test build to play with then Jul 19 15:22:58 Grab a snapshot -- you're going to need to install LuCI anyways to get nginx support Jul 19 15:24:21 you mean master snapshot or 19.07 snapshot, is there a 19.07 snapshot now Jul 19 15:24:48 will try this weekend Jul 19 15:26:11 https://downloads.openwrt.org/releases/ looks like either no 19.07 snapshot, or the new branch is not created yet Jul 19 15:30:32 I was wrong, openwrt does have 19.07 branch now: https://github.com/openwrt/openwrt/tree/openwrt-19.07 Jul 19 15:30:44 time to try! Jul 19 15:31:13 why do you need luci under nginx? Jul 19 15:31:18 lighttpd is 4MB, nginx the smallest memory footprint is 4.6MB, if nginx can do luci as lighttpd does, that will be nice Jul 19 15:31:39 pfft, 4MB, thats larger than my rootfs ;) Jul 19 15:31:59 memory, come on, not your flash-made roottop :) Jul 19 15:32:08 rooftop Jul 19 15:32:34 but still, why luci under nginx? Jul 19 15:32:40 what does it gain you? Jul 19 15:32:43 anyway i want to run something in parallel with luci under one http server, some fastcgi/restful experiments Jul 19 15:32:58 reverse proxy luci then Jul 19 15:33:20 I think in master you need to do this anyway eventually as nginx lacks uhttpd-mod-ubus Jul 19 15:33:31 or rather lacks an ubus module Jul 19 15:34:52 no need uhttpd-mod-ubus, just plain cgi/fastcgi do to rpc-calls(or restful, but unlikely) Jul 19 15:35:05 I mean luci master needs it Jul 19 15:35:36 currently lighttpd hosts both luci and that, want to see if can switch to nginx, because, "nginx" is more "popular" with similar memory footprint Jul 19 15:36:12 interesting, don't think uhttpd-mod-ubus is mandatory to luci-admin-full Jul 19 15:36:25 not yet Jul 19 15:36:28 something changed or I missed something basic Jul 19 15:36:49 right now luci master attempts to use /ubus/ and will fall back to some Lua CGI emulation if its not present Jul 19 15:36:55 but that emulation will go away eventually Jul 19 15:37:28 anyhow; tldr - luci-nginx should "work" Jul 19 15:37:35 seems like this could work: alias.owrt-push-master=!sh -c 'git fetch openwrt-upstream && git branch staging-next && git rebase -i openwrt-upstream/master && git log --stat openwrt-upstream/master..HEAD && echo "hit ctrl+c to abort" && sleep 10 && echo "git push openwrt-upstream staging:master" && git checkout staging-next && git branch -M staging && git rebase openwrt-upstream/master' Jul 19 15:37:56 ok, that's good enough. I noticed spi-dev is broken in 19.07, will see if i can help a bit this weekend if it persists Jul 19 16:01:43 * ldir has managed to fix at least one thing today Jul 19 17:11:27 ldir: thanks! Jul 19 17:13:06 this gcc will never stop amusing me, I've compiled checked it with version 7.4.0, buildbots use 6.y so I've thought, that -Wextra on the lower gcc version wont find more issues then the higher version Jul 19 17:14:55 and now it fails to compile on 7.4.0 :) Jul 19 17:15:37 oh crap - really? Jul 19 17:16:24 I'll fix it later (or disable either -Werror or -Wextra), don't worry Jul 19 17:16:38 What doesn't it like now? Jul 19 17:16:51 http://paste.ubuntu.com/p/d2nwCsvrG3/ Jul 19 17:17:38 with that reverted commit of yours it works here (tm) Jul 19 17:18:55 apt-cache search gcc-6 Jul 19 17:18:59 oops Jul 19 17:19:18 that is erm, madness. Jul 19 17:19:24 indeed Jul 19 17:20:19 that sort of suggests that the type is changing doesn't it? Jul 19 17:21:52 what was the error you got on 9.1? Jul 19 17:22:30 I'll be back in an hour or so Jul 19 17:28:25 https://paste.ubuntu.com/p/3ds2T5cYJd/ Jul 19 18:43:46 are you testing gcc 9 ? Jul 19 18:44:14 I got bug reports in luci from a user that looked like lua is crashing on mips when built with gcc 9 Jul 19 18:44:28 gcc 9 is probably default in brew/ports on otherOS Jul 19 18:44:57 but the error is also visible with gcc 6, but not with 7.4.0 Jul 19 18:45:03 going to take a look at it now Jul 19 18:46:55 ynezz: I suspect this is a difference between definition of stat in stats.h Jul 19 18:47:57 and gcc 9 is in the toolchain options Jul 19 18:48:44 but this is for target, not the host Jul 19 18:48:59 mkfwimage is run on the host system Jul 19 18:49:37 yes, so my host system is macos Jul 19 18:49:52 but buildbot is Linux Jul 19 18:51:03 Yes, what I'm saying is that the stat structure under macos is different from linux, so my fixes won't apply. Jul 19 18:52:12 just installing gcc-9 Jul 19 18:55:13 we could just cast the offending lines ! Jul 19 18:58:03 jow: any particular page? I have 2 archers on master built with gcc 9 Jul 19 18:59:40 ldir: randomly, let me dig out the report Jul 19 19:00:06 as they're APs I tend not to hit the web interface too hard Jul 19 19:00:32 https://github.com/openwrt/luci/issues/2833 Jul 19 19:00:40 reads like "any page" Jul 19 19:01:43 I'm still trying to get linux running on my GS108Tv2. It has the BCM53312 SoC which runs in big endian (!) mode. For some reason the ssb bus isn't working. I've played with the "drivers/ssb/scan.c" file to include some additional output and limited the scan to the cores 0-4 (https://gist.github.com/fvollmer/0291f2c01bf6768dc10ec1e6bc452983). This i Jul 19 19:01:44 s the output: https://gist.github.com/fvollmer/897654cd6e3eb0c94c5d3cb62519f570 Jul 19 19:03:07 It appears like there is some problem with the ssb bus, since no devices are found Jul 19 19:03:35 I'm happy to hear about any ideas :) Jul 19 19:04:17 hmm, archer c7 is mips big endian, whereas the 7620 is little endian - so my test on 'mips' isn't indicative Jul 19 19:14:47 jow: is there a way to tell opkg to use IPv4? Jul 19 19:15:55 i have IPv6 from my DHCP but it's a double NAT situation on IPv4, and delegated IPv6 (I believe). Opkg is telling wget/uclient-fetch to use IPv6. Jul 19 19:18:27 s/DCHP/ISP/ Jul 19 19:23:26 ynezz: pong Jul 19 19:24:00 ynezz: I anyway planned to do some more testing this weekend and then commit this Jul 19 19:24:11 now I will just fix bugs if I find some Jul 19 19:24:27 so I hope, that I didn't ruined your weekend :) Jul 19 19:25:31 no Jul 19 19:36:24 ldir: can you pls try this https://git.openwrt.org/eb6baad39f43aaac7cd23638add89cae6edc43aa ? Jul 19 19:36:36 it compiles here with gcc-6/7/9 Jul 19 19:39:55 trying now Jul 19 19:42:21 I'm also going to run test it as well Jul 19 19:44:52 BTW is there any reason why there's forced host gcc to `HOSTCC:=gcc` in rules.mk ? Jul 19 19:45:46 I've just trashed my toolchain to ensure I start from a clean slate. it may take a little while, but then I only need to get as far as firmware_tools. Jul 19 19:46:18 it's using your gcc from host, isn't it? Jul 19 19:46:34 you can just compile it, event with trashed toolchain Jul 19 19:46:45 ynezz: as a wild stab in the dark guess... I wonder if that is a nbd / macOS'ism to ensure it doesn't use clang. Jul 19 19:47:30 so you've HOSTCC=cc env variable on macOS ? Jul 19 19:47:30 there's a wrapper script somewhere that disguises clang as gcc. Jul 19 19:51:02 ynezz: no, there's no CC or HOSTCC env var set Jul 19 20:13:39 ynezz: computer says "no" https://paste.ubuntu.com/p/9tSM6pzWBR/ Jul 19 20:17:41 can you pastebin somewhere your stat.h ? Jul 19 20:19:14 if I can find where apple hide it - it's not /usr/include Jul 19 20:20:40 gcc -xc -E -v Jul 19 20:21:15 gcc -xc -E -v - Jul 19 20:26:57 ynezz: you won't like it - https://paste.ubuntu.com/p/xFMfsSDC5X/ Jul 19 20:27:56 anyone have issues compiling dnscrypt or .ssl extensions of packages recently? Jul 19 20:29:19 ldir: and types.h ? Jul 19 20:29:27 off_t Jul 19 20:30:38 https://paste.ubuntu.com/p/BDN3WHNSyt/ Jul 19 20:31:05 sys/_types/_off_t.h :) Jul 19 20:31:25 I should probably go for my otherOS laptop Jul 19 20:31:25 yeah I just saw that - f'in insanity! Jul 19 20:31:41 I mean, it's defined in that file, I would like to see it also Jul 19 20:32:35 aaarrrghhh! #include /* __darwin_off_t */ Jul 19 20:32:35 typedef __darwin_off_t off_t; Jul 19 20:33:12 neonknight77: explicts are much mor euseful than vague handwaving Jul 19 20:33:34 at last!!!!! typedef __int64_t __darwin_off_t; /* [???] Used for file sizes */ Jul 19 20:34:29 but it doesn't correspond with the output of gcc Jul 19 20:35:08 ahh, it's format specifier problem Jul 19 20:35:12 not the off_t Jul 19 20:35:37 karlp, sure give me a few min until I get my 5th error in a row so I can copy and paste :-) Jul 19 20:38:14 yes, the printf format says 32bit int, the variable in the structure is 64 bit. Jul 19 20:39:17 hm, switching libc's within the same checkout still breaks the build: Collected errors: Jul 19 20:39:20 * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files: Jul 19 20:39:23 * libssp Jul 19 20:39:25 * opkg_install_cmd: Cannot install package base-files. Jul 19 20:39:28 and so on Jul 19 20:39:39 musl -> glibc -> musl -> wrumms Jul 19 20:39:58 Since type promotion from 32bit to 64bit or 64bit to 64bit should work without loss of precision I'd be tempted to cast the calc to 64bit no matter what, and use the 64bit printf format. Jul 19 20:40:04 although they have individual dirs in build_dir/ and staging_dir/ something gets messed up Jul 19 20:40:57 karlp https://pastebin.com/raw/UTVtw0Nw Jul 19 20:41:17 ynezz: but you probably have a much more elegant solution than my hammer Jul 19 20:54:01 probably inttypes.h and PRId64 Jul 19 21:07:45 ldir: https://git.openwrt.org/ff7909f69ef8f178501797ea9599a0add3f2cbd5 Jul 19 22:11:49 I took a closer look at the boot process of the stock firmware (ecos): https://github.com/fvollmer/GS108Tv2-reverse-engineering/blob/master/README.md#boot-initialization-of-the-stock-firmware . The most interesting bit might be https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbsdram.S#L156 Jul 19 22:13:52 What do you think? Jul 19 22:48:15 someoner: interesting. btw, the chipid register contents seem to be correct, here the code checks for what we saw: https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbutils.c#L617 Jul 19 22:49:52 yes, but this seems to be the only thing Jul 19 22:51:38 "uint32 chipid; /* FIXME (not sure if its there*/" <- how reassuring ;) Jul 19 22:54:13 there is some more interesting stuff: https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/master/packages/hal/mips/bcm953710/v2_0/src/sbutils.c#L208 Jul 19 22:54:36 it says it will scan, but actually it just fails :D Jul 19 23:01:34 I started compiling the ecos stuff... Jul 19 23:03:39 great the link to the mipsisa32-elf toolchain is outdated Jul 19 23:10:48 even the link from mips.com is broken?! https://www.mips.com/files/mips-linux-toolchain-bin-1-1-tar-bz2/ (from https://www.mips.com/develop/tools/compilers/linux-toolchain/ ) Jul 19 23:56:44 ok i've found toolkits here: http://mirrors.kernel.org/sources.redhat.com/ecos/gnutools/i386linux/ **** ENDING LOGGING AT Sat Jul 20 02:59:56 2019