**** BEGIN LOGGING AT Tue Jun 03 02:59:58 2014 Jun 03 03:02:52 bzyx: http://goo.gl/MCI8xp the "Debug" sheet has the layout of the debug interconnects Jun 03 04:01:17 in pthreads, can I access global variables assuming mutex and such Jun 03 04:33:29 foreverska: yes? they're global Jun 03 04:39:49 see that's what I thought... Jun 03 07:40:06 foreverska: What's up? Jun 03 07:42:38 Not much man. How are you? Jun 03 07:43:50 yup, playing with PRU and a kernel driver to work around the memcpy issue Jun 03 07:46:13 A kernel driver? Jun 03 08:32:01 zmatt: hi, so we've meet again :) I've posted that question on ti e2e Jun 03 08:32:03 :) Jun 03 08:54:46 yes I noticed the correlation ;) Jun 03 09:09:14 from today perspecitve I think I should bought beagle board (xm) as i see the omap3 have this directly on their datasheet, but the bbb was so promising at firts sight in TRM :P Jun 03 09:21:35 they're quite different cpus... the omap3 is much older and originally meant for smartphones, the am335x is very recent and aimed at industrial applications Jun 03 09:24:57 the omaps also tend to have the possibility of enormous amounts of trace/observation output, for in-depth analysis of real-time tasks and power management stuff Jun 03 09:27:29 but in other markets that's not quite as critical as in smartphones, so power management and trace capabilities of the netra/centaurus/subarctic family are much more limited Jun 03 09:27:49 mhm Jun 03 09:28:36 I mostly think it sucks that they used a coresight standard ETB instead of their TI-enhanced ETB... Jun 03 09:28:49 why I'm looking for ETM/ETB so CoreSight is I'm working on my msc. thesis in this topic Jun 03 09:29:06 especially since there's also no TPIU, so coresight trace can only go to ET Jun 03 09:29:52 that is a problem, as the etb is rather very small Jun 03 09:29:53 ouch, if you're doing stuff on Coresight then these SoCs are ... not the best choice Jun 03 09:30:20 TI SoCs are not Coresight compliant Jun 03 09:30:53 if you hook it up to JTAG you won't even find DAP without first interacting with TI's poorly documented ICEPick Jun 03 09:31:15 coresight autodetection will fail because TI leaves the CoreSight Debug ROM Table completely blank Jun 03 09:31:17 hmm i don't wont to play with jtag Jun 03 09:31:59 that Jun 03 09:32:01 my thesis topic is about performance analysis using linux kernel Jun 03 09:32:02 that's fortunate ;) Jun 03 09:32:14 so it can be even worse i think Jun 03 09:32:29 for that sort of stuff they use STM, which *can* output to the trace pins Jun 03 09:32:46 but the STM isn't a coresight component Jun 03 09:32:55 it is apparently standardized by MIPI Jun 03 09:32:57 but if i know stm is some kind of vendor encoded Jun 03 09:33:21 and the data are only usable when you use soft of the soc producer Jun 03 09:33:46 thats why i stick to etm as it should be stadarized Jun 03 09:33:54 well no, the data should, if I understand correctly, be "MIPI standard" ... but I'm not sure how helpful that is Jun 03 09:34:03 and i've seen somewhere some kind of decoder Jun 03 09:34:16 for etm tracers in etb Jun 03 09:35:11 ETM and STM do very different things btw: ETM traces processor events, while STM traces software events (by writing into STM-channels) and interconnect events (statistics and such) Jun 03 09:35:13 what i'm trying to do now is run a new kernel driver with preparing device tree file for bbb like this http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/260957.html Jun 03 09:36:07 you should check out the DM816x TRM, its debug chapter has quite a bit of info and afaik AM335x basically has the same debug subsystem Jun 03 09:37:59 ok looking at it Jun 03 09:38:58 what i've tried to do is run coresqight on my Nexus 5 where i know it's fully featured, but for no reason there disabled all of the fused for debugging Jun 03 09:39:11 smartphones are HS devices Jun 03 09:39:16 everything is behind lock and key Jun 03 09:39:20 which is weird cause most of the previous devices have the enabled Jun 03 09:39:25 really? Jun 03 09:39:32 no experience with HS devices myself Jun 03 09:39:32 mostly Jun 03 09:39:39 mhm Nexus4 or Nexus7 (2013) Jun 03 09:40:09 the work from what i've saw in their dmesgs Jun 03 09:42:10 what I really don't understand is why TI requires some bit in an ICEPick register (JTAG-accessible only) to be set to assert the DBGEN signal Jun 03 09:42:47 I'm seriously considering asking for a hardware patch on our board to allow the processor to access its own jtag port to set that bit, to allow the OS to use hardware breakpoint and watchpoints Jun 03 09:43:02 especially watchpoints are damn valuable Jun 03 09:45:37 but that won't affect you if you only use trace (NIDEN is asserted by default) Jun 03 09:46:53 i hope so Jun 03 09:47:52 looking at DM816x TRM an the debug section is way way more advanced and "true life" than for am335x Jun 03 09:49:55 yes, as I mentioned in the "AM335x Debug Access Port" thread on e2e, TI filters the info in TRMs based on intended audience, application domain / market, and I think /dev/urandom Jun 03 09:50:14 DM814x has lot of interconnect info, but no debug chapter whatsoever Jun 03 09:51:05 DM816x has a fair debug chapter, more info on MPUSS than I've seen anywhere else, but nothing on interconnect registers at all Jun 03 09:53:47 but most of the info is portable between those chips and AM335x :) Jun 03 09:54:10 Anybody written a bare-metal executable for BBB in C? Jun 03 09:54:12 when i've chosen that topic i've never thought that it might be so hard to find any useful informations. ARM is very open with their docs but from the SoC manufacturer side if you don't pay much you're probably left with your luck Jun 03 09:54:21 varad: yes Jun 03 09:55:28 varad: well, fully bare-metal on dm814x, I haven't written the init code for am335x yet but managed to start my code from u-boot relying on it to do some basic setup Jun 03 09:55:50 zmatt: Great! I've written this: http://fpaste.org/106566/32870140/ according to the TRM, it's supposed to echo a char stream to UART. Jun 03 09:56:14 #define REG(x) *((unsigned int*) x) Jun 03 09:56:18 please make that volatile unsigned int Jun 03 09:56:29 unless you want the compiler to murder your code Jun 03 09:56:59 zmatt: why do I need volatile? Jun 03 09:57:27 zmatt: okay, got it Jun 03 09:57:35 because otherwise that while() loop inside uart_putchar is an infinite loop Jun 03 09:58:13 without the volatile, the compiler will assume it behaves like memory Jun 03 09:58:52 zmatt: Okay. I'll make it volatile. I've compiled it using a linker script and startup assembly code I found somewhere, but on loading it, my board gets stuck at `reading u-boot.img` Jun 03 09:59:20 zmatt: could this be because of me not using `volatile`? Jun 03 09:59:58 zmatt: the same code in assembly (written by someone else) runs fine Jun 03 10:00:40 varad: disassemble your code, see what the compile made of uart_putchar() Jun 03 10:00:43 *compiler Jun 03 10:02:27 zmatt: Trying. Are linker scripts generic? Jun 03 10:03:25 not really no Jun 03 10:04:13 when working baremetal there's a fair bit you need to look after that would normally be dealt with by the OS Jun 03 10:04:30 like where exactly your code and data are located Jun 03 10:05:18 zmatt: Hmm. Can I find a guide on this somewhere? I'm entirely new to this. Jun 03 10:05:33 expect a steep learning curve Jun 03 10:05:58 (and get a JTAG debugger) Jun 03 10:06:21 because a ton of things can go wrong in those very first steps Jun 03 10:06:32 and if one of them does, you'll be absolutely blind without JTAG Jun 03 10:07:11 you have always have leds to blink :P Jun 03 10:07:47 bzyx: if your code is loaded to the right address, the pinmux is right, the gpio module's clock is enabled, etc etc Jun 03 10:08:08 yeah know, that not that simple on board like this Jun 03 10:08:17 also, gpio is scary on am335x Jun 03 10:08:34 on dm814x, all pinmux is set to "safe mode" by default, you explicitly have to mux something to gpio Jun 03 10:08:48 on am335x there's no safe mode, almost everything is gpio by default Jun 03 10:09:04 which means one tiny mistake and you're driving some external pin connected to who knows what Jun 03 10:09:31 feels like a very easy way to get your hardware damaged Jun 03 10:09:36 maybe it will be a good idea to start with their StarterWare to see what the most simple program is done Jun 03 10:10:16 zmatt: thanks, I'll keep that in mind Jun 03 10:10:43 bzyx: yeah, I should take a look at how StarterWare does things Jun 03 10:13:35 * zmatt is actually moving his code away from C in favor of Forth Jun 03 10:14:15 much better suited for baremetal programming imho Jun 03 10:14:56 didn’t heart about it Jun 03 10:15:19 not very well known, though embedded systems are its primary niche Jun 03 10:16:56 macs used to have Forth-based firmware back when they used PowerPC Jun 03 10:17:26 ("Open Firmware") Jun 03 10:17:34 ;) Jun 03 10:19:08 forth is one of the things that belong to the "everything was much better when we still had those 6000$ machines with 160kByte floppies and 40x25 text terminals, not the fancy stuff we have nowadays"-mindset Jun 03 10:19:40 i, for one, welcome our new technology overlords.... erm... :) Jun 03 10:21:01 LetoThe2nd: lol Jun 03 10:22:35 hi i have some questions on beagleboard xm...can someone please help? Jun 03 10:23:57 LetoThe2nd: I personally found that being able to write low-level code interactively on the target is actually very nice... Jun 03 10:24:39 zmatt: everyone to his own liking Jun 03 10:25:12 that's quite interesting so the forth then works as an OS? Jun 03 10:25:26 bzyx: to some degree Jun 03 10:26:01 hmm I must take a look at it at a free moment Jun 03 10:26:02 a forth can be tiny and basic (and fit in a few KB), or more advanced Jun 03 10:26:16 I recently added MMU support to mine Jun 03 10:27:49 forths are intrinsically very customizable, there's not really any clear separation between compiler and application and it's very normal to extend the compiler as part of your application Jun 03 10:31:18 mine still has a small "kernel" written in assembly (and some init code in C that I plan to eventually move to forth), but that gives just an initial "bootstrap" forth system with no support for comments, no control structures, no way to declare variables, ... all those things are defined in forth code on top of it Jun 03 10:31:43 (and yes, those first few lines of forth code are a bit... arcane) Jun 03 10:32:07 (and uncommented obviously, since comments aren't available yet at that point :P ) Jun 03 10:32:11 hi, i was wondering if someone can help me with my problem. I have a beagleboard xm running on 3.14.4-armv7-x6. I am trying to use the TL-WN722N wireless adapter for my project. The problem is this kernel does no but t have the drivers for this adapter. In particular it is the atheros driver. If i do lsusb on the command prompt i can see my device listed. But if i do iwconfig i donot see my device in the list. Can someone guide me to a d Jun 03 10:32:52 zmatt: that's an old school language :d Jun 03 10:34:00 bzyx: about as old as C Jun 03 10:35:22 it doesn't help that the wikipedia page writes all forth words in all-uppercase Jun 03 10:35:56 mhm it looks like asembly with basic ;p Jun 03 10:36:31 it is low-level, but at least it gives you *control* Jun 03 10:36:42 unlike C which is low-level but doesn't Jun 03 10:37:13 hmm it reminds me python a bit Jun 03 10:37:24 as a language for experiments Jun 03 10:37:34 but for example, thanks to forth's extensibility I can now access cortex-a8 coprocessor registers as if they were normal variables Jun 03 10:38:17 I initially used it mainly for experiments Jun 03 10:39:04 but I've noticed that I actually like it a lot more than C when dealing directly with hardwar Jun 03 10:39:57 :P Jun 03 10:40:09 being able to easily try little snippets interactively helps a lot Jun 03 10:40:44 (especially in cases where the documentation isn't quite adequate and some empirical science is needed) Jun 03 10:43:51 mhm i see the benefits of it. i sometimes really miss that it needs features like this in embedeed, so will give it a try if i find good tutorial about it Jun 03 10:47:32 maybe I can release my forth for am335x once is in a sufficiently usable state... will obviously also depend on whether my boss is going to be ok with that Jun 03 10:50:27 anyway, time for lunch, afk Jun 03 14:42:54 Hi everyone! Jun 03 14:45:23 hello, who could help me with analog inputs in a C program? Jun 03 14:46:30 I was wondering if someone could help me with some digital inputs I'm having issues with Jun 03 14:46:59 what's your problem aleandros? Jun 03 14:51:30 well, I'm using 16 digital inputs Jun 03 14:52:10 11 of them work just fin Jun 03 14:52:11 Hello - the RPI has a serial port which can be used to allow access to the console OR hooked up to a Relayboard which is what i am doing. Does the BBB have such as a serial port available as well that i can connect my wires to, somewhere on the GPIO header? Jun 03 14:52:21 yes Jun 03 14:52:23 several Jun 03 14:52:33 Sweet Jun 03 14:52:35 have a look into the system reference manual aka SRM Jun 03 14:52:44 Ok Jun 03 14:52:48 fine*. Same configuration for all of them (no special purpose pins) Jun 03 14:52:51 you have a console on the J1 header Jun 03 14:53:01 and more serial ports if needed on P8 and P9 Jun 03 14:53:12 but thats all explained there Jun 03 14:53:53 But the other five, by default, can only start detecting after the falling edge Jun 03 14:54:08 after *a* falling edge Jun 03 14:54:44 did you try to change the edge from falling to up edge? or increase the BBB frequency up to 1 GHz Jun 03 14:55:01 I'm using EDGE.BOTH in the configuration Jun 03 14:55:27 what puzzles me is the inconsistency: the other 11 inputs work just fine Jun 03 14:55:58 But I'm having this problem with: GPIO 10, 72, 73, 74 and 75 Jun 03 14:56:17 did you try to change the 5 that do not work fine? Jun 03 14:56:40 because there are some gpio that do also other things, so that could be the problem Jun 03 14:57:40 according to the webpage, those pints (P8_41 to 44) are not used by any other peripherial Jun 03 14:57:49 (neither SPI, I2C, Serial or PWM) Jun 03 14:58:18 And I'm using 16 pins as output, so I'm kind of running out of pins Jun 03 16:09:53 I'm going to post this here on the off chance that anyone is interested: I've ported a real time kernel I wrote for a university course to beaglebone black. I've put it up on github, http://github.com/mthiffau/HeatheRTOS Jun 03 16:10:13 I also added hardware floating point support with a lazy floating point context switch Jun 03 16:11:03 I'm making it GPLv2 until somebody tells me I need to make it something else for a good reason. Jun 03 16:40:54 Can I use the UART on my BBB in a non-uboot dependent standalone application? Jun 03 16:49:35 oooh very nice Jun 03 16:49:46 i might need that kernel Jun 03 16:53:42 but i probably won't be able to write my code in time for my deadline later this month Jun 03 17:18:29 having an issue baking kernel image for beagle, i enabled soc sound and getting failed build Jun 03 17:18:51 sound/soc/davinci/davinci-evm.c: In function ‘evm_tda998x_init’: Jun 03 17:18:51 sound/soc/davinci/davinci-evm.c:151:22: warning: unused variable ‘codec_dai’ [-Wunused-variable] Jun 03 17:18:51 struct snd_soc_dai *codec_dai = rtd->codec_dai; Jun 03 17:19:13 In file included from sound/soc/davinci/davinci-evm.c:12:0: Jun 03 17:19:13 sound/soc/davinci/davinci-evm.c: At top level: Jun 03 17:19:14 include/linux/module.h:87:32: error: ‘__mod_of_device_table’ aliased to undefined symbol ‘davinci_mcasp_dt_ids’ Jun 03 17:19:14 extern const struct gtype##_id __mod_##gtype##_table \ Jun 03 17:19:37 any clues anyone? Jun 03 17:19:55 dogrocket: you should use pastebin of your defconfig and the full build log. Jun 03 17:20:41 ok... will do jason Jun 03 17:21:30 I suspect the McASP driver needs to be enabled and it is a missing dependency in the Makefile that should be there. Jun 03 17:28:52 hi jkridner Jun 03 17:29:02 hi woglinde Jun 03 17:31:35 http://pastebin.com/8iCmrQYS Jun 03 17:32:05 ok.... hope its easy.. that was a looong compile on beagle Jun 03 17:32:19 doing it native, eh? Jun 03 17:32:50 lol Jun 03 17:32:56 what a watse of time Jun 03 17:33:43 well im using arch, and was having issues with x86, i wanted to use linaro toodlchain and arch wants you to use generic tool chain, and said heck with it.. just do it easy and slow Jun 03 17:34:38 thanks woglinde, what a way to uplift my dejected spirit :P Jun 03 17:35:54 glad i was doing something else... lol Jun 03 17:40:43 jkridner... think i should be looking for this file? target 'sound/soc/davinci/davinci-evm.o' Jun 03 17:41:43 err .c extension actually Jun 03 17:42:58 dogrocket .. you might need to specify your compiler prefix .. Arch should be no differnt to any other distro using the linaro chain Jun 03 17:44:43 ended up using arch default chain... and it compiled for 1 1/2 hours fine without issue Jun 03 17:45:09 can you build a cross-compile chain under arch? shouldn't be hard Jun 03 17:45:12 dogrocket: and which kernel sources are you using? Jun 03 17:45:25 obviously don't wanna use the x86 one ;) Jun 03 17:46:22 3.8.13 bone-53 Jun 03 17:47:00 using everything from arch PKGBUILD... guess its just roberts stuff customized a little Jun 03 17:48:00 ok.. davinci-evm.c is there Jun 03 17:48:39 jkridner its a bit ironic its what i enabled, maybe it was broke in first place and arch guys didnt catch it Jun 03 17:49:28 that's what looking at too. would probably be faster for me simply to try to rebuild the kernel to see. Jun 03 17:50:28 would appreciate if you could find time :-) Jun 03 17:54:18 dogrocket: is that module compiled-in or compiled as an external module? I remember facing a similar issue compiling the PRU rproc driver as a module. Jun 03 17:55:27 dinuxbg: hey. Did you work further on GCC port to the PRU? Jun 03 17:55:43 um im thinking the am335x soc was compiled in, the actual modules were completely left out so i moduled all of soc because i was thinking we would have to modify them Jun 03 17:57:16 pru yelled in fact but didnt fail... bad pointer use or something Jun 03 17:58:59 dogrocket: you would have to find out in which source file davinci_mcasp_dt_ids is defined and then copy it over to davinci-evm.c Jun 03 17:59:41 that was the way I fixed a similar issue which occurred with my compiling of the PRU driver Jun 03 18:01:29 Abhishek: OK... checking Jun 03 18:02:57 * Abhishek1 cross compiles beaglebone kernel in 6 minutes, wonders what is the mean cross-compilation time. Jun 03 18:04:20 * jkridner wonders why https://lkml.org/lkml/2013/1/31/183 hasn't been accepted upstream Jun 03 18:05:26 hrm... not able to grep davinci_mcasp_dt except davinci-evm.c Jun 03 18:05:28 * jkridner is still pulling down the kernel sources. Jun 03 18:06:05 none of the on-line lxr's work, since they are all against mainline and this doesn't seem to be there yet. :( Jun 03 18:07:31 Abhishekl: i found it in patch-3.8.13-bone53.diff but i dont understand is that supposedly where davinci-evm.c originates? Jun 03 18:07:33 jkridner: what if you could run the tool generator LXRng on the latest kernel sources and set up a beaglebone lxr? Jun 03 18:08:03 think it'd be used much? Jun 03 18:08:19 * jkridner needs to step away for a while Jun 03 18:08:46 was hoping to have a good recommendation for dogrocket, but I still suspect there is a 'defconfig'-related work-around. Jun 03 18:09:09 thanks jk, we will figure it out Jun 03 18:09:15 dogrocket: soc audio should have been already enabled as it is needed for HDMI. Jun 03 18:10:33 oh... well theres another soc thats not normally enabled besides codec modules, platform, machine, device i think it goes right? Jun 03 18:11:05 looking Jun 03 18:17:05 dogrocket: I opened 3.8.13 sources (Koen's vendor kernel, a month old and a little different from your case what the error messages say) Jun 03 18:18:02 oh... still to do with soc arent they? Jun 03 18:19:09 I found the symbol in my case lurking in sound/soc/davinci/davinci-evm.c Jun 03 18:19:19 https://www.irccloud.com/pastebin/2VeSC2AB Jun 03 18:19:30 i remember seeing an soc error about a week ago during a compile of roberts kernel too Jun 03 18:19:41 thats actually part of reason i went to arch Jun 03 18:20:09 I'm currently on Ubuntu 14.04 / linaro 4.8-armhf Jun 03 18:20:32 yep was exactly what i was using Jun 03 18:21:21 could you try copy-pasting that snippet into the appropriate position? Jun 03 18:21:38 i had forgotten in my angst i was seeing similar issue in another compile lol Jun 03 18:21:56 looking to see if i can find a spot Jun 03 18:22:24 probably right after include files would be good i suppose Jun 03 18:23:05 remove the last line of the snippet , that MODULE_DEVICE_TABLE thing, it might be a duplicate Jun 03 18:26:50 ok Jun 03 18:28:47 im gonna have to give it paths to includes :/ Jun 03 18:43:52 Abhishek: Its going to take me 1 1/2 hours to recompile that.... to find out if it works, it might though Jun 03 18:46:32 * agmlego starts the timer. Jun 03 18:53:02 dogrocket no ccache used? Jun 03 18:54:34 how could i restart? Jun 03 18:55:00 is there a way to restart build from where it exited? Jun 03 18:55:34 it would have unless you distcleaned or mrproper'd it Jun 03 18:55:55 IIRC Jun 03 18:56:17 well im using arches pkgbuild, im not seeing a restart option... havent cleaned Jun 03 19:46:58 Abhishek1: you say you had problems with latest 3.8 build and soc also? Jun 03 19:47:27 with roberts source and build that is? Jun 03 19:48:14 yup, my problem was with Koen's source and only when I modified the config to build a module configured built-in as a loadable module Jun 03 19:49:21 when I build it into the kernel, it builds fine as that #define that appears as an error resolves to a blank Jun 03 19:49:40 oh... im getting ready to do roberts source maybe i should hold off or you think that little addition to davinci-evm.c will fix? Jun 03 19:49:44 which it doesn't when being built as a module Jun 03 19:54:16 wonder if jk will report it to robert then...? Jun 03 19:54:24 i imagine he will Jun 03 19:55:17 or T.I. arago fellas even :P Jun 03 19:55:20 yup, remind him when you find him online, or send a mail to him and robert with the error details and the fix Jun 03 19:55:45 will do, thx for confirming Jun 03 19:56:42 dogrocket: though my issue was not with soc but with a file in drivers/remoteproc/ Jun 03 19:57:13 w 3 Jun 03 19:57:37 oh, thought it was same... so possibly that addition to davinci-evm.c might actually let it work Jun 03 20:03:01 you think its possible i could slap roberts kernel build in arch linux if its same version / commit? Jun 03 20:03:19 oops Abhischek1: sorry Jun 03 20:04:32 can build a lot quicker on x86... not gonna wait 2 hours for beagle to break build again Jun 03 20:04:47 you would just have to install modules correctly and replace the zImage on u-boot Jun 03 20:05:00 yeah for me it builds in 6mins Jun 03 20:05:26 about 15 here. .. will try that, thx Jun 03 20:10:18 is it possible to get an addon or something for virtual box to enable it to make virtual arm devices Jun 03 20:11:58 qemu supports some arm platforms... Jun 03 20:13:52 hmmm thanks i will look into it Jun 03 20:14:04 oops they left Jun 03 22:02:20 hi Jun 03 22:03:18 can i ask something? Jun 03 22:04:37 A Gentle reminder: Don't ask to ask, just ask. Jun 03 23:21:09 Abhishek1: you know what command is to restart rcnee's build is? from where it broke that is Jun 04 01:11:39 is there a way I can cause all log messages to be dumped in a ssh window as they arrive? Jun 04 01:43:01 Abhishek1: should work on the same way i use tcpdump/wireshark; ssh root@192.168.1.1 tcpdump -iany -U -s0 -w - 'not port 22' | wireshark -k -i - Jun 04 01:44:07 Abhishek1: ssh root@192.168.1.1 $command Jun 04 01:45:24 ragnar76: I didn't quite get the hang of the command you wrote Jun 04 01:46:03 Abhishek1: you tell ssh to start a command and see the output on your laptop Jun 04 01:47:08 what I actually wanted was that all the kernel debug messages get printed onto a ssh so that I can see them as they appear Jun 04 01:47:27 (kernel messages from the beaglebone) Jun 04 01:48:42 serial debug ftw :D Jun 04 01:48:55 minicom/etc Jun 04 01:49:35 do the messages echo to all tty's? Jun 04 01:49:38 Abhishek1: this should work with: ssh root@arm less +F /var/log/messages Jun 04 01:50:41 veremit: or that way but you need an ftdi Jun 04 01:51:00 hmm well I guess I had a propellor plug handy :D Jun 04 01:51:08 but serial debug cables are cheap Jun 04 01:51:22 they are. less than 5 bucks Jun 04 01:51:41 and very useful Jun 04 01:53:52 Abhishek1: this one works too (in case your less cannot follow): ssh root@$device tail -f /var/log/messages Jun 04 01:55:09 however. gn8 Jun 04 01:55:18 ah yes, it works. gn9 Jun 04 01:55:22 thanks! Jun 04 02:20:15 hello all, I have a problem I'm having trouble solving. Jun 04 02:20:36 I need to get wifi on a beagleboard black without using usb and none of the capes seem functional Jun 04 02:20:46 i mean, compatible Jun 04 02:21:35 does anyone know of any other options or caps that arn't listed on http://elinux.org/Beagleboard:BeagleBone_Capes Jun 04 02:22:00 capes* Jun 04 02:31:25 jlusby: I see a few options Jun 04 02:31:36 I'd settle for any beaglebone black wifi external antenna cape, does anyone know if one of those exists? I cannot use the WL1835MOD_w/_Chip_Antenna because the chip antenna wont work for our application Jun 04 02:31:55 okay, that was the first thing I was going to link to Jun 04 02:32:02 lol yea Jun 04 02:32:06 I already kinda ruled that one out Jun 04 02:32:12 and all the tiwi's are incompatible with the bbb Jun 04 02:32:15 :( Jun 04 02:32:31 what I am going to try is the HF-A11 eval kit Jun 04 02:32:35 the other off the shelf two options look like the USB hub cape, and the Arduino shield cape Jun 04 02:32:58 yea we cant do the usb hub cape because all the usb bandwidth needs to be devoted to high def cameras Jun 04 02:33:19 arduino shield cape is an option, but then things start to get heavy Jun 04 02:33:35 this is going on a quadcopter so we are trying to save as much weight as possible Jun 04 02:33:41 that's probably the most s/w tinkering required option as well Jun 04 02:33:50 s/w Jun 04 02:33:53 ? Jun 04 02:33:55 whats that mean Jun 04 02:33:57 software Jun 04 02:34:01 yea Jun 04 02:34:53 so you don't know of any options other than use an arduino cape + adapter? Jun 04 02:35:53 i guess we could do two beaglebones and use the usb adapter for the second one for wifi... Jun 04 02:35:58 thats the only other option I can think of Jun 04 02:35:59 what rules out USB? Jun 04 02:36:08 bandwidth Jun 04 02:36:09 on a single BBB, I mean Jun 04 02:36:17 we need to plug in two cameras Jun 04 02:36:20 we're not even sure we can do that Jun 04 02:36:25 ah, two cameras, not one Jun 04 02:36:30 yea Jun 04 02:36:32 lots of pixels Jun 04 02:36:40 and this is all going on a quadcopter Jun 04 02:36:42 no compression in them? Jun 04 02:36:45 so it needs to be lightweight as possible Jun 04 02:36:49 there will be some compression I think Jun 04 02:36:56 but we need it to be lossless Jun 04 02:37:05 so not a ton of compression between the cameras and the bbb Jun 04 02:37:09 asking alot from the am339x :p Jun 04 02:37:11 so its going to eat up a lot of the usb bandwidth Jun 04 02:37:14 yeah, was thinking that Jun 04 02:37:18 am339x? Jun 04 02:37:23 5x Jun 04 02:37:30 xx59 isn't it .. Jun 04 02:37:49 3359 or 3358 on the newer boards Jun 04 02:37:51 you guys lost me Jun 04 02:38:13 my point is .. maybe you should look for a beefier board :p Jun 04 02:38:16 the part number of the TI SoC Jun 04 02:38:42 aah Jun 04 02:39:08 have you tested capturing? Jun 04 02:39:19 we're still in the process of picking the camera Jun 04 02:39:20 with the two cameras, I mean Jun 04 02:39:22 well Jun 04 02:39:30 we're starting this all simultaniously trying to plan it all and jump into it Jun 04 02:44:42 so the plan is to broadcast the two camera feeds to the ground station via wifi, is that correct? Jun 04 02:44:58 wow thats bold lol Jun 04 02:45:20 all over usb?! Jun 04 02:45:29 * veremit runs for the hills lol Jun 04 02:49:14 uum, no not exactly Jun 04 02:49:20 the plan is to take two camerafeeds Jun 04 02:49:26 do some processing to figure out height Jun 04 02:49:38 and then send a compressed version of the feeds to the ground over wifi, Jun 04 02:49:43 the cameras get the usb Jun 04 02:50:00 the wifi gets whatever is left, right now our best idea is to send it out over an ethernet - wifi bridge Jun 04 02:50:35 yeah, that did occur to me Jun 04 02:50:47 thats the HF-A11 thing i was talking about earlier Jun 04 02:51:06 its a ethernet wifi bridge that has an external ufl antenna plug Jun 04 02:51:09 an Jun 04 02:55:31 I think you'll need to prototype a bit **** ENDING LOGGING AT Wed Jun 04 02:59:58 2014