**** BEGIN LOGGING AT Sat Jul 14 03:00:00 2018 Jul 14 03:19:49 neoraider: linux kernel commit 8c2dd3e4a4bae78093c4a5cee6494877651be3c9 from circa January 2017 did some function renaming Jul 14 06:41:34 morning Jul 14 07:33:47 neoraider: thx. i fix this later Jul 14 08:56:37 ldir: go ahead Jul 14 09:12:07 greearb_: pong Jul 14 09:36:17 TobleMiner: could you test 'rbcfg show' on your routerboard devices please (after installing the rbcfg package)? I suspect it's not going to work. Jul 14 09:39:02 DTS newbie question: is it possible to set the model string from a flash address read? Jul 14 09:48:44 f00b4r0: that would be the responsibility of the (second stage) bootloader Jul 14 09:49:41 KanjiMonster: I don't understand. I have a very, very limited understanding of how DTS works tbh Jul 14 09:50:18 basically I want to do with the model variable what's done with e.g. MAC address (typically read from an offset in an mtd partition) Jul 14 09:50:29 reason being, routerboard devices store their model name in flash Jul 14 09:50:33 f00b4r0: in an ideal world, a fully populated and finished dts (or rtather dtb) is passed to the kernel from the bootloader Jul 14 09:52:15 and the preferred way for bootloaders that don't support passing a dtb to the kernel, especially if it requires modifications, is to put a second stage bootloader before the kernel that does the required updating of the dtb to pass to the kernel Jul 14 09:52:49 ok Jul 14 09:55:08 in practice, having the boot loader pass the dtb messes things up or makes the upgrade path really convoluted and nasty Jul 14 09:56:35 right now i'm looknig at ipq40xx but considering how we already have two RB devices in ramips (and a lot more waiting to be converted in ar71xx) I suspect this feature will be desirable for more than one arch Jul 14 09:56:53 generally speaking, either you have a dts that works with all models so you don't need to use unique model names, or you need dts files per board anyway Jul 14 09:57:42 and I suspect it will be the latter eventually when switch configuration is properly described in the dts files Jul 14 09:57:43 the (or a subset of it) can be made to work for several devices indeed. There are however minor differences that require parsing the correct model name, especially for the setup scripts Jul 14 09:58:03 the DTS* Jul 14 09:58:20 the minor differences should probably described in the dts files, and not rely on scripts knowing the differences Jul 14 09:58:38 that's going to duplicate a _lot_ of data Jul 14 09:59:11 not really, since you can create .dtsi files that contain everything that's the same across different devices Jul 14 09:59:12 that's what .dtsi files are for Jul 14 09:59:30 ok Jul 14 09:59:57 final cosmetic argument: some machines are virtually the same hardware in a different casing, where the only difference (besides the form factor) is the model name Jul 14 10:00:12 do we want to present a generic model name to the user or the actual, hardware-coded model string? Jul 14 10:00:53 you could have a generic model name in .dts and have user space put the real one in sysinfo Jul 14 10:01:05 the other thing that what you suggests duplicates is binary code: lots of images which are virtually the same save for a couple bytes ;P Jul 14 10:02:19 later you could make a routerboard zImage which contains all those .dtb images, but compressed Jul 14 10:02:34 and let the compression get rid of the binary data duplication Jul 14 10:03:07 so there's a way to select the correct dtb at boot time? Jul 14 10:03:28 you'd have to write some code for that Jul 14 10:03:31 ha Jul 14 10:03:36 i see ;) Jul 14 10:03:49 it wouldn't be much code though Jul 14 10:03:55 since you can reuse the existing zimage wrapper code Jul 14 10:04:18 but i would suggest doing it later, after you've ported a few devices Jul 14 10:04:31 then you add code which populates the memory node, and add code that sets the chosen/cmdline, and suddenly you have a second stage bootloader ;) Jul 14 10:04:39 ^ Jul 14 10:04:40 ;D Jul 14 10:05:04 oh, and code that populates the mac-addresses in the dts file Jul 14 10:06:03 updating sysinfo will not update the string printed during boot (dmesg) tho Jul 14 10:06:09 correct Jul 14 10:06:37 well i guess I'm going to go for the path of least resistance ;) Jul 14 10:07:18 still waiting for a reply from mikrotik, the archive they sent me had ipq40xx code but no board data Jul 14 10:07:25 I'm afraid they might have embraced DTS Jul 14 10:07:36 and won't share the description files Jul 14 17:34:23 rmounce: ping Jul 14 17:39:01 Hi, I'm trying to send a patch to openwrt-devel mailing list but somehow https://lists.infradead.org/mailman/listinfo/openwrt-devel does not load for me... Jul 14 17:39:09 is it down? Jul 14 17:45:52 stikonas: for me it also does not load Jul 14 17:46:10 but I still get mails Jul 14 17:46:18 last from 2 hours ago Jul 14 17:47:00 Hauke: welll, the thing is I was not registered Jul 14 17:47:14 so I am not sure what will happen to my email. Does it go to moderation queue? Jul 14 17:47:25 the esata port is slow as hell on the r7800. unfortunate Jul 14 17:48:11 stikonas: I do not know Jul 14 17:48:19 well, I'll wait and see... Jul 14 17:48:31 if nothing happens, I'll try later Jul 14 17:51:43 20MB/s Jul 14 17:51:46 jesus Jul 14 17:53:09 oh wrong drive Jul 14 17:53:17 260MB/s. that's more like it but still slow Jul 14 17:54:54 tplink c1750 v4, suddenly 2.4G slows down to 200kbps, reboot does not help, eventually changed wifi chan from 6 to 11 fixed it, dmesg nothing unusual, channel 6 is actually cleaner than channel 11, what gives? Jul 14 17:55:05 never saw this before Jul 14 17:56:31 might be whatever's in your neighbourhood that continually gives you crappy wifi? Jul 14 17:57:17 karlp: used cellphone to analyze wifi for a while, nothing unusual, chan6 is the cleanest actually, anyway very odd Jul 14 17:57:41 could just as well be non-wireless traffic Jul 14 17:57:44 and i switched another router to 6 and it worked just fine Jul 14 17:57:47 (bt, zigbee, a microwave) Jul 14 17:58:36 i have 3 routers (two are running testing builds), each on 1, 6, 11, so I basically swapped 6 and 11 and it 'fixed' it Jul 14 17:59:20 just switched back and see if it occurs on c1750 in the future Jul 14 17:59:30 1, 6, and 11 are all saturated here, so i'm using 3 Jul 14 18:00:10 use 3 so that can you clobber 1 and 6 up more? :P Jul 14 18:00:49 lol Jul 14 18:02:04 whitewolf: more like be clobbered by them Jul 14 18:02:35 being on 3 and being in range of APs on 1 and 6 is more harmful to them than it is to you Jul 14 18:02:46 you're leaking into both 1 and 6 on 3 Jul 14 18:03:04 if your AP is nice, it's also waiting for clear on both ends of the channel Jul 14 18:03:21 there is the matter of signal strength Jul 14 18:04:24 in the spot where i stuck the archer c7, there is very little space near other AP's where the signal is reachable Jul 14 18:05:21 if that were fully true you could use either 1 or 6 in that spot without much problem with spectrum Jul 14 18:06:07 it's true in the spot where the AP is but not where the clients are Jul 14 18:06:58 any transmitting station on those channels creates problems for the APs/clients of the other networks Jul 14 18:07:02 doesn't matter that it's not your AP Jul 14 18:08:29 but clients don't have the level of txpower than an AP does Jul 14 18:09:13 hehe Jul 14 18:09:14 that's somewhat true Jul 14 18:09:15 some do Jul 14 18:09:18 yeah Jul 14 18:09:29 you need as much power to shout back to the AP as it used to shout to you generally Jul 14 18:09:39 physics says different in some situations but that's generally true Jul 14 18:10:38 (if i know where a station is, and i have mimo, i can likely use a bit less power with beamforming to reach you after we figure out where its best to transmit from) Jul 14 18:11:27 if you have access to a wifi radio that supports 802.11 tap you could record the radio traffic and see how badly they're punishing you / you're punishing them Jul 14 18:14:31 * russell-- went to a millimeter wave physical layer talk where the speaker talked about the 20db gain required, using 100 antenna elements, and just finding beams to talk to the other end was a daunting problem, not to mention trying to track each other in a dynamic scattering environment. Jul 14 18:15:01 indeed Jul 14 18:17:55 btw it's not just 1, 6, and 11 saturated here. there are other stations using channel numbers in between, too. many 5ghz channels also have multiple stations Jul 14 18:19:33 i kind of wish 802.11ax would fix the whole 2.4ghz mess Jul 14 18:19:47 and only give three channels Jul 14 18:34:43 there will never be a fix for 2.4GHz Jul 14 18:34:54 people will keep using old hardware that still works Jul 14 18:45:10 yes, that is true **** ENDING LOGGING AT Sun Jul 15 03:00:01 2018