**** BEGIN LOGGING AT Wed Apr 29 02:59:59 2015 Apr 29 07:05:08 Hi! Apr 29 07:06:02 It seems like the pinout of the audio expansion header in the Beagleboard-xM SRM is not correct. Who should i tell this? Apr 29 07:07:58 manta good question Apr 29 07:09:22 manta try to write it to Jason Kridner Apr 29 07:10:23 manta: please write on the mailing list Apr 29 07:10:25 cc jason Apr 29 07:11:34 okay. thank you Apr 29 07:13:34 gm av500 Apr 29 07:13:56 gm woglinde Apr 29 07:39:27 morning Apr 29 07:40:11 +1 Apr 29 07:41:49 bizarre that the 3.3v-staying-on-issue on battery power has remained unsolved for a year and a half (with mostly just silly speculation about pmic settings) when the cause was so obvious... Apr 29 07:41:55 * zmatt just finished a loong forum post Apr 29 07:44:03 so, anyone who wants to know more about the power up/down sequences of the BBB (including pretty pictures) -> http://goo.gl/GQU5Cc Apr 29 08:14:32 zmatz so it is a hardware problem Apr 29 08:18:03 of course it's a hardware problem... it's strange that people were actively toying with pmic settings when the offending regulator that stayed on was a discrete regulator, not one of the pmic Apr 29 08:19:58 none of the regulated pmic supplies stay on in off-mode, regardless of its settings Apr 29 08:21:17 ("When transitioning from ACTIVE to OFF state, any rail not controlled by the sequencer is shut down after the power-down sequencer has finished.") Apr 29 08:22:17 the whole 3v3a/3v3b split is simply a mess Apr 29 08:22:43 I think there will be no new revision Apr 29 08:22:49 but lets see Apr 29 08:23:32 an external circuit that cuts the battery when entering OFF mode (as detected by 1.8V being cut) seems the easiest workaround Apr 29 08:27:37 I don't think battery-powered applications are considered a priority at all Apr 29 15:55:10 the wanderer returns ;P Apr 29 15:55:33 aimlessly... Apr 29 16:13:29 dont' we all!? :P to some extent or another ... Apr 29 16:13:38 we've missed ya :p Apr 29 16:25:34 * KotH wonders what happend to the_wanderer Apr 29 16:29:03 (link to same post I linked to earlier but this one *without* the fumingly annoying iframe -> http://goo.gl/TjnRzN ) Apr 29 16:31:32 I wish the link on the homepage would just link to google groups rather than the weird iframe-embedded thing which is really a pain to use Apr 29 16:34:47 zmatt: danke vielmals! Apr 29 17:01:07 In case anyone was following my attempt to get tilcdc to turn on an LCD with cpufreq set to performance, I've managed to hack it into working with this patch: https://gist.github.com/6959c40db37d6015e220 Apr 29 17:01:21 It almost certainly isn't the right fix, but it'll work for now. Apr 29 17:01:55 <_av500_> looks not too shabby Apr 29 17:01:59 <_av500_> ship it! :) Apr 29 17:02:38 _av500_: you say that as if it's a joke :) Apr 29 17:18:31 hello all Apr 29 17:20:28 I am having a problem with a compiled kernel (3.14.39), and a cape from Chipsee, the BBB-EXP-C. Unfortunately on boot the display is not showing up. The rest of the shield seems to work, however. Apr 29 17:22:02 The cape uses a 24-bit parallel connection with the BBB to output onto a screen. Wondering if anyone knows how I can check those pin statuses on a newer kernel to make sure my dtb is actually working Apr 29 17:22:08 el_ws1, did you follow? http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Chipsee_bbb-exp-c Apr 29 17:22:21 I followed https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SerialLogin Apr 29 17:22:40 Ahh, yes. I added dtb= to my uEnv.txt Apr 29 17:23:31 And my xorg.conf has defaultdepth 24 Apr 29 17:24:12 you should also see the pengiun... give me a moment to double check.. Apr 29 17:24:21 Yeah, that was my first clue I got something wrong Apr 29 17:24:52 AFAIK that penguin is something that u-boot should output, is this correct? Apr 29 17:25:24 nope kernel.. Apr 29 17:26:39 it would be pretty bad if u-boot displayed anything on screen since 1. it's already bloated enough 2. those pins may be used for a different purpose than video output Apr 29 17:26:52 Good point. Apr 29 17:27:33 Well, I am new to the ins and outs of this, so I'm not surprised I have some wrong ideas :P Apr 29 17:27:40 there's a da8xx/am335x fb driver in u-boot...... Apr 29 17:27:44 i don't enable it.. Apr 29 17:28:05 rcn-ee: I know, that doesn't mean it's a good thing :P Apr 29 17:28:06 I think that's how the chipsee guys do it in their custom kernel Apr 29 17:28:30 Which is the type of thing I was specifically trying to avoid, using that custom kernel. It's my fallback though. Apr 29 17:28:54 rcn-ee: u-boot does some inappropriate muxing anyway I think, I was still planning to look into that Apr 29 17:29:14 zmatt, for x15, we are doing all pinmuxing in u-boot.... Apr 29 17:29:27 rcn-ee: it parses the device tree? Apr 29 17:29:38 billh, installing 3.14.39-ti-r61, i have the chipsee in the lab today.. Apr 29 17:29:48 zmatt, nope... per board cfg.... Apr 29 17:29:53 OK, so I did something wrong then, not that surprising. Apr 29 17:30:05 That's the same version I have, let me double check Apr 29 17:30:12 Yup Apr 29 17:30:23 Based off of your ti-linux-kernel-dev repo Apr 29 17:30:25 billh, with v3.14.x we have patches coming in all over, so a regression is possible.. Apr 29 17:30:41 rcn-ee: joy... I hope someone makes a tool that lets you define the stuff you want to use and generates appropriate config files for u-boot, kernel, device-tree, etc Apr 29 17:30:56 rcn-ee: it's because of the iodelay thing right? Apr 29 17:33:10 zmatt, iodelay = exactly.... ti is working on a tool for that.. Apr 29 17:33:27 billh, works here... first is there any "glow" to the screen? like the backlight came on? Apr 29 17:33:46 (is the led on the lower right) pulsing? Apr 29 17:34:15 Yes, I can play with the gpios, the buzzer Apr 29 17:34:17 no backlight Apr 29 17:34:27 zmatt, it's also, we don't want a capemgr situation.. ;) Apr 29 17:34:40 rcn-ee: TI should fucking publish the relevant data in machine-readable format. Like with the AM335x you're supposed to abide by those "io-set" constraints, but they're documented nowhere and their only tool is windows-only and horrid to use Apr 29 17:35:11 FWIW, touch events work Apr 29 17:35:14 so I know my i2c is ok Apr 29 17:36:10 zmatt, yeah it is.. (i have a windows vm just for that software), last i heard from ti, there was internal pressure for a linux tool... Apr 29 17:37:54 rcn-ee: not just a linux version of that tool, something scriptable. you want to be able to made a utility that merges cape constraints and/or end-user requests for certain peripherals, figures out a solution (if any), and configures your system for it Apr 29 17:38:02 *to make Apr 29 17:38:31 it is totally doable... but you do need the data Apr 29 17:38:48 That would be incredibly usefu Apr 29 17:39:10 billh, do you have /sys/class/backlight/backlight.25/ dir? Apr 29 17:39:42 rcn-ee, /sys/class/backlight/backlight.24 Apr 29 17:40:08 fancy general-purpose constraint-solvers exist, you just need to pour the data into the right format, and format the solution into config files Apr 29 17:40:24 the number shouldn't matter... in that there should be a "actual_brightness" what's it's value? Apr 29 17:41:03 cat reveals its value to be 1. Out of curiousity, what does the number mean? Apr 29 17:41:22 1 should be on.. Apr 29 17:41:31 it's a gpio toggle.. 0/1... Apr 29 17:41:48 Sorry, I meant the backlight.* number Apr 29 17:42:23 it's part of the device tree probe order... Apr 29 17:42:51 Ah, okay. Apr 29 17:44:15 And I can change it, but it has no effect. Given my limited knowledge, this to me sounds like my pinmuxes aren't right. Apr 29 17:44:37 i wonder if they changed someting.. Apr 29 17:44:50 KotH: I just realized I might have stumbled over what could very well be the main culprit of 3v3b -> 3v3a leakage... gonna test that when I'm at work again Apr 29 17:46:10 For reference, this shield was bought mid last year Apr 29 17:46:15 billh, pretty much all the lcd's use this pin (as it's also pwm capable, just not pwm working in v3.14.x yet) https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-bbb-exp-c.dtsi#L119 Apr 29 17:47:17 rcn-ee: I got pwm working from userspace, piece of cake Apr 29 17:47:32 OK, I will throw that in my dtbs after compiling. Note that I changed two things in there, 1) I removed the i2s stuff 2) I added pinmuxes for i2c2 Apr 29 17:47:33 (we use it for an RGB led) Apr 29 17:47:43 zmatt: +1 Apr 29 17:48:21 zmatt, yeah from userspace... i meant the "pwm-backlight" driver... it's had some issues, but should be working in v4.0.x... ;) Apr 29 17:49:43 (those offended by use of /dev/mem can even use the uio driver... I've confirmed it works. You'd still need to use /dev/mem to enable the pwm timebase clocks in the control module, but that can be done by a tiny util at boot or something) Apr 29 17:50:42 rcn-ee: ah Apr 29 17:51:35 Also, quick question to those more familiar with the TTL serial output workings of the BBB; Anything off the top of your head that would cause characters from BBB-> computer to disappear through a TTL-USB cable Apr 29 17:52:19 rcn-ee: I'm using increasingly less kernel drivers to be honest... they're often buggy and/or feature-incomplete, and are basically just useless overhead when a userspace process wants to directly work with a peripheral Apr 29 17:52:21 To be a little more precise, it looks like i'm losing some of my boot info. Not the hugest deal but it would be helpful to fix to diagnose the chipsee Apr 29 17:52:38 on the chipsee... possibly the mux.... did you remove that resistor? Apr 29 17:53:56 (of course some things really do need management by the kernel, but also plenty of peripherals don't in many use cases) Apr 29 17:54:16 no - I have the schematic open though, which resistor do you speak of? Apr 29 17:54:44 zmatt: do you know off hand if the 3V3B regulator is in a package that will let you experiment with its enable signal? Apr 29 17:55:00 ds2: I know someone successfully patched it Apr 29 17:55:11 so apparently yes Apr 29 17:55:39 it's a pretty big DIP actually Apr 29 17:55:43 billh, R80/81? i remember reading something in chipsee's documents that unless you removed a few resistors, you were suppost to use COM0 vs the P13 ftdi connector... Apr 29 17:55:51 good, as long as it ain't a BGA Apr 29 17:56:25 Interesting, I missed that little tidbit. I'll check that out and add it to my guide. Apr 29 18:00:19 humm, it's not in the main pdf... i swear i remember reading something odd about how they wired up COM0/P13.. Apr 29 18:01:03 Do you know if that TTL serial header goes out to P8/P9 anywhere? Apr 29 18:01:35 it goes to the debug usart... Apr 29 18:03:06 ds2: 1.27 mm pin spacing even... the package is 4 by 5 mm Apr 29 18:03:21 it's like, HUGE Apr 29 18:03:37 you can almost rework it with a $2 soldering iron! Apr 29 18:03:40 how many pins? Apr 29 18:03:45 8 Apr 29 18:04:25 i like your idea about running it from power_good Apr 29 18:04:37 it has the biggest pin spacing of all DIPs on the BBB Apr 29 18:05:02 ds2: seems sanest Apr 29 18:05:38 ds2: btw, do you happen to know if there's any convenient measurement point for the 3V3A ? Apr 29 18:05:48 hmm, I suppose the 3v3b regulator may actually be Apr 29 18:07:36 zmatt: not off hand... I been battling problems with it running... not quite at the point where I want to stop it ;) Apr 29 18:08:04 for most boards, I have a jumper/slide switch on the battery Apr 29 18:08:50 if you're in a position to easily try: just for fun, try shutting down while pulling the serial console line to ground Apr 29 18:09:29 while on battery, that is Apr 29 18:09:35 what should that do? I'd need a normal kernel to try stuff like that Apr 29 18:09:51 not sure if shutdown works right in the kernel I am using Apr 29 18:10:09 hold on, I have the right u-boot i2c commands for entering off-mode in a text file Apr 29 18:10:24 oh right Apr 29 18:10:28 that won't work Apr 29 18:11:30 actually, driving the console low *after* shutdown would also be a valid test... but nm it's a fuss, I'm gonna try it with a scope attached so I can see how much difference it makes Apr 29 18:12:12 since I'd been wondering who on the 3v3b is driving all that current into the 3v3a domain... most signals in that direction are idle-low or open drain Apr 29 18:13:04 but the isolator/level-shifter for the serial console is 3v3b-powered, and will drive a hard 1 into the cpu Apr 29 18:13:56 it would be rather ironic if it's responsible for driving current into the cpu while powered down, since its intended purpose is to prevent exactly that Apr 29 18:15:13 but I haven't carefully analyzed everything powered by 3v3b yet, there may be other culprits Apr 29 18:29:10 *nod* Apr 29 18:29:26 your post was one of the more interesting things to come by the list in a while ;) Apr 29 18:29:33 bbl Apr 29 18:30:31 thanks :) Apr 29 18:43:40 Hey guys, what's the best way to figure out if a dt file has actually been loaded? Apr 29 18:57:28 rcn-ee, looking back in my kernel build folder, my bone-bbb-exp-c is identical to the dtsi you linked, with the exception of me adding a i2c2 section and removing the mcasp0 Apr 29 18:58:35 And given that dmesg shows that I am initializing i2c2 with the speed I specified, I think I can assume that at least some parts of the device tree are properly loading Apr 29 19:00:01 rcn-ee: any hint on Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fe8c60 ? i am running 3.14.39-ti-r56 Apr 29 19:00:32 I'm using the latest jessie console image (4-26) but I can't enable the SPI, UART, or IIO (ADC) Apr 29 19:00:39 is there a new way of doing that? Apr 29 19:00:52 vvu: that's a misleading and useless message from the kernel: it means "bus error" and gives the virtual address rather than the physical address, making it completely useless Apr 29 19:01:22 ah so i should not care about it, well hope stuff will run ok :) Apr 29 19:01:32 vvu: ehh Apr 29 19:01:36 vvu: it is a real error Apr 29 19:01:46 the message is just useless for identifying the error Apr 29 19:02:18 it typically means an attempt to access a peripheral that's not been enabled Apr 29 19:07:58 any way to figure out what order the kernel walks the device trees? Apr 29 19:11:11 I get the feeling from google that /sys/kernel/debug is the place to Apr 29 19:20:59 billh, other then a message from u-boot, that i stuck in their... you never really know which "dtb" is loaded. ;) Apr 29 19:21:50 I figured it would be something like that Apr 29 19:22:05 jg_, if down grade to v3.8.x you can use all the capemgr options. Apr 29 19:22:44 rcn-ee is there a way to enable the iio, pru etc in jessie? Apr 29 19:22:58 rcn-ee, the one thing I changed between your copy of the device treee and mine was the removal of the i2s audio stuff and the addition of the spidev1 dts Apr 29 19:23:23 jg_, ui_pru is now working on v4.0.x.. Apr 29 19:23:28 I don't think that's the issue here though, which is unfortunate Apr 29 19:23:41 I am about to try another Chipsee shield Apr 29 19:23:49 It is entirely possible I have nuked this one inadvertently Apr 29 19:24:00 jg_, you'll probally just want to downgrade first: sudo apt-get update ; sudo apt-get install linux-image-3.8.13-bone71 ; sudo reboot.. Apr 29 19:24:34 billh, does the un-mofied version work? Apr 29 19:24:48 No problem... I can reflash back to wheezy.... Apr 29 19:24:58 I'll try it again with the new cape and report back. Apr 29 19:25:15 But with the cape I have, no. Apr 29 19:25:16 jg_, it's the same kernel as in wheezy... Apr 29 19:25:18 rcn-ee: i am trying to build 3.14.35-ti-r56. i checked out at the commit when when you changed the kernel version but the patches fail to apply https://gist.github.com/ungureanuvladvictor/026ca7fe0168648579f2 Apr 29 19:25:30 does that work, to build an older version of the ti-kernel ? Apr 29 19:25:37 rcn-ee gotcha.... ok Apr 29 19:25:44 or the patches are just for the latest version Apr 29 19:26:34 rcn-ee: just wondering is it because jessie is still under development which is why I can't access the iio, spi, uart, etc? Apr 29 19:27:10 vvu, if you want to base it on a specific version, you'll need to use the tag from: https://github.com/beagleboard/linux/tree/3.14.35-ti-r56 Apr 29 19:27:40 vvu, ti's doesn't tag their tree... so... we never really have a "non-changing" tree to base on it .;) Apr 29 19:27:48 ok, let my try Apr 29 19:28:53 rcn-ee, Just to make sure I have all the parts I need, I need to recompile my dtbs and get them into my rootfs, install some sort of X (LXDE), and make sure I have an xorg.conf? Anything I am missing? Apr 29 19:29:06 jg_, with v3.14.x/jessie we are say 95% is comparable with v3.8.x.. We need a lot of work to re-implement capemgr on v4.x.x... Once you start asking about iio, pru, spi, uart, it's best to move back to v3.8.x till we are really to fully support you.. Apr 29 19:29:38 billh, you don't need a full x11 session, the fb-console will show up on the lcd too.. Apr 29 19:30:05 Ah, that's far simpler then Apr 29 19:31:57 rcn-ee thank you for the info. I just wanted to be sure I wasn't missing something obvious within jessie WRT enabling the features Apr 29 19:32:52 jg_, we will get there eventually. ;) v3.14.x is good enough for most people, but we still keep v3.8.x in the repo (and update it as more capes arrive) while still working on mainline too.. Apr 29 19:34:12 Hello , anyone around ? Am having trouble pinging internet from my beagleboard (beaglebone black) and am seeking assistance Apr 29 19:35:45 rcn-ee :D to be honest 3.8.x is working for me so there's no real need to move upgrade per se... well, beyond wanting to cut myself on the bleed edge of things Apr 29 19:36:34 jg_, with v3.14.x, we have pm-suspend, better usb/eth and sgx support... Apr 29 19:36:51 Yeah, the sgx support is what I'd like to play with. Apr 29 19:39:08 rcn-ee well that might be of interest! I'll keep my ear to the ground Apr 29 19:39:08 rcn-ee: any instructions how to build this branch ? need some special rebuild.sh script ? Apr 29 19:41:44 vvu, make ARCH=arm CROSS_COMPILE= bb.org_defconfig ; make ARCH=arm CROSS_COMPILE= zImage modules dtbs Apr 29 19:43:49 vvu, or: "make ARCH=arm LOCALVERSION=- CROSS_COMPILE= KBUILD_DEBARCH=armhf deb-pkg" and then just: sudo dpkg -i linux-image*.deb Apr 29 19:44:51 1st one...wasn't sure which config was Apr 29 19:45:02 Does the LOCAL_VERSION get put on the end of your kernel version? Apr 29 19:45:05 all these branches of the kernel for the bb are getting me confused :) Apr 29 19:45:16 Yeah, I had trouble figuring out what the defconfig was too vvu Apr 29 19:45:23 don't know which one to choose to get good usb support Apr 29 19:45:33 with the latest ti-kernel-dev my bluetooth usb is broken again Apr 29 19:45:37 i tried to make it obvious for you guys. ;) Apr 29 19:45:56 * vvu truly appreciates the support from rcn-ee Apr 29 19:46:17 same, haha. I just need to RTFM a little better Apr 29 19:46:23 yeah, the biggest issue with v3.14.x is working off this tree: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-3.14.y Apr 29 19:48:55 vvu, btw, r52 r61 are still in the apt repo, so if you want to do the install/reboot usb bluetooth check, so we can see where it broke.. Apr 29 19:51:30 tomorrow i think i will have some time Apr 29 19:51:36 now i need to get my stuff fixed really quick Apr 29 19:55:33 rcn-ee, looks like i now have backlight Apr 29 19:55:42 But still no splash screen Apr 29 19:55:59 I see this error in dmesg "tilcdc 4830e000.lcdc: timeout waiting for framedone Apr 29 19:56:13 Probably not important but I don't know for sure :) Apr 29 19:56:15 you should see a console prompt at some point.. Apr 29 19:56:34 if it's 'glowing' the backlight is active.. Apr 29 19:57:02 Unfortunately I do not. Able to ssh and TTL-USB serial into it only so far. Apr 29 19:57:08 Yeah, I'm able to control the backlight now Apr 29 19:57:18 Echoing things into the brightness Apr 29 19:58:10 Oh! eureka Apr 29 19:58:18 rebooted, now i have a desktop Apr 29 19:58:27 Interesting, still would like to know wha tI did differently there. Apr 29 19:58:31 cool! it's still alive! Apr 29 19:58:59 And I think the touch axes are reversed, but I'm sure a ts_calibrate will fix that Apr 29 19:59:16 yeah, it's wired inverted... Apr 29 19:59:32 Still, didn't see a splash screen or a terminal. If I uninstall my x window server, should I see the terminal come up on boot? Apr 29 20:00:48 sometimes... but usually the delay on fireing up the lcd, it's already past that.. Apr 29 20:01:15 but yeah, nuke x window and you should see terminal.. will show you it now too.. Apr 29 20:01:52 OK. I'll give that a try, but thanks for the help. I think it was actually that one of our screens is bunk, but I will retry my device tree changes and see if that was the problem. Apr 29 20:02:36 If so though, that will be an interesting time to find out what is wrong with the screen Apr 29 20:13:37 This is interesting, not sure if I just have to wait, but I seem to be freezing up my beaglebone black after a few touch events Apr 29 20:13:50 heartbeat LED stops blinking Apr 29 20:17:27 I don't see any references to the power requirements of the device, but I'm going to guess that maybe I don't have a wall wart with enough power output Apr 29 20:18:29 bench power supply ftw Apr 29 20:18:43 if only Apr 29 20:19:13 Bah, different sized barrel jacks Apr 29 20:22:27 rcn-ee: this kernel tree has any option to produce dtbs.tar.gz like yours ? Apr 29 20:23:39 vvu, it's the same source... just not the pretty scripts... if you use "deb-pkg" the *.dtb's will included inside the *.deb.. Apr 29 20:27:47 rcn-ee: has it been 2 years since we (BB) went DT? Apr 29 20:27:49 billh .. yeah I have a few adapters :D Apr 29 20:27:53 vvu, at least with ti-linux-kernel-dev, all that he is doing for the dtbs is running the dtb compile, then tar-ing them and unzipping them into the SD card Apr 29 20:28:29 ds2, it wasn't till v3.10.x did i start using my xM with device tree's... Apr 29 20:28:57 before that... things... well... yeah.. Apr 29 20:29:12 rcn-ee: trying to get an idea of how long this DT flux has been Apr 29 20:29:37 v3.0.x is about the first works.. v3.10.x was multi platform-dt.... Apr 29 20:31:33 ds2, 17 Mar 2011 was linus rant for v2.6.39 that kicked it off... Apr 29 20:31:57 it seems we have spent a lot of time and resources chasing DT and not getting real stuff done Apr 29 20:32:51 that's why we have acpi for arm64. ;) Apr 29 20:33:02 either that or piss the people off who have to merge the ridiculous board files Apr 29 20:33:12 ie. linus :) Apr 29 20:35:18 ds2, but some things got stuck in never ending review... just look at sunxi list for the recent spidev disussion.. Apr 29 20:41:00 since that time, there has been no "standard" way of loading a DT (higher level then register pointing someplace) Apr 29 20:41:10 rcn-ee: well... spidev should go away ;) Apr 29 20:41:48 appended DT, FLT, uimage + seperate DT, zImage + seperate DT, zImage + DT sitting in another partition, and so forth Apr 29 20:42:06 ds2, want to send patch deleting spidev from kernel? might as well also delete the i2c/gpio userspace varient too.. Apr 29 20:42:11 even if you choose a single boot loader,the picture doesn't get any clearer Apr 29 20:42:26 rcn-ee: i2c is different Apr 29 20:42:37 my complaint about spidev is it monopolizes the device Apr 29 20:42:59 so you are strongly incentivized to keep whatever userland hacks Apr 29 20:43:01 well so does i2c... enable i2c2 on a bbb, you lose can0.. ;) Apr 29 20:43:11 the i2c userland interface can share with the kernel Apr 29 20:43:20 move i2c2 around Apr 29 20:43:34 IIRC - the 2 I2C buses can have 4 sets of possible pins Apr 29 20:43:35 i2c also has easy discoverable devices... as they respond.. Apr 29 20:43:53 but i2c is dog slow and high latency Apr 29 20:44:19 I come close to saturating the I2C bus with a few sensors blasting away Apr 29 20:44:35 yeah it doesn't take much.. Apr 29 20:47:06 wonder how well would GSoC 2016 project along thelines of "Fork Linux" go ;) Apr 29 20:49:17 <_av500_> +1 Apr 29 20:49:23 <_av500_> ds2: can I apply as a student Apr 29 20:50:33 Any reason you guys would think touch events would freeze up the beaglebone? Apr 29 20:51:07 like if the mouse pointer goes outside the screen? (ie. miscalibrated touchscreen) Apr 29 20:54:49 ESD? Apr 29 20:54:50 :D Apr 29 20:56:05 haha maybe, though as a little test I booted it up without touching it Apr 29 20:56:33 and it still hasn't frozen Apr 29 20:57:22 touchscreens are very sensitive to good grounding Apr 29 20:57:41 but as for lockups .. Apr 29 21:00:55 my first intuition would be "because the tscadc driver sucks" ? Apr 29 21:01:37 AFAIK, not using the tscadc driver Apr 29 21:01:53 oh it's an i2c touchscreen Apr 29 21:01:55 y Apr 29 21:01:56 what kind of touch screen is it? Apr 29 21:02:10 cap sense? IR sense? resistive? Apr 29 21:02:12 Chipsee BBB-EXP-C expansion cape, not exactly sure what the model is Apr 29 21:02:15 cap sense Apr 29 21:02:18 omap-i2c/edt-ft5306 sucks. ;) Apr 29 21:02:20 The chip i believe is.. Apr 29 21:02:23 yeah, ft5306 Apr 29 21:02:45 rcn-ee: omap-i2c sucks too for that matter (the hardware mostly, not necessarily the driver) Apr 29 21:02:50 sure it isn't a ESD issue? Apr 29 21:03:28 probally would help if you define "lock up" Apr 29 21:03:29 Well, never can be *sure* Apr 29 21:03:39 Heartbeat LED stops blinking Apr 29 21:03:44 GUI freezes up Apr 29 21:03:55 BB is unresponsive to SSH and TTL serial Apr 29 21:03:57 surely, it didn't sprout arms, toss itself into a safe and clicked hte lock :D Apr 29 21:04:08 +1 ds2 Apr 29 21:04:09 is the I2C bus frozen in a bad state? Apr 29 21:04:15 How can I check? Apr 29 21:04:21 probe it Apr 29 21:04:22 'scope Apr 29 21:04:27 it should idle high Apr 29 21:04:39 ^ or dat Apr 29 21:05:10 but with ttl/ssh down.. it's a full core lockup... billh, what driver are you using for xorg? fbdev or modesetting? Apr 29 21:05:34 modesetting I believe, in an attempt to be as close to what the chipsee guys had as possible Apr 29 21:05:40 ah... use fbdev... Apr 29 21:06:11 modesetting puts the video core in an odd locked state.. ti gave up on me trying to debug it.. jtag clocks even disappear.. Apr 29 21:06:53 okay, I'll give that a try. Apr 29 21:08:39 I'd log the serial console before the "lockup" Apr 29 21:08:50 could be as simple as a kernel panic Apr 29 21:08:57 That's the plan if it still happens after I calibrate :) Apr 29 21:09:02 rcn-ee: "jtag clocks even disappear" -> that sentence doesn't make sense, jtag is clocked externally. a bus lockup can do a proper job of making the system undebuggable though Apr 29 21:09:23 well.. the jtag clocks (from the adapter) disappear into the part... to never be seen again... ;) Apr 29 21:10:48 still not sure what you mean by that, TDO stays high regardless of what you do? that seems rather unlikely Apr 29 21:12:09 (if you mean RTCK doesn't respond anymore, then you broke your JTAG connector since it's wired to TCK on the bbb PCB as the am335x lacks a genuine rtck) Apr 29 21:12:17 :P Apr 29 21:13:26 which is also something I consider a hardware bug actually... if they can't make a proper rtck (suitable for adaptive clocking) then they should have wired RTCK to ground, not fake it Apr 29 21:13:37 zmatt, we'd have to bug Cody Lacey, he was on the conference call, talking about how he was debugging it, and when the "issue" happend, the jtag disconnected/etc... Apr 29 21:14:18 ah, jtag disconnected is a different story... but assuming he was using CCS that's close to meaningless, it'll throw a hissy fit on the slightest provocation Apr 29 21:14:49 usually with an indication of the probably cause (which will be wrong) and a possible solution (which won't solve it) Apr 29 21:14:55 *probable cause Apr 29 21:15:46 followed by the debug server crashing Apr 29 21:15:49 \o/ Apr 29 21:15:53 joy! Apr 29 21:15:56 lol Apr 29 21:19:55 does it happen on the white with the ftdi jtag? Apr 29 21:20:11 there's not really any difference Apr 29 21:20:26 basically the white just has a cheap jtag adapter integrated on pcb Apr 29 21:20:40 it would rule out connector issues Apr 29 21:20:50 I was kinda joking about the connector Apr 29 21:21:06 I'm pretty sure people can tell the difference between a software bug and a broken connector Apr 29 21:21:32 given how the latter isn't exactly related to any system activity :P Apr 29 21:22:43 the connector on the black is user soldered Apr 29 21:23:05 so that assumption you have is aweful generous unless you know the person's abilities Apr 29 21:23:31 doesn't really matter... if it's soldered flakey then it'll either just not work or fail randomly, not fail in correlation with any software bug Apr 29 21:27:00 placement of the connector is also not exactly ideal, had to give my bbb huge legs... http://gerbil.xs4all.nl/barebone.jpg Apr 29 21:28:58 hey, why the hell is that image mirrored Apr 29 21:29:27 there, fixed Apr 29 21:46:07 afk for a bit Apr 29 22:28:51 best 1 euro spent ;) Apr 29 23:00:11 what's the license on the beagle logo? do I need permission to use it for personal use? Apr 29 23:30:29 PDogJr .. that information is on the beagle web pages. Apr 29 23:31:46 if I could have found it on the website, I wouldn't be asking here Apr 29 23:39:15 heh I know how that goes Apr 29 23:39:22 sec let me see if I can locate it quickly Apr 29 23:41:50 hmm I've found the bit about beagle designs but not about the logo .. you need to check with jkridner .. but I think its fairly flexible Apr 29 23:42:12 http://beagleboard.org/media might help you Apr 29 23:45:15 thanks Apr 29 23:45:49 the only pertinent information is that every is under CC unless otherwise stated, but I don't know if there's some exception clause written somewhere regarding the logo specifically Apr 29 23:46:12 I asked jkridner about a year or two ago but he never responded Apr 29 23:47:29 !seen jkridner Apr 29 23:47:38 hmm no seen script Apr 29 23:49:30 he is around from time to time Apr 30 00:02:21 Hey guys Apr 30 00:03:01 if my tslib calibration works, but my desktop (LXDE) does not properly position the mouse pointer, does this mean i have to run some sort of x input configuration? Apr 30 00:26:12 probably :) Apr 30 00:26:18 touchscreens are fun :P Apr 30 00:28:11 depends on your X drivers Apr 30 00:28:23 i think the newer ones do not use tslib cal info Apr 30 00:33:44 ds2: turns out serial console has a pull-down rather than pull-up, so unless a serial cable is connected it won't be the cause of 3v3b -> 3v3a leakage... looks like there's no "main culprit", just lots of reasonably weak pull-ups combined Apr 30 00:34:33 or it is just a crummy regulator Apr 30 00:34:51 why crummy? Apr 30 00:35:10 it does its Apr 30 00:35:21 it does its job exactly as requested Apr 30 00:35:36 not its fault the request is wrong Apr 30 00:36:56 btw, it does mean that the abuse the cpu suffers when in off-mode with battery attached (3v3b powered) will be far far worse when a serial cable is attached Apr 30 00:37:49 since that actually *drives* a pin, buffered by U15, while afaict the remaining leakage is just pull-ups diffusely spread over many pins Apr 30 00:37:49 Crap... I forgot to order a console cable still! Apr 30 00:39:32 you silly Apr 30 00:42:46 I just ordered something and forgot it ... damn Apr 30 00:43:01 Well at least I ordered to SDR dongles. Apr 30 00:44:01 * GenTooMan is silly he was up late reading one night, "the art of electronics volume 3... I think most people think I'm nuts but I enjoyed it." Apr 30 00:44:34 I mean 3rd edition. Sorry very tired. Apr 30 00:44:42 ah, TP4 is a convenient measurement point for 3v3a Apr 30 00:48:13 At least the BBB is a reasonably well done board and documented. Apr 30 00:51:02 and power supplies *are* a headache Apr 30 00:51:57 but it is kinda lame that the "fix" applied in revision A6A ended up reverting to the same scheme as used on the BBW of which the problems were already known Apr 30 01:01:48 one step forward ... and ... Apr 30 01:04:35 lol Apr 30 01:05:10 And Good read GenTooMan +2 Apr 30 01:08:58 Power is always an issue on boards. I was a little disappointed with the "repeat" power solution they had and scewing the RTC again. An LDO specific for the RTC shouldn't be such a big deal. Oh well I being a perfectionist (and I am far from perfect) probably would screw something else up. Apr 30 01:10:56 ds2: using pmic_good to control the 3v3b regulator is a fun patch though... although there are two places you can pick up pmic_good (U16 and the pmic itself), they're both on the other side of the pcb (and considerably more annoying to solder to than the 3v3b regulator itself, although still doable by someone with better soldering skills than me) Apr 30 01:11:41 GenTooMan: I really, really, _really_ don't understand why TI doesn't let end-users reprogram the EEPROM of their power regulators Apr 30 01:11:52 GenTooMan: that would have made things so much easier Apr 30 01:13:46 GenTooMan because TI Apr 30 01:14:46 GenTooMan: but the am335x rtc solution is kinda crappy anyhow.... it consumes way too much power Apr 30 01:21:02 crummy as in ENable threshold is too low Apr 30 01:21:18 zmatt: actually, have you considered putting in a few diodes in series with the enable pin? Apr 30 01:21:48 ds2: I'm not considering any patch myself tbh Apr 30 01:21:55 why not? Apr 30 01:22:03 no rework facility/skill or? Apr 30 01:22:32 zmatt: what is the voltage of the regulator's enable line when it is shutdown? Apr 30 01:22:52 that, and we're going to power it from an external board anyway that's still being designed, so it's much easier to include a workaround there than patch BBBs Apr 30 01:23:18 was thinking of it as an experiment, not a production thing Apr 30 01:23:20 that would be the 3v3a, and I haven't measured it yet... I was going to, when I get myself out of lazy-mode Apr 30 01:23:28 'k Apr 30 01:23:39 if it is like 0.6ish, a diode might fix it Apr 30 01:24:06 if you're gonna patch the hardware anyway, fixing it properly seems more sensible to me than some ugly hack Apr 30 01:24:26 3v3b should go down before or at the same time as 3v3a, not after Apr 30 01:24:31 i am already hw hacking the USB port for battery operation so... Apr 30 01:24:32 as it still would with a diode Apr 30 01:24:58 and since 3v3a gets actively discharged by the pmic and 3v3b doesn't, shutting it down sooner rather than later would be preferred Apr 30 01:25:15 why would it be after? Apr 30 01:25:23 it should be very close to same time Apr 30 01:25:41 or you assuming capacitance on the 3v3b rail? Apr 30 01:26:23 ds2: should be capacitance on all rails .. but it depends on loads too :) Apr 30 01:26:29 of course there's capacitance on the 3v3b rail, it's a stabilized supply rail Apr 30 01:26:50 let me rephase that... large capacitance Apr 30 01:27:07 I am implicitly assuming sufficient loads on there to discharge it reasonably fast Apr 30 01:27:35 not an unreasonable assumption :) Apr 30 01:27:36 dunno if that's true for 3v3b... I think it would still end up discharging partially via the processor's protection diodes Apr 30 01:29:11 what about a diode from 3v3b to 3v3a Apr 30 01:29:17 using pmic_pgood is sort of ideal for the purpose: when it goes high the cpu is fully powered but all IOs are still high-Z Apr 30 01:29:22 that should force the A rail to take down the B rail Apr 30 01:30:11 or more likely make the 3v3b regulator supply 3v3a too Apr 30 01:30:25 innormal operation? Apr 30 01:30:31 in shutdown Apr 30 01:30:41 which will be an even worse violation of absolute max ratings Apr 30 01:30:56 key might be the threshold for EN Apr 30 01:31:03 EN threshold is not well-defined Apr 30 01:31:12 there should be a guaranteed min Apr 30 01:31:24 hence the thought about another diode there to raise it Apr 30 01:31:45 it's logic high >= 2V, logic low <= 0.4 V @ 25 ͏°C Apr 30 01:32:03 logic low <= 0.18 V over full temperature range Apr 30 01:32:37 so over full temperature range, we need to drop EN to <= 0.18V Apr 30 01:33:16 yes, so you really want a proper signal, not abuse a supply line Apr 30 01:33:25 hmmm that's more of a job for a MOSFET Apr 30 01:33:31 pmic_pgood is already there Apr 30 01:33:35 yu Apr 30 01:33:38 it has the right timing Apr 30 01:33:44 it has the right levels Apr 30 01:33:51 is the timing of pmic_pgood correct in ALL cases? Apr 30 01:33:54 afaik yes Apr 30 01:34:04 would still benefit from careful analysis of course Apr 30 01:34:05 but afaik yes Apr 30 01:34:07 really tempted to lift some pins nad try that Apr 30 01:34:21 but then I need to fix my SW to shutdown correctly first ;) hehehe Apr 30 01:34:22 use pmic_good to drive mosfet :D Apr 30 01:34:36 <--- using 3.2 + lots of local hw support code Apr 30 01:34:55 shutdown is not hard though Apr 30 01:35:09 you haven't seen my hacked up kernel Apr 30 01:35:12 hehe Apr 30 01:35:15 could be worse, ds2 .. could be still back on 2.6 ;P Apr 30 01:35:19 though I'll admit it's harder than it ought to be Apr 30 01:35:35 thanks to that weirdass RTC Apr 30 01:36:05 yes, that odd ball handshake Apr 30 01:36:08 it's stupid you can't actually directly request a shutdown, you're required to schedule it slightly in the future Apr 30 01:36:42 lol "shutdown -h 1sec" Apr 30 01:37:14 wonder how many folks actually care about this Apr 30 01:37:23 the official battery capes feed in 5V Apr 30 01:37:58 ds2 .. I think its quite a good learning exercise Apr 30 01:38:27 5V is kind of a waste... I mean the 1.2V and 1.35V supplies use switching supplies, but all 1.8V and 3.3V supplies are LDOs Apr 30 01:38:46 I barely understand what you're trying to achieve .. but there's a sense of quest/mission/aims/etc :) Apr 30 01:38:48 I have toyed around with building a cleaned up version of the board Apr 30 01:39:27 zmatt: what is on the 1.8V line besides the ADC? Apr 30 01:39:29 zmatt .. do they pull much on 1.8 and 3v3 though if the core is working lower Apr 30 01:40:13 you may lose as much on low switching cycles/etc .. Apr 30 01:40:19 ds2: oscillator, PLLs, memory LDOs, backbias LDOs Apr 30 01:40:32 blah Apr 30 01:40:32 quite a bit then :D Apr 30 01:42:35 and it would also be the IO voltage level of choice.... 3.3V is kind of a backward compatibility concession Apr 30 01:43:35 depends on who you ask Apr 30 01:43:41 some folks are still on 5V Apr 30 01:43:44 zmatt .. that is quite true .. but not very handy for real-worldy stuff without interfacing hardware sadly Apr 30 01:44:00 but for example I don't really understand why they used 3.3V for Ethernet Apr 30 01:44:22 they could have run VDDHV5 on 1.8V Apr 30 01:45:09 probably don't want ethernet pickup n the 1.8v line .. Apr 30 01:45:30 or somethin like that Apr 30 01:45:38 veremit: ? Apr 30 01:45:49 cross-talk, etc Apr 30 01:46:10 ethernet still needs a 3.3V supply for the analog side Apr 30 01:46:24 I'm probably blithering .. its nearly 3am and I'm on about 4hrs sleep lol Apr 30 01:46:32 (its core runs on 1.2 V) Apr 30 01:46:55 makes sense Apr 30 01:47:13 IO can run on 1.8 - 3.3V Apr 30 01:47:44 I wonder what the pmic for the x15 looks like Apr 30 01:48:29 quoite simlar I'd imagine, in many ways Apr 30 01:48:33 my guess would be that, being omap-like, it's probably quite a bit more serious Apr 30 01:49:16 dunno, the previous pmic I studied in detail was considerably different from the tps65217 Apr 30 01:49:27 had integrated rtc also Apr 30 01:49:48 I think the imx6 I'm also using has some of that integrated .. I don't know of a pmic as such Apr 30 01:49:55 What voltage does the RTC require zmatt? 1.2? Apr 30 01:51:32 GenTooMan: 1.8V, and 1.1V normally generated by integrated LDO Apr 30 01:52:34 there's a pin to select whether you want to use the integrated LDO, and a pin that should either receive a cap if you do use it, or an 1.1V supply if you disable the LDO Apr 30 01:53:49 see the Supply tab of my subarctic pins spreadsheet ( https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view ) Apr 30 01:57:49 basically all internal logic runs on 1.1V nominal, except the cortex-a8 gets bumped to higher voltages to run it at higher-than-default clock speeds Apr 30 01:58:10 it can lower to 0.95 under certain powersave circumstances Apr 30 01:59:40 on a typical linux system that'll only happen if you enter suspend, since actually running on 0.95V ("OPP50") imposes fairly serious constraints Apr 30 01:59:46 like the inability to use ddr3 memory Apr 30 02:01:36 The RTC isn't the core voltage also is it? That's kind of insane to do that. Apr 30 02:02:00 it's a separate supply, but it runs at a similar voltage Apr 30 02:02:41 they can't seem to go much lower than 1.1V, and they don't need to go higher Apr 30 02:03:45 (except for speed freaks who need their cortex-a8 at *more* than 600 MHz) Apr 30 02:05:23 Well TI has some ultra low current LDO's however TI has issues with their website (they clouded their entire website so now Adobe farms up their PDF's and GOK where the other data is coming from). Apr 30 02:05:56 Anyhow it's hard to find stuff anymore cause of the 'ninja' scripting on their website Apr 30 02:06:50 They had some LDO's with 500/600na Iq but ... Apr 30 02:11:31 I don't see any number for typical power consumption of rtc-only mode Apr 30 02:14:22 stupid thing is, with rtc-only unusable anyway, power consumption would have been reduced if they disabled its internal LDO and hooked it up to the core 1.1V supply instead Apr 30 02:14:35 heh Apr 30 02:14:47 (the TRM actually does mention that) Apr 30 02:14:54 you guys need to put ya oars in for the next beagle-based design ;) Apr 30 02:15:02 ironic huh? Apr 30 02:15:21 well like most designs things are conflicting as always. Apr 30 02:15:41 Convenient parts aren't a perfect match for example :D Apr 30 02:16:29 I think they should have put a standard ARM RTC into the CPU instead with the ability to switch the RTC and core independantly. Apr 30 02:17:28 just tack a uPower rtc on .. much better :p Apr 30 02:17:36 a discrete RTC would probably win anyway, some have insanely low consumption Apr 30 02:17:51 never gonna get a core power consumption down to anything like sensible Apr 30 02:17:55 like this thing 150 nA -> http://www.nxp.com/documents/data_sheet/PCF8523.pdf Apr 30 02:18:21 +1 zmatt Apr 30 02:18:48 they're pretty common too I think Apr 30 02:19:16 though that's more important when powered using a small non-rechargable lithium cell Apr 30 02:19:35 exactly Apr 30 02:24:38 by the way is NXP now freescale or visa versa? **** ENDING LOGGING AT Thu Apr 30 02:59:58 2015