**** BEGIN LOGGING AT Thu Mar 07 02:59:57 2019 Mar 07 03:00:53 Looks like it should be a bool, not a tristate Mar 07 03:39:39 mangix: I think you can fix your bricks by simply desoldering the second flash chip. Mar 07 12:47:22 any idea what image type the "breed" boot loader wants? Mar 07 12:47:44 might be uimage. how do i build that out of openwrt? Mar 07 12:50:22 use the sysupgrade image Mar 07 12:50:29 nah, it doesnt like that Mar 07 12:50:33 Im sure with the latest breed Mar 07 12:50:40 are you in latest breed? Mar 07 12:50:49 https://breed.hackpascal.net/ Mar 07 12:51:10 2018-06-12 [git-b25d73d] Mar 07 12:51:14 upgrade to latest first, then flash sysupgrade image Mar 07 12:51:14 no Mar 07 12:51:17 yeah thats old Mar 07 12:51:21 uuuh, i'd rather not do that Mar 07 12:51:29 well, up to ya. Mar 07 12:51:31 i dont have the source code and dont know if that will brick the board Mar 07 12:51:59 dont manufacturers usually put initialization stuff in there? Mar 07 12:53:37 like if i pick the stock breed-qca953x.bin i'm worried it might not contain the switch config, so it'll just be dead Mar 07 12:54:26 http://www.minihere.com/how-to-update-firmware-on-u-boot.html Mar 07 12:54:45 current breed accepts most aftermarket router firmwares Mar 07 12:54:56 openwrt ddwrt padavan tomato Mar 07 12:55:24 neither accepts sysupgrade nor uimage for me :/ Mar 07 12:55:26 this is ZBT Mar 07 12:55:41 it appears to want tplink image format maybe? Mar 07 12:55:42 zbt what Mar 07 12:55:48 at least there's some words here that say tplink Mar 07 12:56:00 https://breed.hackpascal.net/breed-mt7621-pbr-m1.bin Mar 07 12:56:01 zbt WE826-Q Mar 07 12:56:06 oh Mar 07 12:56:06 nah atheros Mar 07 12:56:10 is that mt7620? Mar 07 12:56:15 qca953x Mar 07 12:56:18 oh Mar 07 12:56:21 then dunno Mar 07 12:56:43 I only had experience with 7621/20 stuff Mar 07 12:56:50 aye thanks Mar 07 12:57:03 I say check breed's official thread Mar 07 12:57:08 i'm going to try feeding it a tplink image Mar 07 12:59:39 aep: rule #1 when trying to add support for a a device: start by finding a way to flash an image (or netboot) that doesn't rely on a working image (e.g. through serial access to the bootloader) ;) Mar 07 13:00:26 that would be the breed thing Mar 07 13:00:41 they explicitly removed tftp Mar 07 13:00:44 only webinterface Mar 07 13:04:28 hah. it accepted tp-link format Mar 07 13:46:53 when adding a new mach to ar71xx, how do i make sure the option is enabled by default? Mar 07 13:47:00 i mean, the kernel option Mar 07 13:47:28 i can set it in the default kernel config of course, but that doesnt seem to be correct as no other machs are set there Mar 07 14:26:00 aep: Why not try ath79 instead? everything in ath79 should work fine unless you need any kind of NAND support. ar71xx will be dropped eventually. Mar 07 14:26:30 aep: kconfig are added to target/linux/ar71xx/{subtarget}/config-default Mar 07 14:32:44 yeah switching to at79 Mar 07 14:32:46 i just hate dts Mar 07 14:34:57 aep: breed-{QCA SoC name}.bin are actually for TP-Link routers. Here in China, TP-Link usually use each board design for around 10 different models across 3 brand name (TP-Link/Fast/Mercury) so I think it's hard to pick a name for it. According to the author, those TP-Link breed supports LSDK firmwares (the one with rootfs before kernel) in additio Mar 07 14:34:57 n to tp-link firmwares. Mar 07 14:35:37 yeah. not sure what that is Mar 07 14:35:40 tplink format worked :) Mar 07 14:35:57 now i need to figure out how dts works D: Mar 07 14:36:44 any idea how to initialize a pm25lv512 in dts? Mar 07 14:36:53 i usually copy paste other dts, since i dont understand how that stuff works Mar 07 14:38:34 copy pasted the m25p80 stuff from another board, but the spi probe failed, so i guess its not the same Mar 07 14:39:22 switchport access vlan 69 Mar 07 14:39:22 power inline port perpetual-poe-ha Mar 07 14:39:22 Mar 07 14:39:33 oops sorry Mar 07 14:40:10 aep: It should be the same. kernel spi-nor framework supports that chip. Mar 07 14:40:21 oops. Mar 07 14:40:52 yeah it worked fine in ar71xx Mar 07 14:41:04 aep: I'm wrong. you'll need to change compatible string to 'pm25lv512', 'jedec,spi-nor' Mar 07 14:41:09 ooh Mar 07 14:41:37 how do you know that? i'd love to understand where all this magic stuff is coming from Mar 07 14:41:50 aep: https://elixir.bootlin.com/linux/v4.14.105/source/drivers/mtd/spi-nor/spi-nor.c#L1054 Mar 07 14:42:07 This weird chip doesn't have a JEDEC ID available. Mar 07 14:42:14 usually the source for the deivce Mar 07 14:43:06 hm ok. thanks Mar 07 14:44:16 aep: I'm probably wrong again. You could check the kernel binding documentation: https://elixir.bootlin.com/linux/v4.14.105/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt Mar 07 14:44:56 ah! Mar 07 14:46:47 I never met a chip without JEDEC ID so far and I couldn't tell how to write it in dts from that documentation :( Mar 07 14:48:32 pretty sure this is wrong anyway Mar 07 14:48:58 i have another board where there's a label on the chip and its a winbond Mar 07 14:49:07 so i'll just ignore the specs... Mar 07 15:08:12 well... maybe its a fake winbond Mar 07 15:08:19 m25p80 spi0.0: unrecognized JEDEC id bytes: 00, 00, 00 Mar 07 15:08:27 ath79_register_m25p80 works fine tho Mar 07 15:18:51 aep: Is that the only flash on board or it's the second flash? I don't think ath79_register_m25p80 supports non-jedec flash. Mar 07 15:20:15 i think i have a board with openwrt with that same flash chip Mar 07 15:20:16 only one Mar 07 15:20:35 yweah i'm wondering if i broke the spi thing Mar 07 15:23:28 hm Mar 07 15:23:29 [ 0.800000] m25p80 spi0.1: pm25lv512 (64 Kbytes) Mar 07 15:23:33 this is the original firmware Mar 07 15:23:36 heh nm Mar 07 15:23:37 [ 3.509705] m25p80 spi0.0: found mx25l12805d, expected m25p80 Mar 07 15:23:37 [ 3.515942] m25p80 spi0.0: mx25l12805d (16384 Kbytes) Mar 07 15:23:38 spi0.1 doesnt look like spi0 Mar 07 15:24:49 but not like spi1 either. whats the second number mean? Mar 07 15:25:33 aep: it's on SPI bus 0 but it used the second chip select. Mar 07 15:25:59 aah Mar 07 15:33:10 soooo flash@0 { req = <1> is apparantly not how you change CS? Mar 07 15:33:20 spi_master spi0: spi_device register error /ahb/spi@1f000000/flash@0 Mar 07 15:33:27 god i hate dts Mar 07 15:33:59 this doc https://elixir.bootlin.com/linux/v4.14.105/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt says reg : Chip-Select number Mar 07 15:34:03 aep: you'll need to figure out which GPIO is used as the second CS and set pinmux register accordingly. And for ath79 you'll need to patch spi-ath79 driver to accept more than 1 chipselects or add "cs-gpios = <0>, <0>" in dts to trick SPI framework setting correct num_chipselect. Mar 07 15:35:42 oh.. Mar 07 15:36:11 aep: Usually factory U-boot will set correct pinmux registers. Mar 07 15:36:51 yeah i mean, it worked fine with ath79_register_m25p80, so can't be that much magic Mar 07 15:40:06 ok i'm just dumb. its actually on spi0.0. bah Mar 07 15:42:47 aep: Is it really a 64k SPI flash? I don't think a 64k flash can do anything on a router. :( Mar 07 15:43:55 nah 16Mb Mar 07 15:45:13 m25p80 spi0.0: found w25q128, expected m25p80 Mar 07 15:45:28 thats the original firmware. i just get: Mar 07 15:45:32 [ 0.350783] m25p80 spi0.0: unrecognized JEDEC id bytes: 00, 00, 00 Mar 07 15:45:47 with the dts thingy at least Mar 07 15:46:11 i'll try m25p80-nonjedec Mar 07 15:59:23 aep: Is there any pinmux node in your dts? I assume that pinmux register for SPI CS0 may be overridden somehow. Mar 07 16:00:49 i included qca953x.dtsi which has one yes Mar 07 16:00:55 but i wouldnt know what to set it to Mar 07 16:02:46 the original kernel doesnt seem to use dts, so no idea how to get that information Mar 07 16:02:59 (obviously no source code available because china) Mar 07 16:03:39 but then again, ar71xx works just fine Mar 07 16:03:53 so must be my fault somehow for not knowing how the whole dts thing works Mar 07 16:04:09 i'll just stick to ar71xx Mar 07 16:39:48 oh ffs - WARNING: Makefile 'package/feeds/packages/postgresql/Makefile' has a build dependency on 'zlib/host', which does not exist Mar 07 16:55:33 aep: i had the same issue when i first ported my device to breed. I had to change the partition format for it to see the jedec id. see: https://github.com/neheb/source/commit/b7ece3b1241dc206e447a12dfdf50bc9ec10db17 Mar 07 17:02:58 interesting Mar 07 18:04:01 oh, something's going on... https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/?h=ath11k-bringup Mar 07 18:04:28 I even see John Crispin name there... I think I saw that name already Mar 07 18:04:33 rings a bell ;) Mar 07 18:08:04 what ? Mar 07 18:08:31 my other patches did not apply after the prior series Mar 07 18:08:44 but they fixed a null pointer caused by a dangling/corrupt linked list Mar 07 18:09:08 looks like the other patches work around the null pointer deref by introducing a memleak Mar 07 18:09:16 need to retest and fix again i guess Mar 07 18:20:35 is ath11k ax? Mar 07 19:38:56 crim-: the hardware, yes - the driver afaik not yet Mar 07 19:42:20 pkgadd: not yet .... Mar 07 19:42:36 ax has some pretty cool features Mar 07 19:42:48 OFDMA allows mutli ul/dl Mar 07 19:43:07 so clients can get assign resource slots which go down to a few kb Mar 07 19:43:22 and then the client receive trigger frames which are pseudo realtime Mar 07 19:43:39 and they start doing dl/ul in parallel on slices of the spectrum Mar 07 19:43:57 in a nutshell this means several hundred clients can ul/dl from an AP in parallel Mar 07 19:44:13 we all know the "wifi deos not work at the airport" scenario Mar 07 19:44:18 ofdma fixes this Mar 07 19:44:32 there is also an extension to wmm Mar 07 19:44:46 so the AP can push wmm+ profiles to the clients with an expire time Mar 07 19:45:20 the ap will send these out to stations then send trigegr frames and by doing so syncs the access slots on the band between all stas Mar 07 19:45:50 there is also mbssid, which means that a AP with >1 vap will not bcast several beacons but an aggregate of all of them Mar 07 19:45:55 this is backwards compat Mar 07 19:46:11 so the first becon in the aggregate is the legacy one and the other ones are the HE ones Mar 07 19:46:22 any pcap available? Mar 07 19:46:27 curious to see how it looks Mar 07 19:46:40 wireshark 3.2.0-rc6 has HE draft 3.2 support Mar 07 19:46:52 i made a pile of sniffs Mar 07 19:47:02 not near the machine where i stored them though Mar 07 19:47:14 mac80211_hwsim has HE support already Mar 07 19:47:24 but mbssid support is still missing from hostapd Mar 07 19:47:39 i am on a 19 hour flight tomorrow and plan to work on it :-D Mar 07 19:47:57 let me know Mar 07 19:48:29 the problem being, that mbssid is part of n/ac aswell but your sta needs to support it Mar 07 19:48:52 so in theory several of the HE features will work on older legacy units if their supplicant is a current one Mar 07 19:49:14 i am currently running backports-5.0-rc6 on my laptop with HEAD supplicant Mar 07 19:49:32 is there any document available explaining this? Mar 07 19:49:34 so i get support but obviously my handheld units are crap arse ancient sw support Mar 07 19:49:53 Mister_X: you need to be WFA memeber to get the 1,6k page pdf Mar 07 19:50:06 nad mine is watertagged so i cant share it :( Mar 07 19:50:07 SoL Mar 07 19:50:23 Mister_X: yarp, $corp sucks butthole Mar 07 19:51:01 blogic: yep, I'm quite interested in qcn5024/ qcn5054 and ipq8074, but it's probably quite a while until either becomes usable Mar 07 19:51:20 pkgadd: i have 8074 on my desk working on it Mar 07 19:51:37 pkgadd: it'll be 6-9 months till we see initial upstream Mar 07 19:51:49 however the ethernet is the same as ipq40xx Mar 07 19:51:53 :) Mar 07 19:52:09 and the builtin switch is supportable with qca8k dsa with a bit of wizardry Mar 07 19:53:32 so the SOC itself is closer to ipq40xx than ipq806x? Mar 07 19:53:48 nss will be a bit of a pita Mar 07 19:53:57 not sure if we even want to support it Mar 07 19:54:08 this is a quad core arm64 ghz soc Mar 07 19:54:25 so sw flow table offload might out perform nss Mar 07 19:54:29 yep, it should be fast Mar 07 19:54:37 ... at a higher power consumption Mar 07 19:56:40 power consumption itself, at least under full load shouldn't be that much of a problem for a stationary device - heat might be more of an issue, but those devices have fans anyways Mar 07 19:58:18 nope they dont Mar 07 19:58:26 8074 is passiv cooling Mar 07 19:58:32 it pretty beefy Mar 07 19:58:43 the sdk is sucky however Mar 07 19:59:10 nss is quad ubicom32 and uses little power Mar 07 19:59:22 so running on the arm64 doubles the consumption Mar 07 19:59:30 not done exact measurments yet though Mar 07 19:59:46 that's more than I'd have guessed Mar 07 20:04:14 ipq806x in my experience has higher latency on ethernet than my other devices. not sure why. Mar 07 20:09:28 mangix: 806x uses stmac and is not very good Mar 07 20:09:46 807x uses ipqess which is actually far better Mar 07 20:09:55 and has hw hashing/rgs suoort Mar 07 20:10:21 807x reuses the ethernet core of ipq40xx and not 806x Mar 07 20:10:25 hmm, at least the FCC image for https://fcc.io/PY3/17300397 suggest an active fan Mar 07 20:10:50 pkgadd: no fan on the unit on my ODM desk Mar 07 21:20:06 Having good luck with @chunkeey's 40XX tree w/ DSA on an IPQ4019 device -- not "UCI-friendly", but seems much more usable Mar 07 21:20:53 great that you're seeing progress with your ea8300 Mar 07 21:53:37 gch981213: do you know the offsets for mac address in breed? In OpenWrt's DTS files I only see uboot 0x1fc00 whereas breed has three mac address fields Mar 07 23:11:44 ha, got VirtualBox's native shared folders working in OpenWrt Mar 07 23:27:51 let's trace calls to the character device to get rid of the proprietary userspace module Mar 08 00:42:17 mangix: MAC address at 0x1fc00 is the one in "TP-LINK设置" page. "设置" means "options" here, and you may find a page called "LSDK设置" where you can configure MAC used in Atheros LSDK. Mar 08 01:01:02 gch981213: for the LSDK page, are those MAC addresses stored in u-boot or ART? Mar 08 01:38:20 mangix: ART **** ENDING LOGGING AT Fri Mar 08 02:59:56 2019