**** BEGIN LOGGING AT Wed Jul 26 03:00:03 2017 Jul 26 03:37:07 * nerdboy is getting a c++ headache... Jul 26 15:54:38 * nerdboy makes a bunch of random kitchen noises Jul 26 15:58:20 hello all :) Jul 26 15:58:28 hello Jul 26 15:58:35 Hi Jul 26 15:59:03 hey Jul 26 15:59:15 Hi Jul 26 15:59:48 hi all Jul 26 16:00:08 * nerdboy pokes _av500_ with a long stick Jul 26 16:01:41 o/ Jul 26 16:01:57 almost a roll-call... Jul 26 16:02:05 who's missing? Jul 26 16:02:26 heh if I'm here on time, then there's no way anyone is missing Jul 26 16:02:43 ee: :-) Jul 26 16:03:03 nm, i couldn't read the dark purple nick... Jul 26 16:03:13 that's 6 Jul 26 16:04:03 * nerdboy pokes _av500_ and then av500 some more Jul 26 16:04:29 did he sat he had a thing today? Jul 26 16:04:35 *say even Jul 26 16:04:48 nerdboy: not that i heard Jul 26 16:04:58 * nerdboy has a 1030 mtg too Jul 26 16:05:17 nerdboy: you missed it! 10:30 was 1.5 hours ago!! ;-) Jul 26 16:05:25 * jkridner found a serial cable yesterday morning and lost it again before having a chance to plug it in now. :-( just the way my luck has been going. Jul 26 16:05:40 tlwoerner: +1 :) Jul 26 16:05:46 tlwoerner: haha Jul 26 16:06:16 not late in *my* timezone... Jul 26 16:06:44 * nerdboy has the super-power of being late in multiple timezones Jul 26 16:06:59 haha Jul 26 16:07:36 also i can make my wife run to the bathroom just by looking at her Jul 26 16:07:41 nerdboy: like my drunk uncle used to say... "it's 5pm *somewhere*" Jul 26 16:07:55 it's a gift... Jul 26 16:08:37 i guess we should get going. roll call is done Jul 26 16:09:08 what should we do next? presentations or issues? Jul 26 16:09:10 Sure. I think it was my turn to do the weekly presentation Jul 26 16:09:25 ee and who else? Jul 26 16:09:31 who else is presenting this week? Jul 26 16:09:41 ravi? Jul 26 16:09:57 ravi i guess Jul 26 16:10:18 yep, just checked the logs from last week Jul 26 16:10:20 Ravi and I Jul 26 16:10:26 I'll go ahead and start it off Jul 26 16:10:41 yes me and ee Jul 26 16:10:55 Also, evals are due this week Jul 26 16:11:04 Have they been completed? Jul 26 16:11:14 Finally, the Rust library is feature complete! Jul 26 16:11:37 I finished up the SPI implementation last weekend, which was the last major component before completion Jul 26 16:11:43 ...and the crowd goes wild... Jul 26 16:11:46 hahhahaha Jul 26 16:12:18 also did a bit of "giving back" to the community with a PR on some of the other libraries in the Rust ecosystem that are doing similar things Jul 26 16:13:22 although hilariously enough as soon as I submitted the PR CI gave me a big fat X since the libs are using older versions of Rust. Either way I look forward to continued work on my own library and other community efforts Jul 26 16:13:58 This brings me to the next stage of the project (the Go lib), which should proceed much faster with the experience of working on it in Rust Jul 26 16:14:29 GPIO has been started and should be up by the end of the week, and PWM should come before the next weekly meeting Jul 26 16:14:45 do you feel the rust stuff is done from the point of view of testing and documentation? Jul 26 16:14:51 * nerdboy notes "upstream" will make you go "wha??" Jul 26 16:15:59 or just "done" in terms of coding? Jul 26 16:16:27 ee: have you looked at supporting both the linux mainline as well as the rcn-ee patch sets? is your code independent of the deltas? Jul 26 16:16:42 I think the documentation does need some more work. The version on docs.rs isn't the latest since I haven't bumped the version up, but I plan on doing that this week. I also need to get some more examples up, especially with the newer additions to the library. These will be on going as I work on the Go library Jul 26 16:17:38 jkridner: to be totally honest this is the first time I've heard of the rcn-ee patch set. Right now it's mainline only, but I'll take a look at that. Shouldn't be too hard to support if there aren't any major changes Jul 26 16:17:59 patch for what exactly? Jul 26 16:18:12 Overall, I'm happy with the progress made so far and we're on track for a successful project. Jul 26 16:18:26 is there a link to the rcn-ee (i have no idea what that is)? Jul 26 16:18:37 jkridner: I also have a hardware request for some additional things that would help with testing Jul 26 16:18:58 ee: such as (hardware requests) Jul 26 16:19:28 ee: you'd need to remind me using regional purchase links. I'm really losing track with distractions. Trusting folks not to take advantage of the .org with my lack of tracking. Jul 26 16:19:37 and lastly, if anyone has experience with TravisCI and autotools please let me know, my CI keeps dying on me because of pkg-config shenanigans which I have 0 experience with Jul 26 16:20:15 there's always #autotools Jul 26 16:20:15 jkrider: Of course. I'll send you an email by the end of the day :) Jul 26 16:20:20 ee: in general, if you support the mainline kernel, backing off to support the 4.4-ti and 4.9-ti kernels should be pretty easy. rcn-ee used mainline stuff where possible. Jul 26 16:20:42 ee: best to also paste links here. my inbox is flooded. Jul 26 16:21:35 being a user-space library, i wouldn't expect the kernel to affect it too much (?) i wouldn't think the kernel<->user-space interface to change much (if ever)? Jul 26 16:21:38 tlwoerner: microSD card and maybe a cheap UART peripheral to test with, since the stuff in the Google IoT dev kit I got is mostly I2C or regular GPIO. Jul 26 16:22:05 also it might be a stretch but I need to solder some headers on the hardware I got and I don't have an iron :( Jul 26 16:22:13 no SPI? Jul 26 16:22:25 local hackerspace? Jul 26 16:23:37 jkridner: that sounds good. Like tlwoerner said, it shouldn't be too hard to support since it's a userspace library, especially if it's based of linux 4.* since the 3.* kernel has some differences Jul 26 16:23:48 jkridner: I will PM you with a link by EOD then :) Jul 26 16:24:11 tlwoerner: sometimes the 4.x-ti kernels add interfaces, especially things like the pinmux helpers. Jul 26 16:24:22 ee: maybe you could drive to Jason's house for some soldering work ;-) Jul 26 16:24:24 ee: no PM/DM, just paste here. Jul 26 16:24:34 tlwoerner: I don't think we have one around here. Maybe I'll try to sneak into the EE labs at school Jul 26 16:24:35 PM/DM === spam for me. :-) Jul 26 16:24:45 jkridner: got it Jul 26 16:25:04 ee: yea, i was just googling, i'm surprised the KW area doesn't have one! maybe it's up to you to start one up? ;-) Jul 26 16:26:11 tlwoerner: heh between school, GSoC, co-op, and a student design team, my hands are more than full enough Jul 26 16:26:36 ee: https://wiki.hackerspaces.org/Kitchener Jul 26 16:27:51 tlwoerner: just checked through the kit again and it's almost all just regular GPIO peripherals, with the exception of the OLED display (I2C) and the hilarious fingerprint reader (UART) Jul 26 16:28:02 thanks for the link, I'll take a look Jul 26 16:28:21 KwartzLab looks good Jul 26 16:28:42 anyways I think that about wraps it up for my section, gotta leave some time for ravi :) Jul 26 16:28:55 ee: sounds good, thanks for the update Jul 26 16:29:07 my pleasure :) Jul 26 16:29:21 i will take a look later today Jul 26 16:29:33 should I start? Jul 26 16:30:12 ready set go? Jul 26 16:30:53 So, this week I got much needed changes implemented in the working of bootloader server Jul 26 16:31:34 Earlier the actions were very much stateful, doing things in series like first spl transfer then uboot.. Jul 26 16:31:50 not like a true server Jul 26 16:32:24 now, it listens to events of rom, spl sevice connection and starts the tftp server accordingly Jul 26 16:33:05 so, it should just work after a reset or connection after disconnection after once running the server Jul 26 16:33:46 also, earlier, the server was servicing requests in series too, first bootp, arp then tftp Jul 26 16:34:15 I just ported the exact working of the c server without rethinking much Jul 26 16:35:09 ravikp7: so, currently, you support all the same features as the c server? Jul 26 16:35:12 Now, the server first identifies the request received and then service the request by handling the received data accordingly Jul 26 16:35:13 ravikp7: can you catch folks up on what is and isn't working? Jul 26 16:36:35 tlwoerner: c server was using ramdisk to boot into mass storage mode, this uses uboot's ums feature Jul 26 16:37:37 we can't get the spl built from uboot mainline to transfer uboot over usb Jul 26 16:38:16 so, I'm using SPL from an older build, and uboot binary built from mainline for ums Jul 26 16:39:54 we also got the server transfer uboot on OS X too, we're having issues with usb module that we're using, it still isn't working on Windows Jul 26 16:40:10 ravikp7: good! thanks for the clarification Jul 26 16:41:36 this server can be extended to transfer ramdisk also with just a few lines of addition Jul 26 16:41:54 as jkridner notes, would be helpful for pocketbone Jul 26 16:43:37 so I guess server is almost complete with documentation Jul 26 16:43:56 ravikp7: what about etcher.io integration? Jul 26 16:44:03 Now comes the integration part, with a app for flashing Jul 26 16:44:34 ravikp7: documentation is pretty good for the server. I believe it still needs a few updates based on recent changes and maybe some API references for serving up different files. Jul 26 16:45:23 jkridner: yeah, plan to complete that part this week Jul 26 16:45:57 Last week I got the app with UI running, with a button click on app, server ran and booted BB into mass storage mode Jul 26 16:46:31 For integration with flashing modules I plan to use etcher sdk Jul 26 16:47:42 currently, from the modules used in etcher, only drivelist and image-write are stable and maintained Jul 26 16:48:13 with those, I can I can only get flashing done for uncompressed images Jul 26 16:48:37 The etcher sdk is due release in a week or two Jul 26 16:49:21 As noted by its developer, all modules are complete, they just got to combine them to get the sdk architecture comlete Jul 26 16:49:32 *complete Jul 26 16:50:18 The sdk has APIs from drives scanning, decompression, flashing and downloading images for flashing Jul 26 16:51:26 Apart from these flashing modules, I've got task to add sudo prompt in app to run server and do flashing, and manage the app state Jul 26 16:51:54 I'm currently working on these Jul 26 16:52:11 Link for server code https://github.com/ravikp7/node-beagle-boot Jul 26 16:52:25 App : https://github.com/ravikp7/BeagleBoot Jul 26 16:52:42 That's all from my side Jul 26 16:52:52 questions/ suggestions ? Jul 26 16:53:53 you must've covered everything i guess... Jul 26 16:54:42 ravikp7: sounds good, thanks for the update. i'm looking forward to giving it a whirl Jul 26 16:55:03 yes, indeed :) Jul 26 16:55:26 tlwoerner: sure, ping me here, if you encounter a problem Jul 26 16:56:03 ravikp7: the etcher.io API also has user elevation (sudo) functionality, yes? Jul 26 16:56:57 jkridner: in current release they use the sudo-prompt npm module, don't know for the sdk Jul 26 16:58:45 jkridner: that also needs some good amount of things handled on different platforms for the drive access, looked into etcher's code, they should've included it also, I guess... Jul 26 16:58:56 ravikp7: is that something you can add as a feature to the server? Jul 26 16:59:14 ravikp7: or does it seem unnecessary given the invocation mechanism? Jul 26 16:59:51 ravikp7: we should do some more promotion in their community to see if they can help any of our cross-platform issues. They seemed very supportive when we met at Embedded World. Jul 26 17:00:38 jkridner: havn't figured out yet, I'm just trying to get sudo-prompt for app to run the server currently Jul 26 17:02:22 jkridner: they plan to add all functionality in etcher app, this server for BB Jul 26 17:03:38 jkridner: what all features do you expect from this flashing app for BeagleBone apart from what I know Jul 26 17:04:49 as roadmap items, I'd like it to be able to load a ramdisk image distro, to automatically detect the version of the image a connected board is running and the ability to automatically display the Cloud9 IDE. Jul 26 17:05:29 from once a ramdisk image distro (buildroot?) additional functions might be possible, like a console for error recovery. Jul 26 17:05:47 * jkridner expects this to be the app folks use to manage their BeagleBones. Jul 26 17:06:22 jkridner: so, I guess I should ahead in the same way I'm on, a standalone app exclusively for BeagleBones Jul 26 17:06:31 oh, I'd also anticipate people using it to save-off their images into files that can be redistributed, including dealing with the fact that rcn-ee is using the disk uuid to specify the disk image in u-boot. Jul 26 17:07:22 did anyone ring the end-of-mtg gong? Jul 26 17:07:29 ring ring Jul 26 17:07:30 ravikp7: well, I like having our own app for which we have full control, but I'd like for etcher.io to also adopt your server so their standard app can put BeagleBones into UMS mode for their app to use. Jul 26 17:07:40 nerdboy, m_w: :-D Jul 26 17:08:12 sorry I wasn't all here today Jul 26 17:09:13 ravikp7: for the GSoC, I'm mostly concerned about having a quality cross-platform server that provides us a good base for recovering/flashing BeagleBones such that they don't need to go through the step of converting non-flasher images into flasher images. Jul 26 17:10:20 ravikp7: and, ideally, though definitely a stretch goal, to have a app that is always ready to grab the https://beagleboard.org/latest-images images. Jul 26 17:10:37 jkridner: I was also thinking same for standalone app, a developer there, was discouraging use of etcher sdk for another tool... said they talked to you about just giving them server module :( Jul 26 17:11:09 jkridner: I plan to develop all the above said features even after GSoC :) Jul 26 17:11:11 ravikp7: 3 big gaps outside the usb-tftp-server cross-platform issues exist.... 1) programming the uuid, 2) programming compressed images and 3) doing the fetch from the website. Jul 26 17:11:44 ravikp7: yeah, my desire was to simply be able to hand-off the server to them for their needs. Jul 26 17:12:03 ravikp7: and they had the roadmap item of adding the fetch from the website.... Jul 26 17:12:15 the uuid issue is a bit of a wildcard. :-/ Jul 26 17:13:33 ravikp7: the uuid may or may not be fixed with an exact image duplication. I'm not sure. I have doubts that it is. In fact I'm pretty sure it isn't. Jul 26 17:13:48 can you explain more about the first two issues? Jul 26 17:18:51 jkridner: so this week I start with adding API's for a different file transfer, what it should be like? should I even remove spl and uboot from there and add api for a file transfer which requires a file name, vid and pid for transfer? Jul 26 17:19:13 jkridner: apart from spl, uboot, ramdisk, anything else? Jul 26 18:08:00 ravikp7: yeah, apps built with StarterWare. Jul 26 18:08:19 ravikp7: doing bare-metal development should be made super-simple with this server. Jul 26 18:09:56 ravikp7: I think the interface is something like creating a USB handler and having various servers you can add to the handler, namely TFTP and UMS (UMS is just notification now and should be able to hand-off back to the system somehow). Jul 26 18:10:41 ravikp7: for the TFTP server, yeah, I think just providing the VID/PID and associated file to transfer is sufficient. I think you are pretty close to that now. Jul 26 18:11:11 I could imaging doing other associations besides VID/PID, but it handles all the use-cases I know right now. Jul 26 18:11:19 s/imaging/imagine/ Jul 26 18:11:59 jkridner: and outend point for usb transfer too, it's different for rom and spl device Jul 26 18:19:05 jkridner: will be also looking to get a hack around for node-usb to set configuration on Windows if I can, FYI I've opened an issue with node-usb for this problem on Windows and OSX, expecting some help from there... **** ENDING LOGGING AT Thu Jul 27 03:00:01 2017