**** BEGIN LOGGING AT Sat Jul 20 02:59:57 2019 Jul 20 03:06:53 * mangix just pushed a bunch of build fixes for openwrt 19.07. let's see if anyone complains Jul 20 03:11:39 did you fix dnscrypt compiling error Jul 20 03:11:59 as well as openssl Jul 20 09:03:17 ynezz: your build fix works - ack Jul 20 09:05:16 anyone use ar7? Compiler spotted something 'interesting' in the srec2bin utility Jul 20 10:23:58 ldir: we should probably enable -Wall -Wextra -Werror as default compiler flag for the firmware-utils package :p Jul 20 10:24:19 I've seen that pile of warnings in other utils as well Jul 20 10:26:02 yes, it's quite frightening really. I'm slowly working my way through some of them. If you look in my staging tree you'll see I've started. Jul 20 10:29:47 great! Jul 20 10:32:38 there's a whole family of 'mkfoo.c' that have the same issues, so it's more tedious than difficult :-) Jul 20 10:33:30 don't know how to solve this src/mkzynfw.c:836:20: warning: taking address of packed member 'ocsum' of class or structure 'zyn_rombin_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member] Jul 20 10:33:30 res = read_magic(&hdr.ocsum); Jul 20 10:39:28 read_magic expects a ptr to a 16bit int... which could live in memory at an unaligned location. Jul 20 10:39:48 So I get the warning. Jul 20 10:43:54 so probably it should be enough to store it in tmp variable and then assign it to that struct? Jul 20 10:45:49 https://git.openwrt.org/63f9e983588aef6e15ffdd71cc80620d7e0c0a85 :) Jul 20 10:46:46 kaboooooom! Jul 20 10:47:29 I'll try your suggestion. Jul 20 10:49:35 ynezz: I think --std=gnu99 should stay in the invidiual flags Jul 20 10:50:13 ok, and the reason for this? Jul 20 10:51:19 I'm just wondering, it's fine for me to keep it, I just find it more relaxing Jul 20 10:54:05 ynezz: because it changes the code standard base, and doesn't directly have anything to do with enabling warnings/errors Jul 20 10:54:57 there's also one instance where you switch from --std=c99 to --std=gnu99 Jul 20 10:55:54 ah, dman, I wanted c99 Jul 20 10:56:00 s/dman/damn/ Jul 20 10:56:15 as in other owrt utils/libs/services Jul 20 10:56:28 but ok, I'll keep it as it is Jul 20 10:57:56 ah, "dialect" was the word I failed to remember Jul 20 11:01:38 believe it or not, the warnings are decreasing in number :-) https://paste.ubuntu.com/p/XX7jcfPGQm/ Jul 20 11:03:27 KanjiMonster: https://git.openwrt.org/d5b1e0c7a585bc6a00cd48ff05f04675a99e6f71 Jul 20 11:03:38 ldir: yes, it's a long way Jul 20 11:04:20 "An error occurred while reading CGI reply (no response received)" *f5* "No such Git commit." Jul 20 11:05:23 sorry, https://git.openwrt.org/99f07064b404d88a651ade0b1d6d6ffab1a95562 Jul 20 11:07:02 ynezz: you dropped nec-enc's --std=gnu99 Jul 20 11:07:49 d'oh! Jul 20 11:07:53 thanks! Jul 20 11:11:10 KanjiMonster: hopefully final https://git.openwrt.org/6b74aa4f6fee8af1aa7f723774c267f6da528c1e Jul 20 11:21:31 ldir: I'll reverse the build process here and will start fixing the utils from the bottom Jul 20 11:21:48 btw you're pushing those changes in the ctinfo branch, right? Jul 20 11:29:33 I'm trying to build the ecos sources. There is a a very short README: https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/master/README.raptor_netgear.txt . After some trying "make L7_CPU=raptor_netgear" run successfully. What do I have to do to run this build on my device? Jul 20 11:30:11 ldir: a-z sorted https://git.openwrt.org/f47f0a4e44f6 Jul 20 12:15:51 ynezz: yes, ctinfo is my default building branch where I have my own tweaks and fixes before I push them. Jul 20 12:16:02 it's basically the branch that I'm running. Jul 20 12:20:32 and very nice re-order! Jul 20 12:25:13 BTW looking at your srec2bin fix, there is few more visible with -Wextra Jul 20 12:35:14 I'm just using the defaults of whatever the build system reports on macOS at the moment Jul 20 12:35:25 this is before your re-order Jul 20 12:36:03 and your enabling of all the extras! Jul 20 12:43:43 well, it makes no sense for me to touch this unless attempting to fix all of the potential issues Jul 20 13:01:24 BTW I might be bikeshedding again :) but following `strncpy((char *)header.model, argv[1], sizeof(header.model));` is simply just making compiler happy, not fix Jul 20 13:03:17 and you're probably not going in the alphabetical order as we've both fixed tplink-safeloader :) Jul 20 13:04:36 tplink-safeloader https://git.openwrt.org/b64134cb1d7f5aed8e72fab510b81aa3e9b9eb70 Jul 20 13:04:59 anyway, I'm afk now Jul 20 13:14:26 After compiling ecos I got the files:libextras.alibtarget.a (ecos kernel and packages?)target.ld (linker script)vectors.oThen I compiled the example applications at https://github.com/fvollmer/GS108Tv2-ecos-2.0/tree/master/examplesThe Makefile ( https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/master/examples/Makefile ) appears to me to use the Jul 20 13:14:26 linker script (target.ld). Now I have e.g. hello.o files. What do I have to do to get a bootable elf? Jul 20 13:15:13 oh it looks like irc can't handle new lines Jul 20 13:18:39 This is the linker script: https://gist.github.com/fvollmer/831a793ff5516c9f8f1b43fccab6099d Jul 20 13:19:45 ynezz: Sorry, no I was just crashing through the errors as they appeared in the build log. Jul 20 13:27:27 ynezz: re the bikeshedding - am no expert as you know. My view is that there's more validity to viewing the firmware image as a byte stream, which to me fits more with 'unsigned char' than 'signed char'. I can sort of see why strncpy expects (signed) char but ultimately the size of the pointed to object is the same 8 bits. So it is shutting the compiler up. Jul 20 13:28:43 but in some areas it wants unsigned and in others it wants signed - it can have have both with the aid of a cast Jul 20 13:29:38 anyway have pushed a branch toolsfix with my work so far, put on top of yours hopefully for easy merging. Jul 20 13:29:59 that's as far as I've got. Jul 20 13:48:03 I think the following command should create an executable: "mipsisa32-elf-gcc -nostartfiles -L/home/fvollmer/openwrt/GS108Tv2-ecos-2.0/output/ecos-2.0--raptor_netgear/install/lib -Ttarget.ld -mips32 -EB -nostdlib -Wl,--gc-sections -Wl,-static -o hello hello.o", but for some reason there is no output and no error Jul 20 13:48:17 any guesses? Jul 20 14:28:55 [Sat 2019-07-20 02:05:14 AM PDT] anyone use ar7? Compiler spotted something 'interesting' in the srec2bin utility <------ very few ar7 devices had more than 16M ram Jul 20 14:29:48 and the ethernet switch code for it never fully worked Jul 20 14:30:25 the later ar7 devices all had wifi for which we never got a working driver Jul 20 15:52:41 Hi everyone Jul 20 15:53:18 I managed to ssh in a sagemcom 5655 and saw its running openwrt Jul 20 15:59:53 DonkeyHotei: so basically if I break it (or indeed unbreak it) no one is going to notice anyway Jul 20 16:11:11 Hi. I am curently trying to port OpenWRT to a a Mikrotik mt7621-based device (LtAP). I have mostly got the device workig, but I am having some trouble getting the internal wifi up and running Jul 20 16:11:29 no ar7 device is goign to have enough ram7flash to run current gen openwrt anyway is it? Jul 20 16:11:44 they're of an age taht makes ath25 look futuristic Jul 20 16:11:57 The card is identified as "Qualcomm Atheros AR93xx Wireless Network Adapter (rev ff)" and during boot I get the following error: ath: phy0: Unable to initialize hardware; initialization status: -5 Jul 20 16:12:24 When searching for this error, the only references I found are to cards not working properly, but that seems a bit odd Jul 20 16:12:43 Most likely there is something wrong in my DTS, so I am wondering if anyone else has seen the same error and how did you solve it? Jul 20 16:17:23 yeah, some progress: I sucessfully build a hello world example with ecos for the BCM53312 Jul 20 16:17:44 I'm very curious if I can access the ssb bus now Jul 20 16:18:22 But I guess I should first cleanup the build process. This is currently very messy... Jul 20 16:19:13 karlp: https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=ea8a9843887653a64abf155551688b2ade33db77 Jul 20 16:19:57 arae you sure it's meant to be a !=? Jul 20 16:20:03 that's not a comon typo like that Jul 20 16:22:08 the second wifi card, which is connected via an external mini-pcie slot, works fine Jul 20 16:22:46 (I've not looked at the surrunding code, I trust you and ynezz) Jul 20 16:25:17 karlp: it would be a very unusual typo - the context is odd it has to be said Jul 20 16:34:30 karlp: https://en.wikipedia.org/wiki/SREC_(file_format) suggests an S5 record (which this is) is a count of other records, so I'd expect our internal count to match the count in the source file, thus != seems more likely intended than |= which is basically 'error if non zero' Jul 20 16:36:32 hmmm, a not uncommon OCR cockup though. Jul 20 16:38:07 yeah, that's what I was thinking. weird though Jul 20 16:48:07 OK, this is interesting! I used the official ecos sources for my device (BCM53312) and used a small program to query the IDs of the SSB cores (https://gist.github.com/fvollmer/6c4c028e72edad6020b7c4ac72253293 ). Interestingly all IDs are 0! So it seems like the problem isn't that the ssb bus isn't initialized. Jul 20 16:48:13 full output: https://gist.github.com/fvollmer/3e157374b915c6ed5072ce86fed4e179 Jul 20 16:51:11 kristrev: Have you fed the driver with corresponding calibration data? You need to set qca,no-eeprom in dts and provide calibration data using a firmware hotplug script. Jul 20 16:52:45 gch981213: Thanks. No, I haven't tried. When searching for fixes to similar problems, it seems that problem caused by missing calibration data triggers a different return value. -22 if I remember correctly Jul 20 16:54:31 But I will try that now. Do you know if there are some patterns to look for, etc. when searching for the calibration data? Jul 20 16:59:53 kristrev: ar9300 eeprom starts with 0x0202 and the following 6 bytes are mac address (some manufacturers don't set correct one here and use 00:02:03:04:05:06 as a placeholder). It's 1088 bytes long. Jul 20 17:02:01 gch981213: Thanks a lot. Time to go digging :) Will send you a virtual cold beverege of choice ;) Jul 20 17:03:40 are the vaues for the different chipsets documented anywhere? So I dont need to ask next time :) Jul 20 18:15:00 are there any packages or similar required to get firmware hotplug events? Jul 20 18:15:41 I am trying to add 11-ath9k-eeprom to ramips (11 since there already is a 10), but I get no firmware events Jul 20 18:16:19 Even running FIRMWARE="ath9k-eeprom-pci-0000:01:00.0.bin" /sbin/hotplug-call manually doesn't trigger my debug output (placed at the top of the script) Jul 20 18:32:56 just me being slow, I had messed up the pcie node in my dts so card was neve recognized Jul 20 18:35:30 now error messaged changed to "[ 16.173130] ath: phy0: both bands are disabled", but at least something is happening Jul 20 19:07:41 jow: ping. The aarch64 build bots seem to be configured incorectly. See: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53_neon-vfpv4/packages/libwebsockets/cyassl/compile.txt Jul 20 19:08:36 that's version 2.2.1, which is not in any of the branches currently. current master is 3.1.0 Jul 20 19:10:32 there are also other long range build failures. Jul 20 19:29:06 does anyone have any suggestion as to what could trigger the error I am seeing ("both bands are disabled")? From what I can tell, the content of my eeprom file is correct (first value is 0202 and then the default MAC addr) Jul 20 20:19:17 It seems the issue is that values the driver expects to be non-zero/not 0xffffffff is zero. I have put a dump of my firmware here if anyone is interested: https://pastebin.com/zF6cRetV Jul 20 21:09:48 at least wifi is working fine on the device. I recycled an eeprom I found from a wdr4300 (quick Saturday-evening "solution") Jul 20 22:12:24 mangix: cyassl for libwebsockets is ~"contributor supported only" I've been extremeely tempted to just drop it. Jul 20 22:12:55 (doesn't fix any underlying problems with aarhc64 buildbots, don't get me wrong, but libwebsockets for non-openssl is not exactly a solid target in the first place :) **** ENDING LOGGING AT Sun Jul 21 02:59:57 2019