**** BEGIN LOGGING AT Fri Feb 02 03:00:05 2018 Feb 02 03:31:35 hello all, when beagle bone is using a cape, some initialization needs to be done, like https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/1dfcf302a5f76e68dc005673d411002181b73ce9/libraries/roboticscape.c#L42 Feb 02 03:31:43 what is this initialization? Feb 02 03:51:29 capes in general don't require initialization, this is just specifically initialization for the robotics cape library Feb 02 03:51:38 oh, he left Feb 02 12:27:33 hi Feb 02 13:51:00 hello all, I have a bb blue and i wanted to know how i can "initialise" the cape...? like what is the procedure and what happens actually?? Feb 02 13:51:09 something like this : https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/1dfcf302a5f76e68dc005673d411002181b73ce9/libraries/roboticscape.c#L43 Feb 02 13:53:25 The device tree to enable all the peripherals is already there by default. Feb 02 13:54:37 so i don't have to perform any initilization myself? Feb 02 13:54:44 jkridner[m]: as we've had a similar topic yesterday, does that include that IMU sensor or whatsitcalled? Feb 02 13:55:08 https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am335x-boneblue.dts Feb 02 13:55:30 The IMU is probably without a driver loaded by default. Feb 02 13:55:44 The libroboticscape does userspace foo. Feb 02 14:11:21 hello all, i was planning on using the python package for i2cdev, my main aim was to be able to get the state of th ei2c bus Feb 02 14:11:29 as i have two sensors on the same bus Feb 02 14:11:46 how can i ensure that bus is not busy when using one of the sensors? Feb 02 14:11:55 and the application is time critical Feb 02 14:14:23 does anyone have any idea Feb 02 14:16:10 Is the Beagle the only I2C master in the system? If so, it will only be busy when the Beagle issues accesses. Feb 02 14:16:52 If all your sensors are using i2cdev, that would only be when your userspace code is making an I2C access. Feb 02 14:17:28 is it the same with using smbus to communicate via i2c Feb 02 14:17:51 Cape_mgr_help: no board setup should be required on Blue to use the libroboticscape functions. Feb 02 14:18:07 Run rc_test_imu Feb 02 14:22:27 im assuming smbus and i2cdev have similar operations Feb 02 14:22:31 also, Feb 02 14:23:19 i don't know why the libroboticscape does checks to see if the bus is busy..? Feb 02 14:25:41 Ugh Feb 02 16:42:07 I don't seem to be able to install the Windows (64 - 10) drivers for my BeagleBoard. Any suggestions? Feb 02 16:49:30 Debian 9.2 2017-10-10 4GB SD IoT. Is there non free software in the image? My usb wifi card requires non free software to work and it does not work. Feb 02 16:50:32 Debian 9.1 2017-08-31 4GB SD LXQT , not Debian 9.2 2017-10-10 4GB SD IoT. Feb 02 19:04:16 hello all, is the smbus an effective way to use I2C on beagle bone? Feb 02 19:04:27 im trying to write an autopilot for a project Feb 02 19:04:35 and im writing the sensor drivers using smbus Feb 02 19:21:28 new images on https://beagleboard.org/latest-images/. Get 'em while there hot. Feb 02 20:36:16 hi all Feb 02 20:36:43 on behalf of all, hi. Feb 02 20:36:51 i want to use yocto with my beaglebone green wireless Feb 02 20:37:10 do you now which layers are necessary to build an working image? Feb 02 20:37:43 I don't really know anything about yocto, but normally it would be identical to the beaglebone black Feb 02 20:38:15 the only difference is in the device tree used, and that's typically selected by u-boot based on the board identification EEPROM, so the same image should be able to work on either Feb 02 20:39:18 i build an image with yocto. there seems to be a template to build one for beaglebone Feb 02 20:39:53 but it doesnt work Feb 02 20:40:02 :) Feb 02 20:40:07 i will try again Feb 02 20:40:27 but you think u-boot will look for the right dtb file? Feb 02 20:41:05 even if it were to use the dtb for the beaglebone black (e.g. if the u-boot is too old to be able to recognize the bbgw), it would still boot Feb 02 20:41:21 ok thx Feb 02 20:41:53 on the other hand, if u-boot recognizes the bbgw but your system has no dtb for it, then it won't boot Feb 02 20:45:03 well i can search the dtb in the build image Feb 02 20:45:08 i will look for it Feb 02 20:45:26 just monitor the serial console to see what's going on Feb 02 20:46:22 brb Feb 02 20:58:31 zmatt, the sd card is not booting. bbgw still boots from internal emmc Feb 02 20:59:55 sd card got two partitions: 1. partition = MLO + u-boot.img Feb 02 21:00:10 2. partition (root) all the folders Feb 02 21:02:47 have you tried bypassing the bootloader on eMMC (by powering on while holding down the S2 button, or just by wiping eMMC) Feb 02 21:03:11 the u-boot on eMMC may expect different things from the system than yocto does Feb 02 21:03:48 (by default u-boot on eMMC takes priority over u-boot on SD) Feb 02 21:28:43 ok, when it wants to to load kernel it stops, also it says it need /boot/am335x-beaglebonegreen-wireless.dtb Feb 02 21:28:58 when i copy this file to boot-folder it doesnt change anything.... Feb 02 21:29:31 this is with eMMC bootloader bypassed? Feb 02 21:30:31 can you share the actual console output via pastebin or such? Feb 02 21:30:53 well, i think yes. it says : U-Boot SPL 2018.01 (Jan 30 2018 - 21:51:37) Feb 02 21:31:01 this is the date i build the image Feb 02 21:31:20 ok Feb 02 21:31:35 may i can post the serial output somewhere Feb 02 21:31:47 that's what I just suggested Feb 02 21:32:41 https://pastebin.com/8jqU7gu3 Feb 02 21:33:11 it says: starting kernel..... and then reboots Feb 02 21:34:16 yeah that's no surprise with no dtb Feb 02 21:34:56 i copied the orginial dtb file from an original beaglebone debian image to the yocto boot folder, where the other dtb files are stored Feb 02 21:35:06 no difference Feb 02 21:35:11 the "5770288 bytes read" is your kernel presumably Feb 02 21:35:39 not using initramfs I guess Feb 02 21:36:09 so yeah it's clearly not loading any dtb... yet proceeds to try to boot anyway (bad move to be honest) Feb 02 21:36:42 ah you included u-boot's env, good Feb 02 21:38:10 yes Feb 02 21:38:24 i am not an expert, i dont now that much about u-boot and kernel Feb 02 21:38:32 just want to boot my bbgw faster Feb 02 21:40:21 i want to use the core-image-minimal from yoco Feb 02 21:40:31 after that i want to install all packages i need Feb 02 21:42:07 yeah I have around 10 second boot time I think (from power on) Feb 02 21:42:44 wow, that would be nice Feb 02 21:42:50 do you have also a bbgw? Feb 02 21:43:01 bbb running debian Feb 02 21:43:06 hm Feb 02 21:43:17 bbgw seems rather misdesigned to me Feb 02 21:43:31 did you use any special recipes with yocto? Feb 02 21:44:06 instead of reusing the pins normally used for ethernet (like the bbb wireless does) they sacrificed a whole bunch of expansion header pins (while leaving the pins normally used for ethernet unused and not-connected) Feb 02 21:44:17 I've never used yocto, I mentioned that already Feb 02 21:44:29 sry Feb 02 21:44:57 I'm browsing u-boot boot script btw to see from where it's trying to load stuff Feb 02 21:45:09 ok Feb 02 21:45:31 where can i browser that? Feb 02 21:45:40 your pastebin Feb 02 21:51:14 it loads the dtb file from the same directory as where your kernel zImage is located Feb 02 21:52:10 wait Feb 02 21:52:21 I looked at the wrong function maybe Feb 02 21:52:34 there's "mmcboot" and "mmc_boot" .... nicely done guys Feb 02 21:55:45 no I looked at the right one Feb 02 22:07:31 ok thx matt Feb 02 22:07:35 i will check that out Feb 02 22:07:41 have to go offline now Feb 02 22:07:44 https://pastebin.com/Zm53kJte Feb 02 22:07:52 here's the relevant parts of the boot script cleaned up Feb 02 22:07:53 will reply tomorrow Feb 02 22:07:58 in roughly chronological order Feb 02 22:08:13 ok thx Feb 02 22:08:18 good night Feb 02 22:08:26 till tomorrow Feb 02 22:39:48 i created touchsceen module to read I2C data, on an gpio interrupt.. most all is working.. haveing hard time figureing this out.. then the module is running the prob/install function I2C is working great.. when the I2C is called in the ISR i am getting a kernel locking rt_mutex warning. and the i2c_transfer is returning what appears to be a EAGAIN. Feb 02 22:42:24 looking for any idea on why the i2c works fine during module init, but seems to be locked or busy from an isr in the module Feb 02 22:46:27 wait what? you're trying to do an i2c transfer from inside an interrupt handler? Feb 02 22:46:39 and you're surprised that you're having problems? Feb 02 22:47:20 this seems to be typical for touchscreen KVMs.. Feb 02 22:47:52 request a threaded interrupt Feb 02 22:47:56 touchscreen send irq on a gpio, isr goes and reads the I2C Feb 02 22:47:59 then you can do pretty much anything I think Feb 02 22:48:32 yeah no, you can't do an i2c read from an isr. you'd kick off a work queue item or something like that from your isr Feb 02 22:49:31 ok.. I think maybe that is where I am messing up.. looks like on thing I copied was doing a threaded isr with not worker.. and the other was doing non threaded isr with worker.. Feb 02 22:49:34 or like I said, maybe it suffices to task for a threaded isr, which basically just means the kernel inserts some glue to kick off a kernel thread when your interrupt hits in which your isr then runs Feb 02 22:49:57 i might have implemented a non-threaded isr without a worker.. let me fix and see what happens Feb 02 22:50:24 an i2c transfer is slow and itself involves completion interrupts Feb 02 22:50:49 so doing one from interrupt context would deadlock the kernel if it were to allow it Feb 02 22:57:30 yeah... that makes sense, i will fix Feb 02 23:11:19 that fixed it up.. thanks zmatt Feb 02 23:13:26 don't forget to grab a mutex over any state your "interrupt handler" shares with functions that can be called (directly or indirectly) from elsewhere, if any Feb 02 23:15:50 (technically this is also true for real interrupt handlers, but in that case it would be a spinlock and you can often get away with forgetting to use one, although that would then bite you in the ass on SMP processors and RT kernels) **** ENDING LOGGING AT Sat Feb 03 03:00:01 2018