**** BEGIN LOGGING AT Mon Dec 14 02:59:58 2015 Dec 14 03:17:45 ok, re-remembered how to erase the eMMC env from u-boot Dec 14 03:21:31 for future reference: http://pastebin.com/x5QzB18E Dec 14 03:21:44 this should probably be wikified somewhere, but I'm too lazy right now Dec 14 03:24:22 to erase where u-boot stores it's env: Dec 14 03:24:22 mmc dev 1 2 Dec 14 03:24:23 mmc erase 1 512 Dec 14 03:24:30 512 might be overkill ... Dec 14 03:24:40 but it worked. Dec 14 03:27:12 I wonder when writing to mmcblkXbootY from linux broke Dec 14 03:27:13 and how Dec 14 03:27:27 i.e. is it a kernel change or is u-boot responsible Dec 14 03:27:41 it might do something evil like mark them write-protected till next power up Dec 14 03:27:44 might just be kernel options not enabled in the kernels shipped with Debian? Dec 14 03:27:49 no Dec 14 03:28:00 if the kernel knows they exist it can write to them Dec 14 03:28:16 either the kernel is deliberately denying access unless you do the right magic dance Dec 14 03:28:39 or u-boot is doing sneaky stuff Dec 14 03:30:04 if either of them is meddling with reset-insensitive eMMC settings that could also be involved in cold boot vs warm boot differences Dec 14 03:30:29 "*** Warning - bad CRC, using default environment" is music to my ears Dec 14 03:30:30 and I'm more inclined to suspect u-boot than the kernel Dec 14 03:34:35 vagrantc .. I see that on every uboot I run .. :) Dec 14 03:35:00 veremit: it's the normal situation Dec 14 03:35:07 which is exactly why vagrantc was happy to see it Dec 14 03:35:08 zmatt.. yes I would have thought so .. Dec 14 03:35:21 well yes. Dec 14 03:35:47 though whether you should have a crc on your config .. -shrug-.. lol Dec 14 03:36:25 given that i want to test the u-boot default env always, and i test new versions regularly ... one stupid saveenv can be really annoying Dec 14 03:36:28 on a non-volatile config that can render your system unbootable? I'm rather glad there's a CRC on that Dec 14 03:36:31 :P Dec 14 03:37:08 but this time i'm going to document what is needed. Dec 14 03:37:43 vagrantc: I'm also pretty sure saveenv is not compiled into the u-boot on rcn's images Dec 14 03:38:02 rcn is smarter than i or upstream. Dec 14 03:38:51 though without saveenv it would be nice if it just kept ENV_IS_NOWHERE Dec 14 03:38:57 well, i don't deviate from upstream on that, and i know there are debian users that make use of saveenv ... because they file lots of bug reports about fw_printenv and such Dec 14 03:39:00 would avoid the error message on every boot too Dec 14 03:39:07 really? there are good reasons for saving a working config. That said, with uEnv.txt its a bit superfluous Dec 14 03:39:27 there's no uEnv.txt in u-boot mainline for bbb Dec 14 03:39:32 at least, there wasn't ... Dec 14 03:39:52 I thought kernel cmdline was there .. Dec 14 03:39:55 right, they're two approaches, and the uEnv.txt version is more user-friendly Dec 14 03:39:57 amogst other things Dec 14 03:40:16 for static config .. saving uboot env makes sense Dec 14 03:40:21 env stashed into some secret place in eMMC you can't easily overwrite is very bad for general usability Dec 14 03:40:35 it should just have used part of the main mmc partition Dec 14 03:40:39 if you're modifiying .. a text file in a boot partition widely accessible .. Dec 14 03:41:01 and if its static .. doesn't matter *where* it is.. imho. Dec 14 03:41:09 if it's static, compile it in Dec 14 03:41:47 my main point was, if you're going to omit 'saveenv', then it should not use persistent env at all :P Dec 14 03:41:55 one instance I've got .. is selecting from a number of hardware options available .. Dec 14 03:42:08 so .. setting a uboot env .. whilst havng a static kernel and uboot .. makes sense Dec 14 03:42:29 otherwise you end up with so many bits and pieces Dec 14 03:42:56 veremit: I understand there are use cases Dec 14 03:43:15 but we digress .. we're talking about one lump of hardware .. Dec 14 03:43:35 for but Joe Average BBB User, u-boot's env stashed into the obscure mmc boot partition is a recipe for hair-pulling Dec 14 03:43:50 and the endless moving target that is its software lol Dec 14 03:44:18 for once I see the sense in one kernel and rootfs image (for them all, lotr quote) Dec 14 03:44:32 *to rule them all Dec 14 03:44:36 damnit get it right lol Dec 14 03:45:19 vagrantc: btw, your bbb-borked loads fine, though it ends in the prompt (no autoboot) Dec 14 03:45:33 no message about env either Dec 14 03:46:41 this is interesting Dec 14 03:46:59 it seems I must have saveenvd myself once Dec 14 03:47:11 o,o Dec 14 03:47:54 unless these environment variables are a standard u-boot thing: LED0=53 LED1=54 LED2=55 LED3=56 PMIC=24 Dec 14 03:48:30 o,O Dec 14 03:48:49 thats bb-specific surely .. in some way Dec 14 03:48:50 erasing env :P Dec 14 03:48:53 but likely deprecated Dec 14 03:49:08 veremit: those are defs I know I made while playing in u-boot Dec 14 03:49:15 aha Dec 14 03:49:24 env erased, let's try again Dec 14 03:49:40 *** Warning - bad CRC, using default environment Dec 14 03:49:43 there we go Dec 14 03:49:55 vagrantc: so, your bbb-borked isn't borked Dec 14 03:49:58 it works fine Dec 14 03:50:42 then what niche edge case caused cccccc ?? Dec 14 03:51:15 bootin from wrong device?! Dec 14 03:51:29 veremit: you mentioned you had written the old u-boot to eMMC before making this image Dec 14 03:51:47 not I .. I've not meesssed with uboot on the BBB Dec 14 03:51:52 sorry Dec 14 03:51:53 mostly on a dm368 Dec 14 03:51:54 vagrantc: Dec 14 03:52:10 and briefly on imx6 Dec 14 03:52:15 stop both starting with a v damnit! Dec 14 03:52:16 :P Dec 14 03:52:37 * zmatt pokes vagrantc Dec 14 03:52:52 vagrantc: you said you verified it still CCCd Dec 14 03:53:00 vagrantc: was that with a cold boot? Dec 14 03:54:11 unless you simply screwed up, there are some potentially disturbing implications... namely that the new u-boot messes with eMMC in a way that is reset-insensitive and requires power cycling Dec 14 04:00:51 zmatt: with a cold boot it started working again Dec 14 04:01:14 vagrantc: but with the 2016.01 u-boot it even CCCd from cold boot right? Dec 14 04:01:49 and continued to CCC even after you fixed the u-boot on eMMC but warm rebooted Dec 14 04:03:57 zmatt: it didn't CCC on 2016.01-rc2, it couldn't find the eMMC and asked to reset the board ... error message posted to beagle-x15 recently Dec 14 04:04:43 then when did the CCC story begin? Dec 14 04:05:21 when i booted it today trying to troubleshoot it ... Dec 14 04:05:36 i think u-boot 2015.10 was installed at that point Dec 14 04:05:55 btw, there's no write protection enabled on the boot partitions, so it's just the linux kernel being stubborn for some reason Dec 14 04:06:23 zmatt: you able to reproduce the unable to write issue? Dec 14 04:06:24 there is a 'boot' partition? Dec 14 04:06:35 veremit: two Dec 14 04:06:47 oh sheesh .. or you mean those mmcblk thingues? Dec 14 04:06:55 yes Dec 14 04:06:56 I thought they were completely redundant Dec 14 04:07:09 alright, this is the suspect patch: 0047-spl-mmc-get-rid-of-emmc-boot-code-duplication.patch Dec 14 04:07:19 or at, least one of them... Dec 14 04:07:23 they allow for very convenient booting and safe upgrades Dec 14 04:07:27 which is why ROM makes no use of them Dec 14 04:07:33 since, that would be easy and reliable Dec 14 04:07:39 zmatt: so how would that work?! Dec 14 04:07:45 what creates them? Dec 14 04:08:09 not the mmcblk driver surely ... that would be crazy! lol Dec 14 04:08:12 veremit: the emmc manufacturer does, their size is fixed Dec 14 04:08:27 wait what?! Dec 14 04:08:35 they're not partitions in the same sense as "partition table" Dec 14 04:08:43 you select them via a special emmc command Dec 14 04:08:46 nope .. no mmc 'partition' is .. Dec 14 04:08:58 they're just blocks of flash Dec 14 04:08:59 see why not saving to these psuedo-partitions is best for everyone? Dec 14 04:09:14 normally they're used to store the bootloader Dec 14 04:09:17 can't even explain it easily without overloading different meanings of various words Dec 14 04:09:40 but the rom is not designed to use these? Dec 14 04:09:48 I suspose its too particular to emmc Dec 14 04:09:51 there are two so you can write an update to the inactive boot partition, and atomically switch once you're sure the new bootloader is in place Dec 14 04:10:04 it already has emmc-specific code, but no it doesn't support them Dec 14 04:10:14 they're insanely easy to use Dec 14 04:10:21 -shrug- Dec 14 04:10:58 once you've selected the active boot partition, here's how you boot from eMMC: Dec 14 04:11:04 hold cmd low Dec 14 04:11:06 start clocking Dec 14 04:11:27 data blocks start getting sent your way... being the content of the active boot partition Dec 14 04:12:07 ok, 9 patches in from a working u-boot ... only a few hundred more patches to test Dec 14 04:12:56 if you've ever seen the number of steps normally required to initialize MMC/SD before you finally get your data, your jaw would probably have dropped on the floor upon reading the procedure above Dec 14 04:13:00 :P Dec 14 04:13:48 oh no, i forgot to do cold boots on all versions.... Dec 14 04:14:23 cold booting should normally not really matter though, except for resampling the SD-boot-button Dec 14 04:15:31 vagrantc: foudn it! Dec 14 04:15:58 echo 0 > /sys/block/mmcblk0boot1/force_ro Dec 14 04:17:09 zmatt: that is *wonderful* news. Dec 14 04:20:57 ok, patch 48 still works, patch 57 doesn't ... that's waaaay better than testing all 475 patches and having it still not work. Dec 14 04:27:57 patch 53 introduces the weird error messages but actually loads u-boot.img Dec 14 04:28:12 * vagrantc suspects there are at least 5 issues here Dec 14 04:32:03 veremit: btw, did you see the scope pics I took from a bbb that started .. misbehaving Dec 14 04:33:10 it gave the power led blip of death when usb powered, but did power up when an ac adapter was used Dec 14 04:33:42 http://gerbil.xs4all.nl/bbb-powerup/ yellow=3v3a green=sys blue=1v8 pink=3v3b Dec 14 04:48:48 zmatt: eh? Dec 14 04:49:14 zmatt: I don't think you can get -out- of that situation if the pmic goes weird? Dec 14 04:50:20 zmatt: what's forcing those blocks to ro? and how can you make anything *use* them anyway? Dec 14 04:51:55 veremit: this isn't the pmic going weird Dec 14 04:52:05 veremit: in the dc power pic, look at 3v3b Dec 14 04:52:18 but the power-led-blip-of-death usualyl is ... Dec 14 04:52:34 uh which one? Dec 14 04:52:38 in this case the pmic isn't blipping Dec 14 04:52:41 and I thought you frigged 3v3b Dec 14 04:52:54 this is an unpatched rev C Dec 14 04:54:52 ewwwwwwwwwwww wtf Dec 14 04:55:16 that's all over the shop Dec 14 04:55:20 * vagrantc found the breakage Dec 14 04:55:26 vagrantc: yay Dec 14 04:55:35 a1e56cf6d430d78db3a4dc08a422311145e32315 spl: mmc: add support for BOOT_DEVICE_MMC2 Dec 14 04:55:43 thank you bisect methodology. Dec 14 04:55:57 note that sys normally does not drop significantly during boot, it's an indication that something is drawing a _lot_ of power Dec 14 04:56:07 the fact that 3v3b hovers around 1.5V gives a hint where to look Dec 14 04:56:08 :P Dec 14 04:56:49 that's badly crowbar'd down ... Dec 14 04:56:54 that's also the only supply not monitored by the pmic, hence no blip... except on usb where the port power gets shut off due to overcurrent Dec 14 04:57:42 interestingly, the usb pic shows 3v3b does not rapidly fall to zero after power is cut Dec 14 04:57:43 so .. what's holding 3v3b down? Dec 14 04:57:55 so it's not an ohmic short to ground Dec 14 04:58:22 no its an active device Dec 14 04:58:47 1v5 = 2x 0.7v diodes :D Dec 14 04:59:40 so... what's on 3v3b... ethernet.. eMMC... hmm Dec 14 05:00:09 something bein held in reset? Dec 14 05:00:30 shouldn't draw current Dec 14 05:00:32 that doesn't explain this Dec 14 05:01:22 zmatt: this is repeatable, yes? Dec 14 05:01:50 perfectly yes.. thermal imaging would probably identify the culprit immediately Dec 14 05:02:14 ofc Dec 14 05:02:22 unfortunately don't have that Dec 14 05:02:39 most likely it doesn't matter anyway, this thing is a goner Dec 14 05:02:44 damnit man .. backup plan .. :p Dec 14 05:03:15 I mean, it has probably been powered on like this for minutes aggregate Dec 14 05:03:36 and making 3v3b drop like that means > 500 mA is involved Dec 14 05:03:47 yes that's really not good! Dec 14 05:03:58 unless the 3v3b regulator itself is broken Dec 14 05:04:02 you can't identify any heat by fat finger aproach? Dec 14 05:04:29 yeah I'm considering doing that out of curiosity when I'm at the office Dec 14 05:04:45 or IR thermometer Dec 14 05:04:57 we have a fancy one with a laser guide Dec 14 05:05:00 its not quite 'magic smoke' just 'getting hot' Dec 14 05:07:09 ah I just realized the blip on usb *is* due to the pmic, but in an indirect way: usb supply is current-limited to 500 mA by default (that's normally cranked up by the bootloader but it never gets there) Dec 14 05:07:29 hence sys drops like brick and then the pmic supplies fault Dec 14 05:09:37 veremit: as for your earlier question about the boot partition: the kernel is apparently forcing them ro by default as a precaution, with a switch for that feature in sysfs Dec 14 05:09:43 *boot partitions Dec 14 05:10:06 (they can also be made ro in eMMC but I had already checked that wasn't the case) Dec 14 05:10:48 zmatt: surely if you can recover the bootloader, the board will boot via usb? or is it a total write-off? Dec 14 05:10:57 ?? Dec 14 05:11:11 no bootloader is actually stored there on a bbb Dec 14 05:11:24 they're *intended* for that purpose Dec 14 05:11:58 whoah whoah .. back a step .. that 'bricked' board .. Dec 14 05:12:05 had nothing to do with them Dec 14 05:12:12 is it actually bricked .. or is usb boot fubar'd by lack of bootloader Dec 14 05:12:17 you're mixing two conversations Dec 14 05:12:21 yes so are you :P~ Dec 14 05:13:05 ignoring the boot "partitions" Dec 14 05:13:20 the bricked board has something shorting 3v3b to ground (up to 1.5V diode drop) so it's pretty bricked Dec 14 05:13:26 the board can be powered via dc? Dec 14 05:13:34 hmm oh ok true .. Dec 14 05:13:54 yeah so the current is less than 2A Dec 14 05:13:58 though more than 500 mA Dec 14 05:14:27 probably not best to keep feeding it more power .. or it will emit the magic smoke .. :) Dec 14 05:14:37 at least that'll identify the cause Dec 14 05:14:49 indeed Dec 14 05:14:54 or even resolve it Dec 14 05:15:08 O,o .. possibly. Dec 14 05:15:11 that's it! I'm going to attach a proper lab supply to the 3v3b to keep it from dropping Dec 14 05:15:23 wuh oh Dec 14 05:15:38 someone seriously "repaired" an am335x this way Dec 14 05:15:48 blew the links through? Dec 14 05:15:55 yep Dec 14 05:16:12 so that guy probably now has some I/Os with no ESD protection diodes Dec 14 05:16:15 or such Dec 14 05:16:34 that was the guess of the TI engineer anyway Dec 14 05:16:35 well .. as long as it doesn't affect core functionality .. Dec 14 05:17:49 in any case, going from "completely dead" to "boots and seems to work" is a form of repair in my opinion, even if the chip is beyond any doubt still damaged in some way Dec 14 05:18:23 and come on, frying a chip back to life :D Dec 14 05:18:30 lol Dec 14 05:18:37 well .. its *one * method Dec 14 05:19:00 I suppose if you have nothing to start with .. and you end up with something .. Dec 14 05:19:09 well it's not like you can repair a chip any other way Dec 14 05:19:11 fair cop Dec 14 05:19:35 (well, maybe some people in some research labs can, but...) Dec 14 05:20:56 I thought it was hilarious anyway... must have been weird for them too Dec 14 05:21:11 the supply briefly showed something like 2-3A Dec 14 05:21:19 and then all went normal and the system booted Dec 14 05:21:34 lol yeah it would be weird Dec 14 05:23:46 what really pisses me off about eMMC is the shitload of OTP settings... some of them I would really like to try to evaluate their impact, but the "one time programmable" part is not exactly developer-friendly Dec 14 05:26:03 lol Dec 14 05:58:00 oh wait, the short might be ohmic after all Dec 14 06:00:35 the supply is still on at the end of the zoomed-in pic, just severely limited... the overview pic shows the supply is only cut somewhat later, and 3v3b does rapidly fall to 0V after that Dec 14 06:39:32 ah Dec 14 06:56:54 weird, a carbon nanotube has a resistance of 6453.2 ohm, regardless of length Dec 14 06:57:22 well, haven't quite found the issue yet, but productivity is waning ... Dec 14 06:57:30 at least i know where the issue was introduced Dec 14 06:57:36 * vagrantc waves Dec 14 06:57:48 everything is waves Dec 14 07:00:12 ah nm, I should have kept on reading... initial prediction disagreed with reality Dec 14 07:04:55 o,o Dec 14 07:07:16 ok so what I'm reading seems slightly conflicting, but if I understand correctly values near the ballistic transport conductance (the 6.5 kΩ) is possible, though making good contacts at the ends can be a problem Dec 14 07:07:28 and max current is 25 μA Dec 14 07:10:16 lol, and it can't be too cold Dec 14 07:13:13 if you get too close to 0K conductance through a nanotube becomes wildly dependent on voltage across the nanotube: only for a series of narrow voltage ranges conductance is excellent, inbetween it is shit Dec 14 07:13:34 this is weird Dec 14 07:20:53 ah, the relevant voltage is between the tube and the gate on which it rests Dec 14 08:05:33 I'm having this weird issue with TI SDK 2 and QtCreator debugging, when I place a breakpoint when the debug session has started the application stops, when placing it before the session starts it works fine Dec 14 08:06:04 Debugger log reports: BREAKPOINTS ARE NOT FULLY SYNCHRONIZED Dec 14 08:06:57 http://e2e.ti.com/support/arm/sitara_arm/f/791/t/467506 << has the same problem, not the main subject but it gets noticed after the initial problem is solved Dec 14 08:07:09 Any thoughts? Dec 14 08:24:50 RagBal: for problems with TI software, you'll have to turn to TI for support Dec 14 12:15:13 Hello all, I am tasked with the replacement of a lockin amplifier, a signal generator/injector and their software with an ARM device. These high precision devices are used for a magnetic field research. I have thought of using the AD7190 as described here - https://developer.mbed.org/users/tkreyche/notebook/ad7190-ultra-low-noise-24-bit-sigma-delta-adc/ I however do not see it doing the whole job for me. Could you advise me on a better AD evaluat Dec 14 12:15:13 ion board. Dec 14 13:50:12 what's the supposed way to use the bbb adc on kernels 4.x? echo cape-bone-iio > $SLOTS gives write error Dec 14 13:51:47 "cape-bone-iio" .. where on earth did you find that??! Dec 14 13:53:37 oic Dec 14 13:53:37 that's a 3.8-ti-ism Dec 14 13:55:20 yep, whas the way i used on 3.8. Dec 14 13:56:14 current kernels should have some way to load dtbo's too Dec 14 13:56:22 haven't played with that yet Dec 14 14:01:28 echo 'BB-ADC' > /sys/devices/platform/bone_capemgr/slots seems to do the trick Dec 14 14:02:08 but adafruit library need to update paths too, it seems Dec 14 14:02:32 adc.setup() dies complaining Dec 14 14:14:31 yea - a lot has changed since 3.8 :) Dec 14 14:23:39 they might want to be a bit smarter about things and identify on what sort of kernel they are running Dec 14 14:33:37 I would like to know if anyone does give BBB training in Pune Dec 14 14:35:36 searching for a BeagleBoard trainer in pune Dec 14 15:22:09 anybody know where to buy a BBB wifi cape or a BBB USB cape? Dec 14 15:33:55 join Dec 14 15:34:11 JOIN Dec 14 15:36:17 http://www.catb.org/esr/faqs/smart-questions.html Dec 14 15:39:37 I've only found one place that ever carried such things and EVERY cape there is out of stock.. it looks like a ghost town. Dec 14 15:41:35 get a usb hub+usb wireless Dec 14 15:41:38 why a cape Dec 14 15:41:54 stt_michael: did that, but the BBB didn't like the two hubs I've tried so far! Dec 14 15:41:59 plus a cape would be tidier :) Dec 14 15:42:16 powered hub Dec 14 15:42:25 I don't think anyone makes a wifi hub .. no call for it with usb dongles Dec 14 15:42:30 Simonious: you may want to email CircuitCo directly Dec 14 15:42:38 stt_michael: there are pics of such a thing, but.. no one sellig htem Dec 14 15:42:39 usb is a bit hit-and-miss on the bbb Dec 14 15:44:16 stt_michael: I'll try the powered up 1st.. should be able to find a supply for this guy in short order. Dec 14 15:56:31 ha.. wel I've got a supply on order.. the suitable supplies I could find weren't easily accessible. Dec 14 16:39:46 stt_michael: frying the bbb back to life didn't work sadly... a characteristic aroma and noticable heat appeared to originate from the eMMC however Dec 14 16:41:05 oh no .. :/ Dec 14 16:41:25 yeah, well, RiP... we got stacks more Dec 14 16:42:02 odd component to fail though... I mean, it's not easily exposed to ESD or such Dec 14 16:43:35 cool, I got mentioned in the TI Community Awards Dec 14 16:43:42 o,O Dec 14 17:02:57 Hey guys/gals, I'm working on a Kernel module for HD44780 Character displays, and would like some help properly defining the interface to user space. I am seeking input as I would like to eventually release this open to the public, and maybe even see it in the main-stream kernel some day. I am currently working on a design doc if anyone is interested in taking a look and making comments. Dec 14 17:03:07 https://gist.github.com/abferm/f2bfe4cd6057d2660aaa Dec 14 17:22:23 abferm, there are many implementations of the hitachi 16x2 family of displays out there on the web you can do a comparison with Dec 14 17:22:57 in a choice of languages I dare say, too Dec 14 17:25:54 stt_michael: This is a kernel level driver (Bit-Banged using GPIO and Pinctrl with device tree bindings) aka a proper driver :) Dec 14 17:26:31 I am mostly looking for help defining the interface to user-space, IE: What operations should be exposed and how. Dec 14 17:26:42 abferm, yes I recall when you first asked, when zmatt told you there was a method implemented in the lcdc module (albeit not in the ti lcdc driver) Dec 14 17:27:36 would be easy enough to use that feature of the lcdc driver from userspace though (via uio) Dec 14 17:28:07 abferm, I would direct you to the Arduino library as a first starting point .. https://www.arduino.cc/en/Reference/LiquidCrystal Dec 14 17:28:14 stt_michael: yes, I have only been able to find one other kernel driver for these LCDs and its user interface is horrible. Dec 14 17:28:19 zmatt, yes yes, we know your uio is da bomb ;P Dec 14 17:28:29 I have a working POC I just need to define an interface Dec 14 17:28:55 Proof of concept, not piece of crap... Dec 14 17:28:56 if it's a character display, shouldn't it just be a VT ? :P Dec 14 17:29:33 existing interface, everybody knows it Dec 14 17:29:35 zmatt: kind of... Dec 14 17:30:02 There are some differences: custom characters, etc. Dec 14 17:31:10 well, if you're not taking advantage of the ability of the standard way for applications to output chars, then I'm not sure why one would bother doing this in kernelspace in the first place Dec 14 17:31:13 Also control of cursor/display status. Memory outside of the display range. Dec 14 17:31:52 zmatt: I originally tried bit-banging from userspace, but ran into lots of issues. Dec 14 17:31:56 especially since the other things you mentioned (custom chars etc) sound like an application will need exclusive access to the device anyway Dec 14 17:32:55 yeah ok, you didn't know yet there's builtin hw for it Dec 14 17:33:12 though bitbanging from userspace seems to work quite okay for me Dec 14 17:34:04 zmatt: I ended up with a bunch of timing issues, and my screen kept getting in a funky state that required a power-cycle to recover from. Dec 14 17:34:54 (irqs from gpio to userspace otoh are a bit sluggish, about 40-80 μs when I measured them, with some outlyers even higher) Dec 14 17:35:35 but yeah bitbanging wouldn't be my first choice for a bus interface Dec 14 17:39:53 Again, I have a working implementation the problem is defining the interface. One of my current thoughts is exposing the DDRAM, CGRAM, cursor/display flags, etc. as files in sysfs. Dec 14 17:45:03 wmat: Contacted CircuitCo - they are friendly and are trying to help me get a cape. Dec 14 18:05:07 Simonious: excellent Dec 14 18:17:31 Hi Dec 14 18:24:09 i am new to BB. i have one issue. Dec 14 18:25:05 i have loaded ubuntu on BB black rev C. but i cant find program that used for shutdown BB with power button. Dec 14 18:25:36 if i want to use that feature where do i get program or files for that . Dec 14 19:21:03 I followed the instructions here: http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2814.04.3.29 starting with wget... and it boots, things are working, but apt-get update gives: http://pastebin.com/ZDFzADYq - I'm still poking at it, but I'd welcome suggestions to get apt-get working properly. Dec 14 20:05:17 My google foo appears to be inadequate to discovering what the coherent_pool setting is for. I need to reserve memory for DMA and this appears to be related, but I can't determine how, in order to know if I should use coherent_pool or mem to set aside space. Dec 14 20:23:39 Is there any way that i can get shutdown program for to power button from original Image? Dec 14 20:29:58 Atul: if it exists in your ubuntu, take a look at /etc/acpi/events Dec 14 21:50:07 hi, someone happen to where to download an "official" cross toolchain for a debian target running on a bbb? Dec 14 21:58:36 Hi guys, I'm trying to follow instructions on elinux to copy my eMMC on a beaglebone to an SD card for future use. Dec 14 21:58:57 sd4130: are you using a Debian source image? Dec 14 21:58:57 I was wondering if there was anything special with Beaglebone Green or if I should just be treating it like I would a Beaglebone Black? Dec 14 21:59:07 if so, it is easier to simply use the script that is there. Dec 14 21:59:20 Nothing special regarding boot on the Green vs. Black. Dec 14 21:59:24 Yes, the image is what came with the board Dec 14 21:59:29 What script are you referring to? Dec 14 22:00:08 xhttps://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Dec 14 22:01:00 it is in the /opt/scripts/tools/eMMC directory on the board Dec 14 22:01:15 just run it with a blank uSD card inserted to create a backup. Dec 14 22:01:31 thank you! Dec 14 22:01:47 @jkridner I appreciate the help! Dec 14 22:17:20 Given the "genric DMA" API has a call dma_alloc_coherent that would imply it's using memory reserved by coherent_pool. I see nothing to indicate that however, on the 'net, in DMA-API.txt, or on the LDD3 Ch 15 on DMA, nor do I see any reason I'd prefer this over ioremap'ed reserved memory for a specific, set hardware configuration. Are there guidelines I've missed? Dec 14 23:01:31 hello, where do i find the gerber and fab files for Beagle Bone Green Board? Dec 14 23:35:05 anyone got good instructions for flashing u-boot to the bbx15 from u-boot with tftp? :) Dec 14 23:36:53 * vagrantc takes the easy route and uses a microSD Dec 15 00:10:44 hey guys, I was wondering if I apt-get a kernel and 'sudo reboot' Dec 15 00:11:02 how long would the beagleboard need to boot up properly? Dec 15 00:11:31 I tried this earlier and it took an awfully long time to boot and wasn't sure if I did something wrong or not Dec 15 02:16:05 Hi, I was wondering if someone was available to chat about updating kernels on the Beaglebone Green? Dec 15 02:17:03 I'm using the latest image of Debian from the website, but once I reboot after I install a kernel it stays at a spot where all four LEDs are on Dec 15 02:17:16 and doesn't seem to move from there. I waited about 45 minutes and no change to the board. Am I missing a step? Dec 15 02:19:12 I use sudo apt-get install linux-image-3.8.13-bone68 Dec 15 02:19:14 and then sudo reboot Dec 15 02:19:18 and run into this issue Dec 15 02:27:28 Hi :) Dec 15 02:28:13 I joining irc (a first) because I have a problem with BBB on OS X (El capitan) Dec 15 02:28:41 Not sure if it's the best place for that though...(StackOverflow?) Dec 15 02:29:33 Since I upgraded to El Capitan (OSX 10.11.1), I am not able to connect to my BBB. Dec 15 02:29:53 I though I had messed up something on my BBB and try to fix it. Dec 15 02:30:13 However, when I am using an Ubuntu, it works perfectly. Dec 15 02:30:38 So I'm guessing, it has to do with OSX drivers. Dec 15 02:30:46 But I'm not able to find a solution. Dec 15 02:31:08 Does anyone have any clue on this? (thanks!) Dec 15 02:45:32 " Heads up: HoRNDIS does NOT yet work on Mac OS X 10.11 (El Capitan)!" - http://joshuawise.com/horndis **** ENDING LOGGING AT Tue Dec 15 02:59:58 2015