**** BEGIN LOGGING AT Sun May 17 02:59:57 2020 May 17 03:01:15 build #86 of cns3xxx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/cns3xxx%2Fgeneric/builds/86 May 17 03:44:16 build #85 of x86/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/x86%2Fgeneric/builds/85 May 17 04:09:28 build #85 of mvebu/cortexa9 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mvebu%2Fcortexa9/builds/85 May 17 04:41:32 build #85 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mvebu%2Fcortexa53/builds/85 May 17 04:44:29 neoraider: I wrote (probably too basic) test cases for CI testing ucert/tests/cram/test_ucert.t May 17 04:51:45 neoraider: I've FS#2762 somewhere on my todo list May 17 05:06:46 build #83 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/archs38%2Fgeneric/builds/83 May 17 05:36:28 build #80 of layerscape/armv8_32b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/layerscape%2Farmv8_32b/builds/80 May 17 05:53:48 build #81 of ramips/rt288x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ramips%2Frt288x/builds/81 May 17 06:25:23 build #79 of brcm47xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/brcm47xx%2Fgeneric/builds/79 May 17 06:44:12 build #80 of octeontx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/octeontx%2Fgeneric/builds/80 May 17 07:10:54 ynezz: ah, I didn't see that there was a ticket already. The patches I sent yesterday should fix it May 17 07:56:31 build #79 of brcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/brcm63xx%2Fgeneric/builds/79 May 17 08:20:48 neoraider: that ucert series doesnt apply here http://paste.ubuntu.com/p/28GwCWCWyR/ May 17 08:24:37 neoraider: do you've some git tree somewhere? May 17 08:28:22 ynezz: ugh, it seems patchwork broke because I sent the libubox patch as another reply to the same thread - so now ucert PATCH 1/13 is missing from the series: https://patchwork.ozlabs.org/project/openwrt/list/?series=177415 May 17 08:28:45 ynezz: give me a sec, I'll push my repos somewhere May 17 08:31:01 neoraider: ah, didn't noticed that, applied that missing 1/13 manually now, thanks May 17 08:33:08 neoraider: btw (as I've noticed your usign fix as well), there is some ongoing attempt to replace usign with signify https://github.com/openwrt/openwrt/pull/2911 May 17 08:35:56 ynezz: nice - and I see the fingerprint operation is implemented correctly in that patchset, always producing the same number of characters May 17 08:37:29 ynezz: when testing my ucert patchset in OpenWrt, you'll need the usign patch at well. Otherwise the improved fingerprint checks in ucert will break the build for 1/16 of keys instead of the current 1/256 of keys May 17 08:41:23 neoraider: you should probably ping that FS#2762 bug report, as you'll probably get another tester :) May 17 08:45:48 Will do May 17 09:31:00 neoraider: I just added some fuzzing to that cert_load https://gitlab.com/ynezz/openwrt-ucert/-/commits/wip/ and will fuzz it for some time May 17 09:31:54 would be nice to get some of that multiblob examples into the fuzzing corpus May 17 11:23:08 build #117 of brcm2708/bcm2709 is complete: Failure [failed signunpack] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/117 May 17 11:29:35 build #118 of brcm2708/bcm2709 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/118 May 17 13:32:11 * f00b4r0 needs an mtd expert: nbd rmilecki maybe ? May 17 13:37:34 build #320 of imx6/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/imx6%2Fgeneric/builds/320 May 17 17:03:06 rr123: I'm not sure what any of that means :D May 17 17:05:05 hmm. 19.07 builders seem to have stopped, some targets aren't built. May 17 17:45:40 zorun: ping May 17 17:45:54 pong May 17 17:46:03 query May 17 17:56:45 ynezz: ping May 17 20:52:18 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html May 17 21:13:21 https://www.youtube.com/watch?v=0gx_r5ohYaA May 17 21:15:02 dave that is a real gem May 17 21:15:05 :-D May 17 21:16:21 blogic: he was also at battlemesh with his guitare last year May 17 21:16:33 blogic: do you plan to clean up target/linux/mediatek/files-5.4/drivers/net/phy/rtk/ in the future? May 17 21:16:48 Hauke: yes May 17 21:17:13 quite a pitch there May 17 21:18:10 I was supprised to seen that some mediatek engineers inteagretd this realtek switch May 17 21:18:41 i could make some comments about how suprised i am about vendors code May 17 21:18:43 :-D May 17 21:18:54 dont throw stones when sitting in a glass house :-D May 17 21:20:51 blogic: I was just looking at this code because I have a device with mt7622 + this RTL switch and would like to create a DSA driver May 17 21:21:03 ok May 17 21:21:09 there is a dsa rtl driver upstream May 17 21:21:13 just want to sync with you prevent double work May 17 21:21:13 already looked into this May 17 21:21:23 but lack the time May 17 21:21:24 yes, but this HW uses a diffeernt interface May 17 21:21:37 this silicon should work with the upstream driver May 17 21:21:40 you have to add an interface for SGMII and some other layer is also diffeernt May 17 21:21:47 mtk used the rtl silicon early int he mt7622 phase May 17 21:22:03 they now have mt7531 (with dsa) and dropped the eval kits with rtl May 17 21:22:08 +I am supprised they did not use a mediatek switch May 17 21:22:15 they had none May 17 21:22:24 mt7531 was not taping out at the time May 17 21:22:30 tapping ? May 17 21:22:34 taping May 17 21:22:35 ok May 17 21:22:36 1 p May 17 21:23:12 mt7530 only had rgmii May 17 21:23:18 *typing sounds* tap tap tappity tap May 17 21:23:23 well trgmii with the propriatory 2,5gbit interface May 17 21:23:34 but "taping out" comes from "tape", it seems May 17 21:23:39 hell__: tapping my feet reading that May 17 21:23:59 hell__: yup, had to type it to read it May 17 21:24:01 :-D May 17 21:24:13 I wonder what year the last tape out used tape. May 17 21:24:37 karlp: when whent he last person hung up their cellphone May 17 21:24:40 ok so only the early device will use the rtl switch and the next gen of mt7622 devices will use mt7531 switch May 17 21:24:41 the reels in which chips are packaged use some thin tape to hold them in place May 17 21:24:50 Hauke: correct May 17 21:24:52 hell__: that's not the tape being talked about though... May 17 21:25:06 karlp: I can imagine May 17 21:25:09 blogic: not sure I follow the cellphone? May 17 21:25:11 tape out is when silicon gets mass produced May 17 21:25:21 karlp: hang up the phone May 17 21:25:34 no it is when you send the tape with the schematics to the fab May 17 21:25:39 > Historically, the term references the early days of printed circuit design, when the enlarged (for higher precision) "artwork" for the photomask was manually "taped out" using black line tape (commonly Bishop Graphics crepe). May 17 21:25:47 then you wait 3 months and get your first silicon back May 17 21:25:47 Hauke: is that where it comes from ? May 17 21:25:48 https://en.wikipedia.org/wiki/Tape-out May 17 21:25:58 blogic: yes May 17 21:26:08 learned something new there May 17 21:26:33 the tape out is the deadline for the chip engineers May 17 21:26:53 which moves us to chicken bits May 17 21:27:24 so qca will, when they fix a silicon level bug not fix the silicon but duplicate the block in a later rev May 17 21:27:55 and then if the newer core part fixes the issue they fuse the chicken bit in the fab to use the newer part and not the broken older one May 17 21:28:02 obviously called chicken bit May 17 21:28:31 love to hear the story why it is named that way May 17 21:28:40 hrm, I thought chicken bits were for having two variants on the same rev, May 17 21:28:49 karlp: yes May 17 21:29:00 you were talking abotu duplicating on a later rev? May 17 21:29:06 a newer eco will have the old and new ethernet core May 17 21:29:19 and then they can choose in the fab which to use May 17 21:30:04 well, even in the first revs, you cna have multiples... depends how chicken you are... May 17 21:30:10 chicken bits are meant to be able to "chicken out" of a certain feature that is broken May 17 21:30:16 you would probably not do it on a complete ethernet mac level or similar, but e.g. the CRC function in the TX path May 17 21:30:19 for example, "disable clock gating" May 17 21:30:26 Hauke: yes May 17 21:30:35 it was just an example for some pipeline feature May 17 21:30:42 maybe even have one chicken bit per clock gate May 17 21:30:57 but then i am just a sw guy ... May 17 21:31:06 so i am talking about stuff i am not an expert on May 17 21:31:47 I've recently tried to bring up RAM on an Intel Haswell machine, and ran across some of these things May 17 21:32:14 hell__: the clock gating is normally controlled by SW anyway, so it that would not work for a IP core, the driver would just not do it May 17 21:33:39 hell__: ok the x86 CPUs are probably different May 17 21:35:48 yes, they are recursively cursed May 17 21:36:09 the closer you come to them, the more cursed subsystems you see inside of them **** ENDING LOGGING AT Mon May 18 02:59:57 2020