**** BEGIN LOGGING AT Mon Jun 27 02:59:58 2016 Jun 27 03:06:31 more docs coming? Jun 27 03:06:51 dia is fine/easy for quick diagrams... Jun 27 03:07:25 some of the symbol sets are a little fugly but who cares? Jun 27 04:19:25 * nerdboy sings the Where's Wormo_ song Jun 27 04:27:49 hey, it worked! Jun 27 04:27:52 inkscape is fun for diagrams Jun 27 04:28:00 :) Jun 27 04:28:19 dia probably faster... Jun 27 04:29:12 yeah for those who never tried out inkscape yet, I'll admit that Jun 27 04:30:19 Visaoni I vote for a diagram too, diagrams are great Jun 27 04:30:26 it also has a bunch of symbol sets Jun 27 04:31:04 little people in suits with computers even Jun 27 04:31:26 * Visaoni had just started thinking about a diagram Jun 27 04:32:04 pretty sure inkscape doesn't have june cleaver sitting at her desk with a mac Jun 27 04:32:30 heh you could even draw it on paper first & scan it, pending doing a real one in $drawing_program Jun 27 04:32:53 pretty sure nobody wants to try and read my handwriting Jun 27 04:32:56 nerdboy, and that's a feature not a bug, right? Jun 27 04:34:03 she's in the Cisco symbol set i think Jun 27 04:34:23 so i imagine they consider it a "feature" Jun 27 04:34:23 pretty sure I don't need an icon of any Macs in my drawing program Jun 27 04:34:38 they have pcs too Jun 27 04:35:01 gimme one with a tux & that might qualify as a "feature" Jun 27 04:35:03 some of the symbols are very domain-specific and some are just old... Jun 27 04:35:49 i'm not sure i like the libreoffice weeble-people better Jun 27 04:38:13 dia sure has some weird ideas about how to draw major gridlines Jun 27 04:46:42 did your google form thingy get filled out Visaoni? Jun 27 04:47:10 Wormo: yep, did it yesterday Jun 27 04:47:50 ok cool Jun 27 06:37:51 nerdboy, Wormo: diagram -> https://raw.githubusercontent.com/Visaoni/beagle-sonic-anemometer/gh-pages/images/beagle-sonic-anemometer.png Jun 27 06:38:05 thoughts? working on wiki page for it now Jun 27 06:41:12 some of the auxiliary detail for the other sensors is omitted Jun 27 06:41:56 looks pretty good Jun 27 06:42:24 the other sensors could be mavlink interface Jun 27 06:43:50 oh hey a diagram... looking Jun 27 06:46:00 I like it, good overview Jun 27 06:48:29 alright cool Jun 27 06:49:17 I think it's the right level of detail for the wiki page Jun 27 07:08:06 nerdboy: so the mavlink stuff, it looks like a serial protocol? Jun 27 07:12:17 sort of maybe? Jun 27 07:13:01 it's a real-time messaging thing for drones Jun 27 07:13:36 they have c/python/other bindings Jun 27 07:15:14 nerdboy are you thinking of it for the IMU <-> BBB interface? Jun 27 07:16:04 yup Jun 27 07:16:07 https://github.com/mavlink/mavlink Jun 27 07:16:24 messaging/marshalling library Jun 27 07:16:35 Visaoni the messages can be sent either over serial or network, IMU tend to do serial as the link layer Jun 27 07:17:31 also has mavconn framework, ardupilot firmware, and ground control pieces Jun 27 07:17:43 IMU firmwares like ardupilot can be set up to use mavlink messaging Jun 27 07:18:37 hm, interesting Jun 27 07:18:42 it would be more like "run base ardupilot firmware to send fused imu position/time/compass messages Jun 27 07:18:47 if the sonic anemometer were up on a drone, the BBB would probably be set up to send mavlink messages to ground control... Jun 27 07:19:02 the your stuff listens to the messages Jun 27 07:19:13 * Visaoni seriously hopes he isn't about to add "build a drone" to the proj Jun 27 07:19:19 heh no Jun 27 07:19:32 ^^ "if" Jun 27 07:19:41 multiple interfaces - shm/udp/serial Jun 27 07:19:57 for transport Jun 27 07:20:34 is there mavlink stuff for dealing with these sensors over the grove interfaces? Jun 27 07:20:47 aka imu over i2c Jun 27 07:20:48 either that or you use kernel modules or bbio interface and query yourself Jun 27 07:21:08 they're all mostly i2c/spi so yeah Jun 27 07:22:18 finish your doc updates and then you can google "ardupilot beaglebone" Jun 27 07:22:20 Visaonin mavlink for I2C? No I saw it running over serial port Jun 27 07:22:41 Wormo: not the firmware itself Jun 27 07:23:13 part of beagle host would run that instead of separate pixhawk Jun 27 07:23:41 actually pixhawk box does have i2c/spi and serial ports Jun 27 07:24:04 But talking I2C is something that happens on the backend, and results get reported via MavLink messages over a serial port Jun 27 07:24:28 doesn't have to be serial, and backend ardupilot Jun 27 07:24:43 *running on beaglebone* Jun 27 07:25:16 no pixhawk, no serial (except grove dht sensor) Jun 27 07:27:48 jic23: one of the patch which I got from your iio kernel repository is failing :( Jun 27 07:28:30 "...communication backbone for the MCU/IMU communication as well as for Linux interprocess and ground link communication" Jun 27 07:28:44 Wormo: it does it all Jun 27 07:29:04 Agreed, but I never saw it use I2C or SPI as transport for the mavlink messagess Jun 27 07:29:28 those IMU had serial as well, and every case I saw that's the interface that MavLink went over Jun 27 07:29:29 what does that say => backbone for the MCU/IMU communication Jun 27 07:30:03 It doesn't say I2C to me, because the pixhawk and friends have plenty of serial ports that can be used Jun 27 07:30:09 you're taking external serial connector from pixhawk to whatever? Jun 27 07:30:16 yes Jun 27 07:30:24 that's not this Jun 27 07:30:42 Wormo: I don't think we need mavlink to use I2C as transport. it's just that the imu uses i2c and I wanted to make sure mavlink could talk to it (seeing as most things seemed ot be saying serial imu) Jun 27 07:30:52 this the pixhwk/mavlink part running on bb instead of pixhawk hardware Jun 27 07:31:23 i2c is not a transport for mavlink Jun 27 07:31:50 but the firmware has to talk to the sensors somehow Jun 27 07:31:57 either i2c or spi Jun 27 07:32:44 in this case beaglebone is the pixhawk and the host Jun 27 07:32:49 Yes, it's the data collection part but not the MavLink messaging part, and I'm still confused about what the proposed Mavlink endpoints are Jun 27 07:33:13 probably should schedule a remote whiteboard session or something soonish Jun 27 07:33:34 it's an option, not a requirement Jun 27 07:33:50 the req is to get regular sensor data Jun 27 07:34:43 ok maybe sometime you'll draw us a diagram, to at least understand this optional idea Jun 27 07:35:06 it sounded intriguing but I'm having trouble following without a picture Jun 27 07:37:30 they're in your flir specs... Jun 27 07:38:15 we should publish them as "examples" Jun 27 07:38:16 the application to this project is not obvious, after hearing that this IMU talks I2C not serial Jun 27 07:39:03 the imu in a pixhawk is not serial either Jun 27 07:39:09 yes it was Jun 27 07:39:25 not inside the box Jun 27 07:39:33 the box interface is serial Jun 27 07:39:49 *external box interface Jun 27 07:39:50 the part which spoke MavLink to a host computer was a serial port Jun 27 07:40:09 yup, but the imu inside doesn't know shit about serial Jun 27 07:40:11 the other part wasn't MavLink, it was just sensor code... Jun 27 07:41:01 pixhawk is an autopilot, which is a lot more than an just imu Jun 27 07:41:36 but only the comms part was (optionally) MavLink, data acq was not Jun 27 07:42:10 that's why we'd run the same piece of software Jun 27 07:42:43 sorry, same piece of software as...? Jun 27 07:42:47 * nerdboy wondering why this is so hard Jun 27 07:43:03 I NEED a picture, already told you Jun 27 07:43:03 the same software as pixhowk! Jun 27 07:43:55 that doesn't make sense to me, where would we run ardupilot in this project? Jun 27 07:44:17 to get mavlink messages of processed sensor data Jun 27 07:44:50 ardupilot does sensor fusion for you, sens timestamped data, the whole shebang Jun 27 07:45:20 pretty much everything except the adc stuff Jun 27 07:45:23 ok so stealing the C code for the data processing Jun 27 07:46:07 and the transport and the messaging... Jun 27 07:46:49 To talk over udp ports internal to the bbb, between processes? Jun 27 07:47:13 if someone prefers to write a bunch of code from scratch. could do that to Jun 27 07:47:27 no, it's shm on the host Jun 27 07:47:44 lcm/ros or whatever Jun 27 07:48:01 * Visaoni is up for whatever ends up being the easiest Jun 27 07:48:10 My guess is ros is more likely to have an actual library for the data fusion Jun 27 07:48:36 ardupilot is written to run on a microcontroller, not so library-ish Jun 27 07:48:55 also runs on bb Jun 27 07:49:05 does it? then that's differentn Jun 27 07:49:11 depends on which version/fork i guess Jun 27 07:49:36 afaik bbmini is a senosr cape, there's no extra microcontroller Jun 27 07:49:52 really, interesting Jun 27 07:49:58 is it running on the prus? that would be a problem Jun 27 07:50:22 (just thinking, if it's a microcontroller port) Jun 27 07:50:25 probably not, but we'd need tp look Jun 27 07:50:27 right Jun 27 07:50:33 I'm looking for the code Jun 27 07:50:36 s/tp/to/ Jun 27 07:53:05 jic23_: did you get my earlier message? Jun 27 08:03:13 https://github.com/mavlink/mavlink_devguide <= current to 1.1 maybe? Jun 27 08:04:04 Hi kiran4399, just catching up with logs now. Busy weekend. Jun 27 08:04:33 yeah. jic23_: one of the patch which you sent is failing.. :( Jun 27 08:04:45 Which one and how? Jun 27 08:05:06 https://github.com/mirkix/BBBMINI Jun 27 08:06:29 so apparently you could make a flying anemometer Jun 27 08:06:50 jic23_: these 2 hunks. Jun 27 08:06:51 http://pastebin.com/sWXEkvsC Jun 27 08:07:14 Not applying to latest tree? Jun 27 08:07:19 or maybe a printed case you can detach and put on a drone airframe Jun 27 08:07:54 http://pastebin.com/se8ZYWVE Jun 27 08:08:08 yeah.. 4.4.8 Jun 27 08:08:28 jic23_: Jun 27 08:08:37 although it may be more of a drone speed gauge than an anemometer at that point Jun 27 08:09:10 would be amusing though... Jun 27 08:10:40 kiran4399, where is your 4.4.8 coming from? Jun 27 08:11:09 rcn did a backport of IIO just before I grabbed his tree for those patches. You may well need something in there... Jun 27 08:11:15 from the rcn.. Jun 27 08:11:29 jic23_: yeah.. that was in 4.4.12 Jun 27 08:11:30 but rcn was at 4.4.11 when I did that... Why running the older version? Jun 27 08:11:40 ok.. Jun 27 08:12:05 jic23_: so you want me to apply on the 4.4 latest? Jun 27 08:12:16 where rcn did the backports? Jun 27 08:12:21 Hmm.. Difficult to say what rcn has done since with backports :) Jun 27 08:12:52 https://github.com/beagleboard/linux/tree/4.4/drivers/iio/imu/inv_mpu6050 Jun 27 08:12:53 'probably' fine to do so. Though sounds like there has been a lot of pru changes recently and you'll want the latest version of those for the other bits of your project I think? Jun 27 08:12:56 this one? Jun 27 08:13:10 yeah.. I think so.. Jun 27 08:14:10 So I'd move as far forward as you can... Jun 27 08:14:22 looks like that tree has the r32 ti changes others are talking about... Jun 27 08:14:58 + a backport of IIO. Unless he's pulling my dev tree (and I'm going to shout at him if he is) there will be very few if any changes in IIO for him to have grabbed in the last month or so. Jun 27 08:15:52 so those patches should drop in fine. Unfortunately the 'interesting' way rcn makes those trees makes clean fast forwarding of the tree impossible so you'll have to cherry pick. Jun 27 08:17:36 Mind you looking at yesterday's logs there are some issues possibly with r32 kernel... Jun 27 08:18:23 or not reading further through yesterday ;) Jun 27 08:18:40 jic23_: hmm.. that hunk is failing again. not sure what the problem is.. Jun 27 08:19:02 Any visual difference in the code? Jun 27 08:19:12 Might be something silly like a white space difference. Jun 27 08:19:28 just apply it by hand if it is obvious what is going on... Jun 27 08:19:33 jic23_: no.. I clearly saw it.. there are large differences.. Jun 27 08:19:40 hmm. Jun 27 08:20:08 jic23_: I tried to manually change for those 2 patches but the funcions which you are removing or adding near them, are no where to be seen.. Jun 27 08:20:35 jic23_: the funny thing is the.. after backport.. more hunks are failing. Jun 27 08:20:52 I wonder if rcn has changed where he is backporting from... Jun 27 08:21:12 jic23_: those patches add support for the mag right? Jun 27 08:21:31 yup, well a fair bit more than that, but that's a side effect. Jun 27 08:21:39 what? Jun 27 08:22:16 Add support for any auxiliary sensor capturing. The ak magnetometer just happens to be one instance. Jun 27 08:22:39 There are boards out there with other things hanging off the chip as the bus is just pinned out via the internally mounted magnetometer. Jun 27 08:23:38 Can you do a diff between the driver on the tree I posted and the one latest rcn has? I'm at work and can't get to a suitable PC till at least this evening. Jun 27 08:23:49 Might let us know what else he has picked up or dropped between the two. Jun 27 08:24:08 jic23_: ok.. Jun 27 08:26:04 jic23_: experimental_beaglefun right? Jun 27 08:41:55 yup. Jun 27 08:45:21 last patch on the inv_mpu that rcn has is probably : https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/commit/drivers/iio/imu/inv_mpu6050?h=fixes-togreg&id=1ffcfaf19597ad26797aac3ab42d8ba6e548ef0a Jun 27 08:46:34 hmm. But that was in the tree I used for doing those patches. Silly question, are you sure you have them all applied in the right order? Jun 27 08:48:13 order? :-o Jun 27 08:48:15 jic23_: Jun 27 08:48:25 jic23_: there is an order? Jun 27 08:48:27 to apply? Jun 27 08:48:31 shit! Jun 27 08:49:02 They do build on top of each other - the 8 patches in that tree... Jun 27 08:51:25 jic23_: can you give the link to the order? Jun 27 08:52:07 https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/log/?h=experimental-beaglefun Jun 27 08:52:11 Just as listed. Jun 27 08:52:53 jic23_: but you said 8.. Jun 27 08:53:00 jic23_: which 8? Jun 27 09:10:00 jic23_: should I patch the bog me out commit? Jun 27 09:17:22 nerdboy: basically slightly annotated diagram -> https://github.com/Visaoni/beagle-sonic-anemometer/wiki/Architecture. also made a little update to the firmware readme Jun 27 09:18:00 as you predicted, writing things up exposed one or two things I hadn't considered Jun 27 09:28:00 readme/diagram looks better Jun 27 09:33:49 notice the bbmini readme now says 9250/grove/uart/ blah blah Jun 27 09:34:02 and beaglebone green Jun 27 09:36:56 so it does... Jun 27 09:37:03 different barometer though Jun 27 09:37:59 i think that's extra Jun 27 09:38:14 9250 has the 185 on it Jun 27 09:38:41 typo maybe? Jun 27 09:38:50 9-dof is 9150 Jun 27 09:39:12 I think the 10-dof is just the 9-dof + bmp180, right? Jun 27 09:39:23 anyway, they have a cape Jun 27 09:39:57 right, 9-dof plus bmp = 10-dof 9250 Jun 27 09:40:58 9150 is a teeny bit different than 9250 but similar enough Jun 27 09:43:11 looks like they might be using spi for the imu though Jun 27 09:43:22 at least going by the readme Jun 27 09:44:03 if it supports green/grove connectors that's i2c Jun 27 09:44:35 Does anybody here have a clear idea on how to build a kernel to a deb file?? I want to get over it asap!! :( Jun 27 09:44:37 they mention grove/i2c for things like compass, status display Jun 27 09:44:39 but spi for imu Jun 27 09:44:41 usually it's both on the driver, not always Jun 27 09:44:58 compas is on the imu Jun 27 09:45:24 and mavlink has a message with "compass bearing" Jun 27 09:45:49 have to look at it and see Jun 27 09:46:00 yeah, doesn't make a whole lot of sense. will go through the source I guess Jun 27 09:46:05 shouldn't take too long to figure that out... Jun 27 09:46:40 kiran4399: I dont think there is anything like kernel deb file . Jun 27 09:46:46 compass heading comes from the magnetometer which is part of the imu Jun 27 09:46:51 When we use apt to install newer kernel Jun 27 09:47:03 it just replaces the kernel image in /boot Jun 27 09:47:09 with the newer image Jun 27 09:47:25 and configures grub accordingly Jun 27 09:47:30 ZeekHuge: there are deb build scripts in rcn patch repos Jun 27 09:47:56 all that stuff is installed via debs Jun 27 09:48:20 kiran4399: oops ! sorry ! Jun 27 09:48:43 *the upstream rcn kernels Jun 27 09:48:56 nerdboy: so isnt that ^^ what the deb file does ? Jun 27 09:49:23 the deb is a package file Jun 27 09:49:33 like an rpm only less weird Jun 27 09:49:57 it has whatever you want in it, if you make it yourself Jun 27 09:50:49 past my bedtime... Jun 27 09:51:24 nerdboy: Wait! can you tell me how to build it.. Jun 27 09:51:37 nerdboy: I've tried fakeroot.. but it is not working.. Jun 27 09:52:13 just run the script Jun 27 09:52:22 build_deb.sh ?? Jun 27 09:52:27 nerdboy: so, anything else I really need to push to get done before deadline? guessing going off and reading src doesn't fit that desc Jun 27 09:52:54 blog-y status page? Jun 27 09:53:27 where you are and where you're going Jun 27 09:53:37 (planned anyway) Jun 27 09:53:57 alright Jun 27 09:54:18 project-wise Jun 27 09:55:12 * Visaoni wonders what else he'd be writing about Jun 27 09:55:55 tasks/milestones, evaluate stack xyz, etc Jun 27 09:58:32 alternatively kernel modules or bbio Jun 27 09:58:52 *for sensor data Jun 27 09:59:04 still need to figure out what's going on with that Jun 27 10:01:04 might need new hardware, guess we'll see Jun 27 10:01:22 that would be a pain Jun 27 10:02:01 i'm still running seeed-iot image, with apt-get upgrades and latest ti kernel Jun 27 10:02:33 suppose I could try the iot image too Jun 27 10:03:22 the 4gb image has the extra python/sensor stuff you need i think Jun 27 10:04:06 okay, sleep for me... Jun 27 10:33:17 Sorry Kiran4399, had a meeting. Jun 27 10:33:49 jic23_: sorry from my side.. no issues with the patches.. Jun 27 10:33:56 cool ;) Jun 27 10:34:02 jic23_: I'll go home and test the sensor.. Jun 27 15:13:55 alexhiam: Hi!! Jun 27 15:14:11 hey kiran4399 Jun 27 15:14:13 how goes it? Jun 27 15:14:14 alexhiam: I've been waiting for you since 3 days!! :( Jun 27 15:14:34 oh no! I was away this past weekend Jun 27 15:14:36 what's up? Jun 27 15:14:42 the gist script which you sent me.. Jun 27 15:14:51 which? Jun 27 15:14:51 the fakeroot stuff is not working.. Jun 27 15:15:18 ohh, I saw that in the irc logs Jun 27 15:15:24 yea Jun 27 15:15:25 what os are you running? Jun 27 15:15:34 ubuntu 14.04 Jun 27 15:15:37 you mean host? Jun 27 15:15:40 yeah Jun 27 15:15:47 or beaglebone? Jun 27 15:17:10 what's the error you're getting? Jun 27 15:19:56 ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. Jun 27 15:20:26 hmm, looks like it could be a 32-/64-bit issue Jun 27 15:20:39 I assume you've spent some time googling that error? Jun 27 15:26:12 alexhiam: yeah.. spent about 1 day.. Jun 27 15:30:37 wait, 14.04? are packages still even supported? (how long is their lts again?) Jun 27 15:34:20 kiran4399: this was on 12.04: https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1001129 Jun 27 15:34:40 seems like that's might be the same issue Jun 27 15:35:15 one small silly question.. is beaglebone 32bit? Jun 27 15:35:22 yeah Jun 27 15:35:29 you could 'apt-get remove fakeroot' then build the latest from source Jun 27 15:36:00 http://freecode.com/projects/fakeroot Jun 27 15:36:53 err, this one: https://alioth.debian.org/scm/?group_id=30001 Jun 27 16:20:00 jic23_: there? Jun 27 16:46:35 Just a few hours left for the mid-evaluation to end !!! Jun 27 17:00:52 alexhiam: there? Jun 27 17:00:58 yeah Jun 27 17:00:59 alexhiam: I think I got the issue.. Jun 27 17:01:07 * nerdboy is confused where the fakeroot thing came from Jun 27 17:01:14 when I echo $LD_PRELOAD Jun 27 17:01:17 nothing is coming Jun 27 17:01:27 looks like LD_PRELOAD has'nt been set.. Jun 27 17:01:34 where do you want me to point it? Jun 27 17:02:08 the fakeroot came from some linux cross-compiling tutorial I saw somewhere once... really might not be necessary Jun 27 17:02:32 "object 'libfakeroot-sysv.so' from LD_PRELOAD" Jun 27 17:02:39 it has been set in the makefile Jun 27 17:02:39 nm, it's in the deb script but not the regular build script Jun 27 17:02:50 yeah Jun 27 17:03:02 and not in the sgx package script either Jun 27 17:03:25 * alexhiam is certainly not the embedded linux expert here Jun 27 17:03:59 not sure you need that Jun 27 17:04:44 kiran4399: have you tried without fakeroot? Jun 27 17:04:54 yeah.. Jun 27 17:05:10 try taking it out and just run with sudo? Jun 27 17:05:22 but I don't know what to do with the uImage file and the dtb.. Jun 27 17:05:26 alexhiam: I'm stuck.. Jun 27 17:05:38 I mean build a deb without fakeroot Jun 27 17:05:41 * nerdboy assumes it's there to get root ownership of packaged files Jun 27 17:06:15 kiran4399: i.e. just replace fakeroot with sudo in those two lines Jun 27 17:06:26 the wiki tells you haw to install manually Jun 27 17:06:47 from there you can apt-get another kernel or not... Jun 27 17:07:02 debs are much easier though, and you don't have to take your sd card out Jun 27 17:07:27 run the normal build script and manually install the stuff from deploy dir Jun 27 17:08:05 it's not much harder than a deb, plus you learn a little bit more... Jun 27 17:08:38 meh, learning is overrated Jun 27 17:08:39 alexhiam: if I do sudo.. then I get the uImage and dtb.. then? Jun 27 17:08:55 stupid deb script worked for me last time, but i hardly ever use it Jun 27 17:08:57 rcn build script is so complicated.. Jun 27 17:09:11 no.. if you do sudo with deb-pkg you still get a deb Jun 27 17:09:25 this isn't an rcn build script, this is the linux makefile Jun 27 17:09:31 alexhiam: yeah, confusion/blockage is sooo much better.,.. Jun 27 17:09:40 oh, you mean from bb_kernel? Jun 27 17:09:54 that is a bit complicated Jun 27 17:09:59 it's not that complicated... Jun 27 17:10:02 nerdboy: exactly! Jun 27 17:10:14 or verbose Jun 27 17:10:25 use ti-linux-kernel-dev no bb-kernel Jun 27 17:10:32 *not even Jun 27 17:10:50 nerdboy: where's that wiki page? Jun 27 17:10:57 build_deb.sh makes a package, using fakeroot Jun 27 17:10:58 * alexhiam always just builds debs Jun 27 17:11:17 build_kernel.sh makes a deploy dir with a bunch of stuff Jun 27 17:11:58 the both do git checkout (local) into KERNEL dir and let you make menuconfig Jun 27 17:12:20 alexhiam: oh.. is it? Jun 27 17:12:26 alexhiam: will try.. Jun 27 17:12:32 rcn defconfig is good, but i usually tweak it a little Jun 27 17:12:57 alexhiam: nerdboy: I think there must be lot of proper documentation for rcn scripts.. Jun 27 17:13:20 alexhiam: btw.. when shall we start the pru stuff?? or do you want me to do the i2c, spi, uart stuff first? Jun 27 17:13:28 one you have KERNEL dir then you run tools/rebuild.sh to update Jun 27 17:13:53 kiran4399: what's left on the APIs besides the PRU stuff? Jun 27 17:14:01 https://eewiki.net/display/linuxonarm/BeagleBone+Black Jun 27 17:14:10 nerdboy: but whenever I do that.. it always goes the trovalds repo.. it was so irritating.. Jun 27 17:14:21 read the "which kerenl" parts Jun 27 17:14:30 alexhiam: i2c, spi, uart, dsm, eqep Jun 27 17:14:41 just keep local clone and edit system.sh Jun 27 17:15:10 that file should point to your copy of linux-stable Jun 27 17:15:18 and your toolchain Jun 27 17:15:26 in this case we want to use the rcn tree and defconfig, because this is all getting upstreamed there for his build system for all the images Jun 27 17:15:33 nerdboy: by setting up the LINUX_GIT variable? Jun 27 17:15:34 copy the sample and edit it first Jun 27 17:15:45 nerdboy: in that case it alwasy gets the master branch.. :( Jun 27 17:15:54 will share a defconfig with all the other boards Jun 27 17:16:02 no it gets the branch you checkout from rcn patch dir Jun 27 17:16:12 kiran4399: you change your branch on bb_kernel first Jun 27 17:16:19 linux-stable should be on master Jun 27 17:16:20 but you should be ignoring that repo Jun 27 17:16:20 alexhiam: where? Jun 27 17:16:28 in system.sh? Jun 27 17:16:29 script does a clone from there Jun 27 17:16:33 kiran4399: no, with git Jun 27 17:17:01 what branch it checks out in KERNEL is different on the different branches of bb_kernel Jun 27 17:17:13 you checkout the branch you want *inside ti-linux-kernel-dev* Jun 27 17:17:50 wiki page is pretty clear Jun 27 17:18:05 just follow it and ask questions Jun 27 17:18:27 kiran4399: are you still talking about bb_kernel, or am I just making things more confusing? Jun 27 17:18:54 alexhiam: yeah.. looks clean to me.. Jun 27 17:19:01 nerdboy: alright.. Jun 27 17:19:06 cd ti-linux-kernel-dev/ && git checkout origin/ti-linux-4.4.y -b tmp Jun 27 17:19:55 the kernel branch it will checkout matches that, then it applies all those lovely rcn patches Jun 27 17:19:55 alexhiam: so what shall we do next?? Jun 27 17:20:16 except we want to use beagleboard/linux with the ti backports, not the ti tree itself Jun 27 17:20:20 READ THE WIKI PAGE Jun 27 17:20:25 see TI BSP Jun 27 17:20:32 not bb-kernel Jun 27 17:20:40 no, bot bb-kernel Jun 27 17:20:43 https://github.com/beagleboard/linux Jun 27 17:20:51 bb-kernel has NO RPROC drivers Jun 27 17:21:10 er, rpmsg Jun 27 17:21:46 I think rcn already grabbed those rpmsg mailbox->intc updates from ti Jun 27 17:22:10 latest on the rcn tree is 4.4.12-ti-rt-r32 Jun 27 17:22:21 using "TI BSP" as it's called on the wiki page will match the ti and ti-rt kernels packaged by rcn Jun 27 17:22:23 those changes were r31&r32, right? Jun 27 17:22:47 that is not bb-kernel Jun 27 17:23:03 that is ti-linux-kernel-dev which is correct Jun 27 17:23:20 bb-kernel is missing ti stuff Jun 27 17:23:23 nerdboy: but we're upstreaming to https://github.com/beagleboard/linux Jun 27 17:23:32 no rpmsg at all Jun 27 17:23:37 where rcn has been backporting from the ti tree on the 4.4 branch Jun 27 17:24:16 follow the wiki, use BSP kernel Jun 27 17:24:41 afaik beagleboard-linux is behind ti-kernel-dev a little Jun 27 17:25:49 alexhiam: no.. I am talking about the project? Jun 27 17:25:56 alexhiam: what should we do next? Jun 27 17:26:39 use the stuff that matches the linux-ti/ti-rt apt-get packages Jun 27 17:27:02 meaning ti-linux-kernel-dev Jun 27 17:27:49 specific questions about patches and where they are or where they go we'll need to ask robert Jun 27 17:28:29 if you need something not in the ti BSP kernel robert can help Jun 27 17:28:34 interesting.. I guess I'm a bit out of the loop here. I thought all the rcn kernel debs where built from beagleboard/linux? Jun 27 17:28:54 kiran4399: what do you mean by i2c, spi and uart? Jun 27 17:28:59 there are several kernel builds Jun 27 17:29:23 armv7, bone-X, ti-X, ti-rt-X Jun 27 17:29:48 the patch sets are different, config is different Jun 27 17:29:57 alexhiam: I mean.. oh.. you mean to say those kernel drivers are alread there right?? Jun 27 17:31:20 nerdboy: right, and the latest look to all be ti-rt-X. rcn has been applying those patches to beagleboard/linux and matching the tags. I assumed all the bb.org builds were coming from there Jun 27 17:31:26 both mailboxes and interrupts are in ti-linux-kernel-dev Jun 27 17:31:41 kiran4399: well, yeah, you just used the i2c driver with the sensors Jun 27 17:32:13 alexhiam: ok.. so we've got about 2 weeks for pru stuff.. Jun 27 17:32:23 after which I need to link the ardupilot.. Jun 27 17:32:38 kiran4399: how much have you tested what you've done so far? Jun 27 17:32:46 i'm not sure exactly how the bb kernel repo relates to rcn patch repo Jun 27 17:32:57 except the pwm.. all are tested.. Jun 27 17:33:03 alexhiam^ Jun 27 17:33:28 need to get him or jason to explain the workflow Jun 27 17:33:50 kiran4399: what have you tested them with? the stuff in examples/? Jun 27 17:34:13 no.. the hardware.. by writing the apis in the main() function which I created.. Jun 27 17:34:43 i just know stuff from the wiki and building/packaging kernels Jun 27 17:35:12 and spelunking through a lot of repos and patches and stuff... Jun 27 17:37:10 so rcn/ti-linux-kernel-dev is a mirror of the ti tree Jun 27 17:37:43 ohh.. with the bb_kernel scripts? Jun 27 17:37:58 not bb-kernel! Jun 27 17:38:20 the rcn bb-kernel repo i mean Jun 27 17:38:22 I mean rcn's build scritps that are also in the bb-kernel repo Jun 27 17:38:33 they all have build scripts Jun 27 17:38:33 build_kernel.sh, etc. Jun 27 17:38:58 beagleboard/linux is just the kernel tree Jun 27 17:39:04 no extra scripts Jun 27 17:39:07 ti-linux-kernel-dev and armv5-devel and bb-kernel Jun 27 17:39:12 they all work the same way Jun 27 17:39:35 the scripts are patch repos not kernel repos Jun 27 17:39:55 they just clone a kernel repo Jun 27 17:40:17 *they're in patche repos even Jun 27 17:41:09 beagleboard-linux otoh *is* a kernel repo Jun 27 17:41:59 the wiki page only makes you build u-boot and clone rcn patch repo Jun 27 17:42:17 there's no "step" to clone a kernel Jun 27 17:43:23 i think the scripts you're talking about are in the patch repos, both top-level and tools/ dir Jun 27 17:44:48 maybe i'm still confused... Jun 27 17:45:17 no, I think I've been the confused one... Jun 27 17:45:33 I've just been using the kernel repo Jun 27 17:46:02 you can see the corresponding "diffs" for each debian/ubuntu release on rcn web server Jun 27 17:46:37 they match the patches in the ones we're talking about Jun 27 17:47:13 xxx-bone3 diff matches bb-kernel from the wiki page Jun 27 17:47:49 xxx-ti/ti-rt diffs match TI BSP (ti-linux-kernel-dev) from the wiki page Jun 27 17:48:20 the diffs are for the deb packages Jun 27 17:50:00 http://rcn-ee.net/deb/xenial-armhf/ Jun 27 17:50:29 http://rcn-ee.net/deb/jessie-armhf/ Jun 27 17:50:33 and so on Jun 27 17:51:26 look in there and you'll find http://rcn-ee.net/deb/jessie-armhf/v4.4.12-ti-r32/patch-4.4.12-ti-r32.diff.gz Jun 27 17:52:08 applies on top of linux-stable Jun 27 18:32:20 hey bradfa, there? Jun 27 18:32:28 hi chanakya_vc Jun 27 18:32:57 bradfa, sorry for not responding during the weekend. Had gone on a vacation Jun 27 18:33:26 bradfa, I am working on the issue right now. But I am unable to find the mistake. Jun 27 18:33:38 Which is causing the error. Jun 27 18:34:18 bradfa, I will work on it tonight and get it up by tomorrow morning. Jun 27 19:10:03 chanakya_vc: which issue? Jun 27 19:11:41 bradfa, The pull request you had pulled. The driver not compiling Jun 27 19:12:05 chanakya_vc: ok. how were you compiling it before to test it? Jun 27 19:14:06 I had not checked it before you sent that pulled request.In the makefile that you are using, I don't get where are we saying that the driver should be cross compiled? Jun 27 19:14:09 bradfa, ^^ Jun 27 19:14:20 *pull request Jun 27 19:14:44 Just received the mail with midterm results. And I cant tell how glad I am after reading the "Feedback for you " part of the mail. Jun 27 19:14:46 chanakya_vc: if you pass CROSS_COMPILE= to make, it'll cross compile with the proper compiler, just like how you do it inside the kernel tree Jun 27 19:15:08 Thank you ds2 Wormo (wish m_w and Abhishek_ were here ) Jun 27 19:15:44 chanakya_vc: the kernel's build infrastructure takes care of this for you Jun 27 19:25:34 Okay bradfa something like : make CROSS_COMPILE=~/projects/buildroot/output/host/usr/bin/arm-linux- Jun 27 19:25:35 ? Jun 27 19:26:08 When you say build infra you mean Kbuild right? Jun 27 19:26:32 chanakya_vc: this might help https://zeekhuge.github.io/post/a_handfull_of_commands_and_scripts_to_get_started_with_beagleboneblack/ Jun 27 19:27:08 chanakya_vc: that'll build the kernel Jun 27 19:30:06 ZeekHuge, I am impressed by your posts Jun 27 19:30:45 Very impressive presentation Jun 27 19:31:35 ds2, You are talking about Kbuild right? Jun 27 19:31:59 ZeekHuge, I don't see my commands anywhere though :( Jun 27 19:33:17 bradfa, Thanks for feedback on the my project. I will definitely try to compile all my code and test/check it before I push it. Thanks a ton!!! Jun 27 19:33:58 chanakya_vc: not sure what you are trying to do, I thought its about cross-compiling so directed you to the post. Jun 27 19:34:20 chanakya_vc: I suppose Jun 27 19:34:31 Yes ZeekHuge , I have written a driver and I want to cross compile it. Jun 27 19:34:37 for our stuff, typically you wnat - Jun 27 19:34:44 ds2, Okay :) Jun 27 19:34:50 make ARCH=arm CROSS_COMPILE=prefix_to_compiler Jun 27 19:35:07 where prefix is either a full path or something like arm-eabi-none- Jun 27 19:35:21 the Makefiles will call teh compiler as $(CROSS_COMPILER)gcc Jun 27 19:36:07 Okay got it. So the makefile simply call the compiler from the path that I give right? ds2 Jun 27 19:36:10 also, you should place the module in the kernel source and then compile it. Jun 27 19:36:26 ZeekHuge: for now chanakya_vc is building an out-of-tree module Jun 27 19:36:32 ZeekHuge, Yes Jun 27 19:36:41 Otherwise it might throw version error Jun 27 19:37:35 ahh okay, but It wasnt loading in my case and was throwing version number errors. Jun 27 19:38:05 Got it bradfa . I am working on it. I will get this done before tomorrow evening(my time). Jun 27 19:38:14 ZeekHuge: you should always build out-of-tree modules against the source for the kernel you want to run the module on, but often if you have sources which are close enough you can force modprobe to load the module anyways and it'll work Jun 27 19:38:39 And thanks for the feedback once again bradfa Jun 27 19:39:10 okay. this makefile ? https://github.com/ZeekHuge/BeagleScope/blob/master/examples/kernel_examples/n-blinky/module/Makefile Jun 27 19:39:32 just build a monolithic kernel Jun 27 19:39:42 no reason to be distracted by module issues Jun 27 19:39:53 chanakya_vc: yep Jun 27 19:52:46 Thanks ds2 Jun 27 20:13:57 * nerdboy fires up the green Jun 27 20:31:28 Any idea how I can include the resource_table structure in asm code ? Jun 27 20:31:36 ds2: alexhiam ^ Jun 27 20:33:21 or anyone ? Jun 27 20:37:20 i think you want to inline your asm code to do that Jun 27 20:37:26 but don't quote me on it Jun 27 20:37:51 * nerdboy sings the Where's wormo song again Jun 27 20:38:21 ZeekHuge: check the pru compiler docs? Jun 27 20:38:53 yeah .. I wasnt able to find something there. Jun 27 20:39:06 examples? Jun 27 20:39:06 PASM docs had info about the struc Jun 27 20:39:24 nope, no examples that I know or could find. Jun 27 20:39:32 am33x reference project code? Jun 27 20:39:49 the PID controller one maybe? Jun 27 20:41:03 that code is based on PASM isnt it ? Jun 27 20:41:35 no idea, haven't looked Jun 27 20:41:54 * nerdboy was just browsing more vendor last night Jun 27 20:42:07 yep. Thats based on PASM and can be only loaded by prudrv Jun 27 20:42:14 found the reference design project-y stuff Jun 27 20:42:25 https://groups.google.com/forum/#!topic/beagleboard/cYHCN3GWw_E Jun 27 20:42:30 okay, nm Jun 27 20:43:08 lurk for wormo, ask ds2 or m_w maybe? Jun 27 20:45:05 * nerdboy doesn't do asm really Jun 27 20:45:46 found a way out of it :) Jun 27 20:45:55 its not needed now. Jun 27 20:46:16 phew Jun 27 20:46:30 what are you trying to accomplish? Jun 27 20:46:39 ask me about gnat maybe Jun 27 20:47:43 * nerdboy thinking of Ada stuff for fun student stuff Jun 27 20:51:19 m_w: okay so At first I thought we could use inline asm. But then was reading compiler docs and found that the C code uses RX registers for stack and various other purposes. While we want to keep data in it for our purpose. SO i was trying to make only-asm code. but then, for code to be uploaded by remoteproc, it needs resource table structure. And therefore the question. Jun 27 20:52:29 so now I have just defined the resource table in C and then declared main function as extern and defined it in asm file linked to the main C file Jun 27 20:52:55 okay Jun 27 20:53:00 ds2: is it ^^ in the right direction ? Jun 27 21:00:07 sounds good, as long as it links correctly Jun 27 21:00:24 does it make a firmware blob? Jun 27 21:05:05 https://github.com/dinuxbg/pru-gcc-examples/blob/master/blinking-led/pru/main1.S Jun 27 21:05:16 see resource table at the bottom Jun 27 21:06:14 ZeekHuge^^ Jun 27 21:49:16 heh, mr idiot <= just saw that the other day Jun 27 21:49:50 dummy data required for loader... Jun 27 22:03:26 m_w: I think the fact that he is using a Gcc compiler (unofficial though ) is what allows him to do that . Jun 27 22:04:56 you are using clpru right? Jun 27 22:54:09 wow, i thought the mavlink message protocol and header-based library was a decent abstraction Jun 27 22:54:29 looks like they did the same thing in ardupilot Jun 27 22:55:23 nice abstraction for PRU firmware / rangefinder stuff Jun 27 22:55:41 *only on bbmini "board" Jun 27 22:56:13 https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_RangeFinder/AP_RangeFinder_BBB_PRU.cpp Jun 27 22:56:45 cpp code loads its own firmware blobs Jun 28 00:21:59 Visaoni: meaning here instead... Jun 28 00:22:37 i did start it though, so Jun 28 00:22:44 * nerdboy slaps himself Jun 28 00:25:59 alright so if I'm understanding you correctly Jun 28 00:26:20 you want to use the ardupilot/bbbmini stuff for a couple different purposes Jun 28 00:27:06 1) follow their example loading firmware stuff from a userspace program (replace the little deploy scripts) Jun 28 00:27:58 2) use their i2c/uart/etc libs to grab data from temp/pressure/mag/humidity sensors Jun 28 00:28:17 2b) present that data on a mavlink interface Jun 28 00:28:35 fin Jun 28 00:46:25 pretty much, the firmware load is optional Jun 28 00:46:41 but it hasn't been bulletproof for me so far Jun 28 00:46:46 *the deploy dance Jun 28 00:47:20 if i don't load blinky first, the other one doesnt load Jun 28 00:47:37 if i do load blinky, the other works fine Jun 28 00:48:39 but the ardupilot stuff has to load on start, it could take care of loading pru blobs also Jun 28 00:49:39 if the blobs are named right and sitting in /lib/firmware they should load anyway if the pm firmware is there Jun 28 00:50:24 would not be a bad idea to have an explicit load in the sensor control side Jun 28 00:51:22 the autoloading has not been reliable either, but i think that's old *-fw firmware barfing on the new kernel stuff Jun 28 00:51:43 *the mailbox vs interrupt change Jun 28 01:14:16 their adc interface for two different part numbers is equally abstracted Jun 28 01:14:35 *ardupilot Jun 28 01:15:07 the comments say "for ardupilot mega" but i'm not sure that means anything Jun 28 01:15:51 i did notice the bbmini loads its own dtb file for the cape and then enables the ADC overlay Jun 28 01:18:39 i'm thinking we're gonna want to make one of these too: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts Jun 28 01:19:20 maybe BB-VISADC-00A0.dts Jun 28 01:19:44 for the ths1206? Jun 28 01:19:50 yup Jun 28 01:19:55 pretty simple Jun 28 01:20:05 mainly it defines the pins Jun 28 01:20:31 pins/registers Jun 28 01:21:15 at some point hopefully it will be a cape with the part instead of evm Jun 28 01:21:50 but the overlay gets you exclusive use of the pins/modes i guess Jun 28 01:21:50 that would be pretty cool Jun 28 01:22:05 sets everything to the right defaults Jun 28 01:23:22 the overlay shouldn't care if it's a cape, just the evm interface might a little different than the cape Jun 28 01:23:39 not a concern for a while yet... Jun 28 01:23:56 the evm kinda sucks in some ways Jun 28 01:24:22 i though they usually brought out all the options/bells/whistles and stuff Jun 28 01:24:28 *thought even Jun 28 01:24:42 I think it does, actually Jun 28 01:25:00 lack of docs for the evm sort of obscure it Jun 28 01:25:26 i think the necessary stuff is known right? Jun 28 01:25:32 yeah Jun 28 01:26:33 they tried ot be cute with some things but didn't say much about it Jun 28 01:27:10 as Wormo suggested, looking at the schematics made it a bit more clear what was going on Jun 28 01:27:19 working prototype is all we need for this Jun 28 01:28:02 Visaoni: can you make a short doc for that gap? Jun 28 01:29:05 a another doc file, evm.md or something Jun 28 01:29:27 evm_missing.md even Jun 28 01:30:18 I guess. I haven't really looked into all the junk they did, just looked at it enough to ensure you can use the thing like a normal chip still Jun 28 01:30:40 yes, that part Jun 28 01:30:57 there's a few other things they've done I'm still not sure about, like the magical bus that is 0-11 on one end and 0-15 on the other Jun 28 01:31:27 "good bus, magic bus" Jun 28 01:32:06 and one signal I'm not sure if we need or not... but I think we can just tie it high or low if needed Jun 28 01:32:20 although I'm not sure if we do need to, or if it should be tied high or low... Jun 28 01:32:47 try it and see... Jun 28 01:33:17 somebody at TI must be a Who fan Jun 28 01:33:35 yeah, will figure it out. just kind of a pain Jun 28 01:35:19 which is a good reason to evaluate writing code using the kernel drivers or bbio is more/less work than making a custom ardupilot build Jun 28 01:35:44 not sure bbio is best interface latency-wise Jun 28 01:36:33 although some sensors are a little "latent" on their own... Jun 28 01:36:39 I don't think it matters over much. sudden shifts in conditions aren't really expected Jun 28 01:36:47 and the DHT22 needs like 2secs between reads anyway Jun 28 01:36:58 but the timing does need to be close Jun 28 01:37:18 timestamps on wind measurements vs the ptu data Jun 28 01:37:56 and the fist one involves time/space averaging Jun 28 01:38:13 yeah, but surely less sensitive than an autopilot Jun 28 01:38:34 latency sensitive, than is Jun 28 01:38:35 *first one even Jun 28 01:40:30 to get the best accuracy for a couple of them we would need to feed independent temp to humidity and feed elevation to pressure sensor Jun 28 01:41:14 defaults make it calculate elevation instead Jun 28 01:41:32 so defaults might be a bit sloppy Jun 28 01:42:33 first try with just default settings and reads from each sensor, then try to get an error estimate Jun 28 01:45:40 yay, got my router antennas Jun 28 01:46:51 and you have a lovely status report for tomorrow too... Jun 28 01:47:14 status/plans even Jun 28 01:47:52 just grab the blob one and bring it a little more up to date you mean? Jun 28 01:48:02 or you know, blog Jun 28 01:48:39 new page even? Jun 28 01:55:28 the *other* docs take work... Jun 28 01:56:02 yeah I guess I can throw up another page and keep a few notes of what I'm working on there **** ENDING LOGGING AT Tue Jun 28 02:59:58 2016