**** BEGIN LOGGING AT Fri Mar 15 02:59:57 2019 Mar 15 16:33:28 ynezz: Your leds migration worked flawlessly, can You take this over? Mar 15 16:37:36 tmn505: thanks for testing, what do you mean by take this over? :) Mar 15 16:40:38 I'll drop my patches regarding leds, You'll send new migration script, then I'll resend adjusted patches for epg5k. Mar 15 16:44:22 feel free to include it in your v2, I don't need any credits for this, it was just an idea how to improve this copy&paste situation Mar 15 16:45:31 do you've it available somewhere in Git ? Mar 15 16:47:31 no not yet, I'll prepare it later today. Mar 15 17:15:18 tmn505, can I grab patches 1/4 and 2/4 from your engenius epg5000 series? Mar 15 17:35:29 lach1012: yes, please Mar 15 17:37:48 tmn505, k. I'm letting it run through the ci. this will take a day or so Mar 15 17:40:25 lach1012: hm ci, what do you use for that? Mar 15 17:43:28 ynezz, it's homebuild thing on top of a do instance. For most devices I can just do compile-tests anyway. Mar 15 17:56:56 ah, ok Mar 15 18:50:12 * ldir is playing with some freshly home grown kernel module code - conndscp - a tc action to store/restore DSCP values to/from firewall connmarks. Mar 15 18:52:50 translation, the DSCP you set on an egress packet will magically have that same DSCP applied to any ingress packets - QoS differentiation across links that wipe it out Mar 15 18:54:13 and 'cos it's done as a tc action it can be used with any dscp aware qdisc incl but not limited to CAKE Mar 15 18:54:52 * ldir now needs to go and lie down - it's been a hard & horrible week for a variety of reasons Mar 15 21:49:05 Amazing, a git rebase that was nearly painless Mar 15 21:56:32 did I understand your (edited) post correctly that you basically have your device working now, including factory images? (yes, I know, kernel 4.19, dsa, lots of code which will need quite a while to become master material - just curious about the basic state) Mar 15 21:57:30 hrmf, why must this modem give me such a hard time Mar 15 22:04:48 pkgadd: Yes, have the images working without U-Boot env changes!!! Rebasing onto today's master and cherry-pick from chunkeey staging Mar 15 22:05:36 Still need to work out the two board.bin into board-2.bin for the IPQ4019 radios, but they are up and running Mar 15 22:06:26 Still have U-Boot resetting the environment the first time you try to switch from boot_part=1 to boot_part=2, but then works the second time Mar 15 22:06:44 But yes, it doesn't look like its destined to be a paperweight Mar 15 22:10:15 great :) Mar 15 22:10:31 :) Mar 15 22:11:43 Rebased build works -- confirming no strange merge issues Mar 16 00:03:00 jeffsf: out of curiosity, are you using qcom-smem or do you hardcode the partition map via DTS? Mar 16 00:03:31 DTS mapping, UBI rootfs and rootfs_data -- "standard" Mar 16 00:03:45 What is qcom-smem? Mar 16 00:03:53 (searching now) Mar 16 00:04:29 qcom-smem is a way to extract a partition map from firmware (bootloader) dynamically Mar 16 00:04:40 LOL Mar 16 00:04:59 doesn't help you with toggling between install locations Mar 16 00:05:15 Maybe once I figure out why U-Boot rewrites the environment Mar 16 00:05:31 I was just curious if there was a device other than the nbg6817 to use it ;) Mar 16 00:05:42 That one is going top haunt me! Mar 16 00:06:16 I'll put it on my list Mar 16 00:06:30 Spent enough time in assy code for one week ;) Mar 16 00:06:43 nah, just forget about qcom-smem's existence Mar 16 00:07:29 only the nbg6817 and two reference boards (ap148 and ap161 seem to use it) Mar 16 00:08:24 AH, OK -- Dallas isn't based on one of those, that I know of Mar 16 00:08:38 all of them ipq806x Mar 16 00:10:35 Machine model: Linksys Dallas WiFi AP router based on Qualcomm AP DK07.1-c1 Mar 16 00:20:11 At least the OEM ath board files are the same in the 2017 firmware as in the 2018 firmware Mar 16 00:20:24 Cuts the potential combinations down Mar 16 00:38:43 Now to figure out how to get the bmi-chip-id... Mar 16 00:38:56 and bmi-board-id Mar 16 00:43:40 ATH10K_DBG_BMI -- /me crosses fingers Mar 16 01:06:50 board binary file 'board-2.bin' is created Mar 16 01:32:05 Oh, that's ugly -- now that I've got the OEM board file, it shuts the other radio down for the upper 5 GHz Mar 16 01:32:27 Might have to go back to OEM firmware to see if that is "right" Mar 16 01:33:32 At least it tells me that I've probably got board-2.bin set up properly **** ENDING LOGGING AT Sat Mar 16 02:59:57 2019