**** BEGIN LOGGING AT Wed Feb 06 02:59:57 2019 Feb 06 03:58:05 gch981213: is it me or is spi fast-read default? I can't see a difference on my device Feb 06 04:08:46 Mangix: If you mean m25p,fast-read: it's only needed when SPI frequency is above 60MHz. The regular read instruction 0x03 doesn't accept such a high frequency. Feb 06 04:09:04 oh Feb 06 04:09:13 Guess 50MHz is not high enough Feb 06 04:10:59 gch981213: I was reading some of the ramips dts files. The spi-max-frequencies that are paired with fast-read are all over the place Feb 06 04:15:04 Mangix: If it works without fast-read option, there is no need to add that. Comparing to normal read instruction 0x03, the fast-read instruction 0x0b needs 1 extra dummy byte for preparation before flash can dump any data out. Feb 06 04:18:17 Mangix: Ah. I just checked Winbond W25Q128JV datasheet and it says that normal read instruction accept SPI frequency up to 50MHz. Feb 06 04:18:43 Oh I see. So it's flash chip dependent Feb 06 09:36:33 * ldir falls foul of software flow offloading, DSCP marking (or lack thereof) and sqm (cake) - that was interesting Feb 06 09:38:23 ldir: what happened? I never tried -j FLOWOFFLOAD together with cake because I read it didn't work. Feb 06 09:40:07 it works absolutely fine *unless* you're trying to do DSCP mangling to get packets into different priority cake tins. Feb 06 09:42:19 cake normally uses the DSCP value to determine which tin a packet flows through. You can use iptables mangle table to change DSCP value. Which is 'fine' on egress but doesn't work on ingress 'cos the packet hits the qdisc *before* it hits iptables mangle. Feb 06 09:43:00 xback: "I'm not seeing the symbol issue here (ubuntu 18.04)" (imx6 4.19 missing symbols) - I'm wondering if you're building with the same config as I do: CONFIG_ALL_KMODS=y CONFIG_ALL_NONSHARED=y CONFIG_TARGET_ALL_PROFILES=y and building with verbose mode enabled `make V=s` Feb 06 09:44:40 xback: just checking unless I try to build it under ubuntu 18.04 inside docker by myself Feb 06 09:44:49 There's a workaround to that by using connmarks. So to cut long story short, I had incoming packets being forced into different (wanted) tins, but bizarrely the ack packets from router weren't egressing via the same (in this case) low priority tin. Feb 06 09:47:42 Since the connmarks were set based on the mangled DSCP value, I couldn't understand how incoming packets had been correctly marked & thus 'tinned' but the egress ACKs weren't. So the clue as such is ingress uses connmarks for tin selection, egress using dscp. Because of flow offloading the egress on an established connection doesn't go through the mangle table, thus didn't have the DSCP changed for *every* packet, thus went to default tin. Feb 06 09:47:42 Simples! (sticks head in bucket) Feb 06 09:50:58 * ldir now wonders if it's possible to use connmarks on egress with cake - hmmmmm Feb 06 09:51:47 ldir: thanks for the explanation, that makes sense. Since I do not do quashing or remarking or anything, I'll try to enable flowoffload and see how this changes my performance. Feb 06 09:52:46 I'm at 40% %sirq when doing 250 megabit/s on my WRT1200AC, which is from what I can see a performance regression from older versions (17.x) Feb 06 09:53:31 I used to be able to do full gig at ~400 byte average packet size with it (when I started doing bufferbloat testing) Feb 06 09:58:32 * ldir has to go out - shopping - but will be back later. Cake has got insanely complicated so not surprised slower Feb 06 10:02:02 ynezz: I shared the config I'm using to test that build :) Feb 06 10:03:40 xback: ah, I've missed it, sorry, where is it? Feb 06 10:12:00 Has anyone used a tplink eap120 or something similar? I was going to test a build for eap225, but I can't find out how I would test it. Do I need this tplink "console cable"? Feb 06 11:06:19 ynezz: new paste created: https://pastebin.com/HsTWdRM4 Feb 06 11:29:53 xback: CONFIG_LINUX_4_14=y ? :-0 Feb 06 11:32:14 xback: I'm usually testing with the http://downloads.openwrt.org/snapshots/targets/imx6/generic/config.seed as used on build bots, to prevent possible build breakage on build bots Feb 06 11:32:30 xback: you seem to be missing CONFIG_ALL_NONSHARED=y (I have it enabled as well) Feb 06 11:33:44 ynezz Feb 06 11:33:56 srry for that. i cleaned my staging tree for a kernel bump Feb 06 11:34:03 that why 4.14 is active again Feb 06 11:34:14 it was changed manually Feb 06 11:36:07 Can anyone help me figure out why make doesn't make factory/sysupgrade images? Feb 06 11:42:00 xback: hm, I get same missing symbols with your OpenWrt config, 4.19 and `make V=s target/linux/{clean,compile}` Feb 06 11:42:33 xback: that's on Ubuntu 14.04 and Debian 8.10 Feb 06 11:43:49 xback: are you really building in verbose mode? Otherwise you don't see the missing symbols issues, but build bots will hit this issue Feb 06 12:57:20 can I trick/coax the image building to make rootfs in uboot format? is that built in already and just not in menuconfig? or will I have to hack it in Feb 06 13:00:10 karlp: rootfs in u-boot format? usually uImage is only the kernel, not the rootfs Feb 06 13:01:20 bootz will boot the zimage already, but I'm using FEL on sunxi to give it a rootfs too, and I need to "mkimage mkimage -A arm -O linux -T ramdisk -C gzip..." the rootfs Feb 06 13:01:59 booting the comibined ramdisk works too, but I can't do that with some other things I'm trying to write and set Feb 06 13:02:31 ynezz: meaning these? Feb 06 13:02:35 Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) (DRM) [M/n/y/?] m Feb 06 13:02:37 DRM DP AUX Interface (DRM_DP_AUX_CHARDEV) [N/y/?] n Feb 06 13:02:38 kselftests for DRM (DRM_DEBUG_SELFTEST) [N/m/?] (NEW) Feb 06 13:02:41 yeah, no (image) target for that, you'll need to hack it in Feb 06 13:03:01 (I have no idea what "FEL" is) Feb 06 13:03:10 sunxi rom bootloader thing. Feb 06 13:03:41 saves me from having to write spi flash or sd cards Feb 06 13:04:16 karlp: is the rootfs required? Feb 06 13:04:35 well, for what I want to test, yes. Feb 06 13:04:48 so not a fixed bootloader requirement Feb 06 13:04:55 the plain ramdisk images work too, the split method just gives me a few more options Feb 06 13:05:14 not passing the ramdisk jsut gives me the usal kernel boot and then panic with no rootfs Feb 06 13:07:16 I'm confused, do the ramdisk images work, or do they panic with no rootfs? Feb 06 13:07:27 the ramdisk images work just fine. Feb 06 13:07:47 but I can _also_ write them separately, which lets me write some _other_ chunks of memory and set other options. Feb 06 13:07:59 which I want to do, otherwise the ramdisk would be jsut fine Feb 06 13:08:12 this is not a shortcoming of the sunxi target or the standard builds in anyway :) Feb 06 13:14:12 do you know an example target at all that provides multiple images? Feb 06 13:14:33 I can just add it to Device/Default..Images:= ? Feb 06 13:21:59 xback: yep Feb 06 13:22:47 xback: as in https://github.com/openwrt/openwrt/pull/1714/commits/f99de950864eb8d0c8f297b144e7d89eb0bf37f4 Feb 06 13:27:12 xback: I was wondering how it's possible that you didn't hit CONFIG_DRM_DEBUG_MM_SELFTEST as it was renamed to CONFIG_DRM_DEBUG_SELFTEST Feb 06 13:45:08 ynezz: just encountered the symbol on my Brix. didn't see it on my builder. checking the delta .. Feb 06 14:52:49 ok, I've got no idea how IMAGES:= stuff works. enough time on that. Feb 06 14:53:09 anyone used the wave-1 CT FW with IBSS/MESH recently? I haven't changed that firmware in some time and I thought it was doing IBSS OK. Someone reported problems though: https://github.com/greearb/ath10k-ct/issues/68 Feb 06 15:00:03 greearb: I can verify this if you want? Feb 06 15:02:12 sure, any help is welcome...I don't have time to dig into that problem anytime soon Feb 06 15:02:52 also curious to know if older openwrt worked better, if we can bisect then it helps a lot. Feb 06 15:04:32 [Wed 2019-02-06 01:42:19 AM PST] cake normally uses the DSCP value to determine which tin a packet flows through. You can use iptables mangle table to change DSCP value. Which is 'fine' on egress but doesn't work on ingress 'cos the packet hits the qdisc *before* it hits iptables mangle. <------ i went with a previous recommendation to use cake on egress only Feb 06 15:32:30 it's not a limitation of cake, it's a limitation of linux network stack ordering and affects any/all qdiscs. In fact ingress qdiscs only exist in a very limited sense, the usual workaround being to create an ifb interface, re-direct the ingress of your input interface to the ifb and put the qdisc on the egress of the ifb. Which is what sqm-scripts does. But it still all happens before iptables mangle. You can just about persuade tc filters Feb 06 15:32:30 to use connmarks to redirect those to different qdisc leaves, and in the case of cake, get those leaves to edit the skb priority in such a way that cake notices and uses that flagging instead of DSCP values to select tin. Feb 06 15:39:29 hi, I need to xxd to compile a package of mine. I tried to add package tools/xxd. But when I add PKG_BUILD_DEPENDS:=xxd to a package in feeds, make complains that that package has a build dependency on 'xxd', which does not exist Feb 06 15:39:52 do new host tools in tools/ need to be registered somewhere? Feb 06 15:40:18 or do I need a different PKG_BUILD_DEPENDS variable Feb 06 15:41:01 or are all tools build by default? Feb 06 15:49:57 bah, bloody fucking strace again Feb 06 15:50:17 was there any strace bump that didn't break? :/ Feb 06 15:52:26 hmph, no numa :( Feb 06 15:56:13 greearb: ping Feb 06 15:58:12 greearb: currently not seeing the issue. AC to N 5GHz, HT40 chan 149 Feb 06 16:13:58 I should also say that cake on ingress is useful for ensuring internal host fairness of the incoming link - e.g. host 1 downloading 1 file v host 2 downloading 20 would result in each host getting 50% of the link. In theory you can further enhance that by putting flows into different classes (tins) e.g. diffserv3 that has Bulk, Best Effort & Voice tins, each with differing priorities and maximum bandwidth limits in the face of competition. Feb 06 16:13:58 It's that further enhancement that was giving me hassle. Feb 06 16:27:37 xback, can you update that bug with how you are successfully testing it? Feb 06 17:24:31 Working on a "new" device (EA8300, ipq40xx) and aware of the (closed) PR for that device Feb 06 17:25:11 U-Boot 2012.07 on the device offers "dhcp - boot image via network using DHCP/TFTP protocol" Feb 06 17:25:59 I am guessing that it would support some type of initramfs -- any experience with use of this kind of "flash-free" testing? Feb 06 17:37:57 most u-boot devices support such Feb 06 18:03:16 (Even with a 12-core Ryzen 5, the from-scratch build takes a long time!) Feb 06 18:19:16 jeffsf, I am trying to uboot to test without flashing as well Feb 06 18:20:16 jeffsf, do you see that message from serial console of the router? Feb 06 18:27:29 Interrupt boot from serial, "help" Feb 06 18:27:58 (IPQ40xx) # help Feb 06 18:28:14 Includes: Feb 06 18:28:16 bootp - boot image via network using BOOTP/TFTP protocol Feb 06 18:28:23 dhcp - boot image via network using DHCP/TFTP protocol Feb 06 18:28:37 tftp - boot image via network using TFTP protocol Feb 06 18:28:50 usbboot - boot from USB device Feb 06 18:29:00 (at least on my device) Feb 06 18:31:57 http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot has some potentially useful information, if "generic" across platforms Feb 06 19:20:12 https://ae01.alicdn.com/kf/HTB1tVt.KFXXXXaJXVXXq6xXFXXXR/PT7A7514WE-PT7A-7514WE-SOP8-ic.jpg_640x640.jpg Feb 06 19:21:04 Could this be the flash? I can't find any data for it. Feb 06 19:31:16 https://pdf.datasheet.live/datasheets-1/pericom_semiconductor/PT7A7514WE.pdf Feb 06 19:31:28 so, no Feb 06 21:50:53 ipq40xx: Is it "officially" on 4.19 for "new" work, or still 4.14? Feb 06 21:52:50 4.14 Feb 06 21:53:19 :+1: Feb 06 21:53:56 jeffsf: yhou can always check here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq40xx/Makefile;h=ab7b174e4000063e585d53368d48174663b52014;hb=HEAD#l12 Feb 06 21:54:00 or similar for other targets. Feb 06 21:54:31 Great, thank you for the pointer Feb 06 21:55:41 If only GPL source drops came with such clarity and knowledgable support! Feb 06 22:01:50 wishful thinking :) Feb 06 22:05:45 my "gpl source" is the openwrt tree.... Feb 06 22:07:32 but it lacks an ancient kernel and loads of security vulnerabilities Feb 06 22:07:37 why would you even want to use that?! Feb 06 22:09:22 ipq40xx tends to be on 3.14.77 Feb 06 22:09:23 hrm? Feb 06 22:09:47 oh, I meant my prodcuts "gpl source" _is_ the openwrt tree Feb 06 22:10:17 pkgadd: 3.14? dafuq Feb 06 22:12:10 ipq806x is on 3.4.103 and ipq8074 on 4.4.60... Feb 06 22:12:19 hmmmm Feb 06 22:12:29 maybe I should revisit Feb 06 22:12:33 my frr port Feb 06 22:12:44 6.0 is shaping up to be just delightful Feb 06 22:26:59 I can't get serial output from this AP. There are two internal switch solder pads on the pcb but no switch is on them, maybe jumping one of them enables console? Is that a bad idea? Feb 06 22:28:32 share pics could help Feb 06 22:28:42 it's a bit hard from just "there's some pads" Feb 06 22:28:43 mvnetbiz: TP-Link seems to "forget" to populate series-resistors and/or pull-up/down resistors Feb 06 22:29:38 Yes, photo would help -- including the area around what you believe to be the serial port, front and back, if it looks like there are any empty SMT pads Feb 06 22:33:16 https://i.imgur.com/kpje39V.jpg Feb 06 22:33:48 R237 and R225 are open Feb 06 22:33:54 https://i.imgur.com/kpje39V.jpg Feb 06 22:33:57 Oops Feb 06 22:34:30 oh i see Feb 06 22:34:42 one each tx and rx maybe? Feb 06 22:34:56 R230 might be a pull-down for RX Feb 06 22:35:11 Yes, probably, one for RX, one for TX Feb 06 22:35:20 Do you think SW1 and SW3 have any function for bootloader? Feb 06 22:35:59 P17A7514 is a voltage monitor from my recollection of this morning's p[osts Feb 06 22:36:04 isn't ar8 a switch chip? Feb 06 22:36:10 are you expecting a serial console there? Feb 06 22:36:17 I'd be pulling the can off Feb 06 22:36:19 oh im dumb that's so obvious where the trace goes across the resistor spots Feb 06 22:36:42 the ar8033 is the switch chip yes Feb 06 22:36:47 I take it hose are your soldered wires on ttheir? Feb 06 22:36:52 yes Feb 06 22:36:55 that does look like a worthwhile place to probe :) Feb 06 22:37:14 I'm with karlp on that -- I was focused in too closely Feb 06 22:37:18 do you think that is not the serial console though? Feb 06 22:37:32 but yeah, I'd try shhorting r237 r225 and perhaps a pullup on r230 Feb 06 22:37:38 what's the SoC on this board? Feb 06 22:37:46 QCA9563 Feb 06 22:37:56 rioght, so don't go looking for a console attached to the sswitch Feb 06 22:38:28 EAP225 -- TP-Link AP Feb 06 22:38:46 there are 2 cans Feb 06 22:40:53 are you sure these pads go to the switch? it looks like the trace goes up further Feb 06 22:41:26 https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=3636805 Feb 06 22:41:43 Has photos under the cans Feb 06 22:41:45 I got 2 * TTL-232R-3V3 for $2 each today Feb 06 22:42:30 I had that link earlier but I can't view on laptop for some reason do you have the parent link for that Feb 06 22:42:55 I think I need some cookie before I can use that link directly Feb 06 22:43:04 FCC ID TE7EAP225V3 Feb 06 22:43:11 https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=Y&application_id=nSqNt5TCfN03rpw0%2F%2B%2FFMg%3D%3D&fcc_id=TE7EAP225V3 Feb 06 22:45:14 One of the photos shows some kind of header in J3, with R237, R230, and what is probably R225 populated Feb 06 22:45:42 (Page 2 of 8) Feb 06 22:46:31 oh yeah those are where I have soldered Feb 06 22:46:46 C817 suggests that the pad closest to "J3" is V+ (leave unconnected) Feb 06 22:47:11 the left bottom is GND and above that is 3v3 Feb 06 22:48:00 oh I explained that wrong but yes you are right Feb 06 22:48:43 Does a resistor matter or can I just jump it Feb 06 22:49:04 Always dicey with any direct connection to a SoC Feb 06 22:49:19 where can I get that tiny of a resistor Feb 06 22:49:48 LOL, they're cheap, but not the easiest things to solder by hand! Feb 06 22:50:11 You can use a regular 1/4 or 1/8 W one with care Feb 06 22:50:43 I have an air gun for soldering Feb 06 22:50:49 See, for some other TP-Link serial games https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#recovery_using_serial_connection Feb 06 22:51:18 and https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#serial Feb 06 22:51:48 which gives some values for the missing resistors on one of the variants Feb 06 22:51:51 interesting. Feb 06 22:52:24 I'll see if I have some regular 800ohm resistors Feb 06 22:52:43 the pad is insanely small though Feb 06 22:52:50 I don't know what country you're in, but SMT resistors a fraction of a cent each through Mouser, Digikey, or the like. Feb 06 22:53:42 yeah I just want to do it now though :) Feb 06 22:53:59 Can you confirm the voltage level that the SoC is supplying? 3.30 V is a lot safer than 2.5 V Feb 06 22:54:28 the VCC on the 4 pins I have soldered to is 3.3 Feb 06 22:54:54 What about TX from the SoC? Feb 06 22:55:51 How would I tell? multimeter on the place where the resistor should go? Feb 06 22:56:22 There is a lot of 3v3 on the board but there is also some stuff like TP2V5_PHY near that ar8033 switch chip Feb 06 22:56:45 Yes, DMM on the chip-side Feb 06 22:57:36 I guess I could just short the resistor spots and put a regular resistor on the wire to the usb adapter Feb 06 22:57:40 or 'scope, if you've got one Feb 06 22:57:47 Don't have a scope :( Feb 06 23:00:31 It's 2.55 Feb 06 23:10:27 If you solder-bridge them, I'd put a couple hundred Ohms in series with your adapter's TX. While most 2.5 V logic is 3.3 V tolerant, better to be safe Feb 06 23:50:49 yay! Feb 06 23:52:58 * karlp cheers Feb 06 23:54:22 so wiki says this has 8MiB of flash, but /dev/mtd seems to say 16MiB Feb 06 23:55:44 init mtdparts=spi0.0:128k(u-boot),64k(pation-table),64k(product-info),1536k(kernel),14336k(rootfs),192k(config),64k(ART) mem=128M board=AP152 Feb 06 23:55:51 Am I reading that wrong Feb 06 23:56:00 Bonus day for you! Feb 06 23:57:20 Flash Manuf Id 0xc8, DeviceId0 0x40, DeviceId1 0x18 Feb 06 23:58:57 Same ID as an Archer C7 V4 -- https://forum.openwrt.org/t/archer-c7-v4-tftp-issues-solved/27958 Feb 07 00:28:42 https://hastebin.com/ogituhotez.bash Feb 07 00:29:50 Looks like the tftp alias in there overwrites the flash. I am not sure how to boot from ram, but the wiki suggests you can do it Feb 07 00:30:34 just use tftpboot and then bootelf or bootm Feb 07 00:32:59 the ramdisk build options in openwrt's buildroot are great for this sort of testing Feb 07 00:35:07 I have make openwrt-ar71xx-generic-eap225-v3-initramfs-kernel.bin Feb 07 00:35:14 would that be the right thing to boot Feb 07 00:35:22 sure. Feb 07 00:35:35 hang on, is this ar71xx? Feb 07 00:36:20 ok, apparentyly it is. Feb 07 00:36:41 shuold it be ath79? Feb 07 00:36:59 I don't really understand where ar71xx even comes from Feb 07 00:37:40 there is ath79 directory under ar71xx in the git Feb 07 00:38:20 ath79 and ar71xx are "same" Feb 07 00:38:35 ath79 is the future name for it Feb 07 00:39:31 I have no clue what I'm doing I just copied some code from other stuff. Feb 07 00:39:47 Theres all sorts of terms in the code I couldn't figure out what they mean like what is GMAC0 Feb 07 00:40:46 someone who wrote most of the original stuff must be people with inside docs from qualcomm? Feb 07 01:08:46 Or deduced from the GPL drops Feb 07 01:10:23 Is there an "easy" way to find out when Linux accepted a patch? (Short of cloning the entire archiive...) Feb 07 01:11:00 In particular, https://patchwork.kernel.org/patch/10426401/ Feb 07 01:11:20 (.dts for qcom-ipq4019-ap.dk07.1-c1) Feb 07 01:13:57 https://hastebin.com/izewizazil Feb 07 01:15:03 karlp, I am assuming I need to run it with some kind of boot parameters? Feb 07 01:20:55 00:30:34 karlp | just use tftpboot and then bootelf or bootm Feb 07 01:21:04 tftpboot just copies files from tftp to ram. Feb 07 01:21:09 bootm and bootelf run them. Feb 07 01:21:11 also go. Feb 07 01:21:16 dependsing on what you tftp'd Feb 07 01:21:19 nvm got it Feb 07 01:21:29 I had to do setenv bootargs 0x81000000 console=ttyS0,115200 root=31:04 rootfstype=squashfs init=/init mtdparts=spi0.0:128k(u-boot),64k(pation-table),64k(product-info),1536k(kernel),14336k(rootfs),192k(config),64k(ART) mem=128M board=EAP225 Feb 07 01:21:46 yiou can pass args to tftpbooty to specify the file too... Feb 07 01:21:51 WOO root@OpenWrt:/# Feb 07 01:22:12 I'm officially a hacker now Feb 07 01:23:03 I think everything is working except my mac address comes from some random memory address Feb 07 01:23:53 if all the hardware works, you can now kinda copyu the old notes on writing it to flash and living in the future Feb 07 01:27:36 I think I have the switch config wrong I only have wlan0 Feb 07 01:30:14 what is the normal config for AP with single ethernet port? Is the eth0 WAN port, and you connect to it's wifi to configure it after you flash if you do a factory image install? Feb 07 01:32:57 was a topic on the list a few months back, Feb 07 01:33:13 traditionally, all openwrt devices hahd the same config, regardless. Feb 07 01:33:33 a few people have suggested that all single port devices should be dhcp on wan, and AP on wifi out of the box, Feb 07 01:33:37 not sur ehow far that went. Feb 07 01:36:04 probably easier to just leave it default and let the user configure it. Feb 07 01:39:13 Worth checking, but several one-port devices come up with the port as LAN and the wireless disabled. That way they work in failsafe and can be reconfigured from there. Feb 07 01:44:59 See, for example, ath79_setup_interfaces() in target/linux/ath79/base-files/etc/board.d/02_network Feb 07 01:48:10 I put it in a section of that file that had some similar hardware Feb 07 01:49:42 I started in target/linux/ar71xx/files/arch/mips/ath79/ should I move it to target/linux/ath79 Feb 07 01:49:57 jeffsf: yeah, it works like that, but not always actualyl any better. Feb 07 01:50:06 requires people to plug directly into them Feb 07 01:50:30 Better than serial ;) Feb 07 01:50:53 I wonder if this one works with the serial-ethernet connector Feb 07 02:29:32 jeffsf_: failsafe isn't affected by default ethernet configuration. It's configured by some scripts in /lib/preinit if I remember correctly. **** ENDING LOGGING AT Thu Feb 07 02:59:57 2019