**** BEGIN LOGGING AT Tue Feb 25 02:59:57 2020 Feb 25 12:52:20 I am a bit confused, I am crosscompiling a tool (this one: https://github.com/net-neutrality-tools/nntool/tree/master/ias-cpp ) and I get errors like error: sys/socket.h: No such file or directory or iostream: No such file or directory Feb 25 12:52:29 aren't those headers supposed to "always be there"? Feb 25 12:52:46 should I be digging on the Yocto side or is it something that could be messed up in the build scripts of the software? Feb 25 12:53:49 Jin^eLD: /me puts his bet on the latter. Feb 25 12:54:17 I kind of thought in that direction as well, not familiar with cmake but did not see anything out of the ordinary there... Feb 25 12:54:24 how hard does one have to mess up to miss the system headers? hmm Feb 25 12:55:34 Jin^eLD: just look at the resulting c++ invocations. Feb 25 12:56:32 it should have --sysroot? Feb 25 12:57:00 yes, i think so. Feb 25 12:57:14 its not there, that could explain it... Feb 25 12:58:02 question is how to fix it... I only did "inherit cmake" but I am not familiar with cmake as such Feb 25 12:58:13 I would be surprised if it filters out sysroot somehow Feb 25 13:00:21 actually, cmake.bbclass does not mention sysroot at all Feb 25 13:01:06 ah, I guess their script simply overwrites CXX flags thats how Yocto passes additional stuff Feb 25 13:12:21 right, --sysroot is part of CXX Feb 25 13:12:33 so if they're being 'clever' then that can be lost Feb 25 13:15:07 probably... if it was autotools I could have fixed it, but have not been friends with cmake from the very beginning :> Feb 25 13:16:27 but yeah. I think they are justt hard-setting some flags they think they need, bug ignore the already set environment Feb 25 14:22:50 rburton: thats why i repeated in my last session a couple of times, to not be clever and such Feb 25 14:23:02 If a certain project doesnt keep a license file in its source code repository, or even mentions the license in any of the source files, what should I set the LIC_FILES_CHKSUM to? The only mention of the license is on the webpage of the project. Feb 25 14:26:17 I noticed I can use the LICENSE="CLOSED" to workaround, but that doesn't really reflect the actual license.. Feb 25 14:26:54 BlastuR: probably the wisest would be to submit a patch to the project which adds the license. Feb 25 14:26:58 download a copy of the web page, and include it as part of the source code.. Feb 25 14:27:30 but ya, I'd be suspect that they can just change their licensing and there is little evidence of tampering in that case.. which could be a problem if there was ever a legal challenge Feb 25 14:29:00 outright fork it, and add a dump/screenshot of the webpage at the time of forking into a documentation directory, plus add the mentioned license file. Feb 25 14:29:39 yup, assuming the license permits forking Feb 25 14:30:20 * LetoThe2nd hereby hands fray the official fringe case medal Feb 25 14:30:44 BlastuR: care to name project and webpage so we can see and judge for ourselves? Feb 25 14:32:56 LetoThe2nd: It's not open source unfortunately. Feb 25 14:34:04 ya, if it's not open source, then likely forking isn't allowed and you are back to dubious use of whatever that code is.. so be careful Feb 25 14:34:21 this is where 'consult a lawyer' comes into play.. Feb 25 14:34:58 it's a workthing. we currently use the android buildsystem, which i hate. So im trying to setup a OE tree instead and im currently writing recipes for all the stuff. We don't have any license of inhouse code except some weird stuff on a wiki. I agree, all code should have some kind of mention of that license. But it doesnt Feb 25 14:35:19 if it's inhouse code, then it is likely CLOSED (assuming you wrote it) Feb 25 14:35:32 but still talk to the corporate lawyers about including proper copyright/legal notices in the code Feb 25 14:36:30 okay, thanks. I'll go with CLOSED then. **** BEGIN LOGGING AT Tue Feb 25 15:27:32 2020 Feb 25 18:17:09 thanks **** ENDING LOGGING AT Tue Feb 25 19:26:28 2020 **** BEGIN LOGGING AT Wed Feb 26 12:56:15 2020 Feb 26 18:37:08 JPEW: apparently the tinker vendor kernel has /sys/firmware/devicetree/base/system-id which corresponds to the sticker on the board Feb 26 18:37:17 vanilla does not seem to provide that Feb 26 18:37:20 do you know anything about that? Feb 26 18:48:01 Jin^eLD: No, sorry Feb 26 18:52:11 seems this feature did not make its way into the mainline kernel Feb 26 19:47:50 Jin^eLD: this is usually vendor kernel feature Feb 26 19:51:39 khem: so it does not make its way into the kernel in the form of some driver or something like that? after all its part of the hardware support? Feb 26 19:51:52 I found those patches in the 4.x debian tree, will see if I can make use of them Feb 26 19:54:28 I would guess its more just like something they inject into the device tree, and then its there for good or bad. there is no rule set in stone that you have to either consume all information in the devicetree, nor that the devicetree has to be complete Feb 26 19:56:08 hmm Feb 26 19:57:43 the firmware bit in the path is a bit irritating, you'd have to figure out where it come from exactly. but beyond that, i guess its more like "don't care" Feb 26 19:58:05 indeed, probably noone really needed it for anything... Feb 26 19:59:34 it could be injected by custom u-boot, even Feb 26 19:59:52 smurray: you think they'd have a custom u-boot per device? Feb 26 20:00:04 although that is probably less effor than a custom cpu serial per device? really not sure Feb 26 20:00:26 Jin^eLD: it might be reading from somewhere in u-boot and populating it in the devicetree it hands the kernel Feb 26 20:00:50 smurray: i'd guess that. some bit that read from an eeeprom or fusebits area, and injects into DT Feb 26 20:00:56 been there, done that. Feb 26 20:01:36 yeah, if you already have the logic in u-boot to read it to handle board rev differences, it's a simple path to that Feb 26 20:01:49 hi5es smurray Feb 26 20:02:01 versus spending the effort to write a kernel driver ;) Feb 26 20:02:09 I've not been there and have not done that and to be honest I am more of a userspace guy :) does this patch make sense to you guys? https://github.com/TinkerBoard/debian_kernel/commit/bf4d66860be2fba3ba72a4d46f22d878ac5ff6da#diff-80547cabf05e570f897035ef8b9ad0d1 Feb 26 20:02:16 like i said. been there, done that. Feb 26 20:03:05 not sure if I am looking at the right one but there isnt much concerning the systemid, but I don't really see where it might be coming from Feb 26 20:03:25 in of/base.c ... ouch Feb 26 20:03:37 yeah, whatever that code's for, it's bogus Feb 26 20:03:54 looks like written by an intern or such. Feb 26 20:04:00 :) Feb 26 20:04:09 industry best practises applied! Feb 26 20:04:10 they'd laugh at someone trying to upstream that Feb 26 20:05:00 :)) Feb 26 20:05:38 basically I was asked if there is anything on the tinker that could be used to "identify" it, and my first thought was of course - to use the mac address Feb 26 20:05:53 smurray: upstream is where the dead fish are coming from. right? RIGHT?!? Feb 26 20:05:57 but it was considered spoofable etc... then I found this system-id Feb 26 20:06:21 Jin^eLD: if you really want to spoof that then theres no magic to it too. Feb 26 20:06:57 well, I guess mac is easier to spoof? not sure... Feb 26 20:07:31 I probably should ask again about why mac would not be good enough, considering its a device that is not supposed to have any user/login capability Feb 26 20:07:37 Jin^eLD: for someone who wants to, not much of a difference. Feb 26 20:07:41 depends, tbh. If the board design is such that the mac is coming from an eeprom, then maybe not Feb 26 20:07:54 well, they want to use a stock tinker-s Feb 26 20:08:01 no custom hardware Feb 26 20:08:16 smurray: ip addr set womething. spoof done. or a systemd link match rule. Feb 26 20:08:46 anyways. Feb 26 20:08:50 LetoThe2nd: there are some MACs that won't let you change it, but yeah, it's pretty typical to be able to Feb 26 20:08:52 back to earning some money. Feb 26 20:09:08 smurray: hey, if i've got source.... Feb 26 20:10:36 ah damn, now I remember the use case... the tinker-s has a sticker with that system-id on Feb 26 20:10:38 on it Feb 26 20:10:38 Jin^eLD: you'll probably need to talk to ASUS folks to see if they do efuses or the like to set something unique per board, if the RK3288 even has such Feb 26 20:11:25 probably next step would be to see if they do something in u-boot, then Feb 26 20:11:47 Jin^eLD: Hmm, I wonder if there is some missing code to read the CPU serial number somewhere: $ cat /proc/cpuinfo | grep Serial -> Serial : 0000000000000000 Feb 26 20:11:54 smurray: well, tinker board does have this system-id printed on the sticker and its shown when runniing the vendor kernel.. Feb 26 20:12:35 JPEW: actually, would be indeed interesting to see if the Serial in cpuinfo is filled with the same number when running the ASUS vendor kernel Feb 26 20:13:48 Jin^eLD: sure, but unless there's an obvious driver somewhere to populate it, it's very likely being stuck into the DT by their board support in u-boot (which is very common, as we were saying earlier) Feb 26 20:14:40 smurray: i.e., if I understood the above dialog correctly, u-boot reads it out from the hw and puts it into the DT? Feb 26 20:14:50 so I should be looking at their u-boot patches? Feb 26 20:15:03 Jin^eLD: yes, that is the possibilty, and yes Feb 26 20:16:56 Jin^eLD: Yes, based on my reading there should be some mechanism where u-boot can stuff the serial number into the device tree and the kernel will read it Feb 26 20:19:00 Jin^eLD: Looks like the kernel is looking for a /serial-number property in the DT: https://elixir.bootlin.com/linux/v5.5.6/source/arch/arm/kernel/setup.c#L941 Feb 26 20:20:37 hmm.. I scanned their uboot git for commits containing "system-id" and did not find anything Feb 26 20:21:15 Jin^eLD: Based on their "interesting" patch for reading it, I doubt one that does it the "correct" way exists ;) Feb 26 20:21:37 heh good point :) Feb 26 20:22:18 Jin^eLD: Ah, I misread... ya something in u-boot should be setting the "system-id" property Feb 26 20:24:06 if it is, I am not finding it.. no commits are adding/removing string "system-id" Feb 26 20:29:25 Jin^eLD: Oh, hmm. It looks like they are overriding the write function of the sysfs node, which makes me think they are setting it from userspace some how Feb 26 20:30:31 JPEW: but it has to come from the hardware... because you can flash any tinker vendor image and it'll show whats printed on the sticker, so they have to read it from somewhere after all Feb 26 20:30:47 actually... let me boot up their image and grep if there is something in the etc scripts Feb 26 20:30:51 ehm, init scripts Feb 26 20:31:29 JPEW: I was discounting that possibility since it seems pretty lame to bother sticking it into the DT that way ;) Feb 26 20:31:42 smurray: Agreed Feb 26 20:54:32 ha! Feb 26 20:54:34 don't laugh Feb 26 20:55:00 so indeed - why would the kernel patch allow to set the serial from userspace?! Feb 26 20:55:03 because an init script does that Feb 26 20:55:37 https://paste.ee/p/gYuQn Feb 26 20:56:41 so while we were kind of discarding that possibility because it was so weird, they indeed chose exactly this :) Feb 26 20:57:17 so of course the kernel patch made zero sense for upstreaming Feb 26 21:01:35 Jin^eLD: Ah, great. So I think if you implemented the eeprom read in u-boot and set the DT property it will work Feb 26 21:02:44 well, I only need the serial in userspace... if I somehow can read /sys/bus/i2c/devices/2-0050/eeprom that'd be enough for me, but of course this node is not available when booting 5.5.x mainline Feb 26 21:04:40 I should be looking at "their" dts for the eeprom node, right? Feb 26 21:24:25 I think I found what may be missing in the mainline dts Feb 26 21:26:21 Jin^eLD: lol, that commit is horrible. nice buffer overrun there if you write strings longer than whatever amount of spaces they put in the system-id node Feb 26 21:27:03 KanjiMonster: I honestly have no idea why they decided to write that information into the kernel if it can anyway be read from userspace... Feb 26 22:09:42 OK, this patch does the trick: Feb 26 22:09:43 https://paste.ee/p/asmcX Feb 26 22:09:54 then I can access that eeprom from 5.5 stable as well Feb 26 23:01:02 Jin^eLD: Cool. You should submit that to the kernel Feb 26 23:22:08 JPEW: I got it from the tinker forum https://tinkerboarding.co.uk/forum/thread-40.html Feb 26 23:22:19 a user decompiled the dtb from the tinkeros kernel Feb 26 23:22:32 how would that work in terms of authorship? cuz ultimately its not my invention Feb 26 23:40:48 mhhh, but even what the linaro image prints from that eeprom is not what is actually on the sticker... Feb 26 23:41:02 I should have checked that first before celebrating Feb 26 23:41:22 although the patch does work same way as on the linaro image and makes the eeprom accessibleb for reading Feb 26 23:45:56 ah, dammit, forums say: the number from eeprom is not the number on the sticker, but it is unique Feb 26 23:46:53 correction: its the 2D matrix barcode on top of the audio jack, oh man Feb 26 23:46:55 :) Feb 26 23:50:31 and that works indeed, wow heh Feb 27 00:44:48 thanks for the pointers everyone! JPEW: I'll ask you for some hints regarding kernel submission if you don't mind, especially which dts exactly to pick as the target for the patch Feb 27 00:45:42 so far I just went with something that seemed OK to me, but I am not a kernel dev, so I am likely to be wrong there Feb 27 00:45:44 nite Feb 27 01:01:13 Jin|away: the tinker-s will never make it into an official yocto release since meta-rockchip is not part of core, that's the whole CORE + LAYERS model of OE development **** ENDING LOGGING AT Thu Feb 27 02:59:58 2020