**** BEGIN LOGGING AT Wed Jun 03 02:59:59 2015 Jun 03 08:50:14 ar e there any ideas what could be wrong if debug interface shows alwas wrong chars and charater mismaches.. no real boot log ? I configured 115200 8,N,1 Jun 03 08:51:36 something wrong with your serial I guess Jun 03 09:46:47 Using BBB with CBB-Serial. I'm trying to get 1PPS to come in on CTS on UART4. linuxpps seems to have registered OMAP-SERIAL4 as source, but ppswatch /dev/pps0 times out. I can see the signal on P8.35 with my scope. What am I missing here? Jun 03 09:49:08 do you have a UART4? Jun 03 09:49:11 in linux Jun 03 09:49:37 Yes, I have /dev/ttyO4 Jun 03 09:50:13 And /var/log/messages says: pps pps0: source "/dev/ttyO4" added Jun 03 09:50:36 cat /proc/tty/driver/OMAP-SERIAL -> uart:OMAP UART4 mmio:0x481A8000 irq:45 tx:549 rx:1320594 fe:889 pe:88 brk:19 RTS|CTS|DTR|DSR Jun 03 09:51:20 I do get NMEA messages in on UART4 Jun 03 09:51:39 hm Jun 03 09:51:51 no idea than Jun 03 09:52:48 and that muxing includes CTS? Jun 03 09:53:33 tbr the problem is somewhere else Jun 03 09:53:41 if he gets nmea out of it Jun 03 09:53:47 its all its needed Jun 03 09:53:47 tbr: I'm using the default firmware for CBB-Serial, and I don't yet know too much about overlays Jun 03 09:54:28 woglinde: AFAIU no. PPS is not part of regular UART data. Jun 03 09:54:39 Yes, gpsd receives NMEA messages just fine, linuxpps claims to have found a PPS-source on the same uart, but no signals are received/emitted from 1PPS Jun 03 09:55:24 Hmm, UART4 says it has RTS|CTS|DTR|DSR (DSR also), which signal does linuxpps hook on to? Jun 03 09:55:26 * tbr still puts bets on CTS not being muxed Jun 03 09:55:58 tbr: how can I check that? Jun 03 09:56:37 Knaldgas: how did you enable the UART? Jun 03 09:56:43 it will depend on that Jun 03 09:57:21 tbr, just loaded the overlay Jun 03 09:57:44 which one? Jun 03 09:57:46 cat /sys/devices/bone_capemgr.9/slots -> 0: 54:P---L cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial Jun 03 09:58:44 ah, so that's some special sauce cape that came with its own overlay Jun 03 09:58:55 https://github.com/lgxlogic/CBB-Serial/tree/master/overlay Jun 03 09:59:20 https://github.com/lgxlogic/CBB-Serial/blob/master/overlay/BB-UART4-RTSCTS-00A0.dts Jun 03 09:59:30 CBB serial is not enuf Jun 03 09:59:35 it only muxes rxtx Jun 03 09:59:47 av500, right - tbr is probably right then, will try Jun 03 10:00:21 ...Because the RTS and CTS pins are shared with the HDMI driver, to enable flow control for either UART4 or UART2 you must first disable HDMI... Jun 03 10:00:42 its all in the manual Jun 03 10:00:47 HDMI has alread been disabled Jun 03 10:00:49 https://docs.google.com/document/d/1sgurQ-7gLyn7g-Kg983NRM0aDkYEqHqy9dmrieX_RUM/edit Jun 03 10:01:31 Hello all Jun 03 10:01:53 Have any one used pyusb for hacking usb devices? Jun 03 10:33:58 hello all Jun 03 10:34:26 Have anyone used pyusb for hacking any USB devices? Jun 03 10:53:42 how do you hack an usb device without using an ax? Jun 03 12:16:40 hello Jun 03 12:22:51 org.bulldog.core.gpio.PinBlockedException: Pin P9_28 is currently blocked by HDMI on Pin P9_28 - (you need to disable this feature at boot time) at org.bulldog.core.gpio.Pin.activateFeature(Pin.java:376) at org.bulldog.core.gpio.Pin.as(Pin.java:164) at Test.enableGpio(Test.java:203) at Test.main(Test.java:142) PinBlockedException - org.bulldog.core.gpio.PinBlockedException: Pin P9_28 is currently blocked by HDMI on Pin P9_28 - (y Jun 03 12:23:15 getting this exception can you please sort this out Jun 03 12:23:16 ? Jun 03 12:23:21 org.bulldog.core.gpio.PinBlockedException: Pin P9_28 is currently blocked by HDMI on Pin P9_28 - (you need to disable this feature at boot time) at org.bulldog.core.gpio.Pin.activateFeature(Pin.java:376) at org.bulldog.core.gpio.Pin.as(Pin.java:164) at Test.enableGpio(Test.java:203) at Test.main(Test.java:142) PinBlockedException - org.bulldog.core.gpio.PinBlockedException: Pin P9_28 is currently blocked by HDMI on Pin P9_28 - (y Jun 03 12:24:26 anyone please help me Jun 03 12:28:50 hello anyone please help me out this ... Jun 03 12:29:30 while am trying to drive a gpio pin i got this exception "--------------------- org.bulldog.core.gpio.PinBlockedException: Pin P9_28 is currently blocked by HDMI on Pin P9_28 - (you need to disable this feature at boot time) at org.bulldog.core.gpio.Pin.activateFeature(Pin.java:376) at org.bulldog.core.gpio.Pin.as(Pin.java:164) at Test.enableGpio(Test.java:203) at Test.main(Test.java:142) PinBlockedException - or Jun 03 12:35:20 Akhil: we have all read it 3 times now. probably nobody knows. please do not repost. thank you. Jun 03 12:36:00 Akhil: respectively, have you actually read the error message? Jun 03 12:36:04 Akhil: can you read? Jun 03 12:36:08 (you need to disable this feature at boot time) Jun 03 12:36:11 ^^^ Jun 03 13:33:54 hey what's a good place for some basic example programs to run on the beaglebone black? Jun 03 13:34:12 like? Jun 03 13:34:22 im just beginning to use it Jun 03 13:34:31 so i just want to see the kind of stuff i can do with it Jun 03 13:36:18 google should have some info Jun 03 13:36:28 i mean what do you recommend for a beginner? my background is coding in c/c++ and i have some javascript experience Jun 03 13:36:34 http://beagleboard.org/project Jun 03 13:36:46 well, basically its a linux computer Jun 03 13:36:51 so you can run a lot of linux SW Jun 03 13:36:58 then it has all this hardware IOs Jun 03 13:37:04 no idea what you are into Jun 03 13:38:09 primarily i want to attach sensors to check temperature and humidity and that sort of stuff Jun 03 13:38:35 pizza: well, there is a lot on google about that Jun 03 13:39:43 thanks btw. and yes, i've been looking the past couple days and i've found some c++ programs and stuff on the beagleboard site to turn the led lights on and off lol Jun 03 13:43:18 whats not to like about turning led lights on and off? Jun 03 13:43:50 lol Jun 03 13:43:56 I can turn on the leds via shell Jun 03 13:44:45 ds2: http://paste.debian.net/196960/ <-- lsm330_acc is crapping out Jun 03 14:03:40 ive gotten up to making one led blink via shell Jun 03 14:03:43 yay Jun 03 14:05:06 anyone ever had their computer crash with a watchdog violation whenever they plug in their beaglebone? Jun 03 14:07:42 ksweens plugin where and what? Jun 03 14:08:42 PCI ? Jun 03 14:50:28 Trying to upgrade BBB to latest kernel, via /opt/scripts/tools/update_kernel.sh, but I am rebooting in 3.8.13-bone50 all the time. Also /boot/uboot/initrd.img and zImage do not seem to be updated. What am I missing? Jun 03 14:54:14 The name of the distribution your are running. Jun 03 14:58:53 DEbian Jun 03 15:01:45 Why not use Debian's pakcage manager then, apt-get? Jun 03 15:01:48 I think I started with the 2014-05-01 image, upgraded all the time via apt-get update/upgrade Jun 03 15:02:38 I did via apt-get update/upgrade, but that did give the same results: a downloaded linux in /boot but still booting the old version Jun 03 15:02:56 That is why I tried the other approach. Jun 03 15:03:00 Did you try dist-upgrade? Jun 03 15:03:10 As in, apt-get dist-upgrade? Jun 03 15:04:58 Both. I also did apt-get install linux-image-4.1.0-rc6-bone5, to get the latest (for CANbus purposes), which gave the same result: a boot folder with that specific kernel, but no update in /boot/uboot Jun 03 15:06:30 Interesting. Jun 03 15:07:29 Sounds like you need to rebuild your initrd and zImage. Jun 03 15:07:58 This is straightforward on x86/amd64, but I am unsure of the tools you need to use to do so on armhf. Jun 03 15:08:07 Best of luck! Jun 03 15:08:17 These are rebuilt, they are just not placed in /boot/uboot… Jun 03 15:09:56 So move them? Jun 03 15:10:04 Or symlink them. Jun 03 15:34:21 I'm writing my cape overlay based on circuitco BB-LCD7, when I try to load it, I get this error: https://www.irccloud.com/pastebin/zHy8d7ad/ Jun 03 16:05:09 Have any one used pyUSB to hack USB devices? Jun 03 16:05:23 I am getting an error "The device does not support the specified langid" Jun 03 16:05:37 I have no Idea what that mean :( Jun 03 16:16:13 aswin: my guess is you are trying to use a langid yhat the device does not support. Jun 03 16:16:23 wakka wakka wakka Jun 03 16:29:51 agmlego|skynet: Actually I don't have any idea about what is langids and why its necessary to use while accepting the packets from a USB device ! Jun 03 16:33:08 might be a thing one could find online. Jun 03 16:33:16 Maybe in the usb spec. Jun 03 16:40:10 Hi Jun 03 16:40:23 to All !!! Jun 03 16:40:53 am trying bbb freertos interrupt Jun 03 16:41:54 am not able to generate Jun 03 16:42:24 any one can suggest how to generate interrupt .. Jun 03 17:00:55 rcn-ee: https://www.irccloud.com/pastebin/zHy8d7ad/ Jun 03 17:12:24 I've got the Gaming Cape reporting back most of the sensors via /dev/input/{event,js}* now. Jun 03 17:12:54 I've also got the buttons sending BTN_LEFT and BTN_RIGHT events... Jun 03 17:13:22 but, I'm not sure how to get the joystick (AIN0/AIN2) to move the mouse on X11 or the buttons to be left and right clicks. Jun 03 17:13:31 ds2: any thoughts from you? Jun 03 17:19:27 don't think there is any recent dev for joystick support in X Jun 03 17:19:46 you might have to write a simple driver that reports it as mouse events Jun 03 17:19:58 have a look at inputattach Jun 03 17:20:10 you can do that in userland if you wish via the uinput stuff Jun 03 17:20:29 ogra_: those are raw ADCs... need an input device for inputattach, right? Jun 03 17:21:02 hmm, i forgot ... it is years ago i touched it ... Jun 03 17:21:37 iirc it creates a /dev/input device for exotic char devices Jun 03 17:25:21 * jkridner has seen ways to do AIN0/AIN2 -> mouse via uinput, but I don't want to do that. Jun 03 17:25:37 * jkridner googles inputattach Jun 03 17:27:04 that sounds like it is using uinput Jun 03 17:27:30 If I understand uinput, I'd make a userspace prog to feed back in the input. Jun 03 17:29:10 I've gotten 'xinput' to report the button status. Jun 03 17:29:27 I added some xorg.conf entries to load a driver for the evdev. Jun 03 17:30:40 http://paste.debian.net/197540/ Jun 03 17:31:34 yes Jun 03 17:31:55 a userland driver for a /dev/input/eventXXX device Jun 03 17:36:11 :( Jun 03 17:36:37 inputattach -bare /dev/input/event4 -> inputattach: can't set line discipline Jun 03 17:37:21 if event4 shows up as a mouse in X, why would I need a userspace driver? that seems like it might only be necessary for the AIN stuff. Jun 03 17:39:13 DISPLAY=:0.0 sudo -u debian xinput query-state 16 --> http://paste.debian.net/197543/ Jun 03 17:39:30 If the button is pressed, it says down. Jun 03 17:46:30 330 gyro? heh Jun 03 17:46:37 seems like there is an extra accel Jun 03 17:46:54 i dont think inputattach will do what you need Jun 03 17:46:59 bbl Jun 03 17:47:02 k Jun 03 17:51:09 Hi,I am a beginner. I want to do some linux kernel related work. How can i contribute? Jun 03 17:52:01 roni__: Find something lacking, and fix it. Jun 03 17:58:18 rcn-ee: ping again Jun 03 18:00:33 Abhishek_, pinctrl-single 44e10800.pinmux: pin 44e10850 already requested by rstctl.4; cannot claim for panel.15 looks like you have a pin somewhere it shouldn't be.. Jun 03 18:13:59 rcn-ee: stripped down the dts, getting this and no display yet https://www.irccloud.com/pastebin/6KOmsuET/ Jun 03 18:14:51 rcn-ee: This is the dts https://www.irccloud.com/pastebin/AqT3Hpxj/ Jun 03 18:36:59 Abhishek_, something in your base *.dtb is already taking up one of the pins.. Jun 03 18:37:26 rcn-ee: But the original LCD7 cape loads fine! Jun 03 18:37:53 why does recompiling it mess it up? Jun 03 18:40:08 Abhishek_, which version of dtc? Jun 03 18:40:31 Version: DTC 1.4.1-g3e538ba1 Jun 03 18:40:52 compiled the latest yesterday Jun 03 18:40:57 so the one for v4.1.x Jun 03 18:41:11 oh Jun 03 18:41:26 so downgrade? Jun 03 18:41:39 if your using 3.8 use: https://raw.githubusercontent.com/RobertCNelson/tools/master/pkgs/dtc.sh Jun 03 18:42:35 i figure'd they would be in-compatible, thus i didn't push the new one to the deb repo yet.. Looks like you proved that. ;) Jun 03 18:44:40 * Abhishek_ grunts like a guinea-pig Jun 03 18:44:46 :P Jun 03 18:49:02 rcn-ee: It'd be nice if it is documented somewhere Jun 03 18:49:07 maybe the wikis? Jun 03 18:49:48 i'll document it... if that fixes your problem. ;) Jun 03 18:50:25 we have display, again :) Jun 03 18:51:11 rcn-ee: see: https://www.irccloud.com/pastebin/rg0t7EoY/ Jun 03 18:51:55 * Abhishek_ moves to fixing display timings now Jun 03 18:52:08 Abhishek_, https://github.com/beagleboard/bb.org-overlays/commit/56390f91e6e1977e3829af638075845dd70c44aa Jun 03 18:53:25 rcn-ee: I believe that the dts's in these use gpio0..3 and 3.8.x use gpio1..4, correct? Jun 03 18:53:47 WHOA... and suddenly a 12-message patch set appears in my inbox since I was Cc'd o.o Jun 03 18:54:24 Abhishek_, 3.8.x is eol.. ;) Jun 03 18:54:54 rcn-ee: where's Jessie ;) ? Jun 03 18:55:04 how many bugs left now? Jun 03 18:55:05 She got lost. Jun 03 18:55:28 I thought maybe bugs have made her lose health Jun 03 18:55:34 Abhishek_, it got released, weekly snapshots here: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots Jun 03 18:55:49 Abhishek_: TI uses inconsistent mixes of 1-based and 0-based indexing (in both docs and code, there may disagree with each other and/or with closely related devices).... using consistent 0-based numbering is much better for one's sanity (and something I also do in my own notes/docs/spreadsheets) Jun 03 18:56:37 I see Jun 03 18:57:02 * Abhishek_ will move to 4.x only when BeagleLogic does as well Jun 03 18:57:13 or Jessie is stable enough Jun 03 18:57:22 Jessie is stable. Jun 03 18:57:34 and 3.8.x is in jessie.. Jun 03 18:57:59 jkridner: The last Jessie image I installed, I disabled HDMI but there was still more CPU usage I remember... Jun 03 18:58:44 Abhishek_, how many weeks ago was that? we've been averging updated kernels every week and the lxqt guys fixed a couple cpu hogs.. Jun 03 18:58:57 rcn-ee: How does one disable HDMI in Jessie images? If that's good I might give it a shot again Jun 03 18:59:24 that was 1W/2W May Jun 03 18:59:28 IIRC Jun 03 19:01:06 * Abhishek_ wants to upgrade BeagleLogic from Wheezy Jun 03 19:01:22 jkridner, cape-universal overlay now works on 4.1.x: https://github.com/beagleboard/bb.org-overlays/commit/ef1a7a2808de388b12bd2461e5069234b2ce2fa1 Jun 03 19:01:47 just make sure to update config-pin ;) https://github.com/cdsteinkuehler/beaglebone-universal-io Jun 03 19:15:55 Hey Guys Jun 03 19:16:43 I am planning to buy Beagle bone for learning more about embedded linux and need help to choose between beaglebone and beagle bone black Jun 03 19:16:53 Buy the black. Jun 03 19:17:03 The original one is deprecated and expensive. Jun 03 19:18:01 ok got it.. thanks for quick response Jun 03 19:20:18 the bb is better in several ways but you need to buy an external active serial cable to get into the debug console Jun 03 19:20:26 the bbb Jun 03 19:21:12 If you need debug prior to the kernel being loaded. ;-P Jun 03 19:42:25 ds2: If the display appears shifted to the right, which LCD timing parameter should I touch? Jun 03 19:47:01 back porch I guess? or possibly hsync Jun 03 19:47:23 hmm, back porch seems to be working but I think I over-corrected Jun 03 19:47:55 keep in mind that (iirc) those parameters are in units of 16 pixels Jun 03 19:51:29 also it's worth reading the Freon/Primus (OMAP-L1xx / AM1xxx / C674x) TRM chapter on the LCDC: it is a slightly older version, but explains some stuff in more detail Jun 03 19:52:47 it also cleared up confusion I had about the number of ditherer levels (turns out this changed from 15 in Freon/Peimus to 16 in Subarctic, but not all occurrences in the docs were correctly updated) Jun 03 19:54:11 e.g. whereever you see the number "3375" mentioned (15^3), read it as 4096 (16^3) instead :P Jun 03 19:55:06 zmatt: What's the best way to ensure that these timings are perfect correspondence to my display? Jun 03 19:55:22 I mean, to check if porch values are correct? Jun 03 19:55:41 Abhishek_, find the datasheet. ;) Jun 03 19:56:10 rcn-ee: The datasheet values give bad display lol :P , Playing with the values manually to find the sweet spot Jun 03 19:56:14 sorry, I have no actual experience with LCD displays Jun 03 19:56:28 thanks for the pointers :) Jun 03 19:57:05 Abhishek_: double-check all units (e.g. are they in 1 pixel, 16 pixels, something else), and definitions Jun 03 19:58:59 Abhishek_, make sure you are reading this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/video/display-timing.txt Jun 03 19:59:14 Abhishek_: but in general, changing the back porch should move your displayed video horizontally, unless the display also reacts to the changed hsync interval.... in that case changing the front borch by the same amount in the opposite direction will ensure your video *will* shift horizontally, since the display controller wouldn't even know Jun 03 19:59:19 *the display Jun 03 20:00:25 ah d'oh, I sometimes keep forgetting when people ask questions about peripherals, they (generally) mean the Linux driver for those peripherals Jun 03 20:01:42 rcn-ee: That was helpful, thanks :) Jun 03 20:02:06 it has pretty picture, then lcd datasheets can atleast be decoded. ;) Jun 03 20:04:27 (random fact that's not really stated explicitly anywhere I think: during sync and blank periods, the data lines are not necessarily zero: they hold the value of the last (valid) pixel Jun 03 20:04:31 ) Jun 03 20:07:17 rcn-ee: btw did you know /dev/mem (with DSYNC flag) is mapped not as device-memory but as strongly-ordered? o.O Jun 03 20:09:02 zmatt, for the lcd? Jun 03 20:09:25 /dev/mem in general Jun 03 20:09:30 uio also Jun 03 20:09:45 rcn-ee: Using the table, the timing fits perfectly Jun 03 20:09:53 (datasheet timings) Jun 03 20:09:58 but... do they work? ;) Jun 03 20:10:21 (unlike normal device drivers, which do not even have the option of asking for strongly-ordered mappings via ioremap() ) Jun 03 20:10:50 so that immediately explains why the CPU turned out the bottleneck in my userspace tests of the AES accelerator Jun 03 20:35:36 rcn-ee: https://hackaday.io/project/4410-yet-another-beaglebone-displaycaptouch-cape/log/18960-more-display Jun 03 20:35:41 jkridner: ^ Jun 03 20:37:30 nice! Jun 03 20:38:14 for the ft5306, either use 3.14.x/4.1.x there's a bit to backport. ;) Jun 03 20:38:35 the bbb-exp-c has that same cap touch ic.. Jun 03 20:38:43 so steal those dt's ;) Jun 03 20:39:21 rcn-ee: btw, do you have any idea what the status is of power management in mainline (or your linux-dev repo) Jun 03 20:40:00 zmatt, i know the suspend-via-cortex-m3 firmware should 'hit' 4.2... ;) Jun 03 20:40:40 just finished adding the hdmi stuff, should look into the wkup-m3 driver again.. ;) Jun 03 20:40:50 that thing is icky Jun 03 20:41:03 the concept is nice though Jun 03 20:41:05 hdmi>hdmi-audio Jun 03 20:41:22 but I meant more things like dynamic frequency management than suspend Jun 03 20:41:35 that should be working? Jun 03 20:41:38 rcn-ee: hi there, did you get a chance to test CWVW? Jun 03 20:41:54 cpufreq-info is showing fun stuff.. Jun 03 20:42:34 cityLights, sorry not lately (it worked when i last tested it on atheros chipset at home), just been hacking on dt/overlays for v4.1.x Jun 03 20:42:36 okidoki, because I noticed my kernel with my dtd has considerably higher consumption than the 3.14-ti kernel I tied, but during heavy activity they are roughly equal again Jun 03 20:43:06 yeap, that's the low state... Jun 03 20:43:12 the m3 driver should fix that. ;) Jun 03 20:43:23 thanks, please let me know what i need to do to get it in to your repo Jun 03 20:43:39 ok so what I'm seeing there is the actualy m3 involvement to briefly power stuff down Jun 03 20:44:32 that's the one.. nasty little core.. its' the only thing running in cpuidle states.. Jun 03 20:44:44 nothing wrong with the m3 :P Jun 03 20:45:41 and I also really like the concept of the synchronization interlock (prcm signalling m3 when a8 has succesfully entered idle state) Jun 03 20:45:54 yeah nothing wrong with it. .(better then the omap3's method), it was fighing with cpuidle to cause this bug; http://bugs.elinux.org/issues/137 Jun 03 20:45:58 the code itself looked.... TI. Jun 03 20:47:13 I've also heard of someone who had frequent brief wakeups (CAN-related) and ended up with the A8 running in bypass mode than pll-locked Jun 03 20:47:27 <_av500_> every night I have brief wakeups Jun 03 20:47:31 <_av500_> they are not CAN related Jun 03 20:48:16 rcn-ee: it mostly sucks the M3 can't access the L3, otherwise it could have served far more versatile duties Jun 03 20:51:31 rcn-ee: Where's the DTO for BBB_EXP_C? Jun 03 20:54:23 (or at least not without ugly hacks... I suppose you have the A8 reserve a QDMA channel + some unused hw dma that the M3 can somehow trigger in software (seems likely there is one), and configure the normal DMA (statically) to transfer the QDMA parameters from M3 EDMA transfer copies the QDMA transfer info from M3 memory to the EDMA CC) Jun 03 20:55:09 the M3's latency to targets outside the L4WKUP would be a bit high-ish, but it would have excellent throughput ;-) Jun 03 20:56:22 Abhishek_, https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1.x/src/arm/am335x-cape-bbb-exp-c.dtsi#L73 Jun 03 20:57:12 rcn-ee: I think I saw the edt-ft5x06 module on the 3.8.13 kernel, is there something amiss in it? Jun 03 20:57:22 zmatt, it'll be interesting on the am57x, as we get two m4's to play with. ;) Jun 03 20:57:42 rcn-ee: four Jun 03 20:57:47 rcn-ee: two instances of Benelli Jun 03 20:58:20 true, thought they were going to try and hide the video one. ;) Jun 03 20:58:32 (same as the Ducati subsystem instantiated on the omap4 and dm81xx systems, except with the M3 cores ripped out and replaced by M4) Jun 03 20:58:51 memory management there is.... interesting though Jun 03 20:59:37 rcn-ee: I have the FT5306 plug in to the cape EEPROM bus that runs on 100kHz, any hints if I could get it running at 400 kHz Jun 03 21:00:30 I have code running on an M3 on our dm814x board, although I was still pondering the best strategy of dealing with both of them Jun 03 21:00:56 since apart from the PPB, they are identical memory views Jun 03 21:01:01 *have Jun 03 21:02:14 even though there's not one but *two* MMUs in the subsystem stacked after each other (the first mandatory and really weird, the second optional and ARM-like), but those already lie after the unification of the M3 buses Jun 03 21:03:42 the best strategh well-supported by toolchains would be to view the two CPUs as two threads of a single process Jun 03 21:04:40 Abhishek_, it running at 400KHz just fine on the bbb-exp-c, it shoudl be fine. Jun 03 21:06:17 but I hate threads, I tried to see if the (PalmOS I think?) strategy for MMUless multitasking with shared libs could be made to work (task-private data in a separate section which is kept in a dedicated register) Jun 03 21:07:48 but I never got around to digging into it much before the project got shelved Jun 03 21:08:43 (there's -msingle-pic-base, but I actually don't want PIC... the code addresses are known as compile time, it's just data that requries care) Jun 03 21:20:36 rcn-ee: btw, what I meant with really weird (L1) MMU: it does no table walking but has a fixed number of entries, specifically: four "large" pages, which are either 512 MB or 32 MB (can be selected per page), two "medium" pages which are 256 KB or 128 KB, and ten "small" pages which are 16 KB or 4 KB Jun 03 21:23:43 (and those weird counts/values are not some kind of side-effect of how the mmu works internally: the same MMU is instantiated a second time in omap4's "Tesla" subsystem, but there you have: 8x large (512 MB or 256 MB), 7x medium (1 MB or 128 KB), 3x small (32 KB or 4 KB) ) Jun 03 21:27:24 it's almost like they got lazy with the silicon.. Just limit it to a list of options and call it good.. Jun 03 21:28:38 someone actually *chose* these values Jun 03 21:28:52 presumably for a reason Jun 03 21:29:03 (not a reason worth putting in the docs apparently) Jun 03 21:29:29 wonder if it was from the tesla video codec people? so the reason is all ip locked up... Jun 03 21:29:52 it's not really locked up Jun 03 21:30:29 the documentation is mostly just mediocre, it fails to explains some terms and what exactly happens under this or that circumstances Jun 03 21:30:59 it also uses non-standard terminology, I suspect coming from the (equally undocumented) VBUS protocol family Jun 03 21:32:35 like this page bit: Jun 03 21:32:52 3 VOLATILE volatile qualifier, see policy matrix Jun 03 21:32:52 0x0: do not follow volatile qualifier Jun 03 21:32:52 0x1: follow volatile qualifier Jun 03 21:33:07 (no, there's no "policy matrix" anywhere of course) Jun 03 21:37:09 I wonder if they licensed it from a third party, since it "feels" very unlike other TI peripheral register interfaces Jun 03 21:38:17 (it's usually easy to spot a peripheral that's "out of place"... like the PWMSS modules of the AM335x, which are in fact ported from TI's C2000 real-time microcontroller series) Jun 03 21:44:20 (lovely btw that Tesla has been declared an obsolete architecture and support dropped in the latest compiler series) Jun 03 21:45:04 they supported it? ;) Jun 03 21:45:15 -mv c64t Jun 03 21:45:49 afaik the only documentation of its instruction set is... compile code, see what it outputs Jun 03 21:47:27 but I can't blame them from dropping it, Tesla probably required special-cased handling all over the compiler Jun 03 21:48:38 still, listing it as an "obsolete" architecture while even the omap543x still has an instance seems a bit... harsh Jun 03 21:59:15 rcn-ee: What does this mean: [ 55.352004] edt_ft5x06 1-0038: no platform data? Jun 03 22:00:58 Abhishek_, sounds like it's pre-dt... time to backport ;) Jun 03 22:06:03 rcn-ee: Indeed, the files are different Jun 03 22:10:46 rcn-ee: Is backporting gonna break compilation? Jun 03 22:11:35 Abhishek_, it depends. ;) Jun 03 22:12:13 using meld, start with 3.9.0 and compare that driver... keep working your way up and testing, till it works. ;) Jun 03 22:12:41 btw, at some point before 3.14.x that driver was renamed.. ;) Jun 03 22:19:56 * Abhishek_ doesn't have a kernel source tree / build system set up yet Jun 03 23:14:15 Hello, the RTEMS support for Beagle boards is expanding with GSoC and general interest. On the tools side of things the RTEMS BB maintainer is asking to add support for qemu-linaro. I am just wondering if the BB support in that version of qemu has been upstreamed to the main qemu project and if anyone here has any info regarding what is happening here ? Jun 03 23:15:02 kiwichris: good question. have you tried looking at the upstream repo and diff'ing them? Jun 03 23:15:30 jkridner, haha, watch qemu patches is a full time job :) Jun 03 23:15:57 fair enough, but the repo should be diff-able. Jun 03 23:16:04 jkridner, if we are not sure I think we will have to do this. Jun 03 23:16:58 If the patches are upstream and in qemu's patchworks we can directly build them into our qemu. We just need a list of patches. Jun 03 23:18:31 If I have to we can support qemu and qemu-linaro but I would rather not have to do this because it adds a layer of complexity to our users, eg a Zynq qemu is not the linaro one etc Jun 03 23:47:07 jkridner: do you care to keep the ADC or TSC functionality for that kernel? Jun 03 23:47:35 yeah..., but it can be dt configured one way or the other. Jun 03 23:47:50 you want one kernel to do it all? Jun 03 23:48:10 if you can give up ADC functionality, I can bang out a driver for you in an hour two Jun 03 23:48:13 yeah... trying to make mods to a stock kernel. Jun 03 23:48:21 coordinating is trick Jun 03 23:48:23 tricky Jun 03 23:48:34 yup... Jun 03 23:48:50 again, duplicating the driver and making it either/or loaded would be fine. Jun 03 23:49:06 but, 'config-pin overlay BB-ADC' has to continue working. Jun 03 23:50:04 is a recompile acceptable? Jun 03 23:50:11 i.e. CONFIG_ADC_JS Jun 03 23:50:22 duplicating drivers adds other complexities Jun 03 23:51:13 nope. :( Jun 03 23:52:02 fine.. userland it is Jun 03 23:52:44 you want it to appear as a linux joystick device or a mouse or ? Jun 03 23:54:18 well... ultimately, I want it to show up in X as a mouse, but I think the best way is to have it be a joystick and use the joystick X driver. Jun 03 23:54:47 it is easy enough to do either Jun 03 23:55:56 joystick makes the most sense, since it is a joystick. Jun 03 23:56:07 with some "deadzone" Jun 03 23:56:27 ah okay Jun 04 00:03:01 jkridner, here is the post and response from Nov last year ... https://lists.linaro.org/pipermail/linaro-dev/2014-November/017614.html Jun 04 00:06:14 * jkridner heads to #linaro to ask Jun 04 00:09:44 jkridner, thanks Jun 04 00:10:33 kiwichris: will I see you there? Jun 04 00:11:02 Sure Jun 04 01:20:07 /proc/bus/input/devices Jun 04 02:42:45 go ahead **** ENDING LOGGING AT Thu Jun 04 02:59:58 2015