**** BEGIN LOGGING AT Mon Jan 06 02:59:59 2014 Jan 06 03:44:21 yo Jan 06 03:44:33 bbb has new library for mono Jan 06 04:43:00 anyone want to chat? Jan 06 04:59:35 Beaglebone rev A6a, custom kernal based on ubuntu, RTL8188CUS. When I plug the wireless adaptor into the beaglebone the beaglebone imediately hangs and reboots. If I start the device with the wifi adaptor in, it'll work until I "lsusb", then it hangs and reboots. Ideas? Jan 06 05:00:18 have you tried a USBHUB yet? Jan 06 05:00:51 yup, same results Jan 06 05:01:21 My next guess would be to rebuild the RTL driver from source Jan 06 05:02:27 best of luck with that Jan 06 06:05:50 Hi all, does anyone know where can i find u-boot and linux source code for debian weezy? i want to make some changes in the default image. Jan 06 06:06:43 *debian Wheezy Jan 06 06:10:32 anyone?? any idea? Jan 06 06:36:27 Can anyone help me with this prob how to solve this dependency "Can't locate DBI.pm in @INC " Jan 06 06:52:36 Hello there Jan 06 06:54:01 Can anyone help me with this prob how to solve this dependency "Can't locate DBI.pm in @INC " Jan 06 06:57:04 Hi there, I have a BeagleBone Black and I noticed that there are several hardware versions (e.g. A4, A5, etc). How do I find out the hardware version that I currently have? Is it written somewhere on the board? Jan 06 06:57:23 I just want to make sure my board is consistent with the schematic and board files Jan 06 07:01:04 The only guess I can make now is comparing the date on the schematic and my date of purchase (receipt). Not sure if that's a good way to find out. Jan 06 07:08:52 HWDev2 mine is on the little barcode sticker on the breakout pins. Jan 06 07:13:50 Thanks, I found out my HW version. It wasn't on the sticker Jan 06 07:14:42 FYI, under the DC power supply, directly on the other side of the board, it tells you the PCB version Jan 06 07:14:58 Then I found the schematic that matches that PCB version Jan 06 07:15:55 Apparently, mine was PCB version B3 which corresponds to schematic version A5A. Jan 06 07:37:11 N2TOH: I figured it out, Kernels 3.9 and after removed some macros that the Realtek adapter needs Jan 06 08:59:01 Hi all, I using RS232 cape with BBB, w/o RS232 cape my UART2 works, but w/ RS232 cape UART2 doesn't work, I checked slots and clock is okay. I also checked voltage levels on cape and connectivity of signal also seems to be fine. Jan 06 09:00:47 i couldn't get a hold of scope to see the signals getting toggled. Any thoughts? Jan 06 09:13:16 Prat: check the schematics for conflicts Jan 06 09:31:09 hi everbody Jan 06 09:31:36 i want to know abt customization posibilities with BBB hardware Jan 06 09:31:50 can anyone help me Jan 06 09:34:36 read the SRM? Jan 06 09:53:16 @ <@KotH> I checked schematic. It seems to be correct. is there any possibility that it can be because of power supply being AC or USB powered? Jan 06 09:54:03 right now its AC powered, I mean via 5V adapter. Jan 06 10:49:07 by default, how many GPIOS is available on BBB? And do I need to create a DeviceTree Overlay to configure other pins? Jan 06 11:00:21 read the SRM? Jan 06 11:00:32 it should state how the pins are muxed by default Jan 06 11:00:53 and yes, DT overlays for different muxing Jan 06 11:00:57 or /dev/mem Jan 06 11:06:48 av500: I have seen the table about P8 and P9, but there shows what is the pin accordingly the mode, but how can I know what is the default mode, by its name? For example pin P9_12 calls GPIO1_28 so it is GPIO by default and pin P9_11 calls UART4_RXD so it is the RX from UART4 by default, correct? Jan 06 11:07:35 I think so Jan 06 11:09:44 av500: ty Jan 06 12:15:16 wow hard to find a beaglebone right now Jan 06 12:18:34 johnwalkr, no stock ? Jan 06 12:18:41 no Jan 06 12:18:58 and especially none i can order through my university (so i don’t have to pay for it) Jan 06 12:19:15 and so far none that i can order without a credit card Jan 06 12:19:37 i’m in japan and most stores you can order with cash butso far i’m only finding overseas stock Jan 06 12:20:01 oh i see Jan 06 12:23:41 fried one at a very inconvenient time Jan 06 14:34:10 I'm trying to load the uio_pruss module, but there does not seem to be a new entry under /dev Jan 06 14:34:14 also the examples fail Jan 06 14:34:23 but lsmod shows uio_pruss Jan 06 14:35:11 Module Size Used by Jan 06 14:35:13 uio_pruss 3825 0 Jan 06 14:35:52 Angstrom v2012.12 - Kernel 3.8.13 Jan 06 14:36:12 heeen: have you read - https://groups.google.com/forum/#!topic/beagleboard/gqCjxh4uZi0 Jan 06 14:37:47 hello. i am using a BBB connected to a monitor but without the X server running. I have a custom program written using ncurses that displays certain information in realtime. The problem I am facing is that the screen goes to sleep after some time and I have to attach a keyboard or mouse to bring it out of that sleep mode. the screen goes dark. How do I prevent this from happening ? Jan 06 14:38:38 vicash: I think you can echo something to somewhere in /sys/ Jan 06 14:39:15 heeen.. looks like an issue in the device-tree file? Jan 06 14:39:44 stt_michael: what is the most recent kernel Jan 06 14:40:05 stt_michael: do you know the place in /sys/ for doing this ? Jan 06 14:40:13 I guess I can just build that with the module hardlinked? should that work? Jan 06 14:40:30 heeen.. I think we're stuck somewhere in 3.8.13 Jan 06 14:40:44 bone28 possibly? Jan 06 14:41:37 heeen... which board you working with? Jan 06 14:41:49 vicash... seen something .. sec.. searching Jan 06 14:42:19 stt_michael: beaglebone (white?) Jan 06 14:42:29 rev a5 Jan 06 14:42:44 ok beaglebone -original :) Jan 06 14:42:52 :) Jan 06 14:43:47 looks like 3.8 is best supported still, but there is a 3.12 out there.. no cape support yet Jan 06 14:44:04 what does cape support mean Jan 06 14:44:07 no GPIO? Jan 06 14:44:16 if you plug in any boards to the headers Jan 06 14:44:17 I want to use the pruss to drive gpios Jan 06 14:44:37 'capes' are the prebuilt boards for beagles Jan 06 14:44:42 right Jan 06 14:44:51 they plug into the gpios though? Jan 06 14:45:10 they plug into the expansion headers P8 & P9 (which contain, amongst other things, GPIOs) Jan 06 14:45:41 vicash: "echo 0 > /sys/class/graphics/fb0/blank " looks like one option Jan 06 14:45:54 so for gpio and pruss, use 3.8.X, enable pruss uio in menuconfig and use that? Jan 06 14:46:19 http://beagleboard.org/linux <- is this up to date? Jan 06 14:46:48 stt_michael : thanks. i am also looking at the command "setterm" as a possibility Jan 06 14:46:57 heeen: most likely, yes Jan 06 14:47:14 ah the first wget is already 404 Jan 06 14:47:16 ;) Jan 06 14:47:17 vicash: I See reference to a beaglebone gui .. but not sure what that is .. setterm is a possibility yes Jan 06 14:47:31 ah the angstrom toolchain will be a ***** I'm afraid Jan 06 14:47:43 I recommend the linaro toolchain Jan 06 14:48:13 why angstrom don't maintain and people keep up-to-speed with the angstrom mess I dunno :/ Jan 06 14:48:14 stt_michael: got instructions for that? Jan 06 14:48:34 http://www.angstrom-distribution.org/ seems to also have instructions Jan 06 14:48:53 ah that site was down last I looked Jan 06 14:49:39 hm but it is about setting up oe Jan 06 14:49:47 I only want the toolchain though I guess Jan 06 14:50:00 stt_michael: what is the path of least resistance here :) Jan 06 14:51:43 heeen: think I'll point you to the excellent Linux-on-ARM site by Robert Nelson - http://eewiki.net/display/linuxonarm/BeagleBone Jan 06 14:52:02 I wouldn't worry about the rootfs necessarily .. but its up to you Jan 06 14:53:26 in that newsgroup thread you linked Jan 06 14:53:40 someone mentioned echoing PRU-BB somewhere /dev/.../cape Jan 06 14:53:44 what is that about Jan 06 14:53:54 I don't have a cape thing anywhere under dev Jan 06 14:56:59 heeen: its a matter of tricking the board into configuring the right peripherals Jan 06 14:59:31 heeen: yes, definitely some hoops to jump through .. reading: http://github.jfet.org/BBKNotes2.html Jan 06 14:59:41 git checkout origin/am33x-v3.2 -b tmp Jan 06 14:59:47 should I use this branch Jan 06 14:59:50 or master Jan 06 15:00:48 hi i ran echo "-11" > $SLOTS command after loading capemgr.9/slots in $SLOTS .It deleted first 2 lines of slots file and now i have not able to ssh into it but it leds seems to glow .Any idea ,now what could be the solution ?? Jan 06 15:04:04 stt_michael: with that magic script it works Jan 06 15:04:08 but Jan 06 15:04:20 would building the new kernel make it work without the script Jan 06 15:04:26 it seems rather hackish Jan 06 15:07:07 heeen: what do you get if you type "uname -a" ? Jan 06 15:07:40 Linux beaglebone 3.8.13 #1 SMP Mon Jun 3 19:22:45 CEST 2013 armv7l GNU/Linux Jan 06 15:09:10 hmm that doesn't tell us anything lol Jan 06 15:10:56 Angstrom v2012.12 Jan 06 15:11:09 http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/ <= might also be useful Jan 06 15:11:41 as so often the case .. something not entirely finished and polished :/ Jan 06 15:11:49 oh ... same version but not same built :: Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux Jan 06 15:12:26 yeah .. what do you find under /lib/modules .. does it say simply 3.8.13+ by any chance? Jan 06 15:12:50 stock beagle kernels don't discriminate .. its a pain. Jan 06 15:14:09 ugh I plugged in a usb wifi dongle and the heartbeat led stopped Jan 06 15:14:23 woops .. my guess is you didn't use a powered hub? Jan 06 15:14:38 probably crashed it Jan 06 15:15:08 wifi cards need more power than the board can natively supply :/ Jan 06 15:19:36 hi all, in /sys/devices/bone_capemgr.9/slots folder i have accidently deleted the first two lines using following export $SLOTS = /sys/devices/bone_capemgr.9/slots and then echo "-11" > $SLOTS commands and now i am not able to ssh into by beagle bone .... Any Idea how could i go back to using ssh ?? thanks Jan 06 15:20:19 stt_michael: I haven't even attached a powersupply Jan 06 15:20:21 hmm http://www.angstrom-distribution.org/ is down :-/ ... Which packages manager user angstrom distro? Jan 06 15:20:41 (would that even remedy that) Jan 06 15:20:49 s/user/use Jan 06 15:21:38 ah opkg ... hmm be Jan 06 15:22:32 halo Jan 06 15:22:44 hola tito_ Jan 06 15:23:00 oh the man of opkg is not in the basics -_-' Jan 06 15:23:25 hai Jan 06 15:23:45 where do you cemo from Jan 06 15:24:11 can you help me? Jan 06 15:24:15 please Jan 06 15:24:16 afaik ... this bubble of univers Jan 06 15:24:42 my english so bad Jan 06 15:24:48 :D Jan 06 15:25:29 tito_: ask your question ... some people here have build the BBB so they should have most of your responses. Jan 06 15:26:10 how set time and date on BBB Jan 06 15:26:31 i'm a newbie Jan 06 15:26:45 tito_ sounds to be a linux question/solution Jan 06 15:27:18 a question Jan 06 15:28:05 tito, from a terminal :: http://superuser.com/questions/302396/how-to-set-current-time-on-linux Jan 06 15:28:40 thank you very much Jan 06 15:28:43 np Jan 06 15:32:14 aurelien: what the mean "np"? Jan 06 15:32:21 np= no problem Jan 06 15:32:52 hihihi Jan 06 15:34:10 which is totally different from np-complete :P Jan 06 15:44:41 how to install adobe player? help me please Jan 06 15:50:32 tito_: 1) download adobe player Jan 06 15:50:36 tito_: 2) install adobe player Jan 06 15:50:39 tito_: 3) ... Jan 06 15:50:43 tito_: 4) profit Jan 06 15:50:47 1) is tricky for arm though Jan 06 15:51:04 ogra_: he could run it in qemu ;) Jan 06 15:51:10 * ogra_ guesses it is 0) ask adobe for a url Jan 06 15:51:23 KotH, no x86 emulation in qemu on arm Jan 06 15:51:34 * ogra_ was begging linaro for that for years ... Jan 06 15:51:36 bah! what community support is taht! Jan 06 15:51:47 they said it is to hard though Jan 06 15:51:53 huh? Jan 06 15:51:57 why? Jan 06 15:52:00 the base exists already Jan 06 15:52:13 you have to emulate a lot of syscalls that arm doesnt have apparently Jan 06 15:52:48 qemu does syscals that are arch dependend? Jan 06 15:53:01 or do you mean qemu-kvm ? Jan 06 15:53:15 no, but x86 simply has them and you translate ... while arm misses them and you need to emulate ... Jan 06 15:53:27 at least thats how they explained it to me iirc Jan 06 15:53:29 so ka Jan 06 15:53:32 i mean install adobe on BBB Jan 06 15:53:33 well, tough luck Jan 06 15:53:43 tito_: ask adobe for a version Jan 06 15:53:52 stt_michael: setterm -blank 0 does the screen blanking from user mode. i also tried the echo 0 > /sys/class/graphics/fb0/blank and that seemed to work as well Jan 06 15:54:45 which a version Jan 06 15:55:07 tito_: hmm... Jan 06 15:55:19 tito_: there is no flash player for ARM processors currently Jan 06 15:55:31 tito_: so, if you need one, you have to ask adobe to write one for you Jan 06 15:55:57 they have one, just not public Jan 06 15:56:05 it's not in opkg? Jan 06 15:56:11 partner companies can get it afaik Jan 06 15:56:23 maybe he can install gnash Jan 06 15:56:24 (or could, not sure anyone is even intrested in it anymore) Jan 06 15:56:38 yeah, gnash should work (kind of) Jan 06 15:56:55 how about cmucam4 on BBB Jan 06 15:57:14 what the mean gnash? Jan 06 15:57:24 gnu flash Jan 06 15:57:41 tito_ gnu = free as in freedom -> gnu.org Jan 06 15:58:00 http://www.gnu.org/software/gnash/ Jan 06 15:58:10 tito_: maybe you should try to search for it in your terminal opkg package manager Jan 06 16:00:59 does the beaglebone supply enough juice to its usb port with a power supply for wifi dongles Jan 06 16:01:16 or will that still overload it Jan 06 16:01:31 imho the host usb port should have a direct connection to the 5v plug Jan 06 16:02:20 heeen: check the SRM and the schematics Jan 06 16:02:41 tito_: http://botbrew.com/man-opkg.htm man of the package manager Jan 06 16:05:09 thank you aurelien Jan 06 16:05:13 np Jan 06 16:07:44 yea. it's working :) Jan 06 16:08:48 how about setting usart on BBB? help me please again Jan 06 16:08:50 hihi Jan 06 16:10:37 tito_: do you mean UART? Jan 06 16:10:55 yes, i mean uart Jan 06 16:10:58 tito_: http://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/uart Jan 06 16:16:19 why am I missing /var/log/messages Jan 06 16:18:22 heeen: cat /var/log/README say it use journal rather than messages Jan 06 16:19:57 complain to mr. poettering :) Jan 06 16:47:48 [kernel] RobertCNelson pushed 1 new commit to 3.13: http://git.io/fR7JZA Jan 06 16:47:48 kernel/3.13 a314c1b Robert Nelson: 3.13: update to v3.13-rc7... Jan 06 17:36:34 Hi! Jan 06 17:38:41 just for curiosity have any of you heard of someone that manufacture a full product (pcb, components, software) from the ones that the proyect provide?. I mean to create a full standalone product. Jan 06 17:41:51 I'm sure plenty would take your money Jan 06 17:53:31 on opkg upgrade it give :: Collected errors: Jan 06 17:53:32 * opkg_install_pkg: Package udev md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. Jan 06 18:02:39 http://www.mcmelectronics.com/product/83-14430?utm_source=Criteo&utm_medium=Retargeting&utm_term=83-14430&utm_campaign=criteo+retargeting&CA_6C15C=1621733040 Jan 06 18:08:21 hmm no one in #angstrom seems to have any idea o_O Jan 06 18:13:50 is there a 46pin ribbon cable you can get to connect to the headers on the BBB? (if there is I don't seem to be able to find one) Jan 06 18:14:31 there are 50 pin cables Jan 06 18:15:42 sorry ... you mean i need a pin cable to make the upgrade?? Jan 06 18:16:42 aurelien: no, that was just a random question Jan 06 18:16:59 -_-' Jan 06 18:19:07 aurelien: well did you try opkg update? Jan 06 18:21:09 that's what he said is causing the error Jan 06 18:21:32 oh, upgrade vs update Jan 06 18:21:36 can't read =) Jan 06 18:53:18 https://github.com/jarrettv/beagle-sharp-io Jan 06 18:53:32 here is an early mono library for working with the GPIO pins Jan 06 19:02:44 hm I am looking at a pruss gpio sample Jan 06 19:03:17 whats up? Jan 06 19:03:17 but I am missing where he sets up the gpio (he is using the onboard leds) Jan 06 19:03:37 the gpio for the pru are internal signals Jan 06 19:03:41 shouldn'T there be some write to 0x44e10000 Jan 06 19:03:48 bringing those internal signals out to a pin requires pin muxing Jan 06 19:03:49 so hard to read MS code with normal text editors Jan 06 19:04:22 nomel I am looking at https://github.com/boxysean/am335x_pru_package/tree/master/pru_sw/example_apps/blink Jan 06 19:04:27 you can do the muxing through the registers in the kernel, or through device tree. Jan 06 19:04:32 trying to understand it but the comments are sparse Jan 06 19:04:51 there's nothing relating to gpio1 in the blink.c source Jan 06 19:05:02 right, that's not the actual pru code Jan 06 19:05:12 that's code that loads the pru with a binary and executes it Jan 06 19:05:15 then waits for an interrupt Jan 06 19:05:20 from the pru, then exits Jan 06 19:05:31 the pru code is blink.p Jan 06 19:05:35 prussdrv_exec_program (PRU_NUM, "./blink.bin"); Jan 06 19:05:53 pru is programmed in asm only, not c. Jan 06 19:06:03 it doesn't really meet the requirements for c. Jan 06 19:06:43 #define GPIO1 0x4804c000 Jan 06 19:06:43 where does he get this address from Jan 06 19:06:43 also, in line 19 ans 28 he is writing 3 bits right? why? the blog post says it is an exercise to the reader Jan 06 19:06:43 https://github.com/boxysean/am335x_pru_package/blob/master/pru_sw/example_apps/blink/blink.p Jan 06 19:06:54 yes Jan 06 19:06:54 I know Jan 06 19:07:06 where did he get the adress for gpio1 from Jan 06 19:07:06 where is the mux done Jan 06 19:07:17 mux has to be done outside of the pru Jan 06 19:07:39 that address can be found in the reference manual for the ti am335x Jan 06 19:07:52 it's probably an address to a arm gpio...which is a bad way to do things. Jan 06 19:07:56 and why does he not have to set up gpio1 throughthe gpio control module? does the kernel do that since it uses iut for the heartbeat leds already? Jan 06 19:08:26 yeah, it's already set up for gpio Jan 06 19:08:30 through device tree Jan 06 19:08:37 hmm Jan 06 19:08:51 https://github.com/boxysean/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf Jan 06 19:08:52 so, the pru has access to all of system memory Jan 06 19:09:03 he's going out to system memory to set a gpio in the arm Jan 06 19:09:07 he's not using pru gpios Jan 06 19:09:10 which are 1 tick access. Jan 06 19:09:21 ah, so this is slower then? Jan 06 19:09:37 yes, much slower. like > 5 tick, and not consistent either. Jan 06 19:09:51 and I guess saturates the memory bus? Jan 06 19:09:57 if you do it a lot Jan 06 19:09:58 yeah, there's contention Jan 06 19:10:01 exactly. Jan 06 19:10:04 ok Jan 06 19:10:05 Table 9. PRU0/1 Constant Table Jan 06 19:11:02 so generic way would bedoes anyone have a better example of pruss gpio Jan 06 19:11:08 does anyone have a better example of pruss gpio Jan 06 19:11:20 read the reference guide, but you basically just set r31 bits Jan 06 19:11:21 that's all. Jan 06 19:13:15 r31 for input, r30 for output it seems Jan 06 19:14:08 someone should write llvm backend for pru asm Jan 06 19:14:37 https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c Jan 06 19:14:41 pru pin list Jan 06 19:14:54 I2C1_SDA is pin 18 on P9 (on the BBB), BB-I2C1-00A1.dts seems to sets offset 0x158 to 0x72 using pinctrl. why 0x158? where can i find this magic offset? :) Jan 06 19:15:31 triggering arm interrupts using pru events: https://show.zoho.com/published.do?rid=b0tmjd21ccd2824464d57afaede48a96dd18f&id=1703625000000004104 Jan 06 19:16:06 http://hipstercircuits.com/category/pru/ Jan 06 19:17:10 nomel: I saw that you has a column showing the pin mux mode, where can I find this information? I would like to know all pins that are on mode 7 by default (GPIO mode). And later create a devicetree override to use the max number of GPIOs Jan 06 19:18:24 elyezer: you could use this that I already made https://github.com/nomel/beaglebone/tree/master/gpio-header Jan 06 19:18:31 see the readme for usage Jan 06 19:19:33 what exqactly is a device tree overlay Jan 06 19:19:37 never heard of that Jan 06 19:20:24 derRichard: use a table: https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdEdwNmVQdHhSd0dmSWZMaWdJbVZJMkE&hl=en#gid=2 Jan 06 19:20:40 I need 6 outputs that I want to write to using pru Jan 06 19:20:49 derRichard: check out that pru pin list Jan 06 19:21:00 nomel: need permission first Jan 06 19:21:02 err, heeen: check out that pru pin list link up there. Jan 06 19:21:19 I'm looking at it Jan 06 19:22:05 derRichard: https://docs.google.com/spreadsheet/pub?hl=en&hl=en&key=0As0aJokrBccAdEdwNmVQdHhSd0dmSWZMaWdJbVZJMkE&output=html Jan 06 19:22:09 so should I just use one of the lcd outs? Jan 06 19:22:38 derRichard: that's not mine. i must have made a copy or something. i can't find the link to the original. Jan 06 19:22:45 why are some gpios pru1 and some pru0 Jan 06 19:22:54 nomel: thanks, i'm looking at it Jan 06 19:23:23 heeen: there are pin conflicts for some of those. hdmi fromer uses lcd. eemc uses some pins too. check the "pin conflicts" or something like that in the reference manual/wiki for the beaglebone black. Jan 06 19:23:37 and the lcd_data pins are sysboot pins. Jan 06 19:24:24 meaning they have to be high impedance at boot, so you'll have have to use an isolator/bilateral switch on those if your pins drive or have pulls Jan 06 19:24:41 nomel: ty Jan 06 19:25:01 elyezer: is that what you were going for? Jan 06 19:26:00 nomel: okay, i'm also ready the user manual (the fat >4000 pages pdf). where in this pdf can i find that I2C1_SCL is at offset 0x158? IOW how was this table made? Jan 06 19:26:16 elyezer: changing the states is pretty slow using anything device tree related. if you need high speed bidirectional, you'll have to do it in the kernel. Jan 06 19:26:56 derRichard: this is related to "pin muxing" so will be in the pad control registers. Jan 06 19:27:15 * derRichard looks Jan 06 19:27:23 i did too much with freescals socs ;) Jan 06 19:27:59 derRichard: wait, i'm confusing myself. Jan 06 19:28:24 hm, i really cannot find a detailed description of all pins in that manual Jan 06 19:28:56 derRichard: it's in the "am335x product preview" Jan 06 19:29:20 or in the beaglebone reference manual. Jan 06 19:30:02 look at the gpio it can be muxed to Jan 06 19:30:56 and then the gpio bank address in the technical reference manual Jan 06 19:31:02 * derRichard googles Jan 06 19:31:04 (page 164 memory map) Jan 06 19:31:14 you don't need the product preview..it's in the beaglebone reference manual. Jan 06 19:31:31 i'm used to using the product preview for pin stuff because the table in the reference manual doesn't list the pru pins Jan 06 19:32:19 nomel: please share the link to the pdf. i found a "beaglebone reference manual" but only with 104 pages... Jan 06 19:33:13 nomel: I'm taking a look Jan 06 19:33:16 https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true Jan 06 19:33:22 http://bbbadventures.blogspot.ca/2013/06/pinmuxing.html Jan 06 19:33:23 here, just read that. Jan 06 19:33:43 5Mb 121 pages Jan 06 19:33:56 or thereabouts .. thats the version I have Jan 06 19:34:36 nomel: i know how to set a mux. i want a _detailed_ mux description of all pins. Jan 06 19:34:57 * derRichard is really confused why the fat 4k pages pdf does not coantain a simple table Jan 06 19:35:02 you'll need to check the am22x processor manual Jan 06 19:35:05 33xx Jan 06 19:35:08 my bad Jan 06 19:35:19 haha .. never that simple Jan 06 19:35:26 derRichard: ahh, then that is in the product preview. Jan 06 19:35:33 nomel: that will help I need a way to define all GPIOs at once Jan 06 19:35:44 nomel: please share the link to the pdf Jan 06 19:35:45 but I can start from what is already done Jan 06 19:37:04 derRichard: http://www.mouser.com/ds/2/405/sprs717d-120055.pdf Jan 06 19:37:49 * derRichard opens and looks Jan 06 19:38:53 nomel: I saw the install script, if I'm correct it will copy al dtbo to /lib/firmware so on startup all GPIOs as configured Jan 06 19:39:02 no Jan 06 19:39:25 all of the dtbo have to be in /lib/firmware for the kernel to see them Jan 06 19:39:37 (and, it's cached at startup, so you'll have to possibly restart if you modify them) Jan 06 19:39:55 you have to load them manually Jan 06 19:40:30 nomel: you mean section 2.3 "signal description"? Jan 06 19:40:35 oh boy this stuff is complicated Jan 06 19:40:43 nomel: got the idea Jan 06 19:40:46 ty Jan 06 19:40:49 to make them load at startup, you'll need to put them into the am335x-boneblack.dtb Jan 06 19:40:51 there is like 10 indirections Jan 06 19:41:19 elyezer: or, just have a script load them all "manually" Jan 06 19:41:25 i'm sorry...that was confusing. Jan 06 19:41:59 to make device tree stuffs load at startup, you have to put them into the am335x-boneblack.dtb in /boot Jan 06 19:42:03 there is P8 and P9 and they contain randomized kernel pins, which map to randmoized GPIOs which map to some randomized PRU GPIOS Jan 06 19:42:12 nomel: no problem I got it Jan 06 19:42:22 or, you can load things after/during boot with a script by doing "echo > " Jan 06 19:42:59 heeen: it would be fine if someone made some tools for this stuff. Jan 06 19:43:12 I will take a look if I get something I send a PR Jan 06 19:43:20 nomel: you mean section 2.3 "signal description"? Jan 06 19:43:47 derRichard: table 2-7, ball characteristics Jan 06 19:43:59 derRichard: gives a list of all signal names a pin can be muxed to, and the mode to do it Jan 06 19:44:30 so in this table https://docs.google.com/viewer?a=v&pid=forums&srcid=MTczNzY5MjQ0Njg2MjQ5NDgzODcBMDIwNTM3NDYzMTAwODMzNTAxNTABekZLS0VaVDFmbHNKATQBAXYy Jan 06 19:44:31 would be nice if you could have the kernel log the modes of all the pins, show resistor and edge detection Jan 06 19:44:52 nomel: but this table still does not tell me the offsets. how can i know that I2C1_SCL P.17 is at offset 0x158 in the pad/mux register Jan 06 19:44:53 what does it mean "mux mode 7" Jan 06 19:45:07 if you set the mode to 7 you get this function? Jan 06 19:45:25 heeen: each pin can have 8 different functions/modes. Jan 06 19:45:36 derRichard: that's a different question, that table answers your "i want a _detailed_ mux description of all pins." Jan 06 19:45:42 nomel: ... Jan 06 19:45:42 :D Jan 06 19:46:18 nomel: okay, again. how can i find out in defail how to configure the mux by hand? i want to know the offsets in the config register for each pin Jan 06 19:46:29 derRichard: the offset can be found by reading that link: http://bbbadventures.blogspot.ca/2013/06/pinmuxing.html Jan 06 19:46:31 maybe i'm blind but the fat 4k pages manual does not tell that Jan 06 19:46:42 derRichard: that's a different question! Jan 06 19:47:08 derRichard: one sec. i know what you're saying ;) Jan 06 19:47:13 why do some entries have no kernel pin number Jan 06 19:47:14 can i install windows 8 on my beaglebone black? Jan 06 19:47:22 xphp: no Jan 06 19:47:30 wtf Jan 06 19:47:49 oh, windows xp? Jan 06 19:47:56 xphp: no way Jan 06 19:48:04 http://nomel.tumblr.com/post/30006589199/beaglebone-tutorial-configuring-gpio-pins Jan 06 19:48:08 derRichard: Jan 06 19:48:20 w98? Jan 06 19:48:22 xphp: you could if you were just using it as a mass storage device. Jan 06 19:48:33 let's ignore xphp, he is a troll Jan 06 19:48:49 no way i'm new here Jan 06 19:48:55 is this for pro people only? Jan 06 19:48:55 xphp: you could, but you'd have to rewrite it. i suggest getting a pascal book and giving it a go. Jan 06 19:49:27 xphp: microsoft only supports a few types of processors, and doesn't support arm, except for windows rt. Jan 06 19:49:38 xphp: just compile qemu and off you go Jan 06 19:49:53 great! Jan 06 19:50:00 no problem Jan 06 19:50:08 * nomel heen is a hero. Jan 06 19:50:25 derRichard: pinmux tends to be in the datasheet rather than the TRM Jan 06 19:50:54 zmatt: seems so on ti socs, yes :D Jan 06 19:51:50 is there a way to echo all the modes of the gpio? Jan 06 19:52:03 to know their current mode Jan 06 19:52:16 * pwillard silently laughs Jan 06 19:52:21 "mode" ? Jan 06 19:54:01 he probably means direction, edge detection, etc. Jan 06 19:54:26 which is a mode, by all the definitions of "mode" that I see. Jan 06 19:54:37 actually, some way to list all the pins in mode7 would be awesome :) Jan 06 19:55:00 guess not :P Jan 06 19:55:01 derRichard: oh, I see your problem now, the pinmux table seems to be missing in the am335x ds Jan 06 19:55:21 jarrettv: hate to say this, but what are you trying to do? Jan 06 19:55:35 zmatt: yeah, it's in the product preview. Jan 06 19:55:44 zmatt: :-) Jan 06 19:55:55 nomel: "the product preview" ? Jan 06 19:56:06 this is really a maze :( Jan 06 19:56:06 which is kinda crazy. "oh, i'm going to preview this cool new part! I'll have to remember these mux modes for when i use it!" Jan 06 19:56:18 nomel: i can look at all the tables to find an unused gpio pin in mode7 or it would be nice if I could just run a command and it would tell me which ones I can allocate Jan 06 19:56:26 jarrettv: that's not a gpio mode, that's pin function Jan 06 19:56:29 derRichard: this is why engineers get paid what they do. it's not that any of this is hard, it's that datasheets, documentation, source all sucks ass. Jan 06 19:56:36 gpio is one possible function of a pin Jan 06 19:56:45 indeed Jan 06 19:56:45 jarrettv: if it's already in mode 7, it's probably not "unused" Jan 06 19:57:04 jarrettv: why not just set the pin you want to mode 7? Jan 06 19:57:20 jarrettv: with something like this: https://github.com/nomel/beaglebone/tree/master/gpio-header Jan 06 19:57:36 nomel: i'm a paid engineer. i'm used to such crap... Jan 06 19:57:42 but still... Jan 06 19:57:46 nomel: because I could possibly grab a pin in use by hdmi or eemc Jan 06 19:58:13 jarrettv: no you couldn't. that's the point of device tree, to make sure you don't use pins that are already used! Jan 06 19:58:17 jarrettv: if you tried, it would fail. Jan 06 19:58:22 jarrettv: and tell you why it failed Jan 06 19:58:23 I've found that to really understand the processor it's advisable to also browse the TRMs of related SoCs since what documentation is or isn't included in the TRM (and its quality) seems to vary quite a bit Jan 06 19:58:36 (keep old versions too, in case TI deletes a section) Jan 06 20:02:00 it also helps in recognizing when a section has been copy/pasted from elsewhere without making the necessary adjustments to actually be correct for your target :P Jan 06 20:02:28 nomel: i see your point... but a script could probe each gpio to see if it could be exported and then show the list of open gpio pins Jan 06 20:02:50 jarrettv: and you would be assuming that "open gpio" actually meant "open gpio" Jan 06 20:03:02 jarrettv: i take that back. i see what you mean. Jan 06 20:03:11 actually, you can get a list of used pins. Jan 06 20:04:10 nomel: now i fully understand how to calculate the offsets on the bbb. thanks a lot for the pointers :) Jan 06 20:04:16 when you say used pins, you mean pins _not_ in mode7? Jan 06 20:04:40 or marked as used via device tree Jan 06 20:04:57 used by device tree. any pin could not be in mode 7. some pins may not support mode 7. Jan 06 20:05:11 so you'd have to start with a sane list of safe mode 7 pins. Jan 06 20:05:35 or, just forget your insanity and pick a pin, and use it as gpio, like everyone else :P Jan 06 20:05:47 nomel: heh Jan 06 20:08:22 just because a pin is set as gpio doesn't mean it isn't in use though Jan 06 20:09:10 heh. agmlego learned a gpio lesson recently. Jan 06 20:09:13 nomel: yea, really have to study the pin-outs to figure out safe pins to use Jan 06 20:09:53 and then some pins have a pullup Jan 06 20:09:54 jarrettv: you can use basically anything on p8 and p9 except the pin used by the emmc and hdmi, both are listed in the beaglebone reference manual. Jan 06 20:09:56 namely, don't connect switches to boot-mode pins unless your intent is to change the boot sequence :p Jan 06 20:10:02 lol Jan 06 20:11:26 myself: going from beaglebone white to black, i learned not to use teh built in sysboot pullup/down pins. :( they can change. Jan 06 20:11:42 nomel: that isn't really true unless you setup the pin manually or generateGPIOOverlays.py Jan 06 20:12:18 you have to set up the pins manually. there aren't any tools right now, unless you use adafruit library or something. Jan 06 20:12:30 there's the pinmux utility Jan 06 20:12:41 for device tree?! Jan 06 20:12:45 oh, no Jan 06 20:12:51 :( Jan 06 20:13:02 zmatt: pinmux utility? Jan 06 20:13:03 why not? why in the world has nobody written a crap little web tool yet? Jan 06 20:13:07 afaik... not using linux myself (yet) so hadn't really looked at it Jan 06 20:13:33 jarrettv: http://www.ti.com/tool/pinmuxtool Jan 06 20:13:34 jarrettv: use that gpio overlay thing i made, it's super easy. Jan 06 20:14:07 once you install, you just do "echo gpio_P8.11 > blah blah" Jan 06 20:14:13 and bam, it's muxed for gpio Jan 06 20:14:43 then echo gpiowhatever > gpio/export, then bam, you have the sysfs interface Jan 06 20:14:54 for all your fun edge detection and inverting needs. Jan 06 20:15:32 and, it's conflict aware, and it's all cleared on reboot, so you're not stuck. Jan 06 20:16:59 nomel: i'm confused... is is a temporary overlay since it isn't copied into firmware? Jan 06 20:19:17 nomel: on the bright side, at least you have device tree... if I want linux on the dm814x-based board I'm writing software for at work I think I'm expected to build a custom kernel with a hardcoded board def Jan 06 20:20:00 if i want to use the i2c bus on the bbb, do i need more than the BB-I2C1 overlay? Jan 06 20:27:51 nm, i2c works now :D Jan 06 20:33:01 jarrettv: it's a regular overlay. Jan 06 20:33:34 jarrettv: overlays are temporary and must be loaded at some point during/after boot by something. Jan 06 20:34:14 only the stuff that's in /boot/am335-boneblack.dtb is loaded at boot. Jan 06 20:34:36 nomel: oh, good to knkow Jan 06 20:34:53 when you "install" it, it just copies the overlays into a place the kernel can find them, /lib/firmware Jan 06 20:35:44 i needed a pullup on one of my pins but I couldn't figure out how to do that at boot time so I ended up using a transistor Jan 06 20:36:15 you can set pullups with that stuff i sent. Jan 06 20:36:22 err...those gpio overlays. Jan 06 20:37:04 but, you'll never be able to get a pullup enabled at power on. the default state for all pins is high impedance Jan 06 20:37:16 then, they can be set sometime after power on when the software gets around to it. Jan 06 20:37:58 nomel: ah i thought it could retain resistor setting across power cycles Jan 06 20:38:27 nope. everything is volatile. there's no baked in firmware. it's just a cpu than runs code. Jan 06 20:38:50 that code either comes from the memory card in the sd card slot, or the memory chip on the board, in the case of the beaglebone. Jan 06 20:42:27 ok, so when i put my mm on a pin and it is 3.3v upon boot, there is some software controlling that Jan 06 20:54:54 nomel: found the commands to know which GPIOs are already requested Jan 06 20:58:13 nomel: can you tell me more about the pru gpios Jan 06 20:58:50 nomel: https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0 can you explain this table Jan 06 20:59:20 if I wanted to use a LCD, then all those GPIO I couldn't use Jan 06 20:59:38 because that are the only pins I can route them to? Jan 06 21:00:18 if I want the 1 tick access, not going through the memory bus Jan 06 21:04:41 heeen: the TRM tells you which pins can be pinmuxed where Jan 06 21:05:51 do I necessarily need a dt overlay, or is it just an automatism for something that I'd have to do manually otherwise Jan 06 21:10:17 heeen: that table is the pru pins that connect to the headers Jan 06 21:10:29 so, for 1 tick access, you need to use those pins Jan 06 21:11:02 I see Jan 06 21:11:33 heeen: the proper way to do it is through device tree, but you can go low level of course Jan 06 21:11:44 is it possible to set resistor via sysfs? Jan 06 21:11:48 jarrettv: well, I think default pinmux *is* programmable.... for high-volume first-tier customers who get to do their own eFUSE programming Jan 06 21:12:20 heeen: pin muxing is through pad control registers. problem is, these registers require "privileged" memory access, so you have to go through the kernel. Jan 06 21:12:34 heeen: you could definitely write your own kernel module or mux interface, if you really wanted to. Jan 06 21:12:36 zmatt: i see Jan 06 21:13:26 jarrettv: if you mean pull up/down, then no. this is a pin mux option so requires device tree. that gpio thing i sent, you can set them with a single echo command. Jan 06 21:14:41 nomel: hmm, does a write to /dev/mem perform an unprivileged store? Jan 06 21:14:47 nomel: thx Jan 06 21:14:57 zmatt: yeah, that can't do it. Jan 06 21:17:56 jarrettv: if you want to throw that stuff in a script, shell scripts don't really support wildcard expansion, so you'll have to do something like this http://pastebin.com/5j9wGdtp Jan 06 21:19:56 heeen: here's the overlay i use for my pru stuff: http://pastebin.com/3WUHeNz4 Jan 06 21:20:41 i load it after boot with a startup script (have an old demo image where loading with uenv.txt is broken) Jan 06 21:21:29 how annoying that the control module disallows unprivileged stores then... I mean, if it is considered desirable to block unprivileged access to some modules just program the L4 interconnect to do so Jan 06 21:22:54 heeen: here's the script. requires some stupid. http://pastebin.com/d7gjhsGt Jan 06 21:23:18 zmatt: it's not a linux thing. it's a hardware thing. Jan 06 21:23:39 I understand that Jan 06 21:26:47 I'm just pointing out that there's already a reconfigurable hardware mechanism available to restrict access to modules based on access MReqInfo, so it's stupid they also have another (probably not reprogrammable) check for that in the control module itself Jan 06 21:28:58 i don't know. sounds sane to me. something that can very very easily destroy the chip with memory writes should probably not be accessible, even if the user poorly decides it should be. Jan 06 21:29:39 heeen: you do want DT. it does not need to be an overlay, you can write a complete DT file as well. but you do not want to use The Other Way Jan 06 21:29:47 (unless they in fact are doing so on the am335x, but on the dm814x the only predefined protection group is one limiting access to the eFUSE controller to secure-world only) Jan 06 21:29:53 who knows, maybe their apps engineers pleaded for it after customers kept screwing things up ;) Jan 06 21:30:00 nomel: that sounds unlikely Jan 06 21:30:21 you'd need to very deliberately open up access to the module by modifying interconnect registers Jan 06 21:30:49 a deliberate action doesn't require a sound mind :P Jan 06 21:30:54 also there's the MMR locks to prevent accidental writes Jan 06 21:31:17 no, but you can't safeguard against deliberate action anyway Jan 06 21:32:38 zmatt: you can help by not giving the user a choice: no non-privileged writes. Jan 06 21:34:34 it's still easy to deliberately bypass that, e.g. by patching the /dev/mem driver to perform privileged writes Jan 06 21:36:00 and if the user is sufficiently intent on frying his chip, there's always a blowtorch :P Jan 06 21:36:26 passing wrong voltage in is way easier than a blowtorch Jan 06 21:36:40 (speaking from experience) Jan 06 21:37:58 so don't copy /dev/urandom into the control module... Jan 06 21:38:06 well actually, nothing bad will happen if you do :P Jan 06 21:38:43 from experience it is easier to bridge the 5v pin to another pin with the male header on the raspberry pi Jan 06 21:39:54 I think in terms of hardware hazard they really made a poor choice by not having a "safe mode" (pull up/down only) as default pin mux like they do on previous socs but configure almost all pins to gpio Jan 06 21:40:21 zmatt: i'm not talking about user being some joe with a beaglebone, i'm talking about system developers. Jan 06 21:40:42 that make systems that joes use. Jan 06 21:41:37 which means that if you do a manual write to GPIO_OE, which is probably among the first things you'll try when first doing baremetal programming for example, and make a mistake (for example by assuming that it's output enable like the name suggests, rather than its inverse) you end up driving many pins Jan 06 21:42:32 yeah, that one is crazy. Jan 06 21:42:57 I think that's far more worrisome than allowing userspace writes (after deliberate configuration) to the control module Jan 06 21:44:35 access control to memory/peripherals should be in the kernel's hands, not hardcoded Jan 06 21:45:44 *hardwired Jan 06 22:47:37 what does one feed the u-boot `ls' command for the interface and device parameters? Jan 06 22:47:53 I can't seem to find anything valid Jan 06 23:53:26 Hello, I am trying to hook a Beagleboard xM to my computer and to the hdmi screen. What is the minimal cabling that I need to use for my computer to recognize the board. Thanks. (I did read the manual, but it does not read well). Jan 06 23:53:46 It is a a laptop Jan 06 23:54:04 Hello, I am trying to hook a Beagleboard xM to my computer and to the hdmi screen. What is the minimal cabling that I need to use for my computer to recognize the board. Thanks. (I did read the manual, but it does not read well). Jan 06 23:55:30 So far, I have usb to mini AB cable, comm cable with serial to usb adapter at its end, and a 5.5V power cable Jan 07 00:00:23 Please help! Jan 07 00:00:26 Thanks Jan 07 00:10:35 Hello, I am trying to hook a Beagleboard xM to my computer and to the hdmi screen. What is the minimal cabling that I need to use for my computer to recognize the board. Thanks. (I did read the manual, but it does not read well). Jan 07 00:10:58 Guest31593: Yeah, so, you have asked the exact same question three times. Jan 07 00:11:50 Yes, sorry about that. I am still waiting to see if anybody can help. Jan 07 00:12:19 Now, a reasonably intelligent person might think that the lack of response might have something to do with it being late in the continental US where this channel's primary members live, or with the enormous winter storm thereupon. Or, they might think that the lack of response is due to the question being inane and the answer obvious. Jan 07 00:12:36 But you chose to instead post the same thing three times, making it even less likely for people yto want to help you. Jan 07 00:13:15 I suggest reading all the links in the topic, and coming back when they all make sense to you. Jan 07 00:19:24 What does not reasonably intelligent mean? Quite a smart insulter you are, agmlego. Good evening. **** ENDING LOGGING AT Tue Jan 07 02:59:58 2014