**** BEGIN LOGGING AT Wed Oct 29 03:00:00 2014 Oct 29 03:01:55 haha. maybe. Oct 29 03:02:00 I think I found something. Oct 29 03:02:01 Thanks. Oct 29 06:58:11 help please... Oct 29 07:31:54 are there any ubuntu video drivers for bbb Oct 29 08:08:29 Guest21225: what are you trying to do with the HDMI output? Oct 29 12:16:33 Have device tree or not, does it matter with the driver development? Oct 29 12:17:01 anything need to pay extra attention? Oct 29 12:18:37 you need to provide DT bindings Oct 29 12:19:01 if your driver needs any kind of "platform" data Oct 29 12:19:12 if its a pure "class" driver then no Oct 29 12:19:22 do you have any example? Oct 29 12:19:32 /usr/src/linux Oct 29 12:20:27 but the comment is not enough. Oct 29 12:21:15 any simple example, like LED or buzzer? Oct 29 12:21:24 https://www.google.com/search?q=device+driver+dt+binding Oct 29 12:22:58 i will read the manual first ,https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt Oct 29 12:40:31 hi Oct 29 12:41:09 is it possible to compile the ti kernel with capemanger support? Oct 29 12:43:10 Laurenceb when you port it, why not Oct 29 12:43:57 i heard there was no capemanager for newer kernels Oct 29 12:46:09 look it up yourself and you will know for sure Oct 29 12:46:44 * Laurenceb brainmelt Oct 29 12:48:36 i know a certain guy who is beating the hell out of kernel maintainers to get teh dto code merged into mainline Oct 29 12:48:59 ive been planning to use the BBIO python libs Oct 29 12:49:06 but i also want usb host Oct 29 12:49:09 KotH panto was here yesterday Oct 29 12:49:30 which works with --ti-kernel Oct 29 12:49:38 as long as you leave the i2c2 configuration in the device tree. it will show up in your /sys/device/bone.cam... Oct 29 12:49:43 but latest stable kernel is 3.8.13 Oct 29 12:49:52 which doesnt support usb host properly Oct 29 12:50:13 sure, with ti kernel i cont have any cape stuff Oct 29 12:50:23 so BBIO wont run Oct 29 12:50:38 3.8.13 bone67 support the usb host well Oct 29 12:50:46 it doesnt Oct 29 12:50:47 i trid already Oct 29 12:50:52 i have it running here Oct 29 12:50:55 not hot swap Oct 29 12:50:59 i get "nuking devices" Oct 29 12:51:09 which is unrecoverable Oct 29 12:52:15 https://github.com/RobertCNelson/ti-linux-kernel Oct 29 12:52:19 that works very nicelyu Oct 29 12:53:55 apart from no capes? Oct 29 12:54:23 yeah nothing in drivers Oct 29 12:54:58 hmm wtf Oct 29 12:55:07 im sure ti intend you to be able to use adc etc Oct 29 12:55:21 i'm not sure whether ti wants anyone using ther cpus Oct 29 12:55:27 lolz Oct 29 12:55:31 i'm sure they want you to buy them, but use? Oct 29 12:55:57 ohhhhhh Oct 29 12:55:59 http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide Oct 29 12:56:10 looks like the kernel was built without adc support lolz Oct 29 12:56:25 there is no iio under /sys/bus Oct 29 12:59:34 grrr Oct 29 12:59:43 surely someone has built this already Oct 29 13:00:27 there are many kernels Oct 29 13:00:34 yeah heh Oct 29 13:00:34 +1 Oct 29 13:00:56 anyone seen a ti kernel with capemanager? Oct 29 13:01:04 hmmm Oct 29 13:01:17 maybe the 3.8.13 ti kernel has fixed adc Oct 29 13:01:43 "fixed adc" Oct 29 13:01:54 erm Oct 29 13:01:57 fixed usb host Oct 29 13:02:01 lol Oct 29 13:02:24 ive tried 3.12 and it was fixed in ti kernel Oct 29 13:03:12 so run that Oct 29 13:03:30 it doesnt support capemanager Oct 29 13:03:52 so build a dts with what you need and move on Oct 29 13:03:58 huh Oct 29 13:04:08 staticly Oct 29 13:04:14 i cant do anything with no capemanager? Oct 29 13:04:41 there is no iio under /sys/bus Oct 29 13:05:16 build your kernel with iio and the drivers you want...add the appropriate notes to the dts..compikle it boot kernel with the resultant dtb Oct 29 13:05:17 done Oct 29 13:05:29 ok... Oct 29 13:05:36 hmm Oct 29 13:05:46 sounds beyond my skill level Oct 29 13:05:48 it's how the rest of the world outside beagle-land works with the kernel Oct 29 13:05:58 hmm Oct 29 13:06:06 Laurenceb: no it's not..it just takes some investment of time..you can do it. Oct 29 13:06:08 ok ill try it O_o Oct 29 13:06:41 it would take longer to bang your head against all the things that don't work in older and scattered kernels Oct 29 13:06:56 yeah, thats what ive been doing for the past week and a half Oct 29 13:07:03 havent achieved anything Oct 29 13:07:12 you might consider using rcn's recent kernel builds as a starting point Oct 29 13:07:46 yeah im running his atm Oct 29 13:08:54 ok ill see if he has a guide Oct 29 13:09:43 https://github.com/RobertCNelson/stable-kernel Oct 29 13:09:45 guide there Oct 29 13:09:53 thanks Oct 29 13:11:26 but i already have stable kernel Oct 29 13:11:33 im going to have to get the ti kernel to run Oct 29 13:12:08 http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git Oct 29 13:12:47 Laurenceb: please stay away from "TI" kernels Oct 29 13:13:39 why? Oct 29 13:13:48 at least usb works Oct 29 13:13:52 because there is a BBB kernel, the one RCN provides Oct 29 13:14:00 its the one most BBB users run and can relate to Oct 29 13:14:13 yeah but you have to choose between usb host or capemanager? Oct 29 13:14:20 if you find something not working, bring it up on the mailing list Oct 29 13:14:31 its already there Oct 29 13:14:40 no cape manager on the newer kernels Oct 29 13:14:42 I dont think the Debian kernel has capemanager anyway Oct 29 13:14:47 wut Oct 29 13:14:52 ok maybe im wrong Oct 29 13:15:03 so ignore capamanager Oct 29 13:15:06 its not the only way Oct 29 13:15:08 but python BBIO only runs with 3.8.13 Oct 29 13:15:17 ah well Oct 29 13:15:36 cape-bone-iio-00A0.dts Oct 29 13:15:48 it needs to send that to slots Oct 29 13:15:59 then look in /sys/bus/iio Oct 29 13:16:02 yes Oct 29 13:16:06 it was written at that time Oct 29 13:16:09 but that time is over Oct 29 13:16:10 none of this is present on >3.8.13 Oct 29 13:16:16 exactly Oct 29 13:16:24 hmm Oct 29 13:16:27 so why base your work on something that is not supported forward Oct 29 13:16:30 so i can fix BBIO? Oct 29 13:16:39 BBIO looks pretty simple Oct 29 13:16:43 you can use old angstrom images with 3.8.13 Oct 29 13:16:49 and be done Oct 29 13:16:57 if you insist on BBIO "as is" Oct 29 13:17:01 i dont Oct 29 13:17:05 or work on it to make it work on newer kernels Oct 29 13:17:09 ok Oct 29 13:17:15 talk to alex hiam Oct 29 13:17:19 that sounds doable Oct 29 13:17:21 maybe he has ideas Oct 29 13:17:38 so how can i use the adc in newer kernels? Oct 29 13:17:46 so, how do you load dt fragments if there isn't a cape manager Oct 29 13:18:07 you dont Oct 29 13:18:17 you load one DT at boot that has what you need Oct 29 13:18:25 hmm Oct 29 13:18:27 overlays are "in the works" in mainline Oct 29 13:18:30 it might take a while Oct 29 13:18:36 how long? Oct 29 13:18:37 then something like capemgr might be back Oct 29 13:18:42 ok Oct 29 13:18:46 so you have to recompile your device tree every time you make a hardware change? Oct 29 13:18:49 this long: |<------------------------------>| Oct 29 13:18:51 i can wait, i have dev work to do Oct 29 13:19:01 so ill stay with 3.8.13 Oct 29 13:19:01 (not to scale) Oct 29 13:19:07 and wait for BBIO to be fixed Oct 29 13:19:17 i can develop the python code in the meantime Oct 29 13:22:38 Laurenceb: https://github.com/RobertCNelson/rscm Oct 29 13:23:13 that doesnt support everythingi need Oct 29 13:23:22 i need usart, i2c, spi, gpio, adc Oct 29 13:23:26 then add the DT stuff for your HW Oct 29 13:23:34 do you really change HW at runtime? Oct 29 13:23:43 if not, you are fine with a fixed tree Oct 29 13:23:44 no Oct 29 13:23:48 so Oct 29 13:26:30 ? Oct 29 13:28:42 i dont understand Oct 29 13:28:54 where will the adc appear? Oct 29 13:29:26 ? Oct 29 13:29:41 somewhere in /dev/ I guess Oct 29 13:30:11 hmf Oct 29 13:30:25 overlay or not does not change how a driver itself works Oct 29 13:30:27 but only after the DT thing is loaded? Oct 29 13:30:34 its just runtime vs boot time Oct 29 13:30:43 yes, but without any DT, you have nothing Oct 29 13:30:45 oh it has to reboot Oct 29 13:30:46 i see Oct 29 13:30:48 yes Oct 29 13:30:53 i didnt try that before Oct 29 13:30:57 as said, your HW does not change on the fly Oct 29 13:31:02 ok ill have another go at this later Oct 29 13:31:21 first i need to modify some more board to fix RTC, shutdown and battery amangement Oct 29 13:31:25 *boards Oct 29 13:31:51 i should document this lol Oct 29 13:32:02 could be useful for a new PCB revision Oct 29 13:32:29 added a cap across the top of U4 to force it to shutdown correctly Oct 29 13:32:45 again, mailing list Oct 29 13:32:52 for hw changes, ping Gerald Oct 29 13:32:59 ok, one thing at a time, soldering time atm :D Oct 29 13:33:11 check which end is the warm one Oct 29 13:35:07 Laurenceb: it appears here: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio Oct 29 13:36:47 more kernel docs tell you how to fill out your dts with examples: https://www.kernel.org/doc/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt Oct 29 13:36:47 thanks Oct 29 13:38:58 you can also look through the various cape fragments for what settings are none to work when building your dts. https://github.com/beagleboard/meta-beagleboard/tree/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus Oct 29 13:39:53 known Oct 29 14:22:38 Hey, i'm trying to write data via SPI using the PRU. CS high works, writing the data doesn't seem to do anything though. Here's the code http://hastebin.com/xumipojara.p Oct 29 14:25:09 the C version does basically the same: HWREG(0x481A0000 + MCSPI_TX(0)) = txData; MCSPI_TX(0) = 0x138 .. Oct 29 14:27:31 and that works? Oct 29 14:29:09 chip select works, yeah Oct 29 14:29:16 and the C version works too.. Oct 29 14:30:04 the C version is straight from TI's McSPI.. I'm using that as a reference Oct 29 14:34:56 do you have to trigger the transfer? Oct 29 14:34:59 somehow? Oct 29 14:35:24 with the C version no, not at all.. Oct 29 14:35:42 pastebin the C code Oct 29 14:36:50 http://hastebin.com/sajarevoto.cpp Oct 29 14:37:12 the wordlength doesnt matter right now since it doesnt change.. Oct 29 14:38:12 has that code anything to do with sarajevo? Oct 29 14:38:21 and why the DCT is it c++? Oct 29 14:38:41 hastebin does some weird things I guess.. Oct 29 14:41:10 LuaStoned: there is a while loop Oct 29 14:41:16 where is that in your code? Oct 29 14:42:26 it's commented out in my C function? I guess I could add it but it works without it.. Oct 29 14:47:20 ok, no while loop Oct 29 14:51:15 Has anyone been successful at enabling the I2C2 bus so the exposed IC2 pins can be used? Oct 29 14:52:15 yes Oct 29 14:53:37 Can you point me to some directions for getting it working on rev C? Oct 29 14:56:23 wohoo Oct 29 14:56:32 4GB revC mods work Oct 29 14:56:46 shutdown down to <100A Oct 29 15:03:16 av500 do you happen to know other people that work with the PRU? Oct 29 15:03:28 there are a few Oct 29 15:07:59 a few come here, bitch about things not working, and leave a couple of days later Oct 29 15:10:16 adugenske: does it work differently on a rev C? Oct 29 15:12:46 KotH I've been sticking around even with some things not working :P Oct 29 15:13:05 LuaStoned: you seem to code under influence ;) Oct 29 15:13:21 it would just be cool to talk to someone with "more" PRU knowledge, I'm pretty sure I could learn/optimize so much more.. Oct 29 15:13:43 Haha, that's one way to see that yeah Oct 29 15:31:22 LuaStoned: btw, why PRU for SPI? Oct 29 15:37:47 mdp I don't think so. Oct 29 15:41:59 adugenske: fwiw, I run rcn's stock 3.16.2-bone5 kernel debs on a Rev A5a..and by default i2c2 is pinmuxed so that capes will be detected. I use i2c-dev for my project. Oct 29 15:42:38 for that matter, I can use i2c0 (no surprise, needed for pmic) or i2c2. Oct 29 15:47:35 I'm running Debian and trying to communicate with an Adafruit device via the header pins. I've run i2cdetect, but only I2C-1 & I2C-0 are being displayed, and nothing for the device at 0x40. Oct 29 15:50:39 mdp Can you expand on using i2c-dev? Oct 29 15:51:51 adugenske: if you do a "dtc -I dtb -O dts -o ~/am335x-boneblack.dts /boot/dtbs/.../am335x-boneblack.dtb" to get your dts...does it show i2c2 properly? Oct 29 15:52:56 mdp Dumb question, should I enter all in quotes? Oct 29 15:53:18 drop the quotes Oct 29 15:53:53 mdp Received: FATAL ERROR: Couldn't open "/boot/dtbs/.../am335x-boneblack.dtb": No such file or directory Oct 29 15:54:16 av500 the PRU can output at a steady rate (10000x / sec), doing that on the host OS would eat CPU like nothing else and be interrupted by other tasks etc.. Oct 29 15:55:19 av500 I'm using the 2nd PRU to interrupt the first 10000times/sec and on each interrupt output data to SPI.. Oct 29 15:55:41 adugenske: replace the ... with whatever the path is to the kernel you are running Oct 29 15:55:54 adugenske: as the dtb that was used to boot is stored there. Oct 29 15:56:29 mdp Where would the kernal be located? Oct 29 15:56:46 do "uname -a" Oct 29 15:57:23 mdp: Result = Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux Oct 29 15:58:15 adugenske: "dtc -I dtb -O dts -o ~/am335x-boneblack.dts /boot/dtbs/3.8.13-bone47/am335x-boneblack.dtb" Oct 29 15:59:19 mdp: Getting fatal error again. Oct 29 15:59:28 mdp: does ~ need to be changed? Oct 29 16:00:08 just cd through /boot and see where your dtb is at Oct 29 16:01:09 find /boot -name am335x-boneblack.dtb Oct 29 16:01:37 mdp: found it here: /boot/uboot/dtbs/am335x-boneblack.dtb Oct 29 16:03:07 ahh, ok, that's the default spot..my updated kernel has it elsewhere. Oct 29 16:03:48 adugenske: "dtc -I dtb -O dts -o ~/am335x-boneblack.dts /boot/uboot/dtbs/am335x-boneblack.dtb" Oct 29 16:04:44 * mdp recalls that the 3.8 kernel/dts is broken is so many ways it may have some of these instances off or misnumbered Oct 29 16:05:37 mdp: Runs without error, but no output. Oct 29 16:06:01 good, the output is in ~/am335x-boneblack.dts Oct 29 16:06:18 pastebin that file if you can Oct 29 16:06:49 adugenske: that's the decompiled source of the device tree that you are booting with Oct 29 16:07:31 mdp: Just download it. Contains 37 lines. Oct 29 16:08:33 mdp My editor is showing quite a few �, but I guess that is ok Oct 29 16:09:17 that doesn't sound good Oct 29 16:09:32 are you sure you are looking at the dts and not the dtb? Oct 29 16:11:28 mdp You are right. I was looking at the dtb, I'm guessing the dts is in different location Oct 29 16:12:00 in your user's home directory...given the command above Oct 29 16:12:17 open ~/am335x-boneblack.dts in your editor Oct 29 16:13:52 mdp: but it's done Oct 29 16:14:03 mdp: the 3.8 kernel Oct 29 16:14:20 mdp: interesting, no *.dts files in /home/root. Could it be somewhere else? Oct 29 16:15:41 adugenske: you got me...it's only somewhere else if you ran that command as a different user ;) Oct 29 16:15:55 this is now squarely a Linux system administration issue ;) Oct 29 16:16:16 KotH: one of the last great kernels, indeed. Oct 29 16:16:40 mdp If I find am335x-boneblack.dts, how should I modify? Oct 29 16:17:22 adugenske: I just wanted to take a look at see what i2c nodes are enabled. Oct 29 16:17:57 mdp: I just found the dts file. Oct 29 16:18:26 any ideas how i can install devmem2 on BBB? Oct 29 16:19:04 Laurenceb scp Oct 29 16:19:08 ooh Oct 29 16:19:10 www.lartmaker.nl/lartware/port/devmem2.c Oct 29 16:19:12 usbstick? Oct 29 16:19:12 perfect Oct 29 16:19:13 gcc -o devmem2 devmem2.c Oct 29 16:19:17 heh Oct 29 16:19:37 mdp I found it here /root/am335x-boneblack.dts Oct 29 16:21:06 mdp: here you go for i2c2 pinmux_i2c2_pins { Oct 29 16:21:06 pinctrl-single,pins = <0x178 0x73 0x17c 0x73>; Oct 29 16:21:06 linux,phandle = <0x7>; Oct 29 16:21:06 phandle = <0x7>; Oct 29 16:21:06 }; Oct 29 16:21:51 Laurenceb: what did i tell you about NOT USING /dev/mem? Oct 29 16:22:35 heh Oct 29 16:22:37 KotH: that we should only use /dev/exynos-mem ? Oct 29 16:22:46 mdp: exactly! Oct 29 16:22:58 * KotH gives mdp some cru sauvage, then leaves Oct 29 16:23:08 uh oh Oct 29 16:23:10 Written 0x0; readback 0x80 Oct 29 16:23:28 Laurenceb: welcome to the world of registers Oct 29 16:25:23 adugenske: and do you have a node that starts with: Oct 29 16:25:35 https://www.irccloud.com/pastebin/IQWjx9kd Oct 29 16:25:47 or thereabouts Oct 29 16:26:57 mdp: Yes! Oct 29 16:27:54 what does "ls /sys/class/i2c-adapter" tell you? Oct 29 16:28:47 also do you have: Oct 29 16:28:53 https://www.irccloud.com/pastebin/U7CT8kGc Oct 29 16:29:04 mdp returns i2c-0 i2c-1 Oct 29 16:30:19 mdp Yes, the second pastbin is locaed in the dts Oct 29 16:31:08 ok, so i2c-1 is the hardware i2c2 Oct 29 16:37:11 hmf Oct 29 16:37:19 i seem to be blocked from gpio 2 and 3 Oct 29 16:37:20 wtf Oct 29 16:38:40 mdp: I think the device may be responding since I'm receiving the following: 40: 40 -- -- -- -- -- - from a i2cdetect, and my device is at 0x40 Oct 29 16:38:58 that's it! Oct 29 16:39:05 on i2c-1, correct? Oct 29 16:39:14 mdp: yes. Oct 29 16:39:26 mdp is there a command line way to read it? Oct 29 16:39:31 cool, so just so you understand why this is misnumbered.... Oct 29 16:39:56 that dts file controls which actual hardware i2c blocks are "visible" to the kernel. Oct 29 16:40:13 so the one called i2c1 is disabled Oct 29 16:40:39 and the kernel driver sees i2c0 and i2c2...but he implements a sequential numberbing scheme for the driver instances Oct 29 16:40:54 which unfortunately names them as i2c0 and i2c1 Oct 29 16:41:14 mdp: Thanks so much for your help! Oct 29 16:41:21 np Oct 29 16:41:31 so ok, you did an i2cdetect and see it. Oct 29 16:41:38 mdp: Is there a command line way to read the device at 0x40 Oct 29 16:42:33 mdp: Yes, i2cdetect -y -r 1 Oct 29 16:42:43 i2cdump will work Oct 29 16:42:47 take a look at http://www.lm-sensors.org/wiki/man/i2cdump Oct 29 16:43:06 if you want to write something in C to drive it from userspace I can recommend libsoc Oct 29 16:43:44 https://github.com/jackmitch/libsoc/ Oct 29 16:44:56 mdp: I'm using node (i.e. javascript). They just added i2c to the code base. Oct 29 16:45:18 noooooo!!! ;) Oct 29 16:45:28 lost another one to node :( Oct 29 16:46:10 mdp: Sorry, I just like the higher level constructs for http etc. Oct 29 16:47:59 understood, I use Go for that stuff Oct 29 16:49:32 mdp: I'm running i2cdump -y 1 0x40 w and receiving all XXX. Is this to be expected? Oct 29 16:50:13 it depends on the part, there are many protocols Oct 29 16:51:05 mdp: I'm using this: https://www.adafruit.com/products/1899 Oct 29 16:54:20 mdp: I owe you a beer. Where are you located? Oct 29 16:54:47 adugenske: np, I'm too far from most people here in almost rural ohio ;) Oct 29 16:55:12 adugenske: so you probably want to do i2cdump -y 1 0x40 b to start Oct 29 16:55:54 and I'd need to look further at that datasheet, but I believe you need to send specific commands to read anything, like most parts Oct 29 16:56:18 mdp: Running it and receiving XX for all entries. Oct 29 16:56:45 mdp: Can you send commands via the command line? Oct 29 16:58:18 adugenske: depends on the I2C device. i2cread can only do up to 2 bytes, I ended up writing a minimal C program to read out and then program an I2C device (http://www.adafruit.com/products/935) Well, actually, I'm using the chip by itself without the Adafruit module. Oct 29 16:59:47 Peanut: Wow, we're going after the https://www.adafruit.com/products/1083. Can you provide any tips? Oct 29 17:02:13 Friends, thanks for the help. Sorry, but I have to be away from the computer for a bit. Oct 29 17:10:08 hi #beagle. I've missed you. Oct 29 17:10:21 We missed you too. Oct 29 17:12:29 hi jkridner, where were you? Oct 29 17:13:15 back home in Michigan Oct 29 17:14:29 hey jkridner, how are things going for the GCI? Oct 29 17:17:49 adugenske: i2cget 1 0x40 0xe7 c Oct 29 17:30:14 adugenske: that should read the user register and return 0x01, the default value. Oct 29 17:31:08 Value at address 0x44E10A34 (0xb6f11a34): 0x20 Oct 29 17:31:08 Written 0x27; readback 0x20 Oct 29 17:31:14 why dont the bits change? Oct 29 17:31:21 with devmem2 Oct 29 17:34:50 because you aren't in supervisor mode when whacking stuff from /dev/mem and the control module is privileged Oct 29 17:35:00 ah Oct 29 17:36:18 Laurenceb: what did KotH tell you about using /dev/mem? ;) Oct 29 17:36:24 lol Oct 29 17:36:34 guess its time for some more board modes Oct 29 17:36:36 *mods Oct 29 17:36:47 i need to power cycle the usb Oct 29 17:36:52 this is a path that leads only to despair Oct 29 17:37:01 i was going to swap the pin into gpio mode Oct 29 17:37:16 is there want way to get supervisor mode? Oct 29 17:40:50 can anyone point me in the right direction in the TRM for the GPIO memory maps? I'm attempting to decipher the DTS regs for the pinctl modules to deepen my understanding of how it all ties together Oct 29 17:41:10 <_av500_> Laurenceb: NO Oct 29 17:41:17 <_av500_> Laurenceb: no Oct 29 17:41:20 lol Oct 29 17:41:25 <_av500_> well, yes, in the kernel Oct 29 17:41:38 nah im not recompiling Oct 29 17:41:38 I've found the base address for each of the 4 GPIO controlers, but cant find out how each pins configuration is managed in this memory region Oct 29 17:41:44 time for board mods Oct 29 17:44:29 KaaK: technical refernece manual Oct 29 17:45:21 Laurenceb, already have it up -- can you point me to a specific section? or even a chapter Oct 29 17:45:34 Hey Kaak Oct 29 17:45:53 You were doing cellular development right? Oct 29 17:47:08 Laurenceb: 1) write kernel module to whack the register and insmod it 2) run kernel with capemanager/overlays and insert dto that has the pinmuxing and let the kernel write the values 3) update your .dts file with proper pinmuxing, compile to to dtb, replace original, and reboot. any will work. Oct 29 17:47:26 oh Oct 29 17:47:32 thats pretty cool Oct 29 17:48:09 why do i need the dto stuff? Oct 29 17:48:23 as its using gpio3_13, which isnt on a pin header Oct 29 17:49:27 you don't need it, there are three options above Oct 29 17:49:56 or even 4) if the default pinmux on powerup is what you need then no need to do anything Oct 29 17:50:20 wait Oct 29 17:50:28 pinmux is in the control register? Oct 29 17:50:43 i mean module Oct 29 17:51:00 yes Oct 29 17:51:05 oh Oct 29 17:51:33 i think i can do this with a custom "cape" Oct 29 17:51:47 just pinmux gpio3_13 to gpio and set it low Oct 29 17:55:11 right, that's #2 or #3 Oct 29 17:56:09 ok, writing dts file Oct 29 18:02:27 http://pastie.org/9683788 Oct 29 18:02:30 is that ok? Oct 29 18:02:43 i was to write 0x27 at offset 0xA34 Oct 29 18:07:59 it loads ok, but register is unchanged Oct 29 18:09:47 0x234 is the offset for conf_usb1_drvvbus Oct 29 18:09:54 arg wtf Oct 29 18:09:56 0x800 is the base from which the offsets are supplied Oct 29 18:09:59 oh Oct 29 18:10:02 lol Oct 29 18:10:13 thanks for spotting Oct 29 18:11:31 register still unchanged :-/ Oct 29 18:14:52 perhaps a problem with capemanager not engaging it..dunno, not a cape manager user Oct 29 18:16:03 maybe i need more than one fragment? Oct 29 18:17:06 grep a34 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins Oct 29 18:18:00 don't trust a read from a privileged register via devmem2...only from the pinctrl driver Oct 29 18:18:03 pin 141 (44e10a34) 00000020 pinctrl-single Oct 29 18:18:05 oh Oct 29 18:18:51 ok, so that confirms that it wasn't activated Oct 29 18:19:18 do i need to reboot? Oct 29 18:19:47 i see my "cape" in /sys/devices/bone_capemgr.*/slots Oct 29 18:22:33 I think you need the bone-pinmux-helper fragment as well..from memory Oct 29 18:22:55 ok Oct 29 18:23:10 I think you'll find examples on google of this Oct 29 18:23:58 http://stackoverflow.com/questions/16872763/configuring-pins-mode-beaglebone Oct 29 18:24:03 ok ill try modifying that Oct 29 18:25:01 yep, derek's example is what I was thinking of Oct 29 18:27:21 Is there any logical reason that plugging in my wifi dongle whilst connected to ethernet would cause my bbb to become unresponsive + drop any sort of connection? (bbb debian) Oct 29 18:27:32 [12471.274408] bone-capemgr bone_capemgr.9: slot #10: Applied #1 overlays. Oct 29 18:27:37 but no change :-/ Oct 29 18:30:15 http://pastie.org/9683849 Oct 29 18:49:40 mdp the i2cget returns 0x02. What does this mean? Oct 29 18:50:12 that looks promising..but not what I expected from the datasheet. Oct 29 18:50:22 you should get that datasheet in front of you to make this thing work Oct 29 18:50:37 https://www.adafruit.com/datasheets/1899_HTU21D.pdf Oct 29 18:51:08 wait! Oct 29 18:51:12 I misread it ;) Oct 29 18:51:27 because it's the worst register doc I've ever seen in my life..good grief Oct 29 18:51:29 page 13 Oct 29 18:51:33 0x02 is correct Oct 29 18:51:42 only bit 1 is asserted Oct 29 18:52:09 so it works...congrats, your i2c interfacing was a success ;) Oct 29 18:52:26 mdp: Thanks for your help! Oct 29 18:53:20 Where did you find 0xe7 in the pdf? Oct 29 18:54:31 look closely at those datasheet examples of how to access registers..they explain in great detail what the process is a accessing a typical i2c device register (most devices work in this fashion)...i2cget in 'c' mode does an smbus read with is a byte write (of the register offset) followed by a byte read of the contents. Oct 29 18:55:14 page 10-11 explains the access model and has a table of the register addresses Oct 29 18:55:55 page 13 details that user register that I thought would be a good test to verify that you are reading from the device properly...as 0x02 is a known value it should return...unless you've written something into it after powerup Oct 29 18:57:03 mdp it looks like sending 0xF3 will trigger a temp meas and then it can be read with 0xe7 Oct 29 19:01:09 yes, but you don't read the result from 0xe7 Oct 29 19:01:19 you simply read 3 bytes Oct 29 19:01:25 msb,lsb,csum Oct 29 19:01:36 after issuing the trigger command Oct 29 19:04:01 mdp Entered: 2cget 1 0x40 0xe3 c, Received: 0x66. How does this map to msb, lsb &csum. Oct 29 19:05:19 mdp: you're back!?! Oct 29 19:10:45 mdp: I placed my figure on the sensor, and the response changed from 0x66 to 0x6d. Seems like it is working. Oct 29 19:11:41 the only problem with that is that you did a write to trigger (0xe3) then just a single byte read so you only go the most significant byte Oct 29 19:11:46 s/go/got/ Oct 29 19:12:16 ideally you'd do an i2cset 1 0x40 0xe3 b Oct 29 19:12:36 should a beaglebone black output hdmi out of the box? Oct 29 19:13:22 then an i2cdump of 3 bytes Oct 29 19:14:06 or maybe you can do two i2cget byte reads..I 'm not sure if the devices wants the 3 bytes read in a single transfer or not Oct 29 19:14:13 adugenske: you'll have to play with that. Oct 29 19:14:30 adugenske: but yeah, sounds like you are reading the MSB of that data Oct 29 19:20:52 mdp I entered i2cset 1 0x40 0xe3 1 b, then i2cdump -y 1 0x40 b and waiting for it to paint the screen Oct 29 19:21:41 mdp is there a more direct way to get MSB, LSB csum? Oct 29 21:52:09 anyone know how lxde starts up on the Debian jessie for the BBB... I can't find no xinit file... Oct 29 21:52:39 *wheezy Oct 29 21:53:34 hello fellow vodafone nz customer Oct 30 00:04:29 hi, my beaglebone black fails to boot after updating the kernel (to 3.16, if i remember correctly -- it's been broken for a while) Oct 30 00:04:59 to be more precise, the kernel boots, but fails to find the device with the rootfs: "Waiting for root device UUID=9c9c1270-ba24-41c3-abd1-3ce2336cc4dd..." Oct 30 00:06:03 the kernel image and rootfs are on the bbb's internal memory and i haven't changed anything other than the kernel, so i'm surprised that it's failing now... Oct 30 00:06:48 also, running `nand info` from the u-boot menu doesn't list anything Oct 30 00:09:15 ah, apparently the internal memory registers as mmc storage rather than nand: "NAND: 0 MiB ⏎ MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1" Oct 30 00:19:22 hey im tryin to disassmble my c code that uses the math library Oct 30 00:19:28 i want to view the assembly of the math functions wih my assembly Oct 30 00:19:37 i was wondering if any one could help with that? Oct 30 00:19:43 i've compiled my stuff using the -static flag: Oct 30 00:19:50 gcc file_name.c -static -O2 -c -std=c99 Oct 30 00:19:56 then used objdump -d on the object file Oct 30 00:20:03 but the math functions were not in there :/ Oct 30 00:23:02 ? Oct 30 00:32:50 zsnafu: does it branch to them? They might just not be getting inlined Oct 30 00:33:33 yea it branches to them Oct 30 00:34:09 Oct 30 00:34:36 opps Oct 30 00:34:42 b.n ffffffba Oct 30 00:43:01 :/ **** ENDING LOGGING AT Thu Oct 30 03:00:00 2014