**** BEGIN LOGGING AT Thu Jan 23 02:59:59 2014 Jan 23 03:00:04 change the pinmux...you would need to call to the pinctrl driver running on a8 to do it for you Jan 23 03:00:07 due to privilege Jan 23 03:00:28 and access from the PRU mastering on the fabric should fail Jan 23 03:00:33 s/and/an Jan 23 03:00:44 try it Jan 23 03:00:57 I don't have it in front of me unfortunately. It's back in the lab. Jan 23 03:02:31 well, when you do..try chapter 9.. Jan 23 03:02:58 write to your control module register directly from the PRU and see if it takes Jan 23 03:03:11 I think you'll find that it fails just like from userspace on linux Jan 23 03:03:20 I gotta run..good luck Jan 23 03:03:32 This is why I keep mentioning device tree, because that is how I've been setting the pinmuxes. Jan 23 03:03:39 ok, ttyl Jan 23 03:04:18 which in turn use the pinctrl driver to set the muxes in kernel space. Jan 23 03:04:53 by userspace, I mean...go try writing to the register with devmem2 Jan 23 03:05:09 ok, really out Jan 23 03:05:15 ok Jan 23 03:09:40 I don't see where you're getting P9_26 being pru1_r30. Is this reference sheet incorrect? https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0 Jan 23 03:10:06 or am I just reading it wrong.... Jan 23 03:10:31 hi every one this is sandy. i want to program GPIO,s of BBB using C language. suggest me some reference sites, blogs or any data links.. Jan 23 03:10:43 sure, give me a moment Jan 23 03:12:30 http://elinux.org/EBC_Exercise_11b_gpio_via_mmap Jan 23 03:12:37 Guest94003: Jan 23 03:13:01 1 min sir i am trying to see the site Jan 23 03:13:53 Here's some code I wrote that abstracts the mmaping: https://github.com/rockybulwinkle/beaglebone/tree/master/homework05 Jan 23 03:13:56 ymmv Jan 23 03:17:06 sir it is not looking similar to c language. sir let me tell u i am best in C language and ok with Python language. now suggest me better way to program Beagleboneblack GPIO's. my aim is to control Quadcopter with BBB so the code should be effective Jan 23 03:17:08 * prpplague will never understand this unreasonable expectations for gpio bitbanging performance Jan 23 03:17:33 prpplague: ;) Jan 23 03:18:58 what ???? rocky|arch Jan 23 03:19:39 lol Jan 23 03:19:54 sandy .. google beaglebone quadcopter .. sure I've seen something before Jan 23 03:20:38 Guest94003: The first link is a page my Professor authored. It will make more sense if you also look at his repository: https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/gpio Jan 23 03:20:53 veremit: I know I have. Being that it's my senior design project. Jan 23 03:21:42 ;P Jan 23 03:22:47 sir i am beginner. so suggest me the best way to program BBB. and suggest some links ... :-) Jan 23 03:24:22 ??? Jan 23 03:26:00 ok, if you want to do some really beginner gpio, you might look at using the device tree. Jan 23 03:26:52 take a look at this: http://elinux.org/EBC_Exercise_10_Flashing_an_LED Jan 23 03:27:46 I'm going to bed. Goodnight all. Jan 23 03:35:37 I'm running x11vnc on my BBB but I have not been able to get it to run automatically on startup. My service is running and the script works fine by itself, any ideas? Jan 23 03:36:34 create a shortcut to x11vnc .. set the password and config file up .. then add it to the appropriate X startup script Jan 23 03:36:49 thats rather a quick overview :) Jan 23 03:38:47 I've already have a script that starts x11vnc which works from shell. I've got a service running that starts the script but it won't launch from that. Jan 23 03:39:35 bear in mind that scripts don't always have an environment set.. ie what things are set/etc paths, etc Jan 23 03:39:50 sorry .. that was a bit non-english too lol Jan 23 03:39:59 maybe the shortcut would take care of permissions? Jan 23 03:40:06 don't bank on it ;) Jan 23 03:40:36 who executes the script has an impact .. and where its executed Jan 23 03:40:54 it is currently in /home/root Jan 23 03:40:58 bear in mind .. that if root exectues .. 99.99% its gonna run Jan 23 03:41:10 if anything else runs it .. thats a whole differnt game Jan 23 03:41:19 really .. we shouldn't be using a root account at all Jan 23 03:55:37 ok time for the pre-work nap :\ nite! Jan 23 05:22:26 Hello everyone, I have a small question Jan 23 05:22:45 Does the BBB have a USB 2.0 port, or a 3.0 Jan 23 05:23:07 and if 2.0, is it compatible with 3.0 Jan 23 05:54:13 2.0 Jan 23 06:20:36 odd Jan 23 06:20:44 what would cause mmcblk1 to be missing? Jan 23 06:20:48 on the bbblack Jan 23 06:21:22 in ubuntu... Jan 23 07:01:06 hi Jan 23 07:28:24 hi Jan 23 07:30:45 ugh, so many channels on freenode, going through the list and joining ones I think I'm interested in Jan 23 07:31:26 join all the channels Jan 23 07:31:44 how it feels like by now, heh Jan 23 07:33:18 wow, so many bitcoin channels Jan 23 07:34:04 anyhow, been thinking of getting a beagleboard for a while, figured I'll idle here as I figure out which one Jan 23 07:34:44 beaglebone black CookieJar Jan 23 07:34:56 is what 99% of people should get Jan 23 07:36:13 interesting, seems about the size of a raspi and same price but much better Jan 23 07:36:46 yes, except for video performance Jan 23 07:36:47 how long has the black been available? last I really looked at beaglebones, I don't think it was around Jan 23 07:37:01 about a year i think Jan 23 07:37:14 ah Jan 23 07:54:53 \o everyone Jan 23 07:55:08 I was lookin for the pin assignment of the J1 header, but havent been able to find anything except gnd, rx,tx Jan 23 07:55:15 I am specifically lookin for 3.3V power Jan 23 07:55:28 its all in the SRM Jan 23 07:55:32 to hook up a rs232 power level converter Jan 23 07:55:34 and the schematics Jan 23 07:55:36 oh Jan 23 07:56:49 found it Jan 23 07:56:54 I didnt found the SRM in the first place Jan 23 07:56:59 that might have been my problem Jan 23 07:57:21 oh wait Jan 23 07:57:41 I am bak again with a table of 3 Jan 23 07:57:44 gnd, rx,tx Jan 23 07:58:16 so have to check schematics Jan 23 08:00:30 so do I see this right? only the 3 pins of that header are connected? Jan 23 08:01:12 might be yes Jan 23 08:02:03 :/ Jan 23 08:02:22 now I need to get a blank copper to plug the power into the cape connector Jan 23 08:02:49 ? Jan 23 08:02:54 you have power on the cape pins Jan 23 08:03:22 yeah Jan 23 08:03:30 but I dont have sth tuo plug inm there Jan 23 08:03:39 just connector cabels pin to pin right now Jan 23 08:03:48 but I'll find sth Jan 23 08:06:44 yay Jan 23 08:06:47 it works :) Jan 23 08:07:20 looks like I better had chosen a chip that doesn't need power supply Jan 23 08:11:51 or ofc one that powers from the other side Jan 23 08:20:53 whew, lots of bumps but i think i2c bootloader for atmega8 and atmega328 is working reliably now Jan 23 08:21:04 proving very time saving Jan 23 10:44:33 i tried opkg upgrade and bbb took about 1 hour and when i reboot it windows cant recognize usb mass storage device Jan 23 10:44:44 help me Jan 23 10:44:57 i can debug and log in serially Jan 23 10:45:13 how can i regain usb configuration Jan 23 10:45:36 dont do opkg upgrade Jan 23 10:45:41 q0: no Jan 23 10:46:03 why would you want to? Jan 23 10:46:29 i just did it Jan 23 10:46:42 to see the change Jan 23 10:48:41 i can access the media nad BEAGLEBONE folder bt serially Jan 23 10:49:27 bt how can i make bbb to interact with windows through usb Jan 23 10:50:16 it does that by default Jan 23 10:50:27 sefat: maybe use one of these glass breaking sensors? Jan 23 10:50:30 just dont do opkg upgrade Jan 23 10:51:42 now what i have to do to get usb to interact Jan 23 10:52:09 when i plug usb pc doesnot recognize the usb and nothing happens Jan 23 10:52:17 hi Jan 23 10:52:45 does the beagleboard black support 3g dongle Jan 23 10:54:26 is there any way to reconfigure the bbb usign serial port Jan 23 10:54:52 vikky: if the dongle is supported by linux, most likely Jan 23 10:55:04 sefat: easiest is to reflash the stock image Jan 23 10:55:55 i dont want to reflash . any possible way ? Jan 23 10:56:27 cz i have some importent files on bbb. Jan 23 10:57:07 connect it to ethernet Jan 23 10:57:44 hi Jan 23 10:58:19 i had an issue with device tree while adding device info on beagle bone black Jan 23 10:58:48 okay thank u Jan 23 11:00:11 while i am compiling "make dtbs" its showing syntax error Jan 23 11:02:32 maybe your devicetree changes introduced a syntax error then? Jan 23 11:04:28 gfr Jan 23 11:06:28 i have added this code http://pastebin.com/dwkaKqaB Jan 23 11:07:23 after "make dtbs" its giving make dts Error: arch/arm/boot/dts/am335x-boneblack.dts syntax error FATAL ERROR: Unable to parse input tree Jan 23 11:07:44 it should give you the line number of where it went wrong too Jan 23 11:07:56 yes its giving that too Jan 23 11:08:21 but removed that its giving exactly over here i2c1: i2c@4802a000 { Jan 23 11:08:55 pastebin the whole error and the whole dts Jan 23 11:09:06 sure Jan 23 11:13:05 http://pastebin.com/4NBUAGxp Jan 23 11:13:55 I think you need an & before i2c1 Jan 23 11:14:30 ah, wait, probably not, if that is the first declared instance of i2c1? Jan 23 11:15:18 basically in header file its declared Jan 23 11:15:34 yes, i2c1 is declared in am335x-bone-common Jan 23 11:15:45 status = "disabled" Jan 23 11:15:48 you need to change line 19 to: Jan 23 11:15:54 &i2c1 { Jan 23 11:16:00 you don't need to redefine it Jan 23 11:16:11 i did that i took node name as refernce Jan 23 11:17:04 then there is no error but after compiling we get .dtb, i converted again to .dts Jan 23 11:17:20 to check this is included or not Jan 23 11:17:30 i couldnt find... Jan 23 11:17:44 why don't you try booting it and then reading the device tree from the running kernel Jan 23 11:18:10 yes i did i have written a driver with minimal probe Jan 23 11:18:27 and i2c1 wasn't present? Jan 23 11:18:27 am able to insert the driver but my probe is not called Jan 23 11:19:29 and no errors in dmesg? Jan 23 11:19:37 no errors... Jan 23 11:19:56 get that printk out and start following it back then I'm afraid Jan 23 11:19:57 so what happens if i redclare no issues write Jan 23 11:20:01 it has to include Jan 23 11:20:18 I doubt it is devicetree related if it's compiling fine and there are no errors on boot Jan 23 11:20:28 no errors Jan 23 11:21:31 the only other thing is maybe the pinmuxing Jan 23 11:21:35 I don't see any in your dts Jan 23 11:21:38 for iec2 Jan 23 11:21:46 i2c1* Jan 23 11:21:48 hmm Jan 23 11:22:07 see there are couple of included files Jan 23 11:22:21 in one of the included file pin muxing details are there Jan 23 11:22:41 for i2c1? and you are enabling the pinmux where? Jan 23 11:23:52 ok Jan 23 11:55:09 hello Jan 23 11:55:41 hello Jan 23 11:56:01 world Jan 23 13:39:29 Hi Jan 23 13:42:29 On a BBB I can't boot from the eMMC but I can alwas from an SD. When I try to boot with no SD all the lights are on and nothing happens. I suspect that there's a problem with my eMMC. When I hexdump /dev/mmcblk1boot0 and 1, it's just empty. Jan 23 13:43:32 Mauro__ .. can you connect a serial debug cable to your BBB? Jan 23 13:43:49 I don't have one :( Jan 23 13:44:16 it looks like I'll have to go shopping Jan 23 13:44:22 I don't suspect you'll see anything meaningful from the mmcboot partitions Jan 23 13:44:43 sure but empty is ok? Jan 23 13:44:47 you'd probbaly be better off checking the 'mmcblkXpY' partitions Jan 23 13:45:03 these are fine Jan 23 13:45:18 hello Jan 23 13:45:19 you should see X = 0 and 1 for uSD and eMMC .. and there should be a Y=1/2 for each Jan 23 13:45:47 you can then mount /dev/mmcblkXpY and check contents. Jan 23 13:45:58 any advice / tutorial on using the BBB as a web host for my site? Jan 23 13:46:29 Mauro__ .. do you have to hold the BOOT switch down on the BBB to boot from uSD? Jan 23 13:46:33 I did that and I've made any possible change to the uEnv Jan 23 13:46:42 bender .. just install a web server and you're good to go Jan 23 13:46:44 no I don't have to Jan 23 13:46:58 if the SD with MLO is there, it boots from the SD Jan 23 13:47:25 I'm running archlinux on this BBB Jan 23 13:47:28 Mauro__ .. then I suggest you have an ok bootloader in the eMMC .. you just need to fix u-boot and the kernel, and any uEnv Jan 23 13:48:11 I copied the one from the booting SD to the eMMC, no luck Jan 23 13:48:31 Mauro__ .. that is unlikely to work as the device addresses will be different Jan 23 13:48:54 and if it happens to use UUIDs .. they won't exist when you remove the uSD, for example Jan 23 13:49:25 I don't use uuids Jan 23 13:51:31 it was working fine until I upgraded the kernel Jan 23 13:52:34 on the emmc or the uSD? Jan 23 13:52:40 on the emmc Jan 23 13:52:58 what method/scripts are you using, out of interest? Jan 23 13:53:12 arch way with pacman Jan 23 13:53:52 not used arch personally Jan 23 13:53:57 well I can reinstall the whole thing with another distro Jan 23 13:54:04 and see what happens Jan 23 13:54:40 better to get the ttl console cable Jan 23 13:54:43 the instructions at http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black look straightforward .. but you have to be careful compiling custom kernels Jan 23 13:55:01 the debug cable will tell you whats going on on a serial console Jan 23 13:55:15 I run arch on my BBB Jan 23 13:55:20 it's quite nice really Jan 23 13:55:50 always a handy thing to have .. a serial console :) Jan 23 13:55:55 Mauro__: you can of course downgrade your kernel on the eMMC? Jan 23 13:56:12 yes sure Jan 23 13:56:18 and see if it works Jan 23 13:56:27 I'll try that :P Jan 23 13:56:32 you know how to do it? Jan 23 13:56:45 no but google knows Jan 23 13:56:46 :P Jan 23 13:56:57 good attitude :) Jan 23 13:57:05 Ask the Oracle (google) :) Jan 23 13:57:52 to get you started, mount the emmc partitions, then arch-chroot to it Jan 23 13:58:18 then you can use pacman etc on the emmc install while running off the uSD kernel Jan 23 13:59:23 your old kernel package should be in /var/cache/pacman/pkg Jan 23 13:59:41 I always clean the cache Jan 23 13:59:45 I'm running out of space Jan 23 13:59:53 well then you're out of luck... Jan 23 14:00:03 what is the kernel version you upgraded to? Jan 23 14:00:16 I was using the legacy kernel Jan 23 14:00:24 linux-am33x-legacy-3.8.13-14 Jan 23 14:00:38 I will try with the standar Jan 23 14:00:41 linux-am33x-3.12.8-1 Jan 23 14:00:49 that will probably break lots of stuff Jan 23 14:00:56 if you use gpio etc Jan 23 14:01:08 no gpio Jan 23 14:01:17 it's just my named server :P Jan 23 14:01:20 ah Jan 23 14:01:24 should be ok then Jan 23 14:11:22 well thanks for the help Jan 23 14:11:32 np Jan 23 14:11:48 I'll try this afternoon the boot from emmc Jan 23 14:12:03 bye! Jan 23 14:43:03 hi there, I wonder if my question is apropriated here : I'd like to make a performance test with beaglebone black = simply make a task that switch a GPIO that is monitored by an oscilloscope Jan 23 14:44:06 sry about such a simple question but I've read the Adafruit, derek molloy tutorials and videos and I'm still not understanding which is the correct GPIO I can use in my test program in task Jan 23 14:46:55 tsoin .. toggling GPIOs with sysfs is quite slow .. have you looked at the /dev/mem methods and using the PRU module? Jan 23 14:47:33 look *ONLY* at the PRU, please. Jan 23 14:47:38 heh Jan 23 14:47:42 you have never heard of /dev/mem Jan 23 14:47:47 lol ok ok :p Jan 23 14:48:08 tsoin .. try http://elinux.org/EBC_Exercise_10_Flashing_an_LED to prove the basics out Jan 23 14:48:31 for simplicity I didn't said that I currently Xenomai Jan 23 14:48:32 * stt_michael is gonna have to investigate these 'ere PRU thingies .. Jan 23 14:48:47 if you want to ride the registers, respectively gpios directly on the main cpu, write a kernel module. but, NEVER EVER listen to some one who tells you to poke /dev/mem Jan 23 14:49:49 well indeed LetoThe2nd : I've seen the posts about /dev/mem and I'm not sure that bypassing the kernel by accessing direcly to /dev/mem is a good thing Jan 23 14:50:05 very risky Jan 23 14:50:20 unless you know Precisely what you're doing .. which, I admit .. most people won't be. Jan 23 14:50:39 that's why I've "tried" to understand devicetree : failed Jan 23 14:50:46 ;) Jan 23 14:50:46 nobody does, because there literally is no point to it. Jan 23 14:51:13 you will need to master device-trees unfortunately .. but it will prove worthwhile to get the PRUs going Jan 23 14:51:21 really ? you make my day I was feeling like dumb Jan 23 14:51:42 from a quick search .. I can see people have worked xenomai/pru's on the beagle for PWM/CNC and suchlike Jan 23 14:53:34 well PRU is a great thing from TI btw I just 1st want to focus on Xenomai (machinekit) perfs btw Jan 23 14:54:02 stt_michael : that is the pointer I needed Jan 23 14:54:23 hello all, I have a question regarding uart, now I am testing on BBB and would like to enable one of UART say UART3. But I would like to implement the uart driver in a customized way, so how can I do that? what I dont understand is we are using DTS, shall we implement the driver in DTS or change it in the kernel? Jan 23 14:54:34 linuxCNC seems to be quite an interesting project :) Jan 23 14:55:04 and it evolves as machinekit brings new capes Jan 23 14:55:07 nicknick .. you can force loading of the UART capes with capemgr .. which will enable the ports Jan 23 14:55:16 nicknick: define "customized" Jan 23 14:55:44 alternatively .. have a look at the device-tree files for the UART capes .. to see what you want to achieve Jan 23 14:56:07 stt_michael : to be honest currently I use it to gain time patching and compiling Xenomai myself Jan 23 14:56:09 customized means it will not implement a general uart, I would like to implement a decoder which will check the message pattern there Jan 23 14:56:51 thank you all (I m not so dumb after all ;o) ) Jan 23 14:56:52 sounds like its not a uart driever, but a protocol sitting on top Jan 23 14:57:14 yes you can say that Jan 23 14:57:38 but my idea is that the kernel space check the pattern and decide when to forward the message up to the user space Jan 23 14:57:51 methinks the physical layer will be the same. . what you do with it on top is up to you Jan 23 14:58:04 nicknick: "sounds like a protocol" Jan 23 14:58:05 nicknick .. write a kernel driver on top of the port Jan 23 14:58:25 nicknick: there are quite some examples for you there, lipe SLIP, PPP, whatever. Jan 23 14:58:26 how to do that Jan 23 14:58:43 LetoThe2nd .. PPP is very much userspace :p Jan 23 14:58:56 stt_michael: part of it, yes. not all AFAIK Jan 23 14:59:08 nicknick, you seem to think you can implement a custom driver using DTS data..what do you mean by that? Jan 23 14:59:25 I just ask if this is possible Jan 23 14:59:32 I can make an example Jan 23 14:59:43 DT is a data definition that defines h/w...so no. Jan 23 14:59:51 it doesn't "do" anything Jan 23 14:59:54 http://lxr.free-electrons.com/source/drivers/net/slip/ Jan 23 14:59:54 nicknick .. start with http://www.tldp.org/LDP/lkmpg/2.4/html/book1.htm Jan 23 15:00:42 now if I do reading from uart, the data will come anytime, but what I want to do is to check the data if the data has the correct header and ender, then let the kernel forward it to the user space, so that my user space will always get the correct pacakage Jan 23 15:01:08 * LetoThe2nd sets the post "sounds like a protocol" to auto-repeat Jan 23 15:01:10 nicknick, read the links others posted..they show implementations of what you describe Jan 23 15:01:57 looks great, then do I still use dts to cape the uart? Jan 23 15:02:05 even irtty-sir should be something like it, AFAICS Jan 23 15:02:06 you'll need to configure the processor/port using a Device-Tree file (either predefined or custom) .. then write some software that talks to the /dev/XYZ node created by it Jan 23 15:04:29 OK, so if I understand correctly, I could implement a top module standing on the uart port driver and set up the pin port by dts when it boots up? Jan 23 15:05:20 nicknick .. yes thats pretty much it Jan 23 15:05:28 and the top module and read the uart data one byte by another? Jan 23 15:05:52 basically yes. Jan 23 15:06:25 depends how you implement your module .. I guess there are interrupts available for UARTs Jan 23 15:06:37 the sense in this design is that this protocol module then is able to work on any serial line which has the hardware capabilites. e.g. on your desktop for testing, for example. Jan 23 15:08:20 yes thats what I want to do Jan 23 15:08:34 any example about protocol on uart? Jan 23 15:08:39 *sigh* Jan 23 15:09:08 go back about 10 minutes. thanks. Jan 23 15:09:19 http://lxr.free-electrons.com/source/drivers/net/slip/ this one is Jan 23 15:09:25 sorry Jan 23 15:10:48 how can I attach the driver to the device I connect to the laptop? for example, when I connect a tty device, it will show ttyUSB0 and use the general driver, how can I force the system to use the protocol driver? Jan 23 15:10:51 that together with drivers/net/irda/irtty-sir.c are two most simple implementations i could find right now Jan 23 15:11:09 do it in user space Jan 23 15:11:18 even that would work Jan 23 15:11:33 (if not tied to very severe timing constraints) Jan 23 15:11:45 and would be WAAAAAY easier probably Jan 23 15:12:11 I have some time constraints thats why I put it in the kernel Jan 23 15:12:21 define "timing constraint" Jan 23 15:12:32 real time system Jan 23 15:12:42 i patched rt patch Jan 23 15:12:44 thats not a "timing constraint", its a buzzword Jan 23 15:12:58 a patched patch? Jan 23 15:13:16 a patched patch patcher. Jan 23 15:13:56 from http://elinux.org/EBC_Exercise_10_Flashing_an_LED example (gpio1_28 ) is about bb white: how to transpose available GPIO for black ? Jan 23 15:14:51 so say that Jan 23 15:15:03 "that" Jan 23 15:15:41 I have a sensor streamming data all the time to BBB, and I would like to receive messages directly from kernel space rather than uart data Jan 23 15:15:52 you are evading. Jan 23 15:16:15 you dont make sense Jan 23 15:16:24 in the end, the very same data ends up in user space Jan 23 15:16:32 minus framing maybe Jan 23 15:16:38 but with the same latency constraints Jan 23 15:16:40 if you want to do cooking of the uart data you have to do a tty discipline Jan 23 15:17:10 ok the data from sensors has the same latency Jan 23 15:17:43 don't do buzzwords, give numbers. Jan 23 15:17:50 but I just want to get the complete message Jan 23 15:18:37 for the user theres no difference in a library or the kernel doing the handling. for the developer, there is. Jan 23 15:19:08 and even if you do things in kernel space, data has to be transferred to userspace, etc. Jan 23 15:19:20 say one message has 10 bytes, if i directly read from uart, sometimes I only read 6 or 8 bytes. I want to use the kernel space to trigger when to store the data in the buffer Jan 23 15:19:28 so without *real* numbers on timing constraints, you are blabbering pointlessly. Jan 23 15:19:53 nicknick: why do you read only 6 or 8 bytes? Jan 23 15:19:53 nicknick, tty discipline Jan 23 15:19:58 your cable that bad? Jan 23 15:20:15 av500: thou shalt donate a new cable. Jan 23 15:20:16 you want to cook the data from a uart so that userspace gets complete messages Jan 23 15:20:26 whatever the message unit for you app is Jan 23 15:20:33 * LetoThe2nd heads off, don't feel like repeating all over Jan 23 15:21:13 LetoThe2nd: too late, burned into my ears Jan 23 15:21:36 I propose a recreation for the mind with my question ;op Jan 23 15:22:04 yes panto Jan 23 15:22:22 so whats the idea Jan 23 15:22:35 I am telling you Jan 23 15:22:35 a line discipline Jan 23 15:22:37 discipline or protocol module? Jan 23 15:22:38 look it up Jan 23 15:22:52 everything has been done before Jan 23 15:23:09 unix has a longer history than 50% of the people on this channel Jan 23 15:23:15 don't reinvent the wheel Jan 23 15:23:20 s/been done/happened/ Jan 23 15:23:25 and it will happen again Jan 23 15:24:30 should I consider GPIO1_28 on white on pin 60 is available on the same (pin60) for the black one ? Jan 23 15:24:43 say I finish the kernel dirver, how to test it with general uart device Jan 23 15:25:00 I have a serial 2 usb cable, Jan 23 15:25:07 the port will be ttyUSB0 Jan 23 15:25:18 that uses general tty driver, right? Jan 23 15:26:25 you use a user-space app that pushes that discipline to the fd it's opening Jan 23 15:26:46 http://www.linux-mag.com/id/1891/ Jan 23 15:27:08 (I should start charging) Jan 23 15:27:30 panto: charging at the red cape? Jan 23 15:27:36 head low? Jan 23 15:27:41 down low low Jan 23 15:28:07 panto: 2001, thats for another version of Linux Jan 23 15:28:17 the steam powered one Jan 23 15:28:26 choo choo m**********r Jan 23 15:29:05 k, conf-call time, l8r Jan 23 15:29:32 panto: be kind to the people from bavaria Jan 23 15:30:01 o,o Jan 23 15:30:57 should I consider GPIO1_28 on white on pin 60 is also available on the same (pin60) for the black one ? Jan 23 15:31:28 the capes should be mostly standard.... *waits for flame* Jan 23 15:32:04 ? Jan 23 15:33:42 check the BBB ref. manual tsoin Jan 23 15:34:01 and/or white one too Jan 23 15:37:04 thank you all! Jan 23 15:37:08 well I've look at the header table where I can see the gpio1[28] = P9_12 on black Jan 23 15:37:32 if this is what you meant stt_michale Jan 23 15:38:31 if the gpio on white matches the gpio on black ..that answers your question, no? Jan 23 15:39:01 (reading header table from each SRM) Jan 23 15:39:30 wasn't sure that available gpios on white = available ones in black Jan 23 15:39:57 no I am Jan 23 15:40:02 now Jan 23 15:40:46 best way is to check .. I -believe- the capes are designed to be cross-compatible .. even if the software support lacks it Jan 23 15:41:14 but I suppose that in a future I'd have to dig in devicetree if I want to free some GPIOs/Pins right ? Jan 23 15:42:09 you'll need to configure the pin_muxes in the device-tree yes Jan 23 15:42:47 even if I know that this is a fresh implementation, why isn't there an automagic tool for that, it would save brain & time Jan 23 15:43:23 tsoin .. cos nobody has made it yet Jan 23 15:43:23 but I 'm sure there is a reason against this Jan 23 15:43:32 really ? Jan 23 15:43:47 oww Jan 23 15:43:49 device-trees are still relatively new .. and specific to each processor Jan 23 15:44:19