**** BEGIN LOGGING AT Fri Feb 05 02:59:59 2016 Feb 05 03:50:34 * zmatt randomly decided to add some more pics to http://elinux.org/BeagleBone_Power_Management#Power_path_and_charger Feb 05 03:53:11 acn't have too many pics :D Feb 05 03:54:23 ~/.../power/scope$ ls *.png | wc -l Feb 05 03:54:23 303 Feb 05 03:58:59 ideally I'd want pics showing *all* relevant supplies during various scenarios, preferably along with some current measurements :P Feb 05 03:59:31 but, well, only four probes, and some things are a PITA to measure Feb 05 04:01:28 couldnt you use multiple scopes, then get the data as csv and then do some PC magic to genenerate an image (sounds like a bit of work thou) Feb 05 04:01:31 and I noticed I'm still missing quite a few pics of a normal, unpatched rev C... which is after all what most people have Feb 05 04:01:43 filt3r: http://elinux.org/File:Bbb-c-shutdown-bat-pmic.png Feb 05 04:01:46 been there, done that :P Feb 05 04:02:01 ohh looks nice :D Feb 05 04:03:09 the Feb 05 04:03:23 did you use image editing or have you rendered it from csv data? Feb 05 04:03:29 the "zoom-in" pic of the 5v ramp up that I just added is also obviously image-edited Feb 05 04:03:32 the former Feb 05 04:03:55 I did also start capturing raw data files at some point, but still need to work on some tooling to visualize them Feb 05 04:04:28 ahh, i was a bit surprised because of the persistence, because i thought it was rendered on the pc Feb 05 04:04:53 having a script grab the png images from the scope was the lazy approach, at least in short term (visualizing raw data would pay off in the longer run of course) Feb 05 04:05:11 well on unix there is gnuplot, but i've never used it for something serious, but i've heard its pretty powerfull Feb 05 04:07:25 is it okay with 2000000 data points? Feb 05 04:07:32 (per channel) Feb 05 04:07:45 has the writing to eeprom method change with a 4.1 kernel other than being i2c-2 instead of i2c-1 ? Feb 05 04:08:41 Hewball: hmm, the nvmem framework is new-ish I think, or rather it's a non-mainline patch that rcn-ee applies (so I don't know if it's new in 4.1 or has also been backported) Feb 05 04:09:18 trying to write to an eeprom on a cape, havnt tried to do it for a good 6 months and now its not working Feb 05 04:10:15 my only experience with it is reading an eeprom (the on-board one), never tried writing to one Feb 05 04:11:00 What distributions are being used with Beaglebone Black for Industrial applications? Feb 05 04:12:07 And what's this about the Rev. C needing patching? Feb 05 04:12:10 i can see it detected as the eeprom address changes when i change a0 and a1 jumpers but just cant write to it :| Feb 05 04:12:45 zmatt, my guess is that gnuplot should be able to handle this size of data fine, it'll obviously take longer to render but other thant that i see no reason why it shouldnt work Feb 05 04:13:53 Tenacious-Techhu: it doesn't need any patching per se, I just happen to have lots of scope pics of power-up/down on a patched one and realized I'm still missing some good pics of an unpatched one Feb 05 04:14:01 zmatt, my guess is that gnuplot should be able to handle this size of data fine, it'll obviously take longer to render but other thant that i see no reason why it shouldnt work Feb 05 04:14:05 fuck Feb 05 04:14:06 :D Feb 05 04:14:10 wrong window Feb 05 04:14:32 the patch is needed if you want to connect a li-ion battery to the battery terminals (TP5-TP8) Feb 05 04:15:04 (which is not an officially supported feature) Feb 05 04:17:44 this section contains links to mailing list posts explaining both the problem and my solution thereof -> http://elinux.org/BeagleBone_Power_Management#Battery Feb 05 04:18:19 Looks like I need a patched one, then. :P Feb 05 04:18:36 Oh; that's not so much a patch as a mod, isn't it? Feb 05 04:18:54 Also, don't you need proper battery management for that? Feb 05 04:19:37 you mean like a "Single-Chip PMIC for Battery-Powered Systems", which is what the TPS65217 is officially advertised as Feb 05 04:20:28 http://gerbil.xs4all.nl/batbeagle.jpg ;) Feb 05 04:21:25 and what do you mean with "patch" vs "mod" ? Feb 05 04:22:06 I mean, in my vocabulary this is still a patch... https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Feb 05 04:26:28 batbeagle actually has a second patch as experiment to also allow RTC-only mode to work. it does work, but the patch is extremely awkward to perform so it's simpler to use just an external RTC Feb 05 04:27:06 (moving R8 to R9) Feb 05 04:27:31 O.K., I see what you mean. Feb 05 04:27:55 Have you at all noticed whether the Blue one is going to have that change? Feb 05 04:28:06 the blue one? Feb 05 04:28:48 so far none of the BBB-derivatives seem to have bothered fixing any of its known issues Feb 05 04:29:19 possibly due to ignorance of those issues, I don't know Feb 05 04:30:13 Other issues? Feb 05 04:30:58 well, the fact that the PMIC briefly goes into FAULT state on every "clean" shutdown isn't exactly elegant, although that's more due to the idiotic design of the PMIC Feb 05 04:32:08 and while powering the battery terminals makes a 3v3b-regulator absolutely *necessary*, even normally the 3v3b stays active much longer than it is supposed to Feb 05 04:32:35 causing undesirable current flows (especially if you have a serial cable attached during shutdown) Feb 05 04:33:50 most people probably aren't bothered by it, but I certainly wouldn't consider the BBB to be an exemplary hardware design Feb 05 04:34:08 zmatt: you have fed back these issues to Gerald ..he is aware, right? Feb 05 04:34:25 veremit: the 3v3 regulator issue actually dates back to the BBW Feb 05 04:35:03 he implemented a wrong fix in early BBB revisions which caused more problems than it solved, then went back to the previous scheme rather than fixing it properly Feb 05 04:35:06 zmatt: may be true, but the BBB is still undergoing small board revisions .. Feb 05 04:35:43 (A6 implemented that change I think) Feb 05 04:36:34 so yes he's aware of it, or certainly at least was... Feb 05 04:37:57 just strikes me that if the changes are reasonable, and justified .. why don't they 'happen' .. Feb 05 04:38:21 not like we're talking about major rework .. ! Feb 05 04:38:35 well to be fair it's not obvious how to *properly* fix this one Feb 05 04:38:58 my solution isn't acceptable in general since it severely limits the amount of current a CAPE can draw from the 3.3V Feb 05 04:39:10 solutions are ofc the key .. you can rant until the sun/moon/etc rises/falls/etc Feb 05 04:39:23 the best solution would be a voltage-tracking regulator, but they're not very common Feb 05 04:40:04 it's the surest way of preventing a significant voltage difference between the 3v3a and 3v3b Feb 05 04:40:27 the issue is in sequencing chiefly right? surely you can sorta 'fudge' that with some ingenuity .. Feb 05 04:41:25 enabling the 3v3b after the 3v3a (but before pgood is asserted) should work yes Feb 05 04:41:56 but iirc there's not really a useful signal in that time interval Feb 05 04:42:10 and the pmic can't be reprogrammed Feb 05 04:42:28 you'd have to rely on a r-c or similar .. Feb 05 04:42:43 gate delay of smething Feb 05 04:42:58 or* Feb 05 04:43:08 keep in mind it alsos needs to work in reverse during poweroff Feb 05 04:43:28 yeah so a C would seem a logical option .. Feb 05 04:43:34 no wait Feb 05 04:43:35 no Feb 05 04:43:45 hrmm right Feb 05 04:44:01 back to my point of ingenuity ;D Feb 05 04:44:31 there are ways to get a fast drop .. you can clamp a C .. Feb 05 04:45:23 you really want a less shitty pmic Feb 05 04:45:25 :P Feb 05 04:45:41 well there is that .. but I was saying about minor board reworks :P Feb 05 04:47:21 or being able to customize the pmic programming would also solve the problem, move LDO2 to a later strobe than LDO4 and use it as the 3v3b-enable (like it was on the BBB before A6) Feb 05 04:47:30 but TI refuses to let customers program their pmics Feb 05 04:47:39 for unspecified reasons Feb 05 04:47:50 and beagle won't do it? Feb 05 04:48:12 why not revert the a6 change .. or does that affect other stuff which is Bad*tm* Feb 05 04:48:35 it enables the 3v3b *before* the 3v3a Feb 05 04:48:50 1 ms before Feb 05 04:49:09 and disabled 3v3b 1 ms after disabling the 3v3a on shutdown Feb 05 04:49:40 so there is an enable signal on that reg... Feb 05 04:49:46 of course Feb 05 04:50:05 you might want to read my post explaining the actual issue :P Feb 05 04:50:06 the change was documented .. and was there a reason? Feb 05 04:50:26 I recall vaguely .. but its late/early and I'm saving brain power :D Feb 05 04:50:28 yes, enabling the 3v3b before the 3v3a is chip-frying-bait Feb 05 04:50:48 since external 3v3b-powered hw may be driving a signal into the am335x Feb 05 04:51:08 (you don't even need a cape for that, the console uart buffer is powered by the 3v3b for inexplicable reasons) Feb 05 04:51:12 which is insane .. Feb 05 04:51:26 most likely a bodge Feb 05 04:51:43 so they went back to the old trick: using 3v3a as enable-signal for the 3v3b Feb 05 04:51:50 or plain oversight Feb 05 04:51:56 eww Feb 05 04:51:59 horrible Feb 05 04:52:17 indeed, a power supply is not a digital signal Feb 05 04:52:48 means its held up on power-off :/ Feb 05 04:52:50 once the 3v3a drops sufficiently below 3v3b, enough current will leak from 3v3b to 3v3a to prevent it from falling any further Feb 05 04:52:53 until the supply collapses Feb 05 04:52:57 thus is stays logic high, and the 3v3b stays enabled Feb 05 04:53:22 "fortunately" the idiotic pmic unconditionally switches to battery power at the start of sequenced powerdown, regardless of whether a battery is actually present Feb 05 04:53:50 its a phone pmic isn't it .. Feb 05 04:54:05 so the caps run out fast enough to keep the 3v3b to do any real harm... hopefully Feb 05 04:54:09 I know we had this discussion .. never designed as an offline powered thing. Feb 05 04:54:20 battery-powered devices, not really phones Feb 05 04:54:24 it's not an omap pmic Feb 05 04:54:39 no .. its probably Cheap. Feb 05 04:54:50 since that seems to govern a lot of the BBB hardware Feb 05 04:54:52 those actually well-designed... this thing has the same design qualities as the am335x itself Feb 05 04:55:02 i.e. it looks like it was done by an intern, in a hurry Feb 05 04:55:29 well that happens all too often, alas. Feb 05 04:56:01 it's a real shame... the dm814x seems to be last TI SoC that was still *designed* rather than cobbled together Feb 05 04:56:27 even Vayu is a mess, just browse its control module -.- Feb 05 04:56:53 (not to mention the 1 year delay due to some, ehm, reset issues) Feb 05 04:58:14 a lot of TI chips seem to be very quirky Feb 05 04:58:31 to be fair, those SoCs are insanely huge and complex Feb 05 04:59:13 so bugs I can understand Feb 05 04:59:30 other manufacturers seem to manage it .. to a greater or lesser extent :) Feb 05 04:59:55 but sure .. I'm not gonna be designing any arm devices in a hurry Feb 05 05:00:05 the am335x prcm however is a mess that defies belief... it's like the register file was organised using "sort -R" Feb 05 05:00:09 or even any arm boards! Feb 05 05:00:52 I'm not so convinced the grass is greener elsewhere though Feb 05 05:01:38 I just happen to know TI SoCs well enough to know their issues :P Feb 05 05:02:22 but omapgeddon does seem to have harmed the quality of their SoCs Feb 05 05:02:43 or maybe my standards are just too high, dunno Feb 05 05:03:35 I see what you mean... Feb 05 05:05:06 I think it's not too much to ask for the "reset control" and "reset status" registers of a power domain to use the same fucking bit allocation of reset lines :P Feb 05 05:05:27 Would it make sense to put a significant impedance between the two input pins, and then surround the input pins with tri-state switches? That way, on startup, you tie the first switch to power, which starts up one 3v3 regulator, then the impedance, then the other regulator, and then the floating switch, which switches to power... Feb 05 05:06:01 On power-down, you switch the switch that would be powered on startup to floating, and then the shutdowns happen in reverse. Feb 05 05:06:11 Tenacious-Techhu: you can of course protect the am335x (as well as external hardware) in numerous ways Feb 05 05:06:36 "don't be a duffer, always buffer"! Feb 05 05:06:51 boofer Feb 05 05:06:59 but inserting high-speed bus switches on all I/Os is not exactly a small/simple/cheap solution Feb 05 05:07:03 Would it be possible to issue a pull request for contributed changes to the board's design? Feb 05 05:07:26 I think the tradition is to bug Gerald on the ML .. Feb 05 05:07:42 there's a bug tracker too... I think nobody reads it Feb 05 05:07:43 I've seen him on there Feb 05 05:07:57 In this case, we're using them to control which direction the "power up" and "shut down" signals travel in. Feb 05 05:08:29 Well yes, but bugging him about changes to make, and making those changes and issuing a pull request are two separate things. Feb 05 05:09:18 Tenacious-Techhu: well I've solved the problem in a way that satisfies our needs, and I've already got enough power domain headaches without also trying to come up with a generic fix for the bbb Feb 05 05:09:49 Fair enough; but do they have a means to accept a pull request if one was provided? Feb 05 05:10:21 I should probably also tell him to put a large cap on the output of the usb power switch, as the datasheet explicitly recommends, but I just can't be bothered to put in the effort :P Feb 05 05:12:54 What about the industrial versions of these boards they're coming out with? Feb 05 05:13:33 I didn't really see the difference, but I also haven't really looked at them in any detail Feb 05 05:14:06 so 3.8 kernel i can read the eeprom and write eeprom, 4.1 kernel cant do either Feb 05 05:15:25 Hewball: reading works fine for me (via /sys/bus/nvmem/devices/0-00500/nvmem in case of the on-board eeprom), except it overreads by one byte Feb 05 05:15:46 not onboard on cape Feb 05 05:16:05 so 2-0056 Feb 05 05:16:08 I don't have a cape to try but I presume they'd appear in /sys/bus/nvmem/devices also? Feb 05 05:17:26 id have to write the new os back to try it Feb 05 05:18:43 I also don't really understand the point of those nvmem patches or why rcn-ee merged them Feb 05 05:18:53 especially since they seem to be buggy Feb 05 05:25:45 ah nvmem is mainline now Feb 05 05:25:46 fair enough Feb 05 05:26:48 what kernel are you running? Feb 05 05:28:48 typically the most recent member of either the 4.1-ti or 4.4-bone branches, usually customized Feb 05 05:29:42 yeah ill flash these eeproms so i can mark these boards as done and send them off and then try newer kernel again Feb 05 05:31:27 What distributions are they using for Industrial applications? Feb 05 05:31:59 you already asked that, more than once. if someone had any clue, they probably would have answered Feb 05 05:32:27 Tenacious-Techhu: personal preference like everyone else Feb 05 05:33:43 I was just wondering if there was something appropriately specialized for the task, but I guess not. Feb 05 05:34:25 or possibly there is but noone currently active here is familiar with it Feb 05 05:34:31 i use either ubuntu or debian depending on the task Feb 05 05:34:44 ew, ubuntu... Feb 05 05:35:02 see my point about personal preference ^^^ Feb 05 05:35:06 hehe Feb 05 05:52:25 zmatt, is the serial cable thing still relevant with unpowered serial cables, or only the powered ones? Feb 05 05:52:43 what on earth is an "unpowered serial cable" ? Feb 05 05:53:00 transmit-data is driven high on an idle line Feb 05 05:53:05 that's power enough Feb 05 05:53:48 (in fact the problem is the actual driver is the buffer IC on the beaglebone, which is powered from the 3v3b) Feb 05 05:54:17 so pulling RxD (data to BBB) high suffices Feb 05 05:58:50 Well, some serial cables supply power to a board in order to be able to have something to read; but there's a particular one I know of from FTDI that uses a vsense line instead, to sample what voltage of serial is being used, rather than powering it to a known value. Feb 05 05:59:13 I'm wondering if using that instead might avoid the problem you're talking about. Feb 05 05:59:46 powering the buffer IC from 3v3a would already fix this particular issue Feb 05 05:59:53 as would fixing the 3v3 regulator bug Feb 05 06:03:34 Does the USB 5V show up at the barrel jack at all, for charging purposes? Feb 05 06:04:08 eww eww eww Feb 05 06:06:02 Not a good idea, huh? Feb 05 06:07:32 that would be some serious crazy leakage Feb 05 06:07:49 afaik those are two completely different power sources for the pmic Feb 05 06:08:03 sources/sinks Feb 05 08:41:26 panto: it's getting better. I moved to your latest tree and tweaked a few things. had to remove cs-gpios since it doesn't work (and I saw you have already patched mcspi), I'm still struggling with spi->irq being zero. did anything change wrt interrupts? Feb 05 13:52:09 Hello everyone! I am a second year engineering student pursuing electronics and communications.I have been working with the beaglebone for some time now and I would like to contribute and also apply in GSOC for Beaglebone.Could someone please guide me? Feb 05 14:17:15 chanakya_vc: follow this channel and the mailing list Feb 05 14:48:28 zmatt: you were right cape slot zero is now nvmem at /sys/bus/nvmem/devices/at24-1/nvmem Feb 05 14:56:33 does anyone here have any experiance with the Crypto cape? Feb 05 14:57:42 I am trying to figure out how to access one of the chips on it via i2c, but I cant seem to find any documentation of the i2c address of the chip Feb 05 14:58:11 brycecater: what chip? Feb 05 14:58:28 (and no I don't have experience with it, most of its content seems of limited to no use) Feb 05 14:59:17 the atmel ATAES132 Feb 05 15:00:07 brycecater: and the data sheet says what? Feb 05 15:00:27 hooked up via i2c instead of spi? pity, there goes performance... Feb 05 15:00:55 it says the the default address for the chip should be 0xA0 Feb 05 15:01:22 but the i2cdetect does not go that high Feb 05 15:01:28 The default value of the I2CAddr Register is 0x01 for devices configured for I2C interface mode Feb 05 15:01:28 brycecater: what kernel? Feb 05 15:03:07 so it's not 0xa0 Feb 05 15:03:16 0x50 maybe? Feb 05 15:03:25 no, 0x01, I just quoted the datasheet Feb 05 15:03:40 at least that's its factory default, you can reconfigure it Feb 05 15:03:43 zmatt: yeah, it says that down in the memory map appendix... but take a look at page 86 Feb 05 15:04:09 maybe i am not understanding the what they are saying on that page Feb 05 15:04:14 zmatt: readink data sheet is cheatink!!! Feb 05 15:04:28 brycecater: ok weird so it's being inconsistent Feb 05 15:04:45 yeah :P Feb 05 15:05:15 although that probably does mean 0x50 indeed Feb 05 15:05:25 since bit 0 isn't part of the address in that register Feb 05 15:06:42 I2CAddr is 0xA1 (the I2C Device Address is 0xA0) for catalog numbers with an I2C interface configuration Feb 05 15:07:33 av500: yeah, and elsewhere it says 0x01 ... in both cases bit 0 merely indicates i2c is being used and is a placeholder for the r/w bit, so the actual device address would be 0x50 or 0x00 respectively, depending on which part of the datasheet is right Feb 05 15:08:22 ...The default value of the I2CAddr Register is 0x01 for devices configured for I2C interface mode Feb 05 15:08:35 I assume this is wrong Feb 05 15:08:46 that would be I2C address 0x00 Feb 05 15:08:52 ahh... thanks guys. that totally makes sense now Feb 05 15:08:54 that's what I just said :) Feb 05 15:09:03 zmatt: right Feb 05 15:09:08 and i2c detect shows up 0x50 Feb 05 15:09:12 see Feb 05 15:09:17 it was there all along Feb 05 15:09:21 only one >>1 away Feb 05 15:09:24 or << 1 Feb 05 15:09:37 or bit reverse if you're lucky Feb 05 15:09:45 hahaha.. yep Feb 05 15:09:57 zmatt: now you are silly Feb 05 15:10:36 av500: I wish I were... I once encountered an i2c chip that used reversed bit-endianness for data (but not commands) Feb 05 15:10:49 well, data is data Feb 05 15:10:58 anything goes Feb 05 15:11:08 :P Feb 05 15:11:22 as far as the bus cares, it's all "data" Feb 05 15:12:25 yes and no, there are numerical fields and therefore msb vs lsb does matter Feb 05 15:13:15 though since ARM has a bitreverse instruction nowadays I wouldn't really care much about reverse bit endianness either Feb 05 15:21:55 interesting, farnell doesn't even list the ATAES and ATECC devices, and lists the ATSHA as "no longer in production" Feb 05 15:24:34 weird Feb 05 15:30:34 echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-1/new_device Feb 05 15:30:47 oops... Feb 05 15:30:57 thought that was a terminal Feb 05 15:38:03 does anyone have any recommendations about the best way to interface with an eeprom attached via i2c ? Feb 05 15:38:32 brycecater: what kernel it moved Feb 05 15:39:24 Hewball: 3.8.13 Feb 05 15:39:38 oh nope thats still where you are looking Feb 05 15:40:52 huh? not sure i undrstand Feb 05 15:41:11 eeproms move in the newer kernels it seems Feb 05 15:41:26 what eeprom are you using ? Feb 05 15:42:07 it is the ATAES132... it is an EEPROM with AES capabilities. I am just trying to get the EEPROM part of it working first Feb 05 18:49:27 hello im trying to use timer to blink led in kernel module Feb 05 18:49:44 i need help Feb 05 18:51:09 have you read ldd3? Feb 05 18:58:41 i need some help Feb 05 18:59:13 i want to create simple kernel module blinking led with timer any help ? Feb 05 19:03:50 create a module, and use linux hrtimers to toggle a gpio, with this you get into microsecond accuracy Feb 05 19:04:35 if you really need a harware timer with an interrupt look into ./arch/arm/plat-omap/dmtimer.c it's a bit more tricky though Feb 05 19:06:08 have you any simple exemple ? Feb 05 19:06:16 just to start with Feb 05 19:08:43 no, not really, there is an article about hrtimers https://lwn.net/Articles/167897/ which covers them a bit, but you obviously need some basic background in linux kernel programming Feb 05 19:13:20 thankss alooooooot Feb 05 19:14:27 this is what i want some basic Feb 05 19:14:31 s Feb 05 19:17:17 also keep in mind this article is from 2006 and if i remember correctly the hrtimer api and struct have changed a bit so if you encounter any issues you best bet would be to look into the include/linux/hrtimer.h and kernel/time/hrtimer.c files in the linux kernel source tree Feb 05 20:46:36 hi guys Feb 05 20:47:03 does beagleboard x15 has gpio pins Feb 05 21:25:51 Is there a version of Debian 8 I can put on the 2GB eMMC flash of my BBB? Feb 05 21:26:12 I found a 4GB image that runs from the SD card fine, but I want to put it on my eMMC **** ENDING LOGGING AT Sat Feb 06 02:59:58 2016